/third_party/tcpip/wolfssl.
Product information is available from the wolfSSL website: https://www.wolfssl.com/wolfSSL/Products-wolfssl.html
For technical documentation, visit: https://www.wolfssl.com/wolfSSL/Docs.html
Additional information is also available from the Microchip Third-Party Software Stacks web page: http://www.microchip.com/devtoolthirdparty/.
Volume VI: Third-Party Products wolfSSL Library Help Introduction
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 75
Index
A
Abstraction Model 21, 29
B
Binary to C Converter (Bin2C) 26
Bitmap Converter (BmpCvt) 26
Build and Program the Application 72
Building the Library 32
C
Configuration Files 44
Configuring the Browser 9
Configuring the Hardware 57
Configuring the Library 23, 32
Creating a New SEGGER emWin Application Within MPLAB Harmony 62
D
Decoder Library Help 4
Demonstration Output 73
E
emWin SPY (emWinSPY) 28
emWin VNC Client (emVNC) 27
emWin Windows View (emWinView) 28
EMWIN_GUI_SCREEN_CREATE type 40
EMWIN_GUI_SCREEN_INITIALIZE type 40
emWin_GuiInitialize function 33
emWin_GuiScreenChange function 34
emWin_GuiScreenEnd function 38
emWin_GuiScreenGet function 39
emWin_GuiScreenInitializeRegister function 35
emWin_GuiScreenRegister function 35
emWin_GuiStartScreenSet function 36
emWin_GuiTasks function 37
EMWIN_TOUCH_INIT structure 42
emWin_TouchInitialize function 41
emWin_TouchMailBoxCreate function 42
Express Logic ThreadX Library Help 5
F
Font Converter (SetupFontCvtDemo_V532) 27
FreeRTOS Library Help 6
G
Get Operation 11
Get_Bulk Operation 12
Get_Next Operation 12
Getting Started 8
GUI and Touch Wrapper Library for SEGGER emWin 28
GUI Builder (GUIBuilder) 25
GUI Resource Management 55
GUI Wrapper Screen Change 31
GUI Wrapper Setup 31
H
Hardware Requirements 56
How the Library Works 22, 30
HTTP Configuration 16
I
Initializing the GUI and Touch Wrappers 30
Integrating SEGGER emWin and MPLAB Harmony 45
Integrating the GUIBuilder Output with MPLAB Harmony 69
InterNiche Library Help 7
Introduction 3, 4, 5, 6, 7, 8, 18, 19, 20, 21, 28, 74, 75
iREASONING Networks MIB Browser 8
J
JPEG to Movie Converter (JPEG2Movie) 27
L
LCD Integration 49
Library Interface 24, 32
Library Overview 22, 29
Loading the GUIBuilder Output into the MPLAB Harmony Project 68
M
Micrium uC/OS Libraries Help 18
MPLAB Harmony Configurator (MHC) 47
O
OPENRTOS Library Help 19
S
SEGGER embOS Library Help 20
SEGGER emWin Event Handling 51
SEGGER emWin Graphics Library Help 21
SEGGER emWin GUI Application Design Process 57
SEGGER emWin Library Architecture 21
SEGGER Utility Tools 24
Set Operation 13
Setup (Initialization) 23
SNMP Operations 11
Software License Agreement 3
Third-Party 3
Software Requirements 57
Start-to-End Example of SEGGER emWin Graphics with MPLAB
Harmony 56
T
Third-Party Products Overview 3
Touch Integration 50
Touch Wrapper Setup 31
Trap Test 15
U
Using GUIBuilder to Create Screens/Dialog Boxes 57
Using SEGGER emWin with MPLAB Harmony 42
Using the Library 29
UTF-8 Text to C Converter (U2C) 26
V
Volume VI: Third-Party Products 2
W
wolfMQTT Library Help 74
wolfSSL Library Help 75
Index
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 76
Data Visualizer
Data Visualizer Software User's Guide
Description
The Data Visualizer is a program to process and visualize data. The Data Visualizer is capable of
receiving data from various sources such as the Embedded Debugger Data Gateway Interface (DGI) and
COM ports.
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 1
Table of Contents
Description.......................................................................................................................1
1. Overview....................................................................................................................4
1.1. Getting Help................................................................................................................................. 6
1.2. Key Concepts...............................................................................................................................6
1.2.1. Workspace.....................................................................................................................6
1.2.2. Connection Overview.....................................................................................................7
1.2.3. Embedded Debuggerʼs Data Gateway Interface........................................................... 7
1.2.4. Simple Transfer..............................................................................................................7
1.2.5. Endpoints.......................................................................................................................8
1.3. Launching Data Visualizer............................................................................................................8
2. External Connection................................................................................................ 10
2.1. Data Gateway Interface (DGI)....................................................................................................10
2.1.1. SPI Interface................................................................................................................13
2.1.2. USART Interface..........................................................................................................14
2.1.3. TWI Interface............................................................................................................... 15
2.1.4. GPIO Interface.............................................................................................................16
2.1.5. Power Interface............................................................................................................18
2.1.6. Code Profiling.............................................................................................................. 19
2.1.7. Sink Data Conversion..................................................................................................34
2.1.8. DGI Data Polling..........................................................................................................35
2.2. Serial Port...................................................................................................................................35
3. Visualization.............................................................................................................40
3.1. Terminal......................................................................................................................................40
3.1.1. Terminal Module.......................................................................................................... 40
3.1.2. Terminal Configuration Example..................................................................................41
3.2. Graph......................................................................................................................................... 43
3.2.1. Graph Module..............................................................................................................43
3.2.2. Graph Configuration Example..................................................................................... 52
3.3. Oscilloscope...............................................................................................................................59
3.3.1. Oscilloscope Module....................................................................................................59
3.3.2. Oscilloscope Configuration Example...........................................................................65
3.4. Power Debugging.......................................................................................................................69
3.4.1. Power Debugging Module........................................................................................... 69
3.4.2. Basic Current Measurement........................................................................................74
3.4.3. Power Analysis using Cursors.....................................................................................77
3.4.4. Code Correlation..........................................................................................................78
3.5. Custom Dashboard.................................................................................................................... 82
3.5.1. Dashboard Module...................................................................................................... 82
3.5.2. Dashboard Configuration Example..............................................................................98
4. Utilities................................................................................................................... 104
4.1. Samplerate Counter................................................................................................................. 104
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 2
4.2. File Logger............................................................................................................................... 104
4.2.1. Logging to a Binary File.............................................................................................104
5. Protocols................................................................................................................105
5.1. Data Stream Protocol...............................................................................................................106
5.1.1. Configuration Format.................................................................................................106
5.1.2. Stream Format...........................................................................................................107
5.1.3. Basic Usage...............................................................................................................107
5.1.4. Auto-Configuration.....................................................................................................107
5.1.5. Auto-Configuration Example......................................................................................108
5.1.6. Auto-Configuration Format.........................................................................................118
5.1.7. Signal Connections File Format.................................................................................120
5.2. Atmel Data Protocol................................................................................................................. 121
5.2.1. Transfer using Atmel Data Protocol...........................................................................121
5.2.2. ADP Example............................................................................................................ 122
5.2.3. Message Flow............................................................................................................149
5.2.4. Message Format........................................................................................................149
5.2.5. Message Types..........................................................................................................149
6. Example Code Snippets........................................................................................ 180
6.1. Data Polling Example Code..................................................................................................... 180
6.1.1. Application Interaction using Dashboard Controls.....................................................183
6.2. Terminal Example Code........................................................................................................... 183
6.3. Graph Example Code...............................................................................................................186
6.3.1. Basic Graph...............................................................................................................187
6.3.2. Adding String Markers............................................................................................... 190
6.3.3. Using Horizontal Cursor Code...................................................................................191
6.4. Oscilloscope Example Code.................................................................................................... 193
6.5. Dashboard Example Code....................................................................................................... 197
6.6. Auto-Configuration Example Code...........................................................................................201
7. Known Issues........................................................................................................ 205
8. Document Revision History................................................................................... 206
The Microchip Web Site.............................................................................................. 207
Customer Change Notification Service........................................................................207
Customer Support....................................................................................................... 207
Microchip Devices Code Protection Feature............................................................... 207
Legal Notice.................................................................................................................208
Trademarks................................................................................................................. 208
Quality Management System Certified by DNV...........................................................209
Worldwide Sales and Service......................................................................................210
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 3
1. Overview
This chapter gives an overview of the main modules/features of the Data Visualizer. Each module is
described in a separate chapter with technical details of the module, and includes an example or use
case showing how to use the module. As each chapter is self-contained, it is possible for the user to
quickly identify and select the chapter/module of interest.
Data Gateway Interface (DGI)
Data Gateway Interface (DGI) enables bidirectional communication over SPI, I
2C, and USART, in
addition to GPIO monitoring, power measurement, and code profiling.
Serial Port
Serial Port communicates with any serial port on the system.
Terminal
Terminal display and send simple text or numeric values.
Graph
Graph can be used to plot data source values vs. time.
• Cursors (time axis) to measure application timing (e.g., PWM frequency)
• Horizontal cursor (data values) to control an applicationʼs set point or threshold
• Band highlights time periods above customizable thresholds
• String markers can be used to add descriptive text to graphed events
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 4
Oscilloscope
Oscilloscope
• Edge or threshold triggers on rising or falling edges
• Run-stop control for single shot or continuous triggering
• Cursors (time axis) to measure application timing (e.g., PWM frequency)
Power Debugging
Power Debugging
• Correlation of code execution and power consumption
• Displays current and voltage measured using Power Debugger (Embedded debugger on some
kits)
Custom Dashboard
Custom Dashboard
• Build a custom user interface to visualize and control user application using: graph, segment
display, binary signals, labels, buttons, linear gauge: Value within defined range. Pie Chart (e.g., for
packets lost vs. transmitted in wireless application).
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 5
Utilities
• Samplerate Counter to validate MCU frequencies (e.g., rate of transmitted ADC samples)
• File Logger module logs all incoming data to a file of selectable format
1.1 Getting Help
Help can be opened at any time by clicking F1. By selecting a module in the Configuration window and
clicking F1, help will be opened at the relevant chapter automatically.
1.2 Key Concepts
This section describes the key concepts to understand when working with the Data Visualizer.
1.2.1 Workspace
Data Visualizer is made up of several elements such as graphs, interfaces, and controls. All these
elements form the workspace.
The elements are called modules, in which any of them can be added to the workspace.
Figure 1-1. Data Visualizer Workspace
1 2 3
4
5
1. Expand/Collapse Configuration pane button. 2. Configuration and Messages pane. 3. Active
modules. 4. Minimize module button. 5. Remove module button.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 6
1.2.2 Connection Overview
The Data Visualizer communicates with the firmware running in the MCU of the embedded system.
Variables in the firmware can be transferred in both directions. In the following example, the temperature
value is sent to the visualizer and plotted in a graph. The filter strength value is set by dragging the slider
in the visualizer, and is then sent to the MCU.
Figure 1-2. Data Visualizer Connection Overview
Embedded system
MCU
PC
Temperature
int temperature;
int filter_strength;
Filter
USB or Strength
serial cable
The communication can take place in a serial cable or USB if the embedded system contains an
Embedded Debugger. (The Xplained Pro MCU boards contain Embedded Debuggers.)
1.2.3 Embedded Debuggerʼs Data Gateway Interface
The Xplained Pro family of boards contain an Embedded Debugger chip. It has a Data Gateway Interface
(DGI) that lets the MCU easily communicate with the Data Visualizer through either its SPI or TWI
interface, or by GPIO pins.
Figure 1-3. The Data Gateway Interface
MCU
Xplained Pro series board
Embedded
Debugger
SPI
TWI
GPIO
USB
In the Data Visualizer, the DGI Control Panel is the module that communicates with the Embedded
Debuggerʼs Data Gateway Interface. When the board is connected to the computer with the USB cable, it
can be selected in the control panel. A list of available interfaces will appear. Enable one or more of them
by checking the boxes. In the figure above, the SPI interface is enabled. The MCU can now communicate
with the Data Visualizer on its SPI port.
1.2.4 Simple Transfer
Sending a single value from the MCU to the Data Visualizer is quite simple. In the figure below, the MCU
sends the temperature variable over its SPI interface. In the visualizer, the SPI interface on the
Embedded Debugger has been enabled. The Embedded Debugger will transmit the SPI data to the
visualizer through the DGI Control Panel.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 7
Figure 1-4. A Simple DGI Transfer
To visualize the temperature data, a Graph has been added. The SPI data is routed to the plot by
dragging the plug icon from the SPI interface in the DGI Control Panel, and dropping it in the plot area.
This will add a new plot to the Graph module.
1.2.5 Endpoints
Data in the Data Visualizer originates from an endpoint and ends in an endpoint. The endpoints are
referred to as sinks and sources. A data source sends data to one or more connected sinks.
In the workspace, the endpoints are represented by the graphical symbols shown below.
Figure 1-5. Data Source
Figure 1-6. Unconnected Data Sink
Figure 1-7. Connected Data Sink
1.3 Launching Data Visualizer
The Data Visualizer is included as part of the Atmel Studio installer, and can be run either as a Studio
extension or in Stand-alone mode.
To run the Data Visualizer as an extension inside Atmel Studio, select it in the Tools menu:
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 8
Kits supporting Data Visualizer functionality include a shortcut to the extension on their start page in
Atmel Studio.
If the stand-alone version of the Data Visualizer has been installed, look for the shortcut in the Windows®
start menu. The stand-alone version is available for download from gallery.atmel.com.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 9
2. External Connection
All communication to the outside world is handled by modules found under the external connection
section.
The DGI Control Panel communicates with any tool that has the Data Gateway Interface. It is capable of
bidirectional communication over SPI, I2C, and USART, in addition to GPIO monitoring, power
measurement, and code profiling. The feature set varies by tool.
The Serial Port Control Panel communicates with any serial port on the system.
2.1 Data Gateway Interface (DGI)
The Data Gateway Interface is available on most kits with an Embedded Debugger. The DGI control
panel can communicate with a DGI device. The figure below shows the DGI control panel module.
Figure 2-1. Data Gateway Interface Control Panel
Tip: A new DGI Control Panel can be opened in External Connection in the Modules section
of the Configuration tab in the Data Visualizer.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 10
All detected DGI devices are listed in the drop-down list with the kit name and serial number. Using the
Connect button will connect to the selected DGI device and query for available interfaces. The available
interfaces will be listed under Interfaces. To enable an interface, check the box next to the name. When
an interface is enabled, the sources and sinks can be connected to other endpoints. The Gear button is
used to configure the interface. See the interface-specific sections for an explanation of the configuration
fields.
To start polling data from the interfaces, click the Start button. The Reset MCU check box will cause the
MCU to be held in Reset during start.
The Data Visualizer supports two different protocols for Auto-configuration; the Atmel Data Protocol
(ADP) and the Data Stream protocol. When using ADP, the configuration resides in the target application
code and the target application sends the configuration settings, upon request, from the Data Visualizer.
When using the Data Stream protocol, the configuration resides in files stored on the host computer and
the target application just sends an ID to identify which configuration files to be loaded by the Data
Visualizer. For more information on ADP, see Atmel Data Protocol. For more information on the Data
Stream protocol, see Data Stream Protocol.
To enable Auto-configuration the Autodetect protocols option must be enabled.
After pushing Connect the Data Visualizer will enable all interfaces while it looks for the ADP handshake
message or a Data Stream Configuration packet. If an ADP handshake message is received, the Data
Visualizer will request configuration information from the target application. If a Data Stream Configuration
packet is found, the Data Visualizer searches through the folders in the Auto-Configuration search path
looking for configuration files with names matching the detected ID.
Important: To make sure the Data Visualizer detects the Data Stream Configuration packet, it
must be sent by the target at least twice per second.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 11
Important: Asynchronous serial protocols (e.g., UART protocols used by DGI USART and
CDC Virtual COM port interfaces) use the following baud rates for auto-detection:
Table 2-1. Baud Rates Used on Asynchronous Interfaces for Auto-Detection of Protocols
Baud Rate
9600
19200
38400
57600
115200
230400
500000
1000000
2000000
Using any baud rates not in the table will not work for auto-detection of protocols over
asynchronous interfaces (DGI UART and Serial port/CDC Virtual COM port).
Tip: To see the current search path used by Data Visualizer to look for configuration files,
check the Show Config search path option.
The search path is a semicolon separated list of paths. When Data Visualizer detects an AutoConfiguration
ID, it will search through the paths in the list looking for configuration files with the
correct file names.
If the Data Visualizer cannot find any valid configuration files it will show a browser dialog window asking
for the path to the folder where the correct configuration files reside.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 12
After selecting a folder, the folder will be APPENDED to the Auto-Configuration search path.
Tip: To reset the search path and select a new single folder as the search path, click the link
on the Autodetect protocols option text.
Data Visualizer will then pop up a browser dialog asking for the path to the folder where the
configuration files reside. The original search path will be CLEARED and the newly selected
folder will be set as search path.
Important: All three configuration files must reside in the same folder.
2.1.1 SPI Interface
The SPI interface source contains the raw values received on the SPI interface. The sink sends values
received back out on the SPI bus. For further details on the physical part of the SPI interface, see the
user guide of the debugging tool to be used to sample the SPI data.
Important: If the SPI sink is connected to a source with a multibyte type, the byte order may
be unpredictable.
Important: The SPI hardware module uses an active-low Chip Select (CS) signal. Any data
sent when the CS pin is high will be ignored.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 13
The SPI Configuration dialog is opened from the SPI interface in the DGI control panel.
Table 2-2. Configuration
Field Name Values Usage
Transfer Mode • SCK normally low, Read data on
rising edge
• SCK normally low, Read data on
falling edge
• SCK normally high, Read data on
falling edge
• SCK normally high, Read data on
rising edge
SPI mode, controlling clock phase
and sampling.
Force synchronization
on CS
ON or OFF The SPI interface is only enabled
after the Chip Select line has
toggled twice.
Enable timestamping ON or OFF Data is timestamped through the
DGI timestamp interface (yields a
slower transfer rate).
Related Links
Sink Data Conversion
2.1.2 USART Interface
The USART interface source contains the raw values received on the USART interface. The sink sends
values received back out on the USART interface. For further details on the physical part of the USART
interface, see the user guide of the debugging tool to be used to sample the USART data.
Important: If the USART sink is connected to a source with a multibyte type, the byte order
may be unpredictable.
The USART Configuration dialog is opened from the USART interface in the DGI Control Panel.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 14
Table 2-3. Configuration
Field Name Values Usage
Baud rate 0-2000000 Baud rate for UART interface in Asynchronous
mode
Char length 5, 6, 7, or 8 bits Number of bits in each transfer
Parity type None, Even, Odd, Mark, or
Space
Parity type used for communication
Stop bits 1, 1.5, or 2 bits Number of Stop bits
Synchronous mode ON or OFF Selecting Synchronous or Asynchronous mode
Enable timestamping ON or OFF Data is timestamped through the DGI timestamp
interface (yields a slower transfer rate)
Related Links
Sink Data Conversion
2.1.3 TWI Interface
The TWI interface source contains the raw values received on the TWI interface. The sink sends values
received back out on the TWI interface. For further details on the physical part of the TWI interface, see
the user guide of the debugging tool to be used to sample the TWI data.
Important: If the TWI sink is connected to a source with a multibyte type, the byte order may
be unpredictable.
The TWI Configuration dialog is opened from the TWI interface in the DGI Control Panel.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 15
Table 2-4. Configuration
Field Name Values Usage
Address 0-127 TWI slave address
Speed 100000, 400000 Speed setting for TWI slave. Used for timing.
Enable timestamping ON, OFF Data is timestamped through the DGI timestamp interface
(yields a slower transfer rate)
Related Links
Sink Data Conversion
2.1.4 GPIO Interface
The GPIO interface source is of type uint8, and contains the bit values of the enabled GPIO pins. A
packet is transmitted every time a pin toggles. The sink sends values received back out to the GPIO
pins. For further details on the physical part of the GPIO interface, see the user guide of the debugging
tool to be used to sample the GPIO data.
The GPIO Configuration dialog is opened from the GPIO interface in the DGI Control Panel.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 16
Table 2-5. Configuration
Field Name Values Usage
GPIO 0 Monitor ON, OFF Monitor GPIO pin 0
GPIO 1 Monitor ON, OFF Monitor GPIO pin 1
GPIO 2 Monitor ON, OFF Monitor GPIO pin 2
GPIO 3 Monitor ON, OFF Monitor GPIO pin 3
GPIO 0 Output ON, OFF Enable GPIO pin 0 output
GPIO 1 Output ON, OFF Enable GPIO pin 1 output
GPIO 2 Output ON, OFF Enable GPIO pin 2 output
GPIO 3 Output ON, OFF Enable GPIO pin 3 output
Mode Pin, Bus, Latched Bus GPIO pins as separate pins, a 4-bit bus, or a 3-bit bus that is
latched on rising edge of GPIO3
Important: When using any of the bus modes (Bus or Latched Bus) all GPIOs are sampled
but only those GPIOs that have monitoring enabled will trigger a sample. For example, if GPIO
0 to GPIO2 all have GPIO Monitor disabled but GPIO 3 has Monitor enabled, then GPIO values
will only be sampled when GPIO 3 changes but all four GPIO values will be read when GPIO 3
changes.
Related Links
Sink Data Conversion
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 17
2.1.5 Power Interface
The Power interface measures the power consumption of the connected circuitry. For more information
on the hardware part of the power interface, see the user guide of the debugging tool to be used for the
power measurements.
The Power Configuration window is opened from the Power interface in the DGI Control Panel.
The content of the Power Configuration window will vary depending on the capabilities of the connected
debugging tool.
Table 2-6. Power Configuration Options
Field Name Values Usage
Enable B
Channel
ON, OFF Enables the second power measurement channel. The A channel is
always enabled.
Trigger
calibration
ON, OFF Triggers the calibration procedure of the current measurement circuitry.
For further details, see Power Measurement Calibration.
Enable Range
Source
ON, OFF Provides a range source, indicating which range is in use for the
primary power measurement channel. The physical hardware used to
measure power consumption will have different configurations
depending on the instantaneous current measured. Each configuration
is referred to as a range.
Lock ChA to High
Range
ON, OFF On the Power Debugger, the A channel can be locked to the high
range to avoid automatic switching to the low range. This allows
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 18
Field Name Values Usage
detection of short spikes in current consumption without critical
samples being lost when switching between the ranges.
Enable Voltage
Output
ON, OFF Enable Power Debugger Voltage Output with the value given by the
Voltage Output slider.
Voltage Output 0 - 5500 mV The Power Debugger features an adjustable target supply that can be
used to power the target application. This setting controls the output
voltage of this supply. The Enable Voltage Output option must be
enabled for the setting to take effect.
Tip: Any configuration changes will not take effect until clicking OK in the Power Configuration
window. E.g., to enable the Voltage Output the Enable Voltage Output option must be
checked, the Voltage Output value set and then after pushing OK the voltage output will
actually be enabled and set according to the slider value.
Tip: The channel A range lock will not force the debugger to return to the high current range if
already running in the low range. Either wait for a current high enough to force it to change, or
simply Stop and Start the debugger.
Important: The Power interface can only be used with the Power module. Neither the
Oscilloscope module nor the Graph module can be used with the Power interface.
2.1.6 Code Profiling
The Code Profiling interface uses the debug interface of the target device to access internal data like
Program Counter and memory locations. It provides timestamped samples of the Program Counter
address, allowing an insight in the program execution of the device. The user can also select arbitrary
memory addresses to poll and control data variables at those locations. In addition, it is possible to
monitor the state of the stack and the Power-Saving/Sleep mode of the target. Finally, it is possible to
receive arbitrary data from the target application through a message pipe in the target On-Chip Debug
(OCD) system.
The availability of the above features varies with target device types and more details can be found in the
following sections.
2.1.6.1 Code Profiling Interface
For a couple of examples on how to configure and use the Code Profiling interface, see Data Polling
Example and Program Counter Polling.
Important: The Code Profiling interface is only available when Data Visualizer is run as an
extension within Atmel Studio. This is because it needs to access the debug system on the
target device through the Atmel Studio debugger backend.
The Code Profiling Configuration window can be opened after enabling the Code Profiling interface in
the DGI Control Panel.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 19
Table 2-7. Configuration
Field Name Values Usage
Enable Code Location ON, OFF Controls the state of the Program Counter sampling.
Enable Stack Monitor ON, OFF Enables polling of the Stack Pointer to monitor stack usage (AVR®
MCU with UPDI only)
AVR MCU OCD
messaging
ON, OFF Enables routing of OCD messages to Data Visualizer rather than
Atmel Studio.
AVR MCU Sleep monitor ON, OFF Enables monitoring of the Sleep state of the MCU (AVR MCU with
UPDI only)
Add Memory Location Adds a new entry of memory location to poll and control. A text box
for entering the address (hexadecimal), selecting data type and a
Delete button will appear.
Each configuration option is detailed in the following sections.
2.1.6.2 Code Location
The Code location feature enables the Data Visualizer to sample the Program Counter of the target
device. This makes it possible to see what is being executed on the target at various sample points. It is
especially useful together with power measurements to correlate code execution with power
consumption. The sampled PC values will only show part of the code execution as in most cases it is
impossible to read out the PC values as fast as the target is executing instructions. The sampled values
are still useful to indicate which code segment is being executed at any point in time.
For an example on how to use the Code location feature, see Program Counter Polling.
Important: The Code location feature is only available on SAM devices and AVR devices
featuring the UPDI debugging and programming interface.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 20
2.1.6.3 Stack Monitor
The Stack Monitor enables developers to monitor the stack usage of their code at run-time. This is done
by sampling the Stack Pointer register via the on-chip debug module. Enable the Stack Monitor in the
Code Profiling Configuration dialog, then connect the Stack Monitor source to a graph plot sink and start
a debug session.
Important: The Stack Monitor feature is only available on AVR devices featuring the UPDI
programming and debugging interface.
The Stack Monitor feature is implemented using polling, which means that not all stack levels will be
visible. The granularity of the resulting graph is a function of the speed of the device clock, the UPDI
clock speed and the nature of the application code. It is recommended to set the UPDI clock to maximum
when using the Stack Monitor.
The example shown here is tracing the stack as points (not plot) from an application running on an
ATtiny817. The points show samples with the Stack Pointer in "Idle state" in the main loop pointing to
address 16372 (0x3FF4) and decrementing as functions are called.
Note: The Data Visualizer has no knowledge of the configuration of the stack on the device, and thus
only shows raw samples of the Stack Pointer.
2.1.6.4 AVR MCU OCD Messaging
The AVR MCU OCD messaging system is a side-channel in the on-chip debug module. It is used
extensively in some OCD variants to communicate with the core when it is stopped, but is not used by the
system during Run mode. It can be used by end-user code to send messages to the debugger at run
time. In Run mode, the debugger constantly polls the OCD for run/stop status, and at the same time picks
up any messages. AVR MCU OCD messaging is a channel for code instrumentation without using any
dedicated pins (other than the debug pins). Messages are single 8-bit values and are by default sent to
Atmel Studio and displayed in the Output window as hex values, unless routed to Data Visualizer.
AVR MCU OCD messaging can be used in several ways. The examples below show three examples of
various techniques.
• No handshaking, no guaranteed delivery
• With handshaking, blocking transport
• With handshaking, non-blocking transport
There is no standard way to use OCD messaging. The techniques shown in these examples each have
advantages and disadvantages, and make use of different resources on the target device. Not all AVR
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 21
devices support OCD messaging, and not all applications are suited to the use of OCD messaging. It is
essentially a side-channel of the on-chip-debug system.
Enable AVR MCU OCD messaging in the Code Profiling Configuration dialog, then connect the AVR
MCU OCD messaging source to a graph plot sink and start a debug session. Messages will not appear
unless code is instrumented accordingly.
The most typical use-case for AVR MCU OCD messaging is ASCII printf-style debugging displayed on a
terminal, as demonstrated in the examples. However, it could be used to transport any 8-bit data values,
or even a composite structure. Messages can, for example, be sent from an ADC sample-complete
interrupt, writing the 8-bit value of an ADC sample directly to the OCD message register. This can then be
plotted directly onto a graph in Data Visualizer.
The ̔defaultʼ OCD message channel to Atmel Studio operates at a fixed sample rate with 50 ms period.
When enabled from Data Visualizer, the polling loop makes use of ̔spareʼ cycles in the debugger to read
and transport OCD messages. This leads to a higher throughput, but is also less deterministic in timing.
AVR MCU OCD Messaging Without Handshaking
The simplest form of using AVR MCU OCD messaging is writing directly to the register without any form
of handshaking. This might be appropriate when, for example, execution speed is more important than
data completeness. A single write to the OCD message register overwrites the previous value, even if it
has not been read by the debugger yet. This could also be used for slow-changing data.
The following example shows how to output AVR MCU OCD messages without handshaking on various
AVR MCU architectures.
OCD Messaging on AVR UPDI Target Device
// Example of OCD message on AVR UPDI target
// No handshaking, no guarantee
#define SYSCFG_OCDM SYSCFG.reserved_0x18
void ocd_putchar (char c)
{
SYSCFG_OCDM = c;
}
OCD Messaging on AVR XMEGA®
Target Device
Note: DGI-based OCD messaging is not yet supported on XMEGA targets. The code shown here will
push OCD messages to Atmel Studio.
// Example of OCD message on AVR XMEGA target
// No handshaking, no guarantee
void ocd_putchar (char c)
{
OCD.OCDR0 = c;
}
OCD Messaging on AVR JTAG Target Device
// Example of OCD message on AVR JTAG target
// No handshaking, no guarantee
void ocd_putchar (char c)
{
OCDR = c;
}
OCD Messaging with Handshaking and Blocking
This example will block on each character sent via the OCD messaging system until it is ready to accept
a new character. A simple timeout is employed to prevent full lockup of code if the debugger is
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 22
disconnected. This example runs on an AVR ATtiny817 using the UPDI interface, but a similar
mechanism could be used on other AVR MCU architectures supporting OCD messaging.
#include
#include
#define SYSCFG_OCDM SYSCFG.reserved_0x18
#define SYSCFG_OCDMS SYSCFG.reserved_0x19
bool ocd_print_ready (void)
{
// Has the last character been collected?
return !(SYSCFG_OCDMS & (1 << 0));
}
bool ocd_print_char (char msg)
{
// Simple timeout mechanism
uint8_t timeout = 0xFF;
while (timeout-- && !ocd_print_ready())
;
// If the debugger fails to collect, continue
if (!timeout)
return false;
// Drop off a message
SYSCFG_OCDM = msg;
return true;
}
void ocd_print (char* pmsg)
{
// Send the message
while (*pmsg) {
if (!ocd_print_char(*pmsg++))
return;
}
}
int main(void)
{
// Send an OCD message
ocd_print ("Hello World\n");
while (1)
;
}
Interrupt-Driven Bufferred OCD Messaging
A more complex method of using AVR MCU OCD messaging involves a small I/O buffer into which a
printf function can inject data which will be gradually transferred to the debugger. A timer interrupt is used
to periodically service the printf buffer. On each interrupt a character will be sent from the buffer, if the
message channel is ready and data is available. This example runs on a megaAVR®
device with JTAG
interface, but a similar mechanism can be employed on other AVR device architectures supporting OCD
messaging.
#include
#include
#include
// Buffer allocated to OCD messaging
#define OCDR_BUFFER_SIZE 32
static uint8_t ocdr_buffer[OCDR_BUFFER_SIZE];
// Buffer pointers
static uint8_t head;
static uint8_t tail;
// Flag to indicate if a debugger is picking up the messages
static uint8_t debugger_attached = 1;
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 23
// Declarations
static int ocdr_putchar(char c, FILE *stream);
static FILE mystdout = FDEV_SETUP_STREAM(ocdr_putchar, NULL, _FDEV_SETUP_WRITE);
// Puts a char into the stream
static int ocdr_putchar(char c, FILE *stream)
{
// If the debugger fails to collect, rather just abort
if (!debugger_attached)
return 1;
// Increment head with wrapping
uint8_t tmphead;
tmphead = (head + 1 );
if (tmphead >= OCDR_BUFFER_SIZE)
tmphead = 0;
if (tmphead == tail) {
// Overflow, abort
debugger_attached = 0;
return 0;
}
// Add data
ocdr_buffer[tmphead] = c;
head = tmphead;
return 1;
}
// Timer interrupt regularly sends data
ISR(TIMER0_OVF_vect)
{
// If no data, continue
if (head == tail)
return;
// If the previous byte has not been collected, continue
if (OCDR & 0x80)
return;
// Increment tail
uint8_t tmptail = (tail + 1);
if (tmptail >= OCDR_BUFFER_SIZE)
tmptail = 0x00;
tail = tmptail;
// Send data to debugger
OCDR = ocdr_buffer[tmptail];
// Reset attached flag to allow hot-plugging
debugger_attached = 1;
}
void ocdr_printf_init (void)
{
// Zero buffer pointers
head = 0;
tail = 0;
// TC setup. 8Mhz DIV32 gives ~1ms overflow ticks
TIFR = (1 << TOV0);
TIMSK = (1 << TOIE0);
TCCR0 = (1 << CS01) | (1 << CS00);
sei();
}
int main(void)
{
// Port init
DDRB |= 0xFF;
PORTB = 0x55;
// Buffer init
stdout = &mystdout;
ocdr_printf_init();
// Demo loop
uint8_t c = 0;
while(1)
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 24
{
c++;
PORTB = ~c;
printf("led %d\n", c);
// Must delay > ~8ms to guarantee printf delivery
uint16_t delay = 0x3FFF;
while (delay--)
;
}
}
2.1.6.5 AVR MCU Sleep Monitor
The AVR MCU Sleep Monitor enables developers to monitor the Sleep mode state of the AVR MCU CPU
at run-time. Sleep mode is a binary representation, and does not indicate which low-power mode is active
(idle, power-down, etc.) The AVR MCU Sleep Monitor can be useful for determining the approximate
amount of time the CPU spends in Sleep mode. Enable the AVR MCU Sleep Monitor in the Code Profiling
Configuration dialog, then connect the AVR MCU Sleep Monitor source to a graph plot sink, and start a
debug session.
Important: The AVR MCU Sleep Monitor feature is only available on AVR devices featuring
the UPDI programming and debugging interface.
The AVR MCU Sleep Monitor feature is implemented using polling, which means that not ALL Sleep
transitions will be visible. The granularity of the resulting graph is a function of the UPDI clock speed and
the nature of the application code. It is recommended to set the UPDI clock to maximum when using the
AVR MCU Sleep Monitor.
The graph below shows an example of the Sleep Monitor in use. A value of ̔ 1ʼ indicates that the MCU is
in Sleep mode, and ̔0ʼ means it is running normally. From the plot, one can measure (using cursors) that
the MCU is entering and exiting Sleep mode with a period of about 2.2s, and stays ̔awakeʼ for about 275
ms on each wake-up cycle.
2.1.6.6 Data Polling and Control
The Data Polling and Control feature makes it possible to continuously sample and alter arbitrary memory
locations in the target device. For an example on how to use this feature, see Data Polling and Control
Example.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 25
Important: The Data Polling and Control feature is only available on SAM devices.
To add a memory location to be polled and/or controlled do the following.
To do:
• Click the Add Memory Location button for each memory location to be added
• Fill in the address and format of each location
There will be one source and one sink for each memory location. Connect the source to any visualization
module to monitor the value of the location and connect any data source to the sink to alter the value of
the memory location.
Important: Declaring variables you are interested in polling as volatile will ensure that they are
placed in SRAM and that their values will not be cached in registers by the compiler. Registers
cannot be polled, only SRAM locations.
Tip: Data polling operates on absolute SRAM locations. It is advised to use global variables for
this purpose so that they are always available at the same location in SRAM. Polling locations in
the stack can yield unpredictable results based on the stack context at the time of polling.
Data Polling Example
An example on how to use Program Counter sampling for power consumption analysis can be found in
Program Counter Polling. The same Mass Storage Class example used in this section is also suited as
an example on how to use the data polling and control of data variables features. A SAM L21 Xplained
Pro board is connected to a host computer both through Target USB and Debug USB connectors on the
kit. The ATSAML21 target device is running the USB Device MSC Example from ASF for SAM L21
Xplained Pro.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 26
For more information on the hardware setup and target application code used in this example, see Data
Polling Example Code.
Although this example makes use of the Graph and Dashboard modules the principles are the same for
using the Code Profiling interface with the other modules in the Data Visualizer.
First, a graph will be set up to monitor variables in the target application.
To do:
• Enable the Code Profiling interface by deselecting the check box for the Code Profiling
interface in the DGI Control Panel
To do:
• Open the Code Profiling Configuration window by pushing the Gear button
To do:
• Click the Add Memory Location button for each memory location to be added
• Fill in the address and format of each location
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 27
To do:
• Open the Configuration panel in Data Visualizer
• Add a graph by double-clicking the Graph module
A new Graph element will open with one y axis configured. However, there are two unrelated variables to
monitor, therefore, two axes are needed.
To do:
• Click the Add axis button to add an additional axis
There are now sources (variables) and sinks (axes), to be connected together.
To do: Drag each of the source plugs on the Code Profiling interface into the New plot
(sink) jack of each axis.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 28
To do: In Atmel Studio click Continue (F5) to resume execution.
Tip: A USB device in the HALT state no longer responds to Windows events, and may be
disconnected from the bus if held in this state for too long. To remedy this simply reset
execution in Atmel Studio.
Look at the output in the graph in Data Visualizer. Format the disk and watch how the write cycles counter
increments. Both values are plotted on independent axes, so they can be scaled accordingly. The output
should look something like this:
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 29
The following part of this example shows how to use a dashboard to interact with the target application.
For more information on the required code changes in the target application, see Application Interaction
using Dashboard Controls.
To do:
• Open Data Visualizer
• Connect
• Add the location of the frame_comparator in the Code Profiling Configuration window
A Data Visualizer dashboard can now be made with controls which manipulate the value of this variable.
To do:
• Open the configuration panel
• Add a new I/O Dashboard component by double-clicking the I/O Dashboard module
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 30
A slider control can now be added to the dashboard.
To do:
• Select the Edit checkbox
• Open the Elements tab
• Drag a Slider element onto the dashboard
A slider control needs to have some configuration parameters.
To do: Select the slider element and set its properties:
• Maximum = 500
• Minimum = 100
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 31
A segment display control can now be added to the dashboard.
To do:
• Select the Edit checkbox
• Open the Elements tab
• Drag a Segment Display element onto the dashboard
A segment display control needs to have some configuration parameters.
To do: Select the segment display element and set its properties:
• Segment Count = 3
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 32
The slider control can now be used as a source which can be connected to any relevant sink in Data
Visualizer. The segment display can similarly be used as a sink to connect any relevant source to.
The Code Profiling data polling interface provides both a source of data and a sink of data. The slider can
now be connected to the sink and the segment display to the source.
To do:
• Deselect the Edit checkbox
• Select the Show Endpoints checkbox
• Connect sources to sinks by dragging each source plug and drop it on a sink
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 33
Now that the connections have been made in Data Visualizer, the system can be put into a running state
and interaction with the variable can be made through the GUI.
To do:
• Deselect the Show Endpoints checkbox
• Start Data Visualizer
• Resume execution in Atmel Studio (F5)
The slider is now in control of the frame_comparator variable in the application code. Drag the slider, and
notice that the LED blink frequency changes. Any change in the slider position will be sent to the target
device through the debug interface, and a new value stored in the variable. At the same time, the value is
also read back from the target and displayed on the segment display.
2.1.7 Sink Data Conversion
Since DGI only can handle 8-bit values natively, all values received by DGI are remapped according to
the rules in the following table.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 34
Table 2-8. Data Conversion
Data Type Conversion
Int8 Cast to uint8. 2ʼs complement value is retained.
Uint8
Int16 2ʼs complement value is retained. Split into two uint8 values. Big endian.
Uint16 Split into two uint8 values. Big endian.
Int32 2ʼs complement value is retained. Split into four uint8 values. Big endian.
Uint32 Split into four uint8 values. Big endian.
Float Cast to Int32
Double Cast to Int32
XY8 X-value sent first, then Y-value
XYu8 X-value sent first, then Y-value
XY16 X-value sent first, then Y-value
XYu16 X-value sent first, then Y-value
XY32 X-value sent first, then Y-value
XYu32 X-value sent first, then Y-value
XYFloat X-value sent first, then Y-value
XYDouble X-value sent first, then Y-value
String The ASCII values of each character is sent. A null termination is added.
StringFloat Sent as a Int32 with the string following
Boolean False is sent as 0, true as 1
2.1.8 DGI Data Polling
The communication with the Data Gateway Interface (DGI) is done through a separate C++ DLL. When a
session is started, it will poll the DGI device for data each 2 ms. However, because the CPU could be
busy with other tasks, the polling might happen with a longer interval.
Since the DGI device has a limited buffer, the DLL needs to poll the device regularly to avoid an overflow.
Therefore, it is important to keep the CPU usage low during polling sessions. In case of overflow
problems, either decrease the transfer rate on the DGI interfaces or decrease the CPU load by shutting
down applications.
2.2 Serial Port
The Data Visualizer can be connected to a standard PC serial port. The Serial Port Control Panel is by
default opened and minimized under the DGI Control Panel when starting the Data Visualizer. To expand
it, click the down arrow in the right corner of the minimized panel.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 35
Tip: A new Serial Port Control Panel can be opened in External Connection in the Modules
section of the Configuration tab in the Data Visualizer.
Baud rate, Stop bits, and parity must be set to match the required settings for the communication partner.
A sink and a source endpoint is present to represent the outgoing and incoming data for the serial port.
The endpoints of the serial port control panel is of uint8 data type, and follows the same conversion rules
as the DGI control panel. The Open Terminal check box will cause a terminal module to automatically
open and connect the endpoints. When disconnecting from a serial port, the created terminal module will
be closed.
Figure 2-2. Serial Port Control Panel
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 36
Table 2-9. Configuration
Field name Values Usage
Baud rate 600-2000000 Baud rate of serial interface
Parity None, Even, Odd, Mark,
or Space
Parity type used for communication
Stop bits 1, 1.5, or 2 bits Number of Stop bits
DTR ON or OFF Data Terminal Ready control signal of RS-232 serial
communication
RTS ON or OFF Request To Send control signal of RS-232 serial
communication
Open Terminal ON or OFF Opens a terminal upon connection with the source and
sink connections automatically connected between the
Serial Port Control Panel serial port and the terminal
Autodetect
protocols
ON or OFF Auto-detection of the Atmel Data Protocol or Data
Stream protocol Auto-configuration. For more
information on the protocols, see Atmel Data Protocol
and Data Stream Protocol
Show Config
search path
ON or OFF Only available when Autodetect protocols is enabled.
Shows the search path for Data Stream Autoconfiguration
files
The Data Visualizer supports two different protocols for Auto-configuration; the Atmel Data Protocol
(ADP) and the Data Stream protocol. When using ADP, the configuration resides in the target application
code and the target application sends the configuration settings, upon request, from the Data Visualizer.
When using the Data Stream protocol, the configuration resides in files stored on the host computer and
the target application just sends an ID to identify which configuration files to be loaded by the Data
Visualizer. For more information on ADP, see Atmel Data Protocol. For more information on the Data
Stream protocol, see Data Stream Protocol.
To enable Auto-configuration the Autodetect protocols option must be enabled.
After pushing Connect the Data Visualizer will enable all interfaces while it looks for the ADP handshake
message or a Data Stream Configuration packet. If an ADP handshake message is received, the Data
Visualizer will request configuration information from the target application. If a Data Stream Configuration
packet is found, the Data Visualizer searches through the folders in the Auto-Configuration search path
looking for configuration files with names matching the detected ID.
Important: To make sure the Data Visualizer detects the Data Stream Configuration packet, it
must be sent by the target at least twice per second.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 37
Important: Asynchronous serial protocols (e.g., UART protocols used by DGI USART and
CDC Virtual COM port interfaces) use the following baud rates for auto-detection:
Table 2-10. Baud Rates Used on Asynchronous Interfaces for Auto-Detection of
Protocols
Baud Rate
9600
19200
38400
57600
115200
230400
500000
1000000
2000000
Using any baud rates not in the table will not work for auto-detection of protocols over
asynchronous interfaces (DGI UART and Serial port/CDC Virtual COM port).
Tip: To see the current search path used by Data Visualizer to look for configuration files,
check the Show Config search path option.
The search path is a semicolon separated list of paths. When Data Visualizer detects an AutoConfiguration
ID, it will search through the paths in the list looking for configuration files with the
correct file names.
If the Data Visualizer cannot find any valid configuration files it will show a browser dialog window asking
for the path to the folder where the correct configuration files reside.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 38
After selecting a folder, the folder will be APPENDED to the Auto-Configuration search path.
Tip: To reset the search path and select a new single folder as the search path, click the link
on the Autodetect protocols option text.
Data Visualizer will then pop up a browser dialog asking for the path to the folder where the
configuration files reside. The original search path will be CLEARED and the newly selected
folder will be set as search path.
Important: All three configuration files must reside in the same folder.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 39
3. Visualization
Incoming data can be visualized using the modules contained under this section.
The Terminal displays data as text, either as raw values or ASCII encoded characters. It is also capable
of sending text-based data.
The Graph module visualizes incoming data over time as plots, bands, and string flags. Cursor helps
analyze the data, and can provide output values for setting thresholds.
The Oscilloscope module is helpful for analyzing time-repeating patterns in a data stream.
The Power Analysis module is made specifically for analyzing power consumption over time. It can also
be used with code profiling to visualize Program Counter samples to get an overview of the program
execution versus power consumption.
The Custom Dashboard module is a customizable canvas to create user interfaces matching the
application. It features the most common user inputs such as buttons, sliders, and check-boxes, in
addition to graphing, etc.
3.1 Terminal
The Terminal module is a raw terminal for displaying and sending simple text or numeric values.
3.1.1 Terminal Module
The Terminal module is used to display and send simple text or numeric values. For an example on how
to configure a terminal, see Terminal Configuration Example.
Figure 3-1. Terminal
1
2
3
4
5 6 7 8 9
1. Input text box. 2. Output text box. 3. Output source. 4. Input sink. 5. Clear button.
6. Automatic line feed checkbox. 7. Hexadecimal mode checkbox. 8. Display timestamp
checkbox. 9. Autoscroll checkbox.
3.1.1.1 Connecting the Terminal and Displaying Data
Data streams are connected to the terminal through the sink and source endpoints. Drop an external
source onto the terminal sink, or drag and drop the terminal source onto an external sink. Data coming
into the terminal's sink endpoint will be presented in the input text box.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 40
3.1.1.2 Sending Data
When the source of the terminal has been connected to a sink endpoint, data can be sent by typing data
in the input text box and pressing enter. Whatever was typed in the text box will be cleared after
transmission. The text box supports the use of break characters (e.g. \x55, which will result in the raw
value 0x55 being transmitted).
3.1.1.3 Setting Hexadecimal Mode
Data is normally assumed to be an ASCII encoded stream of data. To display the hexadecimal value of
the data, select the Hexadecimal mode checkbox.
3.1.1.4 Resizing the Input Text Box
The input text box is re-sizable by clicking and dragging the lower part of the box.
3.1.2 Terminal Configuration Example
The following example shows how to connect the SPI interface to a terminal. However, the procedure is
the same for any of the other available data sources. The target code used in this example can be found
in Terminal Example Code.
To do: Select correct tool in the DGI Control Panel.
To do: Click Connect to make a connection to the DGI on the selected tool.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 41
To do:
• Click the SPI checkbox
• Open the SPI Configuration dialog by clicking the Gear button next to the SPI checkbox
To do:
• Set Transfer Mode to SCK normally low, Read data on rising edge
• Enable the Force start-up synchronization on CS option
To do:
• Open the configuration panel
• Add a Terminal view to the Visualizer
• Drag the source connector from the interface in the DGI Control Panel into the sink for
the Terminal to make a connection
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 42
To do:
• Start the session
• Press the button (SW0) on the Xplained Pro board
On each button press, LED0 on the board should toggle and a message appear on the terminal.
Sometimes more than one message appears for each button press. This is an indication that some
debouncing algorithm is needed in the button sample routine. It is a lot easier to spot this problem by
looking at the terminal output than to watch the LED toggling.
3.2 Graph
The Graph module is a versatile graph plotting tool.
3.2.1 Graph Module
The Graph module is a versatile graph plotting tool. The large plot area has one time axis, and one or
more value axes (Y axes). The value axes are stacked on top of each other. For an example on how to
configure a graph, see Graph Configuration Example.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 43
Figure 3-2. Graph with a Plot, Band, String Marker, and Cursor
1
2
3
4
5
6
7
9
8
1. Plot area. 2. String marker. 3. Horizontal cursor. 4. Plot. 5. Band. 6. Time axis. 7. Y axis.
8. Plot cursors. 9. Configuration panel.
There are four types of elements that can be added to an Y axis:
• Plot
• Band
• String marker
• Horizontal cursor
Each of these elements are described in the following sections.
3.2.1.1 Graph Configuration Panel
Through its Configuration panel, the Graph module is connected to the rest of the system. Here you can
add more axes, plots, and other graph elements. Here you will also connect the graph elements by
connecting sources and sinks.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 44
Figure 3-3. Graph Controls
1 2 3
1. Add axis button. 2. Auto-scroll checkbox. 3. Automatically fit Y checkbox.
Add Axes
Figure 3-4. Graph with Two Y Axes
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 45
Press the Add axis button to add an Y axis to the graph. It will show up in the plot area, and its controls
will be added to the bottom of the Configuration panel.
Delete Axes
1. If the configuration section for the axis you want to delete is hidden, first expand it by clicking the
arrow icon.
2. Delete the axis by pressing its Delete Axis button.
Enabling and Disabling Auto-scrolling
Auto-scrolling locks the plot area to include the latest arriving samples. If auto-scrolling is disabled,
manually scroll the plot by dragging the time axis with the mouse or with the scroll wheel.
Auto-scrolling is enabled by selecting the Auto-scroll check box.
Auto-sizing the Y Axis
When the Automatically Fit Y check box is checked, the Y axis will automatically zoom in or out in order
to fit the whole sample range of the plots in that axis.
3.2.1.2 Plot
A plot is a curve describing a changing value. The curve is drawn between the data samples it receives
from the data source. The samples can arrive sporadically, or at a fixed interval. If the data source is
known to be sampling at a fixed rate the plot can be set to this sample rate. This way, the curve will be
shown correctly even if there are some elasticity in the transmission of the samples. If the samples come
at an irregular rate, set the sample rate to 0. This will make the graph position the samples along the time
axis according to the sampleʼs timestamp. If there is more than one plot in the graph, each plot will
update when new data arrives for that plot.
When adding a plot to an axis, the new plotʼs Plot control panel will be placed under that axis in the
Graph configuration panel.
Figure 3-5. Plot Controls
1 2 3 5 6 8 9
10
11
4 7
1. Plot label. 2. Enable check box. 3. Line color indicator. 4. Plot type selection 5. Data sink.
6. Sample rate edit box. 7. Sample rate set button. 8. Delete plot button.1 9. Plot status.
10. Show Cursors option. 11. Cursor data.
Adding and Connecting a Plot
To connect a plot to a data source, drag the data source plug symbol and drop it on the New plot sink
connector symbol.
Disable a Plot
To stop showing a plot in the graphʼs plot area, deselect the plotʼs Enable check box.
Change the Plot Color
The plot line's color can be changed:
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 46
1. Click on the plot's line color indicator.
2. In the dialog box that opens, adjust the color by dragging the Red, Green, and Blue sliders. Press
OK.
3. The plot line and the line color indicator has now changed to the new color.
Change Plot Type
The plot type can be changed between Plot and Points by changing the selected type in the Plot type
selection. The Plot type will show the graph plot as a continuous line while the Points type will show the
actual plot samples as dots only.
Plot Data at a Fixed Sample Rate
If the data source sends data to the plot at a fixed rate, the plotʼs sample rate can be set. Enter the
number in the Sample rate text box and press the Set button.
Plot Timestamped Data
If the data arrives at irregular intervals, the graph will present a more accurate view if the samples are
placed using the sampleʼs timestamp.
To plot using timestamps, enter 0 into the Sample rate text box and press the Set button.
Remove a Plot
To remove a plot from an axis, press the Delete button in the plot's control panel.
Cursors
If the Show Cursors option is enabled, two vertical cursors will show up in the plot area. The cursors can
be moved by the mouse and the Plot Controls panel shows data related to the cursors.
3.2.1.3 Band
A band is a vertical marking in the plot area that highlights the plot background with the band color. For
example, on the plot of a temperature reading, a band can be added that highlights portions of the plot
where the temperature is above a certain value.
Figure 3-6. Graph Module Showing a Plot and a Band
A band has a minimum and a maximum limit. The band will be active, on, if the input to the band is
between these two values.
Figure 3-7. Band Controls
Adding and Connecting the Band
To add a new band and connect it to a data source, drag the data source plug and drop it on the New
band sink connector.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 47
Setting the Band Color
Click the band color indicator. A dialog box will open. Change the RGB values, and press OK.
Note:
When changing the band color, the change will not affect band regions already in the graph. Only new
band regions will have the new color.
Setting Inverted Band Limits
Figure 3-8. Band with Inverted Behavior
Min limit
Max limit
If the maximum limit is set to a value less than the minimum value, the band will behave in an inverted
manner. Now, the band will be active when the input value is less than the maximum limit, or if the input
value is greater than the minimum limit.
• Enter the minimum and maximum values, and make sure the maximum value is less than the
minimum value. Press the Set button.
Setting the Band Color
Click the band color indicator. A dialog box will open. Change the RGB values, and press OK.
Note:
When changing the band color, the change will not affect band regions already in the graph. Only new
band regions will have the new color.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 48
Remove a Band
To remove a band, press the Delete button in the band's control panel.
3.2.1.4 String Markers
When the source sends a string, the string marker will attach these short messages to the graph. These
markers will be placed according to the timestamp of the sample.
Figure 3-9. Graph with Plot and Two String Markers
Adding and Connecting a String Marker
To add and connect a string marker to a data source, drag the data source plug and drop it on the New
string sink connector.
Setting the String Marker Color
Click on the string color indicator in the String control panel. Change the RGB values, and press OK.
Note:
When changing the string marker color, the change will not affect string markers already in the graph.
Only new string markers will have the new color.
Expanding and Collapsing String Markers
When large strings are sent to a string marker, the marker will collapse into a small box to reduce the
space it occupies in the plot area.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 49
Figure 3-10. Expanded and Collapsed String Marker
To see the text, it must be expanded.
• Expand and collapse a string marker by double-clicking the marker
Remove a String Marker
To remove a string marker, press the Delete button in the string's control panel.
3.2.1.5 Horizontal Cursor
The Horizontal cursor is a horizontal line in the graph that, when dragged up or down, outputs a value
that can be used as a source.
Tip: Use the Horizontal cursor to control an application's setpoint or threshold.
Figure 3-11. Graph Plot and Cursor
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 50
Connecting the Cursor
To connect a cursor to a data sink, drag the cursor's data source plug and drop it on the target's data
sink connector.
Changing the Cursor Value
To change the cursor value, position the mouse over the cursor line. The mouse cursor will change into a
handle. Click and drag the cursor to its new position.
Alternatively, the cursor value can be changed by typing in a new value in the Value field in the Horizontal
Cursor configuration. Note that the change won't take effect until the text box is deactivated by clicking
with the mouse outside the text box.
Changing the Cursor Label
To change the label of the cursor type in a new label in the Label field in the Horizontal Cursor
Configuration. Note that the change won't take effect until the text box is deactivated by clicking with the
mouse outside the text box.
Setting the Cursor Color
Click the Cursor color indicator in the Cursor control panel. A dialog box will open. Change the RGB
values, and press OK.
Remove a Cursor
To remove a cursor, press the Delete button in the cursor control panel.
3.2.1.6 Zooming and Panning
When the Auto-scroll and Automatically fit Y check boxes are checked, the last samples will be shown
and the Y axis will be zoomed such that all values will be visible.
For manually zooming in or out or inspecting a region in more detail, disable these options and zoom and
pan using the mouse.
Zooming the X Axis
The X axis can be zoomed in two different ways:
• Using the mouse scroll wheel
1.1. Click somewhere inside the plot area.
1.2. Press and hold the SHIFT key on the keyboard.
1.3. Scroll the mouse wheel in either direction.
The X axis will zoom in or out (depending on which way you turned the mouse wheel), centered
around the mouse cursor.
• Dragging the X axis resize markers
2.1. Position the mouse cursor over one of the X axis' resize markers. The mouse cursor will
change into horizontal resizing arrows.
2.2. Click and drag horizontally.
Zooming the Y Axis
The Y axis can be zoomed in two different ways:
• Using the mouse scroll wheel
1.1. Click somewhere inside the plot area.
1.2. Press and hold the CTRL key on the keyboard.
1.3. Scroll the mouse wheel in either direction.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 51
The Y axis will zoom in or out (depending on which way the mouse wheel is turned), centered
around the mouse cursor.
• Dragging the X axis resize markers
2.1. Position the mouse cursor over one of the X axis' resize markers. The mouse cursor will
change into vertical resizing arrows.
2.2. Click and drag vertically.
Panning
Panning around the graph can be done in two ways:
• Dragging the plot area
1.1. Position the mouse cursor inside the plot area.
1.2. Click and hold the left mouse button.
1.3. Drag the mouse.
• Dragging the axes
2.1. Position the mouse cursor over one of the axes. The cursor will change into a pointing
hand.
2.2. Click and drag the axis.
3.2.2 Graph Configuration Example
This chapter gives an example on how to configure the Graph module to be used with a target
application implementing a Night mode switch with a light sensor. Although this example utilizes only
some of the data sources available in the Data Visualizer, the procedure will be the same for all data
sources. The target code used in this example and a description of the hardware setup can be found in
the Graph Example Code chapter. The first part of the configuration example uses the code found in the
first subsection of the Graph Example Code chapter (Basic Graph). When changes to the target
application code are required as the example progress a link to the corresponding code listing will be
provided.
To do: Select correct tool in the DGI Control Panel.
To do: Click Connect to make a connection to the DGI on the selected tool.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 52
To do:
• Click the SPI checkbox
• Open the SPI Configuration dialog by clicking the Gear button next to the SPI checkbox
To do:
• Open the configuration panel
• Add a Graph module to the Data Visualizer
• Drag the source connector from the interface in the DGI Control Panel into the sink
marked New plot to make a connection to a new plot
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 53
To do:
• Push Start in DGI Control Panel
The data will be plotted in the Graph module. It could look something like the picture below when
hovering a hand above the light sensor.
The light sensor data can be used to switch between Day and Night mode. For the Night mode switch to
be useful, the threshold when switching between the modes are important. The Graph module contains a
useful feature called Band to mark when the plot data is within a certain range. This can be used to
simplify the selection of the mode switch threshold.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 54
To do:
• Drag the interface source to the New band sink
To see that the Night mode switch is actually working and switching at the right threshold, the string
marker feature of the Graph module is useful. In this example, the CDC USART interface of the target
board is used to send a string each time the mode is switched. These messages can then be shown in
the graph as string markers. The target application source code for this part of the configuration example
can be found in Adding String Markers.
To do:
• Open the Serial Port Control panel found under External Connection in the Modules
section of the Configuration tab in Data Visualizer
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 55
To do:
• Select the correct COM port corresponding to the connected kit
• Set the serial port parameters according to the application code
• Make sure the Open Terminal option is not checked
To do:
• Drag the serial port source to the New string sink
• Click Connect in the Serial Port Control Panel
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 56
String markers will appear as vertical lines with a square on top. By double-clicking the square the string
text will be shown. Note that there will naturally be some delay from the ADC data values crosses the
threshold until the string message reaches the host computer. In addition, the timestamping of the data is
added on the host computer and the two serial interfaces are not synchronized. This results in a
misalignment of the string markers compared to the ADC values. DGI includes timestamping functionality
on the EDBG on the Xplained Pro and this can be enabled in the DGI Control Panel at a performance
cost, but CDC includes no time stamping functionality.
Tip: In this example, a separate serial interface was used for the string marker data. If the
number of serial interfaces available are constrained, the same interface could be used to
stream both the ADC data and the string marker data by using the Atmel Data Protocol (ADP).
For more information, see the Atmel Data Protocol.
So far, the Graph module of the Data Visualizer has been used to show the data generated by the light
sensor and to show when the Night mode switch toggles between the two modes. The Graph module
can also be used to interact with the target application while it is running. In this example, the Night mode
threshold can be adjusted dynamically by using a horizontal cursor.
The target application source code for this part of the configuration example can be found in Using
Horizontal Cursor Code.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 57
To do:
• First, remove the band from the graph as it is of no use when the Night mode threshold is
dynamic
• Click Add Horiz. Cursor to add a horizontal cursor to the graph
• Drag the Horizontal Cursor source to the sink in the Serial Port Control Panel
To move the horizontal cursor either drag it or change the value by typing a new value in the Value field in
the configuration. Note that the value will not be updated until the Value text box is not in focus, i.e. click
somewhere else in the GUI after typing in a value. Every time the cursor is moved the Data Visualizer
sends a new float value to the serial port the cursor is connected to.
Tip: Turn off Auto-scroll and Automatically fit Y to more closely examine a plot while it is still
running.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 58
3.3 Oscilloscope
The Oscilloscope module visualizes data values in real time. The oscilloscope features a trigger submodule
to capture repeating signals or rare events. The oscilloscope also has a cursor system to
measure various properties of the data streams.
3.3.1 Oscilloscope Module
The Oscilloscope module visualizes data values in real time. It has four channels for monitoring four
different data streams at the same time. Each channel's data stream is visualized as a graph in the plot
area, each with a different color. The vertical position and amplitude of each channel can be modified. For
repeating signals, or for capturing rare events, the oscilloscope has a trigger sub-module. The
oscilloscope also has a cursor system to measure various properties of the data streams.
For an example on how to configure an oscilloscope, see Oscilloscope Configuration Example.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 59
Figure 3-12. The Oscilloscope Module
1
2
3
4
5
6
7
8
9
1. Plot area. 2. Zero-line. 3. Plot. 4. Trigger level indicator line. 5. Time axis scale handle.
6. Time axis. 7. Plot area resize handle. 8. Control panel. 9. Show/hide control area arrow.
3.3.1.1 Oscilloscope Control Panel
The Oscilloscope control panel is where the oscilloscope is configured and connected to the rest of the
system. The control panel has five sections, which are described in detail in the following sections.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 60
Figure 3-13. Oscilloscope Control Panel
Vertical Controls
The vertical control section has four sub-sections, one for each of the four oscilloscope channels. The
channel controls are disabled until a source is connected to the channel sink.
Connecting the Oscilloscope
Signals or data streams are connected to the oscilloscope through the channel sink endpoints. Drop an
external source onto the sink. When connected, the rest of the channel controls will be enabled.
Adjusting the Channel Amplitude
When a channel is displayed in the plot area, the signal's height is determined by the channel amplitude
setting.
The amplitude can be adjusted in three different ways:
• Enter an amplitude value into the text box. Deselect the text box to let the new value take effect.
• Click on the up/down arrows located to the right of the text box
• With the mouse cursor positioned over the text box, scroll the mouse wheel to increase/decrease
the amplitude setting
Show and Hide a Channel
When a channel is in use, the plot can be hidden from the plot area by clearing the Amplitude check box.
Click it to show the plot again.
Adjusting the Channel Offset
The channelʼs vertical position in the plot area can be adjusted with the Offset setting. The offset value is
the channelʼs zero-pointʼs distance above the bottom of the plot area.
There are four ways to adjust the offset:
• Enter an offset value into the text box. Deselect the text box to let the new value take effect.
• Click on the up/down arrows located to the right of the text box
• With the mouse cursor positioned over the text box, scroll the mouse wheel to increase/decrease
the offset setting
• If the channelʼs zero line is enabled in the plot area, drag it to a new position
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 61
Show and Hide the Zero Line
A zero line is, by default, shown when a channel is enabled by connecting it to a source. The zero line is
a horizontal line shown in the plot with the same color as the channelʼs color. It also has a 0 label on the
left end.
The zero line can be shown/hidden by clicking/clearing the Offset check box.
Customize the Channel Name
When the oscilloscope module is added to the workspace, the four channels are labeled Channel 1 to
Channel 4. The label can be changed, as a reminder of what signal is connected to that channel.
• Click inside the label and type in the new name
Run Control
The Run/Stop and Single buttons are the run control. These buttons control if the plots are updated or
not.
There are three operating modes:
• Stop (the Run/Stop button is red)
• Single (the Single button is yellow)
• Run (the Run/Stop button is green)
Enter Run Mode
When the stop or single operating mode is active (red or yellow light), enter the run mode by clicking the
Run/Stop button. The button will turn green, and the plots will continuously update according to trigger
settings.
Enter Single Mode
When the stop or run operating mode is active (red or green light), enter the single mode by clicking the
Single button. The button will turn yellow, and the plots will trigger and update only once.
Enter Stop Mode
When the single or run operating mode is active (yellow or green light), enter the stop mode by clicking
the Run/Stop button. The button will turn red, and the plots will freeze.
Trigger Controls
The Oscilloscope trigger sub-module helps to identify and lock on to only the portion of the input signal
desired. Depending on the operating mode set by the run controls, the trigger can:
• Lock on to a periodic signal and constantly update the plot
• Only update the plot when the signal exceeds some level
Edge Triggering
The edge triggering mechanism is looking for the signal to cross the trigger level. For a positive edge
trigger, the signal must go from below the trigger level, to above the trigger level.
Figure 3-14. Positive Edge Trigger
Trigger level
1 2 3
1. No trigger – the line must cross. 2. No trigger – wrong direction. 3. Trigger point.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 62
Figure 3-15. Negative Edge Trigger
Trigger level
1 2 3
1. No trigger – the line must cross. 2. No trigger – wrong direction. 3. Trigger point.
Set the Edge Trigger Type
The trigger mechanism has two edge trigger modes: Positive and Negative Edge Trigger.
•
To set the Positive Edge Trigger mode, click the button. The button will be highlighted when
activated.
•
To set the Negative Edge Trigger mode, click the button. The button will be highlighted when
activated.
Set the Trigger Level
The trigger level can be adjusted in three different ways:
• Enter a trigger level value into the text box. Press the TAB keyboard button or click the mouse
outside the text box to let the new value take effect.
• Click on the up/down arrows located to the right of the text box
• With the mouse cursor positioned over the text box, scroll the mouse wheel to increase/decrease
the trigger level setting
• Drag the trigger level line in the plot area to a new position
Select the Trigger Source
The Oscilloscope trigger sub-module uses one of the channel signals when looking for the trigger
condition.
• Click the colored Trigger source button corresponding to the channel chosen for use as a trigger
source. The active Trigger source button will be highlighted.
Set the Trigger Mode
The Oscilloscope module supports both Triggered and Free Running mode.
• Click Normal to enable Triggered mode. The plot will only be updated when the trigger condition is
satisfied.
• Click Auto to enable Free Running mode. The plot will be updated continuously and the trigger
conditions will be ignored.
Horizontal Control
The oscilloscope draws the plot lines at a constant speed. The X axis is the time axis. The axis labels
show time relative to the trigger point. For the labels to display correctly, the oscilloscope needs to know
the sample rate of the source.
Set the Sample Rate
In the sample rate text box, enter the source's sample rate.
Note:
All sources connected to the oscilloscope must have the same sample rate. If not, the plot lines will not
be synchronous with the time axis.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 63
Set the Horizontal Resolution
The horizontal resolution determines the time axis range, or what time-span is visible in the plot. It can be
adjusted in four different ways:
• Position the mouse cursor inside the plot area. Use the mouse wheel to zoom in or out.
• Enter a resolution value into the text box. Deselect the text box to let the new value take effect.
• Click on the up/down arrows located to the right of the text box
• With the mouse cursor positioned over the text box, scroll the mouse wheel to increase/decrease
the resolution setting
• Drag the time axis scale handles to change the resolution
Set the Horizontal Offset
The horizontal offset is the trigger point's position relative to the center of the plot area. Typically, the
offset is changed in order to inspect the plot on either side of the trigger point. There are five different
ways of changing the offset:
• Position the mouse cursor inside the plot area. Make sure it does not touch any of the trigger line,
zero line, or cursor lines. Then, click and drag the mouse horizontally to change the offset.
• Position the mouse cursor on the time axis. Then click and drag the mouse horizontally to change
the offset.
• Enter an offset value into the text box. Deselect the text box to let the new value take effect.
• Click on the up/down arrows located to the right of the text box
• With the mouse cursor positioned over the text box, scroll the mouse wheel to increase/decrease
the offset setting
3.3.1.2 Cursors
The oscilloscope has two cursors that can be used to inspect the plots. The cursors simplify
measurements such as pulse widths, amplitudes, frequencies, and so on.
Each cursor is displayed in the plot area as two lines, one vertical and one horizontal. When the vertical
cursor line is moved, the horizontal line will follow so that the plot line, vertical and horizontal cursor lines
intersect in the same point.
You can set which channel is the source for each of the cursors.
At the bottom of the plot area is the data line. It displays the X and Y values for each of the cursors. In
addition, ΔX, ΔY, and 1/ΔX is calculated and displayed.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 64
Figure 3-16. Oscilloscope Cursors
Show and Hide the Cursors
In the Cursor area in the Oscilloscope control panel, toggle the Show button to show or hide the
cursors and the cursor data line in the plot area.
Select Cursor Source Channel
In the Cursor group in the oscilloscopeʼs control panel, click on the Cursor 1 and Cursor 2 drop-down
list boxes to select the channel to use as the source for that channel. Pick the color matching the channel
chosen for use.
The cursorʼs X and Y labels in the data line will change color to match the color of the channel selected.
Move a Cursor
Only the vertical line (the X value) of a cursor can be moved. The horizontal line (the Y value) will follow.
• Position the cursor over the vertical cursor line. The mouse cursor will change into a left/right
cursor. Click and drag the cursor to its new position.
After repositioning a cursor, the readouts in the data line are updated.
Bring a Cursor Into View
After some zooming and panning, a cursor can end up far outside the visible region. It is easy to bring it
back into view:
• Right-click on the X1 or Y1 labels in the data line. From the pop-up menu, select Bring into view.
3.3.2 Oscilloscope Configuration Example
This chapter gives an example on how to configure the Oscilloscope module to be used with a target
application implementing a Night mode switch with a light sensor. Although this example only utilizes the
SPI interface as data source, the procedure will be the same for all data sources. The target code used in
this example and a description of the hardware setup can be found in Oscilloscope Example Code.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 65
To do: Select correct tool in the DGI Control Panel.
To do: Click Connect to make a connection to the DGI on the selected tool.
To do:
• Click the SPI checkbox
• Open the SPI Configuration dialog by clicking the Gear button next to the SPI checkbox
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 66
To do:
• Open the configuration panel
• Add an Oscilloscope module to the Data Visualizer
• Drag the source connector from the interface in the DGI Control Panel into the sink for
the oscilloscope channel to make a connection
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 67
The Oscilloscope module can now be used to analyze the data acquired from the light sensor when
toggling a desk lamp ON and OFF above the I/O1 Xplained Pro.
To do:
• Set sample rate to 100 kHz
• Enable Trigger on falling Edge and set Mode to Normal
• Push Start in the DGI Control Panel
• Push the Run-Stop button in the Oscilloscope module
After some adjustments of the trigger level by dragging it with the mouse in the oscilloscope plot area,
and zooming in on the plot by adjusting the Horizontal and Vertical range, a lamp switch on event could
look something like the picture below.
By turning on the Cursors it is possible to measure the time it takes for the lamp to settle in the ON state.
In this case, it took about 300 ms (ΔX in the plot area). Zooming further in on the plot makes it possible to
use the cursors to measure the frequency of the light flickering. The 1/ΔX field in the plot area shows that
the frequency is about 100 Hz, which matches well with the 50 Hz AC power of the lamp (the power
switches polarity 100 times per second).
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 68
3.4 Power Debugging
The Power Debugging module displays current and voltage measurements (commonly referred to as
power measurements) generated by the Power interface in the DGI Control Panel. The power
measurements can be combined with various other interfaces like GPIO and Code Profiling in the same
graph to correlate code execution on the target MCU and power consumption of the target application.
3.4.1 Power Debugging Module
The Power Debugging module displays the current consumption of a connected kit. To get started with
basic current measurements, see the Basic Current Measurement chapter. For an example on how to
use cursors, see Power Analysis using Cursors. For examples on how to correlate current consumption
with code execution, see Code Correlation.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 69
Figure 3-17. Power Debugging
1. Current consumption graph. 2. Y-axis of channel A. 3. Channel A average and instant values. 4. Yaxis
of channel B. 5. Control Panel. 6. Auto-scroll checkbox. 7. Automatically fit Y checkbox.
8. X-axis (time), unit is [minutes]:[seconds].
Important: The Power module can only be used with the Power interface.
3.4.1.1 Scaling and Scrolling a Graph
Tip: Turn off Auto-scroll and Automatically fit Y to more closely examine a plot while it is still
running.
Use the scale and offset controls in order to move the plots as needed. The mouse scroll-wheel is useful
in this regard:
• Shift-scroll on the plot to zoom on the time (X) axis
• Ctrl-scroll on the plot to zoom on the Y axis
• Drag the graph to pan on the time (X) axis and move (offset) the Y axis
• Drag the scales on the left and right to move respective channels in the Y axis (offset)
• Ctrl-scroll on the respective axis scale to zoom that channel
• Right-click and drag to select an area to zoom
3.4.1.2 Power Debugging Module Control Panel
The Power Debugging module Control Panel is placed in the upper right corner of the module.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 70
Notice: Not all configuration options in the control panel are available on all tools. For
example, only the Power Debugger has both an A channel and a B channel. All options will be
visible for all tools, but will have no effect unless the tool supports them.
The Auto-scroll option controls the scrolling in the X-axis direction (time axis). To zoom in on and
examine the graphs in detail, disable this option.
The Automatically fit Y option controls whether the Data Visualizer will automatically adjust the range of
the Y axis according to the graph content or not. If this option is enabled, any manual adjustments of the
Y axis will be overridden.
The Show zero option controls whether the zero-point of the Y axis should always be visible when
Automatically fit Y is enabled.
Channel Configuration
For each power measurement channel there is a Channel configuration section in the Control Panel of
the Power Analysis module.
The channel section allows the user to enable/disable the current and voltage graphs in the Power
Analysis module.
Notice: If the Enable B Channel option in the Power Configuration of the DGI Control
Panel (see Power Interface) is not selected, the B channel will not be available even though the
tool has a B channel. But the B channel configuration will still be visible in the Control Panel.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 71
The Range setting enables the measurement range data for the current measurement channel. To cover
the full range of current values supported by the current measurement channel, most tools have two or
more hardware configurations for each channel. The number of ranges for a channel varies with the
connected tool. The switching between the hardware configurations is done automatically based on the
instant current measured.
Notice: The range graph will only be visible if the Enable Range Source option in the Power
Configuration of the DGI Control Panel is selected.
The Mode option allows for different averaging algorithms to be used for the display of data if this is
enabled for the current tool.
Code Location
The Code Location section contains no options, just the source connection. To enable code locations in
the Power Analysis graph the Code Profiling interface in the DGI control panel must be enabled and
the Enable Code Location option in the Code Profiling Configuration of the DGI Control Panel must
be enabled.
GPIO
Each of the GPIO sources can be switched ON or OFF in the GPIO section of the Control Panel of the
Power Analysis module.
For GPIO data to be available for the Power Analysis module the GPIO interface has to be enabled in
the DGI Control Panel.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 72
Cursors
The Cursors section in the Power Analysis module Control Panel allows the user to enable two vertical
cursors in the graph by checking the Enabled box.
The cursors can be moved by using the mouse pointer to drag them along the X-axis or they can be
centered by pushing the Center button.
When the cursors are enabled the section of the graph between the cursors can be used for various
measurements. The measurements will be shown in the Cursors section below the graph.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 73
Which measurements to be shown can be selected in the Measurements sub-section of the Cursors
section in the Power Analysis module Control Panel.
3.4.2 Basic Current Measurement
To do: Select the correct tool in the DGI Control Panel.
To do: Connect to the DGI on the selected tool.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 74
To do: Enable the Power interface and modify its settings to monitor the relevant channels.
To do: Start the Data Visualizer session.
3.4.2.1 Two Channel Measurement
When using hardware with two measurement channels, the Data Visualizer will display both in the same
graph (unless disabled in the Power Configuration).
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 75
On the Control panel on the right of the module the user can show or hide the current and voltage plots
as well as range information when available.
By default, both channels will be shown in the Power Analysis graph but each plot can be moved up or
down to separate them as best suited.
3.4.2.2 Scaling and Scrolling a Graph
Tip: Turn off Auto-scroll and Automatically fit Y to more closely examine a plot while it is still
running.
Use the scale and offset controls in order to move the plots as needed. The mouse scroll-wheel is useful
in this regard:
• Shift-scroll on the plot to zoom on the time (X) axis
• Ctrl-scroll on the plot to zoom on the Y axis
• Drag the graph to pan on the time (X) axis and move (offset) the Y axis
• Drag the scales on the left and right to move respective channels in the Y axis (offset)
• Ctrl-scroll on the respective axis scale to zoom that channel
• Right-click and drag to select an area to zoom
3.4.2.3 Current Averaging
The Power Analysis module displays two averaged values per channel. One shows the instantaneous
current value, while the other shows the average of the samples visible in the graph view.
3.4.2.4 Power Measurement Calibration
To achieve full measurement accuracy on the current measurement hardware, it should be calibrated
before running the measurements. The calibration procedure is started through the Power Configuration
window in the Power interface in the DGI Control Panel.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 76
Figure 3-18. Triggering Power Measurement Calibration from the Power Configuration Window
To start the calibration procedure, select Trigger calibration and press OK. Then follow the instructions
to complete the calibration procedure for the tool.
3.4.3 Power Analysis using Cursors
In order to analyze the current more closely, the cursor feature of the Power Analysis module is useful.
To do:
• Open the Control Panel in the upper right corner of the Power Analysis module
• Expand the Cursors section
• Click the Enabled box to turn the cursors on
Remember: If the current measurements are still running, make sure to disable
Auto-scroll before enabling the cursors, or else the graph view will rapidly scroll away
from the cursors.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 77
The example above shows the current consumption of a target board with a LED that toggles ON and
OFF regularly.
The cursor data at the bottom of the module shows that the current consumption when the LED is OFF is
about 354 μA, while the current consumption when the LED is ON is about 6.5 mA. The average current
consumption during one period of the LED toggling is about 580 μA. As the current measurement channel
is also monitoring voltage, you can measure the power consumption directly. Enable this by setting the
corresponding options in the Measurements section of the Cursors section in the Control Panel of the
Power Analysis module.
3.4.4 Code Correlation
To optimize current consumption, current measurements must be correlated to the code execution of the
application. The Data Visualizer enables code correlation by the use of GPIO instrumentation or program
counter sample readout. Crucial to both these methods is the ability to show the code execution related
events with the same time base and in the same graph as the current consumption.
3.4.4.1 GPIO Instrumentation
By inserting simple GPIO toggling in the application code, the user can generate common reference
points between the measured current and the code execution. The Data Visualizer is capable of showing
the GPIO events in the same graph as the current measurements.
A mass storage application will be used to demonstrate the use of GPIO instrumentation.
Both Target USB and Debug USB connectors of a SAM L21 Xplained Pro board is connected to a host
computer. The ATSAML21 target device is running the USB Device MSC Example from ASF for SAM L21
Xplained Pro (in Atmel Studio select File→New→Example Project and search for “MSC”). The Current
Measurement jumpers on the kit are set to measure MCU current and bypass I/O current.
The current graph after running a format of the mass storage device:
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 78
A disk format operation consists of both read and write operations, but with just the current it is difficult to
tell what is going on when. To be able to separate the read and write operations, the application code is
modified to set GPIO0 (PB01 on the ATSAML21) high on the start of a read operation and set it low at the
end of the read operation. GPIO1 (PA16 on the ATSAML21) is similarly toggled for write operations. Both
the GPIO interface and the Power interface must be enabled in the DGI Control Panel of the Data
Visualizer as shown below.
In the Control Panel of the Power Analysis module disable GPIO2 and GPIO3 as shown below.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 79
With the GPIO signals enabled, the user can distinguish the current consumption of the read and write
operations. The yellow signal is GPIO0 which signals the read operations and the green signal is GPIO1
showing the write operations.
3.4.4.2 Program Counter Polling
Each time the Program Counter (PC) is read out from the target, we get the exact information on the
address of the code location currently being executed. The Data Visualizer can show PC values with
current measurements in the same graph. This allows the user to see what is being executed by the
target CPU at the various sample points of the current consumption graph. The sampled PC values will
only show part of the code execution, as in most cases it is impossible to read out the PC values as fast
as the target is executing instructions. The sampled values are still useful to indicate which code segment
is being executed at any point in time.
A SAM L21 Xplained Pro board running a Mass Storage Class example will be used to demonstrate PC
polling.
Both Target USB and Debug USB connectors of a SAM L21 Xplained Pro board is connected to a host
computer. The ATSAML21 target device is running the USB Device MSC Example from ASF for SAM L21
Xplained Pro (in Atmel Studio select File→New→Example Project and search for “MSC”). The Current
Measurement jumpers on the kit are set to measure MCU current and bypass I/O current.
The current graph after running a format of the mass storage device:
A disk format operation consists of both read and write operations, but from the current graph it is difficult
to see what is going on when. To get more information on what is going on in the target at the various
points in the current graph, the Program Counter sampling feature will be useful.
To view Program Counter samples together with current measurement data both the Power interface and
the Code Profiling interface must be enabled.
To do:
• Enable both Power interface and Code Profiling interface in DGI Control Panel
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 80
To do:
• Open the Code Profiling Configuration dialog by clicking the Gear button on the Code
Profiling interface
• Select Enable Code Location
A typical current graph with Program Counter sampling enabled during a format operation is shown
below.
The yellow points plotted on the graph represent polled Program Counter values. Their location on the y
axis is a visual representation of their location in the code-space of the target device. The relative
grouping of samples shows the execution of different functions. Patterns can easily be seen using this
technique. Hovering over one of the samples shows the location of that sample in the Code location
details box below the graph, as well as the value of the current sample at that point.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 81
Double-clicking on one of the samples will open the editor and highlight the corresponding line of code.
The highlighted sample is located in a function called udi_msc_trans_block. This function transfers data
from RAM to USB. From the graph it can be seen that the current spike at the marker is generated by the
execution of this function as all Program Counter samples are from the same location during this spike.
3.5 Custom Dashboard
The Dashboard module is a customizable Graphical User Interface (GUI) panel. It can be used to control
and display parameters from the target application.
3.5.1 Dashboard Module
The Dashboard module is a customizable Graphical User Interface (GUI) panel. It can be used to control
and display parameters from the application firmware. Elements (button, label, slider, etc.) are placed in
the dashboard area to form the GUI. Each element can have an endpoint associated with it to send or
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 82
receive values. A slider, for example, has a source that outputs the slider position as a numeric value.
Endpoints are shown when the Show Endpoints option is selected.
For an example on how to configure a dashboard, see Dashboard Configuration Example.
Figure 3-19. Dashboard
1. Dashboard area. 2. Edit checkbox. 3. Show Endpoints checkbox. 4. Height adjustment tab.
3.5.1.1 Edit Panel
When going into Edit mode (by selecting the Edit box), the Edit panel will become visible. Here the user
can customize the dashboard.
Figure 3-20. Edit Panel
Placing Elements on the Dashboard
By default, the dashboard area is empty. Elements can be placed on the dashboard by following the
procedure below.
• Click the Edit checkbox
• Open the Elements panel in the upper right corner of the dashboard area
• Click and hold the element
• Drag the mouse over the dashboard area
• Drop the element in the dashboard area on the desired location
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 83
Configuring Dashboard Elements
All dashboard elements can be configured when in Edit mode. The parameters will vary depending on
element type, but the procedure for changing them is the same.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 84
Figure 3-21. Element Configuration
1. Common parameters. 2. Element-specific parameters. 3. Set button.
• Click the Edit checkbox
• Select the element to configure by clicking it. The Configuration window will list the configurable
parameters for the selected element.
• Change the parameters to the desired value
• Click the Set button
Moving Elements
All parameters related to position and size are available in the element configurations. Elements can also
be moved by dragging them around in the dashboard area in Edit mode. Resizing can be done by
dragging the black tab in the corner after selecting an element.
Deleting Elements
To delete unwanted elements, simply select the element by left-clicking it, and then right-click it to delete.
Important: This action is permanent, and all configuration is lost after deletion.
Loading and Saving
The dashboard can be saved by clicking the Save button in Edit mode. All elements and configuration
parameters, in addition to dashboard background color, will be stored.
To load a dashboard, click the Load button and browse to a valid dashboard save file.
The saved file is a text file but could have any file extension containing all configuration parameters for
each dashboard element enclosed in curly brackets {} and separated by a semicolon. Each line
corresponds to one configuration parameter and the format of each parameter is a list of decimal byte
values separated by commas. Each configuration parameter is given by the Least Significant Byte first.
The order of the configuration parameters are the same as the order of the configuration parameters in
the Configuration window when the Edit option for the dashboard is selected. Comments are marked by
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 85
double forward slashes "//" and the rest of the line is ignored by the parser when encountering double
slashes.
A simple example of a saved dashboard configuration is given below. A more complex example can be
found in Auto-Configuration Example.
The file content of the saved configuration for this dashboard is given below.
{
0,
'\0',
0, 255, 255, 255,
158, 0,
};
{
0, // Dashboard ID
0, // Element ID
DB_TYPE_LABEL, // Element Type
0, // Z-Index (GUI stack order)
61, 0, // X-coordinate
46, 0, // Y-coordinate
122, 0, // Width
17, 0, // Height
12, // Font Size
1,
0, // Horizontal Alignment
0, // Vertical Alignment
0, 255, 255, 255, // Background Color
255, 0, 0, 0, // Foreground Color
'T', 'E', 'S', 'T', ' ', 'D', 'A', 'S', 'H', 'B', 'O', 'A', 'R', 'D', '\0', // Text
};
{
0, // Dashboard ID
1, // Element ID
DB_TYPE_BUTTON, // Element Type
0, // Z-Index (GUI stack order)
61, 0, // X-coordinate
70, 0, // Y-coordinate
75, 0, // Width
25, 0, // Height
12, // Font Size
'B', 'u', 't', 't', 'o', 'n', '\0', // Text
0,
};
The first element in the file is the dashboard itself. The first line defines the Dashboard ID (0). Then
follows the Title of the dashboard (empty string), the background color of the dashboard (Alpha = 0x00,
Red = 0xFF, Green = 0xFF and Blue = 0xFF), and the height of the dashboard (two byte value, LSB first;
152, 0 => 152 = 0x0098 pixels).
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 86
The following elements are the Label element and the Button element.
Note that strings are null terminated (\0).
Checkboxes are usually grouped and only one bit per checkbox is used to indicate the checkbox state.
For example, for the Label element there are two checkboxes following each other in the Edit window,
one named Bold and one Italic. These are combined into one Configuration byte with bit 0 giving the
state of the Bold checkbox and bit 1 giving the state of the Italic checkbox. In the example above, this is
the 1 between Font size and Horizontal alignment. The value 1 indicates that the Label text format should
be bold but not italic.
Drop-down boxes are given as single byte values with a number corresponding to the selected option.
The topmost option in the list corresponds to a configuration value of 0. For example, for the Label
element the Horizontal Alignment can be either Left=0, Center=1, or Right=2.
Setting Background Color
The square next to the Load button is the Background color selector. Clicking the selector will bring up
the Color selector dialog. Use the sliders to select the desired color, then press OK.
3.5.1.2 Element Types
The various dashboard element types are presented in this section. All element types have some
common parameters. These are listed in the table below. The following sections will list only the
parameters specific to each element type.
Table 3-1. Common Element Parameters
Parameter Type Usage
Z-index Numeric Order index, 0 places the element the farthest to the back
Left Numeric Horizontal placement, unit pixels
Top Numeric Vertical placement, unit pixels
Width Numeric Width of element in pixels
Height Numeric Height of element in pixels
Label
The Label element displays a text string.
Figure 3-22. Label
Endpoints
The Label element has a sink endpoint that accepts all types of sources. Any data sent to the label will
be converted to a string and displayed as text.
Configuration
Table 3-2. Label Specific Parameters
Parameter Type Usage
Font Size Numeric Adjusts the size of the font
Bold Checkbox Sets bold style of the font
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 87
Parameter Type Usage
Italic Checkbox Sets italic style of the font
Horizontal Alignment Dropdown box Selects the alignment of the text within the specified width
Vertical Alignment Dropdown box Selects the alignment of the text within the specified height
Background Color Color Sets the background color of the label
Foreground Color Color Sets the color of the text
Text String Sets the label text
Numeric Input
The Numeric Input element enables input of numeric values to the dashboard.
Figure 3-23. Numerical Input
Endpoints
The Numeric Input has a source endpoint of type int32. Each time the numerical input value is changed
a packet with the value is sent.
Configuration
Table 3-3. Numerical Input Specific Parameters
Parameter Type Usage
Minimum Numeric Minimum value of input
Maximum Numeric Maximum value of input
Value Numeric Initial value
Button
The Button element will send an event each time it is pressed. The button can either be configured as a
normal push button or as a toggle button. The button can have a static text to indicate its functionality.
When it is configured as a toggle button the text will be replaced by ON or OFF depending on the state of
the button. To replace the ON/OFF text by something else the Text parameter must be given as a '/'
delimited text with the first part of the text being the ON state text and the second part the OFF state text.
Figure 3-24. Button
Endpoints
The Button element has a source endpoint of type uint8. Each time the button is pressed a packet is
sent. The value of the packet will always be 0 for a normal button and 0 for a toggle button in its OFF
state and a 1 for a toggle button in its ON state.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 88
Configuration
Table 3-4. Button Parameters
Parameter Type Usage
Font Size Numeric Sets the font size of the button tag
Text String Sets the button tag text. If the button is configured as a toggle button the test
should be delimited by '/'. The first part of the text will then be the ON state
text while the second part will be the OFF state text.
Toggle Button Checkbox Configures the button to be a ON/OFF toggle switch.
Radio Group
The Radio Group element is a group of radio buttons where only one option can be selected at any time.
Initially the first option is selected.
Figure 3-25. Radio Group
Endpoints
The Radio Group element has a source endpoint of type uint16. Each time the state of the element is
changed a message is sent with the index of the currently active option.
Configuration
Table 3-5. Radio Group Specific Parameters
Parameter Type Usage
Font Size Numeric Font size of the button text
Number of Radio Buttons Numeric Number of buttons in the group
Orientation Numeric 0 = Horizontal
1 = Vertical
Text String '/' delimited text with the text for each button starting with the text
for button with index 0
Check Box
The Check Box element will send an event each time its state is changed.
Figure 3-26. Check Box
Endpoints
The Check Box element has a source endpoint of type uint8. Every time the state of the element is
changed a message is sent. When the box is checked a 1 is sent and when it is unchecked a 0 is sent.
Configuration
Table 3-6. Check Box Specific Parameters
Parameter Type Usage
Font Size Numeric Font size for the text
Text String Sets the Check Box tag text
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 89
Slider
The Slider element is a linear bar with a movable marker. The marker can be moved to adjust the value
of the slider.
Figure 3-27. Slider
Endpoints
The Slider element has a source endpoint of type double. When the slider value is changed a packet with
the value is sent.
Configuration
Table 3-7. Slider Parameters
Parameter Type Usage
Minimum Numeric Sets the minimum value of the slider
Maximum Numeric Sets the maximum value of the slider
Value Numeric Sets the value of the slider
Signal
The Signal element is a simple color-based ON/OFF indicator.
Figure 3-28. Signal
Endpoints
The Signal element has a sink endpoint that accepts all data types, but ignores strings and multidimensional
values. The color of the signal is decided by a boolean evaluation, if the incoming value is a
number it is true if it is greater than 0.
Configuration
Table 3-8. Signal Parameters
Parameter Type Usage
Color On Color Selects the color used when the signal is ON
Color Off Color Selects the color used when the signal is OFF
Progress Bar
The Progress bar element is a linear bar that shows the position of a value between a min. and max.
value.
Figure 3-29. Progress Bar
Endpoints
The Progress bar element has a sink endpoint that accepts all numeric data types. When a value is
received, it will update the amount of colored area of the progress bar depending on the min. and max.
values.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 90
Configuration
Table 3-9. Progress Bar Parameters
Parameter Type Usage
Minimum Numeric Sets the minimum value of the progress bar
Maximum Numeric Sets the maximum value of the progress bar
Value Numeric Sets the value of the progress bar
Color Color Sets the color of the progress bar
Segment Display
The Segment display element simulates a hex-digit LED display.
Figure 3-30. Segment Display
Endpoints
The Segment display element has a sink endpoint that accepts all numeric data types. The value
received is displayed.
Configuration
Table 3-10. Segment Display Parameters
Parameter Type Usage
Segment Count Numeric Number of hex-segments to display
Numeric Base Numeric Sets the base used for displaying numbers
Segment Color Color Sets the color of the segment display
Graph
The Graph element plots the incoming data streams in a two-dimensional graph. The graph can be
configured to accept zooming and scrolling by mouse interaction or to be static ignoring any mouse
interaction.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 91
Figure 3-31. Graph
Endpoints
The Graph element has one sink endpoint for each plot. The endpoints accepts all numerical data types.
Each plot in the Graph can be shown or hidden dynamically by clicking the legend corresponding to the
plot at the bottom of the Graph element. Hidden plots have a gray legend compared to visible plots
having the same color on the legend as the plot itself.
Figure 3-32. Graph with Visible SPI Output Plot and Hidden TWI Output Plot
In the graph above the plot SPI Output is visible while the plot TWI Output is hidden.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 92
Configuration
Table 3-11. Graph Specific Parameters
Parameter Type Usage
Title color Color Selects the color of the title text
Background color Color Selects the color of the complete Graph element background
Graph background color Color Selects the color of the graph plot area background
Title String Title of the graph
Number of plots Numeric Number of plots to display in the graph. Each plot will have its own
sink endpoint.
X Minimum Numeric Minimum value of X axis
X Maximum Numeric Maximum value of X axis
Y Minimum Numeric Minimum value of Y axis
Y Maximum Numeric Maximum value of Y axis
Mouse Interaction Checkbox Enable mouse interaction with the Graph element
Fit to right Checkbox Expand the Graph element to the right edge of the dashboard
Autoscale Checkbox Automatically scale Y axis accoriding to plot data
Scroll by time Checkbox Scroll X axis by time. If not checked the X axis will scroll by
incoming plot samples.
Show plot Checkbox View continuous graph plot (sample points interconnected)
Show points Checkbox Show single samples as dots
Pie Chart
The Pie Chart element displays the value of the incoming streams as slices in a pie chart.
Figure 3-33. Pie Chart
Endpoints
The Pie Chart element has one sink endpoint for each slice in the pie chart. The sink endpoints accepts
all numerical data types.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 93
Configuration
Table 3-12. Pie Chart Specific Parameters
Parameter Type Usage
Title color Color Selects the color of the title text
Background color Color Selects the element background color
Title String Title of the element
Number of plots Numeric Number of slizes in the pie chart
Rectangle
The Rectangle element sends a packet each time it is clicked by the mouse.
Figure 3-34. Rectangle
Endpoints
The Rectangle element has a source endpoint of type uint32. Each time the element is clicked by the
mouse pointer a packet with value 0 is sent.
Configuration
Table 3-13. Rectangle Specific Parameters
Parameter Type Usage
Background color Color Selects the color of the fill of the rectangle
Foreground color Color Selects the color of the frame of the rectangle
Surface
The Surface element displays grid data as a surface in 3D space.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 94
Figure 3-35. Surface
Endpoints
The Surface element has one endpoint accepting any source of a grid type.
Configuration
Table 3-14. Surface Specific Parameters
Parameter Type Usage
Fill color Color Selects the color of the surface fill
Mesh color Color Selects the color of the surface mesh
Background color Color Selects the color of the background
Background gradient color Color Selects the color of the background gradient
Axis color Color Selects the color of the axes
Tick color Color Selects the color of the tick labels
X Rotation Numeric Sets rotation of view around X
Y Rotation Numeric Sets rotation of view around Y
Z Rotation Numeric Sets rotation of view around Z
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 95
Parameter Type Usage
Show X-axis Checkbox Sets visibility of X-axis
Show Y-axis Checkbox Sets visibility of Y-axis
Show Z-axis Checkbox Sets visibility of Z-axis
Show fill Checkbox Sets visibility of surface fill
Show mesh Checkbox Sets visibility of surface mesh
Use palette coloring Checkbox Sets usage of palette coloring (red-yellow-green-white)
Scaling mode Drop-down box Selects mode of Y-axis auto-scaling
Axis minimum Numeric Sets minimum axis value for Y
Axis maximum Numeric Sets maximum axis value for Y
Table
The Table element displays one or more data sources in a table. Two modes are supported, Auto Labels
and Manual Labels. In the Auto Labels mode, each cell is split into two fields, the field to the left is a label
with the name of the data stream and the field to the right is the actual data of the stream. In the Manual
Labels mode each cell can be manually configured to either be a Label cell or a Data cell. The mode is
selected by the checkbox named Auto Labels in the configuration, see Configuration.
Auto Labels
When using the Auto Labels mode each cell is associated with one data source and the name of the data
source is shown to the left in the cell and the actual data to the right. The source name is automatically
fetched from the source connected to the sink endpoint.
The Table element has one endpoint per table cell accepting any data source. The data will be converted
to a string and displayed as text.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 96
Endpoints are shown when the Show Endpoints option is selected.
Manual Labels
When using the Manual Labels mode each cell either is a Label cell or a Data cell. By default all cells are
Data cells. Label cells can be configured by setting the Label Configuration string, see Configuration.
The Label Configuration string configures which cells are Labels by giving a semicolon separated list of
Labels. Each Label is given by the format ::. The upper left cell is column 0, row 0.
An example is given below.
The Label Configuration for this table is:
0:0:LABEL A;1:0:LABEL B;0:1:LABEL C;0:2:LABEL D
Only the Data cells have endpoints.
The label text should not contain colons or semicolons to avoid confusing the Label Configuration
parser.
Endpoints are shown when the Show Endpoints option is selected.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 97
Configuration
Table 3-15. Table Specific Parameters
Parameter Type Usage
Data Font Size Numeric Sets the size of the font in the data part of a cell
Label Font Size Numeric Sets the size of the font in the label part of a cell
Data Column
Width
Numeric Width of the data part of each cell. Note that changing this width will
change the total width of the table.
Label Column
Width
Numeric Width of the label part of each cell. Note that changing this width will
change the total width of the table.
Row Height Numeric Height if each row in the table. Note that changing this height will
change the total height of the table.
Number of Rows Numeric Number of rows in the table
Number of
Columns
Numeric Number of columns in the table
Auto Labels Checkbox Enables the Auto Labels mode. If disabled labels must be configured
manually
Label
Configuration
String String configuring the labels when using Manual Labels mode (Auto
Labels option disabled). Format is
::;::...
Data Bold Checkbox Sets bold style of the font in the data part of each cell
Data Italic Checkbox Sets italic style of the font in the data part of each cell
Label Bold Checkbox Sets bold style of the font in the label part of each cell
Label Italic Checkbox Sets italic style of the font in the label part of each cell
Background
Color
Color Sets the background color of the table
Foreground
Color
Color Sets the color of the table grid and the data and label text
Label Horizontal
Alignment
Drop-down
box
Selects the placement of the text in the label part of each cell (Left,
Center, or Right)
Data Horizontal
Alignment
Drop-down
box
Selects the placement of the text in the data part of each cell (Left,
Center, or Right)
3.5.2 Dashboard Configuration Example
This section gives an example on how to configure the Dashboard module. Although the example utilizes
only a subset of the available dashboard elements data sources available in the Data Visualizer, the basic
principles are applicable to all elements and data sources.
This example uses manual configuration of the Dashboard module, but it is also possible to use the
Atmel Data Protocol (ADP) to set up a dashboard automatically. For more information on ADP and an
example of a automatically configured dashboard, see Atmel Data Protocol.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 98
The target application code used in this example and a description of the hardware setup can be found in
Dashboard Example Code.
To do:
• Open the configuration panel
• Add a new I/O Dashboard component by double-clicking the I/O Dashboard module
To do:
• Enable editing the dashboard by clicking the Edit option in the lower left corner of the
Dashboard I/O module
• Open the Elements panel in the upper right corner of the dashboard and drag elements
onto the dashboard.
Tip: To remove an element from the dashboard, select it by left-clicking it, and then right-click
the element.
Tip: Changing the parameters in the Configuration section will not take effect until the Set
button is clicked.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 99
In this example, three Label elements are added, one as a title for the dashboard and the two others as
help text for the slider. A Graph element with one plot was added to be used for the light sensor data.
The Y Minimum and Y Maximum values were set to 0 and 255, respectively. A Signal element was
added to be able to see which mode is active. When the Night mode is active the signal turns dark blue
(Color On) and when the Night mode is inactive the signal turns yellow (Color Off). Finally, a slider was
added to make it possible to adjust the Night mode threshold. The Minimum was set to 0 and the
Maximum was set to 255. Moving the slider to the left lowers the threshold and results in the Night mode
being active at brighter light levels.
When the dashboard has been set up it is time to connect the dashboard to the serial interfaces to enable
communication with the target application.
Before the endpoints in the dashboard can be hooked up, the interfaces between the target board and
the host computer must be configured. This example uses the DGI SPI interface and the CDC USART
interface. The CDC interface will appear on the host computer as an ordinary serial COM port.
To do: Select correct tool in the DGI Control Panel.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 100
To do: Click Connect to make a connection to the DGI on the selected tool.
To do:
• Click the SPI checkbox
• Open the SPI Configuration dialog by clicking the Gear button next to the SPI checkbox
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 101
To do:
• Open the Serial Port Control panel found under External Connection in the Modules
section of the Configuration tab in Data Visualizer
To do:
• Select the correct COM port corresponding to the connected kit
• Set the serial port parameters according to the application code
• Make sure the Open Terminal option is not checked
To do:
• Deselect the Edit option
• Click the Show Endpoints option
• Drag the SPI source to the graph sink
• Drag the serial port source to the signal sink
• Drag the slider source to the serial port sink
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 102
Now the dashboard is fully configured and can be used to interact with the Night mode switch application.
To do:
• Deselect the Show Endpoints option
• Click Start in the DGI Control Panel
• Click Connect in the Serial Port Control Panel
Now the ADC raw values are shown in the graph and the slider can be adjusted to a suitable threshold for
the Night mode switch. The signal element shows the state of the switch.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 103
4. Utilities
Utilities are modules that do not fit in the other categories, but are still helpful for analyzing data.
The Samplerate Counter provides a measure of how much data is being transmitted.
The File Logger module stores incoming data in a file of selectable format. The file contents can then be
analyzed in another application.
4.1 Samplerate Counter
The samplerate counter module takes an incoming data stream and measures the amount of incoming
samples in the stream.
To use the samplerate counter simply connect a source to the sink of the samplerate counter module
and start the data stream. The samplerate counter can be used with streams of any data type.
4.2 File Logger
The File Logger module logs all incoming data to a file of selectable format.
Figure 4-1. File Logging
1
2
3 4
1. Output file selection box. 2. Output format selection box. 3. Input sink. 4. Start/Stop button.
4.2.1 Logging to a Binary File
• Select output format “BIN” in the Output format selection box
• Set the output file by pressing the “...” button in the Output file selection box and selecting a path
and name
• Connect an external source to the input sink
• Press the Start button to begin logging. The button will be replaced by the Stop button.
• Press the Stop button to close the file and end logging before inspecting the logged data
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 104
5. Protocols
Most communication interfaces use streams of bytes to transfer data. This is enough for single data
values of 8-bit precision, but when multiple values are required to be transmitted over the same interface,
data must be packed in a protocol. The Data Visualizer supports two such protocols.
The Data Stream protocol is using a light-weight framing format to pack several numerical values over
one interface. It is only capable of handling incoming data and it only supports synchronous streams (i.e.,
every data packet must contain one sample from each data stream).
The Atmel Data Protocol (ADP) enables streaming of data in both directions. ADP is, in general, more
flexible than the Data Stream protocol and it also supports asynchronous streams (i.e., data samples
from each data stream can be sent independently).
Both protocols can be automatically detected and used to automatically configure the Data Visualizer by
defining data streams, configuring a Dashboard and connect the data streams to the Dashboard
elements. The main difference is that for the Data Stream protocol, the configuration settings reside in
configuration files on the host computer while for ADP the configuration settings are sent from the target
application to the host computer. In addition, ADP can configure Graph and Terminal views. The Graph
element in the Dashboard view is supported by both protocols.
Table 5-1. Protocol Comparison
Data Stream Protocol Atmel Data Protocol
(ADP)
Comment
Complexity Simple/Lightweight Complex/Flexible
Start/Stop individual
streams
- X
Data input X X Data transmission from
target application to host
computer
Data output - X Data transmission from
host computer to target
application
Support String data type - X Various length strings
Configuration settings
stored on host computer
X - Configuration of Data
Visualizer GUI
Configuration settings
stored in target
application
- X Configuration of Data
Visualizer GUI
Dashboard View
configuration
X X
Graph View
configuration
- X
Terminal View
configuration
- X
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 105
Data Stream Protocol Atmel Data Protocol
(ADP)
Comment
Data bursts - X More than one sample
of a data stream can be
sent in one package
Asynchronous data
streams
- X Samples from different
data streams can be
sent independently
X = Supported
- = Not supported
5.1 Data Stream Protocol
The data stream module takes an incoming raw data stream and splits it into multiple data streams. The
data stream format is specified by a configuration file provided by the user.
5.1.1 Configuration Format
The configuration file is a comma-delimited text file that specifies one data variable per line. Each line
starts by specifying the data format of the variable by one of the tags presented in the table below. The
position of the variable in the output grid is then given by two coordinates starting at index 1. The final
parameter assigns a text string to the variable.
Table 5-2. Data Stream Types
Type Size Tag Example
Unsigned byte 1 B B,1,1,Light
Signed byte 1 -B -B,1,1,Encoder
Unsigned short 2 D D,1,1,ADC
Signed short 2 -D -D,1,1,ADC
Unsigned word 4 W W,1,1,Transfer rate
Signed word 4 -W -W,1,1,Status code
Floating point 4 F F,1,1,Temperature
Double-precision floating point 8 DF DF,1,1,Measurement
Grid of unsigned bytes 1 * W * D GB GB<10x10>,1,1,Surface
Grid of signed bytes 1 * W * D -GB -GB<10x10>,1,1,Surface
Grid of unsigned short 2 * W * D GD GD<10x10>,1,1,Surface
Grid of signed short 2 * W * D -GD -GD<10x10>,1,1,Surface
Grid of unsigned word 4 * W * D GW GW<10x10>,1,1,Surface
Grid of signed word 4 * W * D -GW -GW<10x10>,1,1,Surface
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 106
Type Size Tag Example
Grid of floating point 8 * W * D GF GF<10x10>,1,1,Surface
Grid of double-precision floating point 8 * W * D GDF GDF<10x10>,1,1,Surface
This is an example configuration:
D,1,1,ADC0
D,1,2,ADC1
D,1,3,ADC2
B,2,1,Prescaler
5.1.2 Stream Format
The data stream is processed in the same order as the configuration file specifies. All data must be given
as little endian values, meaning that the lowest byte must be sent first. Additionally, a wrapper consisting
of one byte before and one byte after the data stream variables must be added. This wrapper is used by
the interpreter to synchronize to the data stream. The start byte can be of an arbitrary value except 0x5F,
which is reserved for Auto-Configuration, but the end byte must be the inverse of the Start byte. For more
information on the Auto-Configuration feature see Auto-Configuration and Auto-Configuration Example.
The configuration file shall not define the start and end bytes.
Consider the example configuration given in the previous section. The figure below gives an example raw
data transmission where ADC0 is 185, ADC1 is 950, ADC2 is 0, and Prescaler is 2.
Figure 5-1. Data Streamer
Start ADC0 ADC1 ADC2 Prescaler End
… 0x03 0xB9 0x00 0xB6 0x03 0x00 0x00 0x02 0xFC …
5.1.3 Basic Usage
Figure 5-2. Data Streamer
• Press the Open file button (3)
• Select the configuration file
• Click the Load configuration button (4)
• Connect the input sink (5)
• Connect one or more output source to a desired sink (1)
5.1.4 Auto-Configuration
The Data Stream format can be used to automatically configure the Data Visualizer based on some predefined
configuration files. This differs from the Atmel Data Protocol (ADP) auto-configuration where the
configuration settings are stored in the target application and sent to the host upon request. The Data
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 107
Stream auto-configuration is limited to setting up a data stream, configure a Dashboard View and connect
the data stream output sources to the dashboard elements.
5.1.5 Auto-Configuration Example
The purpose of this example is to show how to set up the configuration files required to automatically
configure a dashboard with a signal showing the state of a pushbutton on the target hardware and a
graph showing the value of a counter in the target application. The screenshot below shows the final
dashboard.
The target code used in this example can be found in Auto-Configuration Example Code.
Three files are required by the Data Visualizer to enable Auto-Configuration, a .ds file describing the data
stream content, a .db file describing the dashboard and a .sc file describing the connections between the
data stream content and the dashboard elements. All files should be named
"C0FFEEC0FFEEC0FFEEC0FFEE" before the extension to match the Auto Configuration ID sent by the
application code.
The example application generates a data stream with two stream components, an unsigned 16-bit value
and an unsigned 8-bit value.
To do:
• Create a file called "C0FFEEC0FFEEC0FFEEC0FFEE.ds" and add the content below
D,1,1,count
B,2,1,button
The .ds file will create a table with two sources from the data stream. Column 1 row 1 will contain a
source with unsigned 16-bit values named "count" and column 2, row 1 will contain a source with
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 108
unsigned 8-bit values named "button". For more information on the .ds file format see Configuration
Format.
The easiest way to set up a dashboard for the Auto-Configuration is to draw it in the Data Visualizer GUI
and save the configuration to file.
To do:
• Open the configuration panel
• Add a new I/O Dashboard component by double-clicking the I/O Dashboard module
To do:
• Enable editing the dashboard by clicking the Edit option in the lower left corner of the
Dashboard I/O module
• Open the Elements panel in the upper right corner of the dashboard and drag elements
onto the dashboard.
Tip: To remove an element from the dashboard, select it by left-clicking it, and then right-click
the element.
Tip: Changing the parameters in the Configuration section will not take effect until the Set
button is clicked.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 109
To do:
• Drag a Label element to the dashboard
• Select the Label element and set Font Size to 16, Tick the Bold option, set Text field to
“Button State” and set Width to 100.
• Push Set
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 110
To do:
• Drag a Signal element to the Dashboard and put it below the Button State label
• Drag a Graph element to the Dashboard and put it to the right of the Button State label
and signal
• Select the Graph element and set Title to “count value”, X Maximum to 5, Y Maximum
to 66000
• Click Set
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 111
To do:
• Click Save
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 112
To do:
• Save the Dashboard configuration as “C0FFEEC0FFEEC0FFEEC0FFEE.db” in the same
folder as the .ds file
The .db file content should have content similar to:
{
0,
'\0',
0, 255, 255, 255,
44, 1,
};
{
0, // Dashboard ID
0, // Element ID
DB_TYPE_LABEL, // Element Type
0, // Z-Index (GUI stack order)
63, 0, // X-coordinate
48, 0, // Y-coordinate
100, 0, // Width
22, 0, // Height
16, // Font Size
1,
0, // Horizontal Alignment
0, // Vertical Alignment
0, 255, 255, 255, // Background Color
255, 0, 0, 0, // Foreground Color
'B', 'u', 't', 't', 'o', 'n', ' ', 'S', 't', 'a', 't', 'e', '\0', // Text
};
{
0, // Dashboard ID
1, // Element ID
DB_TYPE_SIGNAL, // Element Type
0, // Z-Index (GUI stack order)
98, 0, // X-coordinate
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 113
78, 0, // Y-coordinate
25, 0, // Width
25, 0, // Height
255, 0, 255, 0, // Color On
255, 255, 0, 0, // Color Off
};
{
0, // Dashboard ID
2, // Element ID
DB_TYPE_GRAPH, // Element Type
0, // Z-Index (GUI stack order)
206, 0, // X-coordinate
12, 0, // Y-coordinate
64, 1, // Width
240, 0, // Height
255, 255, 255, // Title color
0, 0, 0, // Background color
20, 20, 20, // Graph background color
'c', 'o', 'u', 'n', 't', ' ', 'v', 'a', 'l', 'u', 'e', '\0', // Title
1, // Number of plots
0,0,0,0, // X Minimum
0,0,160,64, // X Maximum
0,0,0,0, // Y Minimum
0,232,128,71, // Y Maximum
1,
1,
};
For more information on the Dashboard elements, see Element Types.
Finally, the configuration file to connect the data stream sources defined in the .ds file to the Dashboard
elements defined in the .db file must be made.
To do:
• Create a file called “C0FFEEC0FFEEC0FFEEC0FFEE.sc” in the same folder as the other
config files and add the content below:
button,1
count,2
The .sc file will connect the stream source named “button” to the Dashboard element with ID 1 (the Signal
element) and the stream source named “count” to the Dashboard element with ID 2 (the Graph element).
Then it is time to run the example.
To do:
• Close the Dashboard panel
To do:
• Open the Serial Port Control panel found under External Connection in the Modules
section of the Configuration tab in Data Visualizer
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 114
To do:
• Select the correct COM port corresponding to the connected kit
• Make sure Autodetect protocols option is checked and the Parity and Stop bits
configurations are set according to the target application. The Baud rate will be detected
automatically.
To do:
• Click Connect
• If Data Visualizer cannot find the configuration files for the detected Auto-Configuration ID
it will show a pop-up asking for the path to the configuration files. Browse to the folder
where the configuration files reside and click OK
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 115
After selecting a folder, the folder will be APPENDED to the Auto-Configuration search path.
Tip: To reset the search path and select a new single folder as the search path, click the link
on the Autodetect protocols option text.
Data Visualizer will then pop up a browser dialog asking for the path to the folder where the
configuration files reside. The original search path will be CLEARED and the newly selected
folder will be set as search path.
Important: All three configuration files must reside in the same folder.
After connecting and detecting the Auto-Configuration ID the Data Visualizer should create a Data Stream
Control Panel and a Dashboard I/O looking something like the image below.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 116
The Graph element shows a running sawtooth signal which represents the counter continuously counting
up until it wraps. The Signal element shows the state of the push button on the ATtiny104 Xplained Nano
board. Pushing the button changes the color of the Signal element from red to green.
Expanding the Data Stream Control Panel by clicking the down arrow to the right in the panel shows the
content of the automatically configured Data Stream.
The stream has two sources, one for the counter value and one for the button state.
Expanding the Serial Port Control Panel shows that Data Visualizer detected the baud rate to be 38400.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 117
5.1.6 Auto-Configuration Format
If the start byte of a Data Stream packet is 0x5F then this packet is a special Configuration packet.
Table 5-3. Configuration Packet Format
Field Size Values Description
Start token 1 byte 0x5F Start token reserved for configuration packets.
Checksum format 4 bytes 0xB4 0x00 0x86
0x4A
Specifies the checksum format to be used.
Currently only LRC8 is supported.
Configuration
identifier
12 bytes Any value Unique identifier for the configuration.
Checksum 1 byte Checksum
according to
Checksum format
Currently only LRC8 checksum format is
supported. This is the XOR sum of the packet
excluding the start token, the checksum itself and
the end token.
End token 1 byte 0xA0 Following the Data Stream format the end token is
the inverse of the start token.
The identifier given in the Configuration packet is used by Data Visualizer to look-up the corresponding
configuration files used to configure the Data Visualizer. Three configuration files are needed:
• A .ds file defining the Data Stream. This is a normal Data Stream format file and follows the format
given in Configuration Format.
• A .db file defining the Dashboard. This file follows the format of the files generated when saving a
Dashboard to file, see Edit Panel.
• A .sc file defining the connections between the Data Stream components defined in the .ds file and
the elements of the Dashboard defined in the .db file. The format is defined in Signal Connections
File Format.
All three configuration files should have a name equal to the hex values of each Configuration identifier
byte. As an example, a Configuration identifier of [0x12, 0x34, 0x56, 0x78, 0x9A, 0xBC, 0xDE, 0xF0,
0x12, 0x34, 0x56, 0x78] corresponds to configuration files named 123456789ABCDEF012345678.sc,
123456789ABCDEF012345678.db and 123456789ABCDEF012345678.ds.
The Data Streamer Auto-Configuration feature is available both in the DGI Control Panel for all DGI serial
interfaces and in the Serial Port Control Panel for COM ports and Virtual COM ports (CDC interface)
To enable Auto-configuration the Autodetect protocols option must be enabled.
After pushing Connect the Data Visualizer will enable all interfaces while it looks for the ADP handshake
message or a Data Stream Configuration packet. If an ADP handshake message is received, the Data
Visualizer will request configuration information from the target application. If a Data Stream Configuration
packet is found, the Data Visualizer searches through the folders in the Auto-Configuration search path
looking for configuration files with names matching the detected ID.
Important: To make sure the Data Visualizer detects the Data Stream Configuration packet, it
must be sent by the target at least twice per second.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 118
Important: Asynchronous serial protocols (e.g., UART protocols used by DGI USART and
CDC Virtual COM port interfaces) use the following baud rates for auto-detection:
Table 5-4. Baud Rates Used on Asynchronous Interfaces for Auto-Detection of Protocols
Baud Rate
9600
19200
38400
57600
115200
230400
500000
1000000
2000000
Using any baud rates not in the table will not work for auto-detection of protocols over
asynchronous interfaces (DGI UART and Serial port/CDC Virtual COM port).
Tip: To see the current search path used by Data Visualizer to look for configuration files,
check the Show Config search path option.
The search path is a semicolon separated list of paths. When Data Visualizer detects an AutoConfiguration
ID, it will search through the paths in the list looking for configuration files with the
correct file names.
If the Data Visualizer cannot find any valid configuration files it will show a browser dialog window asking
for the path to the folder where the correct configuration files reside.
After selecting a folder, the folder will be APPENDED to the Auto-Configuration search path.
Tip: To reset the search path and select a new single folder as the search path, click the link
on the Autodetect protocols option text.
Data Visualizer will then pop up a browser dialog asking for the path to the folder where the
configuration files reside. The original search path will be CLEARED and the newly selected
folder will be set as search path.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 119
Important: All three configuration files must reside in the same folder.
5.1.7 Signal Connections File Format
A signal connections file has the file extension .sc and it specifies the connections between the data
stream sources defined in a .ds file and the GUI elements in the Dashboard defined in a .db file. The .sc
file format is a comma-delimited text file specifying one connection per line. Each line follows the format
, . The Stream name is defined in the .ds file and is the text string assigned
to each data variable. The Element ID is defined in the .db file for each Dashboard Element.
An example of a .sc file content:
Plane,0
Delta1,2
Delta2,2
A stream called Plane is connected to an Element with ID 0 and both streams Delta1 and Delta2 are
connected to an Element with ID 2. For a full auto-configuration example, see Auto-Configuration
Example.
The Table Element (see Table) has some extra parameters in addition to the Stream name and Element
ID. The column and row of the cell to connect the signal to is given by appending (Column:;Row:) to the lines in the .sc file. The upper left cell is specified by column 0 and
row 0. As an example the table
is connected to sources by the following .sc file content:
Delta1,2(Column:1;Row:1)
Delta2,2(Column:1;Row:2)
Delta3,2(Column:1;Row:3)
Delta4,2(Column:1;Row:4)
Delta5,2(Column:1;Row:5)
Delta6,2(Column:1;Row:6)
Delta7,2(Column:1;Row:7)
Delta8,2(Column:1;Row:8)
Delta9,2(Column:1;Row:9)
Delta10,2(Column:1;Row:10)
Note that in the example the Table element is in Auto-Labels mode so each cell has two fields; a label to
the left and the actual data to the right. For more information, see Auto Labels.
The Graph Element (see Graph) also supports an extra parameter in addition to the Stream name and
Element ID. By default, all plots are visible in the Graph element but they can be hidden or shown by the
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 120
user clicking the legend in the Graph view corresponding to a plot. The extra parameter supported makes
it possible to change the default behavior to hide plots when doing auto-configuration. This is done by
appending (visible:0) to the .sc file. As an example, see the following .sc file
Delta1,2(visible:0)
Delta2,2
Delta3,2(visible:0)
Delta4,2
Delta5,2
Delta6,2
Delta7,2(visible:0)
Delta8,2(visible:0)
Delta9,2
Delta10,2
results in the graph element looking like this:
In the graph the plots named Delta1, Delta3, Delta7, and Delta8 are all hidden and the legends are gray.
The user can enable them by clicking the legends. In the same way the visible plots can be hidden by the
user clicking the corresponding legends.
5.2 Atmel Data Protocol
5.2.1 Transfer using Atmel Data Protocol
The Atmel Data Protocol (ADP) is a content independent protocol intended for transferring data from a
target MCU to a host PC through an EDBG-based debugger (EDBG, Atmel-ICE, Power Debugger) using
the Data Gateway Interface (DGI, see Embedded Debuggerʼs Data Gateway Interface) or directly to the
host computer using a serial port. ADP is content independent and the transfer through the debugger is
transparent, meaning that the content is not interpreted by the debugger.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 121
Transferring a single value is quite simple. But to transfer more than one value, they have to be wrapped
in some kind of protocol that both the sender and receiver understands. ADP is such a protocol. If the
MCU wraps all its data into an ADP packet, it can be decoded in the Data Visualizer and split into
separate data streams.
Figure 5-3. An ADP Transfer
In the figure above, the MCU packs a temperature and a pressure variable inside an ADP packet. In the
Data Visualizer, the SPI endpoints in the DGI Control Panel are now connected to the Data endpoints of
an ADP Control Panel. The ADP Control Panel will decode the packets into separate temperature and
pressure data streams. They can then be connected to two plot lines in the Graph module.
The ADP protocol supports data transfer in both directions. In addition, the MCU can send configuration
packets describing what modules should be opened in the Data Visualizer, and how to connect them.
When the target board is connected to the host computer everything will be configured automatically.
5.2.2 ADP Example
For an example of ADP protocol usage, the ADP example application for SAM D21 Xplained Pro can be
used. This example can be found in Atmel Software Framework (ASF) in Atmel Studio. It uses a SAM
D21 Xplained Pro together with an I/O Xplained Pro board.
This example uses the Data Gateway Interface (DGI), see the Embedded Debuggerʼs Data Gateway
Interface on the Embedded Debugger (EDBG), but any serial port is sufficient.
5.2.2.1 Requirements
• Host computer with Atmel Studio 7 (or later) installed (Data Visualizer is included)
• SAM D21 Xplained Pro kit
• I/O1 Xplained Pro extension
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 122
5.2.2.2 Hardware Setup
To run the example the following hardware setup is required:
• I/O1 Xplained Pro extension connected to SAM D21 Xplained Pro EXT1 connector
• USB cable connected from host PC to DEBUG USB connector on SAM D21 Xplained Pro
A picture of the setup is shown below.
5.2.2.3 Run Example
To run the ADP example follow the steps below.
To do:
• Open Atmel Studio
• Select File → New → Example Project
• Browse to, or search for the ADP example application - SAM D21 Xplained Pro and select
it
• Choose the preferred folder and give the project a name, then click OK to create the
project
The project will be generated, then it is just a matter of compiling it and programming it into the target
board.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 123
To do:
• Open the project properties (right click the project in the Solution Explorer and select
Properties)
• On the Tool tab, select the appropriate tool and interface
To do:
• Click Start Without Debugging (Debug → Start Without Debugging)
To do: Open the Data Visualizer as an extension inside Atmel Studio by selecting it in the
Tools menu.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 124
To do:
• In the DGI Control Panel, select SAM D21 Xplained Pro
• Select the Autodetect protocols box
• Click Connect
You should see something like the screenshot below in the Data Visualizer.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 125
5.2.2.4 How it Works
As the code for the ADP example is quite extensive, it will not make sense to list it or describe all the
details. Especially, details on how to set up the required peripherals on the ATSAMD21 will be left out.
The ADP messages required to create the ADP example dashboard will be detailed in the following
chapters. Note that, after each message sent to the computer, the target (the SAM D21 device) waits for
a MSG_CONF_ACK (MSG_CONF_ACK) before sending the next message.
Tip: This example includes full automatic configuration of a Dashboard. However, the ADP
could be used to configure a set of streams to be connected manually to various modules in the
Data Visualizer like Graph, Oscilloscope, or Terminal. The ADP Control Panel shows the
available sinks and sources for the current ADP instance. These sinks and sources can be used
in the same way as the sources and sinks in the DGI Control Panel and the Serial Port
Control Panel. For more information, see Atmel Data Protocol.
Serial Interface
The ADP example uses an SPI interface to stream the ADP data from the SAM D21 to the embedded
debugger (EDBG) on the SAM D21 Xplained Pro board. The EDBG uses the Data Gateway Interface
(DGI) to stream the data over USB to the host computer. If the target board did not contain a device with
DGI capability, ADP could have been streamed directly to the computer over a serial interface. If this was
the case the Serial Port Control Panel (Serial Port) would have been used in the Data Visualizer instead
of the DGI Control Panel (Data Gateway Interface (DGI)).
Initialization
After setting up the hardware (e.g., initializing the serial interface, setting up the ADC and I/O ports), the
application is ready to start sending the ADP messages. The first message sent is a
MSG_REQ_HANDSHAKE.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 126
Table 5-5. MSG_REQ_HANDSHAKE
Field Values Description
Token 0xFF
Message ID 0x00
Data length 10
Protocol version 0x01 The ADP example uses ADP protocol version 1
Options 0x01 GPIO is in use in this application
Token {0x58, 0x99, 0xAB, 0xC9, 0x0F,
0xE2, 0xF7, 0xAA}
Token used to verify ADP protocol
This message is repeated until a MSG_RES_HANDSHAKE (MSG_RES_HANDSHAKE) is received,
indicating the host is ready to receive messages.
ADP Control Panel
The ADP example configures the ADP Control Panel to look something like the screenshot below.
Notice: The appearance of screenshots will vary with operating system version and
configuration.
The ADP Control Panel is configured by the message detailed in the table below.
Table 5-6. MSG_CONF_INFO
Field Values Description
Token 0xFF
Message ID 0x28
Data length 177
Title “Light Sensor Example for Xplained Pro\0”
Description “This example demonstrates light intensity measurements
through the ADC of a Xplained Pro board. You will need the I/O1
Xplained Pro (EXT1)\0”
Short description of the
application
Light Sensor Dashboard
The ADP example sets up a dashboard for the I/O1 Xplained Pro light sensor and LED that looks
something like the screenshot below.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 127
Notice: The appearance of screenshots will vary with operating system version and
configuration.
The light sensor dashboard is configured by the messages detailed in the tables below.
First, the dashboard itself must be set up.
Table 5-7. MSG_CONF_DASHBOARD
Field Values Description
Token 0xFF
Message ID 0x2A
Data length 38
ID 0x0000 Dashboard ID
Label “Light Sensor Example Dashboard\0” Dashboard label
Background color 0xFFFFFF (transmitted as 0xFFFFFFFFFFFF as
each 0xFF character must be transmitted as
0xFFFF, see Message Format)
Background color of dashboard
Height 300 Height (in pixels) of dashboard
Next, Label elements are added to the dashboard.
Table 5-8. MSG_CONF_DASHBOARD_ELEMENT, ELEMENT_TYPE_LABEL
Field Values Description
Token 0xFF
Message ID 0x2B
Data length 47 Depending on element type
Dashboard ID 0x0000 ID of light sensor dashboard
Element ID 0x0000 Unique ID of label element
Z-Index 0 Order index, 0 places the element the
farthest to the back
X-coordinate 5 X-coordinate of element location. 0 is
topmost position on dashboard.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 128
Field Values Description
Y-coordinate 5 Y-coordinate of element location. 0 is
topmost position on dashboard.
Width 300 Width of element (pixels)
Height 35 Height of element (pixels)
Element type 0x00 ELEMENT_TYPE_LABEL
Font size 24
Attribute 0x00 Bold = OFF, Italic = OFF
Horizontal alignment 1 Center
Vertical alignment 1 Center
Background
transparency
0
Background color 0xFFFFFF (transmitted as
0xFFFFFFFFFFFF as each
0xFF character must be
transmitted as 0xFFFF, see
Message Format)
RGB color of background
Foreground
transparency
255 (transmitted as 0xFFFF as
each 0xFF character must be
transmitted as 0xFFFF, see
Message Format)
Foreground color 0x000000 RGB color of background
Label text “Light Sensor Example\0”
Table 5-9. MSG_CONF_DASHBOARD_ELEMENT, ELEMENT_TYPE_LABEL
Field Values Description
Token 0xFF
Message ID 0x2B
Data length 45 Depending on element type
Dashboard ID 0x0000 ID of light sensor dashboard
Element ID 0x0001 Unique ID of label element
Z-Index 0 Order index, 0 places the element the
farthest to the back
X-coordinate 5 X-coordinate of element location. 0 is
topmost position on dashboard.
Y-coordinate 60 Y-coordinate of element location. 0 is
topmost position on dashboard.
Width 129 Width of element (pixels)
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 129
Field Values Description
Height 25 Height of element (pixels)
Element type 0x00 ELEMENT_TYPE_LABEL
Font size 14
Attribute 0x01 Bold = ON, Italic = OFF
Horizontal alignment 0 Left
Vertical alignment 1 Center
Background
transparency
0
Background color 0xFFFFFF (transmitted as
0xFFFFFFFFFFFF as each
0xFF character must be
transmitted as 0xFFFF, see
Message Format)
RGB color of background
Foreground
transparency
255 (transmitted as 0xFFFF as
each 0xFF character must be
transmitted as 0xFFFF, see
Message Format)
Foreground color 0x000000 RGB color of background
Label text “Light Sensor Value\0”
Table 5-10. MSG_CONF_DASHBOARD_ELEMENT, ELEMENT_TYPE_LABEL
Field Values Description
Token 0xFF
Message ID 0x2B
Data length 38 Depending on element type
Dashboard ID 0x0000 ID of light sensor dashboard
Element ID 0x0002 Unique ID of label element
Z-Index 0 Order index, 0 places the element the
farthest to the back
X-coordinate 5 X-coordinate of element location. 0 is
topmost position on dashboard.
Y-coordinate 100 Y-coordinate of element location. 0 is
topmost position on dashboard.
Width 82 Width of element (pixels)
Height 25 Height of element (pixels)
Element type 0x00 ELEMENT_TYPE_LABEL
Font size 14
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 130
Field Values Description
Attribute 0x01 Bold = ON, Italic = OFF
Horizontal alignment 0 Left
Vertical alignment 1 Center
Background
transparency
0
Background color 0xFFFFFF (transmitted as
0xFFFFFFFFFFFF as each
0xFF character must be
transmitted as 0xFFFF, see
Message Format)
RGB color of background
Foreground
transparency
255 (transmitted as 0xFFFF as
each 0xFF character must be
transmitted as 0xFFFF, see
Message Format)
Foreground color 0x000000 RGB color of background
Label text “Night Light\0”
Table 5-11. MSG_CONF_DASHBOARD_ELEMENT, ELEMENT_TYPE_LABEL
Field Values Description
Token 0xFF
Message ID 0x2B
Data length 38 Depending on element type
Dashboard ID 0x0000 ID of light sensor dashboard
Element ID 0x0003 Unique ID of label element
Z-Index 0 Order index, 0 places the element the
farthest to the back
X-coordinate 5 X-coordinate of element location. 0 is
topmost position on dashboard.
Y-coordinate 230 Y-coordinate of element location. 0 is
topmost position on dashboard.
Width 80 Width of element (pixels)
Height 25 Height of element (pixels)
Element type 0x00 ELEMENT_TYPE_LABEL
Font size 14
Attribute 0x01 Bold = ON, Italic = OFF
Horizontal alignment 0 Left
Vertical alignment 1 Center
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 131
Field Values Description
Background
transparency
0
Background color 0xFFFFFF (transmitted as
0xFFFFFFFFFFFF as each
0xFF character must be
transmitted as 0xFFFF, see
Message Format)
RGB color of background
Foreground
transparency
255 (transmitted as 0xFFFF as
each 0xFF character must be
transmitted as 0xFFFF, see
Message Format)
Foreground color 0x000000 RGB color of background
Label text “LED Control\0”
A stream needs to be set up to receive light sensor data.
Table 5-12. MSG_CONF_STREAM
Field Values Description
Token 0xFF
Message ID 0x20
Data length 18
ID 0x0001 ID of the light sensor data stream
Type 12 Stream type float
Mode 2 Out from target
State 0 Stream state ON
Label “Light sensor\0” Label of the data stream
And a Progress bar to show the light sensor data is added.
Table 5-13. MSG_CONF_DASHBOARD_ELEMENT, ELEMENT_TYPE_PROGRESS
Field Values Description
Token 0xFF
Message ID 0x2B
Data length 29 Depending on element type
Dashboard ID 0x0000 ID of the light sensor dashboard
Element ID 0x0004 Unique ID of the progress bar element
Z-Index 0 Order index, 0 places the element the farthest to the back
X-coordinate 140 X-coordinate of element location. 0 is topmost position on dashboard.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 132
Field Values Description
Y-coordinate 60 Y-coordinate of element location. 0 is topmost position on dashboard.
Width 145 Width of element (pixels)
Height 25 Height of element (pixels)
Element type 0x03 ELEMENT_TYPE_PROGRESS
Minimum value 0
Maximum value 4
Initial value 0
Color 0x008000 RGB color of progress bar
Eventually, the light sensor data stream is connected to the Progress bar element.
Table 5-14. MSG_CONF_ADD_STREAM_TO_ELEMENT
Field Values Description
Message ID 0x2C
Data length 6
Dashboard ID 0x0000 ID of the light sensor dashboard
Element ID 0x0004 ID of the progress bar element
Stream ID 0x0001 ID of the light sensor data stream
Next, a Graph element is added to the dashboard.
Table 5-15. MSG_CONF_DASHBOARD_ELEMENT, ELEMENT_TYPE_GRAPH
Field Values Description
Token 0xFF
Message ID 0x2B
Data length 53 Depending on element type
Dashboard ID 0x0000 ID of the light sensor dashboard
Element ID 0x0007 Unique ID of graph element
Title color 0xFFFFFF (transmitted as
0xFFFFFFFFFFFF as each 0xFF
character must be transmitted as
0xFFFF, see Message Format)
RGB color of title
Background color 0x000000 RGB color of graph frame
Graph background color 0x000000 RGB color of graph
Title text “Light level\0”
Plot count 1
Xmin 0
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 133
Field Values Description
Xmax 10
Ymin 0
Ymax 5
Mode 0x00 Mouse interaction OFF
Fit graph to right edge of canvas
OFF
And the light sensor data stream is connected to the Graph.
Table 5-16. MSG_CONF_ADD_STREAM_TO_ELEMENT
Field Values Description
Message ID 0x2C
Data length 6
Dashboard ID 0x0000 ID of the light sensor dashboard
Element ID 0x0007 ID of the graph element
Stream ID 0x0001 ID of the light sensor data stream
A separate stream is set up to signal Night mode.
Table 5-17. MSG_CONF_STREAM
Field Values Description
Token 0xFF
Message ID 0x20
Data length 16
ID 0x0029 ID of the Night mode stream
Type 2 Stream type uint_8
Mode 2 Out from target
State 0 Stream state ON
Label “Night Mode\0” Label of the data stream
A Signal element is added to the dashboard for the Night mode signal.
Table 5-18. MSG_CONF_DASHBOARD_ELEMENT, ELEMENT_TYPE_SIGNAL
Field Values Description
Token 0xFF
Message ID 0x2B
Data length 22 Depending on element type
Dashboard ID 0x0000 ID of the light sensor dashboard
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 134
Field Values Description
Element ID 0x0005 Unique ID of the signal element
Z-Index 0 Order index, 0 places the element the farthest to the
back
X-coordinate 140 X-coordinate of element location. 0 is topmost
position on dashboard.
Y-coordinate 100 Y-coordinate of element location. 0 is topmost
position on dashboard.
Width 25 Width of element (pixels)
Height 25 Height of element (pixels)
Element type 0x04 ELEMENT_TYPE_SIGNAL
On transparency 255 (transmitted as 0xFFFF
as each 0xFF character must
be transmitted as 0xFFFF, see
Message Format)
On color 0x008000 RGB color for ON state
Off transparency 255 (transmitted as 0xFFFF
as each 0xFF character must
be transmitted as 0xFFFF, see
Message Format)
Off color 0x000000 RGB color for OFF state
And the Night mode stream is connected to the Signal element.
Table 5-19. MSG_CONF_ADD_STREAM_TO_ELEMENT
Field Values Description
Message ID 0x2C
Data length 6
Dashboard ID 0x0000 ID of the light sensor dashboard
Element ID 0x0005 ID of the signal element
Stream ID 0x0029 ID of the night mode stream
Next, a incoming stream (in to target) is set up to transfer the Button status to the target.
Table 5-20. MSG_CONF_STREAM
Field Values Description
Token 0xFF
Message ID 0x20
Data length 16
ID 0x0030 ID of the button stream
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 135
Field Values Description
Type 2 Stream type uint_8
Mode 0 In to target
State 0 Stream state ON
Label “LED Toggle\0” Label of the stream
A Button is added to the dashboard to toggle the target LED.
Table 5-21. MSG_CONF_DASHBOARD_ELEMENT, ELEMENT_TYPE_BUTTON
Field Values Description
Token 0xFF
Message ID 0x2B
Data length 26 Depending on element type
Dashboard ID 0x0000 ID of the light sensor dashboard
Element ID 0x0006 Unique ID of the signal element
Z-Index 0 Order index, 0 places the element the farthest to the back
X-coordinate 110 X-coordinate of element location. 0 is topmost position on
dashboard.
Y-coordinate 230 Y-coordinate of element location. 0 is topmost position on
dashboard.
Width 75 Width of element (pixels)
Height 50 Height of element (pixels)
Element type 0x01 ELEMENT_TYPE_BUTTON
Font size 10
Button text “LED Toggle\0”
Toggle button 0x00 = Normal button
0x01 = Toggle button
Normal button
And the button stream is connected to the Button element.
Table 5-22. MSG_CONF_ADD_STREAM_TO_ELEMENT
Field Values Description
Message ID 0x2C
Data length 6
Dashboard ID 0x0000 ID of the light sensor dashboard
Element ID 0x0006 ID of the button element
Stream ID 0x0030 ID of the button stream
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 136
Control Dashboard
The ADP example sets up a dashboard to control the ADC. The Control dashboard will look something
like the screenshot below.
Notice: The appearance of screenshots will vary with operating system version and
configuration.
The Control dashboard is configured by the messages detailed in the tables below.
First, the dashboard itself is set up:
Table 5-23. MSG_CONF_DASHBOARD
Field Values Description
Token 0xFF
Message ID 0x2A
Data length 25
ID 0x0001 Dashboard ID
Label “Control Dashboard\0” Dashboard label
Background color 0xFFFFFF (transmitted as 0xFFFFFFFFFFFF as
each 0xFF character must be transmitted as
0xFFFF, see Message Format)
Background color of dashboard
Height 150 Height (in pixels) of dashboard
Next, a few labels are added to the dashboard.
Table 5-24. MSG_CONF_DASHBOARD_ELEMENT, ELEMENT_TYPE_LABEL
Field Values Description
Token 0xFF
Message ID 0x2B
Data length 45
Dashboard ID 0x0001 ID of control dashboard
Element ID 0x0008 Unique ID of label element
Z-Index 0 Order index, 0 places the element the
farthest to the back
X-coordinate 5 X-coordinate of element location. 0 is
topmost position on dashboard.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 137
Field Values Description
Y-coordinate 20 Y-coordinate of element location. 0 is
topmost position on dashboard.
Width 128 Width of element (pixels)
Height 25 Height of element (pixels)
Element type 0x00 ELEMENT_TYPE_LABEL
Font size 14
Attribute 0x01 Bold = ON, Italic = OFF
Horizontal alignment 0 Left
Vertical alignment 1 Center
Background
transparency
0
Background color 0xFFFFFF (transmitted as
0xFFFFFFFFFFFF as each 0xFF
character must be transmitted as
0xFFFF, see Message Format)
RGB color of background
Foreground
transparency
255 (transmitted as 0xFFFF as
each 0xFF character must be
transmitted as 0xFFFF, see
Message Format)
Foreground color 0x000000 RGB color of background
Label text “Hysteresis Values\0”
Table 5-25. MSG_CONF_DASHBOARD_ELEMENT, ELEMENT_TYPE_LABEL
Field Values Description
Token 0xFF
Message ID 0x2B
Data length 31
Dashboard ID 0x0001 ID of control dashboard
Element ID 0x000A Unique ID of label element
Z-Index 0 Order index, 0 places the element the
farthest to the back
X-coordinate 25 X-coordinate of element location. 0 is
topmost position on dashboard.
Y-coordinate 100 Y-coordinate of element location. 0 is
topmost position on dashboard.
Width 30 Width of element (pixels)
Height 25 Height of element (pixels)
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 138
Field Values Description
Element type 0x00 ELEMENT_TYPE_LABEL
Font size 14
Attribute 0x02 Bold = OFF, Italic = ON
Horizontal alignment 0 Left
Vertical alignment 1 Center
Background
transparency
0
Background color 0xFFFFFF (transmitted as
0xFFFFFFFFFFFF as each
0xFF character must be
transmitted as 0xFFFF, see
Message Format)
RGB color of background
Foreground
transparency
255 (transmitted as 0xFFFF as
each 0xFF character must be
transmitted as 0xFFFF, see
Message Format)
Foreground color 0x000000 RGB color of background
Label text “High\0”
Table 5-26. MSG_CONF_DASHBOARD_ELEMENT, ELEMENT_TYPE_LABEL
Field Values Description
Token 0xFF
Message ID 0x2B
Data length 30
Dashboard ID 0x0001 ID of control dashboard
Element ID 0x0009 Unique ID of label element
Z-Index 0 Order index, 0 places the element the
farthest to the back
X-coordinate 25 X-coordinate of element location. 0 is
topmost position on dashboard.
Y-coordinate 60 Y-coordinate of element location. 0 is topmost
position on dashboard.
Width 30 Width of element (pixels)
Height 25 Height of element (pixels)
Element type 0x00 ELEMENT_TYPE_LABEL
Font size 14
Attribute 0x02 Bold = OFF, Italic = ON
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 139
Field Values Description
Horizontal alignment 0 Left
Vertical alignment 1 Center
Background
transparency
0
Background color 0xFFFFFF (transmitted as
0xFFFFFFFFFFFF as each
0xFF character must be
transmitted as 0xFFFF, see
Message Format)
RGB color of background
Foreground
transparency
255
Foreground color 0x000000 RGB color of background
Label text “Low\0”
Table 5-27. MSG_CONF_DASHBOARD_ELEMENT, ELEMENT_TYPE_LABEL
Field Values Description
Token 0xFF
Message ID 0x2B
Data length 44
Dashboard ID 0x0001 ID of control dashboard
Element ID 0x000B Unique ID of label element
Z-Index 0 Order index, 0 places the element the
farthest to the back
X-coordinate 350 X-coordinate of element location. 0 is
topmost position on dashboard.
Y-coordinate 20 Y-coordinate of element location. 0 is
topmost position on dashboard.
Width 130 Width of element (pixels)
Height 25 Height of element (pixels)
Element type 0x00 ELEMENT_TYPE_LABEL
Font size 14
Attribute 0x01 Bold = ON, Italic = OFF
Horizontal alignment 0 Left
Vertical alignment 1 Center
Background
transparency
0
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 140
Field Values Description
Background color 0xFFFFFF (transmitted as
0xFFFFFFFFFFFF as each 0xFF
character must be transmitted as
0xFFFF, see Message Format)
RGB color of background
Foreground
transparency
255 (transmitted as 0xFFFF as
each 0xFF character must be
transmitted as 0xFFFF, see
Message Format)
Foreground color 0x000000 RGB color of background
Label text “ADC Sample Value\0”
Next, a stream is set up to set the high value of the hysteresis.
Table 5-28. MSG_CONF_STREAM
Field Values Description
Token 0xFF
Message ID 0x20
Data length 16
ID 0x0010 ID of the hysteresis high value stream
Type 4 Stream type uint_16
Mode 0 In to target
State 0 Stream state ON
Label “Hyst. High\0” Label of the data stream
A Slider is added to be able to adjust the high value of the hysteresis from the dashboard.
Table 5-29. MSG_CONF_DASHBOARD_ELEMENT, ELEMENT_TYPE_SLIDER
Field Values Description
Token 0xFF
Message ID 0x2B
Data length 26
Dashboard ID 0x0001 ID of the control dashboard
Element ID 0x000D Unique ID of the slider element
Z-Index 0 Order index, 0 places the element the farthest to the back
X-coordinate 75 X-coordinate of element location. 0 is topmost position on dashboard.
Y-coordinate 100 Y-coordinate of element location. 0 is topmost position on dashboard.
Width 156 Width of element (pixels)
Height 25 Height of element (pixels)
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 141
Field Values Description
Element type 0x02 ELEMENT_TYPE_SLIDER
Minimum value 2500
Maximum value 4000
Initial value 3000
And the hysteresis high value stream is connected to the Slider element.
Table 5-30. MSG_CONF_ADD_STREAM_TO_ELEMENT
Field Values Description
Message ID 0x2C
Data length 6
Dashboard ID 0x0001 ID of the control dashboard
Element ID 0x000D ID of the hysteresis high slider element
Stream ID 0x0010 ID of the hysteresis high stream
A stream for hysteresis low values is created and added to a Slider element in the same way as for the
hysteresis high value above.
Table 5-31. MSG_CONF_STREAM
Field Values Description
Token 0xFF
Message ID 0x20
Data length 15
ID 0x0011 ID of the hysteresis low value stream
Type 4 Stream type uint_16
Mode 0 In to target
State 0 Stream state ON
Label “Hyst. Low\0” Label of the data stream
Table 5-32. MSG_CONF_DASHBOARD_ELEMENT, ELEMENT_TYPE_SLIDER
Field Values Description
Token 0xFF
Message ID 0x2B
Data length 26
Dashboard ID 0x0001 ID of the control dashboard
Element ID 0x000C Unique ID of the slider element
Z-Index 0 Order index, 0 places the element the farthest to the back
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 142
Field Values Description
X-coordinate 75 X-coordinate of element location. 0 is topmost position on dashboard.
Y-coordinate 60 Y-coordinate of element location. 0 is topmost position on dashboard.
Width 156 Width of element (pixels)
Height 25 Height of element (pixels)
Element type 0x02 ELEMENT_TYPE_SLIDER
Minimum value 1000
Maximum value 2400
Initial value 2000
Table 5-33. MSG_CONF_ADD_STREAM_TO_ELEMENT
Field Values Description
Message ID 0x2C
Data length 6
Dashboard ID 0x0001 ID of the control dashboard
Element ID 0x000C ID of the hysteresis low slider element
Stream ID 0x0011 ID of the hysteresis low stream
A separate stream for the light sensor ADC values to be fed to the Segment display is set up.
Table 5-34. MSG_CONF_STREAM
Field Values Description
Token 0xFF
Message ID 0x20
Data length 22
ID 0x0002 ID of the adc value stream
Type 4 Stream type uint_16
Mode 2 Out from target
State 0 Stream state ON
Label “Light Sensor ADC\0” Label of the data stream
Next, a Segment display with four segments is added to the dashboard.
Table 5-35. MSG_CONF_DASHBOARD_ELEMENT, ELEMENT_TYPE_SEGMENT
Field Values Description
Token 0xFF
Message ID 0x2B
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 143
Field Values Description
Data length 20
Dashboard ID 0x0001 ID of the control dashboard
Element ID 0x000D Unique ID of the segment display element
Z-Index 0 Order index, 0 places the element the farthest to the
back
X-coordinate 500 X-coordinate of element location. 0 is topmost position
on dashboard.
Y-coordinate 20 Y-coordinate of element location. 0 is topmost position
on dashboard.
Width 150 Width of element (pixels)
Height 50 Height of element (pixels)
Element type 0x05 ELEMENT_TYPE_SEGMENT
Count 4 Four segments
Base 10 Ordinary decimal base
Transparency 0xFF (transmitted as 0xFFFF
as each 0xFF character must
be transmitted as 0xFFFF, see
Message Format)
0 - 255
Color 0xFF0000 (transmitted as
0xFFFF0000 as each 0xFF
character must be transmitted
as 0xFFFF, see Message
Format)
RGB color of display
And the ADC sample value stream is connected to the Segment display.
Table 5-36. MSG_CONF_ADD_STREAM_TO_ELEMENT
Field Values Description
Message ID 0x2C
Data length 6
Dashboard ID 0x0001 ID of the control dashboard
Element ID 0x000D ID of the segment display element
Stream ID 0x0002 ID of the ADC sample data stream
Terminal
The ADP example sets up a terminal module that looks something like the screenshot below.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 144
Notice: The appearance of screenshots will vary with operating system version and
configuration.
The terminal module is configured by the messages detailed in the tables below.
First, a stream is set up to send terminal data to the host computer.
Table 5-37. MSG_CONF_STREAM
Field Values Description
Token 0xFF
Message ID 0x20
Data length 21
ID 0x0000
Type 2 UINT_8 stream
Mode 2 Outgoing stream (out from target)
State 0 Stream state ON
Label “Status messages\0” Label of the data stream
Next, the terminal itself is configured.
Table 5-38. MSG_CONF_TERMINAL
Field Values Description
Token 0xFF
Message ID 0x26
Data length 26
ID 0x0000 ID of terminal
Label “Status terminal\0” Terminal label
Width 80 Number of characters wide
Height 50 Number of lines high
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 145
Field Values Description
Background color 0xFFFFFF (transmitted as 0xFFFFFFFFFFFF as each
0xFF character must be transmitted as 0xFFFF, see
Message Format)
RGB background color
Foreground color 0x008000 RGB foreground color
Finally, the data stream is connected to the terminal module.
Table 5-39. MSG_CONF_ADD_TO_TERMINAL
Field Values Description
Token 0xFF
Message ID 0x27
Data length 27
Terminal ID 0x0000 ID of terminal
Stream ID 0x0000 ID of stream
Mode 0xFF (transmitted as 0xFFFF as each 0xFF
character must be transmitted as 0xFFFF,
see Message Format)
Implicit newline in incoming text = ON
Text color 0x000000 RGB color of the text stream received
Tag text “Status messages\0”
Tag text color 0x000000 RGB color of the tag text
Data Transmission
When the terminal module and the two dashboards have been set up as described in the previous
sections, the ADP example goes into a mode where it is continuously sending data to the host computer
and receiving data from the host computer according to the configured streams. Below are examples of
data messages being transmitted from the ATSAMD21 target to the host computer.
Table 5-40. Light Sensor ADC Stream
Field Values Description
Token 0xFF
Message ID 0x40
Data length 6
Number of streams (N) 1
Stream ID 0x0002 ID of ADC value stream
Num bytes (Xn) 2 Number of bytes from the stream
Stream X data sample M 634 (0x027A) The data of the stream (uint_16)
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 146
Table 5-41. Night Mode Stream
Field Values Description
Token 0xFF
Message ID 0x40
Data length 5
Number of streams (N) 1
Stream ID 0x0029 ID of Night mode stream
Num bytes (Xn) 1 Number of bytes from the stream
Stream X data sample M 0x01 (Bright light, day mode) The data of the stream (uint_8)
When the Night mode changes, the example also changes the background color of the terminal module
by sending another MSG_CONF_TERMINAL.
Table 5-42. MSG_CONF_TERMINAL to update Terminal Background Color to White
Field Values Description
Token 0xFF
Message ID 0x26
Data length 26
ID 0x0000 ID of terminal
Label “Status terminal\0” Terminal label
Width 80 Number of characters wide
Height 50 Number of lines high
Background color 0xFFFFFF RGB background color
Foreground color 0x008000 RGB foreground color
Table 5-43. Status Message Stream
Field Values Description
Token 0xFF
Message ID 0x40
Data length 44
Number of streams (N) 1
Stream ID 0x0000 ID of status message
stream
Num bytes (Xn) 40 Number of bytes from the
stream
Stream X data samples “It's bright again... Entered day mode!\r\n” The data of the stream
(uint_8)
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 147
Field Values Description
{0x49, 0x74, 0x27, 0x73, 0x20, 0x62, 0x72, 0x69,
0x67, 0x68, 0x74, 0x20, 0x61, 0x67, 0x61, 0x69,
0x6E, 0x2E, 0x2E, 0x2E, 0x20, 0x45, 0x6E, 0x74,
0x65, 0x72, 0x65, 0x64, 0x20, 0x64, 0x61, 0x79,
0x20, 0x6D, 0x6F, 0x64, 0x65, 0x21, 0x0D, 0x0A}
Examples of data messages for the various streams from the computer to the target can be found in the
tables below.
Table 5-44. Hysteresis Low Value Stream Data Message
Field Values Description
Token 0xFF
Message ID 0x14 MSG_RES_DATA
Data length 5
Stream ID 0x0011 ID of hysteresis low value stream
Bytes sent 2 Number of bytes in the data payload
Data bytes 0x07C6 The data (uint_16)
Table 5-45. Hysteresis High Value Stream Data Message
Field Values Description
Token 0xFF
Message ID 0x14 MSG_RES_DATA
Data length 5
Stream ID 0x0002 ID of hysteresis high value stream
Bytes sent 2 Number of bytes in the data payload
Data bytes 0x0BB7 The data (uint_16)
Table 5-46. LED Toggle Stream Data Message
Field Values Description
Token 0xFF
Message ID 0x14 MSG_RES_DATA
Data length 5
Stream ID 0x0030 ID of LED toggle stream
Bytes sent 1 Number of bytes in the data payload
Data bytes 0x00 The data (uint_8)
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 148
5.2.3 Message Flow
The target is the master in the system, whereas the host computer is the slave. The target will initiate
communication, and the computer will respond. However, the computer will transmit data to the target
MCU as soon as data is generated on the computer.
Before any data can be exchanged between the target and the computer, the connection must be
established using handshake messages.
5.2.4 Message Format
The ADP protocol uses a common message format for both directions of communication and all message
types.
Table 5-47. ADP Message Format
Field Size Values Description
Token 1 byte 0xFF Start token for ADP data
Message ID 1 byte 0x00-0xFE Identifies the type of message being sent
Data length 2 bytes 0x0000-0xFFFF Length of data packet (bytes)
Data N bytes ... Data content of the message
Token
The value 0xFF followed by a value other than 0xFF (0xFF is not a valid Message ID), is used to indicate
the start of the message. This means that 0xFF must be sent between each message.
If the value 0xFF is to be transmitted as part of data or data length, a new 0xFF should be inserted after
it. When receiving messages, two 0xFF should be decoded as a single 0xFF. The extra 0xFF bytes are
not contributing to the Data length field. For example, a color field with the value 0xFFFFFF will have to
be transmitted as 0xFFFFFFFFFFFF, but only contributes to the data length by three bytes.
The value 0xFF is not allowed to be used as a message ID. When polling for data over SPI, the 0xFF
token must be used as a dummy character to not trigger a command unintentionally.
Endianness
All message data is ordered using little endian.
5.2.5 Message Types
There are three main message types; Request messages, Configuration messages, and Data messages.
5.2.5.1 Request Messages
Request messages are used by the target to request information/status from the host PC. These
messages are pre-fixed with MSG_REQ. The PC should always respond with the corresponding
response message, pre-fixed MSG_RES.
Table 5-48. Request Messages and Responses
Message Type ID Description
MSG_REQ_HANDSHAKE 0x00 Request handshake
MSG_RES_HANDSHAKE 0x10 Respond to handshake
MSG_REQ_STATUS 0x02 Request status from PC
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 149
Message Type ID Description
MSG_RES_STATUS 0x12 Respond to status
MSG_RES_DATA 0x14 Raw data from PC to target
5.2.5.2 Configuration Messages
Used by target to send configuration settings to the PC. These messages are pre-fixed with MSG_CONF.
The PC should respond to these messages with an acknowledge message (MSG_ACK).
Table 5-49. Configuration Messages, Target to PC
Message type ID Description
MSG_CONF_STREAM 0x20 Create a new stream
Reserved 0x21 Reserved for future use
MSG_CONF_GRAPH 0x22 Create new graph or reconfigure
existing one
MSG_CONF_ADD_STREAM_T
O_AXIS
0x23 Add stream to axis in graph
MSG_CONF_CURSOR_TO_GR
APH
0x24 Add parameter cursor to graph
Reserved 0x25 Reserved for future use
MSG_CONF_TERMINAL 0x26 Create new terminal or
reconfigure existing one
MSG_CONF_ADD_TO_TERMIN
AL
0x27 Add stream to terminal
MSG_CONF_INFO 0x28 Info about the application
MSG_CONF_AXIS 0x29 Create new axis or reconfigure
existing one
MSG_CONF_DASHBOARD 0x2A Add dashboard container
MSG_CONF_DASHBOARD_EL
EMENT
0x2B Add element to dashboard
container
MSG_CONF_ADD_STREAM_T
O_ELEMENT
0x2C Tie an already configured stream
to an already configured
dashboard element.
Table 5-50. Configuration Messages, PC to Target
Message type ID Description
MSG_CONF_ACK 0x30 Status of last received
configuration message
5.2.5.3 Data Messages
Used by a target to send data to the PC. Prefixed with MSG_DATA. These messages should not be
responded too.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 150
Table 5-51. Data Messages
Message Type ID Description
MSG_DATA_STREAM 0x40 Send data from one or more
streams
5.2.5.4 Request Message Details
MSG_REQ_HANDSHAKE
Before any data can be exchanged between the target and the PC, the connection must be established
using handshake messages.
Important: To make sure the handshake message is detected by the Data Visualizer during
Auto-Detection, the handshake message should be sent at least twice per second.
Field Size Values Description
Message ID 1 byte 0x00
Data length 2 bytes 10
Protocol version 1 byte 0x01-0xFF Version of protocol on
target
Options 1 byte 0xXX Reserved for future use
Token 8 bytes {0x58, 0x99, 0xAB,
0xC9, 0x0F, 0xE2, 0xF7,
0xAA}
Token used to verify
ADP protocol
MSG_RES_HANDSHAKE
The PC should respond to a handshake request from the target with this packet. The PC should always
communicate with the target using the protocol version stated in the targets handshake request message.
If the PC for some reason is unable to do this, the handshake request must be rejected.
Field Size Values Description
Message ID 1 byte 0x10
Data length 2 bytes 1
Handshake status 1 byte 0x00: Handshake
accepted
0x01: Handshake
rejected. Invalid protocol
version.
0x02: Handshake
rejected. Other reason.
MSG_REQ_STATUS
Message used by target to request status from PC. It is good practice to ask for status each time a new
configuration message is sent. While sending raw data, it is good practice to ask for status... occasionally.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 151
Field Size Values Description
Message ID 1 byte 0x02
Data length 2 bytes 0
This message has no data fields.
MSG_RES_STATUS
Status message from PC to target. Once a status is requested from the target and this packet is sent, all
status flags should be cleared on the PC.
Field Size Values Description
Message ID 1 byte 0x12
Data length 2 bytes 2
Status code 2 bytes 0x0000 Reserved for future use
MSG_RES_DATA
Data packet from PC to target MCU. This message can come asynchronously from the PC (i.e., without
the target MCU having requested it).
Field Size Values Description
Message ID 1 byte 0x14
Data length 2 bytes 3 + Data bytes
Stream ID 2 bytes ID of stream
Bytes sent 1 byte Number of bytes in the
data payload. If the
target has requested
data from an unknown
stream, or if the stream
has no data to send, this
field should be set to 0
and the appropriate
status flag should be
set.
Data bytes N bytes The data
5.2.5.5 Configuration Message Details
MSG_CONF_STREAM
Used to create a new stream. The type of the stream can be either EVENT, TEXT, or DATA. Each stream
must be given a unique ID.
Field Size Values Description
Message ID 1 byte 0x20
Data length 2 bytes 5 + label length (N) +
parameter length (M)
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 152
Field Size Values Description
ID 2 bytes 0x0000-0xFFFF ID of stream
Type 1 byte STREAM_DATA_TYPE Stream type
Mode 1 byte 0 = Incoming (normal)
1 = Incoming (single
value)
2 = Outgoing
Stream mode/direction
Direction is defined seen
from target
State 1 byte 0 = ON
1= OFF
Stream state
Label N bytes Null-terminated string Label of the data stream
Parameters M bytes Byte array Parameters specific to
stream type
Table 5-52. STREAM_DATA_TYPE
Type code Data type Parameters Data size
0 EVENT None 0 bytes
1 STRING None N bytes
2 UINT_8 None 1 byte
3 INT_8 None 1 byte
4 UINT_16 None 2 bytes
5 INT_16 None 2 bytes
6 UINT_32 None 4 bytes
7 INT_32 None 4 bytes
8 XY_8 None 2 bytes
9 XY_16 None 4 bytes
10 XY_32 None 8 bytes
11 BOOL None 1 byte
12 Float None 4 bytes
13 Double None 8 bytes
20 Grid Base data type (1 byte,
e.g. 6 for UINT_32)
Width of grid (1 byte)
Depth of grid (1 byte)
Size of base data type *
Width * Depth
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 153
The XY data types are combos of X and Y coordinates. If the format is XY_8 the data will contain one
byte of X-coordinate and one byte of Y-coordinate. For XY_16 the data will contain two bytes of Xcoordinate
and two bytes of Y-coordinates and for XY_32 each coordinate will be four bytes long.
MSG_CONF_GRAPH
Used to create a new or reconfigure an existing graph view. The graph view requires an unique ID.
Values for range, labels, and background color can also be set.
Field Size Values Description
Message ID 1 byte 0x22
Data length 2 bytes 23 + label length (N) +
Xlabel length (M)
ID 2 bytes 0x0000-0xFFFF ID of new graph
Label N bytes Null-terminated string Graph label
Xmin 4 bytes Range Xmin value
Xmax 4 bytes Range Xmax value
Xlabel M bytes Null-terminated string X label
Xscale numerator 4 bytes X range scale value. Set
to 0 to enable autorange.
Xscale denumerator 4 bytes X range scale value. Set
to 0 to enable autorange.
Scale mode 1 byte 0 = scaling off
1 = auto-scale
Vertical scaling
Background color 3 bytes 0xRRGGBB RGB background color
Scroll mode 1 byte 0 = no scrolling
1 = stepping
2 = scroll
3 = circular/sweep
Horizontal scrolling
MSG_CONF_ADD_STREAM_TO_AXIS
Used to add a stream to the specified graph view.
Field Size Values Description
Message ID 1 byte 0x23
Data length 2 bytes 32
Graph ID 2 bytes 0x0000-0xFFFF ID of graph
Axis ID 2 bytes 0x0000-0xFFFF ID of axis
Stream ID 2 bytes 0x0000-0xFFFF ID of stream
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 154
Field Size Values Description
Sample rate numerator 4 bytes Sample rate of stream,
set to 0 if not applicable
Sample rate
denominator
4 bytes Sample rate of stream,
set to 0 in not applicable
Yscale numerator 4 bytes Y range scale value. Set
to 0 to enable autorange.
Yscale denumerator 4 bytes Y range scale value. Set
to 0 to enable autorange.
Yoffset 4 bytes Offset of values
Transparency 1 byte 0 - 255 Adjust the transparency
Mode 1 byte For graphs:
bit 0 = line ON/OFF
bit 1 = points
ON/OFF
For text:
0 = flag
1 = text
Thickness 1 byte 0 - 255 Thickness of line
Color 3 bytes 0xRRGGBB RGB color of line
MSG_CONF_CURSOR_TO_GRAPH
Used to add a parameter cursor to a graph.
Field Size Values Description
Message ID 1 byte 0x24
Data length 2 bytes 35 + label length (N)
Stream ID 2 bytes 0x0000-0xFFFF ID of stream
Graph ID 2 bytes 0x0000-0xFFFF ID of graph
Axis ID 2 bytes 0x0000-0xFFFF ID of axis
Label N bytes Null-terminated string Label of cursor
Thickness 1 byte 0 - 255 Thickness of line
Color 3 bytes 0xRRGGBB RGB color of cursor
Initial value 4 bytes Starting point of cursor
Minimum 4 bytes Minimum allowed value
Maximum 4 byte Maximum allowed value
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 155
Field Size Values Description
Scale numerator 4 bytes Numerator of scaling
value
Scale denominator 4 bytes Denominator of scaling
value
Scale offset 4 bytes Offset of scaling value
Style 1 byte 0xXX Reserved for future use
MSG_CONF_TERMINAL
Used to create a new or reconfigure an existing terminal. The terminal requires a unique ID. Values for
label and background color must also be set.
Field Size Values Description
Message ID 1 byte 0x26
Data length 2 bytes 10 + label length (N)
ID 2 bytes 0x0000-0xFFFF ID of terminal
Label N bytes Null-terminated string Terminal label
Width 1 byte 0 - 255 Number of characters
wide
Height 1 byte 0 - 255 Number of lines high
Background color 3 bytes 0xRRGGBB RGB background color
Foreground color 3 byte 0xRRGGBB RGB foreground color
MSG_CONF_ADD_TO_TERMINAL
Used to add a stream to the specified terminal.
Field Size Values Description
Message ID 1 byte 0x27
Data length 2 bytes 11 + tag length (N)
Terminal ID 2 bytes 0x0000-0xFFFF ID of terminal
Stream ID 2 bytes 0x0000-0xFFFF ID of stream
Mode 1 byte 0bXXXNXXXX N = implicit newline
in incoming text
Text color 3 bytes 0xRRGGBB RGB color of the text
stream received
Tag text N bytes Null-terminated string Descriptive tag
Tag text color 3 bytes 0xRRGGBB RGB color of the tag text
MSG_CONF_INFO
Used to send info about the application. For example, a text string describing the example application.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 156
Field Size Values Description
Message ID 1 byte 0x28
Data length 2 bytes Title length (N) +
Description length (M)
Title N bytes Null-terminated string Application title
Description M bytes Null-terminated string Short description of the
application
MSG_CONF_AXIS
Used to create a new or reconfigure an existing axis of a graph view. The axis requires a unique ID.
Values for range, label, and axis color must also be set.
Field Size Values Description
Message ID 1 byte 0x29
Data length 2 bytes 24 + label length (N)
Axis ID 2 bytes 0x0000-0xFFFF ID of new axis
Graph ID 2 bytes 0x0000-0xFFFF ID of graph containing
the axis
Label N bytes Null-terminated string Axis label
Ymin 4 bytes Range Ymin value
Ymax 4 bytes Range Ymax value
Yscale numerator 4 bytes Y range scale value. Set
to 0 to enable autorange.
Yscale denominator 4 bytes Y range scale value. Set
to 0 to enable autorange.
Scale mode 1 byte 0 = scaling off
1 = auto-scale
Vertical scaling
Axis color 3 bytes 0xRRGGBB RGB color
MSG_CONF_DASHBOARD
Add a dashboard container where dashboard elements can be placed.
Field Size Values Description
Message ID 1 byte 0x2A
Data length 2 bytes 7 + label length (N)
ID 2 bytes 0x0000-0xFFFF Dashboard ID
Label N bytes Null-terminated string Dashboard label
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 157
Field Size Values Description
Background color 3 bytes 0xRRGGBB Background color of
dashboard
Height 2 bytes Height (in pixels) of
dashboard
MSG_CONF_DASHBOARD_ELEMENT
Configure a dashboard element and add it to the specified dashboard. The table shows common fields for
all dashboard element types. Additional fields must be added, depending on element type. See below.
Field Size Values Description
Message ID 1 byte 0x2B
Data length 2 bytes 14 + element specific
length
Depending on element
type
Dashboard ID 2 bytes 0x0000-0xFFFF ID of dashboard to add
the element to
Element ID 2 bytes 0x0000-0xFFFF Unique ID of element
Z-Index 1 byte Order index, 0 places
the element the farthest
to the back
X-coordinate 2 bytes Coordinate value in
pixels
X-coordinate of element
location. 0 is topmost
position on dashboard.
Y-coordinate 2 bytes Coordinate value in
pixels
Y-coordinate of element
location. 0 is topmost
position on dashboard.
Width 2 bytes Width in pixels Width of element
Height 2 bytes Height in pixels Height of element
Element type 1 byte ELEMENT_TYPE See each element type
below
ELEMENT_TYPE_LABEL
The tables below describe the ELEMENT_TYPE_LABEL specific parameters and additional fields for the
MSG_CONF_DASHBOARD_ELEMENT message.
Table 5-53. ELEMENT_TYPE_LABEL Parameters
Parameter Value
ELEMENT_TYPE 0x00
Total data length of MSG_CONF_DASHBOARD_ELEMENT when using
ELEMENT_TYPE_LABEL
26 + length of default text (N)
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 158
Table 5-54. Additional Data Fields to MSG_CONF_DASHBOARD_ELEMENT
Field Size Values Description
Font size 1 byte 1-255
Attribute 1 byte Bit 0: Bold ON/OFF
Bit 1: Italic ON/OFF
Horizontal alignment 1 byte 0 = Left
1 = Center
2 = Right
Vertical alignment 1 byte 0 = Top
1 = Center
2 = Bottom
Background transparency 1 byte 0 - 255
Background color 3 bytes 0xRRGGBB RGB color of background
Foreground transparency 1 byte 0 - 255
Foreground color 3 bytes 0xRRGGBB RGB color of background
Label text N bytes Null-terminated string max. 100 bytes
Example
The picture below shows an example of two labels with the corresponding parameters given in the tables
below the picture.
Notice: The appearance of elements will vary with operating system version and configuration.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 159
Table 5-55. Label1
Field Value
Z-index 0
X-coordinate 30
Y-coordinate 30
Width 200
Height 100
Element type 0x00
Font size 16
Attribute 0x01
Horizontal alignment 0
Vertical alignment 0
Background transparency 255
Background color 0x64FF64
Foreground transparency 255
Foreground color 0x000000
Label text “Label1\0”
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 160
Table 5-56. Label2
Field Value
Z-index 1
X-coordinate 90
Y-coordinate 70
Width 75
Height 25
Element type 0x00
Font size 12
Attribute 0x00
Horizontal alignment 1
Vertical alignment 1
Background transparency 100
Background color 0x646464
Foreground transparency 255
Foreground color 0x7C0000
Label text “Label2\0”
ELEMENT_TYPE_BUTTON
The tables below describe the ELEMENT_TYPE_BUTTON specific parameters and additional fields for
the MSG_CONF_DASHBOARD_ELEMENT message.
Table 5-57. ELEMENT_TYPE_BUTTON Specific Parameters
Parameter Value
ELEMENT_TYPE 0x01
Total data length of MSG_CONF_DASHBOARD_ELEMENT when using
ELEMENT_TYPE_BUTTON
16 + length of button text (N)
Table 5-58. Additional Data Fields to MSG_CONF_DASHBOARD_ELEMENT for
ELEMENT_TYPE_BUTTON
Field Size Values Description
Font size 1 byte 0-255
Button text N bytes Null-terminated string, max. 20
bytes
For toggle button text is selected by '/'
delimited text (/)
Toggle button 1 byte 0x00 = Normal button
0x01 = Toggle button
Change mode to toggle button. Button text is
selected by '/' delimited text field.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 161
Example
The picture below shows an example of two buttons; one normal button and one toggle button. The
element data fields for the example are shown in the tables below the picture.
Notice: The appearance of elements will vary with operating system version and configuration.
Table 5-59. Button
Field Value
Z-index 0
X-coordinate 30
Y-coordinate 30
Width 75
Height 25
Element type 0x01
Font size 12
Button text “Button\0”
Toggle button 0x00
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 162
Table 5-60. Toggle Button
Field Value
Z-index 0
X-coordinate 30
Y-coordinate 70
Width 120
Height 25
Element type 0x01
Font size 12
Button text “ON/OFF\0”
Toggle button 0x01
ELEMENT_TYPE_SLIDER
The tables below describe the ELEMENT_TYPE_SLIDER specific parameters and additional fields for
the MSG_CONF_DASHBOARD_ELEMENT message.
Table 5-61. ELEMENT_TYPE_SLIDER Specific Parameters
Parameter Value
ELEMENT_TYPE 0x02
Total data length of MSG_CONF_DASHBOARD_ELEMENT when using
ELEMENT_TYPE_SLIDER
26
Table 5-62. Additional Data Fields to MSG_CONF_DASHBOARD_ELEMENT for
ELEMENT_TYPE_SLIDER
Field Size Values Description
Minimum value 4 bytes
Maximum value 4 bytes
Initial value 4 byte
Example
The picture below shows an example of a slider element with a range from 0 to 50 and an initial value of
20. The corresponding element data fields are given in the table below the picture.
Notice: The appearance of elements will vary with operating system version and configuration.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 163
Table 5-63. Slider
Field Value
Z-index 0
X-coordinate 20
Y-coordinate 20
Width 200
Height 30
Element type 0x02
Minimum value 0
Maximum value 50
Initial value 20
ELEMENT_TYPE_PROGRESS
The tables below describe the ELEMENT_TYPE_PROGRESS specific parameters and additional fields
for the MSG_CONF_DASHBOARD_ELEMENT message.
Table 5-64. ELEMENT_TYPE_PROGRESS Specific Parameters
Parameter Value
ELEMENT_TYPE 0x03
Total data length of MSG_CONF_DASHBOARD_ELEMENT when using
ELEMENT_TYPE_PROGRESS
29
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 164
Table 5-65. Additional Data Fields to MSG_CONF_DASHBOARD_ELEMENT for
ELEMENT_TYPE_PROGRESS
Field Size Values Description
Minimum value 4 bytes
Maximum value 4 bytes
Initial value 4 byte
Color 3 bytes 0xRRGGBB RGB color of progress bar
Example
The picture below shows an example of a progress bar element. The corresponding element data fields
are given in the table below the picture.
Notice: The appearance of elements will vary with operating system version and configuration.
Table 5-66. Progress Bar
Field Value
Z-index 0
X-coordinate 10
Y-coordinate 10
Width 100
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 165
Field Value
Height 30
Element type 0x03
Minimum value 0
Maximum value 100
Initial value 50
Color 0x01D328
ELEMENT_TYPE_SIGNAL
The tables below describe the ELEMENT_TYPE_SIGNAL specific parameters and additional fields for
the MSG_CONF_DASHBOARD_ELEMENT message.
Table 5-67. ELEMENT_TYPE_SIGNAL Specific Parameters
Parameter Value
ELEMENT_TYPE 0x04
Total data length of MSG_CONF_DASHBOARD_ELEMENT when using
ELEMENT_TYPE_SIGNAL
22
Table 5-68. Additional Data Fields to MSG_CONF_DASHBOARD_ELEMENT for
ELEMENT_TYPE_SIGNAL
Field Size Values Description
On transparency 1 byte 0 - 255
On color 3 bytes 0xRRGGBB RGB color for on state
Off transparency 1 byte
Off color 3 bytes 0xRRGGBB RGB color for off state
Example
The picture below shows an example of a signal element. The corresponding element data fields are
given in the table below the picture.
Notice: The appearance of elements will vary with operating system version and configuration.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 166
Table 5-69. Signal
Field Value
Z-index 0
X-coordinate 20
Y-coordinate 20
Width 50
Height 50
Element type 0x04
On transparency 255
On color 0x00FF00
Off transparency 255
Off Color 0xFF0000
ELEMENT_TYPE_SEGMENT
The tables below describe the ELEMENT_TYPE_SEGMENT specific parameters and additional fields for
the MSG_CONF_DASHBOARD_ELEMENT message.
Table 5-70. ELEMENT_TYPE_SEGMENT Specific Parameters
Parameter Value
ELEMENT_TYPE 0x05
Total data length of MSG_CONF_DASHBOARD_ELEMENT when using
ELEMENT_TYPE_SEGMENT
20
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 167
Table 5-71. Additional Data Fields to MSG_CONF_DASHBOARD_ELEMENT for
ELEMENT_TYPE_SEGMENT
Field Size Values Description
Count 1 byte 1-20 Number of displays
Base 1 byte 2-16 Numeric base
Transparency 1 byte 0 - 255
Color 3 bytes 0xRRGGBB RGB color of display
Example
The picture below shows an example of a segment element with two digits. The corresponding element
data fields are given in the table below the picture.
Notice: The appearance of elements will vary with operating system version and configuration.
Table 5-72. Signal
Field Value
Z-index 0
X-coordinate 30
Y-coordinate 30
Width 174
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 168
Field Value
Height 150
Element type 0x05
Count 2
Base 10
Transparency 255
Color 0xFD0000
ELEMENT_TYPE_GRAPH
The tables below describe the ELEMENT_TYPE_GRAPH specific parameters and additional fields for
the MSG_CONF_DASHBOARD_ELEMENT message. This element generates a graph that visualizes the
data from the target. There will be one input stream for each plot.
Table 5-73. ELEMENT_TYPE_GRAPH Specific Parameters
Parameter Value
ELEMENT_TYPE 0x06
Total data length of MSG_CONF_DASHBOARD_ELEMENT when using
ELEMENT_TYPE_GRAPH
41 + length of title (N)
Table 5-74. Additional Data Fields to MSG_CONF_DASHBOARD_ELEMENT for
ELEMENT_TYPE_GRAPH
Field Size Values Description
Title color 3 bytes 0xRRGGBB RGB color of title
Background color 3 bytes 0xRRGGBB RGB color of graph frame
Graph background
color
3 bytes 0xRRGGBB RGB color of graph
Title text N bytes Null-terminated string max. 20
bytes
Plot count 1 byte 1-10 Number of plots
Xmin 4 bytes Floating point, seconds Will be converted to
: format
Xmax 4 bytes Floating point, seconds Will be converted to
: format
Ymin 4 bytes Floating point
Ymax 4 bytes Floating point
Mode 1 byte Bit 0: Mouse interaction
ON/OFF
Bit 1: Fit graph to right edge
of canvas
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 169
Example
The picture below shows an example of a graph element with tree input plot inputs. The element data
fields for the example is shown in the table below the picture.
Notice: The appearance of elements will vary with operating system version and configuration.
Table 5-75. Graph
Field Value
Z-index 0
X-coordinate 10
Y-coordinate 10
Width 500
Height 250
Element type 0x06
Title color 0xFFFFFF
Background color 0x000000
Graph background color 0x646464
Title text “Graph\0”
Plot count 3
Xmin 0
Xmax 100
Ymin 0
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 170
Field Value
Ymax 2.45
Mode 0x01
ELEMENT_TYPE_NUMERICAL_INPUT
The tables below describe the ELEMENT_TYPE_NUMERICAL_INPUT specific parameters and
additional fields for the MSG_CONF_DASHBOARD_ELEMENT message. This element type is used to
output numerical values to the target from the PC. The element is editable in the dashboard.
Table 5-76. ELEMENT_TYPE_NUMERICAL_INPUT Specific Parameters
Parameter Value
ELEMENT_TYPE 0x07
Total data length of MSG_CONF_DASHBOARD_ELEMENT when using
ELEMENT_TYPE_NUMERICAL_INPUT
26
Table 5-77. Additional Data Fields to MSG_CONF_DASHBOARD_ELEMENT for
ELEMENT_TYPE_NUMERICAL_INPUT
Field Size Values Description
Minimum 4 bytes Signed 32-bit integer
Maximum 4 bytes Signed 32-bit integer
Value 4 bytes Signed 32-bit integer Initial value
Example
The picture below shows an example of a numerical input element with a range of valid values from -100
to 100 and a default value of 30. The element data fields for the example is shown in the table below the
picture.
Notice: The appearance of elements will vary with operating system version and configuration.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 171
Table 5-78. Numerical Input
Field Value
Z-index 0
X-coordinate 20
Y-coordinate 20
Width 50
Height 25
Element type 0x07
Minimum -100
Maximum 100
Value 30
ELEMENT_TYPE_RADIO
The tables below describe the ELEMENT_TYPE_RADIO specific parameters and additional fields for the
MSG_CONF_DASHBOARD_ELEMENT message. This element generates a group of radio buttons
where only one option can be selected. Initially, the first option is selected.
Table 5-79. ELEMENT_TYPE_RADIO Specific Parameters
Parameter Value
ELEMENT_TYPE 0x08
Total data length of MSG_CONF_DASHBOARD_ELEMENT when using
ELEMENT_TYPE_RADIO
17 + length of text fields (N)
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 172
Table 5-80. Additional Data Fields to MSG_CONF_DASHBOARD_ELEMENT for
ELEMENT_TYPE_RADIO
Field Size Values Description
Font size 1 byte 0-100
Number of items 1 byte 1-10
Orientation 1 byte 0 = Horizontal
1 = Vertical
Text fields N bytes Null-terminated string max. 20 bytes '/' separated option list
Example
The picture below shows an example of radio button group with three buttons. The corresponding
element data fields are given in the table below the picture.
Notice: The appearance of elements will vary with operating system version and configuration.
Table 5-81. Radio Button Group
Field Value
Z-index 0
X-coordinate 20
Y-coordinate 20
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 173
Field Value
Width 100
Height 100
Element type 0x08
Font size 16
Number of radio buttons 3
Orientation 1
Text fields “Op 1/Op 2/Op 3\0”
ELEMENT_TYPE_PIE
The tables below describe the ELEMENT_TYPE_PIE specific parameters and additional fields for the
MSG_CONF_DASHBOARD_ELEMENT message. This element generates a pie chart. The size of the
slices are updated based on the data from the target to the PC. There will be one data stream input for
each slice.
Table 5-82. ELEMENT_TYPE_PIE Specific Parameters
Parameter Value
ELEMENT_TYPE 0x09
Total data length of MSG_CONF_DASHBOARD_ELEMENT when using
ELEMENT_TYPE_PIE
21 + length of title (N)
Table 5-83. Additional Data Fields to MSG_CONF_DASHBOARD_ELEMENT for
ELEMENT_TYPE_PIE
Field Size Values Description
Background color 3 bytes 0xRRGGBB RGB color of background
Title color 3 bytes 0xRRGGBB RGB color of title
Title N bytes Null-terminated string max. 20 bytes
Number of slices 1 byte 1-10
Example
The picture below shows an example of a pie element with three slices. The corresponding element data
fields are given in the table below the picture.
Notice: The appearance of elements will vary with operating system version and configuration.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 174
Table 5-84. Numerical Input
Field Value
Z-index 0
X-coordinate 20
Y-coordinate 20
Width 600
Height 400
Element type 0x09
Background color 0xFFFFFF
Title color 0x000000
Title “Pie\0”
Number of slices 3
ELEMENT_TYPE_SURFACE
The tables below describe the ELEMENT_TYPE_SURFACE specific parameters and additional fields for
the MSG_CONF_DASHBOARD_ELEMENT message. This element generates a 3D surface plot that
visualizes the grid of data points from the target. There is one input stream that accepts grid type data.
Table 5-85. ELEMENT_TYPE_SURFACE Specific Parameters
Parameter Value
ELEMENT_TYPE 0x0D
Total data length of MSG_CONF_DASHBOARD_ELEMENT when using
ELEMENT_TYPE_SURFACE
47
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 175
Table 5-86. Additional Data Fields to MSG_CONF_DASHBOARD_ELEMENT for
ELEMENT_TYPE_SURFACE
Field Size Values Description
Fill color 3 bytes 0xRRGGBB RGB color of surface fill
Mesh color 3 bytes 0xRRGGBB RGB color of surface mesh
Background color 4 bytes 0xAARRGGBB RGB color of background
Background gradient
color
4 bytes 0xAARRGGBB RGB color of background gradient
Axis color 3 bytes 0xRRGGBB RGB color of axes
Tick color 3 bytes 0xRRGGBB RGB color of ticks
X Rotation 1 byte -90-90 Rotation of view around X axis in
degrees
Y Rotation 1 byte -90-90 Rotation of view around Y axis in
degrees
Z Rotation 1 byte -90-90 Rotation of view around Z axis in
degrees
Attributes 1 byte Bit 0: Show X axis
Bit 1: Show Y axis
Bit 2: Show Z axis
Bit 3: Show fill
Bit 4: Show mesh
Bit 5: Use palette coloring
Scaling mode 1 byte 0 = Static
1 = Scale roof and floor
2 = Scale roof
3 = Scale floor
4 = Sticky scale roof and floor
5 = Sticky scale roof
6 = Sticky scale floor
Axis minimum 4 bytes Floating point Minimum value (floor) of Y axis
Axis maximum 4 bytes Floating point Maximum value (roof) of Y axis
Example
The picture below shows an example of a surface element. The element data fields for the example are
shown in the table below the picture.
Notice: The appearance of elements will vary with operating system version and configuration.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 176
Table 5-87. Surface
Field Value
Z-index 0
X-coordinate 5
Y-coordinate 5
Width 750
Height 590
Element type 0x0D
Fill color 0x2F4F4F
Mesh color 0x000000
Background color 0x00000000
Axis color 0x505050
Tick color 0x505050
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 177
Field Value
X Rotation 35
Y Rotation -70
Z Rotation 0
Attributes 0b00111111
Scaling mode 5
Axis minimum 0
Axis maximum 10
MSG_CONF_ADD_STREAM_TO_ELEMENT
This message is used to tie an already configured stream to an already configured dashboard element.
Field Size Values Description
Message ID 1 byte 0x2C
Data length 2 bytes 6
Dashboard ID 2 bytes 0x0000-0xFFFF ID of dashboard of given
element
Element ID 2 bytes 0x0000-0xFFFF ID of element
Stream ID 2 bytes 0x0000-0xFFFF ID of stream for this
element
MSG_CONF_ACK
Sent by PC to target to verify whether the last received configuration message was valid or not.
Field Size Values Description
Message ID 1 byte 0x30
Data length 2 bytes 1
Status 1 byte 0 = Not OK
1 = OK
OK = Last
configuration was
OK and applied
Not OK = Last
configuration was
invalid and got
discarded
5.2.5.6 Data Message Details
MSG_DATA_STREAM
This message is used to send data from all enabled streams to the PC. It is possible to send one or
multiple samples of data from all streams in one single message. Only data from the enabled streams will
be sent.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 178
Field Size Values Description
Message ID 1 byte 0x40
Data length 2 bytes 1 + number of streams
(N) * (2 + num bytes for
each stream (Xn) +
length of each data
sample in the stream
(Xd))
Number of streams (N) 1 byte 1 - 255
Stream ID 2 bytes 0x0000-0xFFFF ID of stream X
Num bytes (Xn) 1 byte 1-255 Number of bytes from
stream X
Stream X data sample M Dependent on data type
of the stream (Xd)
The data of stream X
Note that the last row repeats for each sample in the stream and the three last rows repeat for each
stream in the message.
MSG_DATA_STREAM_SINGLE
This message is used to send data from a single enabled stream to the PC. Only data from enabled
streams will be sent.
Field Size Values Description
Message ID 1 byte 0x41
Data length 2 bytes 2 + length of one data
sample of the stream
(Xd)
Stream ID 2 bytes 0x0000-0xFFFF ID of stream
Stream data sample Dependent on data type
of the stream (Xd)
The data of stream
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 179
6. Example Code Snippets
This chapter contains the code snippets used in the examples in this user guide.
6.1 Data Polling Example Code
A Mass Storage Class example is used as an example on how to use the data polling and control of data
variables features. A SAM L21 Xplained Pro board is connected to a host computer trough both the
Target USB and Debug USB connectors on the kit. The ATSAML21 target device is running the USB
Device MSC Example from ASF for SAM L21 Xplained Pro.
To be able to work through this example, the following is required:
• Host computer with Atmel Studio 7 (or later) installed (Data Visualizer is included)
• ATSAML21 Xplained Pro kit
To do:
• Connect both the Target USB and Debug USB connectors on the SAM L21 Xplained Pro
board
This example makes use of the USB Device MSC Example from ASF for SAM L21 Xplained Pro.
To do:
• In Atmel Studio, create a New Example Project
• In the New Example dialog, select the SAM L21 device family (or other relevant device)
and filter by the keyword “MSC”
• Select the USB Device MSC Example
• Build the project/solution (F7)
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 180
To do:
• Open the project properties (right click the project in the Solution Explorer and select
Properties)
• On the Tool tab, select the appropriate tool and interface
Now see how Data Visualizer can poll variables from the target and display their values in graphical form.
Important: Data polling is only available when Data Visualizer is run as an extension within
Atmel Studio. This is because it needs to access the debug system on the device through the
Atmel Studio debugger backend.
First, add a few lines of code containing variables to poll.
To do: Open ui.c and add two global variables to the top of the file.
volatile uint32_t write_count = 0;
volatile uint32_t read_count = 0;
Important: Declaring variables you are interested in polling as volatile will ensure that they are
placed in SRAM and that their values will not be cached in registers by the compiler. Registers
cannot be polled, only SRAM locations.
Tip: Data polling operates on absolute SRAM locations. It is thus advised to use global
variables for this purpose so that they are always available at the same location in SRAM.
Polling locations in the stack can yield unpredictable results based on the stack context at the
time of polling.
To do: Modify the two ̔startʼ functions in ui.c to increment read and write counters on each
access started.
void ui_start_read(void)
{
port_pin_set_output_level(EXT1_PIN_GPIO_0, true);
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 181
read_count++;
}
void ui_start_write(void)
{
port_pin_set_output_level(EXT1_PIN_GPIO_1, true);
write_count++;
}
To do:
• Build the project/solution (F7)
• Open Data Visualizer
• Connect
For data polling functionality, enable the Code Profiling interface.
To do:
• Start the Data Visualizer session
• Launch the debug session using Start Debugging and Break (Alt + F5)
Data polling operates on SRAM locations, so to find out where variables are located in SRAM we need to
use the Atmel Studio Watch window.
To do:
• Locate the two global variables added to ui.c
• Right-click each variable and select Add to Watch
• Examine the type field of each variable in the Watch window to find its location
Switch back to the Data Visualizer to set up the Code Profiling interface and to connect the two variables
to a graph.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 182
6.1.1 Application Interaction using Dashboard Controls
Now see how components placed on a dashboard in Data Visualizer can be hooked up to variables in the
application, and how the dashboard can thus interact with the application at run-time.
Instead of a predefined interval of 1000 USB sync pulses (1 second), add a variable compare reference
to the original code.
To do: Modify ui.c to include a LED blinker in the ui_process() handler as shown here.
volatile uint32_t frame_comparator = 100;
volatile uint32_t frames_received = 0;
void ui_process(uint16_t framenumber)
{
frames_received++;
if (frames_received >= frame_comparator) {
LED_Toggle(LED_0_PIN);
frames_received = 0;
}
}
To do:
• Build the project/solution (F7)
• Launch a debug session using Start Debugging and Break (Alt + F5)
• Find the location of the variable uint32_t frame_comparator
6.2 Terminal Example Code
A typical use of the Terminal module is print-type debugging. A serial interface is used to print debug
messages from the target device to the terminal. In the following example an SPI interface will be used
but the procedure will be the same for any serial interface.
The target device is an ATmega256RFR2 on an ATmega256RFR2 Xplained Pro kit. As the SPI interface
is already wired internally on the board, the only connection needed is the USB cable between the host
computer and the Xplained Pro board.
To do:
• Make a new project in Atmel Studio (File → New → Project → GCC C Executable
Project)
• Replace the content of the automatically generated main.c file with the code below
#include
#include
volatile uint8_t led_on;
volatile uint8_t send_message;
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 183
volatile uint8_t ticker = 0;
const char* message_on = "LED ON ";
const char* message_off = "LED OFF ";
ISR (INT4_vect)
{
// Simple debounce
if (PINE & (1 << 4))
return;
// Update LED
if (led_on)
PORTB |= (1 << 4);
else
PORTB &= ~(1 << 4);
// Invert led_on
led_on = ~led_on;
// Flag a message send
send_message = 1;
// Increment ticker
ticker++;
// Reset ticker
if (ticker >= 10)
ticker = 0;
}
void spi_send (const char data)
{
PORTB &= ~(1 << PINB0);
// Send a character to the USART
SPDR = data;
// Wait for the character to be sent
while (!(SPSR & (1 << SPIF)))
;
PORTB |= (1 << PINB0);
}
int main(void){
// PORTB4 to output
DDRB = (1 << PINB4);
// LED OFF
PORTB |= (1 << PINB4);
led_on = 0;
// Enable pullup on button pin to avoid floating line
PORTE |= (1<
uint16_t adc_value = 0;
void adc_init(void){
// Internal 1.5V reference, ADC0 as single ended input
ADMUX = (1 << REFS1);
// Enable the ADC,
ADCSRA |= (1<
#include
const char* message_on = "NIGHT MODE ON";
const char* message_off = "NIGHT MODE OFF";
uint16_t adc_value = 0;
uint8_t nightmode_threshold = 40;
uint8_t nightmode_active = 0;
void adc_init(void){
// Internal 1.5V reference, ADC0 as single ended input
ADMUX = (1 << REFS1);
// Enable the ADC,
ADCSRA |= (1< nightmode_threshold){
if (0x00 == nightmode_active){
// Changing from night mode inactive to active
nightmode_active = 0x01;
send_message(message_on);
}
} else {
if (0x01 == nightmode_active){
// Changing from night mode active to inactive
nightmode_active = 0x00;
send_message(message_off);
}
}
}
}
To do:
• Build the project, program and run the application by simply selecting Continue (F5) in
the Debug menu of Atmel Studio
6.3.3 Using Horizontal Cursor Code
So far, the Graph module of the Data Visualizer has been used to show the data generated by the light
sensor and to show when the Night mode switch toggles between the two modes. The Graph module
can also be used to interact with the target application while it is running. In this example, the Night mode
threshold can be adjusted dynamically by using a horizontal cursor.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 191
First, the code must be extended to accept incoming data on the CDC USART. The output of the
horizontal cursor is a 4-byte float value and will be sent over the CDC interface to the target application.
This float value will be used as the threshold for the Night mode switch.
#include
#include
const char* message_on = "NIGHT MODE ON";
const char* message_off = "NIGHT MODE OFF";
union u_float{
float flt;
char data[4];
};
uint16_t adc_value = 0;
uint8_t nightmode_threshold;
uint8_t nightmode_active = 0;
union u_float cdc_received_data;
uint8_t cdc_read_index=0;
ISR (USART1_RX_vect){
// A byte is received on the CDC UART, MSB first
cdc_received_data.data[cdc_read_index] = UDR1 & 0xFF;
if (3 == cdc_read_index){
// A complete float value is received
nightmode_threshold = (uint8_t) cdc_received_data.flt;
cdc_read_index = 0;
}
else {
cdc_read_index++;
}
}
void adc_init(void){
// Internal 1.5V reference, ADC0 as single ended input
ADMUX = (1 << REFS1);
// Enable the ADC,
ADCSRA |= (1< nightmode_threshold){
if (0x00 == nightmode_active){
// Changing from nightmode inactive to active
nightmode_active = 0x01;
send_message(message_on);
}
} else {
if (0x01 == nightmode_active){
// Changing from nightmode active to inactive
nightmode_active = 0x00;
send_message(message_off);
}
}
}
}
To do:
• Build the project, program and run the application by simply selecting Continue (F5) in
the Debug menu of Atmel Studio
6.4 Oscilloscope Example Code
To demonstrate how to use the Oscilloscope module a light sensor target application will be used. The
light sensor example is a rather generic data source where an Analog-to-Digital Converter is used to
sample the sensor, and the example applies to a wide range of other data sources.
The example requires the following equipment and software:
• Host computer with Atmel Studio 7 or later installed (Data Visualizer is included)
• ATmega256RFR2 Xplained Pro kit
• I/O1 Xplained Pro extension
To run the example, the following hardware setup is required:
• I/O1 Xplained Pro extension connected to ATmega256RFR2 Xplained Pro EXT1 connector
• USB cable connected from host computer to ATmega256RFR2 Xplained Pro
A picture of the setup is shown below.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 193
To be able to view the light sensor data in the Oscilloscope module, the ATmega256RFR2 target has to
be programmed with code that samples the light sensor and sends the data to the Embedded Debugger
(EDBG) on the ATmega256RFR2 Xplained Pro over a serial interface. The EDBG then uses the Data
Gateway Interface (DGI) to send the data to the host computer.
First, a new project for the target application code has to be set up in Atmel Studio.
To do:
• Make a new project in Atmel Studio (File → New → Project → GCC C Executable
Project)
• Replace the content of the automatically generated main.c file with the code below
#include
#include
uint16_t adc_value = 0;
volatile uint8_t send_data = 0;
void adc_init(void){
// Internal 1.5V reference, ADC0 as single ended input
ADMUX = (1 << REFS1);
// Enable the ADC, auto triggered mode, interrupt on conversion finished
ADCSRA |= (1<
#include
union u_double{
double dbl;
char data[8];
};
uint16_t adc_value = 0;
uint8_t nightmode_threshold;
uint8_t nightmode_active = 0;
union u_double cdc_received_data;
uint8_t cdc_read_index=0;
ISR (USART1_RX_vect){
// A byte is received on the CDC UART, MSB first
cdc_received_data.data[cdc_read_index] = UDR1 & 0xFF;
if (7 == cdc_read_index){
// A complete double value is received
nightmode_threshold = (uint8_t) cdc_received_data.dbl;
cdc_read_index = 0;
}
else {
cdc_read_index++;
}
}
void adc_init(void){
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 198
// Internal 1.5V reference, ADC0 as single ended input
ADMUX = (1 << REFS1);
// Enable the ADC,
ADCSRA |= (1< nightmode_threshold){
if (0x00 == nightmode_active){
// Changing from nightmode inactive to active
nightmode_active = 0x01;
}
} else {
if (0x01 == nightmode_active){
// Changing from nightmode active to inactive
nightmode_active = 0x00;
}
}
cdc_send(nightmode_active);
}
}
The code samples the ADC continuously and sends the data over the SPI interface to the EDBG
(Embedded Debugger) on the ATmega256RFR2 Xplained Pro board. The EDBG then sends the SPI data
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 199
over DGI to the host computer. The ATmega256RFR2 ADC is 10-bit but only the lower 8 bits contain
useful data in this example.
In addition, the code sets up the CDC USART and sends the state of the Night mode switch as a single
byte. The received data on the CDC USART is parsed as a double value and is used as threshold for the
Night mode switch.
To do: Build the project/solution (F7).
To do:
• Open the project properties (right click the project in the Solution Explorer and select
Properties)
• On the Tool tab, select the appropriate tool and interface
To do: Program the application into the target and start the debugging by selecting Continue
(F5).
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 200
To do: Open the Data Visualizer as an extension inside Atmel Studio by selecting it in the
Tools menu.
6.6 Auto-Configuration Example Code
The Auto-Configuration feature of the Data Stream protocol can be used over any DGI serial interface or
Serial Port. In this example, the Virtual COM port of an ATtiny104 Xplained Nano board will be used. This
board has a built-in debugger (mEDBG) that can be used to program the target ATtiny104 device, and the
emEDBG provides a Virtual COM port over USB that is connected to the UART pins of the ATtiny104.
Data Visualizer
© 2017 Microchip Technology Inc. User Guide DS40001903B-page 201
The only hardware connection required to run this example is to connect a USB cable between the host
computer and the Xplained Nano board.
The Data Stream protocol will be used to send the state of the button on the Xplained Nano and the value
of a 16-bit counter to the host computer.
To do:
• Make a new project in Atmel Studio (File → New → Project → GCC C Executable
Project)
• Replace the content of the automatically generated main.c file with the code below
#include
uint8_t start_token = 0xAB;
uint8_t config_id_packet[] = {
/* Token */
0x5F,
/* Specify checksum LRC8 */
0xB4, 0x00, 0x86, 0x4A,
/* Configuration ID */
0xC0, 0xFF, 0xEE, 0xC0, 0xFF, 0xEE, 0xC0, 0xFF, 0xEE, 0xC0, 0xFF, 0xEE,
/* The actual checksum */
0x78,
/* Inverse of Token */
0xA0
};
uint16_t count = 0;
uint8_t send_id = 0;
void uart_send(uint8_t byte){
/* Wait for empty transmit buffer */
while ( !( UCSRA & (1<> 8);
uart_send (!(PINB & (1<
Driver Libraries Help
MPLAB Harmony Integrated Software Framework
© 2013-2018 Microchip Technology Inc. All rights reserved.
Volume V: MPLAB Harmony Framework Reference
This volume provides API reference information for the framework libraries included in your installation of MPLAB Harmony.
Description
This volume is a programmer reference that details the interfaces to the libraries that comprise MPLAB Harmony and
explains how to use the libraries individually to accomplish the tasks for which they were designed.
Volume V: MPLAB Harmony Framework
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 2
Driver Libraries Help
This section provides descriptions of the Driver libraries that are available in MPLAB Harmony.
Driver Library Overview
This topic provides help for the MPLAB Harmony driver libraries. It includes a general driver usage overview, as well as sections providing a
programmer’s reference for each driver that describes its interface and explains how to use it.
Introduction
Introduces MPLAB Harmony device drivers and explains common usage concepts.
Description
MPLAB Harmony device drivers (usually referred to as "drivers") provide simple, highly abstracted C-language interfaces to peripherals and other
resources. A driver's interface allows applications and other client modules to easily interact with the peripheral it controls using consistent usage
models. Some functions are similar on all drivers, while other functions are unique to a particular type of driver or peripheral. However, driver
interface functions are generally independent of the details of how a given peripheral is implemented on any specific hardware or of how many
instances of that peripheral exist in a given system.
Drivers normally utilize MPLAB Harmony Peripheral Libraries (PLIBs) to access and control peripheral hardware that is built into the processor
(and is directly addressable by it). However, drivers can also support external peripheral hardware by calling another driver that directly controls a
built-in peripheral to which the external peripheral is connected. For example, an SD Card driver may use a SPI driver to access its external SD
Card Flash device. A driver may even be completely abstracted away from any hardware (utilizing no peripheral hardware at all), simply controlling
some software resource (such as a buffer queue) or providing some service (such as data formatting or encryption). Using this method, driver and
other modules may be "stacked" into layers of software, with each responsible for the details of managing its own resources while hiding those
details from client modules that use them.
Regardless of the type of peripheral or resource that a MPLAB Harmony driver manages, a driver has the following fundamental responsibilities:
• Provide a common system-level interface to the resource
• Provide a highly abstracted file system style client interface to the resource
• Manage the state of the peripheral or resource
• Manage access to the resource
A driver’s system interface can be thought of as being a horizontal interface and its client interface can be thought of as being a vertical interface,
as shown in the following block diagram.
The horizontal or "system" interface provides functions to initialize the driver and keep it running. To keep a driver running, a system loop or ISR
function (but never both in the same system) calls its state machine "tasks" function repeatedly, as necessary. Therefore, a driver’s system
interface is normally only called by code that is generated by the MPLAB Harmony Configurator (MHC) when you select and configure the driver.
Its purpose is to ensure that the driver works independently (conceptually in the background), providing the capabilities it implements. By contrast,
the application (or any other "client" of the driver) normally only interacts with the driver’s vertical "client" interface (often thought of as the driver’s
API). The client interface provides functions to open the driver for use and interact with it, reading or writing data or performing device-type specific
operations. The client interface is what allows the application to access the peripheral in a safe and easy way without worrying about the details of
the driver or what other clients it may be serving.
Volume V: MPLAB Harmony Framework Driver Libraries Help Driver Library Overview
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 3
The following sections describe in general terms how to use these two interfaces and give specific examples to help illustrate the concepts. The
subsequent help sections for each individual driver describe their specific interfaces in detail; listing all supported functions, parameters, and return
values as well as their data types and expected behavior. You may also refer to the MPLAB Harmony Driver Development guide for additional
information on MPLAB Harmony drivers and for information on how to develop your own drivers, if needed.
Using a Driver's System Interface
Introduces the System Interface of a MPLAB Harmony device driver and explains its usage.
Description
An MPLAB Harmony driver's system interface provides functions to initialize, deinitialize, and reinitialize an instance of a driver, as well as
functions to maintain its state machine (and/or implement its Interrupt Service Routine) and check its current "running" status. Normally, as an
MPLAB Harmony application developer or a developer of a "client" module that uses the driver, you will not call the system interface functions
directly. The MHC generates calls to the system interface functions of any driver that is used in a project when it generates the system
configuration files. Exactly which functions are called and exactly how they’re called depends on the configuration options selected in the project’s
active configuration.
For example, when the box next to “Use Timer Driver?” is selected in the MHC Options tree (within MPLAB Harmony & Application Configuration >
Harmony Framework Configuration > Drivers > Timer), as shown in the following figure, the MHC will generate all necessary definitions and
function calls for the Timer Driver’s system interface.
Example Timer Driver MHC Options
These configuration selections, which are set by default once "Use Timer Driver" is selected, will cause the MHC to generate the following
definitions in the system_config.h header file for the main project’s current configuration when Generate Code is clicked.
Example Driver Options in system_config.h
/*** Timer Driver Configuration ***/
#define DRV_TMR_INTERRUPT_MODE true
#define DRV_TMR_INSTANCES_NUMBER 1
#define DRV_TMR_CLIENTS_NUMBER 1
/*** Timer Driver 0 Configuration ***/
#define DRV_TMR_PERIPHERAL_ID_IDX0 TMR_ID_1
#define DRV_TMR_INTERRUPT_SOURCE_IDX0 INT_SOURCE_TIMER_1
#define DRV_TMR_CLOCK_SOURCE_IDX0 DRV_TMR_CLKSOURCE_INTERNAL
#define DRV_TMR_PRESCALE_IDX0 TMR_PRESCALE_VALUE_256
#define DRV_TMR_OPERATION_MODE_IDX0 DRV_TMR_OPERATION_MODE_16_BIT
#define DRV_TMR_ASYNC_WRITE_ENABLE_IDX0 false
#define DRV_TMR_POWER_STATE_IDX0 SYS_MODULE_POWER_RUN_FULL
It is important to notice that the Driver Implementation selection in the MHC graphical interface does not correlate to a #define statement in the
system_config.h file. Instead, it determines which implementation of the driver this configuration will use. Drivers may have more than one
implementation. For example, most drivers have both static and dynamic implementations. A static implementation is usually the smaller of the
two, but it is only capable of controlling one instance of a peripheral. An equivalent dynamic implementation will be larger, but it is capable of
managing multiple instances of the same type of peripheral using a single instance of the source code (and thus, one instance of the object code).
Some drivers may have additional implementations, each one optimized for a different usage. The Driver Implementation pull-down control in the
MHC graphical interface allows you to select which implementation the current configuration will use. Normally, you can use only a single
implementation of a driver in a given configuration. If you change driver implementations, it changes which implementation is used for all all
instances of a peripheral.
The number of instances option, for example, Number of Timer Driver Instances, which correlates to the DRV_TMR_INSTANCES_NUMBER
definition, determines how many instances of a static driver implementation will be generated or how many instances of a peripheral a dynamic
driver implementation will manage. Drivers may also be designed to allow multiple different clients (applications or other modules) to share the
same instance of a peripheral or resource. Therefore, a driver will have an option to determine a maximum number of simultaneous clients that it
Volume V: MPLAB Harmony Framework Driver Libraries Help Driver Library Overview
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 4
can support. For example, Number of Clients (DRV_TMR_CLIENTS_NUMBER) in the Timer Driver, which is fixed at one (1) and cannot be
changed, which indicates that the Timer Driver is a single-client driver). The last implementation-specific configuration option in this example is the
"Interrupt Mode" (DRV_TMR_INTERRUPT_MODE) setting. This option determines if the implementation is configured to run polled or interrupt
driven (discussed further, in a following section). MPLAB Harmony drivers are generally designed to run most effectively in an interrupt-driven
configuration, but they can also be run in a polled configuration to simplify debugging or to support task prioritization in an RTOS configuration.
The remaining configuration options are all instance-specific initialization options. For a dynamic implementation of a driver, these options are
passed into the driver’s Initialize function through an "init" data structure, as shown in the following example.
Example Driver Init Structure in system_init.c
const DRV_TMR_INIT drvTmr0InitData =
{
.moduleInit.sys.powerState = DRV_TMR_POWER_STATE_IDX0,
.tmrId = DRV_TMR_PERIPHERAL_ID_IDX0,
.clockSource = DRV_TMR_CLOCK_SOURCE_IDX0,
.prescale = DRV_TMR_PRESCALE_IDX0,
.mode = DRV_TMR_OPERATION_MODE_16_BIT,
.interruptSource = DRV_TMR_INTERRUPT_SOURCE_IDX0,
.asyncWriteEnable = false,
};
The exact meaning and usage of these options are described in the Configuring the Library section in the Help documentation for each library.
The live MHC Help windowpane displays the associated help section whenever you select one of these options in the options tree.
There is one instance-specific initialization option of which you should take special notice: the peripheral ID option (.tmrId, in the Timer Driver
example shown). This initialization option associates the driver instance (a zero-based index number) with the peripheral-hardware instance
number, as defined by the data sheet for the processor in use. For a dynamic driver, this association is actually made when the driver’s initialize
function is called and passes a pointer to the init data structure, as shown in the following code example.
Example Driver Initialize Call in system_init.c
/* Initialize Drivers */
sysObj.drvTmr0 = DRV_TMR_Initialize(DRV_TMR_INDEX_0, (SYS_MODULE_INIT *)&drvTmr0InitData);
In this example, the driver index (DRV_TMR_INDEX_0) is defined as a numeric constant with a value of zero (0). This line of code associates
driver instance 0 with hardware timer instance 1 by calling the DRV_TMR_Initialize function from the system initialization code and passing a
pointer to the drvTmr0InitData structure. As shown earlier, the Timer Driver’s init structure contains the value TMR_ID_1 (defined by the timer
peripheral library), in its .tmrId data member.
In a static implementation, the driver peripheral ID macro (DRV_TMR_PERIPHERAL_ID_IDX0) defined in system_config.h is hard-coded into
the driver’s instance-specific initialization function when it is generated by the MHC, instead of defining an "init" structure, as shown in the following
example; however, the effect is the same.
Example Static Driver Initialize Function
void DRV_TMR0_Initialize(void)
{
PLIB_TMR_Stop(DRV_TMR_PERIPHERAL_ID_IDX0);
PLIB_TMR_ClockSourceSelect(DRV_TMR_PERIPHERAL_ID_IDX0, DRV_TMR_CLOCK_SOURCE_IDX0);
PLIB_TMR_PrescaleSelect(DRV_TMR_PERIPHERAL_ID_IDX0, DRV_TMR_PRESCALE_IDX0);
PLIB_TMR_Mode16BitEnable(DRV_TMR_PERIPHERAL_ID_IDX0);
PLIB_TMR_Counter16BitClear(DRV_TMR_PERIPHERAL_ID_IDX0);
PLIB_TMR_Period16BitSet(DRV_TMR_PERIPHERAL_ID_IDX0, 0);
}
The DRV_TMR0_Initialize function (with an instance number ‘0’ in the name) in the previous example, is a static version of the
DRV_TMR_Initialize system interface function. The call to this function is created by the MHC when it generates the system code. Therefore, that
call is always generated with the correct name and with the correct instance number in the name. However, when calling client interface functions
(open, close, read, write, etc.) from your own applications, you should not use an instance number in the function name. Dynamic drivers
implement the client interface functions without any index numbers in their names. Instead, they use an index or handle parameter to identify the
instance of the driver with which to interact. Also, when using static implementations of the drivers, the dynamic API functions are mapped (using
the index or handle parameter) to the appropriate static function with the index number in its name. Therefore, calling the dynamic API function
makes your application always portable, using whichever driver instance is configured to the index value with which you open the driver.
Note:
Calling the static versions of the interface function (with the index numbers in their names) is not prohibited. However, it will limit
the portability of your application.
Understanding this mechanism is critical to understanding how to access the desired peripheral hardware instance. Therefore, it is worth looking at
a few demonstration applications to see how it is used. Also, refer to Volume IV: MPLAB Harmony Development > Key Concepts > Key
One-to-Many Relationships for additional information on the concepts of having multiple implementations, instances, and clients.
Something else worth noting about the previous example call to the Timer Driver’s initialize functions is that when using a dynamic implementation,
it returns a value called an “object handle”. In the previous example, that object handle was stored in a system configuration object data member
(sysObj.drvTmr0). Object handles returned by module initialization functions are stored in a system configuration structure normally named
sysObj. The definition of this structure is generated in the system_definitions.h header file the MHC, as shown in the following example.
Example System Object Data Structure Definition in system_definitions.h
typedef struct
{
Volume V: MPLAB Harmony Framework Driver Libraries Help Driver Library Overview
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 5
SYS_MODULE_OBJ sysDevcon;
SYS_MODULE_OBJ drvTmr0;
} SYSTEM_OBJECTS;
extern SYSTEM_OBJECTS sysObj;
As shown in the previous example, this structure is “extern’d” for use by the other system files. It should not be used by application or library files,
only by the system files for a single configuration. The sysObj structure is defined (and allocated in memory) by the system_init.c file, as
shown in the following example.
Example System sysObj Definition in system_init.c
/* Structure to hold the object handles for the modules in the system. */
SYSTEM_OBJECTS sysObj;
For this discussion, you can ignore the sysDevcon member of the SYSTEM_OBJECTS structure as it will contain the handle for a different library.
The important thing to note is that the drvTmr0 member must be passed into the Timer Driver’s other system interface functions so that the driver
has access to the data it needs manage that specific instance of itself (and the associated peripheral hardware), as shown by the following timer
ISR example.
Example Timer ISR in system_interrupt.c
void __ISR(_TIMER_1_VECTOR, ipl1AUTO) IntHandlerDrvTmrInstance0(void)
{
DRV_TMR_Tasks(sysObj.drvTmr0);
}
In this ISR example, there are three important things to notice.
First, the ISR function itself is associated with a specific vector through the __ISR macro. Different interrupt vectors are associated with different
peripheral instances and interrupts on different processors. That is why MPLAB Harmony ISR vector functions are generated in the
configuration-specific system_interrupt.c file instead of being part of the driver library itself.
Second, the DRV_TMR_Tasks function implements the actual ISR logic of the TMR driver. Most MPLAB Harmony drivers are designed to run
interrupt driven and their tasks functions implement the software state machine logic necessary to keep the driver’s interrupt sequence moving
from one interrupt to the next until the driver’s task is complete.
Third, the sysObj.drvTmr0 object handle’s value is passed into the driver’s tasks function so that it has access to the data it requires to control
instance zero (0) of the Timer Driver and its associated hardware instance, which must match the ISR vector instance from which it is called.
By default, the Timer Driver is configured to run interrupt-driven, as shown previously. This is not necessarily true for all drivers. However, most
drivers (including the Timer Driver) can run in a Polled mode by simply changing the configuration settings. For example, by clearing the "Interrupt
Mode" option in the MHC configuration tree and regenerating the configuration code, the previous example ISR will be removed from
system_interrupt.c and a call to the Timer Driver’s tasks function will be added to the polled system tasks function, as shown by the following
system_tasks.c example code.
Example Call to Timer Tasks from system_tasks.c
void SYS_Tasks ( void )
{
/* Maintain system services */
SYS_DEVCON_Tasks(sysObj.sysDevcon);
/* Maintain Device Drivers */
DRV_TMR_Tasks(sysObj.drvTmr0);
/* Maintain the application's state machine. */
APP_Tasks();
}
In this example, the Timer Driver’s tasks function is called from the polled loop in main by the SYS_Tasks function. The driver’s tasks must still
receive the sysObj.drvTmr0 object handle value and its logic operates in exactly the same way, with one exception. Because the driver is now
polled, the DRV_TMR_INTERRUPT_MODE option is now defined as false. This causes the driver to be built so that it does not enable its own
interrupt, allowing it to run in the polled loop and to not require an ISR.
For additional information on the device driver system interface, refer to Volume IV: MPLAB Harmony Development > MPLAB Harmony Driver
Development Guide > System Interface and to the documentation for the individual system interface functions for the driver in question.
Using a Driver's Client Interface
Introduces the Client Interface (or API) of a MPLAB Harmony device driver and explains common usage models.
Description
Applications (or any other “client” of a MPLAB Harmony device driver) normally only interact with the driver’s client interface (often called its API).
The client interface provides functions to “open” the driver (creating a link between the client and the driver) and interact with it, to transfer data or
perform operations that are specific to a given type of device, and to “close” the driver (releasing the link). Once a driver has been configured and
the configuration code has been generated, the application can assume that the driver will be initialized by the system-wide initialization function
(SYS_Initialize) and that its tasks functions will be called as required from either the system-wide tasks function (SYS_Tasks) or from the
Volume V: MPLAB Harmony Framework Driver Libraries Help Driver Library Overview
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 6
appropriate ISR, depending upon how the driver was designed and configured.
To interact with the driver, a client must first call the driver’s open function. This is necessary because all other client interface functions require a
“handle” to the device driver that is returned by the open function, as shown in the following example.
Example Call to a Driver’s Open Function
appData.handleTmr = DRV_TMR_Open(APP_TMR_DRV_INDEX, DRV_IO_INTENT_EXCLUSIVE);
if( DRV_HANDLE_INVALID != appData.handleTmr )
{
// Advance to next application state.
}
In this example, the first parameter to the DRV_TMR_Open function is the APP_TMR_DRV_INDEX macro, which is a constant defined to the
value of the desired driver instance index number in the system_config.h header file. This value must be the same as the index number used
when the desired driver was initialized (as shown in the previous section). This is how the client becomes associated with a specific instance of a
driver.
The second parameter identifies how the client intends to use the driver. Here, the client wants to have exclusive access to the driver. This means
that no other client can currently have an active handle to this driver or this call will fail and return a value of DRV_HANDLE_INVALID. Drivers can
also be opened as shared, as blocking or non-blocking and for reading, writing, or both. Refer to the help for the DRV_IO_INTENT data type for
additional information about the IO intent parameter of driver open functions. This parameter is merely an advisory parameter. How it is used by
the driver is implementation dependent and will be described in the driver’s help documentation.
Finally, if the open function was successful, the returned value will be a valid handle to the driver instance. This value is opaque and meaningless
to the caller, but it must be passed back to the driver as the first parameter to every other client interface function provided by the driver. A valid
handle identifies both the instance of the driver with which the caller interacts and it identifies the client performing the call. This means that, two
different client applications or modules opening the same driver in the same system at the same time will receive different values for their “opened”
handle. If, for any reason, the driver cannot support the “open” request (it is not finished initializing itself, it has already been opened for exclusive
access, or cannot accept new open requests for any reason), it will return a value of DRV_HANDLE_INVALID, indicating the client cannot use it at
this time. The DRV_HANDLE_INVALID value is the only non-opaque value that a client should consider meaningful. All other values are only
meaningful to the driver that provided them.
Note:
The appData.handleTmr variable in the previous example is a member of the application’s appData structure. This structure is
generated by the MHC as part of the initial application template and should be used to hold an applications state variables.
When the client is finished using a driver, it may close it, as shown in the following example.
Example Call to a Driver’s Close Function
DRV_TMR_Close(appData.handleTmr);
This action releases the link to the driver, invalidating the handle and releasing any resources allocated by the driver to track requests from the
client. Notice that the close function demonstrates the use of the driver handle, requiring it as a parameter. However, after the close function
returns, the handle value cannot be used again. Therefore, the client should not call the driver’s close function until it is done using the driver or it
will have to call open again and obtain a new handle to use the driver again. In fact, since many embedded applications are always running, they
often do not bother to close drivers they use. But, applications that can go idle or that can be stopped and restarted or that need to share a driver
with other clients, but want to conserve resources, or that want use the driver exclusively, can close a driver when they are finished with it for a
time and reopen it later when needed. In fact, this is a good way to share a single-client driver, or a driver that supports exclusive access, allowing
each client to open it and use it only when a valid handle is obtained.
Using a Driver in an Application
Describes how to write a state-machine based application that uses a MPLAB Harmony driver.
Description
MPLAB Harmony generally treats all software modules, including applications, as state machines that have an “initialize” function and a “tasks”
function. In fact, when not using a RTOS, it essentially treats the entire system as one large state machine that runs in a common super loop in the
“main” function, as shown in the following code example.
Example Main Function
int main ( void )
{
SYS_Initialize(NULL);
while(true)
{
SYS_Tasks();
}
return (EXIT_FAILURE);
}
For the purpose of this discussion, it is important to understand that the application’s APP_Initialize function is called from the SYS_Initialize
function, along with the initialization of functions of all drivers and other libraries before execution enters the endless while(true) super loop
that continuously calls the system-wide SYS_Tasks function. The application’s APP_Tasks function is then called from the SYS_Tasks function
Volume V: MPLAB Harmony Framework Driver Libraries Help Driver Library Overview
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 7
inside of the super loop, along with all other polled modules in the system. If you are not already familiar with the organization of an MPLAB
Harmony project, please refer to Volume I: Getting Started With MPLAB Harmony > What is MPLAB Harmony? for more information.
An application that uses a driver must define a DRV_HANDLE variable, as shown in the following example application header file.
Example Driver Application Header (app.h)
#include "driver/usart/drv_usart.h"
typedef enum
{
APP_STATE_SETUP=0,
APP_STATE_MESSAGE_SEND,
APP_STATE_MESSAGE_WAIT,
APP_STATE_DONE
} APP_STATES;
typedef struct
{
APP_STATES state;
DRV_HANDLE usart;
char * message;
} APP_DATA;
In this previous example, the driver handle variable is named usart. To keep the application well organized, it is common to keep all of the
application’s state variables (including one called “state” that holds the current state of the application’s state machine) in a common structure
(APP_DATA). This structure must be allocated in the application’s source file (usually named app.c) and initialized by the application’s
initialization function, as shown in the following example.
Example Driver Application Initialization
APP_DATA appData;
void APP_Initialize ( void )
{
/* Place the App in its initial state. */
appData.state = APP_STATE_SETUP;
appData.usart = DRV_HANDLE_INVALID;
appData.message = “Hello World\n”;
}
The APP_Initialze function must initialize the state variable (appData.state) to put the application’s state machine in its initial state (the
APP_STATE_SETUP value from the APP_STATES enumeration). It must also initialize the driver-handle variable (appData.usart), so that the
state machine knows it is not yet valid, and any other application variables (like the string pointer, appData.message).
Once the application’s data structure has been initialized, it is safe for the system (the main and SYS_Tasks functions) to call the application’s
APP_Tasks function from the super loop to keep it running. The APP_Tasks function then executes state transition code as it switches between
states, as demonstrated by the following example.
Example Application State Machine Using a Driver
void APP_Tasks ( void )
{
switch ( appData.state )
{
case APP_STATE_SETUP:
{
if (SetupApplication() == true)
{
appData.state = APP_STATE_MESSAGE_SEND;
}
break;
}
case APP_STATE_MESSAGE_SEND:
{
if (MessageSend() == true)
{
appData.state = APP_STATE_MESSAGE_WAIT;
}
break;
}
case APP_STATE_MESSAGE_WAIT:
Volume V: MPLAB Harmony Framework Driver Libraries Help Driver Library Overview
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 8
{
if (MessageComplete() == true)
{
appData.state = APP_STATE_DONE;
}
break;
}
case APP_STATE_DONE:
default:
{
break;
}
}
}
There are numerous ways to implement a state machine. However, in this example, the application changes state when the APP_Tasks function
assigns a new value from the APP_STATES enumeration to the appData.states variable. This happens when one of the state transition
function returns true. The end result is an overall application state machine execution that retries each state transition until it succeeds before
moving on to the next state, as shown in the following diagram.
Application State Machine
Note:
The APP_STATE_ prefix and all inter-word underscores were removed from the state names to simplify the diagram.
After APP_Initialize places the state machine in its initial APP_STATE_SETUP state, the APP_Tasks function will call the SetupApplication
function when it is called. When SetupApplication returns true indicating it has completed its task, the state machine advances to the next state.
Otherwise, it stays in the same state and retries the tasks in the SetupApplication function. This pattern repeats for the
APP_STATE_MESSAGE_SEND state and the MessageSend function as well as the APP_STATE_MESSAGE_WAIT state and the
MessageComplete function. When all functions have returned true, the state machine to transitions to the APP_STATE_DONE state where it
unconditionally stays having completed its tasks.
The sum total of the tasks performed by each transition function completes the overall task of the application. For an application that uses a driver
like this example, this includes opening the driver, sending the message, and closing the driver when the message has been sent. How each
individual transition function in this example application accomplishes its portion of the overall task, is described in the examples in the following
sections to demonstrate how drivers are commonly used.
Opening a Driver
Describes how to open a driver in a state-machine based application.
Description
To use a MPLAB Harmony driver, an application (or other client) must call the driver’s “open” function and obtain a valid handle to it, as shown by
the following code example.
Example Opening a Driver
static bool SetupApplication ( void )
{
if (appData.usart == DRV_HANDLE_INVALID)
Volume V: MPLAB Harmony Framework Driver Libraries Help Driver Library Overview
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 9
{
appData.usart = DRV_USART_Open(APP_USART_DRIVER_INDEX,
(DRV_IO_INTENT_READWRITE|DRV_IO_INTENT_NONBLOCKING));
}
if (appData.usart == DRV_HANDLE_INVALID)
{
return false;
}
return true;
}
This example demonstrates the implementation of a state-transition function in a state machine-based application (as shown in the previous Using
a Driver in an Application section). The SetupApplication function assumes that the appData.usart variable has been initialized to a value
of DRV_HANDLE_INVALID when the application’s state machine was initialized. Therefore, it checks this variable every time it is called to see if it
has already completed its task. If appData.usart contains a value of DRV_HANDLE_INVALID, this indicates that the driver has not yet been
successfully opened, causing the function to attempt to open the driver by calling DRV_USART_Open.
If the USART driver is ready and able to support a new client it will return a valid handle. If it is not ready or able to accept a new client, the driver
will return DRV_HANDLE_INVALID and the SetupApplication function will return false and the application will stay in the same state and try to
open the driver again the next time its state machine tasks function is called. When DRV_USART_Open returns a valid handle (a handle that is not
equal to DRV_HANDLE_INVALID), the SetupApplication function returns true, allowing the application’s state machine to advance.
This technique allows the application to try repeatedly to open the driver until it succeeds and guarantees that the application’s state machine will
not advance until it has done so. A more sophisticated application might use a time-out mechanism or some other error handling logic to take
alternative action if it cannot open the driver in an acceptable time period. However, this simple implementation demonstrates the basic concept of
how an MPLAB Harmony application (or any other client module) can safely open a driver before attempting to use it.
Using Driver Interface Functions
Describes how to use a device driver’s synchronous client interface functions, such as those that read and write data.
Description
To use a MPLAB Harmony driver’s client interface, the application must first obtain a valid handle from the driver’s “open” function. The examples
in this section assume that that has already occurred and that the value of the USART driver handle in the appData.usart variable is valid. The
following example code demonstrates the implementation of a state transition function in a state machine-based application (as shown in the
previous Using a Driver in an Application section) that writes data to a USART driver for transmission on the associated USART peripheral.
Example Writing Data To a Driver
static bool MessageSend ( void )
{
size_t count;
size_t length = strlen(appData.message);
count = DRV_USART_Write(appData.usart, appData.message, length);
appData.message += count;
if (count == length)
{
return true;
}
return false;
}
In this example, the appData.message variable is a char pointer pointing to a null-terminated C-language string that was defined and initialized, as
shown in the Using a Driver in an Application section. When MessageSend function is first called by the application’s state machine, it points to
the first character in the string to be transmitted. The function calculates the current length of the message string (using the standard C-language
strlen function) and calls the driver’s DRV_USART_Write function, passing it the valid driver handle (appData.usart) along with the pointer to
the message string and its length, to transmit the message string on the associated USART.
If the driver is configured for blocking, the DRV_USART_Write function will not return until it has processed all of the data in the message string.
However, that usually requires the use of a RTOS. Normally, in a bare-metal system (one that does not use a RTOS), MPLAB Harmony drivers
are used in a non-blocking mode. In that case, a driver will perform as much of a task as it can when one of its interface functions is called without
blocking. This means that the function will then return immediately, not waiting for the task to complete, and provide information on how much of
the task was completed so the client can react appropriately. In this example, the DRV_USART_Write function will return a count of the number of
bytes that were processed by the USART driver by this call to the function.
The MessageSend function captures the number of bytes processed by the DRV_USART_Write function in a local count variable. It then
effectively removes those bytes from the message string by incrementing the pointer by count bytes (appData.message is a char pointer that
increments by the size of one byte for every ‘1’ added to it). Then, the MessageSend function checks to see if it was able to write the entire string
Volume V: MPLAB Harmony Framework Driver Libraries Help Driver Library Overview
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 10
by comparing the value of count to the value of length that it calculated before calling the driver’s write function. If the two are equal, the task is
complete and the MessageSend function returns true and the application’s state machine can continue to the next state. If the two values are not
equal, this indicates there are remaining bytes in the message string. The MessageSend function returns false and the application must stay in the
same state so that the function can attempt to send the remaining bytes next time it is called. A driver only accepts data when it can process it;
therefore, the client can call its data transfer function as many times as necessary, even when the function returns bytes processed if it cannot
accept more data at that time.
When a client has called a driver interface function there are really only two possibilities. Either the operation has completed when the function
returns, or the operation continues after the function has returned. If the operation completes immediately, the client can continue on without taking
further action. However, in this example, while the USART driver may have accepted some of the bytes in the message string (perhaps copying
them to an internal hardware or software FIFO buffer), it still takes some time to transmit the data over the USART peripheral. In many cases the
client may need to know when the operation has actually completed. For this reason, most drivers provide one or more status functions that client
applications may call to determine the current status of an operation, as demonstrated in the following example.
Example Using a Driver Status Function
static bool MessageComplete ( void )
{
if (DRV_USART_ClientStatus(appData.usart) == DRV_USART_CLIENT_STATUS_BUSY)
{
return false;
}
return true;
}
This example extends the previous one and assumes that the MessageSend function has returned true and the application has moved to a new
state where it calls this function to determine when the driver is idle, which indicates that the message has been completely transmitted. To do
that, the MessageComplete function calls the DRV_USART_ClientStatus function. If its return value is DRV_USART_CLIENT_STATUS_BUSY,
the USART driver is still working on a previous request by the client. If any other status value is returned, this indicates that the driver is no longer
busy with a current request and the MessageComplete function returns true so that the client application’s state machine can move on. A more
sophisticated example would check for other possible status values that might indicate some error has occurred and take appropriate action.
However, this example is sufficient to demonstrate the concept of checking a driver status function to determine when it is safe to move to another
state.
Since the client application stays in the same state calling the status function each time its tasks function is called until the desired status is
returned, it is effectively polling the status as if it were in a while loop. In fact, it is in the system-wide while loop. However, by not trapping the
CPU within its own internal while loop, the application allows other modules (including, potentially, the driver it is using) to continue running and
servicing requests. Failing to allow the rest of the system to run can result in a deadlock where the polling application is waiting for a status;
however, the driver it is polling will never be able to provide the expected status, as the driver’s own tasks function is not allowed to run. This is
why it is important to use the technique described here to “poll” status from modules outside of the current module.
Using Asynchronous and Callback Functions
Describes how to use an asynchronous interface function to start a driver operation and receive a callback when the operation is complete.
Description
When a client calls a function that is part of an asynchronous interface, the function starts the request and returns immediately, without finishing
the request. The client can then either poll a status function to determine when the request has finished (as demonstrated in the Using Driver
Interface Functions section) or it can utilize a callback function to receive a notification from the driver when the request has finished. So, the
difference between an asynchronous interface and a synchronous interface is that a synchronous interface may finish all or part of the request
before returning, whereas an asynchronous interface will always return immediately having only started the request. Determination of when the
request has completed is handled separately.
The examples in this section reimplement some of the code from the example application described in the previous sections to demonstrate how
to use asynchronous queuing and callback interfaces instead of the synchronous status-polling interface demonstrated in the Using Driver
Interface Functions section. To use an asynchronous interface, we will first add a couple of new variables to our example application’s data
structure, as shown by the following structure definition.
Example Driver Application Header (app.h)
typedef struct
{
APP_STATES state;
DRV_HANDLE usart;
char * message;
DRV_USART_BUFFER_HANDLE messageHandle;
bool messageDone;
} APP_DATA;
The state, usart, and message members of the APP_DATA structure are used in exactly the same way as they were in the previous examples.
The messageHandle variable will be explained later and the messageDone variable is a Boolean flag used by the callback function to indicate to
the application’s state machine that the message has been completely processed by the driver. Using these new mechanisms results in very minor
changes to the application’s state machine, as shown in the following example APP_Initialize and APP_Tasks implementations.
Volume V: MPLAB Harmony Framework Driver Libraries Help Driver Library Overview
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 11
Example Driver Application State Machine (app.c)
void APP_Initialize ( void )
{
appData.state = APP_STATE_SETUP;
appData.usart = DRV_HANDLE_INVALID;
appData.message = APP_MESSAGE;
appData.messageHandle = DRV_USART_BUFFER_HANDLE_INVALID;
}
void APP_Tasks ( void )
{
switch ( appData.state )
{
case APP_STATE_SETUP:
{
if (SetupApplication() == true)
{
appData.state = APP_STATE_MESSAGE_SEND;
}
break;
}
case APP_STATE_MESSAGE_SEND:
{
if (MessageSend() == true)
{
appData.state = APP_STATE_MESSAGE_WAIT;
}
break;
}
case APP_STATE_MESSAGE_WAIT:
{
if (appData.messageDone)
{
DRV_USART_Close(appData.usart);
appData.state = APP_STATE_DONE;
}
break;
}
case APP_STATE_DONE:
default:
{
break;
}
}
}
As described previously, the SetupApplication state transition function opens the USART driver and the MessageSend function sends the
message to it. However, there is no need for a MessageComplete state transition function. Instead, the application must implement a callback
function that will set the appData.messageDone Boolean flag when the driver calls the application "back" to indicate that the message has been
sent.
Note:
The AppInitialize function initializes the state, usart, and message members of the appData structure as previously
described. And, it also initializes the messageHandle member with an invalid value to indicate that the message has not yet been
sent. However, it does not initialize the messageDone flag because it is more appropriate to clear the flag elsewhere, immediately
before calling the driver to send the message.
To use a callback mechanism requires the client to implement and register a callback function. A client must register this function after opening the
driver, but prior to calling the driver to initiate the operation. This is often done in the same state transition that opens the driver, as shown in the
following SetupApplication example.
Example Registering a Driver Callback Function
static void BufferDone ( DRV_USART_BUFFER_EVENT event,
DRV_USART_BUFFER_HANDLE bufferHandle,
uintptr_t context )
{
APP_DATA *pAppData = (APP_DATA *)context;
Volume V: MPLAB Harmony Framework Driver Libraries Help Driver Library Overview
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 12
if (event == DRV_USART_BUFFER_EVENT_COMPLETE)
{
if (bufferHandle == pAppData->messageHandle)
{
pAppData->messageDone = true;
return;
}
}
/* Error */
return;
}
static bool SetupApplication ( void )
{
if (appData.usart == DRV_HANDLE_INVALID)
{
appData.usart = DRV_USART_Open(APP_USART_DRIVER_INDEX,
(DRV_IO_INTENT_READWRITE|DRV_IO_INTENT_NONBLOCKING));
}
if (appData.usart == DRV_HANDLE_INVALID)
{
return false;
}
DRV_USART_BufferEventHandlerSet(appData.usart, BufferDone, (uintptr_t)&appData);
return true;
}
This code block implements both the BufferDone callback function and the application’s SetupApplication state transition function. After
successfully opening the driver, the SetupApplication function calls the DRV_USART_BufferEventHandlerSet function and passes it the driver
handle (appData.usart) once it is valid, along with the address of the BufferDone callback function and a context value.
The context value can be anything that will fit in an integer large enough to hold a pointer (it is a uintptr_t variable). However, this parameter is
most commonly used to pass a pointer to the caller’s own data structure as demonstrated here (even though it is not strictly necessary). This is
done primarily to support multi-instance clients. (Refer to Volume IV: MPLAB Harmony Development > Key Concepts for information on multiple
instances.) A multi-instance client is designed to manage multiple instances of itself by allocating multiple instances of its own data structure, but
only one instance of its object code. Passing a pointer to the data structure in the context variable identifies the specific instance that was used
when calling the driver.
Once the callback function has been registered with the driver, the application can transition to a state where it attempts to initiate an
asynchronous operation. The following example demonstrates the use of a buffer-queuing write function to transmit a message over the USART.
Example Queuing a Buffer to a Driver
static bool MessageSend ( void )
{
appData.messageDone = false;
DRV_USART_BufferAddWrite(appData.usart, &appData.messageHandle,
appData.message, strlen(appData.message));
if (appData.messageHandle == DRV_USART_BUFFER_HANDLE_INVALID)
{
return false;
}
return true;
}
Before attempting to send the message, this implementation of the MessageSend state transition function clears the appData.messageDone
flag so it can detect when the message has completed. Then, it calls the DRV_USART_BufferAddWrite function to queue up the buffer containing
the message to be transmitted by the USART driver. To that function, it passes the USART driver handle (appData.usart), the address of the
appData.messageHandle variable, the pointer to the message buffer (appData.message), and the size of the buffer in bytes as calculated by
the strlen function. The USART driver then adds this buffer to its internal queue of buffers to transmit and provides a handle to the caller that
identifies that buffer’s place in the queue by storing it to the appData.messageHandle variable.
If, for some reason, the driver is unable to successfully queue up the buffer (perhaps the queue is full), it will assign a value of
DRV_USART_BUFFER_HANDLE_INVALID to the appData.messageHandle variable. If that happens, the MessageSend function returns false
and the application will stay in the same state and retry the operation again next time its tasks function is called. But, if the operation succeeds, the
application advances to the next state.
Once the driver completes the operation, it will call the client’s callback function. As shown in the BufferDone code example, the driver passes it
an enumeration value that identifies which event has just occurred (the DRV_USART_BUFFER_EVENT_COMPLETE value) in the event parameter. It
Volume V: MPLAB Harmony Framework Driver Libraries Help Driver Library Overview
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 13
also passes it the handle of the buffer that has just completed (bufferHandle). The client can use the bufferHandle value to verify that it
matches the value stored in the appData.bufferHandle variable to uniquely identify an individual buffer. This is very useful when a client
queues up multiple buffers at the same, which is being shown in this example as a demonstration.
The context parameter to the BufferDone function contains a pointer to the application’s global (appData) data structure. (This is the same
value that was passed in the context parameter to the DRV_USART_BufferEventHandlerSet function.) While not strictly necessary in this example,
it is very useful for multi-instance clients such as dynamic device drivers and middleware to identify which instance of the client requested the
operation. The callback function simply casts the context value back into a pointer to the client’s own data structure’s data type (APP_DATA in this
example) and uses it to access the structure members. (Again, please refer to Volume IV: MPLAB Harmony Development > Key Concepts for
information on multiple instances.)
The callback function uses the event parameter to identify why the callback occurred. If it was called to indicate that the buffer has been
processed, the event parameter will contain the value DRV_USART_BUFFER_EVENT_COMPLETE. If it contains any other value an error has
occurred. The BufferDone callback also checks to verify that the buffer that completed was the same buffer that it queued up by comparing the
bufferHandle value it was passed with the value assigned to the appData.messageHandle variable when the application called
DRV_USART_BufferAddWrite. It accesses the message handle value it saved using the pAppData pointer given to it through the context
parameter just. Once it has verified that the buffer it queued has completed, it sets the pAppData->messageDone flag to notify the application’s
state machine and execution returns to the driver.
Note:
It is important to understand that the MessageDone callback function executes in the context of the driver, not the application.
Depending on how the system is configured, this means that it may be called from within the driver’s ISR context or from another
thread context if using a RTOS.
In this example, the APP_Tasks application state machine function is essentially the same as the state machine for the synchronous example.
The only difference is that when the application is in the APP_STATE_MESSAGE_WAIT state, it checks the appData.messageDone flag to
determine when to close the driver and transition to the APP_STATE_DONE state instead of calling a transition function. (It could still do this in a
state transition function, but it was done differently in this example to emphasize the concept.)
The advantage of using an asynchronous interface over a synchronous one is that it allows the client’s state machine to continue on, potentially
doing something else while the requested operation completes. Whereas a synchronous interface has the possibility of blocking the client’s state
machine until the operation finishes (when used in a RTOS configuration). An asynchronous interface will always return immediately without
blocking (whether a RTOS is used or not). Because of this, most asynchronous interfaces will also allow queuing of more than one operation at a
time. This allows client applications to keep a driver continuously busy by keeping the driver’s queue full, maximizing data throughput or operation
speed. By contrast, a synchronous interface requires one operation to complete before the synchronous function can be called again to cause the
next one to begin.
The cost of this capability is that an asynchronous interface has the added complexity of a callback function (if the client cares when the operation
finishes) and the fact that a callback function may be called from within the driver’s ISR context, depending on how the driver was designed and
configured. This fact generally restricts what can be done within the callback function. For example, it is usually a bad idea to perform lengthy
processing within a callback function as it will block all lower priority ISRs (as well as the main loop or other threads) while that processing occurs.
Also, it is usually best to not call back into the driver’s own interface functions unless those functions are documented as being safe to call from
within the driver’s callback context. Many interface functions (particularly data transfer and data queuing functions) must use semaphores or
mutexes to protect their internal data structures in RTOS environments and those constructs cannot be used from within an ISR.
It is also important to not make non-atomic (read-modify-write) accesses to the client’s own state data from within the callback function, as the
client cannot protect itself against an interrupt that is owned by the driver. That is why a separate Boolean flag variable is commonly used to
indicate to the client that the callback has occurred. Most other processing should occur in the client’s state machine. It is usually best to simply
capture the event and return as quickly as possible from the callback function and let the application’s state machine tasks function perform any
lengthy processing or calling back into the driver.
Please refer to Volume IV: MPLAB Harmony Development for additional information.
Library Interface
Constants
Name Description
DRV_CONFIG_NOT_SUPPORTED Not supported configuration.
DRV_HANDLE_INVALID Invalid device handle.
DRV_IO_ISBLOCKING Returns if the I/O intent provided is blocking
DRV_IO_ISEXCLUSIVE Returns if the I/O intent provided is non-blocking.
DRV_IO_ISNONBLOCKING Returns if the I/O intent provided is non-blocking.
_DRV_COMMON_H This is macro _DRV_COMMON_H.
_PLIB_UNSUPPORTED Abstracts the use of the unsupported attribute defined by the compiler.
Data Types
Name Description
DRV_CLIENT_STATUS Identifies the current status/state of a client's connection to a driver.
DRV_HANDLE Handle to an opened device driver.
Volume V: MPLAB Harmony Framework Driver Libraries Help Driver Library Overview
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 14
DRV_IO_BUFFER_TYPES Identifies to which buffer a device operation will apply.
DRV_IO_INTENT Identifies the intended usage of the device when it is opened.
Description
Data Types
DRV_CLIENT_STATUS Enumeration
Identifies the current status/state of a client's connection to a driver.
File
driver_common.h
C
typedef enum {
DRV_CLIENT_STATUS_ERROR_EXTENDED = -10,
DRV_CLIENT_STATUS_ERROR = -1,
DRV_CLIENT_STATUS_CLOSED = 0,
DRV_CLIENT_STATUS_BUSY = 1,
DRV_CLIENT_STATUS_READY = 2,
DRV_CLIENT_STATUS_READY_EXTENDED = 10
} DRV_CLIENT_STATUS;
Members
Members Description
DRV_CLIENT_STATUS_ERROR_EXTENDED =
-10
Indicates that a driver-specific error has occurred.
DRV_CLIENT_STATUS_ERROR = -1 An unspecified error has occurred.
DRV_CLIENT_STATUS_CLOSED = 0 The driver is closed, no operations for this client are ongoing, and/or the given handle is
invalid.
DRV_CLIENT_STATUS_BUSY = 1 The driver is currently busy and cannot start additional operations.
DRV_CLIENT_STATUS_READY = 2 The module is running and ready for additional operations
DRV_CLIENT_STATUS_READY_EXTENDED =
10
Indicates that the module is in a driver-specific ready/run state.
Description
Driver Client Status
This enumeration identifies the current status/state of a client's link to a driver.
Remarks
The enumeration used as the return type for the client-level status routines defined by each device driver or system module (for example,
DRV_USART_ClientStatus) must be based on the values in this enumeration.
DRV_HANDLE Type
Handle to an opened device driver.
File
driver_common.h
C
typedef uintptr_t DRV_HANDLE;
Description
Device Handle
This handle identifies the open instance of a device driver. It must be passed to all other driver routines (except the initialization, deinitialization, or
power routines) to identify the caller.
Volume V: MPLAB Harmony Framework Driver Libraries Help Driver Library Overview
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 15
Remarks
Every application or module that wants to use a driver must first call the driver's open routine. This is the only routine that is absolutely required for
every driver.
If a driver is unable to allow an additional module to use it, it must then return the special value DRV_HANDLE_INVALID. Callers should check the
handle returned for this value to ensure this value was not returned before attempting to call any other driver routines using the handle.
DRV_IO_BUFFER_TYPES Enumeration
Identifies to which buffer a device operation will apply.
File
driver_common.h
C
typedef enum {
DRV_IO_BUFFER_TYPE_NONE = 0x00,
DRV_IO_BUFFER_TYPE_READ = 0x01,
DRV_IO_BUFFER_TYPE_WRITE = 0x02,
DRV_IO_BUFFER_TYPE_RW = DRV_IO_BUFFER_TYPE_READ|DRV_IO_BUFFER_TYPE_WRITE
} DRV_IO_BUFFER_TYPES;
Members
Members Description
DRV_IO_BUFFER_TYPE_NONE = 0x00 Operation does not apply to any buffer
DRV_IO_BUFFER_TYPE_READ = 0x01 Operation applies to read buffer
DRV_IO_BUFFER_TYPE_WRITE = 0x02 Operation applies to write buffer
DRV_IO_BUFFER_TYPE_RW =
DRV_IO_BUFFER_TYPE_READ|DRV_IO_BUFFER_TYPE_WRITE
Operation applies to both read and write buffers
Description
Device Driver IO Buffer Identifier
This enumeration identifies to which buffer (read, write, both, or neither) a device operation will apply. This is used for "flush" (or similar) operations.
DRV_IO_INTENT Enumeration
Identifies the intended usage of the device when it is opened.
File
driver_common.h
C
typedef enum {
DRV_IO_INTENT_READ,
DRV_IO_INTENT_WRITE,
DRV_IO_INTENT_READWRITE,
DRV_IO_INTENT_BLOCKING,
DRV_IO_INTENT_NONBLOCKING,
DRV_IO_INTENT_EXCLUSIVE,
DRV_IO_INTENT_SHARED
} DRV_IO_INTENT;
Members
Members Description
DRV_IO_INTENT_READ Read
DRV_IO_INTENT_WRITE Write
DRV_IO_INTENT_READWRITE Read and Write
DRV_IO_INTENT_BLOCKING The driver will block and will return when the operation is complete
DRV_IO_INTENT_NONBLOCKING The driver will return immediately
DRV_IO_INTENT_EXCLUSIVE The driver will support only one client at a time
DRV_IO_INTENT_SHARED The driver will support multiple clients at a time
Volume V: MPLAB Harmony Framework Driver Libraries Help Driver Library Overview
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 16
Description
Device Driver I/O Intent
This enumeration identifies the intended usage of the device when the caller opens the device. It identifies the desired behavior of the device
driver for the following:
• Blocking or non-blocking I/O behavior (do I/O calls such as read and write block until the operation is finished or do they return immediately and
require the caller to call another routine to check the status of the operation)
• Support reading and/or writing of data from/to the device
• Identify the buffering behavior (sometimes called "double buffering" of the driver. Indicates if the driver should maintain its own read/write
buffers and copy data to/from these buffers to/from the caller's buffers.
• Identify the DMA behavior of the peripheral
Remarks
The buffer allocation method is not identified by this enumeration. Buffers can be allocated statically at build time, dynamically at run-time, or even
allocated by the caller and passed to the driver for its own usage if a driver-specific routine is provided for such. This choice is left to the design of
the individual driver and is considered part of its interface.
These values can be considered "flags". One selection from each of the groups below can be ORed together to create the complete value passed
to the driver's open routine.
Constants
DRV_CONFIG_NOT_SUPPORTED Macro
Not supported configuration.
File
driver_common.h
C
#define DRV_CONFIG_NOT_SUPPORTED (((unsigned short) -1))
Description
Not supported configuration
If the configuration option is not supported on an instance of the peripheral, use this macro to equate to that configuration. This option should be
listed as a possible value in the description of that configuration option.
DRV_HANDLE_INVALID Macro
Invalid device handle.
File
driver_common.h
C
#define DRV_HANDLE_INVALID (((DRV_HANDLE) -1))
Description
Invalid Device Handle
If a driver is unable to allow an additional module to use it, it must then return the special value DRV_HANDLE_INVALID. Callers should check the
handle returned for this value to ensure this value was not returned before attempting to call any other driver routines using the handle.
Remarks
None.
Volume V: MPLAB Harmony Framework Driver Libraries Help Driver Library Overview
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 17
DRV_IO_ISBLOCKING Macro
Returns if the I/O intent provided is blocking
File
driver_common.h
C
#define DRV_IO_ISBLOCKING(intent) (intent & DRV_IO_INTENT_BLOCKING)
Description
Device Driver Blocking Status Macro
This macro returns if the I/O intent provided is blocking.
Remarks
None.
DRV_IO_ISEXCLUSIVE Macro
Returns if the I/O intent provided is non-blocking.
File
driver_common.h
C
#define DRV_IO_ISEXCLUSIVE(intent) (intent & DRV_IO_INTENT_EXCLUSIVE)
Description
Device Driver Exclusive Status Macro
This macro returns if the I/O intent provided is non-blocking.
Remarks
None.
DRV_IO_ISNONBLOCKING Macro
Returns if the I/O intent provided is non-blocking.
File
driver_common.h
C
#define DRV_IO_ISNONBLOCKING(intent) (intent & DRV_IO_INTENT_NONBLOCKING )
Description
Device Driver Non Blocking Status Macro
This macro returns if the I/ intent provided is non-blocking.
Remarks
None.
_DRV_COMMON_H Macro
File
driver_common.h
C
#define _DRV_COMMON_H
Volume V: MPLAB Harmony Framework Driver Libraries Help Driver Library Overview
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 18
Description
This is macro _DRV_COMMON_H.
_PLIB_UNSUPPORTED Macro
Abstracts the use of the unsupported attribute defined by the compiler.
File
driver_common.h
C
#define _PLIB_UNSUPPORTED
Description
Unsupported Attribute Abstraction
This macro nulls the definition of the _PLIB_UNSUPPORTED macro, to support compilation of the drivers for all different variants.
Remarks
None.
Example
void _PLIB_UNSUPPORTED PLIB_USART_Enable(USART_MODULE_ID index);
This function will not generate a compiler error if the interface is not defined for the selected device.
Files
Files
Name Description
driver.h This file aggregates all of the driver library interface headers.
driver_common.h This file defines the common macros and definitions used by the driver definition and
implementation headers.
Description
driver.h
This file aggregates all of the driver library interface headers.
Description
Driver Library Interface Header Definitions
Driver Library Interface Header This file aggregates all of the driver library interface headers so client code only needs to include this one single
header to obtain prototypes and definitions for the interfaces to all driver libraries. A device driver provides a simple well-defined interface to a
hardware peripheral that can be used without operating system support or that can be easily ported to a variety of operating systems. A driver has
the fundamental responsibilities:
• Providing a highly abstracted interface to a peripheral
• Controlling access to a peripheral
• Managing the state of a peripheral
Remarks
The directory in which this file resides should be added to the compiler's search path for header files.
File Name
drv.h
Company
Microchip Technology Inc.
Volume V: MPLAB Harmony Framework Driver Libraries Help Driver Library Overview
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 19
driver_common.h
This file defines the common macros and definitions used by the driver definition and implementation headers.
Enumerations
Name Description
DRV_CLIENT_STATUS Identifies the current status/state of a client's connection to a driver.
DRV_IO_BUFFER_TYPES Identifies to which buffer a device operation will apply.
DRV_IO_INTENT Identifies the intended usage of the device when it is opened.
Macros
Name Description
_DRV_COMMON_H This is macro _DRV_COMMON_H.
_PLIB_UNSUPPORTED Abstracts the use of the unsupported attribute defined by the compiler.
DRV_CONFIG_NOT_SUPPORTED Not supported configuration.
DRV_HANDLE_INVALID Invalid device handle.
DRV_IO_ISBLOCKING Returns if the I/O intent provided is blocking
DRV_IO_ISEXCLUSIVE Returns if the I/O intent provided is non-blocking.
DRV_IO_ISNONBLOCKING Returns if the I/O intent provided is non-blocking.
Types
Name Description
DRV_HANDLE Handle to an opened device driver.
Description
Driver Common Header Definitions
This file defines the common macros and definitions used by the driver definition and the implementation header.
Remarks
The directory in which this file resides should be added to the compiler's search path for header files.
File Name
drv_common.h
Company
Microchip Technology Inc.
ADC Driver Library
This section describes the Analog-to-Digital Converter (ADC) Driver Library.
Introduction
This Analog-to-Digital Converter (ADC) driver provides an interface to manage the ADC module on the Microchip family of microcontrollers.
Description
An ADC is a vital part of any system that interfaces to real-world signals. While there are many techniques for analog-to-digital conversion, the
Microchip family of microcontrollers uses Successive Approximation as one of its primary techniques.
Through MHC, this driver provides APIs to interact with the ADC module.
Note:
Only Static implementation is supported for the ADC Driver Library.
Volume V: MPLAB Harmony Framework Driver Libraries Help ADC Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 20
Library Interface
Functions
Name Description
DRV_ADC_Deinitialize Deinitializes the DRV_ADC_Initialize driver module
Implementation: Static
DRV_ADC_Initialize Initializes the ADC driver.
Implementation: Static
DRV_ADC_SamplesAvailable Identifies if specified ADC Driver input has any samples available to read.
Implementation: Static
DRV_ADC_SamplesRead Reads the converted sample data from ADC input Data buffer.
Implementation: Static
DRV_ADC_Start Starts the software trigger for the ADC driver sampling and converting analog to digital values.
Implementation: Static
DRV_ADC_Stop Stops the Global Software Level Trigger from continuing triggering for converting ADC data.
Implementation: Static
DRV_ADCx_Close Closes the ADC instance for the specified driver index.
Implementation: Static
DRV_ADCx_Open Opens the ADC instance for the specified driver index.
Implementation: Static
Description
This section lists the interface routines, data types, constants and macros for the library.
Functions
DRV_ADC_Deinitialize Function
Deinitializes the DRV_ADC_Initialize driver module
Implementation: Static
File
help_drv_adc.h
C
void DRV_ADC_Deinitialize();
Returns
None.
Description
This function deinitializes the ADC Driver module for the specified driver instance, making it ready for clients to use it. The initialization routine is
specified by the MHC parameters.
Remarks
None.
Preconditions
None.
Function
void DRV_ADC_Deinitialize(void)
DRV_ADC_Initialize Function
Initializes the ADC driver.
Implementation: Static
Volume V: MPLAB Harmony Framework Driver Libraries Help ADC Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 21
File
help_drv_adc.h
C
void DRV_ADC_Initialize();
Returns
None.
Description
This function initializes the ADC Driver module for the specified driver instance, making it ready for clients to use it. The initialization routine is
specified by the MHC parameters.
Remarks
This function must be called before any other ADC function is called. This function should only be called once during system initialization.
Preconditions
None.
Function
void DRV_ADC_Initialize(void)
DRV_ADC_SamplesAvailable Function
Identifies if specified ADC Driver input has any samples available to read.
Implementation: Static
File
help_drv_adc.h
C
bool DRV_ADC_SamplesAvailable(uint8_t bufIndex);
Returns
• true - When ADC data buffer is available to be read
• false - When ADC data buffer is not available
Description
This function identifies whether the specified ADC Driver input has any samples available to read.
Remarks
None.
Preconditions
The following functions have been called:
• DRV_ADC_Initialize
• DRV_ADCx_Open
• DRV_ADC_Start or other triggered by source setup in MHC
Parameters
Parameters Description
uint8_t bufIndex ADC input number (ANx)
Function
bool DRV_ADC_SamplesAvailable(uint8_t bufIndex);
DRV_ADC_SamplesRead Function
Reads the converted sample data from ADC input Data buffer.
Implementation: Static
Volume V: MPLAB Harmony Framework Driver Libraries Help ADC Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 22
File
help_drv_adc.h
C
uint32_t DRV_ADC_SamplesRead(uint8_t bufIndex);
Returns
uint32_t - ADC converted sample data.
Description
This function returns the converted sample data from ADC input Data buffer.
Remarks
None.
Preconditions
The following functions have been called:
• DRV_ADC_Initialize
• DRV_ADCx_Open
• DRV_ADC_Start or other triggered by source setup in MHC
Parameters
Parameters Description
uint8_t bufIndex Analog input number (ANx)
Function
uint32_t DRV_ADC_SamplesRead(uint8_t bufIndex);
DRV_ADC_Start Function
Starts the software trigger for the ADC driver sampling and converting analog to digital values.
Implementation: Static
File
help_drv_adc.h
C
void DRV_ADC_Start();
Returns
None.
Description
This function provides a global edge and level trigger for the ADC driver to start the conversion.
Remarks
None.
Preconditions
The following functions have been called:
• DRV_ADC_Initialize
• DRV_ADCx_Open
Function
void DRV_ADC_Start(void);
DRV_ADC_Stop Function
Stops the Global Software Level Trigger from continuing triggering for converting ADC data.
Implementation: Static
Volume V: MPLAB Harmony Framework Driver Libraries Help ADC Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 23
File
help_drv_adc.h
C
void DRV_ADC_Stop();
Returns
None.
Description
This function stops the Global Software Level Trigger from continuing triggering for converting ADC data.
Remarks
None.
Preconditions
The following functions have been called:
• DRV_ADC_Initialize
• DRV_ADCx_Open
Function
void DRV_ADC_Stop(void);
DRV_ADCx_Close Function
Closes the ADC instance for the specified driver index.
Implementation: Static
File
help_drv_adc.h
C
void DRV_ADCx_Close();
Returns
None.
Description
This function closes the specified driver instance (where 'x' is the instance number) making it ready for clients to use it.
Remarks
'x' indicates the instance number.
Preconditions
DRV_ADC_Initialize has been called.
Function
void DRV_ADCx_Close(void)
DRV_ADCx_Open Function
Opens the ADC instance for the specified driver index.
Implementation: Static
File
help_drv_adc.h
C
void DRV_ADCx_Open();
Volume V: MPLAB Harmony Framework Driver Libraries Help ADC Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 24
Returns
None.
Description
This function opens the specified driver instance (where 'x' is the instance number) making it ready for clients to use it.
Remarks
'x' indicates the instance number.
Preconditions
DRV_ADC_Initialize has been called.
Function
void DRV_ADCx_Open(void)
Bluetooth Driver Libraries
This section describes the Bluetooth Driver Libraries that are included in your installation of MPLAB Harmony.
BM64 Bluetooth Driver Library
This section describes the BM64 Bluetooth Driver Library.
Introduction
This library provides an Applications Programming Interface (API) to manage a BM64 Module that is connected to a Microchip PIC32
microcontroller using UART and I²S for providing Bluetooth solutions for audio and Bluetooth Low Energy (BLE) applications.
Description
The BM64 is a Bluetooth 4.2 Stereo Module that supports classic A2DP, AVRCP, HFP, HSP, and SPP protocols, as well as Bluetooth Low Energy
(BLE).
The BM64 streams I2S audio at up to 24-bit and 96 kHz, and uses a UART to receive commands from the host microcontroller (PIC32) and send
events back over the same interface.
Protocols supported by the BM64 include A2DP, AVRCP, HFP, HSP, SPP, and BLE. However, this version of the driver only supports A2DP,
AVRCP, HFP, and BLE.
The BM64 can be connected to a microphone (for HFP) and also has line-input; however, the latter is not supported by this driver. The
multi-speaker modes of the BM64 are also not handled by this driver.
A typical interface of BM64 to a Microchip PIC32 device is provided in the following diagram:
Volume V: MPLAB Harmony Framework Driver Libraries Help Bluetooth Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 25
BM64 to PIC32 Device Interface
An example demonstration application using this library to interface with the BM64 for audio is BM64_a2dp_hfp, which runs on the PIC32
Bluetooth Audio Development Kit and is used to stream A2DP audio from a Bluetooth host such as a smartphone to a pair of headphones
connected to the Audio DAC Daughter Board which comes with the PIC32 Bluetooth Audio Development Kit. The smartphone is controlled using
the AVRCP functions of the library. That demonstration can also automatically answer a voice call coming in via Hands-Free Protocol (HFP),
interrupting (and pausing) any A2DP streaming in progress.
An example demonstration application using this library to interface with the BM64 for BLE functionality is BM64_ble_comm, which is used to send
a string of characters to a smartphone when one of the push buttons is pressed on the PIC32 Bluetooth Audio Development Kit, and to receive a
string of characters from the smartphone and display them on the LCD of the PIC32 Bluetooth Audio Development Kit, both using the "Transparent
Service" feature of the BM64.
The following diagram shows the specific connections used in the PIC32 Bluetooth Audio Development Kit, which uses a PIC32MX470F512L
microcontroller:
PIC32 Device and Module Connections
Volume V: MPLAB Harmony Framework Driver Libraries Help Bluetooth Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 26
Using the Library
This topic describes the basic architecture of the BM64 Bluetooth Driver Library and provides information and examples on its use.
Description
Interface Header File: drv_bm64.h
The interface to the BM64 Bluetooth Driver library is defined in the drv_bm64.h header file. Any C language source (.c) file that uses the BM64
Bluetooth Driver library should include this header.
Please refer to the What is MPLAB Harmony? section for how the driver interacts with the framework.
Library Source Files:
The BM64 Bluetooth Driver Library source files are provided in the \framework\driver\bluetooth\bm64\src directory.
This folder may contain optional files and alternate implementations. Please refer to Configuring the Library for instructions on how to select
optional features. and to Building the Library for instructions on how to build the library.
When the library is being used to stream A2DP audio from the BM64 to the PIC32, the BM64 must be configured as a I2S slave device. See the
application BM64_bootloader demonstration application for instructions on how to do this.
Abstraction Model
This library provides a low-level abstraction of the BM64 Bluetooth Driver Library on the Microchip family microcontrollers with a convenient C
language interface. This topic describes how that abstraction is modeled in software and introduces the library's interface.
Description
The abstraction model shown in the following diagram depicts how the BM64 Bluetooth Driver is positioned in the MPLAB Harmony framework.
The BM64 Bluetooth Driver uses the USART Driver Library to control the BM64 and receive event notifications, the I2S Driver Library is used to
receive audio from the BM64, and the Timer Driver for periodic timing.
BM64 Bluetooth Driver Abstraction Model
Volume V: MPLAB Harmony Framework Driver Libraries Help Bluetooth Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 27
Library Overview
Refer to the Driver Library Overview section for information on how the driver operates in a system.
The BM64 Bluetooth Driver Library provides an API interface to transfer control commands and digital audio data to the serially interfaced BM64
Bluetooth module. The library interface routines are divided into various sub-sections, which address one of the blocks or the overall operation of
the BM64 Bluetooth Driver Library.
Library Interface Section Description
System Functions Provides system module interfaces, device initialization, tasks and status functions.
Client Setup Functions Provides open and close functions.
Data Transfer Functions Provides data transfer functions.
Settings Functions Provides driver specific functions for settings, such as volume control and sampling rate.
Bluetooth-specific Functions Provides functions that are Bluetooth-specific.
AVRCP Functions Provides functions that are used for AVRCP control.
Device Name and Address Functions Provides functions for getting and setting the Bluetooth name and address.
BLE Functions Provides BLE-specific functions.
How the Library Works
Provides information on how the library works.
Description
The library provides interfaces to support:
• System
• Client Setup
• Data Transfer
• Settings
• Bluetooth
• AVRCP
• Device Name and Address
• BLE
The library can be used by programs providing functionality for audio (A2DP, AVRCP and BLE), or BLE, or both.
For audio (A2DP/AVRCP/HFP), typically, there will be one simple state machine for the application and a second state machine just for the audio.
After the application initializes, the audio state machine will open the BM64 Bluetooth Driver using a call to its Open function. Then, it will set up
callbacks for each of two event handlers, and then open the codec driver using a call to its Open function and set up a callback from it. Then, the
driver will wait until the BM64 initialization is complete, at which time the application state machine instructs the audio state machine to perform an
initial buffer read from the BM64 using an AddRead call.
case AUDIO_STATE_OPEN:
{
if (SYS_STATUS_READY == DRV_BT_Status())
{
// open BT module, including RX audio stream
audioData.bt.handle = DRV_BT_Open(DRV_IO_INTENT_READ, DRV_BT_PROTOCOL_ALL);
if(audioData.bt.handle != DRV_HANDLE_INVALID)
{
audioData.state = AUDIO_STATE_SET_BT_BUFFER_HANDLER;
}
}
}
break;
case AUDIO_STATE_SET_BT_BUFFER_HANDLER:
{
DRV_BT_BufferEventHandlerSet(audioData.bt.handle, audioData.bt.bufferHandler,
audioData.bt.context);
DRV_BT_EventHandlerSet(audioData.bt.handle, audioData.bt.eventHandler, (uintptr_t)0);
audioData.state = AUDIO_STATE_CODEC_OPEN;
}
break;
case AUDIO_STATE_CODEC_OPEN:
Volume V: MPLAB Harmony Framework Driver Libraries Help Bluetooth Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 28
{
audioData.codec.handle = DRV_CODEC_Open(DRV_CODEC_INDEX_0, DRV_IO_INTENT_WRITE |
DRV_IO_INTENT_EXCLUSIVE);
if(audioData.codec.handle != DRV_HANDLE_INVALID)
{
audioData.state = AUDIO_STATE_CODEC_SET_BUFFER_HANDLER;
}
}
break;
case AUDIO_STATE_CODEC_SET_BUFFER_HANDLER:
{
_setCodecSamplingRate(DRV_BT_AUDIO_SAMPLING_RATE);
DRV_CODEC_BufferEventHandlerSet(audioData.codec.handle, audioData.codec.bufferHandler,
audioData.codec.context);
audioData.state = AUDIO_STATE_INIT_DONE;
}
break;
case AUDIO_STATE_INIT_DONE:
{
// waits in this state until BT initialization done and app state machine
// calls audioStart() to set state to AUDIO_STATE_BT_SUBMIT_INITIAL_READS
break;
}
After the initial buffer read has been completed, the buffer event handler for the BM64 will get a DRV_BT_BUFFER_EVENT_COMPLETE event.
Once the queue has filled up, this will advance the audio state machine’s state so that it adds the buffer to the codec’s queue using its AddWrite
function call. It then also makes a new call to the AddRead function to keep the queue filled.
When the buffer event handler for the codec gets a DRV_CODEC_BUFFER_EVENT_COMPLETE event, it will mark the buffer free for use again.
See the BM64 demonstration application, BM64_a2dp_hfp, for more information and more example code.
BLE-only applications are much simpler since they do not have to process any audio. Again typically there will be one simple state machine for the
application and a second state machine just for the BLE functionality. After the application initializes, the BLE state machine will open the BM64
Bluetooth driver using a call to its Open function, then it will set up a callback for an event handler.
The application will call one of the BLE Send functions to send data to the host (smartphone). The event handler will be called whenever data has
been received from the BM64, or when the connection status changes. See the BM64 demonstration application, BM64_ble_comm, for more
information and example code.
System Functions
This section describes the BM64 Bluetooth driver functions for initialization, maintaining task state and returning status.
Description
Initialization
The function DRV_BM64_Initialize is called by the function SYS_Initialize, in the file system_init.c, to initialize the BM64 Bluetooth driver using
constants from the generated system_config.h file.
Tasks
The function DRV_BM64_Tasks is called from the System Task Service via the function SYS_Tasks in the file system_tasks.c to maintain the
driver's internal control and data interface state machine.
One can use the function DRV_BM64_TasksReq to make a power on/power off task request (DRV_BM64_REQ_SYSTEM_OFF or
DRV_BM64_REQ_SYSTEM_ON).
Status
The function DRV_BM64_Status returns the BM64 Bluetooth driver status, such as SYS_STATUS_READY, SYS_STATUS_BUSY, or
SYS_STATUS_ERROR. The driver should not be opened until it has been marked ready.
Example:
// note generic version of call (DRV_BT instead of DRV_BM64) is used
if (SYS_STATUS_READY == DRV_BT_Status())
{
// This means the driver can be opened using the
// DRV_BT_Open() function.
}
The BM64-specific function DRV_BM64_GetPowerStatus returns the current power status, e.g. DRV_BM64_STATUS_OFF,
DRV_BM64_STATUS_OFF, and DRV_BM64_STATUS_READY. Once it returns a ready status, this means the BM64 driver has completed its
internal state machine initialization and can begin processing audio.
Volume V: MPLAB Harmony Framework Driver Libraries Help Bluetooth Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 29
Example:
case APP_STATE_WAIT_INIT:
{
// note generic version of call (DRV_BT instead of DRV_BM64) is used
if (DRV_BT_STATUS_READY == DRV_BT_GetPowerStatus())
{
appData.state=APP_STATE_IDLE;
// can start processing audio
}
}
Client Functions
This section describes the BM64 Bluetooth driver functions for client setup (open, close, and setting up event handlers).
Description
Open and Close
For the application to start using an instance of the module, it must call the DRV_BM64_Open function which provides a driver handle to the BM64
Bluetooth driver instance.
Note:
It is necessary to check the status of driver initialization before opening a driver instance. The status of the BM64 Bluetooth Driver
can be known by calling DRV_BM64_Status.
Example:
case AUDIO_STATE_OPEN:
{
if (SYS_STATUS_READY == DRV_BT_Status())
{
// open BT module, including RX audio stream
audioData.bt.handle = DRV_BT_Open(DRV_IO_INTENT_READ, DRV_BT_PROTOCOL_ALL);
if(audioData.bt.handle != DRV_HANDLE_INVALID)
{
audioData.state = AUDIO_STATE_SET_BT_BUFFER_HANDLER;
}
}
}
Event Handlers
Event handlers are functions in the user’s code that are used as callbacks from the driver when something occurs that the client needs to know
about.
The function DRV_BM64_BufferEventHandlerSet is called by a client to identify a buffer-related event handling function for the driver to call back.
The prototype for the callback is defined by DRV_BM64_BUFFER_EVENT_HANDLER. The callback will be called with the event
DRV_BT_BUFFER_EVENT_COMPLETE.
The function DRV_BM64_EventHandlerSet is called by a client to identify a general event handling function for the driver to call back. The
prototype for the callback is defined by DRV_BM64_EVENT_HANDLER.
For audio applications, the callback will be called with events such as DRV_BT_EVENT_VOLUME_CHANGED,
DRV_BT_EVENT_SAMPLERATE_CHANGED, and DRV_BT_EVENT_PLAYBACK_STATUS_CHANGED. For BLE applications, the callback will
be called for events such as DRV_BT_EVENT_BLESPP_MSG_RECEIVED and DRV_BT_EVENT_BLE_STATUS_CHANGED.
Example:
case APP_STATE_SET_BT_BUFFER_HANDLER:
{
// note generic version of calls (DRV_BT instead of DRV_BM64) are used
DRV_BT_BufferEventHandlerSet(appData.bt.handle, appData.bt.bufferHandler,
appData.bt.context);
DRV_BT_EventHandlerSet(appData.bt.handle, appData.bt.eventHandler, (uintptr_t)0);
appData.state = APP_STATE_CODEC_OPEN;
}
Data Transfer Function
This section describes the BM64 Bluetooth Driver data transfer function.
Description
The function DRV_BM64_BufferAddRead schedules a non-blocking read operation. It returns with a valid buffer handle in the bufferHandle
Volume V: MPLAB Harmony Framework Driver Libraries Help Bluetooth Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 30
argument if the read request was scheduled successfully.
If the requesting client registered an event callback with the driver, the driver will issue a DRV_BM64_BUFFER_EVENT_COMPLETE event if the
buffer was processed successfully or DRV_BM64_BUFFER_EVENT_ERROR event if the buffer was not processed successfully.
Example:
case APP_STATE_BT_BUFFER_COMPLETE:
{
if (!_bufferUsed[appData.readIndex])
{
//Next BT Read Queued
// note generic version of call (DRV_BT instead of DRV_BM64) is used
DRV_BT_BufferAddRead(appData.bt.handle, &appData.bt.readBufHandle,
audioBuffer[appData.readIndex], appData.bt.bufferSize);
if(appData.bt.readBufHandle != DRV_BT_BUFFER_HANDLE_INVALID)
{
appData.bt.readBufHandle = DRV_BT_BUFFER_HANDLE_INVALID;
_bufferUsed[appData.readIndex] = true;
appData.readIndex++;
if(appData.readIndex >= AUDIO_QUEUE_SIZE)
{
appData.readIndex = 0;
}
appData.state = APP_STATE_BT_WAIT_FOR_BUFFER_COMPLETE;
}
}
}
Settings Functions
This section describes the BM64 Bluetooth Driver functions for getting and changing settings such as volume and sample rate.
Description
The function DRV_BM64_VolumeGet returns the volume for the current mode (A2DP or HFP) in percent (0-100), and the corresponding function
DRV_BM64_VolumeSet sets the volume in percent.
The functions DRV_BM64_VolumeUp and DRV_BM64_VolumeDown turn the volume up and down on the host device (e.g. smartphone) by one
increment (about 3% of full-scale). Either of these will result in a callback with the event DRV_BM64_EVENT_VOLUME_CHANGED specifying the
new volume setting.
Example:
case BUTTON_STATE_PRESSED: // (debouncing not shown)
{
// bump the volume up one notch based on a button press
if (BSP_SwitchStateGet(BSP_SWITCH_2)==BSP_SWITCH_STATE_PRESSED))
{
// note generic version of call (DRV_BT instead of DRV_BM64) is used
DRV_BT_volumeUp(appData.bt.handle);
appData.buttonState=BUTTON_STATE_WAIT_FOR_RELEASE;
}
}
. . .
// later, a call will come back to the event handler callback function
// (previously set up via a call to DRV_BM64_EventHandlerSet)
static void _BLEEventHandler(DRV_BT_EVENT event, uint32_t param, uintptr_t context)
{
switch(event)
{
case DRV_BM64_EVENT_VOLUME_CHANGED:
{
uint16_t volume7bits = (127*param)/100; // convert to 7 bits
DRV_AK4384_VolumeSet(audioData.codec.handle, // update codec’s volume
DRV_AK4384_CHANNEL_LEFT_RIGHT,volume7bits);
laString tempStr;
char buf[5];
sprintf(buf,"%3d%%",param);
laWidget_SetVisible((laWidget*)GFX_VOLUME_VALUE, LA_TRUE);
tempStr = laString_CreateFromCharBuffer(buf, &LiberationSans12);
laLabelWidget_SetText(GFX_VOLUME_VALUE, tempStr); // update screen
Volume V: MPLAB Harmony Framework Driver Libraries Help Bluetooth Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 31
laString_Destroy(&tempStr);
}
}
}
Sample Rate
This section describes the functions for getting and setting the sampling rate (e.g., 8000, 44100, or 48000 Hz) as a 32-bit integer.
Description
The function DRV_BM64_EnterBTPairingMode is used to enter into pairing mode. Once the BM64 is paired with a device, it will automatically
attempt to connect with it again on the next power cycle.
Calling DRV_BM64_DisconnectAllLinks will disconnect the BM64 from the host (smartphone) but will not erase the pairing. So another call to the
function DRV_BM64_LinkLastDevice will reconnect. However calling the function DRV_BM64_ForgetAllLinks will erase all pairing information, and
another call to DRV_BM64_EnterBTPairingMode will be required to re-establish a connection.
Example:
case BUTTON_STATE_PRESSED: // (debouncing not shown)
{
// initiate pairing with a button press
if (BSP_SwitchStateGet(BSP_SWITCH_1)==BSP_SWITCH_STATE_PRESSED))
{
// note generic version of call (DRV_BT instead of DRV_BM64) is used
DRV_BT_EnterBTPairingMode(appData.bt.handle);
appData.buttonState=BUTTON_STATE_WAIT_FOR_RELEASE;
}
}
The function DRV_BM64_GetLinkStatus returns the current link status, returning an 8-bit value containing the current link status defined by
DRV_BM64_LINKSTATUS enum. This can be used to restrict calls to AVRCP functions only when an AVRCP link is established.
Example:
// note generic version of call (DRV_BT instead of DRV_BM64) is used
if (DRV_BT_GetLinkStatus(appData.bt.handle) & DRV_BT_AVRCP_LINK_STATUS)
{
DRV_BT_CancelForwardOrRewind(appData.bt.handle);
}
AVRCP Functions
This section describes the functions for getting and setting the Bluetooth device’s name and address.
Description
The function DRV_BM64_SetBDName is called to set a temporary Bluetooth device name from an ASCII string buffer. The function
DRV_BM64_GetBDName is called to get the current Bluetooth device name, and DRV_BM64_GetBDAddress is called to get the Bluetooth device
address.
Example:
laString tempStr;
char buf [DRV_BT_MAXBDNAMESIZE+1];
// note generic version of calls (DRV_BT instead of DRV_BM64) are used
DRV_BT_GetBDName(appData.bt.handle, buf, DRV_BT_MAXBDNAMESIZE+1);
tempStr = laString_CreateFromCharBuffer(buf, &LiberationSans12);
laLabelWidget_SetText(GFX_BTNAME_VALUE, tempStr); // display BT name
laString_Destroy(&tempStr);
DRV_BT_GetBDAddress(appData.bt.handle, buf);
tempStr = laString_CreateFromCharBuffer(buf, &LiberationSans12);
laLabelWidget_SetText(GFX_BTADDRESS_VALUE, tempStr); // display BT address
laString_Destroy(&tempStr);
BLE Functions
This section describes the functions specific to Bluetooth Low Energy (BLE) operations, such as sending and receiving data, and BLE
connection-related operations.
Description
The function DRV_BM64_ReadByteFromBLE is used to receive data one byte at a time; the function DRV_BM64_ReadDataFromBLE is used to
receive multiple bytes. Each of them return a Boolean, which is true if data is returned or false if there is no data to return. You can use the
function DRV_BM64_ClearBLEData to clear out the receive buffer before starting.
Volume V: MPLAB Harmony Framework Driver Libraries Help Bluetooth Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 32
Example:
uint8_t byte;
// note generic versions of calls (DRV_BT instead of DRV_BM64) are used
DRV_BT_ClearBLEData(appData.bt.handle);
// wait for byte to arrive
while (!DRV_BT_ReadByteFromBLE(appData.bt.handle, &byte))
{
// should have some sort of way to break out of here if byte never arrives
}
Sending Data
The function DRV_BM64_SendByteOverBLE Is used to send one byte of data at a time; the function DRV_BM64_SendDataOverBLE is used to
send multiple bytes of data.
Example:
#define BUFSIZE 100
uint8_t buf [BUFSIZE];
// (code goes here to fill in buffer with data)
// note generic version of call (DRV_BT instead of DRV_BM64) is used
DRV_BT_SendDataOverBLE(appData.bt.handle, buf, BUFSIZE);
Connection Status
The function DRV_BM64_BLE_EnableAdvertising is called to enable or disable BLE advertising.
The function DRV_BM64_BLE_QueryStatus queries the BM64 to respond with a DRV_BM64_EVENT_BLE_STATUS_CHANGED event, which
will indicate if the BM64 BLE status is standby, advertising, scanning or connected.
Example:
// note generic version of call (DRV_BT instead of DRV_BM64) is used
DRV_BT_BLE_QueryStatus(appData.bt.handle);
. . .
// later, a call will come back to the event handler callback function
// (previously set up via a call to DRV_BM64_EventHandlerSet)
static void _BLEEventHandler(DRV_BT_EVENT event, uint32_t param, uintptr_t context)
{
switch(event)
{
case DRV_BT_EVENT_BLE_STATUS_CHANGED:
{
// do case switch based on param variable
switch(param)
{
case DRV_BM64_BLE_STATUS_STANDBY:
case DRV_BM64_BLE_STATUS_SCANNING:
laWidget_SetVisible((laWidget*)GFX_CONNECTED, LA_FALSE);
laWidget_SetVisible((laWidget*)GFX_PAIRED, LA_FALSE);
laWidget_SetVisible((laWidget*)GFX_NOPAIR_NOCONNECTION, LA_TRUE);
break;
case DRV_BM64_BLE_STATUS_ADVERTISING:
laWidget_SetVisible((laWidget*)GFX_CONNECTED, LA_FALSE);
laWidget_SetVisible((laWidget*)GFX_PAIRED, LA_TRUE); // actually, advertising
laWidget_SetVisible((laWidget*)GFX_NOPAIR_NOCONNECTION, LA_FALSE);
break;
case DRV_BM64_BLE_STATUS_CONNECTED:
laWidget_SetVisible((laWidget*)GFX_CONNECTED, LA_TRUE);
laWidget_SetVisible((laWidget*)GFX_PAIRED, LA_FALSE);
laWidget_SetVisible((laWidget*)GFX_NOPAIR_NOCONNECTION, LA_FALSE);
break;
}
}
}
Configuring the Library
Macros
Name Description
INCLUDE_BM64_BLE Identifies whether the driver should include BLE
Volume V: MPLAB Harmony Framework Driver Libraries Help Bluetooth Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 33
INCLUDE_BM64_I2S Identifies whether the driver should include HFP,A2DP,AVRCP functionality.
INCLUDE_DEPRECATED_MMI_COMMANDS Identifies whether the driver should use deprecated MMI commands.
Description
The configuration of the BM64 Bluetooth Driver is based on the file system_config.h.
This header file contains the configuration selection for the BM64 Bluetooth Driver. Based on the selections made, the driver may support the
selected features. These configuration settings will apply to all instances of the BM64 Bluetooth Driver.
This header can be placed anywhere, the path of this header needs to be present in the include search path for a successful build. Refer to the
Applications Help section for more details.
INCLUDE_BM64_BLE Macro
Identifies whether the driver should include BLE
File
drv_bm64_config_template.h
C
#define INCLUDE_BM64_BLE
Description
Include BLE features?
Identifies whether the driver should include BLE (Bluetooth Low Energy) functions.
This option currently does not have any effect on the code size.
true (checked, default) - include BLE functionality. false (unchecked) - do not include BLE functionality.
Remarks
None
INCLUDE_BM64_I2S Macro
Identifies whether the driver should include HFP,A2DP,AVRCP functionality.
File
drv_bm64_config_template.h
C
#define INCLUDE_BM64_I2S
Description
Include HFP,A2DP,AVRCP protocols?
Identifies whether the driver should include the interface to support HFP, A2DP and AVRCP protocols, which by default also brings in the I2S
driver and the default codec based on the BSP selected.
If you are building a BLE-only application, uncheck this option.
true (checked, default) - include HFP,A2DP,AVRCP functionality. false (unchecked) - do not include HFP,A2DP,AVRCP functionality.
Remarks
None
INCLUDE_DEPRECATED_MMI_COMMANDS Macro
Identifies whether the driver should use deprecated MMI commands.
File
drv_bm64_config_template.h
C
#define INCLUDE_DEPRECATED_MMI_COMMANDS
Volume V: MPLAB Harmony Framework Driver Libraries Help Bluetooth Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 34
Description
Use Deprecated MMI Commands?
There are currently two versions of the BM64 Audio UART Command Set, which is used by the PIC32 to send commands to the BM64 module
and receive responses (events) back from the BM64. The original is version 1.00 and the updated one is version 2.0x. Version 2.0x deprecates
some MMI commands, and adds some new commands to replace them.
If the DRV_BM64_PlayPreviousSong and DRV_BM64_PlayNextSong functions are not working but other AVRCP functions are working properly,
try unchcing this option.
true (checked, default) - use deprecated MMI commands. false (unchecked) - do not deprecated MMI commands.
Remarks
None
Configuring the MHC
Provides examples on how to configure the MPLAB Harmony Configurator (MHC) for a specific driver.
Description
The following figure shows an example MHC configuration for the BM64 Bluetooth Driver.
The option Include HFP,A2DP,AVRCP protocols? identifies whether the driver should include the interface to support HFP, A2DP and AVRCP
protocols, which by default also brings in the I2S driver and the default codec based on the BSP selected. If you are building a BLE-only
application, uncheck this option.
The option Include BLE features? identifies whether the driver should include BLE functions. If you are not using any BLE functionality, uncheck
this option.
When Use BM64 Driver? is selected, and you have already selected the PIC32 Bluetooth Audio Development Kit (AK4384), the proper
configuration for the AK4384, I2S, and Timer will have already been made for you, including:
• Under Drivers/CODEC,
• Use_Codec_AK4384 selected
• I2S Driver (used for data interface interface) instance set to DRV_I2S_INDEX_1
• Under I2S,
• Use I2S Driver Selected
• DMA Mode Selected
• Transmit DMA Support Selected
• Receive DMA Support Selected
• Enable DMA Channel Interrupts selected
• Sampling Rate set to 8000
• Number of I2S Instances set to 2
• I2S Driver Instance 0 selected
• I2S Module ID set to SPI_ID_2 (BM64 Module as wired on BTADK)
• Audio Protocol Mode set to DRV_I2S_AUDIO_I2S
• I2S Driver Instance 1 selected
Volume V: MPLAB Harmony Framework Driver Libraries Help Bluetooth Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 35
• I2S Module ID set to SPI_ID_1 (AK4384 DAC Module as wired on BTADK)
• Audio Protocol Mode set to DRV_I2S_AUDIO_LFET_JUSTIFIED
Building the Library
This section lists the files that are available in the BM64 Bluetooth Driver Library.
Description
This section lists the files that are available in the /src folder of the BM64 Bluetooth Driver. It lists which files need to be included in the build
based on either a hardware feature present on the board or configuration option selected by the system.
The following three tables list and describe the header (.h) and source (.c) files that implement this library. The parent folder for these files is
/framework/driver/bluetooth/bm64.
Interface File(s)
This table lists and describes the header files that must be included (i.e., using #include) by any code that uses this library.
Source File Name Description
/drv_bm64.h Header file that exports the driver API.
Required File(s)
All of the required files listed in the following table are automatically added into the MPLAB X IDE project by the MHC
when the library is selected for use.
This table lists and describes the source and header files that must always be included in the MPLAB X IDE project to build this library.
Source File Name Description
drv_bm64_ble.h Header file for the internal functions of the driver related to BLE.
drv_bm64_command_decode.h Header file for the internal functions of the driver for decoding events from the BM64.
drv_bm64_command_send.h Header file for the internal functions of the driver for sending commands to the BM64
drv_bm64_gpio.h Header file for the internal functions of the driver related to the BM64’s control pins.
drv_bm64_line_in.h Header file for the internal functions of the driver related to the BM64’s line in input.
./src/framework/driver/bluetooth/bm64/
drv_bm64_local.h
Header file for the functions local to the BM64 driver (generated from template).
drv_bm64_sha1.h Header file for the internal functions of the driver for performing SHA hashes.
drv_bm64_uart.h Header file for the internal functions of the driver related to the BM64’s UART interface.
./src/framework/driver/bluetooth/bm64/src/
drv_bm64.c
Main source implementation file for the driver (generated from template).
src/drv_bm64_ble.c Source file for the internal functions of the driver related to BLE.
src/drv_bm64_command_decode.c Source file for the internal functions of the driver for decoding events from the BM64.
src/drv_bm64_command_send.c Source file for the internal functions of the driver for sending commands to the BM64
src/drv_bm64_gpio.c Source file for the internal functions of the driver related to the BM64’s control pins.
src/drv_bm64_line_in.c Source file for the internal functions of the driver related to the BM64’s line in input.
src/drv_bm64_sha1.c Source file for the internal functions of the driver for performing SHA hashs.
src/drv_bm64_uart.c Source file for the internal functions of the driver related to the BM64’s UART interface.
Optional File(s)
This table lists and describes the source and header files that may optionally be included if required for the desired implementation.
Source File Name Description
There are no optional files for this driver. N/A
Module Dependencies
The BM64 Bluetooth Driver Library depends on the following modules:
• I2S Driver Library
• Timer Driver Library
• USART Driver Library
Volume V: MPLAB Harmony Framework Driver Libraries Help Bluetooth Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 36
Library Interface
a) System Functions
Name Description
DRV_BM64_GetPowerStatus Gets the current status of the BM64 Bluetooth driver module (BM64-specific).
DRV_BM64_Initialize Initializes hardware and data for the instance of the BM64 Bluetooth module
DRV_BM64_Status Gets the current system status of the BM64 Bluetooth driver module.
DRV_BM64_TaskReq Make a power on/power off task request.
DRV_BM64_Tasks Maintains the driver's control and data interface state machine.
b) Client Setup Functions
Name Description
DRV_BM64_BufferEventHandlerSet This function allows a client to identify a event handling function for the driver to call back.
DRV_BM64_Close Close an opened-instance of the BM64 Bluetooth driver.
DRV_BM64_EventHandlerSet This function allows a client to identify an event handling function for the driver to call back.
DRV_BM64_Open Open the specified BM64 driver instance and returns a handle to it
c) Data Transfer Functions
Name Description
DRV_BM64_BufferAddRead Schedule a non-blocking driver read operation.
d) Settings Functions
Name Description
DRV_BM64_SamplingRateGet Return the current sampling rate.
DRV_BM64_SamplingRateSet Set the current sampling rate.
DRV_BM64_volumeDown Turn the volume down on the host device.
DRV_BM64_VolumeGet returns 7-bit value 0-127
DRV_BM64_VolumeSet Set current volume.
DRV_BM64_volumeUp Turn the volume up on the host device.
e) Bluetooth-specific Functions
Name Description
DRV_BM64_DisconnectAllLinks Disconnect all links.
DRV_BM64_EnterBTPairingMode Enter Bluetooth pairing mode.
DRV_BM64_ForgetAllLinks Forget all pairings.
DRV_BM64_GetLinkStatus Return link status.
DRV_BM64_LinkLastDevice Link last device.
f) AVRCP Functions
Name Description
DRV_BM64_CancelForwardOrRewind Cancel previous fast forward or rewind request.
DRV_BM64_FastForward Fast forward the media.
DRV_BM64_GetPlayingStatus Return the current playing status of the device.
DRV_BM64_Pause Pause playback.
DRV_BM64_Play Start playback.
DRV_BM64_PlayNextSong Play the next song.
DRV_BM64_PlayPause Toggle play/pause mode.
DRV_BM64_PlayPreviousSong Play the previous song.
DRV_BM64_Rewind Rewind the media.
DRV_BM64_Stop Stop playback.
g) Device Name and Address Functions
Name Description
DRV_BM64_GetBDAddress Return the Bluetooth address.
Volume V: MPLAB Harmony Framework Driver Libraries Help Bluetooth Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 37
DRV_BM64_GetBDName Return Bluetooth device name.
DRV_BM64_SetBDName Set the Bluetooth device name.
h) BLE Functions
Name Description
DRV_BM64_ClearBLEData Clear the BLE receive buffer.
DRV_BM64_ReadByteFromBLE Read a byte over BLE.
DRV_BM64_ReadDataFromBLE Read data over BLE.
DRV_BM64_SendByteOverBLE Send a byte over BLE.
DRV_BM64_SendDataOverBLE Send data over BLE.
DRV_BM64_BLE_QueryStatus Query BM64 LE status.
DRV_BM64_BLE_EnableAdvertising Enable or disable advertising.
i) Data Types and Constants
Name Description
DRV_BM64_BUFFER_EVENT This is macro DRV_BM64_BUFFER_EVENT.
DRV_BM64_BUFFER_EVENT_COMPLETE This is macro DRV_BM64_BUFFER_EVENT_COMPLETE.
DRV_BM64_BUFFER_HANDLE This is macro DRV_BM64_BUFFER_HANDLE.
DRV_BM64_BUFFER_HANDLE_INVALID This is macro DRV_BM64_BUFFER_HANDLE_INVALID.
DRV_BM64_DATA32 BM64 defines based on I2S interface
DRV_BM64_MAXBDNAMESIZE
DRV_BM64_BUFFER_EVENT_HANDLER prototype for callback for DRV_BM64_BufferEventHandlerSet
DRV_BM64_DRVR_STATUS BM64 driver status
DRV_BM64_EVENT events that can be returned to a client via callback
DRV_BM64_EVENT_HANDLER prototype for callback for DRV_BM64_EventHandlerSet
DRV_BM64_LINKSTATUS BM64 link status
DRV_BM64_PLAYINGSTATUS This is type DRV_BM64_PLAYINGSTATUS.
DRV_BM64_PROTOCOL BM64 protocols
DRV_BM64_REQUEST BM64 power on/off request
DRV_BM64_SAMPLE_FREQUENCY BM64 sample frequency
DRV_BM64_BLE_STATUS This is type DRV_BM64_BLE_STATUS.
Description
This section describes the API functions of the BM64 Bluetooth Driver library.
Refer to each section for a detailed description.
a) System Functions
DRV_BM64_GetPowerStatus Function
Gets the current status of the BM64 Bluetooth driver module (BM64-specific).
File
drv_bm64.h
C
DRV_BM64_DRVR_STATUS DRV_BM64_GetPowerStatus();
Returns
Driver status, encoded as type DRV_BM64_DRVR_STATUS enum.
Description
Function DRV_BM64_GetPowerStatus:
DRV_BM64_DRVR_STATUS DRV_BM64_GetPowerStatus( void );
This routine provides the current status (power on/off/ready) of the BM64 Bluetooth driver module passed back as type
DRV_BM64_DRVR_STATUS enum.
Volume V: MPLAB Harmony Framework Driver Libraries Help Bluetooth Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 38
Remarks
A status of DRV_BT_STATUS_READY means the drivers state machine has finished initialization and is ready to stream audio.
Preconditions
DRV_BM64_Initialize must have been called to initialize the driver instance.
Example
case APP_STATE_WAIT_INIT:
{
// note generic version of call (DRV_BT instead of DRV_BM64) is used
if (DRV_BT_STATUS_READY == DRV_BT_GetPowerStatus())
{
appData.state=APP_STATE_IDLE;
// start can processing audio
}
}
break;
DRV_BM64_Initialize Function
Initializes hardware and data for the instance of the BM64 Bluetooth module
File
drv_bm64.h
C
void DRV_BM64_Initialize();
Returns
None.
Description
Function DRV_BM64_Initialize:
void DRV_BM64_Initialize( void );
This routine initializes the BM64 driver instance for the specified driver index, making it ready for clients to open and use it. The initialization data is
specified by the init parameter. The initialization may fail if the number of driver objects allocated are insufficient or if the specified driver instance is
already initialized.
Remarks
This routine must be called before any other BM64 driver routine is called. This routine should only be called once during system initialization. This
routine will never block for hardware access.
Preconditions
None.
Example
// (in SYS_Initialize, system_init.c)*
DRV_BM64_Initialize();
DRV_BM64_Status Function
Gets the current system status of the BM64 Bluetooth driver module.
File
drv_bm64.h
C
SYS_STATUS DRV_BM64_Status();
Returns
Driver status, encoded as type SYS_STATUS enum:
Volume V: MPLAB Harmony Framework Driver Libraries Help Bluetooth Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 39
SYS_STATUS_DEINITIALIZED - Indicates that the driver has been deinitialized SYS_STATUS_READY - Indicates that any previous module
operation for the specified module has completed SYS_STATUS_BUSY - Indicates that a previous module operation for the specified module has
not yet completed SYS_STATUS_ERROR - Indicates that the specified module is in an error state *
Description
Function DRV_BM64_Status:
SYS_STATUS DRV_BM64_Status( void );
This routine provides the current status of the BM64 Bluetooth driver module, passed back as type SYS_STATUS.
Remarks
A driver can opened only when its status is SYS_STATUS_READY.
Preconditions
None.
Example
* // note generic version of call (DRV_BT instead of DRV_BM64) is used
if (SYS_STATUS_READY == DRV_BT_Status())
{
// This means the driver can be opened using the
// DRV_BT_Open() function.
}
DRV_BM64_TaskReq Function
Make a power on/power off task request.
File
drv_bm64.h
C
void DRV_BM64_TaskReq(DRV_BM64_REQUEST request);
Returns
None.
Description
Function DRV_BM64_TaskReq:
void DRV_BM64_TaskReq(DRV_BM64_REQUEST request);
Make a power on/power off task request using the DRV_BM64_REQUEST enum.
Remarks
None.
Preconditions
DRV_BM64_Initialize must have been called to initialize the driver instance.
Example
// note generic version of call (DRV_BT instead of DRV_BM64) is used
DRV_BT_TaskReq(DRV_BM64_REQ_SYSTEM_ON);
Parameters
Parameters Description
request power on/off request of type DRV_BM64_REQUEST
DRV_BM64_Tasks Function
Maintains the driver's control and data interface state machine.
File
drv_bm64.h
Volume V: MPLAB Harmony Framework Driver Libraries Help Bluetooth Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 40
C
void DRV_BM64_Tasks();
Returns
None.
Description
Function DRV_BM64_Tasks:
void DRV_BM64_Tasks( void );
This routine is used to maintain the driver's internal control and data interface state machine and implement its control and data interface
implementations.
This function should be called from the SYS_Tasks() function.
Remarks
This routine is not normally called directly by an application. Instead it is called by the system's Tasks routine (SYS_Tasks).
Preconditions
None.
Example
// (in SYS_Tasks, system_tasks.c)
// Maintain Device Drivers
DRV_BM64_Tasks();
b) Client Setup Functions
DRV_BM64_BufferEventHandlerSet Function
This function allows a client to identify a event handling function for the driver to call back.
File
drv_bm64.h
C
void DRV_BM64_BufferEventHandlerSet(DRV_HANDLE handle, const DRV_BM64_BUFFER_EVENT_HANDLER eventHandler,
const uintptr_t contextHandle);
Returns
None.
Description
Function DRV_BM64_BufferEventHandlerSet:
void DRV_BM64_EventHandlerSet(DRV_HANDLE handle, const DRV_BM64_BUFFER_EVENT_HANDLER eventHandler, const uintptr_t
contextHandle);
This function allows a client to identify a command event handling function for the driver to call back when the last submitted command have
finished.
When a client calls DRV_BM64_BufferAddRead function, it is provided with a handle identifying the buffer that was added to the driver's buffer
queue. The driver will pass this handle back to the client by calling "eventHandler" function when the buffer transfer has completed.
The context parameter contains a handle to the client context, provided at the time the event handling function is registered using the
DRV_BM64_BufferEventHandlerSet function. This context handle value is passed back to the client as the "context" parameter. It can be any
value necessary to identify the client context or instance (such as a pointer to the client's data) instance of the client.
The event handler should be set before the client performs any "BM64 Bluetooth Specific Client Routines" operations that could generate events.
The event handler once set, persists until the client closes the driver or sets another event handler (which could be a "NULL" pointer to indicate no
callback).
Remarks
If the client does not want to be notified when the command has completed, it does not need to register a callback.
Volume V: MPLAB Harmony Framework Driver Libraries Help Bluetooth Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 41
Preconditions
DRV_BM64_Open must have been called to obtain a valid opened device handle.
Example
case APP_STATE_SET_BT_BUFFER_HANDLER:
{
// note generic version of call (DRV_BT instead of DRV_BM64) is used
DRV_BT_BufferEventHandlerSet(appData.bt.handle,
appData.bt.bufferHandler,
appData.bt.context);
DRV_BT_EventHandlerSet(appData.bt.handle,
appData.bt.eventHandler,
(uintptr_t)0);
appData.state = APP_STATE_CODEC_OPEN;
}
break;
Parameters
Parameters Description
handle valid handle to an opened BM64 device driver unique to client
eventHandler pointer to a function to be called back (prototype defined by
DRV_BM64_BUFFER_EVENT_HANDLER)
contextHandle handle to the client context
DRV_BM64_Close Function
Close an opened-instance of the BM64 Bluetooth driver.
File
drv_bm64.h
C
void DRV_BM64_Close(const DRV_HANDLE handle);
Returns
None.
Description
Function DRV_BM64_Close:
void DRV_BM64_Close(DRV_HANDLE handle);
This routine closes an opened-instance of the BM64 driver, invalidating the handle. Any buffers in the driver queue that were submitted by this
client will be removed. After calling this routine, the handle passed in "handle" must not be used with any of the remaining driver routines. A new
handle must be obtained by calling DRV_BM64_Open before the caller may use the driver again
Remarks
Usually there is no need for the driver client to verify that the Close operation has completed. The driver will abort any ongoing operations when
this routine is called.
Preconditions
DRV_BM64_Open must have been called to obtain a valid opened device handle.
Example
// note generic version of call (DRV_BT instead of DRV_BM64) is used
DRV_BT_Close(appData.bt.handle);
*
Parameters
Parameters Description
handle valid handle to an opened BM64 device driver unique to client
Volume V: MPLAB Harmony Framework Driver Libraries Help Bluetooth Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 42
DRV_BM64_EventHandlerSet Function
This function allows a client to identify an event handling function for the driver to call back.
File
drv_bm64.h
C
void DRV_BM64_EventHandlerSet(DRV_HANDLE handle, const DRV_BM64_EVENT_HANDLER eventHandler, const uintptr_t
contextHandle);
Returns
None.
Description
Function DRV_BM64_EventHandlerSet:
void DRV_BM64_EventHandlerSet(DRV_HANDLE handle, const DRV_BM64_EVENT_HANDLER eventHandler, const uintptr_t contextHandle);
This function allows a client to identify a command event handling function for the driver to call back when an event has been received from the
BM64.
The context parameter contains a handle to the client context, provided at the time the event handling function is registered using the
DRV_BM64_BufferEventHandlerSet function. This context handle value is passed back to the client as the "context" parameter. It can be any
value necessary to identify the client context or instance (such as a pointer to the client's data) instance of the client.*
The event handler should be set before the client performs any "BM64 Bluetooth Specific Client Routines" operations that could generate events.
The event handler once set, persists until the client closes the driver or sets another event handler (which could be a "NULL" pointer to indicate no
callback).
Remarks
If the client does not want to be notified when an event has occurred, it does not need to register a callback.
Preconditions
DRV_BM64_Open must have been called to obtain a valid opened device handle.
Example
case APP_STATE_SET_BT_BUFFER_HANDLER:
{
DRV_BT_BufferEventHandlerSet(appData.bt.handle,
appData.bt.bufferHandler,
appData.bt.context);
// note generic version of call (DRV_BT instead of DRV_BM64) is used
DRV_BT_EventHandlerSet(appData.bt.handle,
appData.bt.eventHandler,
(uintptr_t)0);
appData.state = APP_STATE_CODEC_OPEN;
}
break;
Parameters
Parameters Description
handle valid handle to an opened BM64 device driver unique to client
eventHandler pointer to a function to be called back (prototype defined by DRV_BM64_EVENT_HANDLER)
contextHandle handle to the client context
DRV_BM64_Open Function
Open the specified BM64 driver instance and returns a handle to it
File
drv_bm64.h
Volume V: MPLAB Harmony Framework Driver Libraries Help Bluetooth Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 43
C
DRV_HANDLE DRV_BM64_Open(const DRV_IO_INTENT ioIntent, const DRV_BM64_PROTOCOL protocol);
Returns
valid handle to an opened BM64 device driver unique to client
Description
Function DRV_BM64_Open:
DRV_HANDLE DRV_BM64_Open(const DRV_IO_INTENT ioIntent, const DRV_BM64_PROTOCOL protocol);
This routine opens the specified BM64 Bluetooth driver instance and provides a handle that must be provided to all other client-level operations to
identify the caller and the instance of the driver. The ioIntent parameter defines how the client interacts with this driver instance.
Only DRV_IO_INTENT_READ is a valid ioIntent option as the BM64 Bluetooth driver audio stream is read-only.
Specifying a DRV_IO_INTENT_EXCLUSIVE will cause the driver to provide exclusive access to this client. The driver cannot be opened by any
other client.
Remarks
The handle returned is valid until the DRV_BM64_Close routine is called. This routine will never block waiting for hardware. If the requested intent
flags are not supported, the routine will return DRV_HANDLE_INVALID. This function is thread safe in a RTOS application. It should not be called
in an ISR.
Currently only one client is allowed at a time.
Preconditions
DRV_BM64_Initialize must have been called to initialize the driver instance.
Example
case APP_STATE_OPEN:
{
if (SYS_STATUS_READY == DRV_BT_Status())
{
// open BT module, including RX audio stream
// note generic version of call (DRV_BT instead of DRV_BM64) is used
appData.bt.handle = DRV_BT_Open(DRV_IO_INTENT_READ, DRV_BT_PROTOCOL_ALL);
if(appData.bt.handle != DRV_HANDLE_INVALID)
{
appData.state = APP_STATE_SET_BT_BUFFER_HANDLER;
}
else
{
// Got an Invalid Handle. Wait for BT module to Initialize
}
}
}
break;
Parameters
Parameters Description
ioIntent valid handle to an opened BM64 device driver unique to client
protocol specifies which protocol(s) the client intends to use with this driver. One of the various
DRV_BM64_PROTOCOL enum values, including DRV_BM64_PROTOCOL_ALL.
c) Data Transfer Functions
DRV_BM64_BufferAddRead Function
Schedule a non-blocking driver read operation.
File
drv_bm64.h
Volume V: MPLAB Harmony Framework Driver Libraries Help Bluetooth Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 44
C
void DRV_BM64_BufferAddRead(const DRV_HANDLE handle, DRV_BM64_BUFFER_HANDLE * bufferHandle, void * buffer,
size_t size);
Returns
The bufferHandle parameter will contain the return buffer handle. This will be DRV_BM64_BUFFER_HANDLE_INVALID if the function was not
successful.
Description
This function schedules a non-blocking read operation. The function returns with a valid buffer handle in the bufferHandle argument if the read
request was scheduled successfully. The function adds the request to the hardware instance receive queue and returns immediately. While the
request is in the queue, the application buffer is owned by the driver and should not be modified. The function returns
DRV_BM64_BUFFER_HANDLE_INVALID
• if a buffer could not be allocated to the request
• if the input buffer pointer is NULL
• if the buffer size is 0.
• if the queue is full or the queue depth is insufficient
If the requesting client registered an event callback with the driver, the driver will issue a DRV_BM64_BUFFER_EVENT_COMPLETE event if the
buffer was processed successfully of DRV_BM64_BUFFER_EVENT_ERROR event if the buffer was not processed successfully.
Remarks
This function is thread safe in a RTOS application. It can be called from within the BM64 Driver Buffer Event Handler that is registered by this
client. It should not be called in the event handler associated with another BM64 driver instance. It should not otherwise be called directly in an ISR.
Preconditions
DRV_BM64_Open must have been called to obtain a valid opened device handle.
Example
case APP_STATE_BT_BUFFER_COMPLETE:
{
//BT RX
if (!_bufferUsed[appData.readIndex])
{
//Next BT Read Queued
// note generic version of call (DRV_BT instead of DRV_BM64) is used
DRV_BT_BufferAddRead(appData.bt.handle,
&appData.bt.readBufHandle,
audioBuffer[appData.readIndex],
appData.bt.bufferSize);
if(appData.bt.readBufHandle != DRV_BT_BUFFER_HANDLE_INVALID)
{
appData.bt.readBufHandle = DRV_BT_BUFFER_HANDLE_INVALID;
_bufferUsed[appData.readIndex] = true;
//QUEUE HEAD Index (for next BT read)
appData.readIndex++;
if(appData.readIndex >= AUDIO_QUEUE_SIZE)
{
appData.readIndex = 0;
}
appData.state = APP_STATE_BT_WAIT_FOR_BUFFER_COMPLETE;
}
else
{
SYS_DEBUG(0, "BT Buffer Read FAILED!!!");
}
}
else
{
//Overrun -- Wait for Read buffer to become available.
SYS_DEBUG(0, "Buffer Overrunrn");
}
}
break;
Volume V: MPLAB Harmony Framework Driver Libraries Help Bluetooth Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 45
Parameters
Parameters Description
handle valid handle to an opened BM64 device driver unique to client
bufferHandle pointer to an argument that contains the return buffer handle
buffer pointer to buffer that will contain received data
size buffer size in bytes.
Function
void DRV_BM64_BufferAddRead(const DRV_HANDLE handle,
DRV_BM6_BUFFER_HANDLE *bufferHandle, void *buffer, size_t size)
d) Settings Functions
DRV_BM64_SamplingRateGet Function
Return the current sampling rate.
File
drv_bm64.h
C
uint32_t DRV_BM64_SamplingRateGet(DRV_HANDLE handle);
Returns
None.
Description
Function DRV_BM64_SamplingRateGet:
uint32_t DRV_BM64_SamplingRateGet(DRV_HANDLE handle);
Return the current sampling rate as a 32-bit integer.
Remarks
None.
Preconditions
DRV_BM64_Open must have been called to obtain a valid opened device handle.
Example
uint32_t sampleRate;
// note generic version of call (DRV_BT instead of DRV_BM64) is used
sampleRate = DRV_BT_SamplingRateGet(appData.bt.handle);
Parameters
Parameters Description
handle valid handle to an opened BM64 device driver unique to client
DRV_BM64_SamplingRateSet Function
Set the current sampling rate.
File
drv_bm64.h
C
void DRV_BM64_SamplingRateSet(DRV_HANDLE handle, uint32_t samplingRate);
Volume V: MPLAB Harmony Framework Driver Libraries Help Bluetooth Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 46
Returns
None.
Description
Function DRV_BM64_SamplingRateSet:
void DRV_BM64_SamplingRateSet(DRV_HANDLE handle, uint32_t samplingRate);
Set the current sampling rate (passed as a 32-bit integer).
Remarks
None.
Preconditions
DRV_BM64_Open must have been called to obtain a valid opened device handle.
Example
// set sample rate to 44.1 kHz
// note generic version of call (DRV_BT instead of DRV_BM64) is used
DRV_BT_SamplingRateSet(appData.bt.handle, 44100);
Parameters
Parameters Description
handle valid handle to an opened BM64 device driver unique to client
samplingRate sampling rate in Hz (8000, 16000, 44100 or 48000)
DRV_BM64_volumeDown Function
Turn the volume down on the host device.
File
drv_bm64.h
C
void DRV_BM64_volumeDown(const DRV_HANDLE handle);
Returns
None.
Description
Function DRV_BM64_VolumeDown:
void DRV_BM64_VolumeDown(const DRV_HANDLE handle);
Turn the volume down on the host device by one increment (about 3% of full-scale).
Remarks
This will result in a callback with the event DRV_BM64_EVENT_VOLUME_CHANGED specifying the new volume setting for the codec.
Preconditions
DRV_BM64_Open must have been called to obtain a valid opened device handle.
Example
case BUTTON_STATE_PRESSED: // (debouncing not shown)
{
if (BSP_SwitchStateGet(BSP_SWITCH_2)==BSP_SWITCH_STATE_PRESSED))
{
// note generic version of call (DRV_BT instead of DRV_BM64) is used
DRV_BT_volumeUp(appData.bt.handle);
appData.buttonState=BUTTON_STATE_WAIT_FOR_RELEASE;
}
}
break;
Volume V: MPLAB Harmony Framework Driver Libraries Help Bluetooth Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 47
Parameters
Parameters Description
handle valid handle to an opened BM64 device driver unique to client
DRV_BM64_VolumeGet Function
File
drv_bm64.h
C
uint8_t DRV_BM64_VolumeGet(const DRV_HANDLE handle);
Description
returns 7-bit value 0-127
DRV_BM64_VolumeSet Function
Set current volume.
File
drv_bm64.h
C
void DRV_BM64_VolumeSet(const DRV_HANDLE handle, uint8_t volume);
Returns
None.
Description
Function DRV_BM64_VolumeSet:
void DRV_BM64_VolumeSet(const DRV_HANDLE handle, uint8_t volume);
Set volume for current mode (A2DP, HFP etc.) in percent (0-100).
Remarks
None.
Preconditions
DRV_BM64_Open must have been called to obtain a valid opened device handle.
Example
// note generic version of call (DRV_BT instead of DRV_BM64) is used *
volume = DRV_BT_VolumeGet(appData.bt.handle,50); // set volume to 50%
Parameters
Parameters Description
handle valid handle to an opened BM64 device driver unique to client
volume volume level in percent, 0-100
DRV_BM64_volumeUp Function
Turn the volume up on the host device.
File
drv_bm64.h
C
void DRV_BM64_volumeUp(const DRV_HANDLE handle);
Volume V: MPLAB Harmony Framework Driver Libraries Help Bluetooth Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 48
Returns
None.
Description
Function DRV_BM64_VolumeUp:
void DRV_BM64_VolumeUp(const DRV_HANDLE handle);
Turn the volume up on the host device by one increment (about 3% of full-scale).
Remarks
This will result in a callback with the event DRV_BM64_EVENT_VOLUME_CHANGED specifying the new volume setting for the codec.
Preconditions
DRV_BM64_Open must have been called to obtain a valid opened device handle.
Example
case BUTTON_STATE_PRESSED: // (debouncing not shown)
{
if (BSP_SwitchStateGet(BSP_SWITCH_1)==BSP_SWITCH_STATE_PRESSED))
{
// note generic version of call (DRV_BT instead of DRV_BM64) is used
DRV_BT_volumeUp(appData.bt.handle);
appData.buttonState=BUTTON_STATE_WAIT_FOR_RELEASE;
}
}
break;
Parameters
Parameters Description
handle valid handle to an opened BM64 device driver unique to client
e) Bluetooth-specific Functions
DRV_BM64_DisconnectAllLinks Function
Disconnect all links.
File
drv_bm64.h
C
void DRV_BM64_DisconnectAllLinks(const DRV_HANDLE handle);
Returns
None.
Description
Function DRV_BM64_DisconnectAllLinks:
void DRV_BM64_DisconnectAllLinks(const DRV_HANDLE handle);
Disconnect all current links to a Bluetooth host.
Remarks
Does not unpair the device, just disconnects. Use DRV_BM64_LinkLastDevice to reconnect. Use DRV_BM64_ForgetAllLinks to forget all pairings.
Preconditions
DRV_BM64_Open must have been called to obtain a valid opened device handle.
Example
case BUTTON_STATE_PRESSED: // (debouncing not shown)
{
if (BSP_SwitchStateGet(BSP_SWITCH_2)==BSP_SWITCH_STATE_PRESSED))
Volume V: MPLAB Harmony Framework Driver Libraries Help Bluetooth Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 49
{
// note generic version of call (DRV_BT instead of DRV_BM64) is used
DRV_BT_DisconnectAllLinks(appData.bt.handle);
appData.buttonState=BUTTON_STATE_WAIT_FOR_RELEASE;
}
}
break;
Parameters
Parameters Description
handle valid handle to an opened BM64 device driver unique to client
DRV_BM64_EnterBTPairingMode Function
Enter Bluetooth pairing mode.
File
drv_bm64.h
C
void DRV_BM64_EnterBTPairingMode(const DRV_HANDLE handle);
Returns
None.
Description
Function DRV_BM64_EnterBTPairingMode:
void DRV_BM64_EnterBTPairingMode(const DRV_HANDLE handle);
Starting the pairing process, making this BM64 available for pairing with a Bluetooth host.
Remarks
None.
Preconditions
DRV_BM64_Open must have been called to obtain a valid opened device handle.
Example
case BUTTON_STATE_PRESSED: // (debouncing not shown)
{
if (BSP_SwitchStateGet(BSP_SWITCH_1)==BSP_SWITCH_STATE_PRESSED))
{
// note generic version of call (DRV_BT instead of DRV_BM64) is used
DRV_BT_EnterBTPairingMode(appData.bt.handle);
appData.buttonState=BUTTON_STATE_WAIT_FOR_RELEASE;
}
}
break;
Parameters
Parameters Description
handle valid handle to an opened BM64 device driver unique to client
DRV_BM64_ForgetAllLinks Function
Forget all pairings.
File
drv_bm64.h
C
void DRV_BM64_ForgetAllLinks(const DRV_HANDLE handle);
Volume V: MPLAB Harmony Framework Driver Libraries Help Bluetooth Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 50
Returns
None.
Description
Function DRV_BM64_ForgetAllLinks:
void DRV_BM64_ForgetAllLinks(const DRV_HANDLE handle);
Forget (erase) all links and pairings stored in EEPROM.
Remarks
After this is called, one must call DRV_BM64_EnterBTPairingMode to establish a connection to a Bluetooth host again.
Preconditions
DRV_BM64_Open must have been called to obtain a valid opened device handle.
Example
case BUTTON_STATE_PRESSED: // (debouncing not shown)
{
if (BSP_SwitchStateGet(BSP_SWITCH_2)==BSP_SWITCH_STATE_PRESSED))
{
// note generic version of call (DRV_BT instead of DRV_BM64) is used
DRV_BT_ForgetAllLinks(appData.bt.handle);
appData.buttonState=BUTTON_STATE_WAIT_FOR_RELEASE;
}
}
break;
Parameters
Parameters Description
handle valid handle to an opened BM64 device driver unique to client
DRV_BM64_GetLinkStatus Function
Return link status.
File
drv_bm64.h
C
DRV_BM64_LINKSTATUS DRV_BM64_GetLinkStatus(const DRV_HANDLE handle);
Returns
8-bit value defined by DRV_BM64_LINKSTATUS enum.
Description
Function DRV_BM64_GetLinkStatus:
DRV_BM64_LINKSTATUS DRV_BM64_GetLinkStatus(const DRV_HANDLE handle);
Returns a 8-bit value containing current link status as bit flags for SCO (bit 0), ACL, HFP, A2DP, AVRCP, SPP, IAP, MAP (bit 7)
Remarks
None.
Preconditions
DRV_BM64_Open must have been called to obtain a valid opened device handle.
Example
case BUTTON_STATE_PRESSED: // (debouncing not shown)
{
if (BSP_SwitchStateGet(BSP_SWITCH_3)==BSP_SWITCH_STATE_PRESSED))
{
DRV_BT_PLAYINGSTATUS playingStatus = DRV_BT_GetPlayingStatus(appData.bt.handle);
if ((playingStatus==DRV_BT_PLAYING_FF)||(playingStatus==DRV_BT_PLAYING_FR))
{
Volume V: MPLAB Harmony Framework Driver Libraries Help Bluetooth Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 51
// note generic version of call (DRV_BT instead of DRV_BM64) is used
if (DRV_BT_GetLinkStatus(appData.bt.handle) & DRV_BT_AVRCP_LINK_STATUS)
{
DRV_BT_CancelForwardOrRewind(appData.bt.handle);
}
}
}
}
break;
Parameters
Parameters Description
handle valid handle to an opened BM64 device driver unique to client
DRV_BM64_LinkLastDevice Function
Link last device.
File
drv_bm64.h
C
void DRV_BM64_LinkLastDevice(const DRV_HANDLE handle);
Returns
None.
Description
Function DRV_BM64_LinkLastDevice:
void DRV_BM64_LinkLastDevice(const DRV_HANDLE handle);
Link (connect) to last device that was previously linked.
Remarks
None.
Preconditions
DRV_BM64_Open must have been called to obtain a valid opened device handle.
Example
case BUTTON_STATE_PRESSED: // (debouncing not shown)
{
if (BSP_SwitchStateGet(BSP_SWITCH_2)==BSP_SWITCH_STATE_PRESSED))
{
// note generic version of call (DRV_BT instead of DRV_BM64) is used
DRV_BT_LinkLastDevice(appData.bt.handle);
appData.buttonState=BUTTON_STATE_WAIT_FOR_RELEASE;
}
}
break;
Parameters
Parameters Description
handle valid handle to an opened BM64 device driver unique to client
f) AVRCP Functions
DRV_BM64_CancelForwardOrRewind Function
Cancel previous fast forward or rewind request.
Volume V: MPLAB Harmony Framework Driver Libraries Help Bluetooth Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 52
File
drv_bm64.h
C
void DRV_BM64_CancelForwardOrRewind(const DRV_HANDLE handle);
Returns
None.
Description
Function DRV_BM64_CancelForwardOrRewind:
void DRV_BM64_CancelForwardOrRewind(const DRV_HANDLE handle);
Send an AVRCP command to the host device to cancel a previous fast forward or rewind request.
Remarks
None.
Preconditions
DRV_BM64_Open must have been called to obtain a valid opened device handle.
Example
case BUTTON_STATE_PRESSED: // (debouncing not shown)
{
if (BSP_SwitchStateGet(BSP_SWITCH_3)==BSP_SWITCH_STATE_PRESSED))
{
// note generic version of call (DRV_BT instead of DRV_BM64) is used
DRV_BT_CancelForwardOrRewind(appData.bt.handle);
appData.buttonState=BUTTON_STATE_WAIT_FOR_RELEASE;
}
}
break;
Parameters
Parameters Description
handle valid handle to an opened BM64 device driver unique to client
DRV_BM64_FastForward Function
Fast forward the media.
File
drv_bm64.h
C
void DRV_BM64_FastForward(const DRV_HANDLE handle);
Returns
None.
Description
Function DRV_BM64_FastForward:
void DRV_BM64_FastForward(const DRV_HANDLE handle);
Send an AVRCP command to the host device to Fast forward the media.
Remarks
None.
Preconditions
DRV_BM64_Open must have been called to obtain a valid opened device handle.
Volume V: MPLAB Harmony Framework Driver Libraries Help Bluetooth Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 53
Example
case BUTTON_STATE_PRESSED: // (debouncing not shown)
{
if (BSP_SwitchStateGet(BSP_SWITCH_5)==BSP_SWITCH_STATE_PRESSED))
{
// note generic version of call (DRV_BT instead of DRV_BM64) is used
DRV_BT_FastForward(appData.bt.handle);
appData.buttonState=BUTTON_STATE_WAIT_FOR_RELEASE;
}
}
break;
Parameters
Parameters Description
handle valid handle to an opened BM64 device driver unique to client
DRV_BM64_GetPlayingStatus Function
Return the current playing status of the device.
File
drv_bm64.h
C
DRV_BM64_PLAYINGSTATUS DRV_BM64_GetPlayingStatus(const DRV_HANDLE handle);
Returns
None.
Description
Function DRV_BM64_GetPlayingStatus:
void DRV_BM64_GetPlayingStatus(const DRV_HANDLE handle);
Return the current AVRCP playing status of the device, e.g. stopped, playing, paused, fast forward or rewind, encoded as as the enum
DRV_BM64_PLAYINGSTATUS.
Remarks
None.
Preconditions
DRV_BM64_Open must have been called to obtain a valid opened device handle.
Example
case BUTTON_STATE_PRESSED: // (debouncing not shown)
{
if (BSP_SwitchStateGet(BSP_SWITCH_3)==BSP_SWITCH_STATE_PRESSED))
{
// note generic version of call (DRV_BT instead of DRV_BM64) is used
DRV_BT_PLAYINGSTATUS playingStatus = DRV_BT_GetPlayingStatus(appData.bt.handle);
if ((playingStatus==DRV_BT_PLAYING_FF)||(playingStatus==DRV_BT_PLAYING_FR))
{
if (DRV_BT_GetLinkStatus(appData.bt.handle) & DRV_BT_AVRCP_LINK_STATUS)
{
DRV_BT_CancelForwardOrRewind(appData.bt.handle);
}
}
}
}
break;
Parameters
Parameters Description
handle valid handle to an opened BM64 device driver unique to client
Volume V: MPLAB Harmony Framework Driver Libraries Help Bluetooth Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 54
DRV_BM64_Pause Function
Pause playback.
File
drv_bm64.h
C
void DRV_BM64_Pause(const DRV_HANDLE handle);
Returns
None.
Description
Function DRV_BM64_Pause:
void DRV_BM64_Pause(const DRV_HANDLE handle);
Send an AVRCP command to the host device to pause.
Remarks
None.
Preconditions
DRV_BM64_Open must have been called to obtain a valid opened device handle.
Example
case BUTTON_STATE_PRESSED: // (debouncing not shown)
{
if (BSP_SwitchStateGet(BSP_SWITCH_3)==BSP_SWITCH_STATE_PRESSED))
{
// note generic version of call (DRV_BT instead of DRV_BM64) is used
DRV_BT_Pause(appData.bt.handle);
appData.buttonState=BUTTON_STATE_WAIT_FOR_RELEASE;
}
}
break;
Parameters
Parameters Description
handle valid handle to an opened BM64 device driver unique to client
DRV_BM64_Play Function
Start playback.
File
drv_bm64.h
C
void DRV_BM64_Play(const DRV_HANDLE handle);
Returns
None.
Description
Function DRV_BM64_Play:
DRV_BM64_Play(const DRV_HANDLE handle);
Send an AVRCP command to the host device to initiate or resume playback.
Remarks
None.
Volume V: MPLAB Harmony Framework Driver Libraries Help Bluetooth Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 55
Preconditions
DRV_BM64_Open must have been called to obtain a valid opened device handle.
Example
case BUTTON_STATE_PRESSED: // (debouncing not shown)
{
if (BSP_SwitchStateGet(BSP_SWITCH_3)==BSP_SWITCH_STATE_PRESSED))
{
// note generic version of call (DRV_BT instead of DRV_BM64) is used
DRV_BT_Play(appData.bt.handle);
appData.buttonState=BUTTON_STATE_WAIT_FOR_RELEASE;
}
}
break;
Parameters
Parameters Description
handle valid handle to an opened BM64 device driver unique to client
DRV_BM64_PlayNextSong Function
Play the next song.
File
drv_bm64.h
C
void DRV_BM64_PlayNextSong(const DRV_HANDLE handle);
Returns
None.
Description
Function DRV_BM64_PlayNextSong:
void DRV_BM64_PlayNextSong(const DRV_HANDLE handle);
Send an AVRCP command to the host device to play the next song in a playlist.
Remarks
None.
Preconditions
DRV_BM64_Open must have been called to obtain a valid opened device handle.
Example
case BUTTON_STATE_PRESSED: // (debouncing not shown)
{
if (BSP_SwitchStateGet(BSP_SWITCH_3)==BSP_SWITCH_STATE_PRESSED))
{
// note generic version of call (DRV_BT instead of DRV_BM64) is used
DRV_BT_PlayNextSong(appData.bt.handle);
appData.buttonState=BUTTON_STATE_WAIT_FOR_RELEASE;
}
}
break;
Parameters
Parameters Description
handle valid handle to an opened BM64 device driver unique to client
Volume V: MPLAB Harmony Framework Driver Libraries Help Bluetooth Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 56
DRV_BM64_PlayPause Function
Toggle play/pause mode.
File
drv_bm64.h
C
void DRV_BM64_PlayPause(const DRV_HANDLE handle);
Returns
None.
Description
Function DRV_BM64_PlayPause:
void DRV_BM64_PlayPause(const DRV_HANDLE handle);
Send an AVRCP command to the host device to toggle the play/pause mode.
Remarks
None.
Preconditions
DRV_BM64_Open must have been called to obtain a valid opened device handle.
Example
case BUTTON_STATE_PRESSED: // (debouncing not shown)
{
if (BSP_SwitchStateGet(BSP_SWITCH_3)==BSP_SWITCH_STATE_PRESSED))
{
// note generic version of call (DRV_BT instead of DRV_BM64) is used
DRV_BT_PlayPause(appData.bt.handle);
appData.buttonState=BUTTON_STATE_WAIT_FOR_RELEASE;
}
}
break;
Parameters
Parameters Description
handle valid handle to an opened BM64 device driver unique to client
DRV_BM64_PlayPreviousSong Function
Play the previous song.
File
drv_bm64.h
C
void DRV_BM64_PlayPreviousSong(const DRV_HANDLE handle);
Returns
None.
Description
Function DRV_BM64_PlayPreviousSong:
void DRV_BM64_PlayPreviousSong(const DRV_HANDLE handle);
Send an AVRCP command to the host device to play the previous song in a playlist.
Remarks
None.
Volume V: MPLAB Harmony Framework Driver Libraries Help Bluetooth Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 57
Preconditions
DRV_BM64_Open must have been called to obtain a valid opened device handle.
Example
case BUTTON_STATE_PRESSED: // (debouncing not shown)
{
if (BSP_SwitchStateGet(BSP_SWITCH_5)==BSP_SWITCH_STATE_PRESSED))
{
// note generic version of call (DRV_BT instead of DRV_BM64) is used
DRV_BT_PlayPreviousSong(appData.bt.handle);
appData.buttonState=BUTTON_STATE_WAIT_FOR_RELEASE;
}
}
break;
Parameters
Parameters Description
handle valid handle to an opened BM64 device driver unique to client
DRV_BM64_Rewind Function
Rewind the media.
File
drv_bm64.h
C
void DRV_BM64_Rewind(const DRV_HANDLE handle);
Returns
None.
Description
Function DRV_BM64_Rewind:
void DRV_BM64_Rewind(const DRV_HANDLE handle);
Send an AVRCP command to the host device to rewind the media.
Remarks
None.
Preconditions
DRV_BM64_Open must have been called to obtain a valid opened device handle.
Example
case BUTTON_STATE_PRESSED: // (debouncing not shown)
{
if (BSP_SwitchStateGet(BSP_SWITCH_5)==BSP_SWITCH_STATE_PRESSED))
{
// note generic version of call (DRV_BT instead of DRV_BM64) is used
DRV_BT_Rewind(appData.bt.handle);
appData.buttonState=BUTTON_STATE_WAIT_FOR_RELEASE;
}
}
break;
Parameters
Parameters Description
handle valid handle to an opened BM64 device driver unique to client
Volume V: MPLAB Harmony Framework Driver Libraries Help Bluetooth Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 58
DRV_BM64_Stop Function
Stop playback.
File
drv_bm64.h
C
void DRV_BM64_Stop(const DRV_HANDLE handle);
Returns
None.
Description
Function DRV_BM64_Stop:
void DRV_BM64_Stop(const DRV_HANDLE handle);
Send an AVRCP command to the host device to stop playback.
Remarks
None.
Preconditions
DRV_BM64_Open must have been called to obtain a valid opened device handle.
Example
case BUTTON_STATE_PRESSED: // (debouncing not shown)
{
if (BSP_SwitchStateGet(BSP_SWITCH_3)==BSP_SWITCH_STATE_PRESSED))
{
// note generic version of call (DRV_BT instead of DRV_BM64) is used
DRV_BT_Stop(appData.bt.handle);
appData.buttonState=BUTTON_STATE_WAIT_FOR_RELEASE;
}
}
break;
Parameters
Parameters Description
handle valid handle to an opened BM64 device driver unique to client
g) Device Name and Address Functions
DRV_BM64_GetBDAddress Function
Return the Bluetooth address.
File
drv_bm64.h
C
void DRV_BM64_GetBDAddress(const DRV_HANDLE handle, char* buffer);
Returns
None.
Description
Function DRV_BM64_GetBDAddress:
void DRV_BM64_GetBDAddress(const DRV_HANDLE handle, char* buffer);
Return the Bluetooth address of the device as an ASCII string.
Volume V: MPLAB Harmony Framework Driver Libraries Help Bluetooth Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 59
Remarks
Buffer must be at least 18 bytes in length (6 octets separated by ?:?, e.g. able to hold "12:34:56:78:90:120").
Preconditions
DRV_BM64_Open must have been called to obtain a valid opened device handle.
Example
laString tempStr;
char buf [18];
// note generic version of call (DRV_BT instead of DRV_BM64) is used
DRV_BT_GetBDAddress(appData.bt.handle, buf);
tempStr = laString_CreateFromCharBuffer(buf, &LiberationSans12);
laLabelWidget_SetText(GFX_BTADDRESS_VALUE, tempStr); // display BT address
laString_Destroy(&tempStr);
Parameters
Parameters Description
handle valid handle to an opened BM64 device driver unique to client
buffer pointer to a char buffer at least 18 bytes long
DRV_BM64_GetBDName Function
Return Bluetooth device name.
File
drv_bm64.h
C
void DRV_BM64_GetBDName(const DRV_HANDLE handle, char* buffer, const uint8_t buflen);
Returns
None.
Description
Function DRV_BM64_GetBDName:
void DRV_BM64_GetBDName(const DRV_HANDLE handle, char* buffer, const uint8_t buflen);
Return the Bluetooth device name as an ASCII string.
Remarks
If name is longer than buflen-1 bytes long, it will be truncated to fit inside the buffer.
Preconditions
DRV_BM64_Open must have been called to obtain a valid opened device handle.
Example
laString tempStr;
char buf [DRV_BT_MAXBDNAMESIZE+1];
// note generic version of call (DRV_BT instead of DRV_BM64) is used
DRV_BT_GetBDName(appData.bt.handle, buf, DRV_BT_MAXBDNAMESIZE+1);
tempStr = laString_CreateFromCharBuffer(buf, &LiberationSans12);
laLabelWidget_SetText(GFX_BTNAME_VALUE, tempStr); // display BT name
laString_Destroy(&tempStr);
Parameters
Parameters Description
handle valid handle to an opened BM64 device driver unique to client
buffer pointer to a char buffer at least buflen bytes long
buflen length of buffer (including terminating 0 byte)
Volume V: MPLAB Harmony Framework Driver Libraries Help Bluetooth Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 60
DRV_BM64_SetBDName Function
Set the Bluetooth device name.
File
drv_bm64.h
C
void DRV_BM64_SetBDName(const DRV_HANDLE handle, const char* buffer);
Returns
None.
Description
Function DRV_BM64_SetBDName:
void DRV_BM64_SetBTName(const DRV_HANDLE handle, const char* buffer);
Set a temporary Bluetooth device name from an ASCII string buffer.
Remarks
The name is set for this session only; if the BM64 is reset (e.g. power is lost) the name will revert to the Bluetooth name stored in EEPROM.
Preconditions
DRV_BM64_Open must have been called to obtain a valid opened device handle.
Example
// note generic version of call (DRV_BT instead of DRV_BM64) is used
DRV_BT_SetBDName(appData.bt.handle, "Temporary BM64 Name");
Parameters
Parameters Description
handle valid handle to an opened BM64 device driver unique to client
buffer pointer to a char buffer containing the new name
h) BLE Functions
DRV_BM64_ClearBLEData Function
Clear the BLE receive buffer.
File
drv_bm64.h
C
void DRV_BM64_ClearBLEData(const DRV_HANDLE handle);
Returns
None.
Description
Function DRV_BM64_ClearBLEData:
void DRV_BM64_ClearBLEData( const DRV_HANDLE handle );
Clears the buffer used when receiving characters via the DRV_BM64_ReadByteFromBLE and DRV_BM64_ReadDataFromBLE calls.
Remarks
None.
Preconditions
DRV_BM64_Open must have been called to obtain a valid opened device handle.
Volume V: MPLAB Harmony Framework Driver Libraries Help Bluetooth Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 61
Example
uint8_t byte;
// note generic versions of calls (DRV_BT instead of DRV_BM64) is used
DRV_BT_ClearBLEData(appData.bt.handle);
// wait for byte to arrive
while (!DRV_BT_ReadByteFromBLE(appData.bt.handle, &byte))
{
// should have some sort of way to break out of here if byte never arrives
}
Parameters
Parameters Description
handle valid handle to an opened BM64 device driver unique to client
DRV_BM64_ReadByteFromBLE Function
Read a byte over BLE.
File
drv_bm64.h
C
bool DRV_BM64_ReadByteFromBLE(const DRV_HANDLE handle, uint8_t* byte);
Returns
bool - true if a byte was returned, false if receive buffer empty
Description
Function DRV_BM64_ReadByteFromBLE:
bool DRV_BM64_ReadByteFromBLE(const DRV_HANDLE handle, uint8_t* byte);
Read one byte over BLE using the BM64's "Transparent Service" feature.
Remarks
None.
Preconditions
DRV_BM64_Open must have been called to obtain a valid opened device handle.
Example
uint8_t byte;
// note generic version of call (DRV_BT instead of DRV_BM64) is used
if (DRV_BT_ReadByteFromBLE(appData.bt.handle, &byte)) // if byte received
{
// do something
}
Parameters
Parameters Description
handle valid handle to an opened BM64 device driver unique to client
byte pointer to a uint8_t to receive the data
DRV_BM64_ReadDataFromBLE Function
Read data over BLE.
File
drv_bm64.h
Volume V: MPLAB Harmony Framework Driver Libraries Help Bluetooth Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 62
C
bool DRV_BM64_ReadDataFromBLE(const DRV_HANDLE handle, uint8_t* byte, uint16_t size);
Returns
bool - true if data was returned, false if receive buffer empty
Description
Function DRV_BM64_ReadDataFromBLE:
bool DRV_BM64_ReadDataFromBLE(const DRV_HANDLE handle, uint8_t* bytes, uint16_t size );
Read data over BLE using the BM64's "Transparent Service" feature.
Remarks
No more than size bytes will be returned, even if more are available.
Preconditions
DRV_BM64_Open must have been called to obtain a valid opened device handle.
Example
#define BUFSIZE 100
uint8_t buf [BUFSIZE];
// note generic version of call (DRV_BT instead of DRV_BM64) is used
if (DRV_BT_ReadDataFromBLE(appData.bt.handle, buf, BUFSIZE)) // if data received
{
// do something
}
Parameters
Parameters Description
handle valid handle to an opened BM64 device driver unique to client
bytes pointer to a uint8_t buffer at least size bytes long
size length of buffer (including
DRV_BM64_SendByteOverBLE Function
Send a byte over BLE.
File
drv_bm64.h
C
void DRV_BM64_SendByteOverBLE(const DRV_HANDLE handle, uint8_t byte);
Returns
None.
Description
Function DRV_BM64_SendByteOverBLE:
void DRV_BM64_SendByteOverBLE(const DRV_HANDLE handle, uint8_t byte);
Send one byte over BLE using the BM64's "Transparent Service" feature.
Remarks
None.
Preconditions
DRV_BM64_Open must have been called to obtain a valid opened device handle.
Example
uint8_t byte;
byte = 10; // set to some value
Volume V: MPLAB Harmony Framework Driver Libraries Help Bluetooth Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 63
// note generic version of call (DRV_BT instead of DRV_BM64) is used
DRV_BT_SendByteOverBLE(appData.bt.handle, byte);
Parameters
Parameters Description
handle valid handle to an opened BM64 device driver unique to client
byte uint8_t of data to be sent
DRV_BM64_SendDataOverBLE Function
Send data over BLE.
File
drv_bm64.h
C
void DRV_BM64_SendDataOverBLE(const DRV_HANDLE handle, uint8_t* bytes, uint16_t size);
Returns
None.
Description
Function DRV_BM64_SendDataOverBLE:
void DRV_BM64_SendDataOverBLE(const DRV_HANDLE handle, uint8_t* bytes, uint16_t size);
Send data over BLE using the BM64's "Transparent Service" feature.
Remarks
None.
Preconditions
DRV_BM64_Open must have been called to obtain a valid opened device handle.
Example
#define BUFSIZE 100
uint8_t buf [BUFSIZE];
// (code to fill in buffer with data)
// note generic version of call (DRV_BT instead of DRV_BM64) is used
DRV_BT_SendDataOverBLE(appData.bt.handle, buf, BUFSIZE);
Parameters
Parameters Description
handle valid handle to an opened BM64 device driver unique to client
bytes pointer to a uint8_t buffer at least size bytes long
size length of buffer (including
DRV_BM64_BLE_QueryStatus Function
Query BM64 LE status.
File
drv_bm64.h
C
void DRV_BM64_BLE_QueryStatus(const DRV_HANDLE handle);
Returns
None.
Volume V: MPLAB Harmony Framework Driver Libraries Help Bluetooth Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 64
Description
Function DRV_BM64_BLE_QueryStatus:
void DRV_BM64_BLE_QueryStatus(const DRV_HANDLE handle);
Queries the BM64 to respond with a DRV_BM64_EVENT_BLE_STATUS_CHANGED event, which will indicate if the BM64 BLE status is standby,
advertising, scanning or connected.
Remarks
RV_BM64_BLE_QueryStatus is non-blocking; it returns right away and sometime later (perhaps tens or hundreds of ms) the event handler
callback will be called.
Preconditions
DRV_BM64_Open must have been called to obtain a valid opened device handle.
Example
// note generic version of call (DRV_BT instead of DRV_BM64) is used
DRV_BT_BLE_QueryStatus(appData.bt.handle);
. . .
// later, a call will come back to the event handler callback function
// (previously set up via a call to DRV_BM64_EventHandlerSet)
static void _BLEEventHandler(DRV_BT_EVENT event, uint32_t param, uintptr_t context)
{
switch(event)
{
case DRV_BT_EVENT_BLE_STATUS_CHANGED:
{
// do case switch based on param variable
}
}
}
Parameters
Parameters Description
handle valid handle to an opened BM64 device driver unique to client
DRV_BM64_BLE_EnableAdvertising Function
Enable or disable advertising.
File
drv_bm64.h
C
void DRV_BM64_BLE_EnableAdvertising(const DRV_HANDLE handle, bool enable);
Returns
None.
Description
Function DRV_BM64_BLE_EnableAdvertising:
void DRV_BM64_BLE_EnableAdvertising(const DRV_HANDLE handle, bool enable);
Enable or disable BLE advertising.
Remarks
None.
Preconditions
DRV_BM64_Open must have been called to obtain a valid opened device handle.
Example
// note generic version of call (DRV_BT instead of DRV_BM64) is used
Volume V: MPLAB Harmony Framework Driver Libraries Help Bluetooth Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 65
DRV_BM64_BLE_EnableAdvertising(appData.bt.handle, true);
Parameters
Parameters Description
handle valid handle to an opened BM64 device driver unique to client
enable true to enable advertising, false to disable advertising
i) Data Types and Constants
DRV_BM64_BUFFER_EVENT Macro
File
drv_bm64.h
C
#define DRV_BM64_BUFFER_EVENT DRV_I2S_BUFFER_EVENT
Description
This is macro DRV_BM64_BUFFER_EVENT.
DRV_BM64_BUFFER_EVENT_COMPLETE Macro
File
drv_bm64.h
C
#define DRV_BM64_BUFFER_EVENT_COMPLETE DRV_I2S_BUFFER_EVENT_COMPLETE
Description
This is macro DRV_BM64_BUFFER_EVENT_COMPLETE.
DRV_BM64_BUFFER_HANDLE Macro
File
drv_bm64.h
C
#define DRV_BM64_BUFFER_HANDLE DRV_I2S_BUFFER_HANDLE
Description
This is macro DRV_BM64_BUFFER_HANDLE.
DRV_BM64_BUFFER_HANDLE_INVALID Macro
File
drv_bm64.h
C
#define DRV_BM64_BUFFER_HANDLE_INVALID DRV_I2S_BUFFER_HANDLE_INVALID
Description
This is macro DRV_BM64_BUFFER_HANDLE_INVALID.
DRV_BM64_DATA32 Macro
File
drv_bm64.h
Volume V: MPLAB Harmony Framework Driver Libraries Help Bluetooth Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 66
C
#define DRV_BM64_DATA32 DRV_I2S_DATA32
Description
BM64 defines based on I2S interface
DRV_BM64_MAXBDNAMESIZE Macro
File
drv_bm64.h
C
#define DRV_BM64_MAXBDNAMESIZE 32
Section
Constants
DRV_BM64_BUFFER_EVENT_HANDLER Type
File
drv_bm64.h
C
typedef void (* DRV_BM64_BUFFER_EVENT_HANDLER)(DRV_BM64_BUFFER_EVENT event, uintptr_t contextHandle);
Description
prototype for callback for DRV_BM64_BufferEventHandlerSet
DRV_BM64_DRVR_STATUS Enumeration
File
drv_bm64.h
C
typedef enum {
DRV_BM64_STATUS_NONE,
DRV_BM64_STATUS_OFF,
DRV_BM64_STATUS_ON,
DRV_BM64_STATUS_READY
} DRV_BM64_DRVR_STATUS;
Description
BM64 driver status
DRV_BM64_EVENT Enumeration
File
drv_bm64.h
C
typedef enum {
DRV_BM64_EVENT_NONE = 0,
DRV_BM64_EVENT_NSPK_STATUS,
DRV_BM64_EVENT_LINE_IN_STATUS,
DRV_BM64_EVENT_A2DP_STATUS,
DRV_BM64_EVENT_CALL_STATUS_CHANGED,
DRV_BM64_EVENT_CODEC_TYPE,
DRV_BM64_EVENT_HFP_CONNECTED,
DRV_BM64_EVENT_HFP_DISCONNECTED,
DRV_BM64_EVENT_A2DP_CONNECTED,
DRV_BM64_EVENT_A2DP_DISCONNECTED,
DRV_BM64_EVENT_AVRCP_CONNECTED,
Volume V: MPLAB Harmony Framework Driver Libraries Help Bluetooth Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 67
DRV_BM64_EVENT_AVRCP_DISCONNECTED,
DRV_BM64_EVENT_SPP_CONNECTED,
DRV_BM64_EVENT_IAP_CONNETED,
DRV_BM64_EVENT_SPP_IAP_DISCONNECTED,
DRV_BM64_EVENT_ACL_CONNECTED,
DRV_BM64_EVENT_ACL_DISCONNECTED,
DRV_BM64_EVENT_SCO_CONNECTED,
DRV_BM64_EVENT_SCO_DISCONNECTED,
DRV_BM64_EVENT_MAP_CONNECTED,
DRV_BM64_EVENT_MAP_DISCONNECTED,
DRV_BM64_EVENT_SYS_POWER_ON,
DRV_BM64_EVENT_SYS_POWER_OFF,
DRV_BM64_EVENT_SYS_STANDBY,
DRV_BM64_EVENT_SYS_PAIRING_START,
DRV_BM64_EVENT_SYS_PAIRING_OK,
DRV_BM64_EVENT_SYS_PAIRING_FAILED,
DRV_BM64_EVENT_LINKBACK_SUCCESS,
DRV_BM64_EVENT_LINKBACK_FAILED,
DRV_BM64_EVENT_BD_ADDR_RECEIVED,
DRV_BM64_EVENT_PAIR_RECORD_RECEIVED,
DRV_BM64_EVENT_LINK_MODE_RECEIVED,
DRV_BM64_EVENT_PLAYBACK_STATUS_CHANGED,
DRV_BM64_EVENT_AVRCP_VOLUME_CTRL,
DRV_BM64_EVENT_AVRCP_ABS_VOLUME_CHANGED,
DRV_BM64_EVENT_HFP_VOLUME_CHANGED,
DRV_BM64_EVENT_VOLUME_CHANGED,
DRV_BM64_EVENT_SAMPLERATE_CHANGED,
DRV_BM64_EVENT_NSPK_SYNC_POWER_OFF,
DRV_BM64_EVENT_NSPK_SYNC_VOL_CTRL,
DRV_BM64_EVENT_NSPK_SYNC_INTERNAL_GAIN,
DRV_BM64_EVENT_NSPK_SYNC_ABS_VOL,
DRV_BM64_EVENT_NSPK_CHANNEL_SETTING,
DRV_BM64_EVENT_NSPK_ADD_SPEAKER3,
DRV_BM64_EVENT_LE_STATUS_CHANGED,
DRV_BM64_EVENT_LE_ADV_CONTROL_REPORT,
DRV_BM64_EVENT_LE_CONNECTION_PARA_REPORT,
DRV_BM64_EVENT_LE_CONNECTION_PARA_UPDATE_RSP,
DRV_BM64_EVENT_GATT_ATTRIBUTE_DATA,
DRV_BM64_EVENT_PORT0_INPUT_CHANGED,
DRV_BM64_EVENT_PORT1_INPUT_CHANGED,
DRV_BM64_EVENT_PORT2_INPUT_CHANGED,
DRV_BM64_EVENT_PORT3_INPUT_CHANGED,
DRV_BM64_EVENT_BLESPP_MSG_RECEIVED,
DRV_BM64_EVENT_BLE_STATUS_CHANGED
} DRV_BM64_EVENT;
Description
events that can be returned to a client via callback
DRV_BM64_EVENT_HANDLER Type
File
drv_bm64.h
C
typedef void (* DRV_BM64_EVENT_HANDLER)(DRV_BM64_EVENT event, uint32_t param, uintptr_t contextHandle);
Description
prototype for callback for DRV_BM64_EventHandlerSet
DRV_BM64_LINKSTATUS Enumeration
File
drv_bm64.h
C
typedef enum {
DRV_BM64_NO_LINK_STATUS = 0,
DRV_BM64_SCO_LINK_STATUS = 0x01,
Volume V: MPLAB Harmony Framework Driver Libraries Help Bluetooth Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 68
DRV_BM64_ACL_LINK_STATUS = 0x02,
DRV_BM64_HFP_LINK_STATUS = 0x04,
DRV_BM64_A2DP_LINK_STATUS = 0x08,
DRV_BM64_AVRCP_LINK_STATUS = 0x10,
DRV_BM64_SPP_LINK_STATUS = 0x20,
DRV_BM64_IAP_LINK_STATUS = 0x40,
DRV_BM64_MAP_LINK_STATUS = 0x80
} DRV_BM64_LINKSTATUS;
Description
BM64 link status
DRV_BM64_PLAYINGSTATUS Enumeration
File
drv_bm64.h
C
typedef enum {
DRV_BM64_PLAYING_STOPPED,
DRV_BM64_PLAYING_PLAYING,
DRV_BM64_PLAYING_PAUSED,
DRV_BM64_PLAYING_FF,
DRV_BM64_PLAYING_FR,
DRV_BM64_PLAYING_ERROR
} DRV_BM64_PLAYINGSTATUS;
Description
This is type DRV_BM64_PLAYINGSTATUS.
DRV_BM64_PROTOCOL Enumeration
File
drv_bm64.h
C
typedef enum {
DRV_BM64_PROTOCOL_A2DP = 1,
DRV_BM64_PROTOCOL_AVRCP = 2,
DRV_BM64_PROTOCOL_HFP_HSP = 4,
DRV_BM64_PROTOCOL_SPP = 8,
DRV_BM64_PROTOCOL_BLE = 16,
DRV_BM64_PROTOCOL_ALL = 31
} DRV_BM64_PROTOCOL;
Description
BM64 protocols
DRV_BM64_REQUEST Enumeration
File
drv_bm64.h
C
typedef enum {
DRV_BM64_REQ_NONE = 0,
DRV_BM64_REQ_SYSTEM_ON,
DRV_BM64_REQ_SYSTEM_OFF
} DRV_BM64_REQUEST;
Description
BM64 power on/off request
Volume V: MPLAB Harmony Framework Driver Libraries Help Bluetooth Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 69
DRV_BM64_SAMPLE_FREQUENCY Enumeration
File
drv_bm64.h
C
typedef enum {
DRV_BM64_SAMPLEFREQ_8000 = 0,
DRV_BM64_SAMPLEFREQ_12000,
DRV_BM64_SAMPLEFREQ_16000,
DRV_BM64_SAMPLEFREQ_24000,
DRV_BM64_SAMPLEFREQ_32000,
DRV_BM64_SAMPLEFREQ_48000,
DRV_BM64_SAMPLEFREQ_44100,
DRV_BM64_SAMPLEFREQ_88000,
DRV_BM64_SAMPLEFREQ_96000
} DRV_BM64_SAMPLE_FREQUENCY;
Description
BM64 sample frequency
DRV_BM64_BLE_STATUS Enumeration
File
drv_bm64.h
C
typedef enum {
DRV_BM64_BLE_STATUS_STANDBY,
DRV_BM64_BLE_STATUS_ADVERTISING,
DRV_BM64_BLE_STATUS_SCANNING,
DRV_BM64_BLE_STATUS_CONNECTED
} DRV_BM64_BLE_STATUS;
Description
This is type DRV_BM64_BLE_STATUS.
Files
Files
Name Description
drv_bm64.h BM64 Bluetooth Static Driver main header file
drv_bm64_config_template.h BM64 Bluetooth Driver Configuration Template.
Description
This section lists the source and header files used by the BM64 Bluetooth Driver Library.
drv_bm64.h
BM64 Bluetooth Static Driver main header file
Enumerations
Name Description
DRV_BM64_BLE_STATUS This is type DRV_BM64_BLE_STATUS.
DRV_BM64_DRVR_STATUS BM64 driver status
DRV_BM64_EVENT events that can be returned to a client via callback
DRV_BM64_LINKSTATUS BM64 link status
DRV_BM64_PLAYINGSTATUS This is type DRV_BM64_PLAYINGSTATUS.
DRV_BM64_PROTOCOL BM64 protocols
DRV_BM64_REQUEST BM64 power on/off request
Volume V: MPLAB Harmony Framework Driver Libraries Help Bluetooth Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 70
DRV_BM64_SAMPLE_FREQUENCY BM64 sample frequency
Functions
Name Description
DRV_BM64_BLE_EnableAdvertising Enable or disable advertising.
DRV_BM64_BLE_QueryStatus Query BM64 LE status.
DRV_BM64_BufferAddRead Schedule a non-blocking driver read operation.
DRV_BM64_BufferEventHandlerSet This function allows a client to identify a event handling function for the driver to call back.
DRV_BM64_CancelForwardOrRewind Cancel previous fast forward or rewind request.
DRV_BM64_ClearBLEData Clear the BLE receive buffer.
DRV_BM64_Close Close an opened-instance of the BM64 Bluetooth driver.
DRV_BM64_DisconnectAllLinks Disconnect all links.
DRV_BM64_EnterBTPairingMode Enter Bluetooth pairing mode.
DRV_BM64_EventHandlerSet This function allows a client to identify an event handling function for the driver to call back.
DRV_BM64_FastForward Fast forward the media.
DRV_BM64_ForgetAllLinks Forget all pairings.
DRV_BM64_GetBDAddress Return the Bluetooth address.
DRV_BM64_GetBDName Return Bluetooth device name.
DRV_BM64_GetLinkStatus Return link status.
DRV_BM64_GetPlayingStatus Return the current playing status of the device.
DRV_BM64_GetPowerStatus Gets the current status of the BM64 Bluetooth driver module (BM64-specific).
DRV_BM64_Initialize Initializes hardware and data for the instance of the BM64 Bluetooth module
DRV_BM64_LinkLastDevice Link last device.
DRV_BM64_Open Open the specified BM64 driver instance and returns a handle to it
DRV_BM64_Pause Pause playback.
DRV_BM64_Play Start playback.
DRV_BM64_PlayNextSong Play the next song.
DRV_BM64_PlayPause Toggle play/pause mode.
DRV_BM64_PlayPreviousSong Play the previous song.
DRV_BM64_ReadByteFromBLE Read a byte over BLE.
DRV_BM64_ReadDataFromBLE Read data over BLE.
DRV_BM64_Rewind Rewind the media.
DRV_BM64_SamplingRateGet Return the current sampling rate.
DRV_BM64_SamplingRateSet Set the current sampling rate.
DRV_BM64_SendByteOverBLE Send a byte over BLE.
DRV_BM64_SendDataOverBLE Send data over BLE.
DRV_BM64_SetBDName Set the Bluetooth device name.
DRV_BM64_Status Gets the current system status of the BM64 Bluetooth driver module.
DRV_BM64_Stop Stop playback.
DRV_BM64_TaskReq Make a power on/power off task request.
DRV_BM64_Tasks Maintains the driver's control and data interface state machine.
DRV_BM64_volumeDown Turn the volume down on the host device.
DRV_BM64_VolumeGet returns 7-bit value 0-127
DRV_BM64_VolumeSet Set current volume.
DRV_BM64_volumeUp Turn the volume up on the host device.
Macros
Name Description
DRV_BM64_BUFFER_EVENT This is macro DRV_BM64_BUFFER_EVENT.
DRV_BM64_BUFFER_EVENT_COMPLETE This is macro DRV_BM64_BUFFER_EVENT_COMPLETE.
DRV_BM64_BUFFER_HANDLE This is macro DRV_BM64_BUFFER_HANDLE.
DRV_BM64_BUFFER_HANDLE_INVALID This is macro DRV_BM64_BUFFER_HANDLE_INVALID.
DRV_BM64_DATA32 BM64 defines based on I2S interface
DRV_BM64_MAXBDNAMESIZE
Volume V: MPLAB Harmony Framework Driver Libraries Help Bluetooth Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 71
Types
Name Description
DRV_BM64_BUFFER_EVENT_HANDLER prototype for callback for DRV_BM64_BufferEventHandlerSet
DRV_BM64_EVENT_HANDLER prototype for callback for DRV_BM64_EventHandlerSet
Description
BM64 Bluetooth Static Driver implementation
This file is the header file for the external (public) API of the static implementation of the BM64 driver.
The BM64 is a Bluetooth 4.2 Stereo Module that supports classic A2DP, AVRCP, HFP, HSP, and SPP protocols as well as BLE (Bluetooth Low
Energy).
The BM64 streams I2S audio at up to 24-bit, 96 kHz. It uses a UART to receive commands from the host microcontroller (PIC32) and and send
events back.
All functions and constants in this file are named with the format DRV_BM64_xxx, where xxx is a function name or constant. These names are
redefined in the appropriate configuration?s system_config.h file to the format DRV_BT_xxx using #defines so that Bluetooth code in the
application can be written as generically as possible (e.g. by writing DRV_BT_Open instead of DRV_BM64_Open etc.).
File Name
drv_bm64.h
Company
Microchip Technology Inc.
drv_bm64_config_template.h
BM64 Bluetooth Driver Configuration Template.
Macros
Name Description
INCLUDE_BM64_BLE Identifies whether the driver should include BLE
INCLUDE_BM64_I2S Identifies whether the driver should include HFP,A2DP,AVRCP functionality.
INCLUDE_DEPRECATED_MMI_COMMANDS Identifies whether the driver should use deprecated MMI commands.
Description
BM64 Driver Configuration Template
These file provides the list of all the configurations that can be used with the driver. This file should not be included in the driver.
File Name
drv_bm64_config_template.h
Company
Microchip Technology Inc.
Camera Driver Libraries
This section describes the Camera Driver Libraries.
Introduction
This section provides information on the Camera Driver libraries that are provided in MPLAB Harmony and describes the APIs that are common to
all drivers.
Library Interface
a) Common Driver Functions
Name Description
DRV_CAMERA_Close Closes an opened instance of an CAMERA module driver.
DRV_CAMERA_Deinitialize Deinitializes the index instance of the CAMERA module.
DRV_CAMERA_Initialize Initializes hardware and data for the index instance of the CAMERA module.
Volume V: MPLAB Harmony Framework Driver Libraries Help Camera Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 72
DRV_CAMERA_Open Opens the specified instance of the Camera driver for use and provides an "open instance"
handle.
DRV_CAMERA_Reinitialize Reinitializes hardware and data for the index instance of the CAMERA module.
DRV_CAMERA_Status Provides the current status of the index instance of the CAMERA module.
DRV_CAMERA_Tasks This is function DRV_CAMERA_Tasks.
b) Common Data Types and Constants
Name Description
DRV_CAMERA_INIT Defines the data required to initialize or reinitialize the CAMERA driver.
DRV_CAMERA_INTERRUPT_PORT_REMAP Defines the data required to initialize the CAMERA driver interrupt port remap.
DRV_CAMERA_INDEX_0 Camera driver index definitions.
DRV_CAMERA_INDEX_1 This is macro DRV_CAMERA_INDEX_1.
DRV_CAMERA_INDEX_COUNT Number of valid CAMERA driver indices.
CAMERA_MODULE_ID This is type CAMERA_MODULE_ID.
Description
Camera Driver APIs that are common to all Camera drivers.
a) Common Driver Functions
DRV_CAMERA_Close Function
Closes an opened instance of an CAMERA module driver.
File
drv_camera.h
C
void DRV_CAMERA_Close(DRV_HANDLE handle);
Returns
None.
Description
This function closes an opened instance of an CAMERA module driver, making the specified handle invalid.
Remarks
None.
Preconditions
The DRV_CAMERA_Initialize routine must have been called for the specified CAMERA device instance and the DRV_CAMERA_Status must
have returned SYS_STATUS_READY.
DRV_CAMERA_Open must have been called to obtain a valid opened device handle.
Example
myCameraHandle = DRV_CAMERA_Open(DRV_CAMERA_ID_1, DRV_IO_INTENT_NONBLOCKING|DRV_IO_INTENT_READWRITE);
DRV_CAMERA_Close(myCameraHandle);
Parameters
Parameters Description
drvHandle A valid open-instance handle, returned from the driver's open routine
Function
void DRV_CAMERA_Close ( const DRV_HANDLE drvHandle )
DRV_CAMERA_Deinitialize Function
Deinitializes the index instance of the CAMERA module.
Volume V: MPLAB Harmony Framework Driver Libraries Help Camera Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 73
File
drv_camera.h
C
void DRV_CAMERA_Deinitialize(const SYS_MODULE_INDEX index);
Returns
None.
Description
This function deinitializes the index instance of the CAMERA module, disabling its operation (and any hardware for driver modules). It deinitializes
only the specified module instance. It also resets all the internal data structures and fields for the specified instance to the default settings.
Remarks
None.
Preconditions
The DRV_CAMERA_Initialize function should have been called before calling this function.
Example
SYS_STATUS cameraStatus;
DRV_CAMERA_Deinitialize(DRV_CAMERA_ID_1);
cameraStatus = DRV_CAMERA_Status(DRV_CAMERA_ID_1);
Parameters
Parameters Description
index Index, identifying the instance of the CAMERA module to be deinitialized
Function
void DRV_CAMERA_Deinitialize ( const SYS_MODULE_ID index )
DRV_CAMERA_Initialize Function
Initializes hardware and data for the index instance of the CAMERA module.
File
drv_camera.h
C
SYS_MODULE_OBJ DRV_CAMERA_Initialize(const SYS_MODULE_INDEX index, const SYS_MODULE_INIT * const init);
Returns
None.
Description
This function initializes hardware for the index instance of the CAMERA module, using the hardware initialization given data. It also initializes any
internal driver data structures making the driver ready to be opened.
Remarks
None.
Preconditions
None.
Example
DRV_CAMERA_INIT_DATA cameraInitData;
SYS_STATUS cameraStatus;
// Populate the cameraInitData structure
cameraInitData.moduleInit.powerState = SYS_MODULE_POWER_RUN_FULL;
Volume V: MPLAB Harmony Framework Driver Libraries Help Camera Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 74
cameraInitData.moduleInit.moduleCode = (DRV_CAMERA_INIT_DATA_MASTER | DRV_CAMERA_INIT_DATA_SLAVE);
DRV_CAMERA_Initialize(DRV_CAMERA_ID_1, (SYS_MODULE_INIT*)&cameraInitData);
cameraStatus = DRV_CAMERA_Status(DRV_CAMERA_ID_1);
Parameters
Parameters Description
index Index, identifying the instance of the CAMERA module to be initialized
data Pointer to the data structure containing any data necessary to initialize the hardware. This
pointer may be null if no data is required and the default initialization is to be used.
Function
void DRV_CAMERA_Initialize ( const CAMERA_MODULE_ID index,
const SYS_MODULE_INIT *const data )
DRV_CAMERA_Open Function
Opens the specified instance of the Camera driver for use and provides an "open instance" handle.
File
drv_camera.h
C
DRV_HANDLE DRV_CAMERA_Open(const SYS_MODULE_INDEX index, const DRV_IO_INTENT intent);
Returns
If successful, the routine returns a valid open-instance handle (a value identifying both the caller and the module instance). If an error occurs, the
returned value is DRV_HANDLE_INVALID.
Description
This function opens the specified instance of the Camera module for use and provides a handle that is required to use the remaining driver
routines.
This function opens a specified instance of the Camera module driver for use by any client module and provides an "open instance" handle that
must be provided to any of the other Camera driver operations to identify the caller and the instance of the Camera driver/hardware module.
Preconditions
The DRV_CAMERA_Initialize routine must have been called for the specified CAMERA device instance and the DRV_CAMERA_Status must
have returned SYS_STATUS_READY.
Example
DRV_HANDLE cameraHandle;
DRV_CAMERA_CLIENT_STATUS cameraClientStatus;
cameraHandle = DRV_CAMERA_Open(DRV_CAMERA_ID_1, DRV_IO_INTENT_NONBLOCKING|DRV_IO_INTENT_READWRITE);
if (DRV_HANDLE_INVALID == cameraHandle)
{
// Handle open error
}
cameraClientStatus = DRV_CAMERA_ClientStatus(cameraHandle);
// Close the device when it is no longer needed.
DRV_CAMERA_Close(cameraHandle);
Parameters
Parameters Description
index Index, identifying the instance of the CAMERA module to be opened.
intent Flags parameter identifying the intended usage and behavior of the driver. Multiple flags may
be ORed together to specify the intended usage of the device. See the DRV_IO_INTENT
definition.
Function
DRV_HANDLE DRV_CAMERA_Open ( const SYS_MODULE_INDEX index,
Volume V: MPLAB Harmony Framework Driver Libraries Help Camera Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 75
const DRV_IO_INTENT intent )
DRV_CAMERA_Reinitialize Function
Reinitializes hardware and data for the index instance of the CAMERA module.
File
drv_camera.h
C
void DRV_CAMERA_Reinitialize(const SYS_MODULE_INDEX index, const SYS_MODULE_INIT *const data);
Returns
None.
Description
This function reinitializes hardware for the index instance of the CAMERA module, using the hardware initialization given data. It also reinitializes
any internal driver data structures making the driver ready to be opened.
Remarks
None.
Preconditions
The DRV_CAMERA_Initialize function should have been called before calling this function.
Example
SYS_MODULE_INIT cameraInit;
SYS_STATUS cameraStatus;
DRV_CAMERA_Reinitialize(DRV_CAMERA_ID_1, &cameraStatus);
Parameters
Parameters Description
index Index, identifying the instance of the CAMERA module to be reinitialized
data Pointer to the data structure containing any data necessary to reinitialize the hardware. This
pointer may be null if no data is required and default configuration is to be used.
Function
void DRV_CAMERA_Reinitialize( const SYS_MODULE_ID index,
const SYS_MODULE_INIT *const data )
DRV_CAMERA_Status Function
Provides the current status of the index instance of the CAMERA module.
File
drv_camera.h
C
SYS_STATUS DRV_CAMERA_Status(const SYS_MODULE_INDEX index);
Returns
The current status of the index instance.
Description
This function provides the current status of the index instance of the CAMERA module.
Remarks
None.
Preconditions
The DRV_CAMERA_Initialize function should have been called before calling this function.
Volume V: MPLAB Harmony Framework Driver Libraries Help Camera Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 76
Function
SYS_STATUS DRV_CAMERA_Status ( const CAMERA_MODULE_ID index )
DRV_CAMERA_Tasks Function
File
drv_camera.h
C
void DRV_CAMERA_Tasks(SYS_MODULE_OBJ object);
Description
This is function DRV_CAMERA_Tasks.
b) Common Data Types and Constants
DRV_CAMERA_INIT Structure
Defines the data required to initialize or reinitialize the CAMERA driver.
File
drv_camera.h
C
typedef struct {
SYS_MODULE_INIT moduleInit;
int cameraId;
SYS_MODULE_OBJ (* drvInitialize)(const SYS_MODULE_INDEX index, const SYS_MODULE_INIT * const init);
DRV_HANDLE (* drvOpen)(const SYS_MODULE_INDEX index, const DRV_IO_INTENT intent);
INT_SOURCE interruptSource;
DRV_CAMERA_INTERRUPT_PORT_REMAP interruptPort;
uint16_t orientation;
uint16_t horizontalResolution;
uint16_t verticalResolution;
} DRV_CAMERA_INIT;
Members
Members Description
SYS_MODULE_INIT moduleInit; System module initialization
int cameraId; ID
uint16_t orientation; Orientation of the display (given in degrees of 0,90,180,270)
uint16_t horizontalResolution; Horizontal Resolution of the displayed orientation in Pixels
Description
CAMERA Driver Initialization Data
This data type defines the data required to initialize or reinitialize the CAMERA driver. If the driver is built statically, the members of this data
structure are statically over-ridden by static override definitions in the system_config.h file.
Remarks
None.
DRV_CAMERA_INTERRUPT_PORT_REMAP Structure
Defines the data required to initialize the CAMERA driver interrupt port remap.
File
drv_camera.h
C
typedef struct {
Volume V: MPLAB Harmony Framework Driver Libraries Help Camera Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 77
PORTS_REMAP_INPUT_FUNCTION inputFunction;
PORTS_REMAP_INPUT_PIN inputPin;
PORTS_ANALOG_PIN analogPin;
PORTS_PIN_MODE pinMode;
PORTS_CHANNEL channel;
PORTS_DATA_MASK dataMask;
} DRV_CAMERA_INTERRUPT_PORT_REMAP;
Description
CAMERA Driver Interrupt Port Remap Initialization Data
This data type defines the data required to initialize the CAMERA driver interrupt port remap.
Remarks
None.
DRV_CAMERA_INDEX_0 Macro
Camera driver index definitions.
File
drv_camera.h
C
#define DRV_CAMERA_INDEX_0 0
Description
Camera Driver Module Index Numbers
These constants provide the Camera driver index definitions.
Remarks
These constants should be used in place of hard-coded numeric literals.
These values should be passed into the DRV_CAMERA_Initialize and DRV_CAMERA_Open functions to identify the driver instance in use.
DRV_CAMERA_INDEX_1 Macro
File
drv_camera.h
C
#define DRV_CAMERA_INDEX_1 1
Description
This is macro DRV_CAMERA_INDEX_1.
DRV_CAMERA_INDEX_COUNT Macro
Number of valid CAMERA driver indices.
File
drv_camera.h
C
#define DRV_CAMERA_INDEX_COUNT 1
Description
CAMERA Driver Module Index Count
This constant identifies the number of valid CAMERA driver indices.
Remarks
This constant should be used in place of hard-coded numeric literals.
This value is derived from device-specific header files defined as part of the peripheral libraries.
Volume V: MPLAB Harmony Framework Driver Libraries Help Camera Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 78
CAMERA_MODULE_ID Enumeration
File
drv_camera.h
C
typedef enum {
CAMERA_MODULE_OVM7690
} CAMERA_MODULE_ID;
Description
This is type CAMERA_MODULE_ID.
Files
Files
Name Description
drv_camera.h Camera device driver interface file.
Description
drv_camera.h
Camera device driver interface file.
Enumerations
Name Description
CAMERA_MODULE_ID This is type CAMERA_MODULE_ID.
Functions
Name Description
DRV_CAMERA_Close Closes an opened instance of an CAMERA module driver.
DRV_CAMERA_Deinitialize Deinitializes the index instance of the CAMERA module.
DRV_CAMERA_Initialize Initializes hardware and data for the index instance of the CAMERA module.
DRV_CAMERA_Open Opens the specified instance of the Camera driver for use and provides an "open instance"
handle.
DRV_CAMERA_Reinitialize Reinitializes hardware and data for the index instance of the CAMERA module.
DRV_CAMERA_Status Provides the current status of the index instance of the CAMERA module.
DRV_CAMERA_Tasks This is function DRV_CAMERA_Tasks.
Macros
Name Description
DRV_CAMERA_INDEX_0 Camera driver index definitions.
DRV_CAMERA_INDEX_1 This is macro DRV_CAMERA_INDEX_1.
DRV_CAMERA_INDEX_COUNT Number of valid CAMERA driver indices.
Structures
Name Description
DRV_CAMERA_INIT Defines the data required to initialize or reinitialize the CAMERA driver.
DRV_CAMERA_INTERRUPT_PORT_REMAP Defines the data required to initialize the CAMERA driver interrupt port remap.
Description
Camera Driver Interface
The Camera driver provides a abstraction to all camera drivers.
Volume V: MPLAB Harmony Framework Driver Libraries Help Camera Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 79
File Name
drv_camera.h
Company
Microchip Technology Inc.
OVM7690 Camera Driver Library
This topic describes the OVM7690 Camera Driver Library.
Introduction
The OVM7690 Camera Driver provides a high-level interface to manage the OmniVision Technologies, Inc. OVM7690 640x480 CameraCube™
device (referred to as the OVM7690) that is interfaced with serial and parallel ports to a Microchip microcontroller for providing camera solutions.
Description
The OVM7690 640x480 CameraCube™ device (referred to as the OVM7690) can be interfaced to a Microchip microcontroller using the I2C serial
interface and parallel port interface. The I2C serial interface is used for control command transfer. The I2C module from the microcontroller is
connected to the SCCB serial interface of the OVM7690. The parallel port interface is used to transfer pixel data from the OVM7690 to the
microcontroller. There are few other signals from the camera to be interfaced with the microcontroller. The XVCLK pin of the camera is driven by
the Output Compare module. Frame synchronization signals such as HREF and VSYNC from the camera are connected to suitable pins
supporting change notification within the microcontroller. The PCLK pin of the camera drives the pixel clock and is connected at the pin of the
microcontroller supporting external interrupts. The PWDN pin of the camera supports camera power-down mode and is connected at any output
port pin of the microcontroller. A typical interface of the OVM7690 to a PIC32 device is provided in the following diagram:
Using the Library
This topic describes the basic architecture of the OVM7690 Camera Driver Library and provides information and examples on its use.
Description
Interface Header File: drv_camera_ovm7690.h
The interface to the Camera Driver Library is defined in the drv_camera_ovm7690.h header file.
Please refer to the What is MPLAB Harmony? section for how the driver interacts with the framework.
Library Overview
Refer to the Driver Library Overview section for information on how the driver operates in a system.
The library interface routines are divided into various sub-sections, which address the overall operation of the OVM7690 Camera Driver Library.
Library Interface Section Description
System Functions Provides system module interfaces, device initialization and deinitialization.
Client Setup Functions Provides open and close functions.
Camera-specific Functions Provides APIs that are camera-specific.
Other Functions Provides miscellaneous driver-specific functions such as register set functions, among others.
Volume V: MPLAB Harmony Framework Driver Libraries Help Camera Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 80
Abstraction Model
This library provides a low-level abstraction of the OVM7690 Camera Driver Library on Microchip's microcontrollers with a convenient C language
interface. This topic describes how that abstraction is modeled in software and introduces the library's interface.
Description
The OVM7690 Camera Driver is modeled using the abstraction model, as shown in the following diagram.
How the Library Works
Provides information on how the OVM7690 Camera Driver Library works.
Description
The library provides interfaces to support:
• System functionality
• Client functionality
System Initialization
The system performs the Initialization of the device driver with settings that affect only the instance of the device that is being initialized. During
system initialization, each instance of the OVM7690 would be initialized with the following configuration settings that are supported by the specific
OVM7690 device hardware:
• Camera ID: OVM7690 ID
• Source Port: Address of source port to which the pixel data is received
• Horizontal Sync Channel: Channel of the pin to be configured as horizontal sync
• Horizontal Sync Position: Horizontal sync port pin position from selected port channel
• Vertical Sync Channel: Channel the pin to be configured as vertical sync
• Vertical Sync Position: Vertical sync port pin position from selected port channel
• Horizontal Sync Interrupt Source
• Vertical Sync Interrupt Source
• DMA Channel: DMA channel to transfer pixel data from camera to frame buffer
• DMA Channel Trigger Source
• Bits Per Pixel: Bits per pixel to define the size of frame line
The DRV_CAMERA_OVM7690_Initialize API returns an object handle of the type SYS_MODULE_OBJ. The object handler returned by the
Initialize Interface would be used by the other interfaces such as DRV_CAMERA_OVM7690_Deinitialize.
Volume V: MPLAB Harmony Framework Driver Libraries Help Camera Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 81
Client Access
For the application to start using an instance of the module, it must call the DRV_CAMERA_OVM7690_Open function. The
DRV_CAMERA_OVM7690_Open function provides a driver handle to the OVM7690 Camera Driver instance for operations. If the driver is
deinitialized using the function DRV_CAMERA_OVM7690_Deinitialize function, the application must call the DRV_CAMERA_OVM7690_Open
function again to set up the instance of the driver.
Client Operations
Client operations provide the API interface for control command and pixel data transfer from the OVM7690 Camera Driver to the Graphics Frame
Buffer.
Configuring the Library
Macros
Name Description
DRV_OVM7690_INTERRUPT_MODE Controls operation of the driver in the interrupt or polled mode.
Description
The configuration of the OVM7690 Camera Driver is based on the file system_config.h.
This header file contains the configuration selection for the OVM7690 Camera Driver build. Based on the selections made here and the system
setup, the OVM7690 Camera Driver may support the selected features. These configuration settings will apply to all instances of the driver.
This header can be placed anywhere in the application specific folders and the path of this header needs to be presented to the include search for
a successful build. Refer to the Applications Help section for more details.
Control Commands
The following OVM7690-specific control commands are provided:
• DRV_CAMERA_OVM7690_FrameBufferAddressSet
• DRV_CAMERA_OVM7690_Start
• DRV_CAMERA_OVM7690_Stop
• DRV_CAMERA_OVM7690_FrameRectSet
Application Process
An application needs to perform following steps:
1. The system should have completed necessary setup initializations.
2. The I2C driver object should have been initialized by calling DRV_I2C_Initialize.
3. The Timer driver object should have been initialized by calling DRV_Timer_Initialize,
4. The Output Control driver object should have been initialized by calling DRV_OC_Initialize,
5. The OVM7690 Camera Driver object should have been initialized by calling DRV_CAMERA_OVM7690_Initialize,
6. Open the OVM7690 Camera Driver client by calling DRV_CAMERA_OVM7690_Open.
7. Pass the Graphics Frame buffer address to OVM7690 Camera Driver by calling DRV_CAMERA_OVM7690_FrameBufferAddressSet.
8. Set the Frame Rectangle area by calling DRV_CAMERA_OVM7690_FrameRectSet.
9. Set Other Camera settings such as: soft reset, enabling pclk, enabling href, enabling vsync, output color format, reversing HREF polarity,
gating clock to the HREF, pixel clock frequency, sub-sampling mode by calling DRV_CAMERA_OVM7690_RegisterSet.
10. Start the OVM7690 Camera by calling DRV_CAMERA_OVM7690_Start.
DRV_OVM7690_INTERRUPT_MODE Macro
Controls operation of the driver in the interrupt or polled mode.
File
drv_ovm7690_config_template.h
C
#define DRV_OVM7690_INTERRUPT_MODE false
Description
OVM7690 Interrupt And Polled Mode Operation Control
This macro controls the operation of the driver in the interrupt mode of operation. The possible values of this macro are:
• true - Select if interrupt mode of OVM7690 operation is desired
Volume V: MPLAB Harmony Framework Driver Libraries Help Camera Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 82
• false - Select if polling mode of OVM7690 operation is desired
Not defining this option to true or false will result in a build error.
Remarks
None.
Building the Library
This section lists the files that are available in the OVM7690 Camera Driver Library.
Description
The following three tables list and describe the header (.h) and source (.c) files that implement this library. The parent folder for these files is
/framework/driver/camera/ovm7690.
Interface File(s)
This table lists and describes the header files that must be included (i.e., using #include) by any code that uses this library.
Source File Name Description
/drv_camera_ovm7690.h This file provides the interface definitions of the OVM7690 Camera Driver.
Required File(s)
All of the required files listed in the following table are automatically added into the MPLAB X IDE project by the MHC
when the library is selected for use.
This table lists and describes the source and header files that must always be included in the MPLAB X IDE project to build this library.
Source File Name Description
/src/drv_camera_ovm7690.c This file contains the implementation of the OVM7690 Camera Driver.
Optional File(s)
This table lists and describes the source and header files that may optionally be included if required for the desired implementation.
Source File Name Description
N/A No optional files are available for this library.
Module Dependencies
The OVM7690 Camera Driver Library depends on the following modules:
• I2C Driver Library
• Output Compare Driver Library
• Timer Driver Library
Library Interface
a) System Functions
Name Description
DRV_CAMERA_OVM7690_Initialize Initializes the OVM7690 Camera instance for the specified driver index.
DRV_CAMERA_OVM7690_Deinitialize Deinitializes the specified instance of the OVM7690 Camera Driver module.
DRV_CAMERA_OVM7690_RegisterSet Sets the camera OVM7690 configuration registers.
DRV_CAMERA_OVM7690_Tasks Maintains the OVM7690 state machine.
b) Client Setup Functions
Name Description
DRV_CAMERA_OVM7690_Open Opens the specified OVM7690 Camera Driver instance and returns a handle to it.
DRV_CAMERA_OVM7690_Close Closes an opened instance of the OVM7690 Camera Driver.
c) Camera-specific Functions
Name Description
DRV_CAMERA_OVM7690_FrameBufferAddressSet Sets the framebuffer address.
Volume V: MPLAB Harmony Framework Driver Libraries Help Camera Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 83
DRV_CAMERA_OVM7690_FrameRectSet Sets the frame rectangle set.
DRV_CAMERA_OVM7690_Start Starts camera rendering to the display.
DRV_CAMERA_OVM7690_Stop Stops rendering the camera Pixel data.
d) Other Functions
Name Description
DRV_CAMERA_OVM7690_HsyncEventHandler Horizontal synchronization event handler.
DRV_CAMERA_OVM7690_VsyncEventHandler Vertical synchronization event handler .
_DRV_CAMERA_OVM7690_DMAEventHandler This is function _DRV_CAMERA_OVM7690_DMAEventHandler.
_DRV_CAMERA_OVM7690_delayMS This is function _DRV_CAMERA_OVM7690_delayMS.
_DRV_CAMERA_OVM7690_HardwareSetup This is function _DRV_CAMERA_OVM7690_HardwareSetup.
e) Data Types and Constants
Name Description
DRV_CAMERA_OVM7690_CLIENT_OBJ OVM7690 Camera Driver client object.
DRV_CAMERA_OVM7690_CLIENT_STATUS Identifies OVM7690 Camera possible client status.
DRV_CAMERA_OVM7690_ERROR Identifies OVM7690 Camera possible errors.
DRV_CAMERA_OVM7690_INIT OVM7690 Camera Driver initialization parameters.
DRV_CAMERA_OVM7690_OBJ OVM7690 Camera Driver instance object.
DRV_CAMERA_OVM7690_RECT OVM7690 Camera window rectangle coordinates.
DRV_CAMERA_OVM7690_REG12_OP_FORMAT Lists OVM7690 Camera device register addresses.
DRV_CAMERA_OVM7690_INDEX_0 OVM7690 driver index definitions.
DRV_CAMERA_OVM7690_INDEX_1 This is macro DRV_CAMERA_OVM7690_INDEX_1.
DRV_CAMERA_OVM7690_REG12_SOFT_RESET OVM7690 Camera Driver Register 0x12 Soft reset flag.
DRV_CAMERA_OVM7690_SCCB_READ_ID OVM7690 Camera SCCB Interface device Read Slave ID.
DRV_CAMERA_OVM7690_SCCB_WRITE_ID OVM7690 Camera SCCB Interface device Write Slave ID.
Description
This section describes the Application Programming Interface (API) functions of the Camera Driver Library.
a) System Functions
DRV_CAMERA_OVM7690_Initialize Function
Initializes the OVM7690 Camera instance for the specified driver index.
File
drv_camera_ovm7690.h
C
SYS_MODULE_OBJ DRV_CAMERA_OVM7690_Initialize(const SYS_MODULE_INDEX drvIndex, const SYS_MODULE_INIT * const
init);
Returns
If successful, returns a valid handle to a driver instance object. Otherwise, returns SYS_MODULE_OBJ_INVALID.
Description
This function initializes the OVM7690 Camera Driver instance for the specified driver index, making it ready for clients to open and use it. The
initialization data is specified by the init parameter. The initialization may fail if the number of driver objects allocated are insufficient or if the
specified driver instance is already initialized. The driver instance index is independent of the OVM7690 Camera module ID. Refer to the
description of the DRV_CAMERA_OVM7690_INIT data structure for more details on which members on this data structure are overridden.
Remarks
This function must be called before any other OVM7690 Camera Driver function is called.
This function should only be called once during system initialization unless DRV_CAMERA_OVM7690_Deinitialize is called to deinitialize the
driver instance. This function will NEVER block for hardware access.
Volume V: MPLAB Harmony Framework Driver Libraries Help Camera Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 84
Preconditions
None.
Example
// The following code snippet shows an example OVM7690 driver initialization.
DRV_CAMERA_OVM7690_INIT cameraInit;
SYS_MODULE_OBJ objectHandle;
cameraInit.cameraID = CAMERA_MODULE_OVM7690;
cameraInit.sourcePort = (void *)&PORTK,
cameraInit.hsyncInterruptSource = INT_SOURCE_CHANGE_NOTICE_A,
cameraInit.vsyncInterruptSource = INT_SOURCE_CHANGE_NOTICE_J,
cameraInit.dmaChannel = DRV_CAMERA_OVM7690_DMA_CHANNEL_INDEX,
cameraInit.dmaTriggerSource = DMA_TRIGGER_EXTERNAL_2,
cameraInit.bpp = GFX_CONFIG_COLOR_DEPTH,
objectHandle = DRV_CAMERA_OVM7690_Initialize( DRV_CAMERA_OVM7690_INDEX_0,
(SYS_MODULE_INIT*)&cameraInit);
if (SYS_MODULE_OBJ_INVALID == objectHandle)
{
// Handle error
}
Parameters
Parameters Description
index Identifier for the instance to be initialized
init Pointer to a data structure containing any data necessary to initialize the driver.
Function
SYS_MODULE_OBJ DRV_CAMERA_OVM7690_Initialize
(
const SYS_MODULE_INDEX index,
const SYS_MODULE_INIT * const init
)
DRV_CAMERA_OVM7690_Deinitialize Function
Deinitializes the specified instance of the OVM7690 Camera Driver module.
File
drv_camera_ovm7690.h
C
void DRV_CAMERA_OVM7690_Deinitialize(SYS_MODULE_OBJ object);
Returns
None.
Description
This function deinitializes the specified instance of the OVM7690 Camera Driver module, disabling its operation (and any hardware), and
invalidates all of the internal data.
Remarks
Once the Initialize operation has been called, the Deinitialize operation must be called before the Initialize operation can be called again. This
function will NEVER block waiting for hardware.
Preconditions
Function DRV_CAMERA_OVM7690_Initialize should have been called before calling this function.
Example
SYS_MODULE_OBJ object; // Returned from DRV_CAMERA_OVM7690_Initialize
Volume V: MPLAB Harmony Framework Driver Libraries Help Camera Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 85
SYS_STATUS status;
DRV_CAMERA_OVM7690_Deinitialize(object);
status = DRV_CAMERA_OVM7690_Status(object);
if (SYS_MODULE_DEINITIALIZED != status)
{
// Check again later if you need to know
// when the driver is deinitialized.
}
Parameters
Parameters Description
object Driver object handle, returned from the DRV_CAMERA_OVM7690_Initialize function
Function
void DRV_CAMERA_OVM7690_Deinitialize( SYS_MODULE_OBJ object )
DRV_CAMERA_OVM7690_RegisterSet Function
Sets the camera OVM7690 configuration registers.
File
drv_camera_ovm7690.h
C
DRV_CAMERA_OVM7690_ERROR DRV_CAMERA_OVM7690_RegisterSet(DRV_CAMERA_OVM7690_REGISTER_ADDRESS regIndex,
uint8_t regValue);
Returns
• DRV_CAMERA_OVM7690_ERROR_INVALID_HANDLE - Invalid driver Handle.
• DRV_CAMERA_OVM7690_ERROR_NONE - No error.
Description
This function sets the OVM7690 Camera configuration registers using the SCCB interface.
Remarks
This function can be used separately or within an interface.
Preconditions
The DRV_CAMERA_OVM7690_Initialize function must have been called for the specified OVM7690 Camera Driver instance.
DRV_CAMERA_OVM7690_Open must have been called to obtain a valid opened device handle.
The SCCB interface also must have been initialized to configure the OVM7690 Camera Driver.
Example
DRV_HANDLE handle;
uint8_t reg12 = DRV_CAMERA_OVM7690_REG12_SOFT_RESET;
handle = DRV_CAMERA_OVM7690_Open(DRV_CAMERA_OVM7690_INDEX_0, DRV_IO_INTENT_EXCLUSIVE);
if (DRV_HANDLE_INVALID == handle)
{
//error
return;
}
if ( DRV_CAMERA_OVM7690_RegisterSet( DRV_CAMERA_OVM7690_REG12_REG_ADDR,
reg12 ) !=
DRV_CAMERA_OVM7690_ERROR_NONE )
{
//error
return;
}
Volume V: MPLAB Harmony Framework Driver Libraries Help Camera Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 86
Parameters
Parameters Description
regIndex Defines the OVM7690 configuration register addresses.
regValue Defines the register value to be set.
Function
DRV_CAMERA_OVM7690_ERROR DRV_CAMERA_OVM7690_RegisterSet
(
DRV_CAMERA_OVM7690_REGISTER_ADDRESS regIndex,
uint8_t regValue
)
DRV_CAMERA_OVM7690_Tasks Function
Maintains the OVM7690 state machine.
File
drv_camera_ovm7690.h
C
void DRV_CAMERA_OVM7690_Tasks(SYS_MODULE_OBJ object);
Function
void DRV_CAMERA_OVM7690_Tasks(SYS_MODULE_OBJ object );
b) Client Setup Functions
DRV_CAMERA_OVM7690_Open Function
Opens the specified OVM7690 Camera Driver instance and returns a handle to it.
File
drv_camera_ovm7690.h
C
DRV_HANDLE DRV_CAMERA_OVM7690_Open(const SYS_MODULE_INDEX drvIndex, const DRV_IO_INTENT ioIntent);
Returns
If successful, the function returns a valid open instance handle (a number identifying both the caller and the module instance).
If an error occurs, the return value is DRV_HANDLE_INVALID. Errors can occur:
• if the number of client objects allocated via DRV_CAMERA_OVM7690_CLIENTS_NUMBER is insufficient
• if the client is trying to open the driver but driver has been opened exclusively by another client
• if the driver hardware instance being opened is not initialized or is invalid
• if the client is trying to open the driver exclusively, but has already been opened in a non exclusive mode by another client
• if the driver is not ready to be opened, typically when the initialize function has not completed execution
Description
This function opens the specified OVM7690 Camera Driver instance and provides a handle that must be provided to all other client-level
operations to identify the caller and the instance of the driver. The ioIntent parameter defines how the client interacts with this driver instance.
Remarks
The handle returned is valid until the DRV_CAMERA_OVM7690_Close function is called. This function will NEVER block waiting for hardware.If
the requested intent flags are not supported, the function will return DRV_HANDLE_INVALID. This function is thread safe in a RTOS application.
Preconditions
Function DRV_CAMERA_OVM7690_Initialize must have been called before calling this function.
Example
DRV_HANDLE handle;
Volume V: MPLAB Harmony Framework Driver Libraries Help Camera Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 87
handle = DRV_CAMERA_OVM7690_Open(DRV_CAMERA_OVM7690_INDEX_0, DRV_IO_INTENT_EXCLUSIVE);
if (DRV_HANDLE_INVALID == handle)
{
// Unable to open the driver
// May be the driver is not initialized or the initialization
// is not complete.
}
Parameters
Parameters Description
index Identifier for the object instance to be opened
intent Zero or more of the values from the enumeration DRV_IO_INTENT "ORed" together to
indicate the intended use of the driver. See function description for details.
Function
DRV_HANDLE DRV_CAMERA_OVM7690_Open
(
const SYS_MODULE_INDEX index,
const DRV_IO_INTENT ioIntent
)
DRV_CAMERA_OVM7690_Close Function
Closes an opened instance of the OVM7690 Camera Driver.
File
drv_camera_ovm7690.h
C
void DRV_CAMERA_OVM7690_Close(DRV_HANDLE handle);
Returns
None.
Description
This function closes an opened instance of the OVM7690 Camera Driver, invalidating the handle. Any buffers in the driver queue that were
submitted by this client will be removed. After calling this function, the handle passed in "handle" must not be used with any of the remaining driver
routines (with one possible exception described in the "Remarks" section). A new handle must be obtained by calling
DRV_CAMERA_OVM7690_Open before the caller may use the driver again
Remarks
Usually there is no need for the client to verify that the Close operation has completed. The driver will abort any ongoing operations when this
function is called.
Preconditions
The DRV_CAMERA_OVM7690_Initialize function must have been called for the specified OVM7690 Camera Driver instance.
DRV_CAMERA_OVM7690_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE handle; // Returned from DRV_USART_Open
DRV_CAMERA_OVM7690_Close(handle);
Parameters
Parameters Description
handle A valid open instance handle, returned from the driver's Open function
Function
void DRV_CAMERA_OVM7690_Close( DRV_Handle handle )
c) Camera-specific Functions
Volume V: MPLAB Harmony Framework Driver Libraries Help Camera Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 88
DRV_CAMERA_OVM7690_FrameBufferAddressSet Function
Sets the framebuffer address.
File
drv_camera_ovm7690.h
C
DRV_CAMERA_OVM7690_ERROR DRV_CAMERA_OVM7690_FrameBufferAddressSet(DRV_HANDLE handle, void * frameBuffer);
Returns
• DRV_CAMERA_OVM7690_ERROR_INVALID_HANDLE - Invalid driver Handle.
• DRV_CAMERA_OVM7690_ERROR_NONE - No error.
Description
This function will set the framebuffer address. This framebuffer address will point to the location at which frame data is to be rendered. This buffer
is shared with the display controller to display the frame on the display.
Remarks
This function is mandatory. A valid framebuffer address must be set to display the camera data.
Preconditions
The DRV_CAMERA_OVM7690_Initialize function must have been called for the specified OVM7690 Camera Driver instance.
DRV_CAMERA_OVM7690_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE handle;
uint16_t frameBuffer[DISP_VER_RESOLUTION][DISP_HOR_RESOLUTION];
handle = DRV_CAMERA_OVM7690_Open(DRV_CAMERA_OVM7690_INDEX_0, DRV_IO_INTENT_EXCLUSIVE);
if (DRV_HANDLE_INVALID == handle)
{
//error
return;
}
if ( DRV_CAMERA_OVM7690_FrameBufferAddressSet( handle, (void *) frameBuffer ) !=
DRV_CAMERA_OVM7690_ERROR_NONE )
{
//error
return;
}
Parameters
Parameters Description
handle A valid open instance handle, returned from the driver's Open function
Function
DRV_CAMERA_OVM7690_ERROR DRV_CAMERA_OVM7690_FrameBufferAddressSet
(
DRV_HANDLE handle,
void * frameBuffer
)
DRV_CAMERA_OVM7690_FrameRectSet Function
Sets the frame rectangle set.
File
drv_camera_ovm7690.h
Volume V: MPLAB Harmony Framework Driver Libraries Help Camera Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 89
C
DRV_CAMERA_OVM7690_ERROR DRV_CAMERA_OVM7690_FrameRectSet(DRV_HANDLE handle, uint32_t left, uint32_t top,
uint32_t right, uint32_t bottom);
Returns
• DRV_CAMERA_OVM7690_ERROR_INVALID_HANDLE - Invalid driver Handle.
• DRV_CAMERA_OVM7690_ERROR_NONE - No error.
Description
This function sets the frame rectangle coordinates. The frame within the rectangle is copied to the framebuffer. The left and top values are
expected to be less than right and bottom respectively. Left, top, right, and bottom values are also expected to be within range of screen
coordinates. Internally it calls the DRV_CAMERA_OVM7690_RegisterSet function to set the respective registers. The rectangle coordinates are
also maintained in the driver object.
Remarks
This function is optional if default values are expected to be used.
Preconditions
The DRV_CAMERA_OVM7690_Initialize function must have been called for the specified OVM7690 Camera Driver instance.
DRV_CAMERA_OVM7690_Open must have been called to obtain a valid opened device handle.
The SCCB interface also must have been initialized to configure the OVM7690 Camera Driver.
Example
DRV_HANDLE handle;
uint32_t left = 0x69;
uint32_t top = 0x0E;
uint32_t right = DISP_HOR_RESOLUTION + 0x69;
uint32_t bottom = DISP_VER_RESOLUTION + 0x69;
handle = DRV_CAMERA_OVM7690_Open(DRV_CAMERA_OVM7690_INDEX_0, DRV_IO_INTENT_EXCLUSIVE);
if (DRV_HANDLE_INVALID == handle)
{
//error
return;
}
if ( DRV_CAMERA_OVM7690_FrameRectSet( handle, left, top, right, bottom ) !=
DRV_CAMERA_OVM7690_ERROR_NONE )
{
//error
return;
}
Parameters
Parameters Description
handle A valid open instance handle, returned from the driver's Open function
left left frame coordinate
top top frame coordinate
right right frame coordinate
bottom bottom frame coordinate
Function
DRV_CAMERA_OVM7690_ERROR DRV_CAMERA_OVM7690_FrameRectSet
(
DRV_HANDLE handle,
uint32_t left,
uint32_t top,
uint32_t right,
uint32_t bottom
)
Volume V: MPLAB Harmony Framework Driver Libraries Help Camera Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 90
DRV_CAMERA_OVM7690_Start Function
Starts camera rendering to the display.
File
drv_camera_ovm7690.h
C
DRV_CAMERA_OVM7690_ERROR DRV_CAMERA_OVM7690_Start(DRV_HANDLE handle);
Returns
• DRV_CAMERA_OVM7690_ERROR_INVALID_HANDLE - Invalid driver Handle.
• DRV_CAMERA_OVM7690_ERROR_NONE - No error.
Description
This function starts the camera rendering to the display by writing the pixel data to the framebuffer. The framebuffer is shared between the
OVM7690 Camera and the display controller.
Remarks
This function is mandatory. Camera module will not update the framebuffer without calling this function.
Preconditions
The DRV_CAMERA_OVM7690_Initialize function must have been called for the specified OVM7690 Camera Driver instance.
DRV_CAMERA_OVM7690_Open must have been called to obtain a valid opened device handle.
DRV_CAMERA_OVM7690_FrameBufferAddressSet must have been called to set a valid framebuffer address.
Example
DRV_HANDLE handle;
uint16_t frameBuffer[DISP_VER_RESOLUTION][DISP_HOR_RESOLUTION];
handle = DRV_CAMERA_OVM7690_Open(DRV_CAMERA_OVM7690_INDEX_0, DRV_IO_INTENT_EXCLUSIVE);
if (DRV_HANDLE_INVALID == handle)
{
//error
return;
}
if ( DRV_CAMERA_OVM7690_FrameBufferAddressSet( handle, (void *) frameBuffer ) !=
DRV_CAMERA_OVM7690_ERROR_NONE )
{
//error
return;
}
if ( DRV_CAMERA_OVM7690_Start( handle ) !=
DRV_CAMERA_OVM7690_ERROR_NONE )
{
//error
return;
}
Parameters
Parameters Description
handle A valid open instance handle, returned from the driver's Open function
Function
DRV_CAMERA_OVM7690_ERROR DRV_CAMERA_OVM7690_Start
(
DRV_HANDLE handle
);
Volume V: MPLAB Harmony Framework Driver Libraries Help Camera Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 91
DRV_CAMERA_OVM7690_Stop Function
Stops rendering the camera Pixel data.
File
drv_camera_ovm7690.h
C
DRV_CAMERA_OVM7690_ERROR DRV_CAMERA_OVM7690_Stop(DRV_HANDLE handle);
Returns
• DRV_CAMERA_OVM7690_ERROR_INVALID_HANDLE - Invalid driver Handle.
• DRV_CAMERA_OVM7690_ERROR_NONE - No error.
Description
This function starts the camera rendering to the display by writing the pixel data to the framebuffer. The framebuffer is shared between the
OVM7690 Camera and the display controller.
Remarks
This function only disables the interrupt for HSYNC and VSYNC. To stop the camera the power-down pin needs to be toggled to an active-high
value., which will stop the camera internal clock and maintain the register values.
Preconditions
The DRV_CAMERA_OVM7690_Initialize function must have been called for the specified OVM7690 Camera Driver instance.
DRV_CAMERA_OVM7690_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE handle;
handle = DRV_CAMERA_OVM7690_Open(DRV_CAMERA_OVM7690_INDEX_0, DRV_IO_INTENT_EXCLUSIVE);
if (DRV_HANDLE_INVALID == handle)
{
//error
return;
}
if ( DRV_CAMERA_OVM7690_Stop( handle ) !=
DRV_CAMERA_OVM7690_ERROR_NONE )
{
//error
return;
}
Parameters
Parameters Description
handle A valid open instance handle, returned from the driver's Open function.
Function
DRV_CAMERA_OVM7690_ERROR DRV_CAMERA_OVM7690_Stop
(
DRV_HANDLE handle
);
d) Other Functions
DRV_CAMERA_OVM7690_HsyncEventHandler Function
Horizontal synchronization event handler.
Volume V: MPLAB Harmony Framework Driver Libraries Help Camera Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 92
File
drv_camera_ovm7690.h
C
void DRV_CAMERA_OVM7690_HsyncEventHandler(SYS_MODULE_OBJ object);
Returns
None.
Description
This function is called when the OVM7690 Camera sends a Horizontal Sync Pulse on the HSYNC line. It sets the next line address in the DMA
module.
Remarks
This function is mandatory.
Preconditions
The DRV_CAMERA_OVM7690_Initialize function must have been called for the specified OVM7690 Camera Driver instance.
DRV_CAMERA_OVM7690_Open must have been called to obtain a valid opened device handle.
Example
DRV_CAMERA_OVM7690_INIT cameraInit;
SYS_MODULE_OBJ objectHandle;
cameraInit.cameraID = CAMERA_MODULE_OVM7690;
cameraInit.sourcePort = (void *)&PORTK,
cameraInit.hsyncInterruptSource = INT_SOURCE_CHANGE_NOTICE_A,
cameraInit.vsyncInterruptSource = INT_SOURCE_CHANGE_NOTICE_J,
cameraInit.dmaChannel = DRV_CAMERA_OVM7690_DMA_CHANNEL_INDEX,
cameraInit.dmaTriggerSource = DMA_TRIGGER_EXTERNAL_2,
cameraInit.bpp = GFX_CONFIG_COLOR_DEPTH,
objectHandle = DRV_CAMERA_OVM7690_Initialize( DRV_CAMERA_OVM7690_INDEX_0,
(SYS_MODULE_INIT*)&cameraInit);
if (SYS_MODULE_OBJ_INVALID == objectHandle)
{
// Handle error
}
handle = DRV_CAMERA_OVM7690_Open(DRV_CAMERA_OVM7690_INDEX_0, DRV_IO_INTENT_EXCLUSIVE);
if (DRV_HANDLE_INVALID == handle)
{
//error
return;
}
void __ISR( HSYNC_ISR_VECTOR) _Ovm7690HSyncHandler(void)
{
DRV_CAMERA_OVM7690_HsyncEventHandler(objectHandle);
SYS_INT_SourceStatusClear(HSYNC_INTERRUPT_SOURCE);
}
Parameters
Parameters Description
object Driver object handle, returned from the DRV_CAMERA_OVM7690_Initialize function
Function
void DRV_CAMERA_OVM7690_HsyncEventHandler(SYS_MODULE_OBJ object)
DRV_CAMERA_OVM7690_VsyncEventHandler Function
Vertical synchronization event handler .
Volume V: MPLAB Harmony Framework Driver Libraries Help Camera Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 93
File
drv_camera_ovm7690.h
C
void DRV_CAMERA_OVM7690_VsyncEventHandler(SYS_MODULE_OBJ object);
Returns
None.
Description
This function is called when the OVM7690 Camera sends a Vertical Sync Pulse on the VSYNC line. It clears the number of lines drawn variable.
Remarks
This function is mandatory.
Preconditions
The DRV_CAMERA_OVM7690_Initialize function must have been called for the specified OVM7690 Camera Driver instance.
DRV_CAMERA_OVM7690_Open must have been called to obtain a valid opened device handle.
Example
DRV_CAMERA_OVM7690_INIT cameraInit;
SYS_MODULE_OBJ objectHandle;
cameraInit.cameraID = CAMERA_MODULE_OVM7690;
cameraInit.sourcePort = (void *)&PORTK,
cameraInit.hsyncInterruptSource = INT_SOURCE_CHANGE_NOTICE_A,
cameraInit.vsyncInterruptSource = INT_SOURCE_CHANGE_NOTICE_J,
cameraInit.dmaChannel = DRV_CAMERA_OVM7690_DMA_CHANNEL_INDEX,
cameraInit.dmaTriggerSource = DMA_TRIGGER_EXTERNAL_2,
cameraInit.bpp = GFX_CONFIG_COLOR_DEPTH,
objectHandle = DRV_CAMERA_OVM7690_Initialize( DRV_CAMERA_OVM7690_INDEX_0,
(SYS_MODULE_INIT*)&cameraInit);
if (SYS_MODULE_OBJ_INVALID == objectHandle)
{
// Handle error
}
handle = DRV_CAMERA_OVM7690_Open(DRV_CAMERA_OVM7690_INDEX_0, DRV_IO_INTENT_EXCLUSIVE);
if (DRV_HANDLE_INVALID == handle)
{
//error
return;
}
void __ISR( VSYNC_ISR_VECTOR) _Ovm7690VSyncHandler(void)
{
DRV_CAMERA_OVM7690_VsyncEventHandler(objectHandle);
SYS_INT_SourceStatusClear(VSYNC_INTERRUPT_SOURCE);
}
Parameters
Parameters Description
object Driver object handle, returned from the DRV_CAMERA_OVM7690_Initialize function
Function
void DRV_CAMERA_OVM7690_VsyncEventHandler(SYS_MODULE_OBJ object)
Volume V: MPLAB Harmony Framework Driver Libraries Help Camera Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 94
_DRV_CAMERA_OVM7690_DMAEventHandler Function
File
drv_camera_ovm7690.h
C
void _DRV_CAMERA_OVM7690_DMAEventHandler(SYS_DMA_TRANSFER_EVENT event, SYS_DMA_CHANNEL_HANDLE handle,
uintptr_t contextHandle);
Description
This is function _DRV_CAMERA_OVM7690_DMAEventHandler.
_DRV_CAMERA_OVM7690_delayMS Function
File
drv_camera_ovm7690.h
C
void _DRV_CAMERA_OVM7690_delayMS(unsigned int delayMs);
Description
This is function _DRV_CAMERA_OVM7690_delayMS.
_DRV_CAMERA_OVM7690_HardwareSetup Function
File
drv_camera_ovm7690.h
C
void _DRV_CAMERA_OVM7690_HardwareSetup(DRV_CAMERA_OVM7690_OBJ * dObj);
Description
This is function _DRV_CAMERA_OVM7690_HardwareSetup.
e) Data Types and Constants
DRV_CAMERA_OVM7690_CLIENT_OBJ Structure
OVM7690 Camera Driver client object.
File
drv_camera_ovm7690.h
C
typedef struct {
DRV_CAMERA_OVM7690_OBJ * hDriver;
DRV_IO_INTENT ioIntent;
bool inUse;
DRV_CAMERA_OVM7690_ERROR error;
DRV_CAMERA_OVM7690_CLIENT_STATUS status;
} DRV_CAMERA_OVM7690_CLIENT_OBJ;
Members
Members Description
DRV_CAMERA_OVM7690_OBJ * hDriver; The hardware instance object associated with the client
DRV_IO_INTENT ioIntent; The I/O intent with which the client was opened
bool inUse; This flags indicates if the object is in use or is available
DRV_CAMERA_OVM7690_ERROR error; Driver Error
Volume V: MPLAB Harmony Framework Driver Libraries Help Camera Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 95
DRV_CAMERA_OVM7690_CLIENT_STATUS
status;
Client status
Description
OVM7690 Camera Driver Client Object.
This structure provides a definition of the OVM7690 Camera Driver client object.
Remarks
These values are been updated into the DRV_CAMERA_OVM7690_Open function.
DRV_CAMERA_OVM7690_CLIENT_STATUS Enumeration
Identifies OVM7690 Camera possible client status.
File
drv_camera_ovm7690.h
C
typedef enum {
DRV_CAMERA_OVM7690_CLIENT_STATUS_ERROR = DRV_CLIENT_STATUS_ERROR,
DRV_CAMERA_OVM7690_CLIENT_STATUS_CLOSED = DRV_CLIENT_STATUS_CLOSED,
DRV_CAMERA_OVM7690_CLIENT_STATUS_BUSY = DRV_CLIENT_STATUS_BUSY,
DRV_CAMERA_OVM7690_CLIENT_STATUS_READY = DRV_CLIENT_STATUS_READY
} DRV_CAMERA_OVM7690_CLIENT_STATUS;
Members
Members Description
DRV_CAMERA_OVM7690_CLIENT_STATUS_ERROR
= DRV_CLIENT_STATUS_ERROR
An error has occurred.
DRV_CAMERA_OVM7690_CLIENT_STATUS_CLOSED
= DRV_CLIENT_STATUS_CLOSED
The driver is closed, no operations for this client are ongoing, and/or the given handle
is invalid.
DRV_CAMERA_OVM7690_CLIENT_STATUS_BUSY =
DRV_CLIENT_STATUS_BUSY
The driver is currently busy and cannot start additional operations.
DRV_CAMERA_OVM7690_CLIENT_STATUS_READY
= DRV_CLIENT_STATUS_READY
The module is running and ready for additional operations
Description
OVM7690 Camera Client Status.
This enumeration defines possible OVM7690 Camera Client Status.
Remarks
This enumeration values are set by driver interfaces: DRV_CAMERA_OVM7690_Open and DRV_CAMERA_OVM7690_Close.
DRV_CAMERA_OVM7690_ERROR Enumeration
Identifies OVM7690 Camera possible errors.
File
drv_camera_ovm7690.h
C
typedef enum {
DRV_CAMERA_OVM7690_ERROR_INVALID_HANDLE,
DRV_CAMERA_OVM7690_ERROR_NONE
} DRV_CAMERA_OVM7690_ERROR;
Members
Members Description
DRV_CAMERA_OVM7690_ERROR_INVALID_HANDLE OVM7690 Camera Driver Invalid Handle
DRV_CAMERA_OVM7690_ERROR_NONE OVM7690 Camera Driver error none
Description
OVM7690 Camera Error flag
Volume V: MPLAB Harmony Framework Driver Libraries Help Camera Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 96
This enumeration defines possible OVM7690 Camera errors.
Remarks
This enumeration values are returned by driver interfaces in case of errors.
DRV_CAMERA_OVM7690_INIT Structure
OVM7690 Camera Driver initialization parameters.
File
drv_camera_ovm7690.h
C
typedef struct {
CAMERA_MODULE_ID cameraID;
void * sourcePort;
PORTS_CHANNEL hsyncChannel;
PORTS_BIT_POS hsyncPosition;
PORTS_CHANNEL vsyncChannel;
PORTS_BIT_POS vsyncPosition;
INT_SOURCE hsyncInterruptSource;
INT_SOURCE vsyncInterruptSource;
DMA_CHANNEL dmaChannel;
DMA_TRIGGER_SOURCE dmaTriggerSource;
uint16_t bpp;
} DRV_CAMERA_OVM7690_INIT;
Members
Members Description
CAMERA_MODULE_ID cameraID; Camera module ID
void * sourcePort; Source Port Address
PORTS_CHANNEL hsyncChannel; HSYNC pin channel
PORTS_BIT_POS hsyncPosition; HSYNC pin bit position
PORTS_CHANNEL vsyncChannel; VSYNC pin channel
PORTS_BIT_POS vsyncPosition; VSYNC pin bit position
INT_SOURCE hsyncInterruptSource; HSYNC Interrupt Source
INT_SOURCE vsyncInterruptSource; VSYNC Interrupt Source
DMA_CHANNEL dmaChannel; DMA channel
DMA_TRIGGER_SOURCE dmaTriggerSource; DMA trigger source
uint16_t bpp; Bits per pixel
Description
OVM7690 Camera Initialization parameters
This structure defines OVM7690 Camera Driver initialization parameters.
Remarks
These values should be passed into the DRV_CAMERA_OVM7690_Initialize function.
DRV_CAMERA_OVM7690_OBJ Structure
OVM7690 Camera Driver instance object.
File
drv_camera_ovm7690.h
C
typedef struct {
CAMERA_MODULE_ID moduleId;
SYS_STATUS status;
bool inUse;
bool isExclusive;
size_t nClients;
PORTS_CHANNEL hsyncChannel;
PORTS_BIT_POS hsyncPosition;
Volume V: MPLAB Harmony Framework Driver Libraries Help Camera Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 97
PORTS_CHANNEL vsyncChannel;
PORTS_BIT_POS vsyncPosition;
INT_SOURCE hsyncInterruptSource;
INT_SOURCE vsyncInterruptSource;
SYS_DMA_CHANNEL_HANDLE dmaHandle;
DMA_CHANNEL dmaChannel;
DMA_TRIGGER_SOURCE dmaTriggerSource;
bool dmaTransferComplete;
void * sourcePort;
uint32_t frameLineCount;
uint32_t frameLineSize;
void * frameLineAddress;
void * frameBufferAddress;
DRV_CAMERA_OVM7690_RECT rect;
uint16_t bpp;
} DRV_CAMERA_OVM7690_OBJ;
Members
Members Description
CAMERA_MODULE_ID moduleId; The module index associated with the object
SYS_STATUS status; The status of the driver
bool inUse; Flag to indicate this object is in use
bool isExclusive; Flag to indicate that driver has been opened exclusively.
size_t nClients; Keeps track of the number of clients
• that have opened this driver
PORTS_CHANNEL hsyncChannel; HSYNC pin channel
PORTS_BIT_POS hsyncPosition; HSYNC pin bit position
PORTS_CHANNEL vsyncChannel; VSYNC pin channel
PORTS_BIT_POS vsyncPosition; VSYNC pin bit position
INT_SOURCE hsyncInterruptSource; HSYNC Interrupt Source
INT_SOURCE vsyncInterruptSource; VSYNC Interrupt Source
SYS_DMA_CHANNEL_HANDLE dmaHandle; DMA Handle
DMA_CHANNEL dmaChannel; Read DMA channel
DMA_TRIGGER_SOURCE dmaTriggerSource; DMA Trigger Source
bool dmaTransferComplete; DMA Transfer Complete Flag
void * sourcePort; Source Port Address
uint32_t frameLineCount; Frame Line Count
uint32_t frameLineSize; Frame Line Size
void * frameLineAddress; Frame Line Address
void * frameBufferAddress; Framebuffer Address
DRV_CAMERA_OVM7690_RECT rect; Window Rectangle
uint16_t bpp; Bits per pixel supported
Description
OVM7690 Camera Driver Instance Object
This structure provides a definition of the OVM7690 Camera Driver instance object.
Remarks
These values are been updated into the DRV_CAMERA_OVM7690_Initialize function.
DRV_CAMERA_OVM7690_RECT Structure
OVM7690 Camera window rectangle coordinates.
File
drv_camera_ovm7690.h
C
typedef struct {
uint32_t left;
uint32_t top;
uint32_t right;
uint32_t bottom;
Volume V: MPLAB Harmony Framework Driver Libraries Help Camera Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 98
} DRV_CAMERA_OVM7690_RECT;
Members
Members Description
uint32_t left; OVM7690 Camera Window left coordinate
uint32_t top; OVM7690 Camera Window top coordinate
uint32_t right; OVM7690 Camera Window right coordinate
uint32_t bottom; OVM7690 Camera Window bottom coordinate
Description
OVM7690 Camera Window Rect
This structure defines window rectangle co-ordinates as left, right, top, and bottom.
Remarks
These values should be passed into the DRV_CAMERA_OVM7690_FrameRectSet function.
DRV_CAMERA_OVM7690_REG12_OP_FORMAT Enumeration
Lists OVM7690 Camera device register addresses.
File
drv_camera_ovm7690.h
C
typedef enum {
DRV_CAMERA_OVM7690_REG12_OP_FORMAT_RAW_2
} DRV_CAMERA_OVM7690_REG12_OP_FORMAT;
Members
Members Description
DRV_CAMERA_OVM7690_REG12_OP_FORMAT_RAW_2 Bayer Raw Format
Description
OVM7690 Camera Device Register Addresses.
This enumeration defines the list of device register addresses.
Remarks
These constants should be used in place of hard-coded numeric literals. These values should be passed into the
DRV_CAMERA_OVM7690_RegisterSet function. Refer to the specific device data sheet for more information.
DRV_CAMERA_OVM7690_INDEX_0 Macro
OVM7690 driver index definitions.
File
drv_camera_ovm7690.h
C
#define DRV_CAMERA_OVM7690_INDEX_0 0
Description
OVM7690 Camera Driver Module Index
These constants provide OVM7690 Camera Driver index definitions.
Remarks
These constants should be used in place of hard-coded numeric literals. These values should be passed into the
DRV_CAMERA_OVM7690_Initialize and DRV_CAMERA_OVM7690_Open routines to identify the driver instance in use.
Volume V: MPLAB Harmony Framework Driver Libraries Help Camera Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 99
DRV_CAMERA_OVM7690_INDEX_1 Macro
File
drv_camera_ovm7690.h
C
#define DRV_CAMERA_OVM7690_INDEX_1 1
Description
This is macro DRV_CAMERA_OVM7690_INDEX_1.
DRV_CAMERA_OVM7690_REG12_SOFT_RESET Macro
OVM7690 Camera Driver Register 0x12 Soft reset flag.
File
drv_camera_ovm7690.h
C
#define DRV_CAMERA_OVM7690_REG12_SOFT_RESET
Description
OVM7690 Camera Driver Soft reset flag.
This macro provides a definition of the OVM7690 Camera Register 0x12 Soft reset flag.
Remarks
These constants should be used in place of hard-coded numeric literals.
DRV_CAMERA_OVM7690_SCCB_READ_ID Macro
OVM7690 Camera SCCB Interface device Read Slave ID.
File
drv_camera_ovm7690.h
C
#define DRV_CAMERA_OVM7690_SCCB_READ_ID
Description
OVM7690 Camera Driver SCCB Read ID
This macro provides a definition of the OVM7690 Camera SCCB Interface device Read Slave ID.
Remarks
These constants should be used in place of hard-coded numeric literals.
DRV_CAMERA_OVM7690_SCCB_WRITE_ID Macro
OVM7690 Camera SCCB Interface device Write Slave ID.
File
drv_camera_ovm7690.h
C
#define DRV_CAMERA_OVM7690_SCCB_WRITE_ID
Description
OVM7690 Camera Driver SCCB Write ID
This macro provides a definition of the OVM7690 Camera SCCB Interface device Write Slave ID.
Volume V: MPLAB Harmony Framework Driver Libraries Help Camera Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 100
Remarks
These constants should be used in place of hard-coded numeric literals. These values should be passed into the
DRV_CAMERA_OVM7690_RegisterSet function to identify the OVM7690 Camera SCCB Interface device Write Slave ID.
Files
Files
Name Description
drv_camera_ovm7690.h OVM7690 Camera Driver local data structures.
drv_ovm7690_config_template.h OVM7690 Device Driver configuration template.
Description
drv_camera_ovm7690.h
OVM7690 Camera Driver local data structures.
Enumerations
Name Description
DRV_CAMERA_OVM7690_CLIENT_STATUS Identifies OVM7690 Camera possible client status.
DRV_CAMERA_OVM7690_ERROR Identifies OVM7690 Camera possible errors.
DRV_CAMERA_OVM7690_REG12_OP_FORMAT Lists OVM7690 Camera device register addresses.
Functions
Name Description
_DRV_CAMERA_OVM7690_delayMS This is function _DRV_CAMERA_OVM7690_delayMS.
_DRV_CAMERA_OVM7690_DMAEventHandler This is function _DRV_CAMERA_OVM7690_DMAEventHandler.
_DRV_CAMERA_OVM7690_HardwareSetup This is function _DRV_CAMERA_OVM7690_HardwareSetup.
DRV_CAMERA_OVM7690_Close Closes an opened instance of the OVM7690 Camera Driver.
DRV_CAMERA_OVM7690_Deinitialize Deinitializes the specified instance of the OVM7690 Camera Driver module.
DRV_CAMERA_OVM7690_FrameBufferAddressSet Sets the framebuffer address.
DRV_CAMERA_OVM7690_FrameRectSet Sets the frame rectangle set.
DRV_CAMERA_OVM7690_HsyncEventHandler Horizontal synchronization event handler.
DRV_CAMERA_OVM7690_Initialize Initializes the OVM7690 Camera instance for the specified driver index.
DRV_CAMERA_OVM7690_Open Opens the specified OVM7690 Camera Driver instance and returns a handle
to it.
DRV_CAMERA_OVM7690_RegisterSet Sets the camera OVM7690 configuration registers.
DRV_CAMERA_OVM7690_Start Starts camera rendering to the display.
DRV_CAMERA_OVM7690_Stop Stops rendering the camera Pixel data.
DRV_CAMERA_OVM7690_Tasks Maintains the OVM7690 state machine.
DRV_CAMERA_OVM7690_VsyncEventHandler Vertical synchronization event handler .
Macros
Name Description
DRV_CAMERA_OVM7690_INDEX_0 OVM7690 driver index definitions.
DRV_CAMERA_OVM7690_INDEX_1 This is macro DRV_CAMERA_OVM7690_INDEX_1.
DRV_CAMERA_OVM7690_REG12_SOFT_RESET OVM7690 Camera Driver Register 0x12 Soft reset flag.
DRV_CAMERA_OVM7690_SCCB_READ_ID OVM7690 Camera SCCB Interface device Read Slave ID.
DRV_CAMERA_OVM7690_SCCB_WRITE_ID OVM7690 Camera SCCB Interface device Write Slave ID.
Structures
Name Description
DRV_CAMERA_OVM7690_CLIENT_OBJ OVM7690 Camera Driver client object.
DRV_CAMERA_OVM7690_INIT OVM7690 Camera Driver initialization parameters.
DRV_CAMERA_OVM7690_OBJ OVM7690 Camera Driver instance object.
Volume V: MPLAB Harmony Framework Driver Libraries Help Camera Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 101
DRV_CAMERA_OVM7690_RECT OVM7690 Camera window rectangle coordinates.
Description
OVM7690 Camera Driver Local Data Structures
This header file provides the local data structures for the OVM7690 Camera Driver Library.
File Name
drv_camera_ovm7690.h
Company
Microchip Technology Inc.
drv_ovm7690_config_template.h
OVM7690 Device Driver configuration template.
Macros
Name Description
DRV_OVM7690_INTERRUPT_MODE Controls operation of the driver in the interrupt or polled mode.
Description
OVM7690 Device Driver Configuration Template
This header file contains the build-time configuration selections for the OVM7690 device driver. This is the template file which give all possible
configurations that can be made. This file should not be included in any project.
File Name
drv_ovm7690_config_template.h
Company
Microchip Technology Inc.
CAN Driver Library
This section describes the CAN Driver Library.
Introduction
The CAN Static Driver provides a high-level interface to manage the CAN module on the Microchip family of microcontrollers.
Description
Through MHC, this driver provides an API to initialize the CAN module, as well as the baud rate. The API also allows simple transmit and receive
functionality.
Library Interface
Function(s)
Name Description
DRV_CAN_ChannelMessageReceive Receives a message on a channel for the specified driver index.
Implementation: Static
DRV_CAN_ChannelMessageTransmit Transmits a message on a channel for the specified driver index.
Implementation: Static
DRV_CAN_Close Closes the CAN instance for the specified driver index.
Implementation: Static
DRV_CAN_Deinitialize Deinitializes the DRV_CAN_Initialize instance that has been called for the specified driver
index.
Implementation: Static
DRV_CAN_Initialize Initializes the CAN instance for the specified driver index.
Implementation: Static
Volume V: MPLAB Harmony Framework Driver Libraries Help CAN Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 102
DRV_CAN_Open Opens the CAN instance for the specified driver index.
Implementation: Static
Description
This section describes the Application Programming Interface (API) functions of the CAN Driver Library.
Function(s)
DRV_CAN_ChannelMessageReceive Function
Receives a message on a channel for the specified driver index.
Implementation: Static
File
help_drv_can.h
C
bool DRV_CAN_ChannelMessageReceive(CAN_CHANNEL channelNum, int address, uint8_t DLC, uint8_t* message);
Returns
• true - When a message has been received
• false - When a message has not been received
Description
This routine receives data into a buffer from the CAN bus according to the channel, address, and data length given.
Remarks
This routine receives a standard or extended messages based upon the CAN Driver setup.
Preconditions
DRV_CAN_Initialize has been called.
Parameters
Parameters Description
CAN_CHANNEL channelNum CAN channel to use
int address CAN address to receive on
uint8_t DLC Data Length Code of Message
uint8_t* message Pointer to put the message data to receive
Function
bool DRV_CAN_ChannelMessageReceive(CAN_CHANNEL channelNum, int address,
uint8_t DLC, uint8_t* message);
DRV_CAN_ChannelMessageTransmit Function
Transmits a message on a channel for the specified driver index.
Implementation: Static
File
help_drv_can.h
C
bool DRV_CAN_ChannelMessageTransmit(CAN_CHANNEL channelNum, int address, uint8_t DLC, uint8_t* message);
Returns
Boolean "true" when a message has been transmitted.
Description
This routine transmits a data buffer on the CAN bus according to the channel, address, and data length given.
Volume V: MPLAB Harmony Framework Driver Libraries Help CAN Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 103
Remarks
This routine receives a standard or extended messages based upon the CAN Driver setup.
Preconditions
DRV_CAN_Initialize has been called.
Parameters
Parameters Description
CAN_CHANNEL channelNum CAN channel to use
int address CAN address to transmit on
uint8_t DLC Data Length Code of Message
uint8_t* message Pointer to the message data to send
Function
bool DRV_CAN_ChannelMessageTransmit(CAN_CHANNEL channelNum, int address,
uint8_t DLC, uint8_t* message);
DRV_CAN_Close Function
Closes the CAN instance for the specified driver index.
Implementation: Static
File
help_drv_can.h
C
void DRV_CAN_Close();
Returns
None.
Description
This routine closes the CAN driver instance for the specified driver instance, making it ready for clients to use it.
Preconditions
DRV_CAN_Initialize has been called.
Function
void DRV_CAN_Close(void)
DRV_CAN_Deinitialize Function
Deinitializes the DRV_CAN_Initialize instance that has been called for the specified driver index.
Implementation: Static
File
help_drv_can.h
C
void DRV_CAN_Deinitialize();
Returns
None.
Description
This routine deinitializes the CAN Driver instance for the specified driver instance, making it ready for clients to use it. The initialization routine is
specified by the MHC parameters.
Preconditions
None.
Volume V: MPLAB Harmony Framework Driver Libraries Help CAN Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 104
Function
void DRV_CAN_Deinitialize(void)
DRV_CAN_Initialize Function
Initializes the CAN instance for the specified driver index.
Implementation: Static
File
help_drv_can.h
C
void DRV_CAN_Initialize();
Returns
None.
Description
This routine initializes the CAN Driver instance for the specified driver instance, making it ready for clients to use it. The initialization routine is
specified by the MHC parameters.
Remarks
This routine must be called before any other CAN routine is called. This routine should only be called once during system initialization.
Preconditions
None.
Function
void DRV_CAN_Initialize(void)
DRV_CAN_Open Function
Opens the CAN instance for the specified driver index.
Implementation: Static
File
help_drv_can.h
C
void DRV_CAN_Open();
Returns
None.
Description
This routine opens the CAN Driver instance for the specified driver instance, making it ready for clients to use it.
Preconditions
DRV_CAN_Initialize has been called.
Function
void DRV_CAN_Open(void)
Codec Driver Libraries
This section describes the Codec Driver Libraries available in MPLAB Harmony.
AK4384 Codec Driver Library
This topic describes the AK4384 Codec Driver Library.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 105
Introduction
This library provides an interface to manage the AK4384 106 dB 192 kHz 24-Bit DAC that is serially interfaced to a Microchip microcontroller for
providing Audio Solutions.
Description
The AK4384 module is 24-bit Audio DAC from Asahi Kasei Microdevices Corporation. The AK4384 can be interfaced to Microchip microcontrollers
through SPI and I2S serial interfaces. SPI interface is used for control command transfer. The I2S interface is used for Audio data output.
A typical interface of AK4384 to a Microchip PIC32 device is provided in the following diagram:
Features
The AK4384 Codec Driver supports the following features:
• Sampling Rate Ranging from 8 kHz to 192 kHz
• 128 times Oversampling (Normal Speed mode)
• 64 times Oversampling (Double Speed mode)
• 32 times Oversampling (Quad Speed mode)
• Digital de-emphasis for 32k, 44.1k and 48 kHz sampling
• Soft mute
• Digital Attenuator (Linear 256 steps)
• I/F format:
• 24-bit MSB justified
• 24/20/16-bit LSB justified
• I2S
• Master clock:
• 256 fs, 384 fs, 512 fs, 768 fs, or 1152 fs (Normal Speed mode)
• 128 fs, 192 fs, 256 fs, or 384 fs (Double Speed mode)
• 128 fs or 192 fs (Quad Speed mode)
Using the Library
This topic describes the basic architecture of the AK4384 Codec Driver Library and provides information and examples on its use.
Description
Interface Header File: drv_ak4384.h
The interface to the AK4384 Codec Driver library is defined in the drv_ak4384.h header file. Any C language source (.c) file that uses the
AK4384 Codec Driver library should include this header.
Please refer to the What is MPLAB Harmony? section for how the driver interacts with the framework.
Abstraction Model
This library provides a low-level abstraction of the AK4384 Codec Driver Library on the Microchip family microcontrollers with a convenient C
language interface. This topic describes how that abstraction is modeled in software and introduces the library's interface.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 106
Description
The abstraction model shown in the following diagram depicts how the AK4384 Codec Driver is positioned in the MPLAB Harmony framework. The
AK4384 Codec Driver uses the SPI and I2S drivers for control and audio data transfers to the AK4384 module.
AK4384 Driver Abstraction Model
Library Overview
Refer to the Driver Library Overview section for information on how the driver operates in a system.
The AK4384 Codec Driver Library provides an API interface to transfer control commands and digital audio data to the serially interfaced AK4384
DAC module. The library interface routines are divided into various sub-sections, which address one of the blocks or the overall operation of the
AK4384 Codec Driver Library.
Library Interface Section Description
System Functions Provides system module interfaces, device initialization, deinitialization,
reinitialization, tasks and status functions.
Client Setup Functions Provides open and close functions.
Codec Specific Functions Provides functions that are Codec-specific.
Data Transfer Functions Provides data transfer functions.
Other Functions Provides driver specific miscellaneous functions such as sampling rate setting, control
command functions, etc.
Data Types and Constants These data types and constants are required while interacting and setting up the
AK4384 Codec Driver Library.
How the Library Works
The library provides interfaces to support:
• System Functionality
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 107
• Client Functionality
System Access
This topic provides information on system initialization, implementations, and provides a system access code example.
Description
System Initialization
The system performs the initialization of the device driver with settings that affect only the instance of the device that is being initialized. During
system initialization, each instance of the AK4384 module would be initialized with the following configuration settings (either passed dynamically
at run time using DRV_AK4384_INIT or by using Initialization Overrides) that are supported by the specific AK4384 device hardware:
• Device requested power state: one of the System Module Power States. For specific details please refer to Data Types and Constants in the
Library Interface section.
• SPI driver module index. The module index should be same as the one used in initializing the SPI Driver.
• I2S driver module index. The module index should be same as the one used in initializing the I2S Driver.
• Sampling rate
• Master clock detection mode
• Power down pin port initialization
• Queue size for the audio data transmit buffer
The DRV_AK4384_Initialize API returns an object handle of the type SYS_MODULE_OBJ. The object handle returned by the Initialize interface
would be used by the other system interfaces such as DRV_ AK4384_Deinitialize, DRV_ AK4384_Status and DRV_I2S_Tasks.
Implementations
The AK4384 Codec Driver can have the following implementations:
Implementation Description MPLAB Harmony Components
Implementation
1
Dedicated hardware for control (SPI) and data
(I2S) interface.
Standard MPLAB Harmony drivers for SPI and I2S interfaces.
Implementation
2
Dedicated hardware for data (I2S) interface.
Ports pins for control interface.
Standard MPLAB Harmony drivers for I2S interface.
Virtual MPLAB Harmony drivers for SPI interface.
Implementation
3
Dedicated hardware for data (I2S) interface.
Ports pins for control.
Standard MPLAB Harmony drivers for I2S interface.
An internal bit-banged implementation of control interface in the AK4384
Codec Driver.
If Implementation 3 is in use, while initializing fields of DRV_AK4384_INIT structure, the SPI Driver module index initialization is redundant. The
user can pass a dummy value.
For Implementation 3, the user has to additionally initialize parameters to support bit-banged control interface implementation. These additional
parameters can be passed by assigning values to the respective macros in system_config.h.
Example:
DRV_AK4384_INIT drvak4384Init =
{
.moduleInit.value = SYS_MODULE_POWER_RUN_FULL,
.volume = 120,
.mclkMode = DRV_AK4384_MCLK_MODE_MANUAL,
.queueSizeTransmit = 2,
};
/*
The SPI module index should be same as the one used in
initializing the SPI driver.
The SPI module index initialization is redundant
if Implementation 3 is in use.
*/
drvak4384Init.spiDriverModuleIndex = DRV_SPI_INDEX_0;
/*
The I2S module index should be same as the one used in
initializing the I2S driver.
*/
drvak4384Init.i2sDriverModuleIndex = DRV_I2S_INDEX_0;
ak4384DevObject = DRV_AK4384_Initialize(DRV_AK4384_INDEX_0, (SYS_MODULE_INIT *) &drvak4384Init);
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 108
if (SYS_MODULE_OBJ_INVALID == ak4384DevObject)
{
// Handle error
}
Task Routine
The DRV_AK4384_Tasks will be called from the System Task Service.
Client Access
This topic describes client access and includes a code example.
Description
For the application to start using an instance of the module, it must call the DRV_AK4384_Open function. The DRV_AK4384_Open provides a
driver handle to the AK4384 Codec Driver instance for operations. If the driver is deinitialized using the function DRV_AK4384_Deinitialize, the
application must call the DRV_AK4384_Open function again to set up the instance of the driver.
For the various options available for IO_INTENT, please refer to Data Types and Constants in the Library Interface section.
Note:
It is necessary to check the status of driver initialization before opening a driver instance. The status of the AK4384 Codec Driver
can be known by calling DRV_AK4384_Status.
Example:
DRV_HANDLE handle;
SYS_STATUS ak4384Status;
ak4384Status = DRV_AK4384_Status(sysObjects.ak4384DevObject);
if (SYS_STATUS_READY == ak4384Status)
{
// The driver can now be opened.
appData.ak4384Client.handle = DRV_AK4384_Open
(DRV_AK4384_INDEX_0, DRV_IO_INTENT_EXCLUSIVE);
if(appData.ak4384Client.handle != DRV_HANDLE_INVALID)
{
appData.state = APP_STATE_AK4384_SET_BUFFER_HANDLER;
}
else
{
SYS_DEBUG(0, "Find out what's wrong \r\n");
}
}
else
{
/* AK4384 Driver Is not ready */
;
}
Client Operations
This topic describes client operations and provides a code example.
Description
Client operations provide the API interface for control command and audio data transfer to the AK4384 Codec.
The following AK4384 Codec specific control command functions are provided:
Notes:
1. The calling and execution of the following functions does not guarantee that the function (and its associated Codec
command) has been set in the Codec peer interfaced through the SPI. It just means that the submission of the command has
started over the SPI.
2. Regarding Note 1, the user should not call the following functions consecutively, which could result in unexpected behavior. If
needed, the user should confirm the completion status of a function before calling any of the other functions.
3. To know the completion status of the following functions, users can register a command event callback handler by calling the
function ‘DRV_AK4384_CommandEventHandlerSet’. The callback handler will be called when the last submitted command
(submitted by calling one of the following functions) has completed.
• DRV_AK4384_SamplingRateSet
• DRV_AK4384_SamplingRateGet
• DRV_AK4384_VolumeSet
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 109
• DRV_AK4384_VolumeGet
• DRV_AK4384_MuteOn
• DRV_AK4384_MuteOff
• DRV_AK4384_ZeroDetectEnable
• DRV_AK4384_ZeroDetectDisable
• DRV_AK4384_ZeroDetectModeSet
• DRV_AK4384_ZeroDetectInvertEnable
• DRV_AK4384_ZeroDetectInvertDisable
• DRV_AK4384_ChannelOutputInvertEnable
• DRV_AK4384_ChannelOutputInvertDisable
• DRV_AK4384_SlowRollOffFilterEnable
• DRV_AK4384_SlowRollOffFilterDisable
• DRV_AK4384_DeEmphasisFilterSet
These functions schedule a non-blocking control command transfer operation. These functions submit the control command request to the AK4384
Codec. A notification for the submitted requests can be received by registering a command callback event with the driver. The driver notifies by
calling the callback on successfully transmitting the command to the AK4384 Codec module.
The function DRV_AK4384_BufferAddWrite is a buffered data operation functions. This function schedules non-blocking audio data transfer
operation. The function adds the request to the hardware instance queues and returns a buffer handle. The requesting client also registers a
callback event with the driver. The driver notifies the client with DRV_AK4384_BUFFER_EVENT_COMPLETE,
DRV_AK4384_BUFFER_EVENT_ERROR, or DRV_AK4384_BUFFER_EVENT_ABORT events.
The submitted control commands and audio buffer add requests are processed under DRV_AK4384_Tasks function. This function is called from
the SYS_Tasks routine.
The following diagram illustrates the control commands and audio buffered data operations.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 110
Note:
It is not necessary to close and reopen the client between multiple transfers.
An application using the buffered functionality needs to perform the following steps:
1. The system should have completed necessary setup and initializations.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 111
2. The I2S Driver object should have been initialized by calling DRV_I2S_Initialize.
3. The SPI Driver object should have been initialized by calling DRV_SPI_Initialize.
4. The AK4384 Codec Driver object should be initialized by calling DRV_AK4384_Initialize.
5. The necessary sampling rate value should be set up by calling DRV_AK4384_ SamplingRateSet.
6. Register buffer event handler for the client handle by calling DRV_AK4384_BufferEventHandlerSet.
7. Register command event handler for the client handle by calling DRV_AK4384_CommandEventHandlerSet.
8. Submit a command by calling specific command API.
9. Add a buffer to initiate the data transfer by calling DRV_AK4384_BufferAddWrite.
10. The submitted command and Audio data processing happens b calling DRV_AK4384_Tasks from SYS_Tasks.
11. Repeat steps 9 through 10 to handle multiple buffer transmission and reception.
12. When the client is done, it can use DRV_AK4384_Close to close the client handle.
Example:
typedef enum
{
APP_STATE_AK4384_OPEN,
APP_STATE_AK4384_SET_COMMAND_HANDLER,
APP_STATE_AK4384_SET_BUFFER_HANDLER,
APP_STATE_AK4384_SET_SAMPLING_RATE_COMMAND,
APP_STATE_AK4384_ADD_BUFFER,
APP_STATE_AK4384_WAIT_FOR_BUFFER_COMPLETE,
APP_STATE_AK4384_BUFFER_COMPLETE
} APP_STATES;
typedef struct
{
DRV_HANDLE handle;
DRV_AK4384_BUFFER_HANDLE writeBufHandle;
DRV_AK4384_BUFFER_EVENT_HANDLER bufferHandler;
DRV_AK4384_COMMAND_EVENT_HANDLER commandHandler;
uintptr_t context;
uint8_t *txbufferObject;
size_t bufferSize;
} APP_AK4384_CLIENT;
typedef struct
{
/* Application's current state*/
APP_STATES state;
/* USART client handle */
APP_AK4384_CLIENT ak4384Client;
} APP_DATA;
APP_DATA appData;
SYS_MODULE_OBJ ak4384DevObject;
DRV_AK4384_INIT drvak4384Init =
{
.moduleInit.value = SYS_MODULE_POWER_RUN_FULL,
.volume = 120,
.mclkMode = DRV_AK4384_MCLK_MODE_MANUAL,
.queueSizeTransmit = 2,
};
void SYS_Initialize(void * data)
{
/*
The SPI module index should be same as the one used in
initializing the SPI driver.
The SPI module index initialization is redundant
if Implementation 3 (Described in System Access) is in use.
*/
drvak4384Init.spiDriverModuleIndex = DRV_SPI_INDEX_0;
/*
The I2S module index should be same as the one used in
initializing the I2S driver.
*/
drvak4384Init.i2sDriverModuleIndex = DRV_I2S_INDEX_0;
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 112
ak4384DevObject = DRV_AK4384_Initialize(DRV_AK4384_INDEX_0, (SYS_MODULE_INIT *) & drvak4384Init);
if (SYS_MODULE_OBJ_INVALID == ak4384DevObject) {
// Handle error
}
}
void APP_Tasks (void )
{
switch(appData.state)
{
/* Open the ak4384 client and get an Handle */
case APP_STATE_AK4384_OPEN:
{
SYS_STATUS ak4384Status;
ak4384Status = DRV_AK4384_Status(sysObjects.ak4384DevObject);
if (SYS_STATUS_READY == ak4384Status)
{
// This means the driver can now be opened.
appData.ak4384Client.handle = DRV_AK4384_Open(DRV_AK4384_INDEX_0, DRV_IO_INTENT_EXCLUSIVE);
if(appData.ak4384Client.handle != DRV_HANDLE_INVALID)
{
appData.state = APP_STATE_AK4384_SET_COMMAND_HANDLER;
}
else
{
SYS_DEBUG(0, "Find out what is wrong \r\n");
}
}
else
{
/* Wait for AK4384 to Initialize */
;
}
}
break;
/* Register a command event handler */
case APP_STATE_AK4384_SET_COMMAND_HANDLER:
{
DRV_AK4384_CommandEventHandlerSet(appData.ak4384Client.handle,
appData.ak4384Client.commandHandler,
appData.ak4384Client.context);
appData.state = APP_STATE_AK4384_SET_BUFFER_HANDLER;
}
break;
/* Register a buffer event handler */
case APP_STATE_AK4384_SET_BUFFER_HANDLER:
{
DRV_AK4384_BufferEventHandlerSet(appData.ak4384Client.handle,
appData.ak4384Client.bufferHandler,
appData.ak4384Client.context);
appData.state = APP_STATE_AK4384_SET_SAMPLING_RATE_COMMAND;
}
break;
/* Submit a set sampling rate command */
case APP_STATE_AK4384_SET_SAMPLING_RATE_COMMAND:
{
DRV_AK4384_SamplingRateSet(appData.ak4384Client.handle,48000);
appData.state = APP_STATE_AK4384_ADD_BUFFER;
}
break;
/* Add the Audio buffer to be transmitted */
case APP_STATE_AK4384_ADD_BUFFER:
{
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 113
DRV_AK4384_BufferAddWrite(appData.ak4384Client.handle, &appData.ak4384Client.writeBufHandle,
appData.ak4384Client.txbufferObject, appData.ak4384Client.bufferSize);
if(appData.ak4384Client.writeBufHandle != DRV_AK4384_BUFFER_HANDLE_INVALID)
{
appData.state = APP_STATE_AK4384_WAIT_FOR_BUFFER_COMPLETE;
}
else
{
SYS_DEBUG(0, "Find out what is wrong \r\n");
}
}
break;
/* Audio Buffer transmission under process */
case APP_STATE_AK4384_WAIT_FOR_BUFFER_COMPLETE:
{
}
break;
/* Audio Buffer transmission completed */
case APP_STATE_AK4384_BUFFER_COMPLETE:
{
/* Add another buffer */
appData.state = APP_STATE_AK4384_ADD_BUFFER;
}
break;
default:
{
}
break;
}
}
void APP_AK4384CommandEventHandler(uintptr_t context )
{
// Last submitted command successful. Take action as needed.
}
void APP_AK4384BufferEventHandler(DRV_AK4384_BUFFER_EVENT event,
DRV_AK4384_BUFFER_HANDLE handle, uintptr_t context )
{
switch(event)
{
case DRV_AK4384_BUFFER_EVENT_COMPLETE:
{
// Can set appData.state = APP_STATE_AK4384_BUFFER_COMPLETE;
// Take Action as needed
}
break;
case DRV_AK4384_BUFFER_EVENT_ERROR:
{
// Take Action as needed
} break;
case DRV_AK4384_BUFFER_EVENT_ABORT:
{
// Take Action as needed
} break;
}
}
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 114
void SYS_Tasks(void)
{
DRV_AK4384_Tasks(ak4384DevObject);
APP_Tasks();
}
Configuring the Library
Macros
Name Description
DRV_AK4384_CLIENTS_NUMBER Sets up the maximum number of clients that can be connected to any
hardware instance.
DRV_AK4384_CONTROL_CLOCK Sets up clock frequency for the control interface (SPI)
DRV_AK4384_INPUT_REFCLOCK Identifies the input REFCLOCK source to generate the MCLK to codec.
DRV_AK4384_INSTANCES_NUMBER Sets up the maximum number of hardware instances that can be supported
DRV_AK4384_TIMER_DRIVER_MODULE_INDEX Identifies the Timer Module Index for custom virtual SPI driver
implementation.
DRV_AK4384_TIMER_PERIOD Identifies the period for the bit bang timer.
DRV_AK4384_BCLK_BIT_CLK_DIVISOR Sets up the BCLK to LRCK Ratio to Generate Audio Stream for 32, 44.1,
and 48K sampling frequency
DRV_AK4384_MCLK_SAMPLE_FREQ_MULTPLIER Sets up the MCLK to LRCK Ratio to Generate Audio Stream for 32, 44.1
and 48K sampling frequency
Description
The configuration of the AK4384 Codec Driver is based on the file system_config.h.
This header file contains the configuration selection for the AK4384 Codec Driver. Based on the selections made, the driver may support the
selected features. These configuration settings will apply to all instances of the AK4384 Codec Driver.
This header can be placed anywhere, the path of this header needs to be present in the include search path for a successful build. Refer to the
Applications Help section for more details.
DRV_AK4384_CLIENTS_NUMBER Macro
Sets up the maximum number of clients that can be connected to any hardware instance.
File
drv_ak4384_config_template.h
C
#define DRV_AK4384_CLIENTS_NUMBER DRV_AK4384_INSTANCES_NUMBER
Description
AK4384 Client Count Configuration
Sets up the maximum number of clients that can be connected to any hardware instance. Typically only one client could be connected to one
hardware instance. This value represents the total number of clients to be supported across all hardware instances. Therefore, if there are five
AK4384 hardware interfaces, this number will be 5.
Remarks
None.
DRV_AK4384_CONTROL_CLOCK Macro
Sets up clock frequency for the control interface (SPI)
File
drv_ak4384_config_template.h
C
#define DRV_AK4384_CONTROL_CLOCK
Description
AK4384 Control Interface Clock Speed configuration
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 115
Sets up clock frequency for the control interface (SPI). The maximum value supported is 5MHZ.
Remarks
1. This Macro is useful only when a hardware SPI module is not available(used) or a virtual SPI driver is not available(used) for the control
interface to the AK4384 CODEC.
2. This constant needs to defined only for a bit banged implementation of control interface with in the driver.
DRV_AK4384_INPUT_REFCLOCK Macro
Identifies the input REFCLOCK source to generate the MCLK to codec.
File
drv_ak4384_config_template.h
C
#define DRV_AK4384_INPUT_REFCLOCK
Description
AK4384 Input reference clock
Identifies the input REFCLOCK source to generate the MCLK to codec.
Remarks
None.
DRV_AK4384_INSTANCES_NUMBER Macro
Sets up the maximum number of hardware instances that can be supported
File
drv_ak4384_config_template.h
C
#define DRV_AK4384_INSTANCES_NUMBER
Description
AK4384 driver objects configuration
Sets up the maximum number of hardware instances that can be supported. It is recommended that this number be set exactly equal to the
number of AK4384 CODEC modules that are needed by the application. Hardware Instance support consumes RAM memory space. If this macro
is not defined, then the driver will be built statically.
Remarks
None.
DRV_AK4384_TIMER_DRIVER_MODULE_INDEX Macro
Identifies the Timer Module Index for custom virtual SPI driver implementation.
File
drv_ak4384_config_template.h
C
#define DRV_AK4384_TIMER_DRIVER_MODULE_INDEX
Description
AK4384 Timer Module Index
Identifies the Timer Module Index for custom virtual SPI driver implementation. The AK4384 uses SPI protocol for control interface. The Timer
Module Index is needed by AK4384 driver to implement a virtual SPI driver for control command exchange with the AK4384 CODEC.
Remarks
1. This Macro is useful only when a hardware SPI module is not available(used) or a virtual SPI driver is not available(used) for the control
interface to the AK4384 CODEC.
2. This constant needs to defined only for a bit banged implementation of control interface with in the driver.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 116
DRV_AK4384_TIMER_PERIOD Macro
Identifies the period for the bit bang timer.
File
drv_ak4384_config_template.h
C
#define DRV_AK4384_TIMER_PERIOD
Description
AK4384 Timer Period
Identifies the period for the bit bang timer after which the timer interrupt should occur. The value assigned should align with the expected control
interface clock defined by AK4384_CONTROL_CLOCK.
Remarks
1. This Macro is useful only when a hardware SPI module is not available(used) or a virtual SPI driver is not available(used) for the control
interface to the AK4384 CODEC.
2. This constant needs to defined only for a bit banged implementation of control interface with in the driver.
DRV_AK4384_BCLK_BIT_CLK_DIVISOR Macro
Sets up the BCLK to LRCK Ratio to Generate Audio Stream for 32, 44.1, and 48K sampling frequency
File
drv_ak4384_config_template.h
C
#define DRV_AK4384_BCLK_BIT_CLK_DIVISOR
Description
AK4384 BCLK to LRCK Ratio to Generate Audio Stream
Sets up the BCLK to LRCK Ratio to Generate Audio Stream for 32, 44.1 and 48K I2S sampling frequency
Following BCLK to LRCK ratios are supported 16bit LSB Justified >=32fs 20bit LSB Justified >=40fs 24bit MSB Justified >=48fs 24bit I2S
Compatible >=48fs 24bit LSB Justified >=48fs
Typical values for the divisor are 1,2,4 and 8
Remarks
None.
DRV_AK4384_MCLK_SAMPLE_FREQ_MULTPLIER Macro
Sets up the MCLK to LRCK Ratio to Generate Audio Stream for 32, 44.1 and 48K sampling frequency
File
drv_ak4384_config_template.h
C
#define DRV_AK4384_MCLK_SAMPLE_FREQ_MULTPLIER
Description
AK4384 MCLK to LRCK Ratio to Generate Audio Stream
Sets up the MCLK to LRCK Ratio to Generate Audio Stream for 32, 44.1, and 48K I2S sampling frequency
Supported MCLK to LRCK Ratios are as below 256fs, 384fs, 512fs, 768fs or 1152fs [Normal Speed Mode(8kHz~48kHz)] 128fs, 192fs, 256fs or
384fs [Double Speed Mode(60kHz~96kHz)] 128fs, 192fs [Quad Speed Mode(120kHz~192kHz)]
Remarks
None
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 117
Configuring the MHC
Provides examples on how to configure the MPLAB Harmony Configurator (MHC) for a specific driver.
Description
The following three figures show examples of MHC configurations for the AK4384 Codec Driver, I2S Driver, and the Timer Driver.
Figure 1: AK4384 Codec Driver MHC Configuration
Figure 2: I2S Driver MHC Configuration
Figure 3: Timer Driver MHC Configuration
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 118
Building the Library
This section lists the files that are available in the AK4384 Codec Driver Library.
Description
This section list the files that are available in the /src folder of the AK4384 Codec Driver. It lists which files need to be included in the build based
on either a hardware feature present on the board or configuration option selected by the system.
The following three tables list and describe the header (.h) and source (.c) files that implement this library. The parent folder for these files is
/framework/driver/codec/ak4384.
Interface File(s)
This table lists and describes the header files that must be included (i.e., using #include) by any code that uses this library.
Source File Name Description
/drv_ak4384.h Header file that exports the driver API.
Required File(s)
All of the required files listed in the following table are automatically added into the MPLAB X IDE project by the MHC
when the library is selected for use.
This table lists and describes the source and header files that must always be included in the MPLAB X IDE project to build this library.
Source File Name Description
/src/dynamic/drv_ak4384_bit_banged_control_interface.c This file contains implementation of the AK4384 Codec Driver with a
custom bit-banged implementation for control interface driver.
Optional File(s)
This table lists and describes the source and header files that may optionally be included if required for the desired implementation.
Source File Name Description
/src/dynamic/drv_ak4384_virtual_control_interface.c This file contains implementation of the AK4384 Codec Driver with a
virtual SPI driver as control interface driver.
Note: This file is currently unsupported.
/src/dynamic/drv_ak4384.c This file contains the core implementation of the AK4384 Codec Driver
Note: This file currently unsupported.
Module Dependencies
The AK4384 Driver Library depends on the following modules:
• I2S Driver Library
• SPI Driver Library
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 119
• Timer Driver Library
Library Interface
a) System Interaction Functions
Name Description
DRV_AK4384_Initialize Initializes hardware and data for the instance of the AK4384 DAC module.
Implementation: Dynamic
DRV_AK4384_Deinitialize Deinitializes the specified instance of the AK4384 driver module.
Implementation: Dynamic
DRV_AK4384_Status Gets the current status of the AK4384 driver module.
Implementation: Dynamic
DRV_AK4384_Tasks Maintains the driver's control and data interface state machine.
Implementation: Dynamic
DRV_AK4384_SetAudioCommunicationMode This function provides a run time audio format configuration
b) Client Setup Functions
Name Description
DRV_AK4384_Open Opens the specified AK4384 driver instance and returns a handle to it.
Implementation: Dynamic
DRV_AK4384_Close Closes an opened-instance of the AK4384 driver.
Implementation: Dynamic
c) Codec Specific Functions
Name Description
DRV_AK4384_ChannelOutputInvertDisable Disables output polarity of the selected Channel.
Implementation: Dynamic
DRV_AK4384_ChannelOutputInvertEnable Enables output polarity of the selected channel.
Implementation: Dynamic
DRV_AK4384_DeEmphasisFilterSet Allows specifies enabling of digital de-emphasis filter.
Implementation: Dynamic
DRV_AK4384_MuteOff Disables AK4384 output for soft mute.
Implementation: Dynamic
DRV_AK4384_MuteOn Allows AK4384 output for soft mute on.
Implementation: Dynamic
DRV_AK4384_SamplingRateGet This function gets the sampling rate set on the DAC AK4384.
Implementation: Dynamic
DRV_AK4384_SamplingRateSet This function sets the sampling rate of the media stream.
Implementation: Dynamic
DRV_AK4384_SlowRollOffFilterDisable Disables Slow Roll-off filter function.
Implementation: Dynamic
DRV_AK4384_SlowRollOffFilterEnable Enables Slow Roll-off filter function.
Implementation: Dynamic
DRV_AK4384_VolumeGet This function gets the volume for AK4384 Codec.
Implementation: Dynamic
DRV_AK4384_VolumeSet This function sets the volume for AK4384 Codec.
Implementation: Dynamic
DRV_AK4384_ZeroDetectDisable Disables AK4384 channel-independent zeros detect function.
Implementation: Dynamic
DRV_AK4384_ZeroDetectEnable Enables AK4384 channel-independent zeros detect function.
Implementation: Dynamic
DRV_AK4384_ZeroDetectInvertDisable Disables inversion of polarity for zero detect function.
Implementation: Dynamic
DRV_AK4384_ZeroDetectInvertEnable Enables inversion of polarity for zero detect function.
Implementation: Dynamic
DRV_AK4384_ZeroDetectModeSet Sets mode of AK4384 channel-independent zeros detect function.
Implementation: Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 120
d) Data Transfer Functions
Name Description
DRV_AK4384_BufferAddWrite Schedule a non-blocking driver write operation.
Implementation: Dynamic
DRV_AK4384_BufferEventHandlerSet This function allows a client to identify a buffer event handling function for the driver
to call back when queued buffer transfers have finished.
Implementation: Dynamic
DRV_AK4384_BufferCombinedQueueSizeGet This function returns the number of bytes queued (to be processed) in the buffer
queue.
Implementation: Dynamic
DRV_AK4384_BufferQueueFlush This function flushes off the buffers associated with the client object.
Implementation: Dynamic
DRV_AK4384_BufferProcessedSizeGet This function returns number of bytes that have been processed for the specified
buffer.
Implementation: Dynamic
e) Other Functions
Name Description
DRV_AK4384_CommandEventHandlerSet This function allows a client to identify a command event handling function for the
driver to call back when the last submitted command have finished.
Implementation: Dynamic
DRV_AK4384_VersionGet Returns the version of the AK4384 driver.
Implementation: Dynamic
DRV_AK4384_VersionStrGet Returns the version of AK4384 driver in string format.
Implementation: Dynamic
f) Data Types and Constants
Name Description
DRV_AK4384_AUDIO_DATA_FORMAT Identifies the Serial Audio data interface format.
DRV_AK4384_BUFFER_EVENT Identifies the possible events that can result from a buffer add request.
DRV_AK4384_BUFFER_EVENT_HANDLER Pointer to a AK4384 Driver Buffer Event handler function.
DRV_AK4384_BUFFER_HANDLE Handle identifying a write buffer passed to the driver.
DRV_AK4384_CHANNEL Identifies Left/Right Audio channel
DRV_AK4384_COMMAND_EVENT_HANDLER Pointer to a AK4384 Driver Command Event Handler Function
DRV_AK4384_DEEMPHASIS_FILTER Identifies de-emphasis filter function.
DRV_AK4384_INIT Defines the data required to initialize or reinitialize the AK4384 driver.
DRV_AK4384_MCLK_MODE Identifies the mode of master clock to AK4384 DAC.
DRV_AK4384_ZERO_DETECT_MODE Identifies Zero Detect Function mode
DRV_AK4384_BUFFER_HANDLE_INVALID Definition of an invalid buffer handle.
DRV_AK4384_COUNT Number of valid AK4384 driver indices.
DRV_AK4384_INDEX_0 AK4384 driver index definitions.
DRV_AK4384_INDEX_1 This is macro DRV_AK4384_INDEX_1.
DRV_AK4384_INDEX_2 This is macro DRV_AK4384_INDEX_2.
DRV_AK4384_INDEX_3 This is macro DRV_AK4384_INDEX_3.
DRV_AK4384_INDEX_4 This is macro DRV_AK4384_INDEX_4.
DRV_AK4384_INDEX_5 This is macro DRV_AK4384_INDEX_5.
Description
This section describes the API functions of the AK4384 Codec Driver library.
Refer to each section for a detailed description.
a) System Interaction Functions
DRV_AK4384_Initialize Function
Initializes hardware and data for the instance of the AK4384 DAC module.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 121
Implementation: Dynamic
File
drv_ak4384.h
C
SYS_MODULE_OBJ DRV_AK4384_Initialize(const SYS_MODULE_INDEX drvIndex, const SYS_MODULE_INIT * const init);
Returns
If successful, returns a valid handle to a driver instance object. Otherwise, it returns SYS_MODULE_OBJ_INVALID.
Description
This routine initializes the AK4384 driver instance for the specified driver index, making it ready for clients to open and use it. The initialization data
is specified by the 'init' parameter. The initialization may fail if the number of driver objects allocated are insufficient or if the specified driver
instance is already initialized.
Remarks
This routine must be called before any other AK4384 routine is called.
This routine should only be called once during system initialization unless DRV_AK4384_Deinitialize is called to deinitialize the driver instance.
This routine will NEVER block for hardware access.
Preconditions
DRV_I2S_Initialize must be called before calling this function to initialize the data interface of this CODEC driver. DRV_SPI_Initialize must be
called if SPI driver is used for handling the control interface of this CODEC driver.
Example
DRV_AK4384_INIT init;
SYS_MODULE_OBJ objectHandle;
init.moduleInit.value = SYS_MODULE_POWER_RUN_FULL;
init.spiDriverModuleIndex = DRV_SPI_INDEX_0; // This will be ignored for a custom
// control interface driver implementation
init.i2sDriverModuleIndex = DRV_I2S_INDEX_0;
init.mclkMode = DRV_AK4384_MCLK_MODE_MANUAL;
init.audioDataFormat = DRV_AK4384_AUDIO_DATA_FORMAT_24BIT_I2S;
init.powerDownPortChannel = PORT_CHANNEL_G;
init.powerDownBitPosition = PORTS_BIT_POS_15;
objectHandle = DRV_AK4384_Initialize(DRV_AK4384_0, (SYS_MODULE_INIT*)init);
if (SYS_MODULE_OBJ_INVALID == objectHandle)
{
// Handle error
}
Parameters
Parameters Description
drvIndex Identifier for the driver instance to be initialized
init Pointer to the data structure containing any data necessary to initialize the hardware. This
pointer may be null if no data is required and default initialization is to be used.
Function
SYS_MODULE_OBJ DRV_AK4384_Initialize
(
const SYS_MODULE_INDEX drvIndex,
const SYS_MODULE_INIT *const init
);
DRV_AK4384_Deinitialize Function
Deinitializes the specified instance of the AK4384 driver module.
Implementation: Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 122
File
drv_ak4384.h
C
void DRV_AK4384_Deinitialize(SYS_MODULE_OBJ object);
Returns
None.
Description
Deinitializes the specified instance of the AK4384 driver module, disabling its operation (and any hardware). Invalidates all the internal data.
Remarks
Once the Initialize operation has been called, the Deinitialize operation must be called before the Initialize operation can be called again. This
routine will NEVER block waiting for hardware.
Preconditions
Function DRV_AK4384_Initialize should have been called before calling this function.
Example
SYS_MODULE_OBJ object; // Returned from DRV_AK4384_Initialize
SYS_STATUS status;
DRV_AK4384_Deinitialize(object);
status = DRV_AK4384_Status(object);
if (SYS_MODULE_DEINITIALIZED != status)
{
// Check again later if you need to know
// when the driver is deinitialized.
}
Parameters
Parameters Description
object Driver object handle, returned from the DRV_AK4384_Initialize routine
Function
void DRV_AK4384_Deinitialize( SYS_MODULE_OBJ object)
DRV_AK4384_Status Function
Gets the current status of the AK4384 driver module.
Implementation: Dynamic
File
drv_ak4384.h
C
SYS_STATUS DRV_AK4384_Status(SYS_MODULE_OBJ object);
Returns
SYS_STATUS_DEINITIALIZED - Indicates that the driver has been deinitialized
SYS_STATUS_READY - Indicates that any previous module operation for the specified module has completed
SYS_STATUS_BUSY - Indicates that a previous module operation for the specified module has not yet completed
SYS_STATUS_ERROR - Indicates that the specified module is in an error state
Description
This routine provides the current status of the AK4384 driver module.
Remarks
A driver can opened only when its status is SYS_STATUS_READY.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 123
Preconditions
Function DRV_AK4384_Initialize should have been called before calling this function.
Example
SYS_MODULE_OBJ object; // Returned from DRV_AK4384_Initialize
SYS_STATUS ak4384Status;
ak4384Status = DRV_AK4384_Status(object);
if (SYS_STATUS_READY == ak4384Status)
{
// This means the driver can be opened using the
// DRV_AK4384_Open function.
}
Parameters
Parameters Description
object Driver object handle, returned from the DRV_AK4384_Initialize routine
Function
SYS_STATUS DRV_AK4384_Status( SYS_MODULE_OBJ object)
DRV_AK4384_Tasks Function
Maintains the driver's control and data interface state machine.
Implementation: Dynamic
File
drv_ak4384.h
C
void DRV_AK4384_Tasks(SYS_MODULE_OBJ object);
Returns
None.
Description
This routine is used to maintain the driver's internal control and data interface state machine and implement its control and data interface
implementations. This function should be called from the SYS_Tasks function.
Remarks
This routine is normally not called directly by an application. It is called by the system's Tasks routine (SYS_Tasks).
Preconditions
The DRV_AK4384_Initialize routine must have been called for the specified AK4384 driver instance.
Example
SYS_MODULE_OBJ object; // Returned from DRV_AK4384_Initialize
while (true)
{
DRV_AK4384_Tasks (object);
// Do other tasks
}
Parameters
Parameters Description
object Object handle for the specified driver instance (returned from DRV_AK4384_Initialize)
Function
void DRV_AK4384_Tasks(SYS_MODULE_OBJ object);
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 124
DRV_AK4384_SetAudioCommunicationMode Function
This function provides a run time audio format configuration
File
drv_ak4384.h
C
void DRV_AK4384_SetAudioCommunicationMode(DRV_HANDLE handle, const DATA_LENGTH dl, const SAMPLE_LENGTH sl);
Returns
None
Description
This function sets up audio mode in I2S protocol
Remarks
None.
Preconditions
The DRV_AK4384_Initialize routine must have been called for the specified AK4384 driver instance.
DRV_AK4384_Open must have been called to obtain a valid opened device handle.
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
dl Data length for I2S audio interface
sl Left/Right Sample Length for I2S audio interface
Function
void DRV_AK4384_SetAudioCommunicationMode
(
DRV_HANDLE handle,
const DATA_LENGTH dl,
const SAMPLE_LENGTH sl
)
b) Client Setup Functions
DRV_AK4384_Open Function
Opens the specified AK4384 driver instance and returns a handle to it.
Implementation: Dynamic
File
drv_ak4384.h
C
DRV_HANDLE DRV_AK4384_Open(const SYS_MODULE_INDEX iDriver, const DRV_IO_INTENT ioIntent);
Returns
If successful, the routine returns a valid open-instance handle (a number identifying both the caller and the module instance).
If an error occurs, the return value is DRV_HANDLE_INVALID. Errors can occur under following conditions:
• if the number of client objects allocated via DRV_AK4384_CLIENTS_NUMBER is insufficient
• if the client is trying to open the driver but driver has been opened exclusively by another client
• if the driver hardware instance being opened is not initialized or is invalid
• if the ioIntent options passed are not relevant to this driver
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 125
Description
This routine opens the specified AK4384 driver instance and provides a handle that must be provided to all other client-level operations to identify
the caller and the instance of the driver. The ioIntent parameter defines how the client interacts with this driver instance.
The DRV_IO_INTENT_BLOCKING and DRV_IO_INTENT_NONBLOCKING ioIntent options are not relevant to this driver. All the data transfer
functions of this driver are non blocking.
Only DRV_IO_INTENT_WRITE is a valid ioIntent option as AK4384 is DAC only.
Specifying a DRV_IO_INTENT_EXCLUSIVE will cause the driver to provide exclusive access to this client. The driver cannot be opened by any
other client.
Remarks
The handle returned is valid until the DRV_AK4384_Close routine is called. This routine will NEVER block waiting for hardware.If the requested
intent flags are not supported, the routine will return DRV_HANDLE_INVALID. This function is thread safe in a RTOS application. It should not be
called in an ISR.
Preconditions
Function DRV_AK4384_Initialize must have been called before calling this function.
Example
DRV_HANDLE handle;
handle = DRV_AK4384_Open(DRV_AK4384_INDEX_0, DRV_IO_INTENT_EXCLUSIVE);
if (DRV_HANDLE_INVALID == handle)
{
// Unable to open the driver
// May be the driver is not initialized or the initialization
// is not complete.
}
Parameters
Parameters Description
drvIndex Identifier for the object instance to be opened
ioIntent Zero or more of the values from the enumeration DRV_IO_INTENT "ORed" together to
indicate the intended use of the driver. See function description for details.
Function
DRV_HANDLE DRV_AK4384_Open
(
const SYS_MODULE_INDEX drvIndex,
const DRV_IO_INTENT ioIntent
)
DRV_AK4384_Close Function
Closes an opened-instance of the AK4384 driver.
Implementation: Dynamic
File
drv_ak4384.h
C
void DRV_AK4384_Close(const DRV_HANDLE handle);
Returns
None.
Description
This routine closes an opened-instance of the AK4384 driver, invalidating the handle. Any buffers in the driver queue that were submitted by this
client will be removed. After calling this routine, the handle passed in "handle" must not be used with any of the remaining driver routines. A new
handle must be obtained by calling DRV_AK4384_Open before the caller may use the driver again
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 126
Remarks
Usually there is no need for the driver client to verify that the Close operation has completed. The driver will abort any ongoing operations when
this routine is called.
Preconditions
The DRV_AK4384_Initialize routine must have been called for the specified AK4384 driver instance.
DRV_AK4384_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE handle; // Returned from DRV_AK4384_Open
DRV_AK4384_Close(handle);
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
void DRV_AK4384_Close( DRV_Handle handle )
c) Codec Specific Functions
DRV_AK4384_ChannelOutputInvertDisable Function
Disables output polarity of the selected Channel.
Implementation: Dynamic
File
drv_ak4384.h
C
void DRV_AK4384_ChannelOutputInvertDisable(DRV_HANDLE handle, DRV_AK4384_CHANNEL chan);
Returns
None.
Description
This function disables output polarity of the selected Channel.
Remarks
None.
Preconditions
The DRV_AK4384_Initialize routine must have been called for the specified AK4384 driver instance.
DRV_AK4384_Open must have been called to obtain a valid opened device handle.
Example
// myAppObj is an application specific object.
MY_APP_OBJ myAppObj;
// myAK4384Handle is the handle returned
// by the DRV_AK4384_Open function.
DRV_AK4384_ChannelOutputInvertDisable(myAK4384Handle, DRV_AK4384_CHANNEL_LEFT);
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
chan Left or Right channel
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 127
Function
void DRV_AK4384_ChannelOutputInvertDisable( DRV_HANDLE handle, DRV_AK4384_CHANNEL chan)
DRV_AK4384_ChannelOutputInvertEnable Function
Enables output polarity of the selected channel.
Implementation: Dynamic
File
drv_ak4384.h
C
void DRV_AK4384_ChannelOutputInvertEnable(DRV_HANDLE handle, DRV_AK4384_CHANNEL chan);
Returns
None.
Description
This function enables output polarity of the selected channel.
Remarks
None.
Preconditions
The DRV_AK4384_Initialize routine must have been called for the specified AK4384 driver instance.
DRV_AK4384_Open must have been called to obtain a valid opened device handle.
Example
// myAppObj is an application specific object.
MY_APP_OBJ myAppObj;
// myAK4384Handle is the handle returned
// by the DRV_AK4384_Open function.
DRV_AK4384_ChannelOutputInvertEnable(myAK4384Handle, DRV_AK4384_CHANNEL_LEFT);
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
chan Left or Right channel
Function
void DRV_AK4384_ChannelOutputInvertEnable( DRV_HANDLE handle, DRV_AK4384_CHANNEL chan)
DRV_AK4384_DeEmphasisFilterSet Function
Allows specifies enabling of digital de-emphasis filter.
Implementation: Dynamic
File
drv_ak4384.h
C
void DRV_AK4384_DeEmphasisFilterSet(DRV_HANDLE handle, DRV_AK4384_DEEMPHASIS_FILTER filter);
Returns
None.
Description
This function allows specifies enabling of digital de-emphasis for 32, 44.1 or 48 kHz sampling rates (tc = 50/15 µs)
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 128
Remarks
None.
Preconditions
The DRV_AK4384_Initialize routine must have been called for the specified AK4384 driver instance.
DRV_AK4384_Open must have been called to obtain a valid opened device handle.
Example
// myAppObj is an application specific object.
MY_APP_OBJ myAppObj;
// myAK4384Handle is the handle returned
// by the DRV_AK4384_Open function.
DRV_AK4384_DeEmphasisFilterSet(myAK4384Handle, DRV_AK4384_DEEMPHASIS_FILTER_44_1KHZ)
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
filter Specifies Enable of de-emphasis filter
Function
void DRV_AK4384_DeEmphasisFilterSet
(
DRV_HANDLE handle,
DRV_AK4384_DEEMPHASIS_FILTER filter
)
DRV_AK4384_MuteOff Function
Disables AK4384 output for soft mute.
Implementation: Dynamic
File
drv_ak4384.h
C
void DRV_AK4384_MuteOff(DRV_HANDLE handle);
Returns
None.
Description
This function disables AK4384 output for soft mute.
Remarks
None.
Preconditions
The DRV_AK4384_Initialize routine must have been called for the specified AK4384 driver instance.
DRV_AK4384_Open must have been called to obtain a valid opened device handle.
Example
// myAppObj is an application specific object.
MY_APP_OBJ myAppObj;
// myAK4384Handle is the handle returned
// by the DRV_AK4384_Open function.
DRV_AK4384_MuteOff(myAK4384Handle); //AK4384 output soft mute disabled
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 129
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
void DRV_AK4384_MuteOff( DRV_HANDLE handle)
DRV_AK4384_MuteOn Function
Allows AK4384 output for soft mute on.
Implementation: Dynamic
File
drv_ak4384.h
C
void DRV_AK4384_MuteOn(DRV_HANDLE handle);
Returns
None.
Description
This function Enables AK4384 output for soft mute.
Remarks
None.
Preconditions
The DRV_AK4384_Initialize routine must have been called for the specified AK4384 driver instance.
DRV_AK4384_Open must have been called to obtain a valid opened device handle.
Example
// myAppObj is an application specific object.
MY_APP_OBJ myAppObj;
// myAK4384Handle is the handle returned
// by the DRV_AK4384_Open function.
DRV_AK4384_MuteOn(myAK4384Handle); //AK4384 output soft muted
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
void DRV_AK4384_MuteOn( DRV_HANDLE handle);
DRV_AK4384_SamplingRateGet Function
This function gets the sampling rate set on the DAC AK4384.
Implementation: Dynamic
File
drv_ak4384.h
C
uint32_t DRV_AK4384_SamplingRateGet(DRV_HANDLE handle);
Returns
None.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 130
Description
This function gets the sampling rate set on the DAC AK4384.
Remarks
None.
Preconditions
The DRV_AK4384_Initialize routine must have been called for the specified AK4384 driver instance.
DRV_AK4384_Open must have been called to obtain a valid opened device handle.
Example
uint32_t baudRate;
// myAK4384Handle is the handle returned
// by the DRV_AK4384_Open function.
baudRate = DRV_AK4384_SamplingRateGet(myAK4384Handle);
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
uint32_t DRV_AK4384_SamplingRateGet( DRV_HANDLE handle)
DRV_AK4384_SamplingRateSet Function
This function sets the sampling rate of the media stream.
Implementation: Dynamic
File
drv_ak4384.h
C
void DRV_AK4384_SamplingRateSet(DRV_HANDLE handle, uint32_t samplingRate);
Returns
None.
Description
This function sets the media sampling rate for the client handle.
Remarks
None.
Preconditions
The DRV_AK4384_Initialize routine must have been called for the specified AK4384 driver instance.
DRV_AK4384_Open must have been called to obtain a valid opened device handle.
Example
// myAK4384Handle is the handle returned
// by the DRV_AK4384_Open function.
DRV_AK4384_SamplingRateSet(myAK4384Handle, 48000); //Sets 48000 media sampling rate
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
baudRate Baud Rate to be set
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 131
Function
void DRV_AK4384_SamplingRateSet( DRV_HANDLE handle, uint32_t samplingRate)
DRV_AK4384_SlowRollOffFilterDisable Function
Disables Slow Roll-off filter function.
Implementation: Dynamic
File
drv_ak4384.h
C
void DRV_AK4384_SlowRollOffFilterDisable(DRV_HANDLE handle);
Returns
None.
Description
This function disables Slow Roll-off filter function. Sharp Roll-off filter function gets enabled.
Remarks
None.
Preconditions
The DRV_AK4384_Initialize routine must have been called for the specified AK4384 driver instance.
DRV_AK4384_Open must have been called to obtain a valid opened device handle.
Example
// myAppObj is an application specific object.
MY_APP_OBJ myAppObj;
// myAK4384Handle is the handle returned
// by the DRV_AK4384_Open function.
DRV_AK4384_SlowRollOffFilterDisable(myAK4384Handle);
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
void DRV_AK4384_SlowRollOffFilterDisable( DRV_HANDLE handle);
DRV_AK4384_SlowRollOffFilterEnable Function
Enables Slow Roll-off filter function.
Implementation: Dynamic
File
drv_ak4384.h
C
void DRV_AK4384_SlowRollOffFilterEnable(DRV_HANDLE handle);
Returns
None.
Description
This function enables Slow Roll-off filter function.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 132
Remarks
None.
Preconditions
The DRV_AK4384_Initialize routine must have been called for the specified AK4384 driver instance.
DRV_AK4384_Open must have been called to obtain a valid opened device handle.
Example
// myAppObj is an application specific object.
MY_APP_OBJ myAppObj;
// myAK4384Handle is the handle returned
// by the DRV_AK4384_Open function.
DRV_AK4384_SlowRollOffFilterEnable(myAK4384Handle);
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
void DRV_AK4384_SlowRollOffFilterEnable( DRV_HANDLE handle);
DRV_AK4384_VolumeGet Function
This function gets the volume for AK4384 Codec.
Implementation: Dynamic
File
drv_ak4384.h
C
uint8_t DRV_AK4384_VolumeGet(DRV_HANDLE handle, DRV_AK4384_CHANNEL chan);
Returns
None.
Description
This functions gets the current volume programmed to the DAC AK4384.
Remarks
None.
Preconditions
The DRV_AK4384_Initialize routine must have been called for the specified AK4384 driver instance.
DRV_AK4384_Open must have been called to obtain a valid opened device handle.
Example
// myAppObj is an application specific object.
MY_APP_OBJ myAppObj;
uint8_t volume;
// myAK4384Handle is the handle returned
// by the DRV_AK4384_Open function.
volume = DRV_AK4384_VolumeGet(myAK4384Handle, DRV_AK4384_CHANNEL_LEFT_RIGHT);
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
chan Audio channel volume to get.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 133
Function
uint8_t DRV_AK4384_VolumeGet( DRV_HANDLE handle, DRV_AK4384_CHANNEL chan)
DRV_AK4384_VolumeSet Function
This function sets the volume for AK4384 Codec.
Implementation: Dynamic
File
drv_ak4384.h
C
void DRV_AK4384_VolumeSet(DRV_HANDLE handle, DRV_AK4384_CHANNEL chan, uint8_t volume);
Returns
None.
Description
This functions sets the volume value from 0-255, which can attenuate from 0 dB to –48 dB and mute.
Remarks
None.
Preconditions
The DRV_AK4384_Initialize routine must have been called for the specified AK4384 driver instance.
DRV_AK4384_Open must have been called to obtain a valid opened device handle.
Example
// myAppObj is an application specific object.
MY_APP_OBJ myAppObj;
// myAK4384Handle is the handle returned
// by the DRV_AK4384_Open function.
DRV_AK4384_VolumeSet(myAK4384Handle, DRV_AK4384_CHANNEL_LEFT_RIGHT, 120); //Step 120 volume
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
chan Audio channel volume to be set
volume volume value from 0-255, which can attenuate from 0 dB to –48 dB and mute
Function
void DRV_AK4384_VolumeSet( DRV_HANDLE handle, DRV_AK4384_CHANNEL chan, uint8_t volume)
DRV_AK4384_ZeroDetectDisable Function
Disables AK4384 channel-independent zeros detect function.
Implementation: Dynamic
File
drv_ak4384.h
C
void DRV_AK4384_ZeroDetectDisable(DRV_HANDLE handle);
Returns
None.
Description
This function disables AK4384 channel-independent zeros detect function.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 134
Remarks
None.
Preconditions
The DRV_AK4384_Initialize routine must have been called for the specified AK4384 driver instance.
DRV_AK4384_Open must have been called to obtain a valid opened device handle.
Example
// myAppObj is an application specific object.
MY_APP_OBJ myAppObj;
// myAK4384Handle is the handle returned
// by the DRV_AK4384_Open function.
DRV_AK4384_ZeroDetectDisable(myAK4384Handle);
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
void DRV_AK4384_ZeroDetectDisable( DRV_HANDLE handle)
DRV_AK4384_ZeroDetectEnable Function
Enables AK4384 channel-independent zeros detect function.
Implementation: Dynamic
File
drv_ak4384.h
C
void DRV_AK4384_ZeroDetectEnable(DRV_HANDLE handle);
Returns
None.
Description
This function enables AK4384 channel-independent zeros detect function.
Remarks
None.
Preconditions
The DRV_AK4384_Initialize routine must have been called for the specified AK4384 driver instance.
DRV_AK4384_Open must have been called to obtain a valid opened device handle.
Example
// myAppObj is an application specific object.
MY_APP_OBJ myAppObj;
// myAK4384Handle is the handle returned
// by the DRV_AK4384_Open function.
DRV_AK4384_ZeroDetectEnable(myAK4384Handle);
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 135
Function
void DRV_AK4384_ZeroDetectEnable( DRV_HANDLE handle)
DRV_AK4384_ZeroDetectInvertDisable Function
Disables inversion of polarity for zero detect function.
Implementation: Dynamic
File
drv_ak4384.h
C
void DRV_AK4384_ZeroDetectInvertDisable(DRV_HANDLE handle);
Returns
None.
Description
This function disables inversion of polarity for zero detect function. DZF goes “H” at Zero Detection.
Remarks
None.
Preconditions
The DRV_AK4384_Initialize routine must have been called for the specified AK4384 driver instance.
DRV_AK4384_Open must have been called to obtain a valid opened device handle.
Example
// myAppObj is an application specific object.
MY_APP_OBJ myAppObj;
// myAK4384Handle is the handle returned
// by the DRV_AK4384_Open function.
DRV_AK4384_ZeroDetectInvertDisable(myAK4384Handle);
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
void DRV_AK4384_ZeroDetectInvertDisable( DRV_HANDLE handle)
DRV_AK4384_ZeroDetectInvertEnable Function
Enables inversion of polarity for zero detect function.
Implementation: Dynamic
File
drv_ak4384.h
C
void DRV_AK4384_ZeroDetectInvertEnable(DRV_HANDLE handle);
Returns
None.
Description
This function enables inversion of polarity for zero detect function. DZF goes “L” at Zero Detection
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 136
Remarks
None.
Preconditions
The DRV_AK4384_Initialize routine must have been called for the specified AK4384 driver instance.
DRV_AK4384_Open must have been called to obtain a valid opened device handle.
Example
// myAppObj is an application specific object.
MY_APP_OBJ myAppObj;
// myAK4384Handle is the handle returned
// by the DRV_AK4384_Open function.
DRV_AK4384_ZeroDetectInvertEnable(myAK4384Handle);
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
void DRV_AK4384_ZeroDetectInvertEnable( DRV_HANDLE handle)
DRV_AK4384_ZeroDetectModeSet Function
Sets mode of AK4384 channel-independent zeros detect function.
Implementation: Dynamic
File
drv_ak4384.h
C
void DRV_AK4384_ZeroDetectModeSet(DRV_HANDLE handle, DRV_AK4384_ZERO_DETECT_MODE zdMode);
Returns
None.
Description
This function sets mode of AK4384 channel-independent zeros detect function
Remarks
None.
Preconditions
The DRV_AK4384_Initialize routine must have been called for the specified AK4384 driver instance.
DRV_AK4384_Open must have been called to obtain a valid opened device handle.
Example
// myAppObj is an application specific object.
MY_APP_OBJ myAppObj;
// myAK4384Handle is the handle returned
// by the DRV_AK4384_Open function.
DRV_AK4384_ZeroDetectModeSet(myAK4384Handle, DRV_AK4384_ZERO_DETECT_MODE_ANDED);
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
zdMode Specifies zero detect function mode.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 137
Function
void DRV_AK4384_ZeroDetectModeSet
(
DRV_HANDLE handle,
DRV_AK4384_ZERO_DETECT_MODE zdMode
)
d) Data Transfer Functions
DRV_AK4384_BufferAddWrite Function
Schedule a non-blocking driver write operation.
Implementation: Dynamic
File
drv_ak4384.h
C
void DRV_AK4384_BufferAddWrite(const DRV_HANDLE handle, DRV_AK4384_BUFFER_HANDLE * bufferHandle, void *
buffer, size_t size);
Returns
The bufferHandle parameter will contain the return buffer handle. This will be DRV_AK4384_BUFFER_HANDLE_INVALID if the function was not
successful.
Description
This function schedules a non-blocking write operation. The function returns with a valid buffer handle in the bufferHandle argument if the write
request was scheduled successfully. The function adds the request to the hardware instance transmit queue and returns immediately. While the
request is in the queue, the application buffer is owned by the driver and should not be modified. The function returns
DRV_AK4384_BUFFER_HANDLE_INVALID if:
• a buffer could not be allocated to the request
• the input buffer pointer is NULL
• the buffer size is '0'
• the queue is full or the queue depth is insufficient
If the requesting client registered an event callback with the driver, the driver will issue a DRV_AK4384_BUFFER_EVENT_COMPLETE event if
the buffer was processed successfully of DRV_AK4384_BUFFER_EVENT_ERROR event if the buffer was not processed successfully.
Remarks
This function is thread safe in a RTOS application. It can be called from within the AK4384 Driver Buffer Event Handler that is registered by this
client. It should not be called in the event handler associated with another AK4384 driver instance. It should not otherwise be called directly in an
ISR.
Preconditions
The DRV_AK4384_Initialize routine must have been called for the specified AK4384 device instance and the DRV_AK4384_Status must have
returned SYS_STATUS_READY.
DRV_AK4384_Open must have been called to obtain a valid opened device handle.
DRV_IO_INTENT_WRITE must have been specified in the DRV_AK4384_Open call.
Example
MY_APP_OBJ myAppObj;
uint8_t mybuffer[MY_BUFFER_SIZE];
DRV_AK4384_BUFFER_HANDLE bufferHandle;
// myAK4384Handle is the handle returned
// by the DRV_AK4384_Open function.
// Client registers an event handler with driver
DRV_AK4384_BufferEventHandlerSet(myAK4384Handle,
APP_AK4384BufferEventHandler, (uintptr_t)&myAppObj);
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 138
DRV_AK4384_BufferAddWrite(myAK4384handle, &bufferHandle
myBuffer, MY_BUFFER_SIZE);
if(DRV_AK4384_BUFFER_HANDLE_INVALID == bufferHandle)
{
// Error handling here
}
// Event is received when
// the buffer is processed.
void APP_AK4384BufferEventHandler(DRV_AK4384_BUFFER_EVENT event,
DRV_AK4384_BUFFER_HANDLE bufferHandle, uintptr_t contextHandle)
{
// contextHandle points to myAppObj.
switch(event)
{
case DRV_AK4384_BUFFER_EVENT_COMPLETE:
// This means the data was transferred.
break;
case DRV_AK4384_BUFFER_EVENT_ERROR:
// Error handling here.
break;
default:
break;
}
}
Parameters
Parameters Description
handle Handle of the AK4384 instance as return by the DRV_AK4384_Open function.
buffer Data to be transmitted.
size Buffer size in bytes.
bufferHandle Pointer to an argument that will contain the return buffer handle.
Function
void DRV_AK4384_BufferAddWrite
(
const DRV_HANDLE handle,
DRV_AK4384_BUFFER_HANDLE *bufferHandle,
void *buffer, size_t size
)
DRV_AK4384_BufferEventHandlerSet Function
This function allows a client to identify a buffer event handling function for the driver to call back when queued buffer transfers have finished.
Implementation: Dynamic
File
drv_ak4384.h
C
void DRV_AK4384_BufferEventHandlerSet(DRV_HANDLE handle, const DRV_AK4384_BUFFER_EVENT_HANDLER
eventHandler, const uintptr_t contextHandle);
Returns
None.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 139
Description
This function allows a client to identify a buffer event handling function for the driver to call back when queued buffer transfers have finished. When
a client calls DRV_AK4384_BufferAddWrite function, it is provided with a handle identifying the buffer that was added to the driver's buffer queue.
The driver will pass this handle back to the client by calling "eventHandler" function when the buffer transfer has completed.
The event handler should be set before the client performs any "buffer add" operations that could generate events. The event handler once set,
persists until the client closes the driver or sets another event handler (which could be a "NULL" pointer to indicate no callback).
Remarks
If the client does not want to be notified when the queued buffer transfer has completed, it does not need to register a callback.
Preconditions
The DRV_AK4384_Initialize routine must have been called for the specified AK4384 driver instance.
DRV_AK4384_Open must have been called to obtain a valid opened device handle.
Example
MY_APP_OBJ myAppObj;
uint8_t mybuffer[MY_BUFFER_SIZE];
DRV_AK4384_BUFFER_HANDLE bufferHandle;
// myAK4384Handle is the handle returned
// by the DRV_AK4384_Open function.
// Client registers an event handler with driver
DRV_AK4384_BufferEventHandlerSet(myAK4384Handle,
APP_AK4384BufferEventHandler, (uintptr_t)&myAppObj);
DRV_AK4384_BufferAddWrite(myAK4384handle, &bufferHandle
myBuffer, MY_BUFFER_SIZE);
if(DRV_AK4384_BUFFER_HANDLE_INVALID == bufferHandle)
{
// Error handling here
}
// Event is received when
// the buffer is processed.
void APP_AK4384BufferEventHandler(DRV_AK4384_BUFFER_EVENT event,
DRV_AK4384_BUFFER_HANDLE bufferHandle, uintptr_t contextHandle)
{
// contextHandle points to myAppObj.
switch(event)
{
case DRV_AK4384_BUFFER_EVENT_COMPLETE:
// This means the data was transferred.
break;
case DRV_AK4384_BUFFER_EVENT_ERROR:
// Error handling here.
break;
default:
break;
}
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
eventHandler Pointer to the event handler function.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 140
context The value of parameter will be passed back to the client unchanged, when the eventHandler
function is called. It can be used to identify any client specific data object that identifies the
instance of the client module (for example, it may be a pointer to the client module's state
structure).
Function
void DRV_AK4384_BufferEventHandlerSet
(
DRV_HANDLE handle,
const DRV_AK4384_BUFFER_EVENT_HANDLER eventHandler,
const uintptr_t contextHandle
)
DRV_AK4384_BufferCombinedQueueSizeGet Function
This function returns the number of bytes queued (to be processed) in the buffer queue.
Implementation: Dynamic
File
drv_ak4384.h
C
size_t DRV_AK4384_BufferCombinedQueueSizeGet(DRV_HANDLE handle);
Returns
Returns the number of the bytes that have been processed for this buffer. Returns 0 for an invalid or an expired client handle.
Description
This function returns the number of bytes queued (to be processed) in the buffer queue associated with the driver instance to which the calling
client belongs. The client can use this function to know number of bytes that is in the queue to be transmitted.
Remarks
None.
Preconditions
The DRV_AK4384_Initialize routine must have been called for the specified AK4384 driver instance.
DRV_AK4384_Open must have been called to obtain a valid opened device handle.
One of DRV_AK4384_BufferAddRead/DRV_AK4384_BufferAddWrite function must have been called and buffers should have been queued for
transmission.
Example
// myAppObj is an application specific object.
MY_APP_OBJ myAppObj;
size_t bufferQueuedSize;
uint8_t mybuffer[MY_BUFFER_SIZE];
DRV_AK4384_BUFFER_HANDLE bufferHandle;
// myI2SHandle is the handle returned
// by the DRV_AK4384_Open function.
// Client registers an event handler with driver. This is done once
DRV_AK4384_BufferEventHandlerSet(myAK4384Handle, APP_AK4384BufferEventHandle,
(uintptr_t)&myAppObj);
DRV_AK4384_BufferAddRead(myAK4384handle,&bufferHandle,
myBuffer, MY_BUFFER_SIZE);
if(DRV_AK4384_BUFFER_HANDLE_INVALID == bufferHandle)
{
// Error handling here
}
// The data is being processed after adding the buffer to the queue.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 141
// The user can get to know dynamically available data in the queue to be
// transmitted by calling DRV_AK4384_BufferCombinedQueueSizeGet
bufferQueuedSize = DRV_AK4384_BufferCombinedQueueSizeGet(myAK4384Handle);
Parameters
Parameters Description
handle Opened client handle associated with a driver object.
Function
size_t DRV_AK4384_BufferCombinedQueueSizeGet( DRV_HANDLE handle)
DRV_AK4384_BufferQueueFlush Function
This function flushes off the buffers associated with the client object.
Implementation: Dynamic
File
drv_ak4384.h
C
void DRV_AK4384_BufferQueueFlush(const DRV_HANDLE handle);
Returns
None.
Description
This function flushes off the buffers associated with the client object and disables the DMA channel used for transmission.
Remarks
None.
Preconditions
The DRV_AK4384_Initialize routine must have been called for the specified AK4384 driver instance.
DRV_AK4384_Open must have been called to obtain a valid opened device handle.
One of DRV_AK4384_BufferAddRead/DRV_AK4384_BufferAddWrite function must have been called and buffers should have been queued for
transmission.
Example
// myAppObj is an application specific object.
MY_APP_OBJ myAppObj;
size_t bufferQueuedSize;
uint8_t mybuffer[MY_BUFFER_SIZE];
DRV_AK4384_BUFFER_HANDLE bufferHandle;
// myAK4384Handle is the handle returned
// by the DRV_AK4384_Open function.
// Client registers an event handler with driver. This is done once
DRV_AK4384_BufferEventHandlerSet(myAK4384Handle, APP_AK4384BufferEventHandle,
(uintptr_t)&myAppObj);
DRV_AK4384_BufferAddRead(myAK4384handle,&bufferHandle,
myBuffer, MY_BUFFER_SIZE);
if(DRV_AK4384_BUFFER_HANDLE_INVALID == bufferHandle)
{
// Error handling here
}
// The data is being processed after adding the buffer to the queue.
// The user can stop the data processing and flushoff the data
// in the queue by calling DRV_AK4384_BufferQueueFlush
DRV_AK4384_BufferQueueFlush(myAK4384Handle);
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 142
Parameters
Parameters Description
handle Opened client handle associated with a driver object.
Function
void DRV_AK4384_BufferQueueFlush( DRV_HANDLE handle)
DRV_AK4384_BufferProcessedSizeGet Function
This function returns number of bytes that have been processed for the specified buffer.
Implementation: Dynamic
File
drv_ak4384.h
C
size_t DRV_AK4384_BufferProcessedSizeGet(DRV_HANDLE handle);
Returns
Returns the number of the bytes that have been processed for this buffer. Returns 0 for an invalid or an expired buffer handle.
Description
This function returns number of bytes that have been processed for the specified buffer. The client can use this function, in a case where the buffer
has terminated due to an error, to obtain the number of bytes that have been processed. If this function is called on a invalid buffer handle, or if the
buffer handle has expired, the function returns 0.
Remarks
None.
Preconditions
The DRV_AK4384_Initialize routine must have been called for the specified I2S driver instance.
DRV_AK4384_Open must have been called to obtain a valid opened device handle.
One of DRV_AK4384_BufferAddRead, DRV_AK4384_BufferAddWrite function must have been called and a valid buffer handle returned.
Example
// myAppObj is an application specific object.
MY_APP_OBJ myAppObj;
uint8_t mybuffer[MY_BUFFER_SIZE];
DRV_AK4384_BUFFER_HANDLE bufferHandle;
// myAK4384Handle is the handle returned
// by the DRV_AK4384_Open function.
// Client registers an event handler with driver. This is done once
DRV_AK4384_BufferEventHandlerSet(myAK4384Handle, APP_AK4384BufferEventHandle,
(uintptr_t)&myAppObj);
DRV_AK4384_BufferAddRead(myAK4384handle,&bufferHandle,
myBuffer, MY_BUFFER_SIZE);
if(DRV_AK4384_BUFFER_HANDLE_INVALID == bufferHandle)
{
// Error handling here
}
// Event Processing Technique. Event is received when
// the buffer is processed.
void APP_AK4384BufferEventHandler(DRV_AK4384_BUFFER_EVENT event,
DRV_AK4384_BUFFER_HANDLE bufferHandle, uintptr_t contextHandle)
{
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 143
// The context handle was set to an application specific
// object. It is now retrievable easily in the event handler.
MY_APP_OBJ myAppObj = (MY_APP_OBJ *) contextHandle;
size_t processedBytes;
switch(event)
{
case DRV_AK4384_BUFFER_EVENT_COMPLETE:
// This means the data was transferred.
break;
case DRV_AK4384_BUFFER_EVENT_ERROR:
// Error handling here.
// We can find out how many bytes were processed in this
// buffer before the error occurred.
processedBytes = DRV_AK4384_BufferProcessedSizeGet(myAK4384Handle);
break;
default:
break;
}
}
Parameters
Parameters Description
bufferhandle Handle of the buffer of which the processed number of bytes to be obtained.
Function
size_t DRV_AK4384_BufferProcessedSizeGet( DRV_HANDLE handle)
e) Other Functions
DRV_AK4384_CommandEventHandlerSet Function
This function allows a client to identify a command event handling function for the driver to call back when the last submitted command have
finished.
Implementation: Dynamic
File
drv_ak4384.h
C
void DRV_AK4384_CommandEventHandlerSet(DRV_HANDLE handle, const DRV_AK4384_COMMAND_EVENT_HANDLER
eventHandler, const uintptr_t contextHandle);
Returns
None.
Description
This function allows a client to identify a command event handling function for the driver to call back when the last submitted command have
finished.
When a client calls DRV_AK4384_BufferAddWrite function, it is provided with a handle identifying the buffer that was added to the driver's buffer
queue. The driver will pass this handle back to the client by calling "eventHandler" function when the buffer transfer has completed.
The event handler should be set before the client performs any "AK4384 CODEC Specific Client Routines" operations that could generate events.
The event handler once set, persists until the client closes the driver or sets another event handler (which could be a "NULL" pointer to indicate no
callback).
Remarks
If the client does not want to be notified when the command has completed, it does not need to register a callback.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 144
Preconditions
The DRV_AK4384_Initialize routine must have been called for the specified AK4384 driver instance.
DRV_AK4384_Open must have been called to obtain a valid opened device handle.
Example
MY_APP_OBJ myAppObj;
// myAK4384Handle is the handle returned
// by the DRV_AK4384_Open function.
// Client registers an event handler with driver
DRV_AK4384_CommandEventHandlerSet(myAK4384Handle,
APP_AK4384CommandEventHandler, (uintptr_t)&myAppObj);
DRV_AK4384_DeEmphasisFilterSet(myAK4384Handle, DRV_AK4384_DEEMPHASIS_FILTER_44_1KHZ)
// Event is received when
// the buffer is processed.
void APP_AK4384CommandEventHandler(uintptr_t contextHandle)
{
// contextHandle points to myAppObj.
switch(event)
{
// Last Submitted command is completed.
// Perform further processing here
}
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
eventHandler Pointer to the event handler function.
context The value of parameter will be passed back to the client unchanged, when the eventHandler
function is called. It can be used to identify any client specific data object that identifies the
instance of the client module (for example, it may be a pointer to the client module's state
structure).
Function
void DRV_AK4384_CommandEventHandlerSet
(
DRV_HANDLE handle,
const DRV_AK4384_COMMAND_EVENT_HANDLER eventHandler,
const uintptr_t contextHandle
)
DRV_AK4384_VersionGet Function
Returns the version of the AK4384 driver.
Implementation: Dynamic
File
drv_ak4384.h
C
uint32_t DRV_AK4384_VersionGet();
Returns
Returns the version of AK4384 driver.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 145
Description
The version number returned from the DRV_AK4384_VersionGet function is an unsigned integer in the following decimal format. * 10000 + * 100
+ Where the numbers are represented in decimal and the meaning is the same as above. Note that there is no numerical representation of
release type.
Remarks
None.
Example 1
For version "0.03a", return: 0 * 10000 + 3 * 100 + 0 For version "1.00", return: 1 * 100000 + 0 * 100 + 0
Example 2
uint32_t ak4384version;
ak4384version = DRV_AK4384_VersionGet();
Function
uint32_t DRV_AK4384_VersionGet( void )
DRV_AK4384_VersionStrGet Function
Returns the version of AK4384 driver in string format.
Implementation: Dynamic
File
drv_ak4384.h
C
int8_t* DRV_AK4384_VersionStrGet();
Returns
returns a string containing the version of AK4384 driver.
Description
The DRV_AK4384_VersionStrGet function returns a string in the format: ".[.][]" Where: is the AK4384 driver's version number. is the AK4384
driver's version number. is an optional "patch" or "dot" release number (which is not included in the string if it equals '00'). is an optional release
type ('a' for alpha, 'b' for beta not the entire word spelled out) that is not included if the release is a production version (i.e., not an alpha or beta).
The String does not contain any spaces.
Remarks
None.
Preconditions
None.
Example 1
"0.03a" "1.00"
Example 2
int8_t *ak4384string;
ak4384string = DRV_AK4384_VersionStrGet();
Function
int8_t* DRV_AK4384_VersionStrGet(void)
f) Data Types and Constants
DRV_AK4384_AUDIO_DATA_FORMAT Enumeration
Identifies the Serial Audio data interface format.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 146
File
drv_ak4384.h
C
typedef enum {
DRV_AK4384_AUDIO_DATA_FORMAT_16BIT_RIGHT_JUSTIFIED = 0,
DRV_AK4384_AUDIO_DATA_FORMAT_20BIT_RIGHT_JUSTIFIED,
DRV_AK4384_AUDIO_DATA_FORMAT_24BIT_LEFT_JUSTIFIED,
DRV_AK4384_AUDIO_DATA_FORMAT_24BIT_I2S,
DRV_AK4384_AUDIO_DATA_FORMAT_24BIT_RIGHT_JUSTIFIED
} DRV_AK4384_AUDIO_DATA_FORMAT;
Members
Members Description
DRV_AK4384_AUDIO_DATA_FORMAT_16BIT_RIGHT_JUSTIFIED
= 0
16 bit Right Justified Audio data format
DRV_AK4384_AUDIO_DATA_FORMAT_20BIT_RIGHT_JUSTIFIED 20 bit Right Justified Audio data format
DRV_AK4384_AUDIO_DATA_FORMAT_24BIT_LEFT_JUSTIFIED 24 bit Left Justified Audio data format
DRV_AK4384_AUDIO_DATA_FORMAT_24BIT_I2S 24 bit I2S Audio data format
DRV_AK4384_AUDIO_DATA_FORMAT_24BIT_RIGHT_JUSTIFIED 24 bit Right Justified Audio data format
Description
AK4384 Audio data format
This enumeration identifies Serial Audio data interface format.
Remarks
None.
DRV_AK4384_BUFFER_EVENT Enumeration
Identifies the possible events that can result from a buffer add request.
File
drv_ak4384.h
C
typedef enum {
DRV_AK4384_BUFFER_EVENT_COMPLETE,
DRV_AK4384_BUFFER_EVENT_ERROR,
DRV_AK4384_BUFFER_EVENT_ABORT
} DRV_AK4384_BUFFER_EVENT;
Members
Members Description
DRV_AK4384_BUFFER_EVENT_COMPLETE Data was transferred successfully.
DRV_AK4384_BUFFER_EVENT_ERROR Error while processing the request
DRV_AK4384_BUFFER_EVENT_ABORT Data transfer aborted (Applicable in DMA mode)
Description
AK4384 Driver Events
This enumeration identifies the possible events that can result from a buffer add request caused by the client calling either the
DRV_AK4384_BufferAddWrite function.
Remarks
One of these values is passed in the "event" parameter of the event handling callback function that the client registered with the driver by calling
the DRV_AK4384_BufferEventHandlerSet function when a buffer transfer request is completed.
DRV_AK4384_BUFFER_EVENT_HANDLER Type
Pointer to a AK4384 Driver Buffer Event handler function.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 147
File
drv_ak4384.h
C
typedef void (* DRV_AK4384_BUFFER_EVENT_HANDLER)(DRV_AK4384_BUFFER_EVENT event, DRV_AK4384_BUFFER_HANDLE
bufferHandle, uintptr_t contextHandle);
Returns
None.
Description
AK4384 Driver Buffer Event Handler Function
This data type defines the required function signature for the AK4384 driver buffer event handling callback function. A client must register a pointer
to a buffer event handling function whose function signature (parameter and return value types) match the types specified by this function pointer
in order to receive buffer related event calls back from the driver.
The parameters and return values are described here and a partial example implementation is provided.
Remarks
If the event is DRV_AK4384_BUFFER_EVENT_COMPLETE, this means that the data was transferred successfully.
If the event is DRV_AK4384_BUFFER_EVENT_ERROR, this means that the data was not transferred successfully. The bufferHandle parameter
contains the buffer handle of the buffer that failed. The DRV_AK4384_BufferProcessedSizeGet function can be called to find out how many bytes
were processed.
The bufferHandle parameter contains the buffer handle of the buffer that associated with the event.
The context parameter contains a handle to the client context, provided at the time the event handling function was registered using the
DRV_AK4384_BufferEventHandlerSet function. This context handle value is passed back to the client as the "context" parameter. It can be any
value necessary to identify the client context or instance (such as a pointer to the client's data) instance of the client that made the buffer add
request.
The buffer handle in bufferHandle expires after this event handler exits. In that the buffer object that was allocated is deallocated by the driver after
the event handler exits.
The event handler function executes in the data driver (I2S) peripheral's interrupt context when the driver is configured for interrupt mode
operation. It is recommended of the application to not perform process intensive or blocking operations with in this function.
DRV_AK4384_BufferAddWrite function can be called in the event handler to add a buffer to the driver queue.
Example
void APP_MyBufferEventHandler( DRV_AK4384_BUFFER_EVENT event,
DRV_AK4384_BUFFER_HANDLE bufferHandle,
uintptr_t context )
{
MY_APP_DATA_STRUCT pAppData = (MY_APP_DATA_STRUCT) context;
switch(event)
{
case DRV_AK4384_BUFFER_EVENT_COMPLETE:
// Handle the completed buffer.
break;
case DRV_AK4384_BUFFER_EVENT_ERROR:
default:
// Handle error.
break;
}
}
Parameters
Parameters Description
event Identifies the type of event
bufferHandle Handle identifying the buffer to which the event relates
context Value identifying the context of the application that registered the event handling function.
DRV_AK4384_BUFFER_HANDLE Type
Handle identifying a write buffer passed to the driver.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 148
File
drv_ak4384.h
C
typedef uintptr_t DRV_AK4384_BUFFER_HANDLE;
Description
AK4384 Driver Buffer Handle
A buffer handle value is returned by a call to the DRV_AK4384_BufferAddWrite function. This handle is associated with the buffer passed into the
function and it allows the application to track the completion of the data from (or into) that buffer. The buffer handle value returned from the "buffer
add" function is returned back to the client by the "event handler callback" function registered with the driver.
The buffer handle assigned to a client request expires when the client has been notified of the completion of the buffer transfer (after event handler
function that notifies the client returns) or after the buffer has been retired by the driver if no event handler callback was set.
Remarks
None.
DRV_AK4384_CHANNEL Enumeration
Identifies Left/Right Audio channel
File
drv_ak4384.h
C
typedef enum {
DRV_AK4384_CHANNEL_LEFT,
DRV_AK4384_CHANNEL_RIGHT,
DRV_AK4384_CHANNEL_LEFT_RIGHT,
DRV_AK4384_NUMBER_OF_CHANNELS
} DRV_AK4384_CHANNEL;
Description
AK4384 Audio Channel
This enumeration identifies Left/Right Audio channel
Remarks
None.
DRV_AK4384_COMMAND_EVENT_HANDLER Type
Pointer to a AK4384 Driver Command Event Handler Function
File
drv_ak4384.h
C
typedef void (* DRV_AK4384_COMMAND_EVENT_HANDLER)(uintptr_t contextHandle);
Returns
None.
Description
AK4384 Driver Command Event Handler Function
This data type defines the required function signature for the AK4384 driver command event handling callback function.
A command is a control instruction to the AK4384 Codec. For example, Mute ON/OFF, Zero Detect Enable/Disable, etc.
A client must register a pointer to a command event handling function whose function signature (parameter and return value types) match the
types specified by this function pointer in order to receive command related event calls back from the driver.
The parameters and return values are described here and a partial example implementation is provided.
Remarks
The occurrence of this call back means that the last control command was transferred successfully.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 149
The context parameter contains a handle to the client context, provided at the time the event handling function was registered using the
DRV_AK4384_CommandEventHandlerSet function. This context handle value is passed back to the client as the "context" parameter. It can be
any value necessary to identify the client context or instance (such as a pointer to the client's data) of the client that made the buffer add request.
The event handler function executes in the control data driver interrupt context. It is recommended of the application to not perform process
intensive or blocking operations with in this function.
Example
void APP_AK4384CommandEventHandler( uintptr_t context )
{
MY_APP_DATA_STRUCT pAppData = (MY_APP_DATA_STRUCT) context;
// Last Submitted command is completed.
// Perform further processing here
}
Parameters
Parameters Description
context Value identifying the context of the application that registered the event handling function.
DRV_AK4384_DEEMPHASIS_FILTER Enumeration
Identifies de-emphasis filter function.
File
drv_ak4384.h
C
typedef enum {
DRV_AK4384_DEEMPHASIS_FILTER_44_1KHZ,
DRV_AK4384_DEEMPHASIS_FILTER_OFF,
DRV_AK4384_DEEMPHASIS_FILTER_48KHZ,
DRV_AK4384_DEEMPHASIS_FILTER_32KHZ
} DRV_AK4384_DEEMPHASIS_FILTER;
Members
Members Description
DRV_AK4384_DEEMPHASIS_FILTER_44_1KHZ De-Emphasis filter for 44.1kHz.
DRV_AK4384_DEEMPHASIS_FILTER_OFF De-Emphasis filter Off This is the default setting.
DRV_AK4384_DEEMPHASIS_FILTER_48KHZ De-Emphasis filter for 48kHz.
DRV_AK4384_DEEMPHASIS_FILTER_32KHZ De-Emphasis filter for 32kHz.
Description
AK4384 De-Emphasis Filter
This enumeration identifies the settings for de-emphasis filter function.
Remarks
None.
DRV_AK4384_INIT Structure
Defines the data required to initialize or reinitialize the AK4384 driver.
File
drv_ak4384.h
C
typedef struct {
SYS_MODULE_INIT moduleInit;
SYS_MODULE_INDEX spiDriverModuleIndex;
SYS_MODULE_INDEX i2sDriverModuleIndex;
uint8_t volume;
DRV_AK4384_MCLK_MODE mclkMode;
bool delayDriverInitialization;
} DRV_AK4384_INIT;
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 150
Members
Members Description
SYS_MODULE_INIT moduleInit; System module initialization
SYS_MODULE_INDEX spiDriverModuleIndex; Identifies control module(SPI) driver ID for control interface of Codec
SYS_MODULE_INDEX i2sDriverModuleIndex; Identifies data module(I2S) driver ID for data interface of Codec
uint8_t volume; Volume
DRV_AK4384_MCLK_MODE mclkMode; Set MCLK mode.
bool delayDriverInitialization; true if driver initialization should be delayed due to shared RESET pin
Description
AK4384 Driver Initialization Data
This data type defines the data required to initialize or reinitialize the AK4384 Codec driver.
Remarks
None.
DRV_AK4384_MCLK_MODE Enumeration
Identifies the mode of master clock to AK4384 DAC.
File
drv_ak4384.h
C
typedef enum {
DRV_AK4384_MCLK_MODE_MANUAL,
DRV_AK4384_MCLK_MODE_AUTO
} DRV_AK4384_MCLK_MODE;
Members
Members Description
DRV_AK4384_MCLK_MODE_MANUAL Master clock frequency mode Manual
DRV_AK4384_MCLK_MODE_AUTO Master clock frequency mode Auto This is the default mode.
Description
AK4384 Master clock frequency mode
This enumeration identifies mode of master clock to AK4384 DAC. In Manual Setting Mode, the sampling speed is set by setting DFS0/1 bits in
Control Register 2. The frequency of MCLK at each sampling speed is set automatically. In Auto Setting Mode, the MCLK frequency is detected
automatically
Remarks
None.
DRV_AK4384_ZERO_DETECT_MODE Enumeration
Identifies Zero Detect Function mode
File
drv_ak4384.h
C
typedef enum {
DRV_AK4384_ZERO_DETECT_MODE_CHANNEL_SEPARATED,
DRV_AK4384_ZERO_DETECT_MODE_ANDED
} DRV_AK4384_ZERO_DETECT_MODE;
Members
Members Description
DRV_AK4384_ZERO_DETECT_MODE_CHANNEL_SEPARATED Zero Detect channel separated. When the input data at each channel is
continuously zeros for 8192 LRCK cycles, DZF pin of each channel goes to
“H” This is the default mode.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 151
DRV_AK4384_ZERO_DETECT_MODE_ANDED Zero Detect Anded DZF pins of both channels go to “H” only when the input
data at both channels are continuously zeros for 8192 LRCK cycles
Description
AK4384 Zero Detect mode
This enumeration identifies the mode of zero detect function
Remarks
None.
DRV_AK4384_BUFFER_HANDLE_INVALID Macro
Definition of an invalid buffer handle.
File
drv_ak4384.h
C
#define DRV_AK4384_BUFFER_HANDLE_INVALID ((DRV_AK4384_BUFFER_HANDLE)(-1))
Description
AK4384 Driver Invalid Buffer Handle
This is the definition of an invalid buffer handle. An invalid buffer handle is returned by DRV_AK4384_BufferAddWrite function if the buffer add
request was not successful.
Remarks
None.
DRV_AK4384_COUNT Macro
Number of valid AK4384 driver indices.
File
drv_ak4384.h
C
#define DRV_AK4384_COUNT
Description
AK4384 Driver Module Count
This constant identifies the maximum number of AK4384 Driver instances that should be defined by the application. Defining more instances than
this constant will waste RAM memory space.
This constant can also be used by the application to identify the number of AK4384 instances on this microcontroller.
Remarks
This value is device-specific.
DRV_AK4384_INDEX_0 Macro
AK4384 driver index definitions.
File
drv_ak4384.h
C
#define DRV_AK4384_INDEX_0 0
Description
Driver AK4384 Module Index
These constants provide AK4384 driver index definition.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 152
Remarks
These constants should be used in place of hard-coded numeric literals. These values should be passed into the DRV_AK4384_Initialize and
DRV_AK4384_Open routines to identify the driver instance in use.
DRV_AK4384_INDEX_1 Macro
File
drv_ak4384.h
C
#define DRV_AK4384_INDEX_1 1
Description
This is macro DRV_AK4384_INDEX_1.
DRV_AK4384_INDEX_2 Macro
File
drv_ak4384.h
C
#define DRV_AK4384_INDEX_2 2
Description
This is macro DRV_AK4384_INDEX_2.
DRV_AK4384_INDEX_3 Macro
File
drv_ak4384.h
C
#define DRV_AK4384_INDEX_3 3
Description
This is macro DRV_AK4384_INDEX_3.
DRV_AK4384_INDEX_4 Macro
File
drv_ak4384.h
C
#define DRV_AK4384_INDEX_4 4
Description
This is macro DRV_AK4384_INDEX_4.
DRV_AK4384_INDEX_5 Macro
File
drv_ak4384.h
C
#define DRV_AK4384_INDEX_5 5
Description
This is macro DRV_AK4384_INDEX_5.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 153
Files
Files
Name Description
drv_ak4384.h AK4384 Codec Driver Interface header file
drv_ak4384_config_template.h AK4384 Codec Driver Configuration Template.
Description
This section lists the source and header files used by the AK4384Codec Driver Library.
drv_ak4384.h
AK4384 Codec Driver Interface header file
Enumerations
Name Description
DRV_AK4384_AUDIO_DATA_FORMAT Identifies the Serial Audio data interface format.
DRV_AK4384_BUFFER_EVENT Identifies the possible events that can result from a buffer add request.
DRV_AK4384_CHANNEL Identifies Left/Right Audio channel
DRV_AK4384_DEEMPHASIS_FILTER Identifies de-emphasis filter function.
DRV_AK4384_MCLK_MODE Identifies the mode of master clock to AK4384 DAC.
DRV_AK4384_ZERO_DETECT_MODE Identifies Zero Detect Function mode
Functions
Name Description
DRV_AK4384_BufferAddWrite Schedule a non-blocking driver write operation.
Implementation: Dynamic
DRV_AK4384_BufferCombinedQueueSizeGet This function returns the number of bytes queued (to be processed) in the buffer
queue.
Implementation: Dynamic
DRV_AK4384_BufferEventHandlerSet This function allows a client to identify a buffer event handling function for the driver
to call back when queued buffer transfers have finished.
Implementation: Dynamic
DRV_AK4384_BufferProcessedSizeGet This function returns number of bytes that have been processed for the specified
buffer.
Implementation: Dynamic
DRV_AK4384_BufferQueueFlush This function flushes off the buffers associated with the client object.
Implementation: Dynamic
DRV_AK4384_ChannelOutputInvertDisable Disables output polarity of the selected Channel.
Implementation: Dynamic
DRV_AK4384_ChannelOutputInvertEnable Enables output polarity of the selected channel.
Implementation: Dynamic
DRV_AK4384_Close Closes an opened-instance of the AK4384 driver.
Implementation: Dynamic
DRV_AK4384_CommandEventHandlerSet This function allows a client to identify a command event handling function for the
driver to call back when the last submitted command have finished.
Implementation: Dynamic
DRV_AK4384_DeEmphasisFilterSet Allows specifies enabling of digital de-emphasis filter.
Implementation: Dynamic
DRV_AK4384_Deinitialize Deinitializes the specified instance of the AK4384 driver module.
Implementation: Dynamic
DRV_AK4384_Initialize Initializes hardware and data for the instance of the AK4384 DAC module.
Implementation: Dynamic
DRV_AK4384_MuteOff Disables AK4384 output for soft mute.
Implementation: Dynamic
DRV_AK4384_MuteOn Allows AK4384 output for soft mute on.
Implementation: Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 154
DRV_AK4384_Open Opens the specified AK4384 driver instance and returns a handle to it.
Implementation: Dynamic
DRV_AK4384_SamplingRateGet This function gets the sampling rate set on the DAC AK4384.
Implementation: Dynamic
DRV_AK4384_SamplingRateSet This function sets the sampling rate of the media stream.
Implementation: Dynamic
DRV_AK4384_SetAudioCommunicationMode This function provides a run time audio format configuration
DRV_AK4384_SlowRollOffFilterDisable Disables Slow Roll-off filter function.
Implementation: Dynamic
DRV_AK4384_SlowRollOffFilterEnable Enables Slow Roll-off filter function.
Implementation: Dynamic
DRV_AK4384_Status Gets the current status of the AK4384 driver module.
Implementation: Dynamic
DRV_AK4384_Tasks Maintains the driver's control and data interface state machine.
Implementation: Dynamic
DRV_AK4384_VersionGet Returns the version of the AK4384 driver.
Implementation: Dynamic
DRV_AK4384_VersionStrGet Returns the version of AK4384 driver in string format.
Implementation: Dynamic
DRV_AK4384_VolumeGet This function gets the volume for AK4384 Codec.
Implementation: Dynamic
DRV_AK4384_VolumeSet This function sets the volume for AK4384 Codec.
Implementation: Dynamic
DRV_AK4384_ZeroDetectDisable Disables AK4384 channel-independent zeros detect function.
Implementation: Dynamic
DRV_AK4384_ZeroDetectEnable Enables AK4384 channel-independent zeros detect function.
Implementation: Dynamic
DRV_AK4384_ZeroDetectInvertDisable Disables inversion of polarity for zero detect function.
Implementation: Dynamic
DRV_AK4384_ZeroDetectInvertEnable Enables inversion of polarity for zero detect function.
Implementation: Dynamic
DRV_AK4384_ZeroDetectModeSet Sets mode of AK4384 channel-independent zeros detect function.
Implementation: Dynamic
Macros
Name Description
DRV_AK4384_BUFFER_HANDLE_INVALID Definition of an invalid buffer handle.
DRV_AK4384_COUNT Number of valid AK4384 driver indices.
DRV_AK4384_INDEX_0 AK4384 driver index definitions.
DRV_AK4384_INDEX_1 This is macro DRV_AK4384_INDEX_1.
DRV_AK4384_INDEX_2 This is macro DRV_AK4384_INDEX_2.
DRV_AK4384_INDEX_3 This is macro DRV_AK4384_INDEX_3.
DRV_AK4384_INDEX_4 This is macro DRV_AK4384_INDEX_4.
DRV_AK4384_INDEX_5 This is macro DRV_AK4384_INDEX_5.
Structures
Name Description
DRV_AK4384_INIT Defines the data required to initialize or reinitialize the AK4384 driver.
Types
Name Description
DRV_AK4384_BUFFER_EVENT_HANDLER Pointer to a AK4384 Driver Buffer Event handler function.
DRV_AK4384_BUFFER_HANDLE Handle identifying a write buffer passed to the driver.
DRV_AK4384_COMMAND_EVENT_HANDLER Pointer to a AK4384 Driver Command Event Handler Function
Description
AK4384 Codec Driver Interface
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 155
The AK4384 Codec device driver interface provides a simple interface to manage the AK4384 106 dB 192 kHz 24-Bit DAC that can be interfaced
Microchip Microcontroller. This file provides the interface definition for the AK4384 Codec device driver.
File Name
drv_ak4384.h
Company
Microchip Technology Inc.
drv_ak4384_config_template.h
AK4384 Codec Driver Configuration Template.
Macros
Name Description
DRV_AK4384_BCLK_BIT_CLK_DIVISOR Sets up the BCLK to LRCK Ratio to Generate Audio Stream for 32, 44.1,
and 48K sampling frequency
DRV_AK4384_CLIENTS_NUMBER Sets up the maximum number of clients that can be connected to any
hardware instance.
DRV_AK4384_CONTROL_CLOCK Sets up clock frequency for the control interface (SPI)
DRV_AK4384_INPUT_REFCLOCK Identifies the input REFCLOCK source to generate the MCLK to codec.
DRV_AK4384_INSTANCES_NUMBER Sets up the maximum number of hardware instances that can be supported
DRV_AK4384_MCLK_SAMPLE_FREQ_MULTPLIER Sets up the MCLK to LRCK Ratio to Generate Audio Stream for 32, 44.1
and 48K sampling frequency
DRV_AK4384_TIMER_DRIVER_MODULE_INDEX Identifies the Timer Module Index for custom virtual SPI driver
implementation.
DRV_AK4384_TIMER_PERIOD Identifies the period for the bit bang timer.
Description
AK4384 Codec Driver Configuration Template
These file provides the list of all the configurations that can be used with the driver. This file should not be included in the driver.
File Name
drv_ak4384_config_template.h
Company
Microchip Technology Inc.
AK4642 Codec Driver Library
This topic describes the AK4642 Codec Driver Library.
Introduction
This library provides an interface to manage the AK4642 Codec that is serially interfaced to a Microchip microcontroller for providing Audio
Solutions.
Description
The AK4642 module is 16/24-bit Audio Codec from Asahi Kasei Microdevices Corporation. The AK4642 can be interfaced to Microchip
microcontrollers through I2C and I2S serial interfaces. The I2C interface is used for control command transfer. The I2S interface is used for Audio
data output.
A typical interface of AK4642 to a Microchip PIC32 device is provided in the following diagram:
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 156
Features
The AK4642 Codec Driver supports the following features:
• Audio Interface Format: MSB first
• ADC: 16-bit MSB justified, 16/24-bit I2S
• DAC: 16-bit MSB justified, 16bit LSB justified, 16/24-bit I2S
• Sampling Frequency Range: 8 kHz to 48 kHz
• Digital Volume Control: +12dB ~ .115dB, 0.5dB Step
• SoftMute: On and Off
• Master Clock Frequencies: 32 fs/64 fs/128fs/256fs
Using the Library
This topic describes the basic architecture of the AK4642 Codec Driver Library and provides information and examples on its use.
Description
Interface Header File: drv_ak4642.h
The interface to the AK4642 Codec Driver library is defined in the drv_ak4642.h header file. Any C language source (.c) file that uses the
AK4642 Codec Driver library should include this header.
Please refer to the What is MPLAB Harmony? section for how the driver interacts with the framework.
Abstraction Model
This library provides a low-level abstraction of the AK4642 Codec Driver Library on the Microchip family microcontrollers with a convenient C
language interface. This topic describes how that abstraction is modeled in software and introduces the library's interface.
Description
The abstraction model shown in the following diagram depicts how the AK4642 Codec Driver is positioned in the MPLAB Harmony framework. The
AK4642 Codec Driver uses the SPI and I2S drivers for control and audio data transfers to the AK4642 module.
AK4642 Driver Abstraction Model
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 157
Library Overview
Refer to the Driver Library Overview section for information on how the driver operates in a system.
The AK4642 Codec Driver Library provides an API interface to transfer control commands and digital audio data to the serially interfaced AK4642
DAC module. The library interface routines are divided into various sub-sections, which address one of the blocks or the overall operation of the
AK4642 Codec Driver Library.
Library Interface Section Description
System Functions Provides system module interfaces, device initialization, deinitialization,
reinitialization, tasks and status functions.
Client Setup Functions Provides open and close functions.
Codec Specific Functions Provides functions that are codec specific.
Data Transfer Functions Provides data transfer functions.
Other Functions Provides driver specific miscellaneous functions such as sampling rate setting, control
command functions, etc.
Data Types and Constants These data types and constants are required while interacting and setting up the
AK4642 Codec Driver Library.
How the Library Works
The library provides interfaces to support:
• System Functionality
• Client Functionality
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 158
System Access
This topic provides information on system initialization, implementations, and provides a system access code example.
Description
System Initialization
The system performs the initialization of the device driver with settings that affect only the instance of the device that is being initialized. During
system initialization, each instance of the AK4642 module would be initialized with the following configuration settings (either passed dynamically
at run time using DRV_AK4642_INIT or by using Initialization Overrides) that are supported by the specific AK4642 device hardware:
• Device requested power state: one of the System Module Power States. For specific details please refer to Data Types and Constants in the
Library Interface section.
• I2C driver module index. The module index should be same as the one used in initializing the I2C Driver.
• I2S driver module index. The module index should be same as the one used in initializing the I2S Driver.
• Sampling rate
• Master clock detection mode
• Power down pin port initialization
The DRV_AK4642_Initialize API returns an object handle of the type SYS_MODULE_OBJ. The object handle returned by the Initialize interface
would be used by the other system interfaces such as DRV_ AK4642_Deinitialize, DRV_ AK4642_Status and DRV_I2S_Tasks.
Implementations
The AK4642 Codec Driver can have the following implementations:
Implementation Description MPLAB Harmony Components
Implementation
1
Dedicated hardware for control (I2C) and data (I2S)
interface.
Standard MPLAB Harmony drivers for I2C and I2S interfaces.
Implementation
2
Dedicated hardware for data (I2S) interface.
Ports pins for control interface.
Standard MPLAB Harmony drivers for I2S interface.
Virtual MPLAB Harmony drivers for I2C interface.
Example:
DRV_AK4642_INIT drvak4642Init =
{
.moduleInit.value = SYS_MODULE_POWER_RUN_FULL,
.i2sDriverModuleIndex = DRV_AK4642_I2S_DRIVER_MODULE_INDEX_IDX0,
.i2cDriverModuleIndex = DRV_AK4642_I2C_DRIVER_MODULE_INDEX_IDX0,
.volume = DRV_AK4642_VOLUME,
};
/*
The I2C and I2S module index should be same as the one used in
initializing the I2C and I2S drivers.
*/
ak4642DevObject = DRV_AK4642_Initialize(DRV_AK4642_INDEX_0, (SYS_MODULE_INIT *) &drvak4642Init);
if (SYS_MODULE_OBJ_INVALID == ak4642DevObject)
{
// Handle error
}
Task Routine
The DRV_AK4642_Tasks will be called from the System Task Service.
Client Access
This topic describes client access and includes a code example.
Description
For the application to start using an instance of the module, it must call the DRV_AK4642_Open function. The DRV_AK4642_Open provides a
driver handle to the AK4642 Codec Driver instance for operations. If the driver is deinitialized using the function DRV_AK4642_Deinitialize, the
application must call the DRV_AK4642_Open function again to set up the instance of the driver.
For the various options available for IO_INTENT, please refer to Data Types and Constants in the Library Interface section.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 159
Note:
It is necessary to check the status of driver initialization before opening a driver instance. The status of the AK4642 Codec Driver
can be known by calling DRV_AK4642_Status.
Example:
DRV_HANDLE handle;
SYS_STATUS ak4642Status;
ak4642Status = DRV_AK4642_Status(sysObjects.ak4642DevObject);
if (SYS_STATUS_READY == ak4642Status)
{
// The driver can now be opened.
appData.ak4642Client.handle = DRV_AK4642_Open
(DRV_AK4642_INDEX_0,
DRV_IO_INTENT_WRITE |
DRV_IO_INTENT_EXCLUSIVE );
if(appData.ak4642Client.handle != DRV_HANDLE_INVALID)
{
appData.state = APP_STATE_AK4642_SET_BUFFER_HANDLER;
}
else
{
SYS_DEBUG(0, "Find out what's wrong \r\n");
}
}
else
{
/* AK4642 Driver Is not ready */
;
}
Client Operations
This topic describes client operations and provides a code example.
Description
Client operations provide the API interface for control command and audio data transfer to the AK4642 Codec.
The following AK4642 Codec specific control command functions are provided:
• DRV_AK4642_SamplingRateSet
• DRV_AK4642_SamplingRateGet
• DRV_AK4642_VolumeSet
• DRV_AK4642_VolumeGet
• DRV_AK4642_MuteOn
• DRV_AK4642_MuteOff
• DRV_AK4642_IntExtMicSet
• DRV_AK4642_MonoStereoMicSet
These functions schedule a non-blocking control command transfer operation. These functions submit the control command request to the I2C
Driver transmit queue, where the request is processed immediately if it is the first request, or it is processed when the previous request is complete.
DRV_AK4642_BufferAddWrite, DRV_AK4642_BufferAddRead, and DRV_AK4642_BufferAddWriteRead are buffered data operation functions.
These functions schedule non-blocking audio data transfer operations. These functions add the request to the I2S Driver transmit or receive buffer
queue depending on the request type, and are executed immediately if it is the first buffer, or executed later when the previous buffer is complete.
The driver notifies the client with DRV_AK4642_BUFFER_EVENT_COMPLETE, DRV_AK4642_BUFFER_EVENT_ERROR, or
DRV_AK4642_BUFFER_EVENT_ABORT events.
The following diagram illustrates the control commands and audio buffered data operations.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 160
Note:
It is not necessary to close and reopen the client between multiple transfers.
An application using the buffered functionality needs to perform the following steps:
1. The system should have completed necessary setup and initializations.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 161
2. The I2S driver object should have been initialized by calling DRV_I2S_Initialize.
3. The I2C driver object should have been initialized by calling DRV_I2C_Initialize.
4. The AK4642 driver object should be initialized by calling DRV_AK4642_Initialize.
5. The necessary sampling rate value should be set up by calling DRV_AK4642_ SamplingRateSet.
6. Register buffer event handler for the client handle by calling DRV_AK4642_BufferEventHandlerSet.
7. Submit a command by calling specific command API.
8. Add a buffer to initiate the data transfer by calling DRV_AK4642_BufferAddWrite, DRV_AK4642_BufferAddRead, and
DRV_AK4642_BufferAddWriteRead.
9. Call the DRV_AK4642_BufferAddWrite, DRV_AK4642_BufferAddRead, or DRV_AK4642_BufferAddWriteRead function for handling multiple
buffer transmissions or receptions.
10. When the client is done, it can use DRV_AK4642_Close to close the client handle.
Example:
typedef enum
{
APP_STATE_AK4642_OPEN,
APP_STATE_AK4642_SET_BUFFER_HANDLER,
APP_STATE_AK4642_ADD_FIRST_BUFFER_READ,
APP_STATE_AK4642_ADD_BUFFER_OUT,
APP_STATE_AK4642_ADD_BUFFER_IN,
APP_STATE_AK4642_WAIT_FOR_BUFFER_COMPLETE,
} APP_STATES;
typedef struct
{
DRV_HANDLE handle;
DRV_AK4642_BUFFER_HANDLE writereadBufHandle;
DRV_AK4642_BUFFER_EVENT_HANDLER bufferEventHandler;
uintptr_t context;
uint8_t *txbufferObject;
uint8_t *rxbufferObject;
size_t bufferSize;
} APP_AK4642_CLIENT;
typedef struct
{
/* Application's current state*/
APP_STATES state;
/* USART client handle */
APP_AK4642_CLIENT ak4642Client;
} APP_DATA;
APP_DATA appData;
SYS_MODULE_OBJ ak4642DevObject;
DRV_AK4642_INIT drvak4642Init =
{
.moduleInit.value = SYS_MODULE_POWER_RUN_FULL,
.i2sDriverModuleIndex = DRV_AK4642_I2S_DRIVER_MODULE_INDEX_IDX0,
.i2cDriverModuleIndex = DRV_AK4642_I2C_DRIVER_MODULE_INDEX_IDX0,
.volume = DRV_AK4642_VOLUME,
};
void SYS_Initialize(void * data)
{
/* Initialize Drivers */
DRV_I2C0_Initialize();
sysObj.drvI2S0 = DRV_I2S_Initialize(DRV_I2S_INDEX_0, (SYS_MODULE_INIT *)
&drvI2S0InitData);
sysObj.drvak4642Codec0 = DRV_AK4642_Initialize(DRV_AK4642_INDEX_0,
(SYS_MODULE_INIT *)&drvak4642Codec0InitData);
/* Initialize System Services */
SYS_INT_Initialize();
}
void APP_Tasks (void )
{
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 162
switch(appData.state)
{
case APP_STATE_AK4642_OPEN:
{
SYS_STATUS status;
status = DRV_CODEC_Status(sysObjdrvCodec0);
if (SYS_STATUS_READY == status)
{
/* A client opens the driver object to get an Handle */
appData.ak4642Client.handle = DRV_AK4642_Open(DRV_AK4642_INDEX_0,
DRV_IO_INTENT_WRITE|DRV_IO_INTENT_EXCLUSIVE);
if(appData.ak4642Client.handle != DRV_HANDLE_INVALID)
{
appData.state = APP_STATE_AK4642_SET_BUFFER_HANDLER;
}
else
{
/* Got an Invalid Handle. Wait for AK4642 to Initialize */
}
}
}
break;
/* Set a handler for the audio buffer completion event */
case APP_STATE_AK4642_SET_BUFFER_HANDLER:
{
DRV_AK4642_BufferEventHandlerSet(appData.ak4642Client.handle,
appData.ak4642Client.bufferEventHandler,
appData.ak4642Client.context);
appData.state = APP_STATE_AK4642_ADD_FIRST_BUFFER_READ;
}
break;
case APP_STATE_AK4642_ADD_FIRST_BUFFER_READ:
{
DRV_AK4642_BufferAddWriteRead(appData.ak4642Client.handle,
&appData.ak4642Client.writeReadBufHandle,
appData.ak4642Client.txbufferObject,
appData.ak4642Client.rxbufferObject,
appData.ak4642Client.bufferSize);
if(appData.ak4642Client.writeReadBufHandle != DRV_AK4642_BUFFER_HANDLE_INVALID)
{
appData.state = APP_STATE_AK4642_WAIT_FOR_BUFFER_COMPLETE;
}
else
{
SYS_DEBUG(0, "Find out what is wrong \r\n");
}
}
break;
/* Add an audio buffer to the ak4642 driver to be transmitted to
* AK4642 CODEC */
case APP_STATE_AK4642_ADD_BUFFER_OUT:
{
DRV_AK4642_BufferAddWrite(appData.ak4642Client.handle, &appData.ak4642Client.writeBufHandle,
appData.ak4642Client.txbufferObject, appData.ak4642Client.bufferSize);
if(appData.ak4642Client.writeBufHandle != DRV_AK4642_BUFFER_HANDLE_INVALID)
{
appData.state = APP_STATE_AK4642_WAIT_FOR_BUFFER_COMPLETE;
}
else
{
SYS_DEBUG(0, "Find out what is wrong \r\n");
}
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 163
}
break;
/* Add an audio buffer to the ak4642 driver to be received
* AK4642 CODEC */
case APP_STATE_AK4642_ADD_BUFFER_IN:
{
DRV_AK4642_BufferAddRead(appData.ak4642Client.handle, &appData.ak4642Client.readBufHandle,
appData.ak4642Client.rxbufferObject, appData.ak4642Client.bufferSize);
if(appData.ak4642Client.readBufHandle != DRV_AK4642_BUFFER_HANDLE_INVALID)
{
appData.state = APP_STATE_AK4642_ADD_BUFFER_OUT;
}
else
{
SYS_DEBUG(0, "Find out what is wrong \r\n");
}
}
break;
/* Audio data Transmission under process */
case APP_STATE_AK4642_WAIT_FOR_BUFFER_COMPLETE:
{
/*Do nothing*/
}
break;
default:
{
}
break;
}
}
/**********************************************************
* Application AK4642 buffer Event handler.
* This function is called back by the AK4642 driver when
* a AK4642 data buffer RX completes.
**********************************************************/
void APP_AK4642MicBufferEventHandler(DRV_AK4642_BUFFER_EVENT event,
DRV_AK4642_BUFFER_HANDLE handle, uintptr_t context )
{
static uint8_t cnt = 0;
switch(event)
{
case DRV_AK4642_BUFFER_EVENT_COMPLETE:
{
bufnum ^= 1;
if(bufnum ==0)
{
appData.ak4642Client.rxbufferObject = (uint8_t *) micbuf1;
appData.ak4642Client.txbufferObject = (uint8_t *) micbuf2;
}
else if(bufnum ==1)
{
appData.ak4642Client.rxbufferObject = (uint8_t *) micbuf2;
appData.ak4642Client.txbufferObject = (uint8_t *) micbuf1;
}
DRV_AK4642_BufferAddWriteRead(appData.ak4642Client.handle,
&appData.ak4642Client.writeReadBufHandle,
appData.ak4642Client.txbufferObject,
appData.ak4642Client.rxbufferObject,
appData.ak4642Client.bufferSize);
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 164
appData.state = APP_STATE_AK4642_WAIT_FOR_BUFFER_COMPLETE;
}
break;
case DRV_AK4642_BUFFER_EVENT_ERROR:
{
} break;
case DRV_AK4642_BUFFER_EVENT_ABORT:
{
} break;
}
}
void SYS_Tasks(void)
{
DRV_AK4642_Tasks(ak4642DevObject);
APP_Tasks();
}
Configuring the Library
Macros
Name Description
DRV_AK4642_BCLK_BIT_CLK_DIVISOR Sets up the BCLK to LRCK Ratio to Generate Audio Stream for specified
sampling frequency
DRV_AK4642_CLIENTS_NUMBER Sets up the maximum number of clients that can be connected to any
hardware instance.
DRV_AK4642_INPUT_REFCLOCK Identifies the input REFCLOCK source to generate the MCLK to codec.
DRV_AK4642_INSTANCES_NUMBER Sets up the maximum number of hardware instances that can be supported
DRV_AK4642_MCLK_SAMPLE_FREQ_MULTPLIER Sets up the MCLK to LRCK Ratio to Generate Audio Stream for specified
sampling frequency
DRV_AK4642_MCLK_SOURCE Indicate the input clock frequency to generate the MCLK to codec.
Description
The configuration of the AK4642 Codec Driver is based on the file system_config.h.
This header file contains the configuration selection for the AK4642 Codec Driver. Based on the selections made, the driver may support the
selected features. These configuration settings will apply to all instances of the AK4642 Codec Driver.
This header can be placed anywhere, the path of this header needs to be present in the include search path for a successful build. Refer to the
Applications Help section for more details.
DRV_AK4642_BCLK_BIT_CLK_DIVISOR Macro
Sets up the BCLK to LRCK Ratio to Generate Audio Stream for specified sampling frequency
File
drv_ak4642_config_template.h
C
#define DRV_AK4642_BCLK_BIT_CLK_DIVISOR
Description
AK4642 BCLK to LRCK Ratio to Generate Audio Stream
Sets up the BCLK to LRCK Ratio to Generate Audio Stream for specified sampling frequency
Following BCLK to LRCK ratios are supported 16bit data 16 bit channel :- 32fs, hence divisor would be 8 16bit data 32 bit channel :- 64fs, hence
divisor would be 4
Remarks
None.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 165
DRV_AK4642_CLIENTS_NUMBER Macro
Sets up the maximum number of clients that can be connected to any hardware instance.
File
drv_ak4642_config_template.h
C
#define DRV_AK4642_CLIENTS_NUMBER DRV_AK4642_INSTANCES_NUMBER
Description
AK4642 Client Count Configuration
Sets up the maximum number of clients that can be connected to any hardware instance. Typically only one client could be connected to one
hardware instance. This value represents the total number of clients to be supported across all hardware instances. Therefore, if there are five
AK4642 hardware interfaces, this number will be 5.
Remarks
None.
DRV_AK4642_INPUT_REFCLOCK Macro
Identifies the input REFCLOCK source to generate the MCLK to codec.
File
drv_ak4642_config_template.h
C
#define DRV_AK4642_INPUT_REFCLOCK
Description
AK4642 Input reference clock
Identifies the input REFCLOCK source to generate the MCLK to codec.
Remarks
None.
DRV_AK4642_INSTANCES_NUMBER Macro
Sets up the maximum number of hardware instances that can be supported
File
drv_ak4642_config_template.h
C
#define DRV_AK4642_INSTANCES_NUMBER
Description
AK4642 driver objects configuration
Sets up the maximum number of hardware instances that can be supported. It is recommended that this number be set exactly equal to the
number of AK4642 CODEC modules that are needed by the application. Hardware Instance support consumes RAM memory space. If this macro
is not defined, then the driver will be built statically.
Remarks
None.
DRV_AK4642_MCLK_SAMPLE_FREQ_MULTPLIER Macro
Sets up the MCLK to LRCK Ratio to Generate Audio Stream for specified sampling frequency
File
drv_ak4642_config_template.h
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 166
C
#define DRV_AK4642_MCLK_SAMPLE_FREQ_MULTPLIER
Description
AK4642 MCLK to LRCK Ratio to Generate Audio Stream
Sets up the MCLK to LRCK Ratio to Generate Audio Stream for specified sampling frequency I2S sampling frequency
Supported MCLK to Sampling frequency Ratios are as below 256fs, 384fs, 512fs, 768fs or 1152fs
Remarks
None
DRV_AK4642_MCLK_SOURCE Macro
Indicate the input clock frequency to generate the MCLK to codec.
File
drv_ak4642_config_template.h
C
#define DRV_AK4642_MCLK_SOURCE
Description
AK4642 Data Interface Master Clock Speed configuration
Indicate the input clock frequency to generate the MCLK to codec.
Remarks
None.
Configuring the MHC
Provides examples on how to configure the MPLAB Harmony Configurator (MHC) for a specific driver.
Description
The following three figures show examples of MHC configurations for the AK4642 Codec Driver, I2S Driver, and the I2C Driver.
Figure 1: AK4642 Codec Driver MHC Configuration
Figure 2: I2S Driver MHC Configuration
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 167
Figure 3: I2C Driver MHC Configuration
Migrating the AK4642 Driver From Earlier Versions of Microchip Harmony
Prior to version 1.08 of MPLAB Harmony, the AK4642 Codec Driver Library used the static I2C driver implementation. Beginning with v1.08 of
MPLAB Harmony, applications must use the Dynamic Driver implementation with the MHC configured as shown in Figure 3. In addition, PIC32MZ
configurations require the "Include Force Write I2C Function (Master Mode Only - Ignore NACK from Slave)" option to be selected.
Building the Library
This section lists the files that are available in the AK4642 Codec Driver Library.
Description
This section list the files that are available in the /src folder of the AK4642 Codec Driver. It lists which files need to be included in the build based
on either a hardware feature present on the board or configuration option selected by the system.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 168
The following three tables list and describe the header (.h) and source (.c) files that implement this library. The parent folder for these files is
/framework/driver/codec/ak4642.
Interface File(s)
This table lists and describes the header files that must be included (i.e., using #include) by any code that uses this library.
Source File Name Description
/drv_ak4642.h Header file that exports the driver API.
Required File(s)
All of the required files listed in the following table are automatically added into the MPLAB X IDE project by the MHC
when the library is selected for use.
This table lists and describes the source and header files that must always be included in the MPLAB X IDE project to build this library.
Source File Name Description
/src/dynamic/drv_ak4642.c This file contains implementation of the AK4642 Codec Driver.
Optional File(s)
This table lists and describes the source and header files that may optionally be included if required for the desired implementation.
Source File Name Description
There are no optional files for this driver. N/A
Module Dependencies
The AK4642 Driver Library depends on the following modules:
• I2S Driver Library
• I2C Driver Library
Library Interface
a) System Interaction Functions
Name Description
DRV_AK4642_Initialize Initializes hardware and data for the instance of the AK4642 DAC module
DRV_AK4642_Deinitialize Deinitializes the specified instance of the AK4642 driver module
DRV_AK4642_Status Gets the current status of the AK4642 driver module.
DRV_AK4642_Tasks Maintains the driver's control and data interface state machine.
b) Client Setup Functions
Name Description
DRV_AK4642_Open Opens the specified AK4642 driver instance and returns a handle to it
DRV_AK4642_Close Closes an opened-instance of the AK4642 driver
c) Codec Specific Functions
Name Description
DRV_AK4642_MuteOff This function disables AK4642 output for soft mute.
DRV_AK4642_MuteOn This function allows AK4642 output for soft mute on.
DRV_AK4642_SamplingRateGet This function gets the sampling rate set on the AK4642.
Implementation: Dynamic
DRV_AK4642_SamplingRateSet This function sets the sampling rate of the media stream.
DRV_AK4642_VolumeGet This function gets the volume for AK4642 CODEC.
DRV_AK4642_VolumeSet This function sets the volume for AK4642 CODEC.
DRV_AK4642_IntExtMicSet This function sets up the codec for the internal or the external microphone use.
DRV_AK4642_MonoStereoMicSet This function sets up the codec for the Mono or Stereo microphone mode.
DRV_AK4642_SetAudioCommunicationMode This function provides a run time audio format configuration
DRV_AK4642_MicSet This function select the single-ended AK4642 microphone input for the AK4642
Codec
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 169
d) Data Transfer Functions
Name Description
DRV_AK4642_BufferAddWrite Schedule a non-blocking driver write operation.
DRV_AK4642_BufferAddRead Schedule a non-blocking driver read operation.
DRV_AK4642_BufferAddWriteRead Schedule a non-blocking driver write-read operation.
Implementation: Dynamic
DRV_AK4642_BufferEventHandlerSet This function allows a client to identify a buffer event handling function for the driver to call
back when queued buffer transfers have finished.
e) Other Functions
Name Description
DRV_AK4642_CommandEventHandlerSet This function allows a client to identify a command event handling function for the
driver to call back when the last submitted command have finished.
DRV_AK4642_VersionGet This function returns the version of AK4642 driver
DRV_AK4642_VersionStrGet This function returns the version of AK4642 driver in string format.
f) Data Types and Constants
Name Description
_DRV_AK4642_H Include files.
DRV_AK4642_BUFFER_HANDLE_INVALID Definition of an invalid buffer handle.
DRV_AK4642_COUNT Number of valid AK4642 driver indices
DRV_AK4642_INDEX_0 AK4642 driver index definitions
DRV_AK4642_INDEX_1 This is macro DRV_AK4642_INDEX_1.
DRV_AK4642_INDEX_2 This is macro DRV_AK4642_INDEX_2.
DRV_AK4642_INDEX_3 This is macro DRV_AK4642_INDEX_3.
DRV_AK4642_INDEX_4 This is macro DRV_AK4642_INDEX_4.
DRV_AK4642_INDEX_5 This is macro DRV_AK4642_INDEX_5.
DRV_AK4642_AUDIO_DATA_FORMAT Identifies the Serial Audio data interface format.
DRV_AK4642_BUFFER_EVENT Identifies the possible events that can result from a buffer add request.
DRV_AK4642_BUFFER_EVENT_HANDLER Pointer to a AK4642 Driver Buffer Event handler function
DRV_AK4642_BUFFER_HANDLE Handle identifying a write buffer passed to the driver.
DRV_AK4642_CHANNEL Identifies Left/Right Audio channel
DRV_AK4642_COMMAND_EVENT_HANDLER Pointer to a AK4642 Driver Command Event Handler Function
DRV_AK4642_INIT Defines the data required to initialize or reinitialize the AK4642 driver
DRV_AK4642_INT_EXT_MIC Identifies the Mic input source.
DRV_AK4642_MONO_STEREO_MIC Identifies the Mic input as Mono / Stereo.
DRV_AK4642_MIC This is type DRV_AK4642_MIC.
Description
This section describes the API functions of the AK4642 Codec Driver library.
Refer to each section for a detailed description.
a) System Interaction Functions
DRV_AK4642_Initialize Function
Initializes hardware and data for the instance of the AK4642 DAC module
File
drv_ak4642.h
C
SYS_MODULE_OBJ DRV_AK4642_Initialize(const SYS_MODULE_INDEX drvIndex, const SYS_MODULE_INIT * const init);
Returns
If successful, returns a valid handle to a driver instance object. Otherwise, it returns SYS_MODULE_OBJ_INVALID.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 170
Description
This routine initializes the AK4642 driver instance for the specified driver index, making it ready for clients to open and use it. The initialization data
is specified by the init parameter. The initialization may fail if the number of driver objects allocated are insufficient or if the specified driver instance
is already initialized.
Remarks
This routine must be called before any other AK4642 routine is called.
This routine should only be called once during system initialization unless DRV_AK4642_Deinitialize is called to deinitialize the driver instance.
This routine will NEVER block for hardware access.
Preconditions
DRV_I2S_Initialize must be called before calling this function to initialize the data interface of this CODEC driver. DRV_I2C_Initialize must be
called if SPI driver is used for handling the control interface of this CODEC driver.
Example
DRV_AK4642_INIT init;
SYS_MODULE_OBJ objectHandle;
init->inUse = true;
init->status = SYS_STATUS_BUSY;
init->numClients = 0;
init->i2sDriverModuleIndex = ak4642Init->i2sDriverModuleIndex;
init->i2cDriverModuleIndex = ak4642Init->i2cDriverModuleIndex;
init->samplingRate = DRV_AK4642_AUDIO_SAMPLING_RATE;
init->audioDataFormat = DRV_AK4642_AUDIO_DATA_FORMAT_MACRO;
init->isInInterruptContext = false;
init->commandCompleteCallback = (DRV_AK4642_COMMAND_EVENT_HANDLER)0;
init->commandContextData = 0;
init->mclk_multiplier = DRV_AK4642_MCLK_SAMPLE_FREQ_MULTPLIER;
objectHandle = DRV_AK4642_Initialize(DRV_AK4642_0, (SYS_MODULE_INIT*)init);
if (SYS_MODULE_OBJ_INVALID == objectHandle)
{
// Handle error
}
Parameters
Parameters Description
drvIndex Identifier for the driver instance to be initialized
init Pointer to the data structure containing any data necessary to initialize the hardware. This
pointer may be null if no data is required and default initialization is to be used.
Function
SYS_MODULE_OBJ DRV_AK4642_Initialize
(
const SYS_MODULE_INDEX drvIndex,
const SYS_MODULE_INIT *const init
);
DRV_AK4642_Deinitialize Function
Deinitializes the specified instance of the AK4642 driver module
File
drv_ak4642.h
C
void DRV_AK4642_Deinitialize(SYS_MODULE_OBJ object);
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 171
Returns
None.
Description
Deinitializes the specified instance of the AK4642 driver module, disabling its operation (and any hardware). Invalidates all the internal data.
Remarks
Once the Initialize operation has been called, the De-initialize operation must be called before the Initialize operation can be called again. This
routine will NEVER block waiting for hardware.
Preconditions
Function DRV_AK4642_Initialize should have been called before calling this function.
Example
SYS_MODULE_OBJ object; // Returned from DRV_AK4642_Initialize
SYS_STATUS status;
DRV_AK4642_Deinitialize(object);
status = DRV_AK4642_Status(object);
if (SYS_MODULE_DEINITIALIZED != status)
{
// Check again later if you need to know
// when the driver is deinitialized.
}
Parameters
Parameters Description
object Driver object handle, returned from the DRV_AK4642_Initialize routine
Function
void DRV_AK4642_Deinitialize( SYS_MODULE_OBJ object)
DRV_AK4642_Status Function
Gets the current status of the AK4642 driver module.
File
drv_ak4642.h
C
SYS_STATUS DRV_AK4642_Status(SYS_MODULE_OBJ object);
Returns
SYS_STATUS_DEINITIALIZED - Indicates that the driver has been deinitialized
SYS_STATUS_READY - Indicates that any previous module operation for the specified module has completed
SYS_STATUS_BUSY - Indicates that a previous module operation for the specified module has not yet completed
SYS_STATUS_ERROR - Indicates that the specified module is in an error state
Description
This routine provides the current status of the AK4642 driver module.
Remarks
A driver can opened only when its status is SYS_STATUS_READY.
Preconditions
Function DRV_AK4642_Initialize should have been called before calling this function.
Example
SYS_MODULE_OBJ object; // Returned from DRV_AK4642_Initialize
SYS_STATUS AK4642Status;
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 172
AK4642Status = DRV_AK4642_Status(object);
if (SYS_STATUS_READY == AK4642Status)
{
// This means the driver can be opened using the
// DRV_AK4642_Open() function.
}
Parameters
Parameters Description
object Driver object handle, returned from the DRV_AK4642_Initialize routine
Function
SYS_STATUS DRV_AK4642_Status( SYS_MODULE_OBJ object)
DRV_AK4642_Tasks Function
Maintains the driver's control and data interface state machine.
File
drv_ak4642.h
C
void DRV_AK4642_Tasks(SYS_MODULE_OBJ object);
Returns
None.
Description
This routine is used to maintain the driver's internal control and data interface state machine and implement its control and data interface
implementations. This function should be called from the SYS_Tasks() function.
Remarks
This routine is normally not called directly by an application. It is called by the system's Tasks routine (SYS_Tasks).
Preconditions
The DRV_AK4642_Initialize routine must have been called for the specified AK4642 driver instance.
Example
SYS_MODULE_OBJ object; // Returned from DRV_AK4642_Initialize
while (true)
{
DRV_AK4642_Tasks (object);
// Do other tasks
}
Parameters
Parameters Description
object Object handle for the specified driver instance (returned from DRV_AK4642_Initialize)
Function
void DRV_AK4642_Tasks(SYS_MODULE_OBJ object);
b) Client Setup Functions
DRV_AK4642_Open Function
Opens the specified AK4642 driver instance and returns a handle to it
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 173
File
drv_ak4642.h
C
DRV_HANDLE DRV_AK4642_Open(const SYS_MODULE_INDEX iDriver, const DRV_IO_INTENT ioIntent);
Returns
If successful, the routine returns a valid open-instance handle (a number identifying both the caller and the module instance).
If an error occurs, the return value is DRV_HANDLE_INVALID. Error can occur
• if the number of client objects allocated via DRV_AK4642_CLIENTS_NUMBER is insufficient.
• if the client is trying to open the driver but driver has been opened exclusively by another client.
• if the driver hardware instance being opened is not initialized or is invalid.
• if the ioIntent options passed are not relevant to this driver.
Description
This routine opens the specified AK4642 driver instance and provides a handle that must be provided to all other client-level operations to identify
the caller and the instance of the driver. The ioIntent parameter defines how the client interacts with this driver instance.
The DRV_IO_INTENT_BLOCKING and DRV_IO_INTENT_NONBLOCKING ioIntent options are not relevant to this driver. All the data transfer
functions of this driver are non blocking.
AK4642 can be opened with DRV_IO_INTENT_WRITE, or DRV_IO_INTENT_READ or DRV_IO_INTENT_WRITEREAD io_intent option. This
decides whether the driver is used for headphone output, or microphone input or both modes simultaneously.
Specifying a DRV_IO_INTENT_EXCLUSIVE will cause the driver to provide exclusive access to this client. The driver cannot be opened by any
other client.
Remarks
The handle returned is valid until the DRV_AK4642_Close routine is called. This routine will NEVER block waiting for hardware.If the requested
intent flags are not supported, the routine will return DRV_HANDLE_INVALID. This function is thread safe in a RTOS application. It should not be
called in an ISR.
Preconditions
Function DRV_AK4642_Initialize must have been called before calling this function.
Example
DRV_HANDLE handle;
handle = DRV_AK4642_Open(DRV_AK4642_INDEX_0, DRV_IO_INTENT_WRITEREAD | DRV_IO_INTENT_EXCLUSIVE);
if (DRV_HANDLE_INVALID == handle)
{
// Unable to open the driver
// May be the driver is not initialized or the initialization
// is not complete.
}
Parameters
Parameters Description
drvIndex Identifier for the object instance to be opened
ioIntent Zero or more of the values from the enumeration DRV_IO_INTENT "ORed" together to
indicate the intended use of the driver. See function description for details.
Function
DRV_HANDLE DRV_AK4642_Open
(
const SYS_MODULE_INDEX drvIndex,
const DRV_IO_INTENT ioIntent
)
DRV_AK4642_Close Function
Closes an opened-instance of the AK4642 driver
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 174
File
drv_ak4642.h
C
void DRV_AK4642_Close(const DRV_HANDLE handle);
Returns
• None
Description
This routine closes an opened-instance of the AK4642 driver, invalidating the handle. Any buffers in the driver queue that were submitted by this
client will be removed. After calling this routine, the handle passed in "handle" must not be used with any of the remaining driver routines. A new
handle must be obtained by calling DRV_AK4642_Open before the caller may use the driver again
Remarks
Usually there is no need for the driver client to verify that the Close operation has completed. The driver will abort any ongoing operations when
this routine is called.
Preconditions
The DRV_AK4642_Initialize routine must have been called for the specified AK4642 driver instance.
DRV_AK4642_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE handle; // Returned from DRV_AK4642_Open
DRV_AK4642_Close(handle);
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
void DRV_AK4642_Close( DRV_Handle handle )
c) Codec Specific Functions
DRV_AK4642_MuteOff Function
This function disables AK4642 output for soft mute.
File
drv_ak4642.h
C
void DRV_AK4642_MuteOff(DRV_HANDLE handle);
Returns
None.
Description
This function disables AK4642 output for soft mute.
Remarks
None.
Preconditions
The DRV_AK4642_Initialize routine must have been called for the specified AK4642 driver instance.
DRV_AK4642_Open must have been called to obtain a valid opened device handle.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 175
Example
// myAppObj is an application specific object.
MY_APP_OBJ myAppObj;
uint8_t mybuffer[MY_BUFFER_SIZE];
DRV_BUFFER_HANDLE bufferHandle;
// myAK4642Handle is the handle returned
// by the DRV_AK4642_Open function.
DRV_AK4642_MuteOff(myAK4642Handle); //AK4642 output soft mute disabled
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
void DRV_AK4642_MuteOff( DRV_HANDLE handle)
DRV_AK4642_MuteOn Function
This function allows AK4642 output for soft mute on.
File
drv_ak4642.h
C
void DRV_AK4642_MuteOn(DRV_HANDLE handle);
Returns
None.
Description
This function Enables AK4642 output for soft mute.
Remarks
None.
Preconditions
The DRV_AK4642_Initialize routine must have been called for the specified AK4642 driver instance.
DRV_AK4642_Open must have been called to obtain a valid opened device handle.
Example
// myAppObj is an application specific object.
MY_APP_OBJ myAppObj;
uint8_t mybuffer[MY_BUFFER_SIZE];
DRV_BUFFER_HANDLE bufferHandle;
// myAK4642Handle is the handle returned
// by the DRV_AK4642_Open function.
DRV_AK4642_MuteOn(myAK4642Handle); //AK4642 output soft muted
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
void DRV_AK4642_MuteOn( DRV_HANDLE handle);
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 176
DRV_AK4642_SamplingRateGet Function
This function gets the sampling rate set on the AK4642.
Implementation: Dynamic
File
drv_ak4642.h
C
uint32_t DRV_AK4642_SamplingRateGet(DRV_HANDLE handle);
Description
This function gets the sampling rate set on the DAC AK4642.
Remarks
None.
Example
uint32_t baudRate;
// myAK4642Handle is the handle returned
// by the DRV_AK4642_Open function.
baudRate = DRV_AK4642_SamplingRateGet(myAK4642Handle);
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
uint32_t DRV_AK4642_SamplingRateGet( DRV_HANDLE handle)
DRV_AK4642_SamplingRateSet Function
This function sets the sampling rate of the media stream.
File
drv_ak4642.h
C
void DRV_AK4642_SamplingRateSet(DRV_HANDLE handle, uint32_t samplingRate);
Returns
None.
Description
This function sets the media sampling rate for the client handle.
Remarks
None.
Preconditions
The DRV_AK4642_Initialize routine must have been called for the specified AK4642 driver instance.
DRV_AK4642_Open must have been called to obtain a valid opened device handle.
Example
// myAK4642Handle is the handle returned
// by the DRV_AK4642_Open function.
DRV_AK4642_SamplingRateSet(myAK4642Handle, 48000); //Sets 48000 media sampling rate
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 177
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
samplingRate Sampling frequency in Hz
Function
void DRV_AK4642_SamplingRateSet( DRV_HANDLE handle, uint32_t samplingRate)
DRV_AK4642_VolumeGet Function
This function gets the volume for AK4642 CODEC.
File
drv_ak4642.h
C
uint8_t DRV_AK4642_VolumeGet(DRV_HANDLE handle, DRV_AK4642_CHANNEL channel);
Returns
None.
Description
This functions gets the current volume programmed to the CODEC AK4642.
Remarks
None.
Preconditions
The DRV_AK4642_Initialize routine must have been called for the specified AK4642 driver instance.
DRV_AK4642_Open must have been called to obtain a valid opened device handle.
Example
// myAppObj is an application specific object.
MY_APP_OBJ myAppObj;
uint8_t volume;
// myAK4642Handle is the handle returned
// by the DRV_AK4642_Open function.
volume = DRV_AK4642_VolumeGet(myAK4642Handle, DRV_AK4642_CHANNEL_LEFT);
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
channel argument indicating Left or Right or Both channel volume to be modified
Function
uint8_t DRV_AK4642_VolumeGet( DRV_HANDLE handle, DRV_AK4642_CHANNEL channel)
DRV_AK4642_VolumeSet Function
This function sets the volume for AK4642 CODEC.
File
drv_ak4642.h
C
void DRV_AK4642_VolumeSet(DRV_HANDLE handle, DRV_AK4642_CHANNEL channel, uint8_t volume);
Returns
None
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 178
Description
This functions sets the volume value from 0-255. The codec has DAC value to volume range mapping as :- 00 H : +12dB FF H : -115dB In order to
make the volume value to dB mapping monotonically increasing from 00 to FF, re-mapping is introduced which reverses the volume value to dB
mapping as well as normalizes the volume range to a more audible dB range. The current driver implementation assumes that all dB values under
-60 dB are inaudible to the human ear. Re-Mapped values 00 H : -60 dB FF H : +12 dB
Remarks
None.
Preconditions
The DRV_AK4642_Initialize routine must have been called for the specified AK4642 driver instance.
DRV_AK4642_Open must have been called to obtain a valid opened device handle.
Example
// myAppObj is an application specific object.
MY_APP_OBJ myAppObj;
uint8_t mybuffer[MY_BUFFER_SIZE];
DRV_BUFFER_HANDLE bufferHandle;
// myAK4642Handle is the handle returned
// by the DRV_AK4642_Open function.
DRV_AK4642_VolumeSet(myAK4642Handle,DRV_AK4642_CHANNEL_LEFT, 120);
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
channel argument indicating Left or Right or Both channel volume to be modified
volume volume value specified in the range 0-255 (0x00 to 0xFF)
Function
void DRV_AK4642_VolumeSet( DRV_HANDLE handle, DRV_AK4642_CHANNEL channel, uint8_t volume);
DRV_AK4642_IntExtMicSet Function
This function sets up the codec for the internal or the external microphone use.
File
drv_ak4642.h
C
void DRV_AK4642_IntExtMicSet(DRV_HANDLE handle, DRV_AK4642_INT_EXT_MIC micInput);
Returns
None
Description
This function sets up the codec for the internal or the external microphone use.
Remarks
None.
Preconditions
The DRV_AK4642_Initialize routine must have been called for the specified AK4642 driver instance.
DRV_AK4642_Open must have been called to obtain a valid opened device handle.
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
micInput INT_MIC or EXT_MIC
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 179
Function
void DRV_AK4642_IntExtMicSet( DRV_HANDLE handle,
DRV_AK4642_INT_EXT_MIC micInput);
DRV_AK4642_MonoStereoMicSet Function
This function sets up the codec for the Mono or Stereo microphone mode.
File
drv_ak4642.h
C
void DRV_AK4642_MonoStereoMicSet(DRV_HANDLE handle, DRV_AK4642_MONO_STEREO_MIC mono_stereo_mic);
Returns
None
Description
This function sets up the codec for the Mono or Stereo microphone mode.
Remarks
Currently the ak4642 codec does not work in the MONO_LEFT_CHANNEL mode. This issue will be followed up with AKM.
Preconditions
The DRV_AK4642_Initialize routine must have been called for the specified AK4642 driver instance.
DRV_AK4642_Open must have been called to obtain a valid opened device handle.
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
mono_stereo_mic Mono / Stereo mic setup
Function
void DRV_AK4642_MonoStereoMicSet( DRV_HANDLE handle);
DRV_AK4642_SetAudioCommunicationMode Function
This function provides a run time audio format configuration
File
drv_ak4642.h
C
void DRV_AK4642_SetAudioCommunicationMode(DRV_HANDLE handle, const DATA_LENGTH dl, const SAMPLE_LENGTH sl);
Returns
None
Description
This function sets up audio mode in I2S protocol
Remarks
None.
Preconditions
The DRV_AK4642_Initialize routine must have been called for the specified AK4642 driver instance.
DRV_AK4642_Open must have been called to obtain a valid opened device handle.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 180
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
dl Data length for I2S audio interface
sl Left/Right Sample Length for I2S audio interface
Function
void DRV_AK4642_SetAudioCommunicationMode
(
DRV_HANDLE handle,
const DATA_LENGTH dl,
const SAMPLE_LENGTH sl
)
DRV_AK4642_MicSet Function
This function select the single-ended AK4642 microphone input for the AK4642 Codec
File
drv_ak4642.h
C
void DRV_AK4642_MicSet(DRV_HANDLE handle, DRV_AK4642_MIC micInput);
Returns
None
Description
This function selects the single-ended AK4642 microphone input for the AK4642 Codec (Where the MEMS mic is MIC1, and the external
Microphone input is MIC2 on the AK4642 XC32 Daughter Board)
Remarks
None.
Preconditions
The DRV_AK4642_Initialize routine must have been called for the specified AK4642 driver instance.
DRV_AK4642_Open must have been called to obtain a valid opened device handle.
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
micInput MIC1 or MIC2
Function
void DRV_AK4642_MicSet( DRV_HANDLE handle, DRV_AK4642_MIC micInput);
d) Data Transfer Functions
DRV_AK4642_BufferAddWrite Function
Schedule a non-blocking driver write operation.
File
drv_ak4642.h
C
void DRV_AK4642_BufferAddWrite(const DRV_HANDLE handle, DRV_AK4642_BUFFER_HANDLE * bufferHandle, void *
buffer, size_t size);
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 181
Returns
The bufferHandle parameter will contain the return buffer handle. This will be DRV_AK4642_BUFFER_HANDLE_INVALID if the function was not
successful.
Description
This function schedules a non-blocking write operation. The function returns with a valid buffer handle in the bufferHandle argument if the write
request was scheduled successfully. The function adds the request to the hardware instance transmit queue and returns immediately. While the
request is in the queue, the application buffer is owned by the driver and should not be modified. The function returns
DRV_AK4642_BUFFER_HANDLE_INVALID:
• if a buffer could not be allocated to the request
• if the input buffer pointer is NULL
• if the buffer size is 0.
• if the queue is full or the queue depth is insufficient
If the requesting client registered an event callback with the driver, the driver will issue a DRV_AK4642_BUFFER_EVENT_COMPLETE event if
the buffer was processed successfully of DRV_AK4642_BUFFER_EVENT_ERROR event if the buffer was not processed successfully.
Remarks
This function is thread safe in a RTOS application. It can be called from within the AK4642 Driver Buffer Event Handler that is registered by this
client. It should not be called in the event handler associated with another AK4642 driver instance. It should not otherwise be called directly in an
ISR.
Preconditions
The DRV_AK4642_Initialize routine must have been called for the specified AK4642 device instance and the DRV_AK4642_Status must have
returned SYS_STATUS_READY.
DRV_AK4642_Open must have been called to obtain a valid opened device handle.
DRV_IO_INTENT_WRITE must have been specified in the DRV_AK4642_Open call.
Example
MY_APP_OBJ myAppObj;
uint8_t mybuffer[MY_BUFFER_SIZE];
DRV_AK4642_BUFFER_HANDLE bufferHandle;
// myAK4642Handle is the handle returned
// by the DRV_AK4642_Open function.
// Client registers an event handler with driver
DRV_AK4642_BufferEventHandlerSet(myAK4642Handle,
APP_AK4642BufferEventHandler, (uintptr_t)&myAppObj);
DRV_AK4642_BufferAddWrite(myAK4642handle, &bufferHandle
myBuffer, MY_BUFFER_SIZE);
if(DRV_AK4642_BUFFER_HANDLE_INVALID == bufferHandle)
{
// Error handling here
}
// Event is received when
// the buffer is processed.
void APP_AK4642BufferEventHandler(DRV_AK4642_BUFFER_EVENT event,
DRV_AK4642_BUFFER_HANDLE bufferHandle, uintptr_t contextHandle)
{
// contextHandle points to myAppObj.
switch(event)
{
case DRV_AK4642_BUFFER_EVENT_COMPLETE:
// This means the data was transferred.
break;
case DRV_AK4642_BUFFER_EVENT_ERROR:
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 182
// Error handling here.
break;
default:
break;
}
}
Parameters
Parameters Description
handle Handle of the AK4642 instance as return by the DRV_AK4642_Open function.
buffer Data to be transmitted.
size Buffer size in bytes.
bufferHandle Pointer to an argument that will contain the return buffer handle.
Function
void DRV_AK4642_BufferAddWrite
(
const DRV_HANDLE handle,
DRV_AK4642_BUFFER_HANDLE *bufferHandle,
void *buffer, size_t size
)
DRV_AK4642_BufferAddRead Function
Schedule a non-blocking driver read operation.
File
drv_ak4642.h
C
void DRV_AK4642_BufferAddRead(const DRV_HANDLE handle, DRV_AK4642_BUFFER_HANDLE * bufferHandle, void *
buffer, size_t size);
Returns
The bufferHandle parameter will contain the return buffer handle. This will be DRV_AK4642_BUFFER_HANDLE_INVALID if the function was not
successful.
Description
This function schedules a non-blocking read operation. The function returns with a valid buffer handle in the bufferHandle argument if the read
request was scheduled successfully. The function adds the request to the hardware instance receive queue and returns immediately. While the
request is in the queue, the application buffer is owned by the driver and should not be modified. The function returns
DRV_AK4642_BUFFER_HANDLE_INVALID
• if a buffer could not be allocated to the request
• if the input buffer pointer is NULL
• if the buffer size is 0.
• if the queue is full or the queue depth is insufficient
If the requesting client registered an event callback with the driver, the driver will issue a DRV_AK4642_BUFFER_EVENT_COMPLETE event if
the buffer was processed successfully of DRV_AK4642_BUFFER_EVENT_ERROR event if the buffer was not processed successfully.
Remarks
This function is thread safe in a RTOS application. It can be called from within the AK4642 Driver Buffer Event Handler that is registered by this
client. It should not be called in the event handler associated with another AK4642 driver instance. It should not otherwise be called directly in an
ISR.
Preconditions
The DRV_AK4642_Initialize routine must have been called for the specified AK4642 device instance and the DRV_AK4642_Status must have
returned SYS_STATUS_READY.
DRV_AK4642_Open must have been called to obtain a valid opened device handle.
DRV_IO_INTENT_READ must have been specified in the DRV_AK4642_Open call.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 183
Parameters
Parameters Description
handle Handle of the AK4642 instance as return by the DRV_AK4642_Open function.
buffer Data to be transmitted.
size Buffer size in bytes.
bufferHandle Pointer to an argument that will contain the return buffer handle.
Function
void DRV_AK4642_BufferAddRead
(
const DRV_HANDLE handle,
DRV_AK4642_BUFFER_HANDLE *bufferHandle,
void *buffer, size_t size
)
DRV_AK4642_BufferAddWriteRead Function
Schedule a non-blocking driver write-read operation.
Implementation: Dynamic
File
drv_ak4642.h
C
void DRV_AK4642_BufferAddWriteRead(const DRV_HANDLE handle, DRV_AK4642_BUFFER_HANDLE * bufferHandle, void *
transmitBuffer, void * receiveBuffer, size_t size);
Returns
The bufferHandle parameter will contain the return buffer handle. This will be DRV_AK4642_BUFFER_HANDLE_INVALID if the function was not
successful.
Description
This function schedules a non-blocking write-read operation. The function returns with a valid buffer handle in the bufferHandle argument if the
write-read request was scheduled successfully. The function adds the request to the hardware instance queue and returns immediately. While the
request is in the queue, the application buffer is owned by the driver and should not be modified. The function returns
DRV_AK4642_BUFFER_EVENT_COMPLETE:
• if a buffer could not be allocated to the request
• if the input buffer pointer is NULL
• if the client opened the driver for read only or write only
• if the buffer size is 0
• if the queue is full or the queue depth is insufficient
If the requesting client registered an event callback with the driver, the driver will issue a DRV_AK4642_BUFFER_EVENT_COMPLETE event if
the buffer was processed successfully of DRV_AK4642_BUFFER_EVENT_ERROR event if the buffer was not processed successfully.
Remarks
This function is thread safe in a RTOS application. It can be called from within the AK4642 Driver Buffer Event Handler that is registered by this
client. It should not be called in the event handler associated with another AK4642 driver instance. It should not otherwise be called directly in an
ISR.
This function is useful when there is valid read expected for every AK4642 write. The transmit and receive size must be same.
Preconditions
The DRV_AK4642_Initialize routine must have been called for the specified AK4642 device instance and the DRV_AK4642_Status must have
returned SYS_STATUS_READY.
DRV_AK4642_Open must have been called to obtain a valid opened device handle.
DRV_IO_INTENT_READWRITE must have been specified in the DRV_AK4642_Open call.
Example
MY_APP_OBJ myAppObj;
uint8_t mybufferTx[MY_BUFFER_SIZE];
uint8_t mybufferRx[MY_BUFFER_SIZE];
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 184
DRV_AK4642_BUFFER_HANDLE bufferHandle;
// myak4642Handle is the handle returned
// by the DRV_AK4642_Open function.
// Client registers an event handler with driver
DRV_AK4642_BufferEventHandlerSet(myak4642Handle,
APP_AK4642BufferEventHandler, (uintptr_t)&myAppObj);
DRV_AK4642_BufferAddWriteRead(myak4642handle, &bufferHandle,
mybufferTx,mybufferRx,MY_BUFFER_SIZE);
if(DRV_AK4642_BUFFER_HANDLE_INVALID == bufferHandle)
{
// Error handling here
}
// Event is received when
// the buffer is processed.
void APP_AK4642BufferEventHandler(DRV_AK4642_BUFFER_EVENT event,
DRV_AK4642_BUFFER_HANDLE bufferHandle, uintptr_t contextHandle)
{
// contextHandle points to myAppObj.
switch(event)
{
case DRV_AK4642_BUFFER_EVENT_COMPLETE:
// This means the data was transferred.
break;
case DRV_AK4642_BUFFER_EVENT_ERROR:
// Error handling here.
break;
default:
break;
}
}
Parameters
Parameters Description
handle Handle of the AK4642 instance as returned by the DRV_AK4642_Open function
bufferHandle Pointer to an argument that will contain the return buffer handle
transmitBuffer The buffer where the transmit data will be stored
receiveBuffer The buffer where the received data will be stored
size Buffer size in bytes
Function
void DRV_AK4642_BufferAddWriteRead
(
const DRV_HANDLE handle,
DRV_AK4642_BUFFER_HANDLE *bufferHandle,
void *transmitBuffer,
void *receiveBuffer,
size_t size
)
DRV_AK4642_BufferEventHandlerSet Function
This function allows a client to identify a buffer event handling function for the driver to call back when queued buffer transfers have finished.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 185
File
drv_ak4642.h
C
void DRV_AK4642_BufferEventHandlerSet(DRV_HANDLE handle, const DRV_AK4642_BUFFER_EVENT_HANDLER
eventHandler, const uintptr_t contextHandle);
Returns
None.
Description
This function allows a client to identify a buffer event handling function for the driver to call back when queued buffer transfers have finished. When
a client calls DRV_AK4642_BufferAddWrite function, it is provided with a handle identifying the buffer that was added to the driver's buffer queue.
The driver will pass this handle back to the client by calling "eventHandler" function when the buffer transfer has completed.
The event handler should be set before the client performs any "buffer add" operations that could generate events. The event handler once set,
persists until the client closes the driver or sets another event handler (which could be a "NULL" pointer to indicate no callback).
Remarks
If the client does not want to be notified when the queued buffer transfer has completed, it does not need to register a callback.
Preconditions
The DRV_AK4642_Initialize routine must have been called for the specified AK4642 driver instance.
DRV_AK4642_Open must have been called to obtain a valid opened device handle.
Example
MY_APP_OBJ myAppObj;
uint8_t mybuffer[MY_BUFFER_SIZE];
DRV_AK4642_BUFFER_HANDLE bufferHandle;
// myAK4642Handle is the handle returned
// by the DRV_AK4642_Open function.
// Client registers an event handler with driver
DRV_AK4642_BufferEventHandlerSet(myAK4642Handle,
APP_AK4642BufferEventHandler, (uintptr_t)&myAppObj);
DRV_AK4642_BufferAddWrite(myAK4642handle, &bufferHandle
myBuffer, MY_BUFFER_SIZE);
if(DRV_AK4642_BUFFER_HANDLE_INVALID == bufferHandle)
{
// Error handling here
}
// Event is received when
// the buffer is processed.
void APP_AK4642BufferEventHandler(DRV_AK4642_BUFFER_EVENT event,
DRV_AK4642_BUFFER_HANDLE bufferHandle, uintptr_t contextHandle)
{
// contextHandle points to myAppObj.
switch(event)
{
case DRV_AK4642_BUFFER_EVENT_COMPLETE:
// This means the data was transferred.
break;
case DRV_AK4642_BUFFER_EVENT_ERROR:
// Error handling here.
break;
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 186
default:
break;
}
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
eventHandler Pointer to the event handler function.
context The value of parameter will be passed back to the client unchanged, when the eventHandler
function is called. It can be used to identify any client specific data object that identifies the
instance of the client module (for example, it may be a pointer to the client module's state
structure).
Function
void DRV_AK4642_BufferEventHandlerSet
(
DRV_HANDLE handle,
const DRV_AK4642_BUFFER_EVENT_HANDLER eventHandler,
const uintptr_t contextHandle
)
e) Other Functions
DRV_AK4642_CommandEventHandlerSet Function
This function allows a client to identify a command event handling function for the driver to call back when the last submitted command have
finished.
File
drv_ak4642.h
C
void DRV_AK4642_CommandEventHandlerSet(DRV_HANDLE handle, const DRV_AK4642_COMMAND_EVENT_HANDLER
eventHandler, const uintptr_t contextHandle);
Returns
None.
Description
This function allows a client to identify a command event handling function for the driver to call back when the last submitted command have
finished.
When a client calls DRV_AK4642_BufferAddWrite function, it is provided with a handle identifying the buffer that was added to the driver's buffer
queue. The driver will pass this handle back to the client by calling "eventHandler" function when the buffer transfer has completed.
The event handler should be set before the client performs any "AK4642 CODEC Specific Client Routines" operations that could generate events.
The event handler once set, persists until the client closes the driver or sets another event handler (which could be a "NULL" pointer to indicate no
callback).
Remarks
If the client does not want to be notified when the command has completed, it does not need to register a callback.
Preconditions
The DRV_AK4642_Initialize routine must have been called for the specified AK4642 driver instance.
DRV_AK4642_Open must have been called to obtain a valid opened device handle.
Example
MY_APP_OBJ myAppObj;
uint8_t mybuffer[MY_BUFFER_SIZE];
DRV_AK4642_BUFFER_HANDLE bufferHandle;
// myAK4642Handle is the handle returned
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 187
// by the DRV_AK4642_Open function.
// Client registers an event handler with driver
DRV_AK4642_CommandEventHandlerSet(myAK4642Handle,
APP_AK4642CommandEventHandler, (uintptr_t)&myAppObj);
DRV_AK4642_DeEmphasisFilterSet(myAK4642Handle, DRV_AK4642_DEEMPHASIS_FILTER_44_1KHZ)
// Event is received when
// the buffer is processed.
void APP_AK4642CommandEventHandler(uintptr_t contextHandle)
{
// contextHandle points to myAppObj.
switch(event)
{
// Last Submitted command is completed.
// Perform further processing here
}
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
eventHandler Pointer to the event handler function.
context The value of parameter will be passed back to the client unchanged, when the eventHandler
function is called. It can be used to identify any client specific data object that identifies the
instance of the client module (for example, it may be a pointer to the client module's state
structure).
Function
void DRV_AK4642_CommandEventHandlerSet
(
DRV_HANDLE handle,
const DRV_AK4642_COMMAND_EVENT_HANDLER eventHandler,
const uintptr_t contextHandle
)
DRV_AK4642_VersionGet Function
This function returns the version of AK4642 driver
File
drv_ak4642.h
C
uint32_t DRV_AK4642_VersionGet();
Returns
returns the version of AK4642 driver.
Description
The version number returned from the DRV_AK4642_VersionGet function is an unsigned integer in the following decimal format. * 10000 + * 100
+ Where the numbers are represented in decimal and the meaning is the same as above. Note that there is no numerical representation of
release type.
Remarks
None.
Preconditions
None.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 188
Example 1
For version "0.03a", return: 0 * 10000 + 3 * 100 + 0 For version "1.00", return: 1 * 100000 + 0 * 100 + 0
Example 2
uint32_t AK4642version;
AK4642version = DRV_AK4642_VersionGet();
Function
uint32_t DRV_AK4642_VersionGet( void )
DRV_AK4642_VersionStrGet Function
This function returns the version of AK4642 driver in string format.
File
drv_ak4642.h
C
int8_t* DRV_AK4642_VersionStrGet();
Returns
returns a string containing the version of AK4642 driver.
Description
The DRV_AK4642_VersionStrGet function returns a string in the format: ".[.][]" Where: is the AK4642 driver's version number. is the AK4642
driver's version number. is an optional "patch" or "dot" release number (which is not included in the string if it equals "00"). is an optional release
type ("a" for alpha, "b" for beta ? not the entire word spelled out) that is not included if the release is a production version (I.e. Not an alpha or beta).
The String does not contain any spaces. For example, "0.03a" "1.00"
Remarks
None
Preconditions
None.
Example
int8_t *AK4642string;
AK4642string = DRV_AK4642_VersionStrGet();
Function
int8_t* DRV_AK4642_VersionStrGet(void)
f) Data Types and Constants
_DRV_AK4642_H Macro
File
drv_ak4642.h
C
#define _DRV_AK4642_H
Description
Include files.
DRV_AK4642_BUFFER_HANDLE_INVALID Macro
Definition of an invalid buffer handle.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 189
File
drv_ak4642.h
C
#define DRV_AK4642_BUFFER_HANDLE_INVALID ((DRV_AK4642_BUFFER_HANDLE)(-1))
Description
AK4642 Driver Invalid Buffer Handle
This is the definition of an invalid buffer handle. An invalid buffer handle is returned by DRV_AK4642_BufferAddWrite() and the
DRV_AK4642_BufferAddRead() function if the buffer add request was not successful.
Remarks
None.
DRV_AK4642_COUNT Macro
Number of valid AK4642 driver indices
File
drv_ak4642.h
C
#define DRV_AK4642_COUNT
Description
AK4642 Driver Module Count
This constant identifies the maximum number of AK4642 Driver instances that should be defined by the application. Defining more instances than
this constant will waste RAM memory space.
This constant can also be used by the application to identify the number of AK4642 instances on this microcontroller.
Remarks
This value is part-specific.
DRV_AK4642_INDEX_0 Macro
AK4642 driver index definitions
File
drv_ak4642.h
C
#define DRV_AK4642_INDEX_0 0
Description
Driver AK4642 Module Index
These constants provide AK4642 driver index definition.
Remarks
These constants should be used in place of hard-coded numeric literals. These values should be passed into the DRV_AK4642_Initialize and
DRV_AK4642_Open routines to identify the driver instance in use.
DRV_AK4642_INDEX_1 Macro
File
drv_ak4642.h
C
#define DRV_AK4642_INDEX_1 1
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 190
Description
This is macro DRV_AK4642_INDEX_1.
DRV_AK4642_INDEX_2 Macro
File
drv_ak4642.h
C
#define DRV_AK4642_INDEX_2 2
Description
This is macro DRV_AK4642_INDEX_2.
DRV_AK4642_INDEX_3 Macro
File
drv_ak4642.h
C
#define DRV_AK4642_INDEX_3 3
Description
This is macro DRV_AK4642_INDEX_3.
DRV_AK4642_INDEX_4 Macro
File
drv_ak4642.h
C
#define DRV_AK4642_INDEX_4 4
Description
This is macro DRV_AK4642_INDEX_4.
DRV_AK4642_INDEX_5 Macro
File
drv_ak4642.h
C
#define DRV_AK4642_INDEX_5 5
Description
This is macro DRV_AK4642_INDEX_5.
DRV_AK4642_AUDIO_DATA_FORMAT Enumeration
Identifies the Serial Audio data interface format.
File
drv_ak4642.h
C
typedef enum {
DRV_AK4642_AUDIO_DATA_FORMAT_NOT_APPLICABLE = 0,
DRV_AK4642_AUDIO_DATA_FORMAT_16BITMSB_SDTO_16BITLSB_SDTI,
DRV_AK4642_AUDIO_DATA_FORMAT_16BITMSB_SDTO_16BITMSB_SDTI,
DRV_AK4642_AUDIO_DATA_FORMAT_I2S
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 191
} DRV_AK4642_AUDIO_DATA_FORMAT;
Description
AK4642 Audio data format
This enumeration identifies Serial Audio data interface format.
DRV_AK4642_BUFFER_EVENT Enumeration
Identifies the possible events that can result from a buffer add request.
File
drv_ak4642.h
C
typedef enum {
DRV_AK4642_BUFFER_EVENT_COMPLETE,
DRV_AK4642_BUFFER_EVENT_ERROR,
DRV_AK4642_BUFFER_EVENT_ABORT
} DRV_AK4642_BUFFER_EVENT;
Members
Members Description
DRV_AK4642_BUFFER_EVENT_COMPLETE Data was transferred successfully.
DRV_AK4642_BUFFER_EVENT_ERROR Error while processing the request
DRV_AK4642_BUFFER_EVENT_ABORT Data transfer aborted (Applicable in DMA mode)
Description
AK4642 Driver Events
This enumeration identifies the possible events that can result from a buffer add request caused by the client calling either the
DRV_AK4642_BufferAddWrite() or the DRV_AK4642_BufferAddRead() function.
Remarks
One of these values is passed in the "event" parameter of the event handling callback function that the client registered with the driver by calling
the DRV_AK4642_BufferEventHandlerSet function when a buffer transfer request is completed.
DRV_AK4642_BUFFER_EVENT_HANDLER Type
Pointer to a AK4642 Driver Buffer Event handler function
File
drv_ak4642.h
C
typedef void (* DRV_AK4642_BUFFER_EVENT_HANDLER)(DRV_AK4642_BUFFER_EVENT event, DRV_AK4642_BUFFER_HANDLE
bufferHandle, uintptr_t contextHandle);
Returns
None.
Description
AK4642 Driver Buffer Event Handler Function
This data type defines the required function signature for the AK4642 driver buffer event handling callback function. A client must register a pointer
to a buffer event handling function who's function signature (parameter and return value types) match the types specified by this function pointer in
order to receive buffer related event calls back from the driver.
The parameters and return values are described here and a partial example implementation is provided.
Remarks
If the event is DRV_AK4642_BUFFER_EVENT_COMPLETE, this means that the data was transferred successfully.
If the event is DRV_AK4642_BUFFER_EVENT_ERROR, this means that the data was not transferred successfully. The bufferHandle parameter
contains the buffer handle of the buffer that failed. The DRV_AK4642_BufferProcessedSizeGet() function can be called to find out how many bytes
were processed.
The bufferHandle parameter contains the buffer handle of the buffer that associated with the event.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 192
The context parameter contains a handle to the client context, provided at the time the event handling function was registered using the
DRV_AK4642_BufferEventHandlerSet function. This context handle value is passed back to the client as the "context" parameter. It can be any
value necessary to identify the client context or instance (such as a pointer to the client's data) instance of the client that made the buffer add
request.
The buffer handle in bufferHandle expires after this event handler exits. In that the buffer object that was allocated is deallocated by the driver after
the event handler exits.
The event handler function executes in the data driver(i2S) peripheral's interrupt context when the driver is configured for interrupt mode operation.
It is recommended of the application to not perform process intensive or blocking operations with in this function.
DRV_AK4642_BufferAddWrite function can be called in the event handler to add a buffer to the driver queue.
Example
void APP_MyBufferEventHandler( DRV_AK4642_BUFFER_EVENT event,
DRV_AK4642_BUFFER_HANDLE bufferHandle,
uintptr_t context )
{
MY_APP_DATA_STRUCT pAppData = (MY_APP_DATA_STRUCT) context;
switch(event)
{
case DRV_AK4642_BUFFER_EVENT_COMPLETE:
// Handle the completed buffer.
break;
case DRV_AK4642_BUFFER_EVENT_ERROR:
default:
// Handle error.
break;
}
}
Parameters
Parameters Description
event Identifies the type of event
bufferHandle Handle identifying the buffer to which the event relates
context Value identifying the context of the application that registered the event handling function.
DRV_AK4642_BUFFER_HANDLE Type
Handle identifying a write buffer passed to the driver.
File
drv_ak4642.h
C
typedef uintptr_t DRV_AK4642_BUFFER_HANDLE;
Description
AK4642 Driver Buffer Handle
A buffer handle value is returned by a call to the DRV_AK4642_BufferAddWrite() or DRV_AK4642_BufferAddRead() function. This handle is
associated with the buffer passed into the function and it allows the application to track the completion of the data from (or into) that buffer. The
buffer handle value returned from the "buffer add" function is returned back to the client by the "event handler callback" function registered with the
driver.
The buffer handle assigned to a client request expires when the client has been notified of the completion of the buffer transfer (after event handler
function that notifies the client returns) or after the buffer has been retired by the driver if no event handler callback was set.
Remarks
None
DRV_AK4642_CHANNEL Enumeration
Identifies Left/Right Audio channel
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 193
File
drv_ak4642.h
C
typedef enum {
DRV_AK4642_CHANNEL_LEFT,
DRV_AK4642_CHANNEL_RIGHT,
DRV_AK4642_CHANNEL_LEFT_RIGHT,
DRV_AK4642_NUMBER_OF_CHANNELS
} DRV_AK4642_CHANNEL;
Description
AK4642 Audio Channel
This enumeration identifies Left/Right Audio channel
Remarks
None.
DRV_AK4642_COMMAND_EVENT_HANDLER Type
Pointer to a AK4642 Driver Command Event Handler Function
File
drv_ak4642.h
C
typedef void (* DRV_AK4642_COMMAND_EVENT_HANDLER)(uintptr_t contextHandle);
Returns
None.
Description
AK4642 Driver Command Event Handler Function
This data type defines the required function signature for the AK4642 driver command event handling callback function.
A command is a control instruction to the AK4642 CODEC. Example Mute ON/OFF, Zero Detect Enable/Disable etc.
A client must register a pointer to a command event handling function who's function signature (parameter and return value types) match the types
specified by this function pointer in order to receive command related event calls back from the driver.
The parameters and return values are described here and a partial example implementation is provided.
Remarks
The occurrence of this call back means that the last control command was transferred successfully.
The context parameter contains a handle to the client context, provided at the time the event handling function was registered using the
DRV_AK4642_CommandEventHandlerSet function. This context handle value is passed back to the client as the "context" parameter. It can be
any value necessary to identify the client context or instance (such as a pointer to the client's data) instance of the client that made the buffer add
request.
The event handler function executes in the control data driver interrupt context. It is recommended of the application to not perform process
intensive or blocking operations with in this function.
Example
void APP_AK4642CommandEventHandler( uintptr_t context )
{
MY_APP_DATA_STRUCT pAppData = (MY_APP_DATA_STRUCT) context;
// Last Submitted command is completed.
// Perform further processing here
}
Parameters
Parameters Description
context Value identifying the context of the application that registered the event handling function.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 194
DRV_AK4642_INIT Structure
Defines the data required to initialize or reinitialize the AK4642 driver
File
drv_ak4642.h
C
typedef struct {
SYS_MODULE_INIT moduleInit;
SYS_MODULE_INDEX i2sDriverModuleIndex;
SYS_MODULE_INDEX i2cDriverModuleIndex;
uint32_t samplingRate;
uint8_t volume;
DRV_AK4642_AUDIO_DATA_FORMAT audioDataFormat;
} DRV_AK4642_INIT;
Members
Members Description
SYS_MODULE_INIT moduleInit; System module initialization
SYS_MODULE_INDEX i2sDriverModuleIndex; Identifies data module(I2S) driver ID for data interface of CODEC
SYS_MODULE_INDEX i2cDriverModuleIndex; Identifies data module(I2C) driver ID for control interface of CODEC
uint32_t samplingRate; Sampling rate
uint8_t volume; Volume
DRV_AK4642_AUDIO_DATA_FORMAT
audioDataFormat;
Identifies the Audio data format
Description
AK4642 Driver Initialization Data
This data type defines the data required to initialize or reinitialize the AK4642 CODEC driver.
Remarks
None.
DRV_AK4642_INT_EXT_MIC Enumeration
Identifies the Mic input source.
File
drv_ak4642.h
C
typedef enum {
INT_MIC,
EXT_MIC
} DRV_AK4642_INT_EXT_MIC;
Description
AK4642 Mic Internal / External Input
This enumeration identifies the Mic input source.
DRV_AK4642_MONO_STEREO_MIC Enumeration
Identifies the Mic input as Mono / Stereo.
File
drv_ak4642.h
C
typedef enum {
ALL_ZEROS,
MONO_RIGHT_CHANNEL,
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 195
MONO_LEFT_CHANNEL,
STEREO
} DRV_AK4642_MONO_STEREO_MIC;
Description
AK4642 Mic Mono / Stereo Input
This enumeration identifies the Mic input as Mono / Stereo.
DRV_AK4642_MIC Enumeration
File
drv_ak4642.h
C
typedef enum {
MIC1 = 0,
MIC2,
DRV_AK4642_NUMBER_MIC
} DRV_AK4642_MIC;
Members
Members Description
MIC1 = 0 INT_MIC
MIC2 EXT_MIC
Description
This is type DRV_AK4642_MIC.
Files
Files
Name Description
drv_ak4642.h AK4642 CODEC Driver Interface header file
drv_ak4642_config_template.h AK4642 Codec Driver Configuration Template.
Description
This section lists the source and header files used by the AK4642 Codec Driver Library.
drv_ak4642.h
AK4642 CODEC Driver Interface header file
Enumerations
Name Description
DRV_AK4642_AUDIO_DATA_FORMAT Identifies the Serial Audio data interface format.
DRV_AK4642_BUFFER_EVENT Identifies the possible events that can result from a buffer add request.
DRV_AK4642_CHANNEL Identifies Left/Right Audio channel
DRV_AK4642_INT_EXT_MIC Identifies the Mic input source.
DRV_AK4642_MIC This is type DRV_AK4642_MIC.
DRV_AK4642_MONO_STEREO_MIC Identifies the Mic input as Mono / Stereo.
Functions
Name Description
DRV_AK4642_BufferAddRead Schedule a non-blocking driver read operation.
DRV_AK4642_BufferAddWrite Schedule a non-blocking driver write operation.
DRV_AK4642_BufferAddWriteRead Schedule a non-blocking driver write-read operation.
Implementation: Dynamic
DRV_AK4642_BufferEventHandlerSet This function allows a client to identify a buffer event handling function for the driver
to call back when queued buffer transfers have finished.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 196
DRV_AK4642_Close Closes an opened-instance of the AK4642 driver
DRV_AK4642_CommandEventHandlerSet This function allows a client to identify a command event handling function for the
driver to call back when the last submitted command have finished.
DRV_AK4642_Deinitialize Deinitializes the specified instance of the AK4642 driver module
DRV_AK4642_Initialize Initializes hardware and data for the instance of the AK4642 DAC module
DRV_AK4642_IntExtMicSet This function sets up the codec for the internal or the external microphone use.
DRV_AK4642_MicSet This function select the single-ended AK4642 microphone input for the AK4642
Codec
DRV_AK4642_MonoStereoMicSet This function sets up the codec for the Mono or Stereo microphone mode.
DRV_AK4642_MuteOff This function disables AK4642 output for soft mute.
DRV_AK4642_MuteOn This function allows AK4642 output for soft mute on.
DRV_AK4642_Open Opens the specified AK4642 driver instance and returns a handle to it
DRV_AK4642_SamplingRateGet This function gets the sampling rate set on the AK4642.
Implementation: Dynamic
DRV_AK4642_SamplingRateSet This function sets the sampling rate of the media stream.
DRV_AK4642_SetAudioCommunicationMode This function provides a run time audio format configuration
DRV_AK4642_Status Gets the current status of the AK4642 driver module.
DRV_AK4642_Tasks Maintains the driver's control and data interface state machine.
DRV_AK4642_VersionGet This function returns the version of AK4642 driver
DRV_AK4642_VersionStrGet This function returns the version of AK4642 driver in string format.
DRV_AK4642_VolumeGet This function gets the volume for AK4642 CODEC.
DRV_AK4642_VolumeSet This function sets the volume for AK4642 CODEC.
Macros
Name Description
_DRV_AK4642_H Include files.
DRV_AK4642_BUFFER_HANDLE_INVALID Definition of an invalid buffer handle.
DRV_AK4642_COUNT Number of valid AK4642 driver indices
DRV_AK4642_INDEX_0 AK4642 driver index definitions
DRV_AK4642_INDEX_1 This is macro DRV_AK4642_INDEX_1.
DRV_AK4642_INDEX_2 This is macro DRV_AK4642_INDEX_2.
DRV_AK4642_INDEX_3 This is macro DRV_AK4642_INDEX_3.
DRV_AK4642_INDEX_4 This is macro DRV_AK4642_INDEX_4.
DRV_AK4642_INDEX_5 This is macro DRV_AK4642_INDEX_5.
Structures
Name Description
DRV_AK4642_INIT Defines the data required to initialize or reinitialize the AK4642 driver
Types
Name Description
DRV_AK4642_BUFFER_EVENT_HANDLER Pointer to a AK4642 Driver Buffer Event handler function
DRV_AK4642_BUFFER_HANDLE Handle identifying a write buffer passed to the driver.
DRV_AK4642_COMMAND_EVENT_HANDLER Pointer to a AK4642 Driver Command Event Handler Function
Description
AK4642 CODEC Driver Interface
The AK4642 CODEC device driver interface provides a simple interface to manage the AK4642 16/24-Bit CODEC that can be interfaced Microchip
Microcontroller. This file provides the interface definition for the AK4642 CODEC device driver.
File Name
drv_ak4642.h
Company
Microchip Technology Inc.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 197
drv_ak4642_config_template.h
AK4642 Codec Driver Configuration Template.
Macros
Name Description
DRV_AK4642_BCLK_BIT_CLK_DIVISOR Sets up the BCLK to LRCK Ratio to Generate Audio Stream for specified
sampling frequency
DRV_AK4642_CLIENTS_NUMBER Sets up the maximum number of clients that can be connected to any
hardware instance.
DRV_AK4642_INPUT_REFCLOCK Identifies the input REFCLOCK source to generate the MCLK to codec.
DRV_AK4642_INSTANCES_NUMBER Sets up the maximum number of hardware instances that can be supported
DRV_AK4642_MCLK_SAMPLE_FREQ_MULTPLIER Sets up the MCLK to LRCK Ratio to Generate Audio Stream for specified
sampling frequency
DRV_AK4642_MCLK_SOURCE Indicate the input clock frequency to generate the MCLK to codec.
Description
AK4642 Codec Driver Configuration Template
These file provides the list of all the configurations that can be used with the driver. This file should not be included in the driver.
File Name
drv_ak4642_config_template.h
Company
Microchip Technology Inc.
AK4953 Codec Driver Library
This topic describes the AK4953 Codec Driver Library.
Introduction
This library provides an interface to manage the AK4953 Codec that is serially interfaced to a Microchip microcontroller for providing Audio
Solutions.
Description
The AK4953 module is 16/24-bit Audio Codec from Asahi Kasei Microdevices Corporation. The AK4953 can be interfaced to Microchip
microcontrollers through I2C and I2S serial interfaces. The I2C interface is used for control command transfer. The I2S interface is used for Audio
data output.
A typical interface of AK4953 to a Microchip PIC32 device is provided in the following diagram:
Features
The AK4953 Codec supports the following features:
• Audio Interface Format: MSB first
• ADC: 24-bit MSB justified, 16/24-bit I2S
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 198
• DAC: 24-bit MSB justified, 1-6bit LSB justified, 24-bit LSB justified, 16/24-bit I2S
• Sampling Frequency Range: 8 kHz to 192 kHz
• Digital Volume Control: +12dB ~ .115dB, 0.5dB Step
• SoftMute: On and Off
• Master Clock Frequencies: 32 fs/64 fs/128 fs/256 fs
Using the Library
This topic describes the basic architecture of the AK4953 Codec Driver Library and provides information and examples on its use.
Description
Interface Header File: drv_AK4953.h
The interface to the AK4953 Codec Driver library is defined in the drv_AK4953.h header file. Any C language source (.c) file that uses the
AK4953 Codec Driver library should include this header.
Please refer to the What is MPLAB Harmony? section for how the driver interacts with the framework.
Library Overview
Refer to the Driver Library Overview section for information on how the driver operates in a system.
The AK4953 Codec Driver Library provides an API interface to transfer control commands and digital audio data to the serially interfaced AK4953
DAC module. The library interface routines are divided into various sub-sections, which address one of the blocks or the overall operation of the
AK4953 Codec Driver Library.
Library Interface Section Description
System Functions Provides system module interfaces, device initialization, deinitialization,
reinitialization, tasks and status functions.
Status Functions Provides status functions.
Other Functions Provides driver specific miscellaneous functions such as sampling rate setting, control
command functions, etc.
Data Types and Constants These data types and constants are required while interacting and setting up the
AK4953 Codec Driver Library.
Abstraction Model
This library provides a low-level abstraction of the AK4953 Codec Driver Library on the Microchip family microcontrollers with a convenient C
language interface. This topic describes how that abstraction is modeled in software and introduces the library's interface.
Description
The abstraction model shown in the following diagram depicts how the AK4953 Codec Driver is positioned in the MPLAB Harmony framework. The
AK4953 Codec Driver uses the SPI and I2S drivers for control and audio data transfers to the AK4953 module.
AK4953 Driver Abstraction Model
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 199
How the Library Works
The library provides interfaces to support:
• System Functionality
• Client Functionality
System Access
This topic describes system initialization, implementations, and includes a system access code example.
Description
System Initialization
The system performs the initialization of the device driver with settings that affect only the instance of the device that is being initialized. During
system initialization, each instance of the AK4953 module would be initialized with the following configuration settings (either passed dynamically
at run time using DRV_AK4953_INIT or by using Initialization Overrides) that are supported by the specific AK4953 device hardware:
• Device requested power state: one of the System Module Power States. For specific details please refer to Data Types and Constants in the
Library Interface section.
• I2C driver module index. The module index should be same as the one used in initializing the I2C Driver.
• I2S driver module index. The module index should be same as the one used in initializing the I2S Driver.
• Sampling rate
• Audio data format. The audio data format should match with the audio data format settings done in I2S driver initialization
• Power down pin port initialization
• Queue size for the audio data transmit buffer
The DRV_AK4953_Initialize API returns an object handle of the type SYS_MODULE_OBJ. The object handle returned by the Initialize interface
would be used by the other system interfaces such as DRV_ AK4953_Deinitialize, DRV_ AK4953_Status and DRV_I2S_Tasks.
Implementations
The AK4953 Codec Driver can has the following implementation:
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 200
Description MPLAB Harmony Components
Dedicated hardware for control (I2C) and data (I2S) interface. Standard MPLAB Harmony drivers for I2C and I2S interfaces.
Example:
DRV_AK4953_INIT drvak4953Codec0InitData =
{
.moduleInit.value = SYS_MODULE_POWER_RUN_FULL,
.i2sDriverModuleIndex = DRV_AK4953_I2S_DRIVER_MODULE_INDEX_IDX0,
.i2cDriverModuleIndex = DRV_AK4953_I2C_DRIVER_MODULE_INDEX_IDX0,
.volume = DRV_AK4953_VOLUME,
.queueSizeTransmit = DRV_AK4953_TRANSMIT_QUEUE_SIZE,
};
// Initialize the I2C driver
DRV_I2C0_Initialize();
// Initialize the I2S driver. The I2S module index should be same as the one used in initializing
// the I2S driver.
sysObj.drvI2S0 = DRV_I2S_Initialize(DRV_I2S_INDEX_0, (SYS_MODULE_INIT *)&drvI2S0InitData);
// Initialize the Codec driver
sysObj.drvak4953Codec0 = DRV_AK4953_Initialize(DRV_AK4953_INDEX_0, (SYS_MODULE_INIT
*)&drvak4953Codec0InitData);
if (SYS_MODULE_OBJ_INVALID == AK4953DevObject)
{
// Handle error
}
Task Routine
The DRV_AK4953_Tasks will be called from the System Task Service.
Client Access
For the application to start using an instance of the module, it must call the DRV_AK4953_Open function. The DRV_AK4953_Open provides a
driver handle to the AK4953 Codec Driver instance for operations. If the driver is deinitialized using the function DRV_AK4953_Deinitialize, the
application must call the DRV_AK4953_Open function again to set up the instance of the driver.
For the various options available for IO_INTENT, please refer to Data Types and Constants in the Library Interface section.
Client Operations
This topic provides information on client operations and includes a control command and audio buffered data operation flow diagram.
Description
Client operations provide the API interface for control command and audio data transfer to the AK4953 Codec.
The following AK4953 Codec specific control command functions are provided:
• DRV_AK4953_SamplingRateSet
• DRV_AK4953_SamplingRateGet
• DRV_AK4953_VolumeSet
• DRV_AK4953_VolumeGet
• DRV_AK4953_MuteOn
• DRV_AK4953_MuteOff
• DRV_AK4953_IntExtMicSet
• DRV_AK4953_MonoStereoMicSet
These functions schedule a non-blocking control command transfer operation. These functions submit the control command request to the AK4953
Codec. These functions submit the control command request to I2C Driver transmit queue, the request is processed immediately if it is the first
request, or processed when the previous request is complete.
DRV_AK4953_BufferAddWrite, DRV_AK4953_BufferAddRead, and DRV_AK4953_BufferAddWriteRead are buffered data operation functions.
These functions schedule non-blocking audio data transfer operations. These functions add the request to I2S Driver transmit or receive buffer
queue depends on the request type, and are executed immediately if it is the first buffer, or executed later when the previous buffer is complete.
The driver notifies the client with DRV_AK4953_BUFFER_EVENT_COMPLETE, DRV_AK4953_BUFFER_EVENT_ERROR, or
DRV_AK4953_BUFFER_EVENT_ABORT events.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 201
The following diagram illustrates the control commands and audio buffered data operations.
Note:
It is not necessary to close and reopen the client between multiple transfers.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 202
Configuring the Library
Macros
Name Description
DRV_AK4953_BCLK_BIT_CLK_DIVISOR Sets up the BCLK to LRCK Ratio to Generate Audio Stream for specified
sampling frequency
DRV_AK4953_CLIENTS_NUMBER Sets up the maximum number of clients that can be connected to any
hardware instance.
DRV_AK4953_INPUT_REFCLOCK Identifies the input REFCLOCK source to generate the MCLK to codec.
DRV_AK4953_INSTANCES_NUMBER Sets up the maximum number of hardware instances that can be supported
DRV_AK4953_MCLK_SAMPLE_FREQ_MULTPLIER Sets up the MCLK to LRCK Ratio to Generate Audio Stream for specified
sampling frequency
DRV_AK4953_MCLK_SOURCE Indicate the input clock frequency to generate the MCLK to codec.
DRV_AK4953_QUEUE_DEPTH_COMBINED Number of entries of all queues in all instances of the driver.
Description
The configuration of the AK4953 Codec Driver is based on the file system_config.h.
This header file contains the configuration selection for the AK4953 Codec Driver. Based on the selections made, the driver may support the
selected features. These configuration settings will apply to all instances of the AK4953 Codec Driver.
This header can be placed anywhere, the path of this header needs to be present in the include search path for a successful build. Refer to the
Applications Help section for more details.
DRV_AK4953_BCLK_BIT_CLK_DIVISOR Macro
Sets up the BCLK to LRCK Ratio to Generate Audio Stream for specified sampling frequency
File
drv_ak4953_config_template.h
C
#define DRV_AK4953_BCLK_BIT_CLK_DIVISOR
Description
AK4953 BCLK to LRCK Ratio to Generate Audio Stream
Sets up the BCLK to LRCK Ratio to Generate Audio Stream for specified sampling frequency
Following BCLK to LRCK ratios are supported 16bit data 16 bit channel :- 32fs, hence divisor would be 8 16bit data 32 bit channel :- 64fs, hence
divisor would be 4
Remarks
None.
DRV_AK4953_CLIENTS_NUMBER Macro
Sets up the maximum number of clients that can be connected to any hardware instance.
File
drv_ak4953_config_template.h
C
#define DRV_AK4953_CLIENTS_NUMBER DRV_AK4953_INSTANCES_NUMBER
Description
AK4953 Client Count Configuration
Sets up the maximum number of clients that can be connected to any hardware instance. Typically only one client could be connected to one
hardware instance. This value represents the total number of clients to be supported across all hardware instances. Therefore, if there are five
AK4953 hardware interfaces, this number will be 5.
Remarks
None.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 203
DRV_AK4953_INPUT_REFCLOCK Macro
Identifies the input REFCLOCK source to generate the MCLK to codec.
File
drv_ak4953_config_template.h
C
#define DRV_AK4953_INPUT_REFCLOCK
Description
AK4953 Input reference clock
Identifies the input REFCLOCK source to generate the MCLK to codec.
Remarks
None.
DRV_AK4953_INSTANCES_NUMBER Macro
Sets up the maximum number of hardware instances that can be supported
File
drv_ak4953_config_template.h
C
#define DRV_AK4953_INSTANCES_NUMBER
Description
AK4953 driver objects configuration
Sets up the maximum number of hardware instances that can be supported. It is recommended that this number be set exactly equal to the
number of AK4953 CODEC modules that are needed by the application. Hardware Instance support consumes RAM memory space. If this macro
is not defined, then the driver will be built statically.
Remarks
None.
DRV_AK4953_MCLK_SAMPLE_FREQ_MULTPLIER Macro
Sets up the MCLK to LRCK Ratio to Generate Audio Stream for specified sampling frequency
File
drv_ak4953_config_template.h
C
#define DRV_AK4953_MCLK_SAMPLE_FREQ_MULTPLIER
Description
AK4953 MCLK to LRCK Ratio to Generate Audio Stream
Sets up the MCLK to LRCK Ratio to Generate Audio Stream for specified sampling frequency I2S sampling frequency
Supported MCLK to Sampling frequency Ratios are as below 256fs, 384fs, 512fs, 768fs or 1152fs
Remarks
None
DRV_AK4953_MCLK_SOURCE Macro
Indicate the input clock frequency to generate the MCLK to codec.
File
drv_ak4953_config_template.h
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 204
C
#define DRV_AK4953_MCLK_SOURCE
Description
AK4953 Data Interface Master Clock Speed configuration
Indicate the input clock frequency to generate the MCLK to codec.
Remarks
None.
DRV_AK4953_QUEUE_DEPTH_COMBINED Macro
Number of entries of all queues in all instances of the driver.
File
drv_ak4953_config_template.h
C
#define DRV_AK4953_QUEUE_DEPTH_COMBINED
Description
AK4953 Driver Buffer Queue Entries
This macro defined the number of entries of all queues in all instances of the driver.
Each hardware instance supports a buffer queue for transmit operations. The size of queue is specified either in driver initialization (for dynamic
build) or by macros (for static build). The hardware instance transmit buffer queue will queue transmit buffers submitted by the
DRV_AK4953_BufferAddWrite function.
A buffer queue will contains buffer queue entries, each related to a BufferAdd request. This configuration macro defines total number of buffer
entries that will be available for use between all AK4953 driver hardware instances. The buffer queue entries are allocated to individual hardware
instances as requested by hardware instances. Once the request is processed, the buffer queue entry is free for use by other hardware instances.
The total number of buffer entries in the system determines the ability of the driver to service non blocking write requests. If a free buffer entry is
not available, the driver will not add the request and will return an invalid buffer handle. More the number of buffer entries, greater the ability of the
driver to service and add requests to its queue. A hardware instance additionally can queue up as many buffer entries as specified by its transmit
buffer queue size.
As an example, consider the case of static single client driver application where full duplex non blocking operation is desired without queuing, the
minimum transmit queue depth and minimum receive queue depth should be 1. Hence the total number of buffer entries should be 2.
As an example, consider the case of a dynamic driver (say two instances) where instance one will queue up to three write requests and up to two
read requests, and instance two will queue up to two write requests and up to six read requests, the value of this macro should be 13 (2 + 3 + 2 +
6).
Configuring the MHC
Provides examples on how to configure the MPLAB Harmony Configurator (MHC) for a specific driver.
Description
The following three figures show examples of MHC configurations for the AK4953 Codec Driver, I2S Driver, and the I2C Driver.
Figure 1: AK4953 Codec Driver MHC Configuration
Figure 2: I2S Driver MHC Configuration
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 205
Figure 3: I2C Driver MHC Configuration
Migrating the AK4953 Driver From Earlier Versions of Microchip Harmony
Prior to version 1.08 of MPLAB Harmony, the AK4953 Codec Driver Library used the static I2C driver implementation. Beginning with v1.08 of
MPLAB Harmony, applications must use the Dynamic Driver implementation with the MHC configured as shown in Figure 3. In addition, PIC32MZ
configurations require the "Include Force Write I2C Function (Master Mode Only - Ignore NACK from Slave)" option to be selected.
Building the Library
This section lists the files that are available in the AK4953 Codec Driver Library.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 206
Description
This section list the files that are available in the /src folder of the AK4953 Codec Driver. It lists which files need to be included in the build based
on either a hardware feature present on the board or configuration option selected by the system.
The following three tables list and describe the header (.h) and source (.c) files that implement this library. The parent folder for these files is
/framework/driver/codec/ak4953.
Interface File(s)
This table lists and describes the header files that must be included (i.e., using #include) by any code that uses this library.
Source File Name Description
/drv_ak4953.h Header file that exports the driver API.
Required File(s)
All of the required files listed in the following table are automatically added into the MPLAB X IDE project by the MHC
when the library is selected for use.
This table lists and describes the source and header files that must always be included in the MPLAB X IDE project to build this library.
Source File Name Description
/src/dynamic/drv_ak4953.c This file contains implementation of the AK4953 Codec Driver.
Optional File(s)
This table lists and describes the source and header files that may optionally be included if required for the desired implementation.
Source File Name Description
N/A No optional files are available for this library.
Module Dependencies
The AK4953 Codec Driver Library depends on the following modules:
• I2S Driver Library
• I2C Driver Library
Library Interface
a) System Interaction Functions
Name Description
DRV_AK4953_Initialize Initializes hardware and data for the instance of the AK4953 DAC module.
Implementation: Dynamic
DRV_AK4953_Deinitialize Deinitializes the specified instance of the AK4953 driver module.
Implementation: Dynamic
DRV_AK4953_Open Opens the specified AK4953 driver instance and returns a handle to it.
Implementation: Dynamic
DRV_AK4953_Close Closes an opened-instance of the AK4953 driver.
Implementation: Dynamic
DRV_AK4953_Tasks Maintains the driver's control and data interface state machine.
Implementation: Dynamic
DRV_AK4953_CommandEventHandlerSet This function allows a client to identify a command event handling function for the
driver to call back when the last submitted command have finished.
Implementation: Dynamic
DRV_AK4953_BufferEventHandlerSet This function allows a client to identify a buffer event handling function for the driver
to call back when queued buffer transfers have finished.
DRV_AK4953_SamplingRateSet This function sets the sampling rate of the media stream.
Implementation: Dynamic
DRV_AK4953_SetAudioCommunicationMode This function provides a run time audio format configuration
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 207
b) Status Functions
Name Description
DRV_AK4953_SamplingRateGet This function gets the sampling rate set on the DAC AK4953.
Implementation: Dynamic
DRV_AK4953_Status Gets the current status of the AK4953 driver module.
Implementation: Dynamic
DRV_AK4953_VersionGet This function returns the version of AK4953 driver.
Implementation: Dynamic
DRV_AK4953_VersionStrGet This function returns the version of AK4953 driver in string format.
Implementation: Dynamic
DRV_AK4953_VolumeGet This function gets the volume for AK4953 CODEC.
Implementation: Dynamic
c) Other Functions
Name Description
DRV_AK4953_BufferAddWrite Schedule a non-blocking driver write operation.
Implementation: Dynamic
DRV_AK4953_BufferAddWriteRead Schedule a non-blocking driver write-read operation.
Implementation: Dynamic
DRV_AK4953_MuteOff This function disables AK4953 output for soft mute.
Implementation: Dynamic
DRV_AK4953_MuteOn This function allows AK4953 output for soft mute on.
Implementation: Dynamic
DRV_AK4953_VolumeSet This function sets the volume for AK4953 CODEC.
Implementation: Dynamic
DRV_AK4953_BufferAddRead Schedule a non-blocking driver read operation.
DRV_AK4953_IntExtMicSet This function sets up the codec for the X32 DB internal or the external microphone use.
DRV_AK4953_MonoStereoMicSet This function sets up the codec for the Mono or Stereo microphone mode.
DRV_AK4953_MicSet This function sets up the codec for the internal or the AK4953 Mic1 or Mic2 input.
d) Data Types and Constants
Name Description
DRV_AK4953_AUDIO_DATA_FORMAT Identifies the Serial Audio data interface format.
DRV_AK4953_BUFFER_EVENT Identifies the possible events that can result from a buffer add request.
DRV_AK4953_BUFFER_EVENT_HANDLER Pointer to a AK4953 Driver Buffer Event handler function
DRV_AK4953_BUFFER_HANDLE Handle identifying a write buffer passed to the driver.
DRV_AK4953_COMMAND_EVENT_HANDLER Pointer to a AK4953 Driver Command Event Handler Function
DRV_AK4953_DIGITAL_BLOCK_CONTROL Identifies Bass-Boost Control function
DRV_AK4953_INIT Defines the data required to initialize or reinitialize the AK4953 driver
_DRV_AK4953_H Include files.
DRV_AK4953_BUFFER_HANDLE_INVALID Definition of an invalid buffer handle.
DRV_AK4953_COUNT Number of valid AK4953 driver indices
DRV_AK4953_INDEX_0 AK4953 driver index definitions
DRV_AK4953_INDEX_1 This is macro DRV_AK4953_INDEX_1.
DRV_AK4953_INDEX_2 This is macro DRV_AK4953_INDEX_2.
DRV_AK4953_INDEX_3 This is macro DRV_AK4953_INDEX_3.
DRV_AK4953_INDEX_4 This is macro DRV_AK4953_INDEX_4.
DRV_AK4953_INDEX_5 This is macro DRV_AK4953_INDEX_5.
DRV_AK4953_CHANNEL Identifies Left/Right Audio channel
DRV_AK4953_INT_EXT_MIC Identifies the Mic input source.
DRV_AK4953_MONO_STEREO_MIC Identifies the Mic input as Mono / Stereo.
DRV_AK4953_MIC This is type DRV_AK4953_MIC.
Description
This section describes the API functions of the AK4953 Codec Driver library.
Refer to each section for a detailed description.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 208
a) System Interaction Functions
DRV_AK4953_Initialize Function
Initializes hardware and data for the instance of the AK4953 DAC module.
Implementation: Dynamic
File
drv_ak4953.h
C
SYS_MODULE_OBJ DRV_AK4953_Initialize(const SYS_MODULE_INDEX drvIndex, const SYS_MODULE_INIT * const init);
Returns
If successful, returns a valid handle to a driver instance object. Otherwise, it returns SYS_MODULE_OBJ_INVALID.
Description
This routine initializes the AK4953 driver instance for the specified driver index, making it ready for clients to open and use it. The initialization data
is specified by the init parameter. The initialization may fail if the number of driver objects allocated are insufficient or if the specified driver instance
is already initialized.
Remarks
This routine must be called before any other AK4953 routine is called.
This routine should only be called once during system initialization unless DRV_AK4953_Deinitialize is called to deinitialize the driver instance.
This routine will NEVER block for hardware access.
Preconditions
DRV_I2S_Initialize must be called before calling this function to initialize the data interface of this CODEC driver. Also DRV_I2C_Initialize must be
called before calling this function to initialize the control interface of this CODEC driver.
Example
DRV_AK4953_INIT init;
SYS_MODULE_OBJ objectHandle;
init->inUse = true;
init->status = SYS_STATUS_BUSY;
init->numClients = 0;
init->i2sDriverModuleIndex = ak4953Init->i2sDriverModuleIndex;
init->i2cDriverModuleIndex = ak4953Init->i2cDriverModuleIndex;
init->samplingRate = DRV_AK4953_AUDIO_SAMPLING_RATE;
init->audioDataFormat = DRV_AK4953_AUDIO_DATA_FORMAT_MACRO;
for(index=0; index < DRV_AK4953_NUMBER_OF_CHANNELS; index++)
{
init->volume[index] = ak4953Init->volume;
}
init->isInInterruptContext = false;
init->commandCompleteCallback = (DRV_AK4953_COMMAND_EVENT_HANDLER)0;
init->commandContextData = 0;
init->mclk_multiplier = DRV_AK4953_MCLK_SAMPLE_FREQ_MULTPLIER;
objectHandle = DRV_AK4953_Initialize(DRV_AK4953_0, (SYS_MODULE_INIT*)init);
if (SYS_MODULE_OBJ_INVALID == objectHandle)
{
// Handle error
}
Parameters
Parameters Description
drvIndex Identifier for the driver instance to be initialized
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 209
init Pointer to the data structure containing any data necessary to initialize the hardware. This
pointer may be null if no data is required and default initialization is to be used.
Function
SYS_MODULE_OBJ DRV_AK4953_Initialize
(
const SYS_MODULE_INDEX drvIndex,
const SYS_MODULE_INIT *const init
);
DRV_AK4953_Deinitialize Function
Deinitializes the specified instance of the AK4953 driver module.
Implementation: Dynamic
File
drv_ak4953.h
C
void DRV_AK4953_Deinitialize(SYS_MODULE_OBJ object);
Returns
None.
Description
Deinitializes the specified instance of the AK4953 driver module, disabling its operation (and any hardware). Invalidates all the internal data.
Remarks
Once the Initialize operation has been called, the De-initialize operation must be called before the Initialize operation can be called again. This
routine will NEVER block waiting for hardware.
Preconditions
Function DRV_AK4953_Initialize should have been called before calling this function.
Example
SYS_MODULE_OBJ object; // Returned from DRV_AK4953_Initialize
SYS_STATUS status;
DRV_AK4953_Deinitialize(object);
status = DRV_AK4953_Status(object);
if (SYS_MODULE_DEINITIALIZED != status)
{
// Check again later if you need to know
// when the driver is deinitialized.
}
Parameters
Parameters Description
object Driver object handle, returned from the DRV_AK4953_Initialize routine
Function
void DRV_AK4953_Deinitialize( SYS_MODULE_OBJ object)
DRV_AK4953_Open Function
Opens the specified AK4953 driver instance and returns a handle to it.
Implementation: Dynamic
File
drv_ak4953.h
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 210
C
DRV_HANDLE DRV_AK4953_Open(const SYS_MODULE_INDEX iDriver, const DRV_IO_INTENT ioIntent);
Returns
If successful, the routine returns a valid open-instance handle (a number identifying both the caller and the module instance).
If an error occurs, the return value is DRV_HANDLE_INVALID. Error can occur
• if the number of client objects allocated via DRV_AK4953_CLIENTS_NUMBER is insufficient.
• if the client is trying to open the driver but driver has been opened exclusively by another client.
• if the driver hardware instance being opened is not initialized or is invalid.
• if the ioIntent options passed are not relevant to this driver.
Description
This routine opens the specified AK4953 driver instance and provides a handle that must be provided to all other client-level operations to identify
the caller and the instance of the driver. The ioIntent parameter defines how the client interacts with this driver instance.
The DRV_IO_INTENT_BLOCKING and DRV_IO_INTENT_NONBLOCKING ioIntent options are not relevant to this driver. All the data transfer
functions of this driver are non blocking.
AK4953 can be opened with DRV_IO_INTENT_WRITE, or DRV_IO_INTENT_READ or DRV_IO_INTENT_WRITEREAD io_intent option. This
decides whether the driver is used for headphone output, or microphone input or both modes simultaneously.
Specifying a DRV_IO_INTENT_EXCLUSIVE will cause the driver to provide exclusive access to this client. The driver cannot be opened by any
other client.
Remarks
The handle returned is valid until the DRV_AK4953_Close routine is called. This routine will NEVER block waiting for hardware.If the requested
intent flags are not supported, the routine will return DRV_HANDLE_INVALID. This function is thread safe in a RTOS application. It should not be
called in an ISR.
Preconditions
Function DRV_AK4953_Initialize must have been called before calling this function.
Example
DRV_HANDLE handle;
handle = DRV_AK4953_Open(DRV_AK4953_INDEX_0, DRV_IO_INTENT_WRITEREAD | DRV_IO_INTENT_EXCLUSIVE);
if (DRV_HANDLE_INVALID == handle)
{
// Unable to open the driver
// May be the driver is not initialized or the initialization
// is not complete.
}
Parameters
Parameters Description
drvIndex Identifier for the object instance to be opened
ioIntent Zero or more of the values from the enumeration DRV_IO_INTENT "ORed" together to
indicate the intended use of the driver. See function description for details.
Function
DRV_HANDLE DRV_AK4953_Open
(
const SYS_MODULE_INDEX drvIndex,
const DRV_IO_INTENT ioIntent
)
DRV_AK4953_Close Function
Closes an opened-instance of the AK4953 driver.
Implementation: Dynamic
File
drv_ak4953.h
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 211
C
void DRV_AK4953_Close(const DRV_HANDLE handle);
Returns
None.
Description
This routine closes an opened-instance of the AK4953 driver, invalidating the handle. Any buffers in the driver queue that were submitted by this
client will be removed. After calling this routine, the handle passed in "handle" must not be used with any of the remaining driver routines. A new
handle must be obtained by calling DRV_AK4953_Open before the caller may use the driver again
Remarks
Usually there is no need for the driver client to verify that the Close operation has completed. The driver will abort any ongoing operations when
this routine is called.
Preconditions
The DRV_AK4953_Initialize routine must have been called for the specified AK4953 driver instance.
DRV_AK4953_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE handle; // Returned from DRV_AK4953_Open
DRV_AK4953_Close(handle);
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
void DRV_AK4953_Close( DRV_Handle handle )
DRV_AK4953_Tasks Function
Maintains the driver's control and data interface state machine.
Implementation: Dynamic
File
drv_ak4953.h
C
void DRV_AK4953_Tasks(SYS_MODULE_OBJ object);
Returns
None.
Description
This routine is used to maintain the driver's internal control and data interface state machine and implement its control and data interface
implementations. This function should be called from the SYS_Tasks() function.
Remarks
This routine is normally not called directly by an application. It is called by the system's Tasks routine (SYS_Tasks).
Preconditions
The DRV_AK4953_Initialize routine must have been called for the specified AK4953 driver instance.
Example
SYS_MODULE_OBJ object; // Returned from DRV_AK4953_Initialize
while (true)
{
DRV_AK4953_Tasks (object);
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 212
// Do other tasks
}
Parameters
Parameters Description
object Object handle for the specified driver instance (returned from DRV_AK4953_Initialize)
Function
void DRV_AK4953_Tasks(SYS_MODULE_OBJ object);
DRV_AK4953_CommandEventHandlerSet Function
This function allows a client to identify a command event handling function for the driver to call back when the last submitted command have
finished.
Implementation: Dynamic
File
drv_ak4953.h
C
void DRV_AK4953_CommandEventHandlerSet(DRV_HANDLE handle, const DRV_AK4953_COMMAND_EVENT_HANDLER
eventHandler, const uintptr_t contextHandle);
Returns
None.
Description
This function allows a client to identify a command event handling function for the driver to call back when the last submitted command have
finished.
When a client calls DRV_AK4953_BufferAddWrite function, it is provided with a handle identifying the buffer that was added to the driver's buffer
queue. The driver will pass this handle back to the client by calling "eventHandler" function when the buffer transfer has completed.
The event handler should be set before the client performs any "AK4953 CODEC Specific Client Routines" operations that could generate events.
The event handler once set, persists until the client closes the driver or sets another event handler (which could be a "NULL" pointer to indicate no
callback).
Remarks
If the client does not want to be notified when the command has completed, it does not need to register a callback.
Preconditions
The DRV_AK4953_Initialize routine must have been called for the specified AK4953 driver instance.
DRV_AK4953_Open must have been called to obtain a valid opened device handle.
Example
MY_APP_OBJ myAppObj;
uint8_t mybuffer[MY_BUFFER_SIZE];
DRV_AK4953_BUFFER_HANDLE bufferHandle;
// myAK4953Handle is the handle returned
// by the DRV_AK4953_Open function.
// Client registers an event handler with driver
DRV_AK4953_CommandEventHandlerSet(myAK4953Handle,
APP_AK4953CommandEventHandler, (uintptr_t)&myAppObj);
DRV_AK4953_DeEmphasisFilterSet(myAK4953Handle, DRV_AK4953_DEEMPHASIS_FILTER_44_1KHZ)
// Event is received when
// the buffer is processed.
void APP_AK4953CommandEventHandler(uintptr_t contextHandle)
{
// contextHandle points to myAppObj.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 213
switch(event)
{
// Last Submitted command is completed.
// Perform further processing here
}
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
eventHandler Pointer to the event handler function.
context The value of parameter will be passed back to the client unchanged, when the eventHandler
function is called. It can be used to identify any client specific data object that identifies the
instance of the client module (for example, it may be a pointer to the client module's state
structure).
Function
void DRV_AK4953_CommandEventHandlerSet
(
DRV_HANDLE handle,
const DRV_AK4953_COMMAND_EVENT_HANDLER eventHandler,
const uintptr_t contextHandle
)
DRV_AK4953_BufferEventHandlerSet Function
This function allows a client to identify a buffer event handling function for the driver to call back when queued buffer transfers have finished.
File
drv_ak4953.h
C
void DRV_AK4953_BufferEventHandlerSet(DRV_HANDLE handle, const DRV_AK4953_BUFFER_EVENT_HANDLER
eventHandler, const uintptr_t contextHandle);
Returns
None.
Description
This function allows a client to identify a buffer event handling function for the driver to call back when queued buffer transfers have finished. When
a client calls DRV_AK4953_BufferAddRead function, it is provided with a handle identifying the buffer that was added to the driver's buffer queue.
The driver will pass this handle back to the client by calling "eventHandler" function when the buffer transfer has completed.
The event handler should be set before the client performs any "buffer add" operations that could generate events. The event handler once set,
persists until the client closes the driver or sets another event handler (which could be a "NULL" pointer to indicate no callback).
Remarks
If the client does not want to be notified when the queued buffer transfer has completed, it does not need to register a callback.
Preconditions
The DRV_AK4953_Initialize routine must have been called for the specified AK4953 driver instance.
DRV_AK4953_Open must have been called to obtain a valid opened device handle.
Example
MY_APP_OBJ myAppObj;
uint8_t mybuffer[MY_BUFFER_SIZE];
DRV_AK4953_BUFFER_HANDLE bufferHandle;
// myAK4953Handle is the handle returned
// by the DRV_AK4953_Open function.
// Client registers an event handler with driver
DRV_AK4953_BufferEventHandlerSet(myAK4953Handle,
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 214
APP_AK4953BufferEventHandler, (uintptr_t)&myAppObj);
DRV_AK4953_BufferAddRead(myAK4953handle, &bufferHandle
myBuffer, MY_BUFFER_SIZE);
if(DRV_AK4953_BUFFER_HANDLE_INVALID == bufferHandle)
{
// Error handling here
}
// Event is received when
// the buffer is processed.
void APP_AK4953BufferEventHandler(DRV_AK4953_BUFFER_EVENT event,
DRV_AK4953_BUFFER_HANDLE bufferHandle, uintptr_t contextHandle)
{
// contextHandle points to myAppObj.
switch(event)
{
case DRV_AK4953_BUFFER_EVENT_COMPLETE:
// This means the data was transferred.
break;
case DRV_AK4953_BUFFER_EVENT_ERROR:
// Error handling here.
break;
default:
break;
}
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
eventHandler Pointer to the event handler function.
context The value of parameter will be passed back to the client unchanged, when the eventHandler
function is called. It can be used to identify any client specific data object that identifies the
instance of the client module (for example, it may be a pointer to the client module's state
structure).
Function
void DRV_AK4953_BufferEventHandlerSet
(
DRV_HANDLE handle,
const DRV_AK4953_BUFFER_EVENT_HANDLER eventHandler,
const uintptr_t contextHandle
)
DRV_AK4953_SamplingRateSet Function
This function sets the sampling rate of the media stream.
Implementation: Dynamic
File
drv_ak4953.h
C
void DRV_AK4953_SamplingRateSet(DRV_HANDLE handle, uint32_t samplingRate);
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 215
Returns
None.
Description
This function sets the media sampling rate for the client handle.
Remarks
None.
Preconditions
The DRV_AK4953_Initialize routine must have been called for the specified AK4953 driver instance.
DRV_AK4953_Open must have been called to obtain a valid opened device handle.
Example
// myAK4953Handle is the handle returned
// by the DRV_AK4953_Open function.
DRV_AK4953_SamplingRateSet(myAK4953Handle, 48000); //Sets 48000 media sampling rate
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
void DRV_AK4953_SamplingRateSet( DRV_HANDLE handle, uint32_t samplingRate)
DRV_AK4953_SetAudioCommunicationMode Function
This function provides a run time audio format configuration
File
drv_ak4953.h
C
void DRV_AK4953_SetAudioCommunicationMode(DRV_HANDLE handle, const DATA_LENGTH dl, const SAMPLE_LENGTH sl);
Returns
None
Description
This function sets up audio mode in I2S protocol
Remarks
None.
Preconditions
The DRV_AK4953_Initialize routine must have been called for the specified AK4953 driver instance.
DRV_AK4953_Open must have been called to obtain a valid opened device handle.
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
dl Data length for I2S audio interface
sl Left/Right Sample Length for I2S audio interface
Function
void DRV_AK4953_SetAudioCommunicationMode
(
DRV_HANDLE handle,
const DATA_LENGTH dl,
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 216
const SAMPLE_LENGTH sl
)
b) Status Functions
DRV_AK4953_SamplingRateGet Function
This function gets the sampling rate set on the DAC AK4953.
Implementation: Dynamic
File
drv_ak4953.h
C
uint32_t DRV_AK4953_SamplingRateGet(DRV_HANDLE handle);
Returns
None.
Description
This function gets the sampling rate set on the DAC AK4953.
Remarks
None.
Preconditions
The DRV_AK4953_Initialize routine must have been called for the specified AK4953 driver instance.
DRV_AK4953_Open must have been called to obtain a valid opened device handle.
Example
uint32_t baudRate;
// myAK4953Handle is the handle returned
// by the DRV_AK4953_Open function.
baudRate = DRV_AK4953_SamplingRateGet(myAK4953Handle);
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
uint32_t DRV_AK4953_SamplingRateGet( DRV_HANDLE handle)
DRV_AK4953_Status Function
Gets the current status of the AK4953 driver module.
Implementation: Dynamic
File
drv_ak4953.h
C
SYS_STATUS DRV_AK4953_Status(SYS_MODULE_OBJ object);
Returns
SYS_STATUS_DEINITIALIZED - Indicates that the driver has been deinitialized
SYS_STATUS_READY - Indicates that any previous module operation for the specified module has completed
SYS_STATUS_BUSY - Indicates that a previous module operation for the specified module has not yet completed
SYS_STATUS_ERROR - Indicates that the specified module is in an error state
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 217
Description
This routine provides the current status of the AK4953 driver module.
Remarks
A driver can opened only when its status is SYS_STATUS_READY.
Preconditions
Function DRV_AK4953_Initialize should have been called before calling this function.
Example
SYS_MODULE_OBJ object; // Returned from DRV_AK4953_Initialize
SYS_STATUS AK4953Status;
AK4953Status = DRV_AK4953_Status(object);
if (SYS_STATUS_READY == AK4953Status)
{
// This means the driver can be opened using the
// DRV_AK4953_Open() function.
}
Parameters
Parameters Description
object Driver object handle, returned from the DRV_AK4953_Initialize routine
Function
SYS_STATUS DRV_AK4953_Status( SYS_MODULE_OBJ object)
DRV_AK4953_VersionGet Function
This function returns the version of AK4953 driver.
Implementation: Dynamic
File
drv_ak4953.h
C
uint32_t DRV_AK4953_VersionGet();
Returns
returns the version of AK4953 driver.
Description
The version number returned from the DRV_AK4953_VersionGet function is an unsigned integer in the following decimal format. * 10000 + * 100
+ Where the numbers are represented in decimal and the meaning is the same as above. Note that there is no numerical representation of
release type.
Remarks
None.
Preconditions
None.
Example 1
For version "0.03a", return: 0 * 10000 + 3 * 100 + 0 For version "1.00", return: 1 * 100000 + 0 * 100 + 0
Example 2
uint32_t AK4953version;
AK4953version = DRV_AK4953_VersionGet();
Function
uint32_t DRV_AK4953_VersionGet( void )
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 218
DRV_AK4953_VersionStrGet Function
This function returns the version of AK4953 driver in string format.
Implementation: Dynamic
File
drv_ak4953.h
C
int8_t* DRV_AK4953_VersionStrGet();
Returns
returns a string containing the version of AK4953 driver.
Description
The DRV_AK4953_VersionStrGet function returns a string in the format: ".[.][]" Where: is the AK4953 driver's version number. is the AK4953
driver's version number. is an optional "patch" or "dot" release number (which is not included in the string if it equals "00"). is an optional release
type ("a" for alpha, "b" for beta ? not the entire word spelled out) that is not included if the release is a production version (I.e. Not an alpha or beta).
The String does not contain any spaces.
Remarks
None.
Preconditions
None.
Example 1
"0.03a" "1.00"
Example 2
int8_t *AK4953string;
AK4953string = DRV_AK4953_VersionStrGet();
Function
int8_t* DRV_AK4953_VersionStrGet(void)
DRV_AK4953_VolumeGet Function
This function gets the volume for AK4953 CODEC.
Implementation: Dynamic
File
drv_ak4953.h
C
uint8_t DRV_AK4953_VolumeGet(DRV_HANDLE handle, DRV_AK4953_CHANNEL chan);
Returns
None.
Description
This functions gets the current volume programmed to the CODEC AK4953.
Remarks
None.
Preconditions
The DRV_AK4953_Initialize routine must have been called for the specified AK4953 driver instance.
DRV_AK4953_Open must have been called to obtain a valid opened device handle.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 219
Example
// myAppObj is an application specific object.
MY_APP_OBJ myAppObj;
uint8_t volume;
// myAK4953Handle is the handle returned
// by the DRV_AK4953_Open function.
volume = DRV_AK4953_VolumeGet(myAK4953Handle,DRV_AK4953_CHANNEL_LEFT);
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
chan Audio channel volume to be set
Function
uint8_t DRV_AK4953_VolumeGet( DRV_HANDLE handle, DRV_AK4953_CHANNEL chan)
c) Other Functions
DRV_AK4953_BufferAddWrite Function
Schedule a non-blocking driver write operation.
Implementation: Dynamic
File
drv_ak4953.h
C
void DRV_AK4953_BufferAddWrite(const DRV_HANDLE handle, DRV_AK4953_BUFFER_HANDLE * bufferHandle, void *
buffer, size_t size);
Returns
The bufferHandle parameter will contain the return buffer handle. This will be DRV_AK4953_BUFFER_HANDLE_INVALID if the function was not
successful.
Description
This function schedules a non-blocking write operation. The function returns with a valid buffer handle in the bufferHandle argument if the write
request was scheduled successfully. The function adds the request to the hardware instance transmit queue and returns immediately. While the
request is in the queue, the application buffer is owned by the driver and should not be modified. The function returns
DRV_AK4953_BUFFER_HANDLE_INVALID
• if a buffer could not be allocated to the request
• if the input buffer pointer is NULL
• if the buffer size is 0.
• if the queue is full or the queue depth is insufficient
If the requesting client registered an event callback with the driver, the driver will issue a DRV_AK4953_BUFFER_EVENT_COMPLETE event if
the buffer was processed successfully of DRV_AK4953_BUFFER_EVENT_ERROR event if the buffer was not processed successfully.
Remarks
This function is thread safe in a RTOS application. It can be called from within the AK4953 Driver Buffer Event Handler that is registered by this
client. It should not be called in the event handler associated with another AK4953 driver instance. It should not otherwise be called directly in an
ISR.
Preconditions
The DRV_AK4953_Initialize routine must have been called for the specified AK4953 device instance and the DRV_AK4953_Status must have
returned SYS_STATUS_READY.
DRV_AK4953_Open must have been called to obtain a valid opened device handle.
DRV_IO_INTENT_WRITE must have been specified in the DRV_AK4953_Open call.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 220
Example
MY_APP_OBJ myAppObj;
uint8_t mybuffer[MY_BUFFER_SIZE];
DRV_AK4953_BUFFER_HANDLE bufferHandle;
// myAK4953Handle is the handle returned
// by the DRV_AK4953_Open function.
// Client registers an event handler with driver
DRV_AK4953_BufferEventHandlerSet(myAK4953Handle,
APP_AK4953BufferEventHandler, (uintptr_t)&myAppObj);
DRV_AK4953_BufferAddWrite(myAK4953handle, &bufferHandle
myBuffer, MY_BUFFER_SIZE);
if(DRV_AK4953_BUFFER_HANDLE_INVALID == bufferHandle)
{
// Error handling here
}
// Event is received when
// the buffer is processed.
void APP_AK4953BufferEventHandler(DRV_AK4953_BUFFER_EVENT event,
DRV_AK4953_BUFFER_HANDLE bufferHandle, uintptr_t contextHandle)
{
// contextHandle points to myAppObj.
switch(event)
{
case DRV_AK4953_BUFFER_EVENT_COMPLETE:
// This means the data was transferred.
break;
case DRV_AK4953_BUFFER_EVENT_ERROR:
// Error handling here.
break;
default:
break;
}
}
Parameters
Parameters Description
handle Handle of the AK4953 instance as return by the DRV_AK4953_Open function.
buffer Data to be transmitted.
size Buffer size in bytes.
bufferHandle Pointer to an argument that will contain the return buffer handle.
Function
void DRV_AK4953_BufferAddWrite
(
const DRV_HANDLE handle,
DRV_AK4953_BUFFER_HANDLE *bufferHandle,
void *buffer, size_t size
)
DRV_AK4953_BufferAddWriteRead Function
Schedule a non-blocking driver write-read operation.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 221
Implementation: Dynamic
File
drv_ak4953.h
C
void DRV_AK4953_BufferAddWriteRead(const DRV_HANDLE handle, DRV_AK4953_BUFFER_HANDLE * bufferHandle, void *
transmitBuffer, void * receiveBuffer, size_t size);
Returns
The bufferHandle parameter will contain the return buffer handle. This will be DRV_AK4953_BUFFER_HANDLE_INVALID if the function was not
successful.
Description
This function schedules a non-blocking write-read operation. The function returns with a valid buffer handle in the bufferHandle argument if the
write-read request was scheduled successfully. The function adds the request to the hardware instance queue and returns immediately. While the
request is in the queue, the application buffer is owned by the driver and should not be modified. The function returns
DRV_AK4953_BUFFER_EVENT_COMPLETE:
• if a buffer could not be allocated to the request
• if the input buffer pointer is NULL
• if the client opened the driver for read only or write only
• if the buffer size is 0
• if the queue is full or the queue depth is insufficient
If the requesting client registered an event callback with the driver, the driver will issue a DRV_AK4953_BUFFER_EVENT_COMPLETE event if
the buffer was processed successfully of DRV_AK4953_BUFFER_EVENT_ERROR event if the buffer was not processed successfully.
Remarks
This function is thread safe in a RTOS application. It can be called from within the AK4953 Driver Buffer Event Handler that is registered by this
client. It should not be called in the event handler associated with another AK4953 driver instance. It should not otherwise be called directly in an
ISR.
This function is useful when there is valid read expected for every AK4953 write. The transmit and receive size must be same.
Preconditions
The DRV_AK4953_Initialize routine must have been called for the specified AK4953 device instance and the DRV_AK4953_Status must have
returned SYS_STATUS_READY.
DRV_AK4953_Open must have been called to obtain a valid opened device handle.
DRV_IO_INTENT_READWRITE must have been specified in the DRV_AK4953_Open call.
Example
MY_APP_OBJ myAppObj;
uint8_t mybufferTx[MY_BUFFER_SIZE];
uint8_t mybufferRx[MY_BUFFER_SIZE];
DRV_AK4953_BUFFER_HANDLE bufferHandle;
// myak4953Handle is the handle returned
// by the DRV_AK4953_Open function.
// Client registers an event handler with driver
DRV_AK4953_BufferEventHandlerSet(myak4953Handle,
APP_AK4953BufferEventHandler, (uintptr_t)&myAppObj);
DRV_AK4953_BufferAddWriteRead(myak4953handle, &bufferHandle,
mybufferTx,mybufferRx,MY_BUFFER_SIZE);
if(DRV_AK4953_BUFFER_HANDLE_INVALID == bufferHandle)
{
// Error handling here
}
// Event is received when
// the buffer is processed.
void APP_AK4953BufferEventHandler(DRV_AK4953_BUFFER_EVENT event,
DRV_AK4953_BUFFER_HANDLE bufferHandle, uintptr_t contextHandle)
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 222
{
// contextHandle points to myAppObj.
switch(event)
{
case DRV_AK4953_BUFFER_EVENT_COMPLETE:
// This means the data was transferred.
break;
case DRV_AK4953_BUFFER_EVENT_ERROR:
// Error handling here.
break;
default:
break;
}
}
Parameters
Parameters Description
handle Handle of the AK4953 instance as returned by the DRV_AK4953_Open function
bufferHandle Pointer to an argument that will contain the return buffer handle
transmitBuffer The buffer where the transmit data will be stored
receiveBuffer The buffer where the received data will be stored
size Buffer size in bytes
Function
void DRV_AK4953_BufferAddWriteRead
(
const DRV_HANDLE handle,
DRV_AK4953_BUFFER_HANDLE *bufferHandle,
void *transmitBuffer,
void *receiveBuffer,
size_t size
)
DRV_AK4953_MuteOff Function
This function disables AK4953 output for soft mute.
Implementation: Dynamic
File
drv_ak4953.h
C
void DRV_AK4953_MuteOff(DRV_HANDLE handle);
Returns
None.
Description
This function disables AK4953 output for soft mute.
Remarks
None.
Preconditions
The DRV_AK4953_Initialize routine must have been called for the specified AK4953 driver instance.
DRV_AK4953_Open must have been called to obtain a valid opened device handle.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 223
Example
// myAppObj is an application specific object.
MY_APP_OBJ myAppObj;
uint8_t mybuffer[MY_BUFFER_SIZE];
DRV_BUFFER_HANDLE bufferHandle;
// myAK4953Handle is the handle returned
// by the DRV_AK4953_Open function.
DRV_AK4953_MuteOff(myAK4953Handle); //AK4953 output soft mute disabled
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
void DRV_AK4953_MuteOff( DRV_HANDLE handle)
DRV_AK4953_MuteOn Function
This function allows AK4953 output for soft mute on.
Implementation: Dynamic
File
drv_ak4953.h
C
void DRV_AK4953_MuteOn(DRV_HANDLE handle);
Returns
None.
Description
This function Enables AK4953 output for soft mute.
Remarks
None.
Preconditions
The DRV_AK4953_Initialize routine must have been called for the specified AK4953 driver instance.
DRV_AK4953_Open must have been called to obtain a valid opened device handle.
Example
// myAppObj is an application specific object.
MY_APP_OBJ myAppObj;
uint8_t mybuffer[MY_BUFFER_SIZE];
DRV_BUFFER_HANDLE bufferHandle;
// myAK4953Handle is the handle returned
// by the DRV_AK4953_Open function.
DRV_AK4953_MuteOn(myAK4953Handle); //AK4953 output soft muted
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
void DRV_AK4953_MuteOn( DRV_HANDLE handle);
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 224
DRV_AK4953_VolumeSet Function
This function sets the volume for AK4953 CODEC.
Implementation: Dynamic
File
drv_ak4953.h
C
void DRV_AK4953_VolumeSet(DRV_HANDLE handle, DRV_AK4953_CHANNEL channel, uint8_t volume);
Returns
None.
Description
This functions sets the volume value from 0-255. The codec has DAC value to volume range mapping as :- 00 H : +12dB FF H : -115dB In order to
make the volume value to dB mapping monotonically increasing from 00 to FF, re-mapping is introduced which reverses the volume value to dB
mapping as well as normalizes the volume range to a more audible dB range. The current driver implementation assumes that all dB values under
-60 dB are inaudible to the human ear. Re-Mapped values 00 H : -60 dB FF H : +12 dB
Remarks
None.
Preconditions
The DRV_AK4953_Initialize routine must have been called for the specified AK4953 driver instance.
DRV_AK4953_Open must have been called to obtain a valid opened device handle.
Example
// myAppObj is an application specific object.
MY_APP_OBJ myAppObj;
uint8_t mybuffer[MY_BUFFER_SIZE];
DRV_BUFFER_HANDLE bufferHandle;
// myAK4953Handle is the handle returned
// by the DRV_AK4953_Open function.
DRV_AK4953_VolumeSet(myAK4953Handle, DRV_AK4953_CHANNEL_LEFT, 120);
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
chan Audio channel volume to be set
volume volume value specified in the range 0-255 (0x00 to 0xFF)
Function
void DRV_AK4953_VolumeSet( DRV_HANDLE handle, DRV_AK4953_CHANNEL channel, uint8_t volume);
DRV_AK4953_BufferAddRead Function
Schedule a non-blocking driver read operation.
File
drv_ak4953.h
C
void DRV_AK4953_BufferAddRead(const DRV_HANDLE handle, DRV_AK4953_BUFFER_HANDLE * bufferHandle, void *
buffer, size_t size);
Returns
The bufferHandle parameter will contain the return buffer handle. This will be DRV_AK4953_BUFFER_HANDLE_INVALID if the function was not
successful.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 225
Description
This function schedules a non-blocking read operation. The function returns with a valid buffer handle in the bufferHandle argument if the read
request was scheduled successfully. The function adds the request to the hardware instance receive queue and returns immediately. While the
request is in the queue, the application buffer is owned by the driver and should not be modified. The function returns
DRV_AK4953_BUFFER_HANDLE_INVALID
• if a buffer could not be allocated to the request
• if the input buffer pointer is NULL
• if the buffer size is 0.
• if the queue is full or the queue depth is insufficient
If the requesting client registered an event callback with the driver, the driver will issue a DRV_AK4953_BUFFER_EVENT_COMPLETE event if
the buffer was processed successfully of DRV_AK4953_BUFFER_EVENT_ERROR event if the buffer was not processed successfully.
Remarks
This function is thread safe in a RTOS application. It can be called from within the AK4953 Driver Buffer Event Handler that is registered by this
client. It should not be called in the event handler associated with another AK4953 driver instance. It should not otherwise be called directly in an
ISR.
Preconditions
The DRV_AK4953_Initialize routine must have been called for the specified AK4953 device instance and the DRV_AK4953_Status must have
returned SYS_STATUS_READY.
DRV_AK4953_Open must have been called to obtain a valid opened device handle.
DRV_IO_INTENT_READ must have been specified in the DRV_AK4953_Open call.
Parameters
Parameters Description
handle Handle of the AK4953 instance as return by the DRV_AK4953_Open function.
buffer Data to be transmitted.
size Buffer size in bytes.
bufferHandle Pointer to an argument that will contain the return buffer handle.
Function
void DRV_AK4953_BufferAddRead
(
const DRV_HANDLE handle,
DRV_AK4953_BUFFER_HANDLE *bufferHandle,
void *buffer, size_t size
)
DRV_AK4953_IntExtMicSet Function
This function sets up the codec for the X32 DB internal or the external microphone use.
File
drv_ak4953.h
C
void DRV_AK4953_IntExtMicSet(DRV_HANDLE handle, DRV_AK4953_INT_EXT_MIC micInput);
Returns
None
Description
This function sets up the codec for the internal or the external microphone use.
Remarks
None.
Preconditions
The DRV_AK4953_Initialize routine must have been called for the specified AK4953 driver instance.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 226
DRV_AK4953_Open must have been called to obtain a valid opened device handle.
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
micInput Internal vs External mic input
Function
void DRV_AK4953_IntExtMicSet
DRV_AK4953_MonoStereoMicSet Function
This function sets up the codec for the Mono or Stereo microphone mode.
File
drv_ak4953.h
C
void DRV_AK4953_MonoStereoMicSet(DRV_HANDLE handle, DRV_AK4953_MONO_STEREO_MIC mono_stereo_mic);
Returns
None
Description
This function sets up the codec for the Mono or Stereo microphone mode.
Remarks
None.
Preconditions
The DRV_AK4953_Initialize routine must have been called for the specified AK4953 driver instance.
DRV_AK4953_Open must have been called to obtain a valid opened device handle.
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
void DRV_AK4953_MonoStereoMicSet( DRV_HANDLE handle);
DRV_AK4953_MicSet Function
This function sets up the codec for the internal or the AK4953 Mic1 or Mic2 input.
File
drv_ak4953.h
C
void DRV_AK4953_MicSet(DRV_HANDLE handle, DRV_AK4953_MIC micInput);
Returns
None
Description
This function sets up the codec.
Remarks
None.
Preconditions
The DRV_AK4953_Initialize routine must have been called for the specified AK4953 driver instance.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 227
DRV_AK4953_Open must have been called to obtain a valid opened device handle.
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
micInput Internal vs External mic input
Function
void DRV_AK4953_IntMic12Set
d) Data Types and Constants
DRV_AK4953_AUDIO_DATA_FORMAT Enumeration
Identifies the Serial Audio data interface format.
File
drv_ak4953.h
C
typedef enum {
DRV_AK4953_AUDIO_DATA_FORMAT_24BIT_MSB_SDTO_24BIT_LSB_SDTI = 0,
DRV_AK4953_AUDIO_DATA_FORMAT_24BIT_MSB_SDTO_16BIT_LSB_SDTI,
DRV_AK4953_AUDIO_DATA_FORMAT_24BIT_MSB_SDTO_24BIT_MSB_SDTI,
DRV_AK4953_AUDIO_DATA_FORMAT_I2S
} DRV_AK4953_AUDIO_DATA_FORMAT;
Description
AK4953 Audio data format
This enumeration identifies Serial Audio data interface format.
DRV_AK4953_BUFFER_EVENT Enumeration
Identifies the possible events that can result from a buffer add request.
File
drv_ak4953.h
C
typedef enum {
DRV_AK4953_BUFFER_EVENT_COMPLETE,
DRV_AK4953_BUFFER_EVENT_ERROR,
DRV_AK4953_BUFFER_EVENT_ABORT
} DRV_AK4953_BUFFER_EVENT;
Members
Members Description
DRV_AK4953_BUFFER_EVENT_COMPLETE Data was transferred successfully.
DRV_AK4953_BUFFER_EVENT_ERROR Error while processing the request
DRV_AK4953_BUFFER_EVENT_ABORT Data transfer aborted (Applicable in DMA mode)
Description
AK4953 Driver Events
This enumeration identifies the possible events that can result from a buffer add request caused by the client calling either the
DRV_AK4953_BufferAddWrite() function.
Remarks
One of these values is passed in the "event" parameter of the event handling callback function that the client registered with the driver by calling
the DRV_AK4953_BufferEventHandlerSet function when a buffer transfer request is completed.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 228
DRV_AK4953_BUFFER_EVENT_HANDLER Type
Pointer to a AK4953 Driver Buffer Event handler function
File
drv_ak4953.h
C
typedef void (* DRV_AK4953_BUFFER_EVENT_HANDLER)(DRV_AK4953_BUFFER_EVENT event, DRV_AK4953_BUFFER_HANDLE
bufferHandle, uintptr_t contextHandle);
Returns
None.
Description
AK4953 Driver Buffer Event Handler Function
This data type defines the required function signature for the AK4953 driver buffer event handling callback function. A client must register a pointer
to a buffer event handling function who's function signature (parameter and return value types) match the types specified by this function pointer in
order to receive buffer related event calls back from the driver.
The parameters and return values are described here and a partial example implementation is provided.
Remarks
If the event is DRV_AK4953_BUFFER_EVENT_COMPLETE, this means that the data was transferred successfully.
If the event is DRV_AK4953_BUFFER_EVENT_ERROR, this means that the data was not transferred successfully. The bufferHandle parameter
contains the buffer handle of the buffer that failed. The DRV_AK4953_BufferProcessedSizeGet() function can be called to find out how many bytes
were processed.
The bufferHandle parameter contains the buffer handle of the buffer that associated with the event.
The context parameter contains a handle to the client context, provided at the time the event handling function was registered using the
DRV_AK4953_BufferEventHandlerSet function. This context handle value is passed back to the client as the "context" parameter. It can be any
value necessary to identify the client context or instance (such as a pointer to the client's data) instance of the client that made the buffer add
request.
The buffer handle in bufferHandle expires after this event handler exits. In that the buffer object that was allocated is deallocated by the driver after
the event handler exits.
The event handler function executes in the data driver (I2S) peripheral's interrupt context when the driver is configured for interrupt mode
operation. It is recommended of the application to not perform process intensive or blocking operations with in this function.
DRV_AK4953_BufferAddWrite function can be called in the event handler to add a buffer to the driver queue.
Example
void APP_MyBufferEventHandler( DRV_AK4953_BUFFER_EVENT event,
DRV_AK4953_BUFFER_HANDLE bufferHandle,
uintptr_t context )
{
MY_APP_DATA_STRUCT pAppData = (MY_APP_DATA_STRUCT) context;
switch(event)
{
case DRV_AK4953_BUFFER_EVENT_COMPLETE:
// Handle the completed buffer.
break;
case DRV_AK4953_BUFFER_EVENT_ERROR:
default:
// Handle error.
break;
}
}
Parameters
Parameters Description
event Identifies the type of event
bufferHandle Handle identifying the buffer to which the event relates
context Value identifying the context of the application that registered the event handling function.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 229
DRV_AK4953_BUFFER_HANDLE Type
Handle identifying a write buffer passed to the driver.
File
drv_ak4953.h
C
typedef uintptr_t DRV_AK4953_BUFFER_HANDLE;
Description
AK4953 Driver Buffer Handle
A buffer handle value is returned by a call to the DRV_AK4953_BufferAddWrite() function. This handle is associated with the buffer passed into the
function and it allows the application to track the completion of the data from (or into) that buffer. The buffer handle value returned from the "buffer
add" function is returned back to the client by the "event handler callback" function registered with the driver.
The buffer handle assigned to a client request expires when the client has been notified of the completion of the buffer transfer (after event handler
function that notifies the client returns) or after the buffer has been retired by the driver if no event handler callback was set.
Remarks
None
DRV_AK4953_COMMAND_EVENT_HANDLER Type
Pointer to a AK4953 Driver Command Event Handler Function
File
drv_ak4953.h
C
typedef void (* DRV_AK4953_COMMAND_EVENT_HANDLER)(uintptr_t contextHandle);
Returns
None.
Description
AK4953 Driver Command Event Handler Function
This data type defines the required function signature for the AK4953 driver command event handling callback function.
A command is a control instruction to the AK4953 CODEC. Example Mute ON/OFF, Zero Detect Enable/Disable etc.
A client must register a pointer to a command event handling function who's function signature (parameter and return value types) match the types
specified by this function pointer in order to receive command related event calls back from the driver.
The parameters and return values are described here and a partial example implementation is provided.
Remarks
The occurrence of this call back means that the last control command was transferred successfully.
The context parameter contains a handle to the client context, provided at the time the event handling function was registered using the
DRV_AK4953_CommandEventHandlerSet function. This context handle value is passed back to the client as the "context" parameter. It can be
any value necessary to identify the client context or instance (such as a pointer to the client's data) instance of the client that made the buffer add
request.
The event handler function executes in the control data driver interrupt context. It is recommended of the application to not perform process
intensive or blocking operations with in this function.
Example
void APP_AK4953CommandEventHandler( uintptr_t context )
{
MY_APP_DATA_STRUCT pAppData = (MY_APP_DATA_STRUCT) context;
// Last Submitted command is completed.
// Perform further processing here
}
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 230
Parameters
Parameters Description
context Value identifying the context of the application that registered the event handling function.
DRV_AK4953_DIGITAL_BLOCK_CONTROL Enumeration
Identifies Bass-Boost Control function
File
drv_ak4953.h
C
typedef enum {
DRV_AK4953_RECORDING_MODE,
DRV_AK4953_PLAYBACK_MODE,
DRV_AK4953_RECORDING_PLAYBACK_2_MODE,
DRV_AK4953_LOOPBACK_MODE
} DRV_AK4953_DIGITAL_BLOCK_CONTROL;
Members
Members Description
DRV_AK4953_RECORDING_MODE This is the default setting
DRV_AK4953_PLAYBACK_MODE Min control
DRV_AK4953_RECORDING_PLAYBACK_2_MODE Medium control
DRV_AK4953_LOOPBACK_MODE Maximum control
Description
AK4953 Bass-Boost Control
This enumeration identifies the settings for Bass-Boost Control function.
Remarks
None.
DRV_AK4953_INIT Structure
Defines the data required to initialize or reinitialize the AK4953 driver
File
drv_ak4953.h
C
typedef struct {
SYS_MODULE_INIT moduleInit;
SYS_MODULE_INDEX i2sDriverModuleIndex;
SYS_MODULE_INDEX i2cDriverModuleIndex;
uint32_t samplingRate;
uint8_t volume;
DRV_AK4953_AUDIO_DATA_FORMAT audioDataFormat;
} DRV_AK4953_INIT;
Members
Members Description
SYS_MODULE_INIT moduleInit; System module initialization
SYS_MODULE_INDEX i2sDriverModuleIndex; Identifies data module(I2S) driver ID for data interface of CODEC
SYS_MODULE_INDEX i2cDriverModuleIndex; Identifies data module(I2C) driver ID for control interface of CODEC
uint32_t samplingRate; Sampling rate
uint8_t volume; Volume
DRV_AK4953_AUDIO_DATA_FORMAT
audioDataFormat;
Identifies the Audio data format
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 231
Description
AK4953 Driver Initialization Data
This data type defines the data required to initialize or reinitialize the AK4953 CODEC driver.
Remarks
None.
_DRV_AK4953_H Macro
File
drv_ak4953.h
C
#define _DRV_AK4953_H
Description
Include files.
DRV_AK4953_BUFFER_HANDLE_INVALID Macro
Definition of an invalid buffer handle.
File
drv_ak4953.h
C
#define DRV_AK4953_BUFFER_HANDLE_INVALID ((DRV_AK4953_BUFFER_HANDLE)(-1))
Description
AK4953 Driver Invalid Buffer Handle
This is the definition of an invalid buffer handle. An invalid buffer handle is returned by DRV_AK4953_BufferAddWrite() function if the buffer add
request was not successful.
Remarks
None
DRV_AK4953_COUNT Macro
Number of valid AK4953 driver indices
File
drv_ak4953.h
C
#define DRV_AK4953_COUNT
Description
AK4953 Driver Module Count
This constant identifies the maximum number of AK4953 Driver instances that should be defined by the application. Defining more instances than
this constant will waste RAM memory space.
This constant can also be used by the application to identify the number of AK4953 instances on this microcontroller.
Remarks
This value is part-specific.
DRV_AK4953_INDEX_0 Macro
AK4953 driver index definitions
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 232
File
drv_ak4953.h
C
#define DRV_AK4953_INDEX_0 0
Description
Driver AK4953 Module Index
These constants provide AK4953 driver index definition.
Remarks
These constants should be used in place of hard-coded numeric literals. These values should be passed into the DRV_AK4953_Initialize and
DRV_AK4953_Open routines to identify the driver instance in use.
DRV_AK4953_INDEX_1 Macro
File
drv_ak4953.h
C
#define DRV_AK4953_INDEX_1 1
Description
This is macro DRV_AK4953_INDEX_1.
DRV_AK4953_INDEX_2 Macro
File
drv_ak4953.h
C
#define DRV_AK4953_INDEX_2 2
Description
This is macro DRV_AK4953_INDEX_2.
DRV_AK4953_INDEX_3 Macro
File
drv_ak4953.h
C
#define DRV_AK4953_INDEX_3 3
Description
This is macro DRV_AK4953_INDEX_3.
DRV_AK4953_INDEX_4 Macro
File
drv_ak4953.h
C
#define DRV_AK4953_INDEX_4 4
Description
This is macro DRV_AK4953_INDEX_4.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 233
DRV_AK4953_INDEX_5 Macro
File
drv_ak4953.h
C
#define DRV_AK4953_INDEX_5 5
Description
This is macro DRV_AK4953_INDEX_5.
DRV_AK4953_CHANNEL Enumeration
Identifies Left/Right Audio channel
File
drv_ak4953.h
C
typedef enum {
DRV_AK4953_CHANNEL_LEFT,
DRV_AK4953_CHANNEL_RIGHT,
DRV_AK4953_CHANNEL_LEFT_RIGHT,
DRV_AK4953_NUMBER_OF_CHANNELS
} DRV_AK4953_CHANNEL;
Description
AK4953 Audio Channel
This enumeration identifies Left/Right Audio channel
Remarks
None.
DRV_AK4953_INT_EXT_MIC Enumeration
Identifies the Mic input source.
File
drv_ak4953.h
C
typedef enum {
INT_MIC,
EXT_MIC
} DRV_AK4953_INT_EXT_MIC;
Description
AK4953 Mic Internal / External Input
This enumeration identifies the Mic input source.
DRV_AK4953_MONO_STEREO_MIC Enumeration
Identifies the Mic input as Mono / Stereo.
File
drv_ak4953.h
C
typedef enum {
ALL_ZEROS,
MONO_RIGHT_CHANNEL,
MONO_LEFT_CHANNEL,
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 234
STEREO
} DRV_AK4953_MONO_STEREO_MIC;
Description
AK4953 Mic Mono / Stereo Input
This enumeration identifies the Mic input as Mono / Stereo.
DRV_AK4953_MIC Enumeration
File
drv_ak4953.h
C
typedef enum {
MIC1 = 0,
MIC2,
MIC3,
DRV_AK4953_NUMBER_OF_MIC
} DRV_AK4953_MIC;
Members
Members Description
MIC1 = 0 INT_MIC
MIC2 EXT_MIC
MIC3 LINE-IN
Description
This is type DRV_AK4953_MIC.
Files
Files
Name Description
drv_ak4953.h AK4953 CODEC Driver Interface header file
drv_ak4953_config_template.h AK4953 Codec Driver Configuration Template.
Description
This section lists the source and header files used by the AK4953Codec Driver Library.
drv_ak4953.h
AK4953 CODEC Driver Interface header file
Enumerations
Name Description
DRV_AK4953_AUDIO_DATA_FORMAT Identifies the Serial Audio data interface format.
DRV_AK4953_BUFFER_EVENT Identifies the possible events that can result from a buffer add request.
DRV_AK4953_CHANNEL Identifies Left/Right Audio channel
DRV_AK4953_DIGITAL_BLOCK_CONTROL Identifies Bass-Boost Control function
DRV_AK4953_INT_EXT_MIC Identifies the Mic input source.
DRV_AK4953_MIC This is type DRV_AK4953_MIC.
DRV_AK4953_MONO_STEREO_MIC Identifies the Mic input as Mono / Stereo.
Functions
Name Description
DRV_AK4953_BufferAddRead Schedule a non-blocking driver read operation.
DRV_AK4953_BufferAddWrite Schedule a non-blocking driver write operation.
Implementation: Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 235
DRV_AK4953_BufferAddWriteRead Schedule a non-blocking driver write-read operation.
Implementation: Dynamic
DRV_AK4953_BufferEventHandlerSet This function allows a client to identify a buffer event handling function for the driver
to call back when queued buffer transfers have finished.
DRV_AK4953_Close Closes an opened-instance of the AK4953 driver.
Implementation: Dynamic
DRV_AK4953_CommandEventHandlerSet This function allows a client to identify a command event handling function for the
driver to call back when the last submitted command have finished.
Implementation: Dynamic
DRV_AK4953_Deinitialize Deinitializes the specified instance of the AK4953 driver module.
Implementation: Dynamic
DRV_AK4953_Initialize Initializes hardware and data for the instance of the AK4953 DAC module.
Implementation: Dynamic
DRV_AK4953_IntExtMicSet This function sets up the codec for the X32 DB internal or the external microphone
use.
DRV_AK4953_MicSet This function sets up the codec for the internal or the AK4953 Mic1 or Mic2 input.
DRV_AK4953_MonoStereoMicSet This function sets up the codec for the Mono or Stereo microphone mode.
DRV_AK4953_MuteOff This function disables AK4953 output for soft mute.
Implementation: Dynamic
DRV_AK4953_MuteOn This function allows AK4953 output for soft mute on.
Implementation: Dynamic
DRV_AK4953_Open Opens the specified AK4953 driver instance and returns a handle to it.
Implementation: Dynamic
DRV_AK4953_SamplingRateGet This function gets the sampling rate set on the DAC AK4953.
Implementation: Dynamic
DRV_AK4953_SamplingRateSet This function sets the sampling rate of the media stream.
Implementation: Dynamic
DRV_AK4953_SetAudioCommunicationMode This function provides a run time audio format configuration
DRV_AK4953_Status Gets the current status of the AK4953 driver module.
Implementation: Dynamic
DRV_AK4953_Tasks Maintains the driver's control and data interface state machine.
Implementation: Dynamic
DRV_AK4953_VersionGet This function returns the version of AK4953 driver.
Implementation: Dynamic
DRV_AK4953_VersionStrGet This function returns the version of AK4953 driver in string format.
Implementation: Dynamic
DRV_AK4953_VolumeGet This function gets the volume for AK4953 CODEC.
Implementation: Dynamic
DRV_AK4953_VolumeSet This function sets the volume for AK4953 CODEC.
Implementation: Dynamic
Macros
Name Description
_DRV_AK4953_H Include files.
DRV_AK4953_BUFFER_HANDLE_INVALID Definition of an invalid buffer handle.
DRV_AK4953_COUNT Number of valid AK4953 driver indices
DRV_AK4953_INDEX_0 AK4953 driver index definitions
DRV_AK4953_INDEX_1 This is macro DRV_AK4953_INDEX_1.
DRV_AK4953_INDEX_2 This is macro DRV_AK4953_INDEX_2.
DRV_AK4953_INDEX_3 This is macro DRV_AK4953_INDEX_3.
DRV_AK4953_INDEX_4 This is macro DRV_AK4953_INDEX_4.
DRV_AK4953_INDEX_5 This is macro DRV_AK4953_INDEX_5.
Structures
Name Description
DRV_AK4953_INIT Defines the data required to initialize or reinitialize the AK4953 driver
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 236
Types
Name Description
DRV_AK4953_BUFFER_EVENT_HANDLER Pointer to a AK4953 Driver Buffer Event handler function
DRV_AK4953_BUFFER_HANDLE Handle identifying a write buffer passed to the driver.
DRV_AK4953_COMMAND_EVENT_HANDLER Pointer to a AK4953 Driver Command Event Handler Function
Description
AK4953 CODEC Driver Interface
The AK4953 CODEC device driver interface provides a simple interface to manage the AK4953 106dB 192kHz 24-Bit DAC that can be interfaced
Microchip Microcontroller. This file provides the interface definition for the AK4953 CODEC device driver.
File Name
drv_AK4953.h
Company
Microchip Technology Inc.
drv_ak4953_config_template.h
AK4953 Codec Driver Configuration Template.
Macros
Name Description
DRV_AK4953_BCLK_BIT_CLK_DIVISOR Sets up the BCLK to LRCK Ratio to Generate Audio Stream for specified
sampling frequency
DRV_AK4953_CLIENTS_NUMBER Sets up the maximum number of clients that can be connected to any
hardware instance.
DRV_AK4953_INPUT_REFCLOCK Identifies the input REFCLOCK source to generate the MCLK to codec.
DRV_AK4953_INSTANCES_NUMBER Sets up the maximum number of hardware instances that can be supported
DRV_AK4953_MCLK_SAMPLE_FREQ_MULTPLIER Sets up the MCLK to LRCK Ratio to Generate Audio Stream for specified
sampling frequency
DRV_AK4953_MCLK_SOURCE Indicate the input clock frequency to generate the MCLK to codec.
DRV_AK4953_QUEUE_DEPTH_COMBINED Number of entries of all queues in all instances of the driver.
Description
AK4953 Codec Driver Configuration Template
These file provides the list of all the configurations that can be used with the driver. This file should not be included in the driver.
File Name
drv_ak4953_config_template.h
Company
Microchip Technology Inc.
AK4954 Codec Driver Library
This topic describes the AK4954 Codec Driver Library.
Introduction
This library provides an interface to manage the AK4954 Codec that is serially interfaced to a Microchip microcontroller for providing Audio
Solutions.
Description
The AK4954 module is 16/24-bit Audio Codec from Asahi Kasei Microdevices Corporation. The AK4954 can be interfaced to Microchip
microcontrollers through I2C and I2S serial interfaces. The I2C interface is used for control command transfer. The I2S interface is used for Audio
data output.
A typical interface of AK4954 to a Microchip PIC32 device is provided in the following diagram:
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 237
Features
The AK4954 Codec supports the following features:
• Audio Interface Format: MSB first
• ADC: 24-bit MSB justified, 16/24-bit I2S
• DAC: 24-bit MSB justified, 1-6bit LSB justified, 24-bit LSB justified, 16/24-bit I2S
• Sampling Frequency Range: 8 kHz to 192 kHz
• Digital Volume Control: +12dB ~ .115dB, 0.5dB Step
• SoftMute: On and Off
• Master Clock Frequencies: 32 fs/64 fs/128 fs/256 fs
Using the Library
This topic describes the basic architecture of the AK4954 Codec Driver Library and provides information and examples on its use.
Description
Interface Header File: drv_ak4954.h
The interface to the AK4954 Codec Driver library is defined in the drv_ak4954.h header file. Any C language source (.c) file that uses the
AK4954 Codec Driver library should include this header.
Please refer to the What is MPLAB Harmony? section for how the driver interacts with the framework.
Abstraction Model
This library provides a low-level abstraction of the AK4954 Codec Driver Library on the Microchip family microcontrollers with a convenient C
language interface. This topic describes how that abstraction is modeled in software and introduces the library's interface.
Description
The abstraction model shown in the following diagram depicts how the AK4954 Codec Driver is positioned in the MPLAB Harmony framework. The
AK4954 Codec Driver uses the SPI and I2S drivers for control and audio data transfers to the AK4954 module.
AK4954 Driver Abstraction Model
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 238
Library Overview
Refer to the Driver Library Overview section for information on how the driver operates in a system.
The AK4954 Codec Driver Library provides an API interface to transfer control commands and digital audio data to the serially interfaced AK4954
DAC module. The library interface routines are divided into various sub-sections, which address one of the blocks or the overall operation of the
AK4954 Codec Driver Library.
Library Interface Section Description
System Functions Provides system module interfaces, device initialization, deinitialization,
reinitialization, tasks and status functions.
Status Functions Provides status functions.
Other Functions Provides driver specific miscellaneous functions such as sampling rate setting, control
command functions, etc.
Data Types and Constants These data types and constants are required while interacting and setting up the
AK4954 Codec Driver Library.
How the Library Works
The library provides interfaces to support:
• System Functionality
• Client Functionality
System Access
This topic describes system initialization, implementations, and includes a system access code example.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 239
Description
System Initialization
The system performs the initialization of the device driver with settings that affect only the instance of the device that is being initialized. During
system initialization, each instance of the AK4954 module would be initialized with the following configuration settings (either passed dynamically
at run time using DRV_AK4954_INIT or by using Initialization Overrides) that are supported by the specific AK4954 device hardware:
• Device requested power state: one of the System Module Power States. For specific details please refer to Data Types and Constants in the
Library Interface section.
• I2C driver module index. The module index should be same as the one used in initializing the I2C Driver.
• I2S driver module index. The module index should be same as the one used in initializing the I2S Driver.
• Sampling rate
• Audio data format. The audio data format should match with the audio data format settings done in I2S driver initialization
• Power down pin port initialization
• Queue size for the audio data transmit buffer
The DRV_AK4954_Initialize API returns an object handle of the type SYS_MODULE_OBJ. The object handle returned by the Initialize interface
would be used by the other system interfaces such as DRV_ AK4954_Deinitialize, DRV_ AK4954_Status and DRV_I2S_Tasks.
Implementations
The AK4954 Codec Driver can has the following implementation:
Description MPLAB Harmony Components
Dedicated hardware for control (I2C) and data (I2S) interface. Standard MPLAB Harmony drivers for I2C and I2S interfaces.
Example:
DRV_AK4954_INIT drvak4954Codec0InitData =
{
.moduleInit.value = SYS_MODULE_POWER_RUN_FULL,
.i2sDriverModuleIndex = DRV_AK4954_I2S_DRIVER_MODULE_INDEX_IDX0,
.i2cDriverModuleIndex = DRV_AK4954_I2C_DRIVER_MODULE_INDEX_IDX0,
.volume = DRV_AK4954_VOLUME,
.queueSizeTransmit = DRV_AK4954_TRANSMIT_QUEUE_SIZE,
};
// Initialize the I2C driver
DRV_I2C0_Initialize();
// Initialize the I2S driver. The I2S module index should be same as the one used in initializing
// the I2S driver.
sysObj.drvI2S0 = DRV_I2S_Initialize(DRV_I2S_INDEX_0, (SYS_MODULE_INIT *)&drvI2S0InitData);
// Initialize the Codec driver
sysObj.drvak4954Codec0 = DRV_AK4954_Initialize(DRV_AK4954_INDEX_0, (SYS_MODULE_INIT
*)&drvak4954Codec0InitData);
if (SYS_MODULE_OBJ_INVALID == AK4954DevObject)
{
// Handle error
}
Task Routine
The DRV_AK4954_Tasks will be called from the System Task Service.
Client Access
For the application to start using an instance of the module, it must call the DRV_AK4954_Open function. The DRV_AK4954_Open provides a
driver handle to the AK4954 Codec Driver instance for operations. If the driver is deinitialized using the function DRV_AK4954_Deinitialize, the
application must call the DRV_AK4954_Open function again to set up the instance of the driver.
For the various options available for IO_INTENT, please refer to Data Types and Constants in the Library Interface section.
Client Operations
This topic provides information on client operations and includes a control command and audio buffered data operation flow diagram.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 240
Description
Client operations provide the API interface for control command and audio data transfer to the AK4954 Codec.
The following AK4954 Codec specific control command functions are provided:
• DRV_AK4954_SamplingRateSet
• DRV_AK4954_SamplingRateGet
• DRV_AK4954_VolumeSet
• DRV_AK4954_VolumeGet
• DRV_AK4954_MuteOn
• DRV_AK4954_MuteOff
• DRV_AK4954_IntExtMicSet
• DRV_AK4954_MonoStereoMicSet
These functions schedule a non-blocking control command transfer operation. These functions submit the control command request to the AK4954
Codec. These functions submit the control command request to I2C Driver transmit queue, the request is processed immediately if it is the first
request, or processed when the previous request is complete.
DRV_AK4954_BufferAddWrite, DRV_AK4954_BufferAddRead, and DRV_AK4954_BufferAddWriteRead are buffered data operation functions.
These functions schedule non-blocking audio data transfer operations. These functions add the request to I2S Driver transmit or receive buffer
queue depends on the request type, and are executed immediately if it is the first buffer, or executed later when the previous buffer is complete.
The driver notifies the client with DRV_AK4954_BUFFER_EVENT_COMPLETE, DRV_AK4954_BUFFER_EVENT_ERROR, or
DRV_AK4954_BUFFER_EVENT_ABORT events.
The following diagram illustrates the control commands and audio buffered data operations.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 241
Note:
It is not necessary to close and reopen the client between multiple transfers.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 242
Configuring the Library
Macros
Name Description
DRV_AK4954_BCLK_BIT_CLK_DIVISOR Indicates whether the initilization of the AK4954 codec should be delayed.
DRV_AK4954_CLIENTS_NUMBER Sets up the maximum number of clients that can be connected to any
hardware instance.
DRV_AK4954_INPUT_REFCLOCK Identifies the input REFCLOCK source to generate the MCLK to codec.
DRV_AK4954_INSTANCES_NUMBER Sets up the maximum number of hardware instances that can be supported
DRV_AK4954_MCLK_SAMPLE_FREQ_MULTPLIER Sets up the MCLK to LRCK Ratio to Generate Audio Stream for specified
sampling frequency
DRV_AK4954_MCLK_SOURCE Indicate the input clock frequency to generate the MCLK to codec.
DRV_AK4954_QUEUE_DEPTH_COMBINED Number of entries of all queues in all instances of the driver.
Description
The configuration of the AK4954 Codec Driver is based on the file system_config.h.
This header file contains the configuration selection for the AK4954 Codec Driver. Based on the selections made, the driver may support the
selected features. These configuration settings will apply to all instances of the AK4954 Codec Driver.
This header can be placed anywhere, the path of this header needs to be present in the include search path for a successful build. Refer to the
Applications Help section for more details.
DRV_AK4954_BCLK_BIT_CLK_DIVISOR Macro
Indicates whether the initilization of the AK4954 codec should be delayed.
File
drv_ak4954_config_template.h
C
#define DRV_AK4954_BCLK_BIT_CLK_DIVISOR
Description
AK4954 Delay Initialization
If the AK4954 Codec shares its RESET pin with another peripheral, such as a Bluetooth module, then this define should be true, in order to
indicate the AK4954 Codec should starts its initialization only after the other peripheral has completed theirs. It is set in the MHC menu with the
checkbox: "Delay driver initialization (due to shared RESET pin)"
Remarks
This needs to be set, for example, in the case where the AK4954 and the BM64 share a common PDN (power down) or RESET pin on the PIC32
Bluetooth Audio Development Kit (BTADK).
DRV_AK4954_CLIENTS_NUMBER Macro
Sets up the maximum number of clients that can be connected to any hardware instance.
File
drv_ak4954_config_template.h
C
#define DRV_AK4954_CLIENTS_NUMBER DRV_AK4954_INSTANCES_NUMBER
Description
AK4954 Client Count Configuration
Sets up the maximum number of clients that can be connected to any hardware instance. Typically only one client could be connected to one
hardware instance. This value represents the total number of clients to be supported across all hardware instances. Therefore, if there are five
AK4954 hardware interfaces, this number will be 5.
Remarks
None.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 243
DRV_AK4954_INPUT_REFCLOCK Macro
Identifies the input REFCLOCK source to generate the MCLK to codec.
File
drv_ak4954_config_template.h
C
#define DRV_AK4954_INPUT_REFCLOCK
Description
AK4954 Input reference clock
Identifies the input REFCLOCK source to generate the MCLK to codec.
Remarks
None.
DRV_AK4954_INSTANCES_NUMBER Macro
Sets up the maximum number of hardware instances that can be supported
File
drv_ak4954_config_template.h
C
#define DRV_AK4954_INSTANCES_NUMBER
Description
AK4954 driver objects configuration
Sets up the maximum number of hardware instances that can be supported. It is recommended that this number be set exactly equal to the
number of AK4954 CODEC modules that are needed by the application. Hardware Instance support consumes RAM memory space. If this macro
is not defined, then the driver will be built statically.
Remarks
None.
DRV_AK4954_MCLK_SAMPLE_FREQ_MULTPLIER Macro
Sets up the MCLK to LRCK Ratio to Generate Audio Stream for specified sampling frequency
File
drv_ak4954_config_template.h
C
#define DRV_AK4954_MCLK_SAMPLE_FREQ_MULTPLIER
Description
AK4954 MCLK to LRCK Ratio to Generate Audio Stream
Sets up the MCLK to LRCK Ratio to Generate Audio Stream for specified sampling frequency I2S sampling frequency
Supported MCLK to Sampling frequency Ratios are as below 256fs, 384fs, 512fs, 768fs or 1152fs
Remarks
None
DRV_AK4954_MCLK_SOURCE Macro
Indicate the input clock frequency to generate the MCLK to codec.
File
drv_ak4954_config_template.h
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 244
C
#define DRV_AK4954_MCLK_SOURCE
Description
AK4954 Data Interface Master Clock Speed configuration
Indicate the input clock frequency to generate the MCLK to codec.
Remarks
None.
DRV_AK4954_QUEUE_DEPTH_COMBINED Macro
Number of entries of all queues in all instances of the driver.
File
drv_ak4954_config_template.h
C
#define DRV_AK4954_QUEUE_DEPTH_COMBINED
Description
AK4954 Driver Buffer Queue Entries
This macro defined the number of entries of all queues in all instances of the driver.
Each hardware instance supports a buffer queue for transmit operations. The size of queue is specified either in driver initialization (for dynamic
build) or by macros (for static build). The hardware instance transmit buffer queue will queue transmit buffers submitted by the
DRV_AK4954_BufferAddWrite function.
A buffer queue will contains buffer queue entries, each related to a BufferAdd request. This configuration macro defines total number of buffer
entries that will be available for use between all AK4954 driver hardware instances. The buffer queue entries are allocated to individual hardware
instances as requested by hardware instances. Once the request is processed, the buffer queue entry is free for use by other hardware instances.
The total number of buffer entries in the system determines the ability of the driver to service non blocking write requests. If a free buffer entry is
not available, the driver will not add the request and will return an invalid buffer handle. More the number of buffer entries, greater the ability of the
driver to service and add requests to its queue. A hardware instance additionally can queue up as many buffer entries as specified by its transmit
buffer queue size.
As an example, consider the case of static single client driver application where full duplex non blocking operation is desired without queuing, the
minimum transmit queue depth and minimum receive queue depth should be 1. Hence the total number of buffer entries should be 2.
As an example, consider the case of a dynamic driver (say two instances) where instance one will queue up to three write requests and up to two
read requests, and instance two will queue up to two write requests and up to six read requests, the value of this macro should be 13 (2 + 3 + 2 +
6).
Configuring the MHC
Provides examples on how to configure the MPLAB Harmony Configurator (MHC) for a specific driver.
Description
The following three figures show examples of MHC configurations for the AK4954 Codec Driver, I2S Driver, and the I2C Driver.
Figure 1: AK4954 Codec Driver MHC Configuration
Figure 2: I2S Driver MHC Configuration
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 245
Figure 3: I2C Driver MHC Configuration
Migrating the AK4954 Driver From Earlier Versions of Microchip Harmony
Prior to version 1.08 of MPLAB Harmony, the AK4954 Codec Driver Library used the static I2C driver implementation. Beginning with v1.08 of
MPLAB Harmony, applications must use the Dynamic Driver implementation with the MHC configured as shown in Figure 3. In addition, PIC32MZ
configurations require the "Include Force Write I2C Function (Master Mode Only - Ignore NACK from Slave)" option to be selected.
Building the Library
This section lists the files that are available in the AK4954 Codec Driver Library.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 246
Description
This section list the files that are available in the /src folder of the AK4954 Codec Driver. It lists which files need to be included in the build based
on either a hardware feature present on the board or configuration option selected by the system.
The following three tables list and describe the header (.h) and source (.c) files that implement this library. The parent folder for these files is
/framework/driver/codec/ak4954.
Interface File(s)
This table lists and describes the header files that must be included (i.e., using #include) by any code that uses this library.
Source File Name Description
/drv_ak4954.h Header file that exports the driver API.
Required File(s)
All of the required files listed in the following table are automatically added into the MPLAB X IDE project by the MHC
when the library is selected for use.
This table lists and describes the source and header files that must always be included in the MPLAB X IDE project to build this library.
Source File Name Description
/src/dynamic/drv_ak4954.c This file contains implementation of the AK4954 Codec Driver.
Optional File(s)
This table lists and describes the source and header files that may optionally be included if required for the desired implementation.
Source File Name Description
N/A No optional files are available for this library.
Module Dependencies
The AK4954 Codec Driver Library depends on the following modules:
• I2S Driver Library
• I2C Driver Library
Library Interface
a) System Interaction Functions
Name Description
DRV_AK4954_Initialize Initializes hardware and data for the instance of the AK4954 DAC module.
Implementation: Dynamic
DRV_AK4954_Deinitialize Deinitializes the specified instance of the AK4954 driver module.
Implementation: Dynamic
DRV_AK4954_Open Opens the specified AK4954 driver instance and returns a handle to it.
Implementation: Dynamic
DRV_AK4954_Close Closes an opened-instance of the AK4954 driver.
Implementation: Dynamic
DRV_AK4954_Tasks Maintains the driver's control and data interface state machine.
Implementation: Dynamic
DRV_AK4954_CommandEventHandlerSet This function allows a client to identify a command event handling function for the
driver to call back when the last submitted command have finished.
Implementation: Dynamic
DRV_AK4954_BufferEventHandlerSet This function allows a client to identify a buffer event handling function for the driver
to call back when queued buffer transfers have finished.
DRV_AK4954_SamplingRateSet This function sets the sampling rate of the media stream.
Implementation: Dynamic
DRV_AK4954_SetAudioCommunicationMode This function provides a run time audio format configuration
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 247
b) Status Functions
Name Description
DRV_AK4954_SamplingRateGet This function gets the sampling rate set on the DAC AK4954.
Implementation: Dynamic
DRV_AK4954_Status Gets the current status of the AK4954 driver module.
Implementation: Dynamic
DRV_AK4954_VersionGet This function returns the version of AK4954 driver.
Implementation: Dynamic
DRV_AK4954_VersionStrGet This function returns the version of AK4954 driver in string format.
Implementation: Dynamic
DRV_AK4954_VolumeGet This function gets the volume for AK4954 CODEC.
Implementation: Dynamic
c) Other Functions
Name Description
DRV_AK4954_VolumeSet This function sets the volume for AK4954 CODEC.
Implementation: Dynamic
DRV_AK4954_BufferAddRead Schedule a non-blocking driver read operation.
DRV_AK4954_BufferAddWrite Schedule a non-blocking driver write operation.
Implementation: Dynamic
DRV_AK4954_BufferAddWriteRead Schedule a non-blocking driver write-read operation.
Implementation: Dynamic
DRV_AK4954_IntExtMicSet This function sets up the codec for the X32 DB internal or the external microphone use.
DRV_AK4954_MicSet This function sets up the codec for the internal or the AK4954 Mic1 or Mic2 input.
DRV_AK4954_MonoStereoMicSet This function sets up the codec for the Mono or Stereo microphone mode.
DRV_AK4954_MuteOff This function disables AK4954 output for soft mute.
Implementation: Dynamic
DRV_AK4954_MuteOn This function allows AK4954 output for soft mute on.
Implementation: Dynamic
d) Data Types and Constants
Name Description
DRV_AK4954_AUDIO_DATA_FORMAT Identifies the Serial Audio data interface format.
DRV_AK4954_BUFFER_EVENT Identifies the possible events that can result from a buffer add request.
DRV_AK4954_BUFFER_EVENT_HANDLER Pointer to a AK4954 Driver Buffer Event handler function
DRV_AK4954_BUFFER_HANDLE Handle identifying a write buffer passed to the driver.
DRV_AK4954_CHANNEL Identifies Left/Right Audio channel
DRV_AK4954_COMMAND_EVENT_HANDLER Pointer to a AK4954 Driver Command Event Handler Function
DRV_AK4954_DIGITAL_BLOCK_CONTROL Identifies Bass-Boost Control function
DRV_AK4954_INIT Defines the data required to initialize or reinitialize the AK4954 driver
DRV_AK4954_INT_EXT_MIC Identifies the Mic input source.
DRV_AK4954_MIC This is type DRV_AK4954_MIC.
DRV_AK4954_MONO_STEREO_MIC Identifies the Mic input as Mono / Stereo.
DRV_AK4954_BUFFER_HANDLE_INVALID Definition of an invalid buffer handle.
DRV_AK4954_COUNT Number of valid AK4954 driver indices
DRV_AK4954_INDEX_0 AK4954 driver index definitions
DRV_AK4954_INDEX_1 This is macro DRV_AK4954_INDEX_1.
DRV_AK4954_INDEX_2 This is macro DRV_AK4954_INDEX_2.
DRV_AK4954_INDEX_3 This is macro DRV_AK4954_INDEX_3.
DRV_AK4954_INDEX_4 This is macro DRV_AK4954_INDEX_4.
DRV_AK4954_INDEX_5 This is macro DRV_AK4954_INDEX_5.
Description
This section describes the API functions of the AK4954 Codec Driver library.
Refer to each section for a detailed description.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 248
a) System Interaction Functions
DRV_AK4954_Initialize Function
Initializes hardware and data for the instance of the AK4954 DAC module.
Implementation: Dynamic
File
drv_ak4954.h
C
SYS_MODULE_OBJ DRV_AK4954_Initialize(const SYS_MODULE_INDEX drvIndex, const SYS_MODULE_INIT * const init);
Returns
If successful, returns a valid handle to a driver instance object. Otherwise, it returns SYS_MODULE_OBJ_INVALID.
Description
This routine initializes the AK4954 driver instance for the specified driver index, making it ready for clients to open and use it. The initialization data
is specified by the init parameter. The initialization may fail if the number of driver objects allocated are insufficient or if the specified driver instance
is already initialized.
Remarks
This routine must be called before any other AK4954 routine is called.
This routine should only be called once during system initialization unless DRV_AK4954_Deinitialize is called to deinitialize the driver instance.
This routine will NEVER block for hardware access.
Preconditions
DRV_I2S_Initialize must be called before calling this function to initialize the data interface of this CODEC driver. Also DRV_I2C_Initialize must be
called before calling this function to initialize the control interface of this CODEC driver.
Example
DRV_AK4954_INIT init;
SYS_MODULE_OBJ objectHandle;
init->inUse = true;
init->status = SYS_STATUS_BUSY;
init->numClients = 0;
init->i2sDriverModuleIndex = ak4954Init->i2sDriverModuleIndex;
init->i2cDriverModuleIndex = ak4954Init->i2cDriverModuleIndex;
init->samplingRate = DRV_AK4954_AUDIO_SAMPLING_RATE;
init->audioDataFormat = DRV_AK4954_AUDIO_DATA_FORMAT_MACRO;
for(index=0; index < DRV_AK4954_NUMBER_OF_CHANNELS; index++)
{
init->volume[index] = ak4954Init->volume;
}
init->isInInterruptContext = false;
init->commandCompleteCallback = (DRV_AK4954_COMMAND_EVENT_HANDLER)0;
init->commandContextData = 0;
init->mclk_multiplier = DRV_AK4954_MCLK_SAMPLE_FREQ_MULTPLIER;
objectHandle = DRV_AK4954_Initialize(DRV_AK4954_0, (SYS_MODULE_INIT*)init);
if (SYS_MODULE_OBJ_INVALID == objectHandle)
{
// Handle error
}
Parameters
Parameters Description
drvIndex Identifier for the driver instance to be initialized
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 249
init Pointer to the data structure containing any data necessary to initialize the hardware. This
pointer may be null if no data is required and default initialization is to be used.
Function
SYS_MODULE_OBJ DRV_AK4954_Initialize
(
const SYS_MODULE_INDEX drvIndex,
const SYS_MODULE_INIT *const init
);
DRV_AK4954_Deinitialize Function
Deinitializes the specified instance of the AK4954 driver module.
Implementation: Dynamic
File
drv_ak4954.h
C
void DRV_AK4954_Deinitialize(SYS_MODULE_OBJ object);
Returns
None.
Description
Deinitializes the specified instance of the AK4954 driver module, disabling its operation (and any hardware). Invalidates all the internal data.
Remarks
Once the Initialize operation has been called, the De-initialize operation must be called before the Initialize operation can be called again. This
routine will NEVER block waiting for hardware.
Preconditions
Function DRV_AK4954_Initialize should have been called before calling this function.
Example
SYS_MODULE_OBJ object; // Returned from DRV_AK4954_Initialize
SYS_STATUS status;
DRV_AK4954_Deinitialize(object);
status = DRV_AK4954_Status(object);
if (SYS_MODULE_DEINITIALIZED != status)
{
// Check again later if you need to know
// when the driver is deinitialized.
}
Parameters
Parameters Description
object Driver object handle, returned from the DRV_AK4954_Initialize routine
Function
void DRV_AK4954_Deinitialize( SYS_MODULE_OBJ object)
DRV_AK4954_Open Function
Opens the specified AK4954 driver instance and returns a handle to it.
Implementation: Dynamic
File
drv_ak4954.h
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 250
C
DRV_HANDLE DRV_AK4954_Open(const SYS_MODULE_INDEX iDriver, const DRV_IO_INTENT ioIntent);
Returns
If successful, the routine returns a valid open-instance handle (a number identifying both the caller and the module instance).
If an error occurs, the return value is DRV_HANDLE_INVALID. Error can occur
• if the number of client objects allocated via DRV_AK4954_CLIENTS_NUMBER is insufficient.
• if the client is trying to open the driver but driver has been opened exclusively by another client.
• if the driver hardware instance being opened is not initialized or is invalid.
• if the ioIntent options passed are not relevant to this driver.
Description
This routine opens the specified AK4954 driver instance and provides a handle that must be provided to all other client-level operations to identify
the caller and the instance of the driver. The ioIntent parameter defines how the client interacts with this driver instance.
The DRV_IO_INTENT_BLOCKING and DRV_IO_INTENT_NONBLOCKING ioIntent options are not relevant to this driver. All the data transfer
functions of this driver are non blocking.
AK4954 can be opened with DRV_IO_INTENT_WRITE, or DRV_IO_INTENT_READ or DRV_IO_INTENT_WRITEREAD io_intent option. This
decides whether the driver is used for headphone output, or microphone input or both modes simultaneously.
Specifying a DRV_IO_INTENT_EXCLUSIVE will cause the driver to provide exclusive access to this client. The driver cannot be opened by any
other client.
Remarks
The handle returned is valid until the DRV_AK4954_Close routine is called. This routine will NEVER block waiting for hardware.If the requested
intent flags are not supported, the routine will return DRV_HANDLE_INVALID. This function is thread safe in a RTOS application. It should not be
called in an ISR.
Preconditions
Function DRV_AK4954_Initialize must have been called before calling this function.
Example
DRV_HANDLE handle;
handle = DRV_AK4954_Open(DRV_AK4954_INDEX_0, DRV_IO_INTENT_WRITEREAD | DRV_IO_INTENT_EXCLUSIVE);
if (DRV_HANDLE_INVALID == handle)
{
// Unable to open the driver
// May be the driver is not initialized or the initialization
// is not complete.
}
Parameters
Parameters Description
drvIndex Identifier for the object instance to be opened
ioIntent Zero or more of the values from the enumeration DRV_IO_INTENT "ORed" together to
indicate the intended use of the driver. See function description for details.
Function
DRV_HANDLE DRV_AK4954_Open
(
const SYS_MODULE_INDEX drvIndex,
const DRV_IO_INTENT ioIntent
)
DRV_AK4954_Close Function
Closes an opened-instance of the AK4954 driver.
Implementation: Dynamic
File
drv_ak4954.h
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 251
C
void DRV_AK4954_Close(const DRV_HANDLE handle);
Returns
None.
Description
This routine closes an opened-instance of the AK4954 driver, invalidating the handle. Any buffers in the driver queue that were submitted by this
client will be removed. After calling this routine, the handle passed in "handle" must not be used with any of the remaining driver routines. A new
handle must be obtained by calling DRV_AK4954_Open before the caller may use the driver again
Remarks
Usually there is no need for the driver client to verify that the Close operation has completed. The driver will abort any ongoing operations when
this routine is called.
Preconditions
The DRV_AK4954_Initialize routine must have been called for the specified AK4954 driver instance.
DRV_AK4954_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE handle; // Returned from DRV_AK4954_Open
DRV_AK4954_Close(handle);
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
void DRV_AK4954_Close( DRV_Handle handle )
DRV_AK4954_Tasks Function
Maintains the driver's control and data interface state machine.
Implementation: Dynamic
File
drv_ak4954.h
C
void DRV_AK4954_Tasks(SYS_MODULE_OBJ object);
Returns
None.
Description
This routine is used to maintain the driver's internal control and data interface state machine and implement its control and data interface
implementations. This function should be called from the SYS_Tasks() function.
Remarks
This routine is normally not called directly by an application. It is called by the system's Tasks routine (SYS_Tasks).
Preconditions
The DRV_AK4954_Initialize routine must have been called for the specified AK4954 driver instance.
Example
SYS_MODULE_OBJ object; // Returned from DRV_AK4954_Initialize
while (true)
{
DRV_AK4954_Tasks (object);
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 252
// Do other tasks
}
Parameters
Parameters Description
object Object handle for the specified driver instance (returned from DRV_AK4954_Initialize)
Function
void DRV_AK4954_Tasks(SYS_MODULE_OBJ object);
DRV_AK4954_CommandEventHandlerSet Function
This function allows a client to identify a command event handling function for the driver to call back when the last submitted command have
finished.
Implementation: Dynamic
File
drv_ak4954.h
C
void DRV_AK4954_CommandEventHandlerSet(DRV_HANDLE handle, const DRV_AK4954_COMMAND_EVENT_HANDLER
eventHandler, const uintptr_t contextHandle);
Returns
None.
Description
This function allows a client to identify a command event handling function for the driver to call back when the last submitted command have
finished.
When a client calls DRV_AK4954_BufferAddWrite function, it is provided with a handle identifying the buffer that was added to the driver's buffer
queue. The driver will pass this handle back to the client by calling "eventHandler" function when the buffer transfer has completed.
The event handler should be set before the client performs any "AK4954 CODEC Specific Client Routines" operations that could generate events.
The event handler once set, persists until the client closes the driver or sets another event handler (which could be a "NULL" pointer to indicate no
callback).
Remarks
If the client does not want to be notified when the command has completed, it does not need to register a callback.
Preconditions
The DRV_AK4954_Initialize routine must have been called for the specified AK4954 driver instance.
DRV_AK4954_Open must have been called to obtain a valid opened device handle.
Example
MY_APP_OBJ myAppObj;
uint8_t mybuffer[MY_BUFFER_SIZE];
DRV_AK4954_BUFFER_HANDLE bufferHandle;
// myAK4954Handle is the handle returned
// by the DRV_AK4954_Open function.
// Client registers an event handler with driver
DRV_AK4954_CommandEventHandlerSet(myAK4954Handle,
APP_AK4954CommandEventHandler, (uintptr_t)&myAppObj);
DRV_AK4954_DeEmphasisFilterSet(myAK4954Handle, DRV_AK4954_DEEMPHASIS_FILTER_44_1KHZ)
// Event is received when
// the buffer is processed.
void APP_AK4954CommandEventHandler(uintptr_t contextHandle)
{
// contextHandle points to myAppObj.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 253
switch(event)
{
// Last Submitted command is completed.
// Perform further processing here
}
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
eventHandler Pointer to the event handler function.
context The value of parameter will be passed back to the client unchanged, when the eventHandler
function is called. It can be used to identify any client specific data object that identifies the
instance of the client module (for example, it may be a pointer to the client module's state
structure).
Function
void DRV_AK4954_CommandEventHandlerSet
(
DRV_HANDLE handle,
const DRV_AK4954_COMMAND_EVENT_HANDLER eventHandler,
const uintptr_t contextHandle
)
DRV_AK4954_BufferEventHandlerSet Function
This function allows a client to identify a buffer event handling function for the driver to call back when queued buffer transfers have finished.
File
drv_ak4954.h
C
void DRV_AK4954_BufferEventHandlerSet(DRV_HANDLE handle, const DRV_AK4954_BUFFER_EVENT_HANDLER
eventHandler, const uintptr_t contextHandle);
Returns
None.
Description
This function allows a client to identify a buffer event handling function for the driver to call back when queued buffer transfers have finished. When
a client calls DRV_AK4954_BufferAddRead function, it is provided with a handle identifying the buffer that was added to the driver's buffer queue.
The driver will pass this handle back to the client by calling "eventHandler" function when the buffer transfer has completed.
The event handler should be set before the client performs any "buffer add" operations that could generate events. The event handler once set,
persists until the client closes the driver or sets another event handler (which could be a "NULL" pointer to indicate no callback).
Remarks
If the client does not want to be notified when the queued buffer transfer has completed, it does not need to register a callback.
Preconditions
The DRV_AK4954_Initialize routine must have been called for the specified AK4954 driver instance.
DRV_AK4954_Open must have been called to obtain a valid opened device handle.
Example
MY_APP_OBJ myAppObj;
uint8_t mybuffer[MY_BUFFER_SIZE];
DRV_AK4954_BUFFER_HANDLE bufferHandle;
// myAK4954Handle is the handle returned
// by the DRV_AK4954_Open function.
// Client registers an event handler with driver
DRV_AK4954_BufferEventHandlerSet(myAK4954Handle,
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 254
APP_AK4954BufferEventHandler, (uintptr_t)&myAppObj);
DRV_AK4954_BufferAddRead(myAK4954handle, &bufferHandle
myBuffer, MY_BUFFER_SIZE);
if(DRV_AK4954_BUFFER_HANDLE_INVALID == bufferHandle)
{
// Error handling here
}
// Event is received when
// the buffer is processed.
void APP_AK4954BufferEventHandler(DRV_AK4954_BUFFER_EVENT event,
DRV_AK4954_BUFFER_HANDLE bufferHandle, uintptr_t contextHandle)
{
// contextHandle points to myAppObj.
switch(event)
{
case DRV_AK4954_BUFFER_EVENT_COMPLETE:
// This means the data was transferred.
break;
case DRV_AK4954_BUFFER_EVENT_ERROR:
// Error handling here.
break;
default:
break;
}
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
eventHandler Pointer to the event handler function.
context The value of parameter will be passed back to the client unchanged, when the eventHandler
function is called. It can be used to identify any client specific data object that identifies the
instance of the client module (for example, it may be a pointer to the client module's state
structure).
Function
void DRV_AK4954_BufferEventHandlerSet
(
DRV_HANDLE handle,
const DRV_AK4954_BUFFER_EVENT_HANDLER eventHandler,
const uintptr_t contextHandle
)
DRV_AK4954_SamplingRateSet Function
This function sets the sampling rate of the media stream.
Implementation: Dynamic
File
drv_ak4954.h
C
void DRV_AK4954_SamplingRateSet(DRV_HANDLE handle, uint32_t samplingRate);
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 255
Returns
None.
Description
This function sets the media sampling rate for the client handle.
Remarks
None.
Preconditions
The DRV_AK4954_Initialize routine must have been called for the specified AK4954 driver instance.
DRV_AK4954_Open must have been called to obtain a valid opened device handle.
Example
// myAK4954Handle is the handle returned
// by the DRV_AK4954_Open function.
DRV_AK4954_SamplingRateSet(myAK4954Handle, 48000); //Sets 48000 media sampling rate
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
void DRV_AK4954_SamplingRateSet( DRV_HANDLE handle, uint32_t samplingRate)
DRV_AK4954_SetAudioCommunicationMode Function
This function provides a run time audio format configuration
File
drv_ak4954.h
C
void DRV_AK4954_SetAudioCommunicationMode(DRV_HANDLE handle, const DATA_LENGTH dl, const SAMPLE_LENGTH sl);
Returns
None
Description
This function sets up audio mode in I2S protocol
Remarks
None.
Preconditions
The DRV_AK4954_Initialize routine must have been called for the specified AK4954 driver instance.
DRV_AK4954_Open must have been called to obtain a valid opened device handle.
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
dl Data length for I2S audio interface
sl Left/Right Sample Length for I2S audio interface
Function
void DRV_AK4954_SetAudioCommunicationMode
(
DRV_HANDLE handle,
const DATA_LENGTH dl,
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 256
const SAMPLE_LENGTH sl
)
b) Status Functions
DRV_AK4954_SamplingRateGet Function
This function gets the sampling rate set on the DAC AK4954.
Implementation: Dynamic
File
drv_ak4954.h
C
uint32_t DRV_AK4954_SamplingRateGet(DRV_HANDLE handle);
Returns
None.
Description
This function gets the sampling rate set on the DAC AK4954.
Remarks
None.
Preconditions
The DRV_AK4954_Initialize routine must have been called for the specified AK4954 driver instance.
DRV_AK4954_Open must have been called to obtain a valid opened device handle.
Example
uint32_t baudRate;
// myAK4954Handle is the handle returned
// by the DRV_AK4954_Open function.
baudRate = DRV_AK4954_SamplingRateGet(myAK4954Handle);
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
uint32_t DRV_AK4954_SamplingRateGet( DRV_HANDLE handle)
DRV_AK4954_Status Function
Gets the current status of the AK4954 driver module.
Implementation: Dynamic
File
drv_ak4954.h
C
SYS_STATUS DRV_AK4954_Status(SYS_MODULE_OBJ object);
Returns
SYS_STATUS_DEINITIALIZED - Indicates that the driver has been deinitialized
SYS_STATUS_READY - Indicates that any previous module operation for the specified module has completed
SYS_STATUS_BUSY - Indicates that a previous module operation for the specified module has not yet completed
SYS_STATUS_ERROR - Indicates that the specified module is in an error state
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 257
Description
This routine provides the current status of the AK4954 driver module.
Remarks
A driver can opened only when its status is SYS_STATUS_READY.
Preconditions
Function DRV_AK4954_Initialize should have been called before calling this function.
Example
SYS_MODULE_OBJ object; // Returned from DRV_AK4954_Initialize
SYS_STATUS AK4954Status;
AK4954Status = DRV_AK4954_Status(object);
if (SYS_STATUS_READY == AK4954Status)
{
// This means the driver can be opened using the
// DRV_AK4954_Open() function.
}
Parameters
Parameters Description
object Driver object handle, returned from the DRV_AK4954_Initialize routine
Function
SYS_STATUS DRV_AK4954_Status( SYS_MODULE_OBJ object)
DRV_AK4954_VersionGet Function
This function returns the version of AK4954 driver.
Implementation: Dynamic
File
drv_ak4954.h
C
uint32_t DRV_AK4954_VersionGet();
Returns
returns the version of AK4954 driver.
Description
The version number returned from the DRV_AK4954_VersionGet function is an unsigned integer in the following decimal format. * 10000 + * 100
+ Where the numbers are represented in decimal and the meaning is the same as above. Note that there is no numerical representation of
release type.
Remarks
None.
Preconditions
None.
Example 1
For version "0.03a", return: 0 * 10000 + 3 * 100 + 0 For version "1.00", return: 1 * 100000 + 0 * 100 + 0
Example 2
uint32_t AK4954version;
AK4954version = DRV_AK4954_VersionGet();
Function
uint32_t DRV_AK4954_VersionGet( void )
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 258
DRV_AK4954_VersionStrGet Function
This function returns the version of AK4954 driver in string format.
Implementation: Dynamic
File
drv_ak4954.h
C
int8_t* DRV_AK4954_VersionStrGet();
Returns
returns a string containing the version of AK4954 driver.
Description
The DRV_AK4954_VersionStrGet function returns a string in the format: ".[.][]" Where: is the AK4954 driver's version number. is the AK4954
driver's version number. is an optional "patch" or "dot" release number (which is not included in the string if it equals "00"). is an optional release
type ("a" for alpha, "b" for beta ? not the entire word spelled out) that is not included if the release is a production version (I.e. Not an alpha or beta).
The String does not contain any spaces.
Remarks
None.
Preconditions
None.
Example 1
"0.03a" "1.00"
Example 2
int8_t *AK4954string;
AK4954string = DRV_AK4954_VersionStrGet();
Function
int8_t* DRV_AK4954_VersionStrGet(void)
DRV_AK4954_VolumeGet Function
This function gets the volume for AK4954 CODEC.
Implementation: Dynamic
File
drv_ak4954.h
C
uint8_t DRV_AK4954_VolumeGet(DRV_HANDLE handle, DRV_AK4954_CHANNEL chan);
Returns
None.
Description
This functions gets the current volume programmed to the CODEC AK4954.
Remarks
None.
Preconditions
The DRV_AK4954_Initialize routine must have been called for the specified AK4954 driver instance.
DRV_AK4954_Open must have been called to obtain a valid opened device handle.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 259
Example
// myAppObj is an application specific object.
MY_APP_OBJ myAppObj;
uint8_t volume;
// myAK4954Handle is the handle returned
// by the DRV_AK4954_Open function.
volume = DRV_AK4954_VolumeGet(myAK4954Handle,DRV_AK4954_CHANNEL_LEFT);
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
chan Audio channel volume to be set
Function
uint8_t DRV_AK4954_VolumeGet( DRV_HANDLE handle, DRV_AK4954_CHANNEL chan)
c) Other Functions
DRV_AK4954_VolumeSet Function
This function sets the volume for AK4954 CODEC.
Implementation: Dynamic
File
drv_ak4954.h
C
void DRV_AK4954_VolumeSet(DRV_HANDLE handle, DRV_AK4954_CHANNEL channel, uint8_t volume);
Returns
None.
Description
This functions sets the volume value from 0-255. The codec has DAC value to volume range mapping as :- 00 H : +12dB FF H : -115dB In order to
make the volume value to dB mapping monotonically increasing from 00 to FF, re-mapping is introduced which reverses the volume value to dB
mapping as well as normalizes the volume range to a more audible dB range. The current driver implementation assumes that all dB values under
-60 dB are inaudible to the human ear. Re-Mapped values 00 H : -60 dB FF H : +12 dB
Remarks
None.
Preconditions
The DRV_AK4954_Initialize routine must have been called for the specified AK4954 driver instance.
DRV_AK4954_Open must have been called to obtain a valid opened device handle.
Example
// myAppObj is an application specific object.
MY_APP_OBJ myAppObj;
uint8_t mybuffer[MY_BUFFER_SIZE];
DRV_BUFFER_HANDLE bufferHandle;
// myAK4954Handle is the handle returned
// by the DRV_AK4954_Open function.
DRV_AK4954_VolumeSet(myAK4954Handle, DRV_AK4954_CHANNEL_LEFT, 120);
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 260
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
chan Audio channel volume to be set
volume volume value specified in the range 0-255 (0x00 to 0xFF)
Function
void DRV_AK4954_VolumeSet( DRV_HANDLE handle, DRV_AK4954_CHANNEL channel, uint8_t volume);
DRV_AK4954_BufferAddRead Function
Schedule a non-blocking driver read operation.
File
drv_ak4954.h
C
void DRV_AK4954_BufferAddRead(const DRV_HANDLE handle, DRV_AK4954_BUFFER_HANDLE * bufferHandle, void *
buffer, size_t size);
Returns
The bufferHandle parameter will contain the return buffer handle. This will be DRV_AK4954_BUFFER_HANDLE_INVALID if the function was not
successful.
Description
This function schedules a non-blocking read operation. The function returns with a valid buffer handle in the bufferHandle argument if the read
request was scheduled successfully. The function adds the request to the hardware instance receive queue and returns immediately. While the
request is in the queue, the application buffer is owned by the driver and should not be modified. The function returns
DRV_AK4954_BUFFER_HANDLE_INVALID
• if a buffer could not be allocated to the request
• if the input buffer pointer is NULL
• if the buffer size is 0.
• if the queue is full or the queue depth is insufficient
If the requesting client registered an event callback with the driver, the driver will issue a DRV_AK4954_BUFFER_EVENT_COMPLETE event if
the buffer was processed successfully of DRV_AK4954_BUFFER_EVENT_ERROR event if the buffer was not processed successfully.
Remarks
This function is thread safe in a RTOS application. It can be called from within the AK4954 Driver Buffer Event Handler that is registered by this
client. It should not be called in the event handler associated with another AK4954 driver instance. It should not otherwise be called directly in an
ISR.
Preconditions
The DRV_AK4954_Initialize routine must have been called for the specified AK4954 device instance and the DRV_AK4954_Status must have
returned SYS_STATUS_READY.
DRV_AK4954_Open must have been called to obtain a valid opened device handle.
DRV_IO_INTENT_READ must have been specified in the DRV_AK4954_Open call.
Parameters
Parameters Description
handle Handle of the AK4954 instance as return by the DRV_AK4954_Open function.
buffer Data to be transmitted.
size Buffer size in bytes.
bufferHandle Pointer to an argument that will contain the return buffer handle.
Function
void DRV_AK4954_BufferAddRead
(
const DRV_HANDLE handle,
DRV_AK4954_BUFFER_HANDLE *bufferHandle,
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 261
void *buffer, size_t size
)
DRV_AK4954_BufferAddWrite Function
Schedule a non-blocking driver write operation.
Implementation: Dynamic
File
drv_ak4954.h
C
void DRV_AK4954_BufferAddWrite(const DRV_HANDLE handle, DRV_AK4954_BUFFER_HANDLE * bufferHandle, void *
buffer, size_t size);
Returns
The bufferHandle parameter will contain the return buffer handle. This will be DRV_AK4954_BUFFER_HANDLE_INVALID if the function was not
successful.
Description
This function schedules a non-blocking write operation. The function returns with a valid buffer handle in the bufferHandle argument if the write
request was scheduled successfully. The function adds the request to the hardware instance transmit queue and returns immediately. While the
request is in the queue, the application buffer is owned by the driver and should not be modified. The function returns
DRV_AK4954_BUFFER_HANDLE_INVALID
• if a buffer could not be allocated to the request
• if the input buffer pointer is NULL
• if the buffer size is 0.
• if the queue is full or the queue depth is insufficient
If the requesting client registered an event callback with the driver, the driver will issue a DRV_AK4954_BUFFER_EVENT_COMPLETE event if
the buffer was processed successfully of DRV_AK4954_BUFFER_EVENT_ERROR event if the buffer was not processed successfully.
Remarks
This function is thread safe in a RTOS application. It can be called from within the AK4954 Driver Buffer Event Handler that is registered by this
client. It should not be called in the event handler associated with another AK4954 driver instance. It should not otherwise be called directly in an
ISR.
Preconditions
The DRV_AK4954_Initialize routine must have been called for the specified AK4954 device instance and the DRV_AK4954_Status must have
returned SYS_STATUS_READY.
DRV_AK4954_Open must have been called to obtain a valid opened device handle.
DRV_IO_INTENT_WRITE must have been specified in the DRV_AK4954_Open call.
Example
MY_APP_OBJ myAppObj;
uint8_t mybuffer[MY_BUFFER_SIZE];
DRV_AK4954_BUFFER_HANDLE bufferHandle;
// myAK4954Handle is the handle returned
// by the DRV_AK4954_Open function.
// Client registers an event handler with driver
DRV_AK4954_BufferEventHandlerSet(myAK4954Handle,
APP_AK4954BufferEventHandler, (uintptr_t)&myAppObj);
DRV_AK4954_BufferAddWrite(myAK4954handle, &bufferHandle
myBuffer, MY_BUFFER_SIZE);
if(DRV_AK4954_BUFFER_HANDLE_INVALID == bufferHandle)
{
// Error handling here
}
// Event is received when
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 262
// the buffer is processed.
void APP_AK4954BufferEventHandler(DRV_AK4954_BUFFER_EVENT event,
DRV_AK4954_BUFFER_HANDLE bufferHandle, uintptr_t contextHandle)
{
// contextHandle points to myAppObj.
switch(event)
{
case DRV_AK4954_BUFFER_EVENT_COMPLETE:
// This means the data was transferred.
break;
case DRV_AK4954_BUFFER_EVENT_ERROR:
// Error handling here.
break;
default:
break;
}
}
Parameters
Parameters Description
handle Handle of the AK4954 instance as return by the DRV_AK4954_Open function.
buffer Data to be transmitted.
size Buffer size in bytes.
bufferHandle Pointer to an argument that will contain the return buffer handle.
Function
void DRV_AK4954_BufferAddWrite
(
const DRV_HANDLE handle,
DRV_AK4954_BUFFER_HANDLE *bufferHandle,
void *buffer, size_t size
)
DRV_AK4954_BufferAddWriteRead Function
Schedule a non-blocking driver write-read operation.
Implementation: Dynamic
File
drv_ak4954.h
C
void DRV_AK4954_BufferAddWriteRead(const DRV_HANDLE handle, DRV_AK4954_BUFFER_HANDLE * bufferHandle, void *
transmitBuffer, void * receiveBuffer, size_t size);
Returns
The bufferHandle parameter will contain the return buffer handle. This will be DRV_AK4954_BUFFER_HANDLE_INVALID if the function was not
successful.
Description
This function schedules a non-blocking write-read operation. The function returns with a valid buffer handle in the bufferHandle argument if the
write-read request was scheduled successfully. The function adds the request to the hardware instance queue and returns immediately. While the
request is in the queue, the application buffer is owned by the driver and should not be modified. The function returns
DRV_AK4954_BUFFER_EVENT_COMPLETE:
• if a buffer could not be allocated to the request
• if the input buffer pointer is NULL
• if the client opened the driver for read only or write only
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 263
• if the buffer size is 0
• if the queue is full or the queue depth is insufficient
If the requesting client registered an event callback with the driver, the driver will issue a DRV_AK4954_BUFFER_EVENT_COMPLETE event if
the buffer was processed successfully of DRV_AK4954_BUFFER_EVENT_ERROR event if the buffer was not processed successfully.
Remarks
This function is thread safe in a RTOS application. It can be called from within the AK4954 Driver Buffer Event Handler that is registered by this
client. It should not be called in the event handler associated with another AK4954 driver instance. It should not otherwise be called directly in an
ISR.
This function is useful when there is valid read expected for every AK4954 write. The transmit and receive size must be same.
Preconditions
The DRV_AK4954_Initialize routine must have been called for the specified AK4954 device instance and the DRV_AK4954_Status must have
returned SYS_STATUS_READY.
DRV_AK4954_Open must have been called to obtain a valid opened device handle.
DRV_IO_INTENT_READWRITE must have been specified in the DRV_AK4954_Open call.
Example
MY_APP_OBJ myAppObj;
uint8_t mybufferTx[MY_BUFFER_SIZE];
uint8_t mybufferRx[MY_BUFFER_SIZE];
DRV_AK4954_BUFFER_HANDLE bufferHandle;
// myak4954Handle is the handle returned
// by the DRV_AK4954_Open function.
// Client registers an event handler with driver
DRV_AK4954_BufferEventHandlerSet(myak4954Handle,
APP_AK4954BufferEventHandler, (uintptr_t)&myAppObj);
DRV_AK4954_BufferAddWriteRead(myak4954handle, &bufferHandle,
mybufferTx,mybufferRx,MY_BUFFER_SIZE);
if(DRV_AK4954_BUFFER_HANDLE_INVALID == bufferHandle)
{
// Error handling here
}
// Event is received when
// the buffer is processed.
void APP_AK4954BufferEventHandler(DRV_AK4954_BUFFER_EVENT event,
DRV_AK4954_BUFFER_HANDLE bufferHandle, uintptr_t contextHandle)
{
// contextHandle points to myAppObj.
switch(event)
{
case DRV_AK4954_BUFFER_EVENT_COMPLETE:
// This means the data was transferred.
break;
case DRV_AK4954_BUFFER_EVENT_ERROR:
// Error handling here.
break;
default:
break;
}
}
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 264
Parameters
Parameters Description
handle Handle of the AK4954 instance as returned by the DRV_AK4954_Open function
bufferHandle Pointer to an argument that will contain the return buffer handle
transmitBuffer The buffer where the transmit data will be stored
receiveBuffer The buffer where the received data will be stored
size Buffer size in bytes
Function
void DRV_AK4954_BufferAddWriteRead
(
const DRV_HANDLE handle,
DRV_AK4954_BUFFER_HANDLE *bufferHandle,
void *transmitBuffer,
void *receiveBuffer,
size_t size
)
DRV_AK4954_IntExtMicSet Function
This function sets up the codec for the X32 DB internal or the external microphone use.
File
drv_ak4954.h
C
void DRV_AK4954_IntExtMicSet(DRV_HANDLE handle, DRV_AK4954_INT_EXT_MIC micInput);
Returns
None
Description
This function sets up the codec for the internal or the external microphone use.
Remarks
None.
Preconditions
The DRV_AK4954_Initialize routine must have been called for the specified AK4954 driver instance.
DRV_AK4954_Open must have been called to obtain a valid opened device handle.
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
micInput Internal vs External mic input
Function
void DRV_AK4954_IntExtMicSet
DRV_AK4954_MicSet Function
This function sets up the codec for the internal or the AK4954 Mic1 or Mic2 input.
File
drv_ak4954.h
C
void DRV_AK4954_MicSet(DRV_HANDLE handle, DRV_AK4954_MIC micInput);
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 265
Returns
None
Description
This function sets up the codec.
Remarks
None.
Preconditions
The DRV_AK4954_Initialize routine must have been called for the specified AK4954 driver instance.
DRV_AK4954_Open must have been called to obtain a valid opened device handle.
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
micInput Internal vs External mic input
Function
void DRV_AK4954_IntMic12Set
DRV_AK4954_MonoStereoMicSet Function
This function sets up the codec for the Mono or Stereo microphone mode.
File
drv_ak4954.h
C
void DRV_AK4954_MonoStereoMicSet(DRV_HANDLE handle, DRV_AK4954_MONO_STEREO_MIC mono_stereo_mic);
Returns
None
Description
This function sets up the codec for the Mono or Stereo microphone mode.
Remarks
None.
Preconditions
The DRV_AK4954_Initialize routine must have been called for the specified AK4954 driver instance.
DRV_AK4954_Open must have been called to obtain a valid opened device handle.
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
void DRV_AK4954_MonoStereoMicSet( DRV_HANDLE handle);
DRV_AK4954_MuteOff Function
This function disables AK4954 output for soft mute.
Implementation: Dynamic
File
drv_ak4954.h
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 266
C
void DRV_AK4954_MuteOff(DRV_HANDLE handle);
Returns
None.
Description
This function disables AK4954 output for soft mute.
Remarks
None.
Preconditions
The DRV_AK4954_Initialize routine must have been called for the specified AK4954 driver instance.
DRV_AK4954_Open must have been called to obtain a valid opened device handle.
Example
// myAppObj is an application specific object.
MY_APP_OBJ myAppObj;
uint8_t mybuffer[MY_BUFFER_SIZE];
DRV_BUFFER_HANDLE bufferHandle;
// myAK4954Handle is the handle returned
// by the DRV_AK4954_Open function.
DRV_AK4954_MuteOff(myAK4954Handle); //AK4954 output soft mute disabled
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
void DRV_AK4954_MuteOff( DRV_HANDLE handle)
DRV_AK4954_MuteOn Function
This function allows AK4954 output for soft mute on.
Implementation: Dynamic
File
drv_ak4954.h
C
void DRV_AK4954_MuteOn(DRV_HANDLE handle);
Returns
None.
Description
This function Enables AK4954 output for soft mute.
Remarks
None.
Preconditions
The DRV_AK4954_Initialize routine must have been called for the specified AK4954 driver instance.
DRV_AK4954_Open must have been called to obtain a valid opened device handle.
Example
// myAppObj is an application specific object.
MY_APP_OBJ myAppObj;
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 267
uint8_t mybuffer[MY_BUFFER_SIZE];
DRV_BUFFER_HANDLE bufferHandle;
// myAK4954Handle is the handle returned
// by the DRV_AK4954_Open function.
DRV_AK4954_MuteOn(myAK4954Handle); //AK4954 output soft muted
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
void DRV_AK4954_MuteOn( DRV_HANDLE handle);
d) Data Types and Constants
DRV_AK4954_AUDIO_DATA_FORMAT Enumeration
Identifies the Serial Audio data interface format.
File
drv_ak4954.h
C
typedef enum {
DRV_AK4954_AUDIO_DATA_FORMAT_24BIT_MSB_SDTO_24BIT_LSB_SDTI = 0,
DRV_AK4954_AUDIO_DATA_FORMAT_24BIT_MSB_SDTO_16BIT_LSB_SDTI,
DRV_AK4954_AUDIO_DATA_FORMAT_24BIT_MSB_SDTO_24BIT_MSB_SDTI,
DRV_AK4954_AUDIO_DATA_FORMAT_I2S_16BIT_24BIT,
DRV_AK4954_AUDIO_DATA_FORMAT_32BIT_MSB_SDTO_32BIT_MSB_SDTI = 6,
DRV_AK4954_AUDIO_DATA_FORMAT_I2S_32BIT
} DRV_AK4954_AUDIO_DATA_FORMAT;
Description
AK4954 Audio data format
This enumeration identifies Serial Audio data interface format.
DRV_AK4954_BUFFER_EVENT Enumeration
Identifies the possible events that can result from a buffer add request.
File
drv_ak4954.h
C
typedef enum {
DRV_AK4954_BUFFER_EVENT_COMPLETE,
DRV_AK4954_BUFFER_EVENT_ERROR,
DRV_AK4954_BUFFER_EVENT_ABORT
} DRV_AK4954_BUFFER_EVENT;
Members
Members Description
DRV_AK4954_BUFFER_EVENT_COMPLETE Data was transferred successfully.
DRV_AK4954_BUFFER_EVENT_ERROR Error while processing the request
DRV_AK4954_BUFFER_EVENT_ABORT Data transfer aborted (Applicable in DMA mode)
Description
AK4954 Driver Events
This enumeration identifies the possible events that can result from a buffer add request caused by the client calling either the
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 268
DRV_AK4954_BufferAddWrite() function.
Remarks
One of these values is passed in the "event" parameter of the event handling callback function that the client registered with the driver by calling
the DRV_AK4954_BufferEventHandlerSet function when a buffer transfer request is completed.
DRV_AK4954_BUFFER_EVENT_HANDLER Type
Pointer to a AK4954 Driver Buffer Event handler function
File
drv_ak4954.h
C
typedef void (* DRV_AK4954_BUFFER_EVENT_HANDLER)(DRV_AK4954_BUFFER_EVENT event, DRV_AK4954_BUFFER_HANDLE
bufferHandle, uintptr_t contextHandle);
Returns
None.
Description
AK4954 Driver Buffer Event Handler Function
This data type defines the required function signature for the AK4954 driver buffer event handling callback function. A client must register a pointer
to a buffer event handling function who's function signature (parameter and return value types) match the types specified by this function pointer in
order to receive buffer related event calls back from the driver.
The parameters and return values are described here and a partial example implementation is provided.
Remarks
If the event is DRV_AK4954_BUFFER_EVENT_COMPLETE, this means that the data was transferred successfully.
If the event is DRV_AK4954_BUFFER_EVENT_ERROR, this means that the data was not transferred successfully. The bufferHandle parameter
contains the buffer handle of the buffer that failed. The DRV_AK4954_BufferProcessedSizeGet() function can be called to find out how many bytes
were processed.
The bufferHandle parameter contains the buffer handle of the buffer that associated with the event.
The context parameter contains a handle to the client context, provided at the time the event handling function was registered using the
DRV_AK4954_BufferEventHandlerSet function. This context handle value is passed back to the client as the "context" parameter. It can be any
value necessary to identify the client context or instance (such as a pointer to the client's data) instance of the client that made the buffer add
request.
The buffer handle in bufferHandle expires after this event handler exits. In that the buffer object that was allocated is deallocated by the driver after
the event handler exits.
The event handler function executes in the data driver (I2S) peripheral's interrupt context when the driver is configured for interrupt mode
operation. It is recommended of the application to not perform process intensive or blocking operations with in this function.
DRV_AK4954_BufferAddWrite function can be called in the event handler to add a buffer to the driver queue.
Example
void APP_MyBufferEventHandler( DRV_AK4954_BUFFER_EVENT event,
DRV_AK4954_BUFFER_HANDLE bufferHandle,
uintptr_t context )
{
MY_APP_DATA_STRUCT pAppData = (MY_APP_DATA_STRUCT) context;
switch(event)
{
case DRV_AK4954_BUFFER_EVENT_COMPLETE:
// Handle the completed buffer.
break;
case DRV_AK4954_BUFFER_EVENT_ERROR:
default:
// Handle error.
break;
}
}
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 269
Parameters
Parameters Description
event Identifies the type of event
bufferHandle Handle identifying the buffer to which the event relates
context Value identifying the context of the application that registered the event handling function.
DRV_AK4954_BUFFER_HANDLE Type
Handle identifying a write buffer passed to the driver.
File
drv_ak4954.h
C
typedef uintptr_t DRV_AK4954_BUFFER_HANDLE;
Description
AK4954 Driver Buffer Handle
A buffer handle value is returned by a call to the DRV_AK4954_BufferAddWrite() function. This handle is associated with the buffer passed into the
function and it allows the application to track the completion of the data from (or into) that buffer. The buffer handle value returned from the "buffer
add" function is returned back to the client by the "event handler callback" function registered with the driver.
The buffer handle assigned to a client request expires when the client has been notified of the completion of the buffer transfer (after event handler
function that notifies the client returns) or after the buffer has been retired by the driver if no event handler callback was set.
Remarks
None
DRV_AK4954_CHANNEL Enumeration
Identifies Left/Right Audio channel
File
drv_ak4954.h
C
typedef enum {
DRV_AK4954_CHANNEL_LEFT,
DRV_AK4954_CHANNEL_RIGHT,
DRV_AK4954_CHANNEL_LEFT_RIGHT,
DRV_AK4954_NUMBER_OF_CHANNELS
} DRV_AK4954_CHANNEL;
Description
AK4954 Audio Channel
This enumeration identifies Left/Right Audio channel
Remarks
None.
DRV_AK4954_COMMAND_EVENT_HANDLER Type
Pointer to a AK4954 Driver Command Event Handler Function
File
drv_ak4954.h
C
typedef void (* DRV_AK4954_COMMAND_EVENT_HANDLER)(uintptr_t contextHandle);
Returns
None.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 270
Description
AK4954 Driver Command Event Handler Function
This data type defines the required function signature for the AK4954 driver command event handling callback function.
A command is a control instruction to the AK4954 CODEC. Example Mute ON/OFF, Zero Detect Enable/Disable etc.
A client must register a pointer to a command event handling function who's function signature (parameter and return value types) match the types
specified by this function pointer in order to receive command related event calls back from the driver.
The parameters and return values are described here and a partial example implementation is provided.
Remarks
The occurrence of this call back means that the last control command was transferred successfully.
The context parameter contains a handle to the client context, provided at the time the event handling function was registered using the
DRV_AK4954_CommandEventHandlerSet function. This context handle value is passed back to the client as the "context" parameter. It can be
any value necessary to identify the client context or instance (such as a pointer to the client's data) instance of the client that made the buffer add
request.
The event handler function executes in the control data driver interrupt context. It is recommended of the application to not perform process
intensive or blocking operations with in this function.
Example
void APP_AK4954CommandEventHandler( uintptr_t context )
{
MY_APP_DATA_STRUCT pAppData = (MY_APP_DATA_STRUCT) context;
// Last Submitted command is completed.
// Perform further processing here
}
Parameters
Parameters Description
context Value identifying the context of the application that registered the event handling function.
DRV_AK4954_DIGITAL_BLOCK_CONTROL Enumeration
Identifies Bass-Boost Control function
File
drv_ak4954.h
C
typedef enum {
DRV_AK4954_RECORDING_MODE,
DRV_AK4954_PLAYBACK_MODE,
DRV_AK4954_RECORDING_PLAYBACK_2_MODE,
DRV_AK4954_LOOPBACK_MODE
} DRV_AK4954_DIGITAL_BLOCK_CONTROL;
Members
Members Description
DRV_AK4954_RECORDING_MODE This is the default setting
DRV_AK4954_PLAYBACK_MODE Min control
DRV_AK4954_RECORDING_PLAYBACK_2_MODE Medium control
DRV_AK4954_LOOPBACK_MODE Maximum control
Description
AK4954 Bass-Boost Control
This enumeration identifies the settings for Bass-Boost Control function.
Remarks
None.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 271
DRV_AK4954_INIT Structure
Defines the data required to initialize or reinitialize the AK4954 driver
File
drv_ak4954.h
C
typedef struct {
SYS_MODULE_INIT moduleInit;
SYS_MODULE_INDEX i2sDriverModuleIndex;
SYS_MODULE_INDEX i2cDriverModuleIndex;
uint32_t samplingRate;
uint8_t volume;
DRV_AK4954_AUDIO_DATA_FORMAT audioDataFormat;
bool delayDriverInitialization;
} DRV_AK4954_INIT;
Members
Members Description
SYS_MODULE_INIT moduleInit; System module initialization
SYS_MODULE_INDEX i2sDriverModuleIndex; Identifies data module(I2S) driver ID for data interface of CODEC
SYS_MODULE_INDEX i2cDriverModuleIndex; Identifies data module(I2C) driver ID for control interface of CODEC
uint32_t samplingRate; Sampling rate
uint8_t volume; Volume
DRV_AK4954_AUDIO_DATA_FORMAT
audioDataFormat;
Identifies the Audio data format
bool delayDriverInitialization; true if driver initialization should be delayed due to shared RESET pin
Description
AK4954 Driver Initialization Data
This data type defines the data required to initialize or reinitialize the AK4954 CODEC driver.
Remarks
None.
DRV_AK4954_INT_EXT_MIC Enumeration
Identifies the Mic input source.
File
drv_ak4954.h
C
typedef enum {
INT_MIC,
EXT_MIC
} DRV_AK4954_INT_EXT_MIC;
Description
AK4954 Mic Internal / External Input
This enumeration identifies the Mic input source.
DRV_AK4954_MIC Enumeration
File
drv_ak4954.h
C
typedef enum {
MIC1 = 0,
MIC2,
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 272
MIC3,
DRV_AK4954_NUMBER_OF_MIC
} DRV_AK4954_MIC;
Members
Members Description
MIC1 = 0 INT_MIC
MIC2 EXT_MIC
MIC3 LINE-IN
Description
This is type DRV_AK4954_MIC.
DRV_AK4954_MONO_STEREO_MIC Enumeration
Identifies the Mic input as Mono / Stereo.
File
drv_ak4954.h
C
typedef enum {
ALL_ZEROS,
MONO_RIGHT_CHANNEL,
MONO_LEFT_CHANNEL,
STEREO
} DRV_AK4954_MONO_STEREO_MIC;
Description
AK4954 Mic Mono / Stereo Input
This enumeration identifies the Mic input as Mono / Stereo.
DRV_AK4954_BUFFER_HANDLE_INVALID Macro
Definition of an invalid buffer handle.
File
drv_ak4954.h
C
#define DRV_AK4954_BUFFER_HANDLE_INVALID ((DRV_AK4954_BUFFER_HANDLE)(-1))
Description
AK4954 Driver Invalid Buffer Handle
This is the definition of an invalid buffer handle. An invalid buffer handle is returned by DRV_AK4954_BufferAddWrite() function if the buffer add
request was not successful.
Remarks
None
DRV_AK4954_COUNT Macro
Number of valid AK4954 driver indices
File
drv_ak4954.h
C
#define DRV_AK4954_COUNT
Description
AK4954 Driver Module Count
This constant identifies the maximum number of AK4954 Driver instances that should be defined by the application. Defining more instances than
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 273
this constant will waste RAM memory space.
This constant can also be used by the application to identify the number of AK4954 instances on this microcontroller.
Remarks
This value is part-specific.
DRV_AK4954_INDEX_0 Macro
AK4954 driver index definitions
File
drv_ak4954.h
C
#define DRV_AK4954_INDEX_0 0
Description
Driver AK4954 Module Index
These constants provide AK4954 driver index definition.
Remarks
These constants should be used in place of hard-coded numeric literals. These values should be passed into the DRV_AK4954_Initialize and
DRV_AK4954_Open routines to identify the driver instance in use.
DRV_AK4954_INDEX_1 Macro
File
drv_ak4954.h
C
#define DRV_AK4954_INDEX_1 1
Description
This is macro DRV_AK4954_INDEX_1.
DRV_AK4954_INDEX_2 Macro
File
drv_ak4954.h
C
#define DRV_AK4954_INDEX_2 2
Description
This is macro DRV_AK4954_INDEX_2.
DRV_AK4954_INDEX_3 Macro
File
drv_ak4954.h
C
#define DRV_AK4954_INDEX_3 3
Description
This is macro DRV_AK4954_INDEX_3.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 274
DRV_AK4954_INDEX_4 Macro
File
drv_ak4954.h
C
#define DRV_AK4954_INDEX_4 4
Description
This is macro DRV_AK4954_INDEX_4.
DRV_AK4954_INDEX_5 Macro
File
drv_ak4954.h
C
#define DRV_AK4954_INDEX_5 5
Description
This is macro DRV_AK4954_INDEX_5.
Files
Files
Name Description
drv_ak4954.h AK4954 CODEC Driver Interface header file
drv_ak4954_config_template.h AK4954 Codec Driver Configuration Template.
Description
This section lists the source and header files used by the AK4954Codec Driver Library.
drv_ak4954.h
AK4954 CODEC Driver Interface header file
Enumerations
Name Description
DRV_AK4954_AUDIO_DATA_FORMAT Identifies the Serial Audio data interface format.
DRV_AK4954_BUFFER_EVENT Identifies the possible events that can result from a buffer add request.
DRV_AK4954_CHANNEL Identifies Left/Right Audio channel
DRV_AK4954_DIGITAL_BLOCK_CONTROL Identifies Bass-Boost Control function
DRV_AK4954_INT_EXT_MIC Identifies the Mic input source.
DRV_AK4954_MIC This is type DRV_AK4954_MIC.
DRV_AK4954_MONO_STEREO_MIC Identifies the Mic input as Mono / Stereo.
Functions
Name Description
DRV_AK4954_BufferAddRead Schedule a non-blocking driver read operation.
DRV_AK4954_BufferAddWrite Schedule a non-blocking driver write operation.
Implementation: Dynamic
DRV_AK4954_BufferAddWriteRead Schedule a non-blocking driver write-read operation.
Implementation: Dynamic
DRV_AK4954_BufferEventHandlerSet This function allows a client to identify a buffer event handling function for the driver
to call back when queued buffer transfers have finished.
DRV_AK4954_Close Closes an opened-instance of the AK4954 driver.
Implementation: Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 275
DRV_AK4954_CommandEventHandlerSet This function allows a client to identify a command event handling function for the
driver to call back when the last submitted command have finished.
Implementation: Dynamic
DRV_AK4954_Deinitialize Deinitializes the specified instance of the AK4954 driver module.
Implementation: Dynamic
DRV_AK4954_Initialize Initializes hardware and data for the instance of the AK4954 DAC module.
Implementation: Dynamic
DRV_AK4954_IntExtMicSet This function sets up the codec for the X32 DB internal or the external microphone
use.
DRV_AK4954_MicSet This function sets up the codec for the internal or the AK4954 Mic1 or Mic2 input.
DRV_AK4954_MonoStereoMicSet This function sets up the codec for the Mono or Stereo microphone mode.
DRV_AK4954_MuteOff This function disables AK4954 output for soft mute.
Implementation: Dynamic
DRV_AK4954_MuteOn This function allows AK4954 output for soft mute on.
Implementation: Dynamic
DRV_AK4954_Open Opens the specified AK4954 driver instance and returns a handle to it.
Implementation: Dynamic
DRV_AK4954_SamplingRateGet This function gets the sampling rate set on the DAC AK4954.
Implementation: Dynamic
DRV_AK4954_SamplingRateSet This function sets the sampling rate of the media stream.
Implementation: Dynamic
DRV_AK4954_SetAudioCommunicationMode This function provides a run time audio format configuration
DRV_AK4954_Status Gets the current status of the AK4954 driver module.
Implementation: Dynamic
DRV_AK4954_Tasks Maintains the driver's control and data interface state machine.
Implementation: Dynamic
DRV_AK4954_VersionGet This function returns the version of AK4954 driver.
Implementation: Dynamic
DRV_AK4954_VersionStrGet This function returns the version of AK4954 driver in string format.
Implementation: Dynamic
DRV_AK4954_VolumeGet This function gets the volume for AK4954 CODEC.
Implementation: Dynamic
DRV_AK4954_VolumeSet This function sets the volume for AK4954 CODEC.
Implementation: Dynamic
Macros
Name Description
DRV_AK4954_BUFFER_HANDLE_INVALID Definition of an invalid buffer handle.
DRV_AK4954_COUNT Number of valid AK4954 driver indices
DRV_AK4954_INDEX_0 AK4954 driver index definitions
DRV_AK4954_INDEX_1 This is macro DRV_AK4954_INDEX_1.
DRV_AK4954_INDEX_2 This is macro DRV_AK4954_INDEX_2.
DRV_AK4954_INDEX_3 This is macro DRV_AK4954_INDEX_3.
DRV_AK4954_INDEX_4 This is macro DRV_AK4954_INDEX_4.
DRV_AK4954_INDEX_5 This is macro DRV_AK4954_INDEX_5.
Structures
Name Description
DRV_AK4954_INIT Defines the data required to initialize or reinitialize the AK4954 driver
Types
Name Description
DRV_AK4954_BUFFER_EVENT_HANDLER Pointer to a AK4954 Driver Buffer Event handler function
DRV_AK4954_BUFFER_HANDLE Handle identifying a write buffer passed to the driver.
DRV_AK4954_COMMAND_EVENT_HANDLER Pointer to a AK4954 Driver Command Event Handler Function
Description
AK4954 CODEC Driver Interface
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 276
The AK4954 CODEC device driver interface provides a simple interface to manage the AK4954 106dB 192kHz 24-Bit DAC that can be interfaced
Microchip Microcontroller. This file provides the interface definition for the AK4954 CODEC device driver.
File Name
drv_AK4954.h
Company
Microchip Technology Inc.
drv_ak4954_config_template.h
AK4954 Codec Driver Configuration Template.
Macros
Name Description
DRV_AK4954_BCLK_BIT_CLK_DIVISOR Indicates whether the initilization of the AK4954 codec should be delayed.
DRV_AK4954_CLIENTS_NUMBER Sets up the maximum number of clients that can be connected to any
hardware instance.
DRV_AK4954_INPUT_REFCLOCK Identifies the input REFCLOCK source to generate the MCLK to codec.
DRV_AK4954_INSTANCES_NUMBER Sets up the maximum number of hardware instances that can be supported
DRV_AK4954_MCLK_SAMPLE_FREQ_MULTPLIER Sets up the MCLK to LRCK Ratio to Generate Audio Stream for specified
sampling frequency
DRV_AK4954_MCLK_SOURCE Indicate the input clock frequency to generate the MCLK to codec.
DRV_AK4954_QUEUE_DEPTH_COMBINED Number of entries of all queues in all instances of the driver.
Description
AK4954 Codec Driver Configuration Template
These file provides the list of all the configurations that can be used with the driver. This file should not be included in the driver.
File Name
drv_ak4954_config_template.h
Company
Microchip Technology Inc.
AK7755 Codec Driver Library
This topic describes the AK7755 Codec Driver Library.
Introduction
This library provides an interface to manage the AK7755 Codec that is serially interfaced to a Microchip microcontroller for providing Audio
Solutions.
Description
The AK7755 module is 16/20/24-bit Audio Codec from Asahi Kasei Microdevices Corporation. The AK7755 can be interfaced to Microchip
microcontrollers through I2C and I2S serial interfaces. The I2C interface is used for control command transfer. The I2S interface is used for Audio
data output. A typical interface of the AK7755 Codec to a Microchip PIC32 device is provided in the following diagram:
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 277
Features
The AK7755 Codec supports the following features:
• Two Digital Interfaces (I/F1, I/F2):
• 4-channel/6-channel Digital Signal Input Port: MSB justified 24-bit, LSB justified 24/20/16-bit, I2S
• Short/Long Frame
• 24-bit linear, 8-bit A-law, 8-bit µ-law
• TDM 256 fs (8-channel) MSB Justified and I2S Formats
• SoftMute: On and Off
• Stereo 24-bit ADC:
• Sampling Frequency: fs = 8 kHz ~96 kHz
• ADC Characteristics S/(N+D): 91 dB, DR, S/N: 102 dB
• Two-Channel Analog Input Selector (Differential, Single-ended Input)
• Channel Independent Microphone Analog Gain Amplifier (0 ~18 dB (2 dB Step), 18 ~36 dB (3 dB Step))
• Analog DRC (Dynamic Range Control)
• Channel Independent Digital Volume (24 ~-103 dB, 0.5 dB Step Mute)
• Digital HPF for DC Offset Cancelling
• Mono 24-bit ADC:
• Sampling Frequency: 8 kHz ~ 96 kHz
• ADC Characteristics S/(N+D): 90 dB; DR, S/N: 100 dB
• Line Amplifier: 21 dB ~ -21 dB, 3 dB Step
• Digital Volume (24 dB ~ -103 dB, 0.5 dB step, Mute)
• Digital HPF for DC Offset Cancelling
• Stereo 24-bit DAC:
• Sampling Frequency: fs = 8 kHz ~ 96 kHz
• Digital Volume (12 dB ~ -115 dB, 0.5 step, Mute)
• Digital De-emphasis Filter (tc = 50/15 µs, fs = 32 kHz, 44.1 kHz, 48 kHz)
• Master Clock: 2560 fs (internally generated by PLL from 32, 48, 64, 128, 256 and 384 fs clock)
Using the Library
This topic describes the basic architecture of the AK7755 Codec Driver Library and provides information and examples on its use.
Description
Interface Header File: drv_AK7755.h
The interface to the AK7755 Codec Driver library is defined in the drv_AK7755.h header file. Any C language source (.c) file that uses the
AK7755 Codec Driver library should include this header.
Please refer to the What is MPLAB Harmony? section for how the driver interacts with the framework.
Abstraction Model
This library provides a low-level abstraction of the AK7755 Codec Driver Library on the Microchip family microcontrollers with a convenient C
language interface. This topic describes how that abstraction is modeled in software and introduces the library's interface.
Description
The abstraction model shown in the following diagram depicts how the AK7755 Codec Driver is positioned in the MPLAB Harmony framework. The
AK7755 Codec Driver uses the SPI and I2S drivers for control and audio data transfers to the AK7755 module.
AK7755 Driver Abstraction Model
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 278
Library Overview
Refer to the Driver Library Overview section for information on how the driver operates in a system.
The AK7755 Codec Driver Library provides an API interface to transfer control commands and digital audio data to the serially interfaced AK7755
DAC module. The library interface routines are divided into various sub-sections, which address one of the blocks or the overall operation of the
AK7755 Codec Driver Library.
Library Interface Section Description
System Functions Provides system module interfaces, device initialization, deinitialization,
reinitialization, tasks and status functions.
Status Functions Provides status functions.
Other Functions Provides driver specific miscellaneous functions such as sampling rate setting, control
command functions, etc.
Data Types and Constants These data types and constants are required while interacting and setting up the
AK7755 Codec Driver Library.
How the Library Works
The library provides interfaces to support:
• System Functionality
• Client Functionality
System Access
This topic describes system initialization, implementations, and includes a system access code example.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 279
Description
System Initialization
The system performs the initialization of the device driver with settings that affect only the instance of the device that is being initialized. During
system initialization, each instance of the AK7755 module would be initialized with the following configuration settings (either passed dynamically
at run time using DRV_AK7755_INIT or by using Initialization Overrides) that are supported by the specific AK7755 device hardware:
• Device requested power state: one of the System Module Power States. For specific details please refer to Data Types and Constants in the
Library Interface section.
• I2C driver module index. The module index should be same as the one used in initializing the I2C Driver.
• I2S driver module index. The module index should be same as the one used in initializing the I2S Driver.
• Sampling rate
• Audio data format. The audio data format should match with the audio data format settings done in I2S driver initialization
• Power down pin port initialization
• Queue size for the audio data transmit buffer
The DRV_AK7755_Initialize API returns an object handle of the type SYS_MODULE_OBJ. The object handle returned by the Initialize interface
would be used by the other system interfaces such as DRV_ AK7755_Deinitialize, DRV_ AK7755_Status and DRV_I2S_Tasks.
Implementations
The AK7755 Codec Driver can has the following implementation:
Description MPLAB Harmony Components
Dedicated hardware for control (I2C) and data (I2S) interface. Standard MPLAB Harmony drivers for I2C and I2S interfaces.
Example:
DRV_AK7755_INIT drvak7755Codec0InitData =
{
.moduleInit.value = SYS_MODULE_POWER_RUN_FULL,
.i2sDriverModuleIndex = DRV_AK7755_I2S_DRIVER_MODULE_INDEX_IDX0,
.i2cDriverModuleIndex = DRV_AK7755_I2C_DRIVER_MODULE_INDEX_IDX0,
.volume = DRV_AK7755_VOLUME,
.queueSizeTransmit = DRV_AK7755_TRANSMIT_QUEUE_SIZE,
};
// Initialize the I2C driver
DRV_I2C0_Initialize();
// Initialize the I2S driver. The I2S module index should be same as the one used in initializing
// the I2S driver.
sysObj.drvI2S0 = DRV_I2S_Initialize(DRV_I2S_INDEX_0, (SYS_MODULE_INIT *)&drvI2S0InitData);
// Initialize the Codec driver
sysObj.drvak7755Codec0 = DRV_AK7755_Initialize(DRV_AK7755_INDEX_0, (SYS_MODULE_INIT
*)&drvak7755Codec0InitData);
if (SYS_MODULE_OBJ_INVALID == AK7755DevObject)
{
// Handle error
}
Task Routine
The DRV_AK7755_Tasks will be called from the System Task Service.
Client Access
For the application to start using an instance of the module, it must call the DRV_AK7755_Open function. The DRV_AK7755_Open provides a
driver handle to the AK7755 Codec Driver instance for operations. If the driver is deinitialized using the function DRV_AK7755_Deinitialize, the
application must call the DRV_AK7755_Open function again to set up the instance of the driver.
For the various options available for IO_INTENT, please refer to Data Types and Constants in the Library Interface section.
Client Operations
This topic provides information on client operations and includes a control command and audio buffered data operation flow diagram.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 280
Description
Client operations provide the API interface for control command and audio data transfer to the AK7755 Codec.
The following AK7755 Codec specific control command functions are provided:
• DRV_AK7755_SamplingRateSet
• DRV_AK7755_SamplingRateGet
• DRV_AK7755_VolumeSet
• DRV_AK7755_VolumeGet
• DRV_AK7755_MuteOn
• DRV_AK7755_MuteOff
• DRV_AK7755_IntExtMicSet
• DRV_AK7755_MonoStereoMicSet
These functions schedule a non-blocking control command transfer operation. These functions submit the control command request to the AK7755
Codec. These functions submit the control command request to I2C Driver transmit queue, the request is processed immediately if it is the first
request, or processed when the previous request is complete.
DRV_AK7755_BufferAddWrite, DRV_AK7755_BufferAddRead, and DRV_AK7755_BufferAddWriteRead are buffered data operation functions.
These functions schedule non-blocking audio data transfer operations. These functions add the request to I2S Driver transmit or receive buffer
queue depends on the request type, and are executed immediately if it is the first buffer, or executed later when the previous buffer is complete.
The driver notifies the client with DRV_AK7755_BUFFER_EVENT_COMPLETE, DRV_AK7755_BUFFER_EVENT_ERROR, or
DRV_AK7755_BUFFER_EVENT_ABORT events.
The following diagram illustrates the control commands and audio buffered data operations.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 281
Note:
It is not necessary to close and reopen the client between multiple transfers.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 282
Configuring the Library
Macros
Name Description
DRV_AK7755_BCLK_BIT_CLK_DIVISOR Sets up the BCLK to LRCK ratio to generate the audio stream for the
specified sampling frequency.
DRV_AK7755_CLIENTS_NUMBER Sets up the maximum number of clients that can be connected to any
hardware instance.
DRV_AK7755_INPUT_REFCLOCK Identifies the input REFCLOCK source to generate the MCLK to the codec.
DRV_AK7755_INSTANCES_NUMBER Sets up the maximum number of hardware instances that can be supported
DRV_AK7755_MCLK_SAMPLE_FREQ_MULTPLIER Sets up the MCLK to LRCK ratio to generate the audio stream for the
specified sampling frequency.
DRV_AK7755_MCLK_SOURCE Indicates the input clock frequency to generate the MCLK to the codec.
Description
The configuration of the AK7755 Codec Driver is based on the file system_config.h.
This header file contains the configuration selection for the AK7755 Codec Driver. Based on the selections made, the driver may support the
selected features. These configuration settings will apply to all instances of the AK7755 Codec Driver.
This header can be placed anywhere, the path of this header needs to be present in the include search path for a successful build. Refer to the
Applications Help section for more details.
DRV_AK7755_BCLK_BIT_CLK_DIVISOR Macro
Sets up the BCLK to LRCK ratio to generate the audio stream for the specified sampling frequency.
File
drv_ak7755_config_template.h
C
#define DRV_AK7755_BCLK_BIT_CLK_DIVISOR
Description
AK7755 BCLK to LRCK Ratio to Generate Audio Stream
This macro sets up the BCLK to LRCK ratio to generate the audio stream for the specified sampling frequency.
The following BCLK to LRCK ratios are supported:
• 16-bit data 16-bit channel: 32 fs; therefore, the divisor would be 8
• 16-bit data 32-bit channel: 64 fs; therefore, the divisor would be 4
Remarks
None.
DRV_AK7755_CLIENTS_NUMBER Macro
Sets up the maximum number of clients that can be connected to any hardware instance.
File
drv_ak7755_config_template.h
C
#define DRV_AK7755_CLIENTS_NUMBER DRV_AK7755_INSTANCES_NUMBER
Description
AK7755 Client Count Configuration
This macro sets up the maximum number of clients that can be connected to any hardware instance. Typically only one client could be connected
to one hardware instance. This value represents the total number of clients to be supported across all hardware instances. Therefore, if there are
five AK7755 hardware interfaces, this number will be 5.
Remarks
None.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 283
DRV_AK7755_INPUT_REFCLOCK Macro
Identifies the input REFCLOCK source to generate the MCLK to the codec.
File
drv_ak7755_config_template.h
C
#define DRV_AK7755_INPUT_REFCLOCK
Description
AK7755 Input reference clock
This macro identifies the input REFCLOCK source to generate the MCLK to the codec.
Remarks
None.
DRV_AK7755_INSTANCES_NUMBER Macro
Sets up the maximum number of hardware instances that can be supported
File
drv_ak7755_config_template.h
C
#define DRV_AK7755_INSTANCES_NUMBER
Description
AK7755 driver objects configuration
This macro sets up the maximum number of hardware instances that can be supported. It is recommended that this number be set exactly equal to
the number of AK7755 Codec modules that are needed by the application. Hardware Instance support consumes RAM memory space. If this
macro is not defined, the driver will be built statically.
Remarks
None.
DRV_AK7755_MCLK_SAMPLE_FREQ_MULTPLIER Macro
Sets up the MCLK to LRCK ratio to generate the audio stream for the specified sampling frequency.
File
drv_ak7755_config_template.h
C
#define DRV_AK7755_MCLK_SAMPLE_FREQ_MULTPLIER
Description
AK7755 MCLK to LRCK Ratio to Generate Audio Stream
This macro sets up the MCLK to LRCK ratio to generate the audio stream for the specified I2S sampling frequency.
The supported MCLK to sampling frequency ratios are as follows:
• 256 fs
• 384 fs
• 512 fs
• 768 fs
• 1152 fs
Remarks
None.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 284
DRV_AK7755_MCLK_SOURCE Macro
Indicates the input clock frequency to generate the MCLK to the codec.
File
drv_ak7755_config_template.h
C
#define DRV_AK7755_MCLK_SOURCE
Description
AK7755 Data Interface Master Clock Speed configuration
This macro indicates the input clock frequency to generate the MCLK to the codec.
Remarks
None.
Configuring the MHC
Description
The following three figures show examples of MHC configurations for the AK7755 Codec Driver, I2S Driver, and the I2C Driver.
Figure 1: AK7755 Codec Driver MHC Configuration
Figure 2: I2S Driver MHC Configuration
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 285
Figure 3: I2C Driver MHC Configuration
Migrating the AK7755 Driver From Earlier Versions of Microchip Harmony
Prior to version 1.08 of MPLAB Harmony, the AK7755 Codec Driver Library used the static I2C driver implementation. Beginning with v1.08 of
MPLAB Harmony, applications must use the Dynamic Driver implementation with the MHC configured as shown in Figure 3. In addition, PIC32MZ
configurations require the "Include Force Write I2C Function (Master Mode Only - Ignore NACK from Slave)" option to be selected.
Building the Library
This section lists the files that are available in the AK7755 Codec Driver Library.
Description
This section list the files that are available in the /src folder of the AK7755 Codec Driver. It lists which files need to be included in the build based
on either a hardware feature present on the board or configuration option selected by the system.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 286
The following three tables list and describe the header (.h) and source (.c) files that implement this library. The parent folder for these files is
/framework/driver/codec/ak7755.
Interface File(s)
This table lists and describes the header files that must be included (i.e., using #include) by any code that uses this library.
Source File Name Description
/drv_ak7755.h Header file that exports the driver API.
Required File(s)
All of the required files listed in the following table are automatically added into the MPLAB X IDE project by the MHC
when the library is selected for use.
This table lists and describes the source and header files that must always be included in the MPLAB X IDE project to build this library.
Source File Name Description
/src/dynamic/drv_ak7755.c This file contains implementation of the AK7755 Codec Driver.
Optional File(s)
This table lists and describes the source and header files that may optionally be included if required for the desired implementation.
Source File Name Description
N/A No optional files are available for this library.
Module Dependencies
The AK7755 Codec Driver Library depends on the following modules:
• I2S Driver Library
• I2C Driver Library
Library Interface
a) System Interaction Functions
Name Description
DRV_AK7755_Close Closes an opened-instance of the AK7755 Codec Driver.
DRV_AK7755_Deinitialize Deinitializes the specified instance of the AK7755 Codec Driver module.
DRV_AK7755_Initialize Initializes hardware and data for the instance of the AK7755 DAC module
DRV_AK7755_Open Opens the specified AK7755 Codec Driver instance and returns a handle to it
DRV_AK7755_Tasks Maintains the driver's control and data interface state machine.
DRV_AK7755_BufferEventHandlerSet This function allows a client to identify a buffer event handling function for the driver
to call back when queued buffer transfers have finished.
DRV_AK7755_CommandEventHandlerSet Allows a client to identify a command event handling function for the driver to call
back when the last submitted command have finished.
DRV_AK7755_SamplingRateSet This function sets the sampling rate of the media stream.
DRV_AK7755_SetAudioCommunicationMode This function provides a run time audio format configuration
b) Status Functions
Name Description
DRV_AK7755_SamplingRateGet This function gets the sampling rate set on the AK7755.
Implementation: Dynamic
DRV_AK7755_Status Gets the current status of the AK7755 Codec Driver module.
DRV_AK7755_VersionGet Returns the version of the AK7755 Codec Driver.
DRV_AK7755_VersionStrGet This function returns the version of AK7755 Codec Driver in string format.
DRV_AK7755_VolumeGet Gets the volume for the AK7755 Codec Driver.
c) Other Functions
Name Description
DRV_AK7755_VolumeSet This function sets the volume for AK7755 CODEC.
DRV_AK7755_BufferAddRead Schedule a non-blocking driver read operation.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 287
DRV_AK7755_BufferAddWrite Schedule a non-blocking driver write operation.
DRV_AK7755_BufferAddWriteRead This is function DRV_AK7755_BufferAddWriteRead.
DRV_AK7755_IntExtMicSet Sets up the codec for the internal or the external microphone use.
DRV_AK7755_MonoStereoMicSet Sets up the codec for the Mono or Stereo microphone mode.
DRV_AK7755_MuteOff Disables AK7755 output for soft mute.
DRV_AK7755_MuteOn Allows AK7755 output for soft mute on.
d) Data Types and Constants
Name Description
_DRV_AK7755_H Include files.
DRV_AK7755_BUFFER_HANDLE_INVALID Definition of an invalid buffer handle.
DRV_AK7755_COUNT Number of valid AK7755 Codec Driver indices
DRV_AK7755_INDEX_0 AK7755 driver index definitions
DRV_AK7755_INDEX_1 This is macro DRV_AK7755_INDEX_1.
DRV_AK7755_INDEX_2 This is macro DRV_AK7755_INDEX_2.
DRV_AK7755_INDEX_3 This is macro DRV_AK7755_INDEX_3.
DRV_AK7755_INDEX_4 This is macro DRV_AK7755_INDEX_4.
DRV_AK7755_INDEX_5 This is macro DRV_AK7755_INDEX_5.
DRV_AK7755_BICK_FS_FORMAT This is type DRV_AK7755_BICK_FS_FORMAT.
DRV_AK7755_BUFFER_EVENT Identifies the possible events that can result from a buffer add request.
DRV_AK7755_BUFFER_EVENT_HANDLER Pointer to a AK7755 Driver Buffer Event handler function.
DRV_AK7755_BUFFER_HANDLE Handle identifying a write buffer passed to the driver.
DRV_AK7755_CHANNEL Identifies left/right audio channel.
DRV_AK7755_COMMAND_EVENT_HANDLER Pointer to a AK7755 Codec Driver command event handler function.
DRV_AK7755_DAC_INPUT_FORMAT Identifies the Serial Audio data interface format.
DRV_AK7755_DSP_DIN1_INPUT_FORMAT This is type DRV_AK7755_DSP_DIN1_INPUT_FORMAT.
DRV_AK7755_DSP_DOUT1_OUTPUT_FORMAT This is type DRV_AK7755_DSP_DOUT1_OUTPUT_FORMAT.
DRV_AK7755_DSP_DOUT4_OUTPUT_FORMAT This is type DRV_AK7755_DSP_DOUT4_OUTPUT_FORMAT.
DRV_AK7755_DSP_PROGRAM This is type DRV_AK7755_DSP_PROGRAM.
DRV_AK7755_INIT Defines the data required to initialize or reinitialize the AK7755 Codec Driver.
DRV_AK7755_INT_EXT_MIC Identifies the Mic input source.
DRV_AK7755_LRCK_IF_FORMAT This is type DRV_AK7755_LRCK_IF_FORMAT.
DRV_AK7755_MONO_STEREO_MIC Identifies the Mic input as Mono/Stereo.
DRV_I2C_INDEX This is macro DRV_I2C_INDEX.
DATA_LENGTH in bits
SAMPLE_LENGTH in bits
Description
This section describes the API functions of the AK7755 Codec Driver library.
Refer to each section for a detailed description.
a) System Interaction Functions
DRV_AK7755_Close Function
Closes an opened-instance of the AK7755 Codec Driver.
File
drv_ak7755.h
C
void DRV_AK7755_Close(const DRV_HANDLE handle);
Returns
None.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 288
Description
This function closes an opened-instance of the AK7755 Codec Driver, invalidating the handle. Any buffers in the driver queue that were submitted
by this client will be removed. After calling this function, the handle passed in "handle" must not be used with any of the remaining driver functions.
A new handle must be obtained by calling DRV_AK7755_Open before the caller may use the driver again.
Remarks
Usually there is no need for the driver client to verify that the Close operation has completed. The driver will abort any ongoing operations when
this function is called.
Preconditions
The DRV_AK7755_Initialize function must have been called for the specified AK7755 Codec Driver instance.
DRV_AK7755_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE handle; // Returned from DRV_AK7755_Open
DRV_AK7755_Close(handle);
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
Function
void DRV_AK7755_Close( DRV_Handle handle )
DRV_AK7755_Deinitialize Function
Deinitializes the specified instance of the AK7755 Codec Driver module.
File
drv_ak7755.h
C
void DRV_AK7755_Deinitialize(SYS_MODULE_OBJ object);
Returns
None.
Description
This function deinitializes the specified instance of the AK7755 Codec Driver module, disabling its operation (and any hardware). Invalidates all the
internal data.
Remarks
Once the Initialize operation has been called, the Deinitialize operation must be called before the Initialize operation can be called again. This
function will NEVER block waiting for hardware.
Preconditions
The DRV_AK7755_Initialize function should have been called before calling this function.
Example
SYS_MODULE_OBJ object; // Returned from DRV_AK7755_Initialize
SYS_STATUS status;
DRV_AK7755_Deinitialize(object-->);
status = DRV_AK7755_Status(object);
if (SYS_MODULE_DEINITIALIZED != status)
{
// Check again later if you need to know
// when the driver is deinitialized.
}
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 289
Parameters
Parameters Description
object Driver object handle, returned from the DRV_AK4642_Initialize routine
Function
void DRV_AK7755_Deinitialize( SYS_MODULE_OBJ object)
DRV_AK7755_Initialize Function
Initializes hardware and data for the instance of the AK7755 DAC module
File
drv_ak7755.h
C
SYS_MODULE_OBJ DRV_AK7755_Initialize(const SYS_MODULE_INDEX drvIndex, const SYS_MODULE_INIT * const init);
Returns
If successful, returns a valid handle to a driver instance object. Otherwise, it returns SYS_MODULE_OBJ_INVALID.
Description
This function initializes the AK7755 Codec Driver instance for the specified driver index, making it ready for clients to open and use it. The
initialization data is specified by the init parameter. The initialization may fail if the number of driver objects allocated are insufficient or if the
specified driver instance is already initialized.
Remarks
This function must be called before any other AK7755 function is called.
This function should only be called once during system initialization unless DRV_AK7755_Deinitialize is called to deinitialize the driver instance.
This function will NEVER block for hardware access.
Preconditions
DRV_I2S_Initialize must be called before calling this function to initialize the data interface of this codec driver. DRV_SPI_Initialize must be called
if SPI driver is used for handling the control interface of this codec driver.
Example
DRV_AK7755_INIT init;
SYS_MODULE_OBJ objectHandle;
init->inUse = true;
init->status = SYS_STATUS_BUSY;
init->numClients = 0;
init->i2sDriverModuleIndex = ak7755Init->i2sDriverModuleIndex;
init->i2cDriverModuleIndex = ak7755Init->i2cDriverModuleIndex;
init->samplingRate = DRV_AK7755_AUDIO_SAMPLING_RATE;
init->audioDataFormat = DRV_AK7755_AUDIO_DATA_FORMAT_MACRO;
init->isInInterruptContext = false;
init->commandCompleteCallback = (DRV_AK7755_COMMAND_EVENT_HANDLER)0;
init->commandContextData = 0;
init->mclk_multiplier = DRV_AK7755_MCLK_SAMPLE_FREQ_MULTPLIER;
objectHandle = DRV_AK7755_Initialize(DRV_AK7755_0, (SYS_MODULE_INIT*)init);
if (SYS_MODULE_OBJ_INVALID == objectHandle)
{
// Handle error
}
Parameters
Parameters Description
drvIndex Identifier for the driver instance to be initialized
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 290
init Pointer to the data structure containing any data necessary to initialize the hardware. This
pointer may be null if no data is required and default initialization is to be used.
Function
SYS_MODULE_OBJ DRV_AK7755_Initialize
(
const SYS_MODULE_INDEX drvIndex,
const SYS_MODULE_INIT *const init
);
DRV_AK7755_Open Function
Opens the specified AK7755 Codec Driver instance and returns a handle to it
File
drv_ak7755.h
C
DRV_HANDLE DRV_AK7755_Open(const SYS_MODULE_INDEX iDriver, const DRV_IO_INTENT ioIntent);
Returns
If successful, the function returns a valid open-instance handle (a number identifying both the caller and the module instance).
If an error occurs, the return value is DRV_HANDLE_INVALID. Error can occur
• if the number of client objects allocated via DRV_AK7755_CLIENTS_NUMBER is insufficient.
• if the client is trying to open the driver but driver has been opened exclusively by another client.
• if the driver hardware instance being opened is not initialized or is invalid.
• if the ioIntent options passed are not relevant to this driver.
Description
This function opens the specified AK7755 Codec Driver instance and provides a handle that must be provided to all other client-level operations to
identify the caller and the instance of the driver. The ioIntent parameter defines how the client interacts with this driver instance.
The DRV_IO_INTENT_BLOCKING and DRV_IO_INTENT_NONBLOCKING ioIntent options are not relevant to this driver. All the data transfer
functions of this driver are non blocking.
Only DRV_IO_INTENT_WRITE is a valid ioIntent option as AK7755 is DAC only.
Specifying a DRV_IO_INTENT_EXCLUSIVE will cause the driver to provide exclusive access to this client. The driver cannot be opened by any
other client.
Remarks
The handle returned is valid until the DRV_AK7755_Close function is called. This function will NEVER block waiting for hardware.If the requested
intent flags are not supported, the function will return DRV_HANDLE_INVALID. This function is thread safe in a RTOS application. It should not be
called in an ISR.
Preconditions
The DRV_AK7755_Initialize function must have been called before calling this function.
Example
DRV_HANDLE handle;
handle = DRV_AK7755_Open(DRV_AK7755_INDEX_0, DRV_IO_INTENT_EXCLUSIVE);
if (DRV_HANDLE_INVALID == handle)
{
// Unable to open the driver
// May be the driver is not initialized or the initialization
// is not complete.
}
Parameters
Parameters Description
drvIndex Identifier for the object instance to be opened
ioIntent Zero or more of the values from the enumeration DRV_IO_INTENT "ORed" together to
indicate the intended use of the driver. See function description for details.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 291
Function
DRV_HANDLE DRV_AK7755_Open
(
const SYS_MODULE_INDEX drvIndex,
const DRV_IO_INTENT ioIntent
)
DRV_AK7755_Tasks Function
Maintains the driver's control and data interface state machine.
File
drv_ak7755.h
C
void DRV_AK7755_Tasks(SYS_MODULE_OBJ object);
Returns
None.
Description
This function is used to maintain the driver's internal control and data interface state machine and implement its control and data interface
implementations. This function should be called from the SYS_Tasks function.
Remarks
This function is normally not called directly by an application. It is called by the system's Tasks function (SYS_Tasks).
Preconditions
The DRV_AK7755_Initialize function must have been called for the specified AK7755 Codec Driver instance.
Example
SYS_MODULE_OBJ object; // Returned from DRV_AK7755_Initialize
while (true)
{
DRV_AK7755_Tasks (object);
// Do other tasks
}
Parameters
Parameters Description
object Object handle for the specified driver instance (returned from DRV_AK7755_Initialize)
Function
void DRV_AK7755_Tasks(SYS_MODULE_OBJ object);
DRV_AK7755_BufferEventHandlerSet Function
This function allows a client to identify a buffer event handling function for the driver to call back when queued buffer transfers have finished.
File
drv_ak7755.h
C
void DRV_AK7755_BufferEventHandlerSet(DRV_HANDLE handle, const DRV_AK7755_BUFFER_EVENT_HANDLER
eventHandler, const uintptr_t contextHandle);
Returns
None.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 292
Description
This function allows a client to identify a buffer event handling function for the driver to call back when queued buffer transfers have finished. When
a client calls DRV_AK7755_BufferAddWrite function, it is provided with a handle identifying the buffer that was added to the driver's buffer queue.
The driver will pass this handle back to the client by calling "eventHandler" function when the buffer transfer has completed.
The event handler should be set before the client performs any "buffer add" operations that could generate events. The event handler once set,
persists until the client closes the driver or sets another event handler (which could be a "NULL" pointer to indicate no callback).
Remarks
If the client does not want to be notified when the queued buffer transfer has completed, it does not need to register a callback.
Preconditions
The DRV_AK7755_Initialize function must have been called for the specified AK7755 Codec Driver instance.
DRV_AK7755_Open must have been called to obtain a valid opened device handle.
Example
MY_APP_OBJ myAppObj;
uint8_t mybuffer[MY_BUFFER_SIZE];
DRV_AK7755_BUFFER_HANDLE bufferHandle;
// myAK7755Handle is the handle returned
// by the DRV_AK7755_Open function.
// Client registers an event handler with driver
DRV_AK7755_BufferEventHandlerSet(myAK7755Handle,
APP_AK7755BufferEventHandler, (uintptr_t)&myAppObj);
DRV_AK7755_BufferAddWrite(myAK7755handle, &bufferHandle
myBuffer, MY_BUFFER_SIZE);
if(DRV_AK7755_BUFFER_HANDLE_INVALID == bufferHandle)
{
// Error handling here
}
// Event is received when
// the buffer is processed.
void APP_AK7755BufferEventHandler(DRV_AK7755_BUFFER_EVENT event,
DRV_AK7755_BUFFER_HANDLE bufferHandle, uintptr_t contextHandle)
{
// contextHandle points to myAppObj.
switch(event)
{
case DRV_AK7755_BUFFER_EVENT_COMPLETE:
// This means the data was transferred.
break;
case DRV_AK7755_BUFFER_EVENT_ERROR:
// Error handling here.
break;
default:
break;
}
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
eventHandler Pointer to the event handler function.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 293
context The value of parameter will be passed back to the client unchanged, when the eventHandler
function is called. It can be used to identify any client specific data object that identifies the
instance of the client module (for example, it may be a pointer to the client module's state
structure).
Function
void DRV_AK7755_BufferEventHandlerSet
(
DRV_HANDLE handle,
const DRV_AK7755_BUFFER_EVENT_HANDLER eventHandler,
const uintptr_t contextHandle
)
DRV_AK7755_CommandEventHandlerSet Function
Allows a client to identify a command event handling function for the driver to call back when the last submitted command have finished.
File
drv_ak7755.h
C
void DRV_AK7755_CommandEventHandlerSet(DRV_HANDLE handle, const DRV_AK7755_COMMAND_EVENT_HANDLER
eventHandler, const uintptr_t contextHandle);
Returns
None.
Description
This function allows a client to identify a command event handling function for the driver to call back when the last submitted command have
finished.
When a client calls DRV_AK7755_BufferAddWrite function, it is provided with a handle identifying the buffer that was added to the driver's buffer
queue. The driver will pass this handle back to the client by calling "eventHandler" function when the buffer transfer has completed.
The event handler should be set before the client performs any "AK7755 CODEC Specific Client Routines" operations that could generate events.
The event handler once set, persists until the client closes the driver or sets another event handler (which could be a "NULL" pointer to indicate no
callback).
Remarks
If the client does not want to be notified when the command has completed, it does not need to register a callback.
Preconditions
The DRV_AK7755_Initialize function must have been called for the specified AK7755 Codec Driver instance.
DRV_AK7755_Open must have been called to obtain a valid opened device handle.
Example
MY_APP_OBJ myAppObj;
uint8_t mybuffer[MY_BUFFER_SIZE];
DRV_AK7755_BUFFER_HANDLE bufferHandle;
// myAK7755Handle is the handle returned
// by the DRV_AK7755_Open function.
// Client registers an event handler with driver
DRV_AK7755_CommandEventHandlerSet(myAK7755Handle,
APP_AK7755CommandEventHandler, (uintptr_t)&myAppObj);
DRV_AK7755_DeEmphasisFilterSet(myAK7755Handle, DRV_AK7755_DEEMPHASIS_FILTER_44_1KHZ)
// Event is received when
// the buffer is processed.
void APP_AK7755CommandEventHandler(uintptr_t contextHandle)
{
// contextHandle points to myAppObj.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 294
switch(event)
{
// Last Submitted command is completed.
// Perform further processing here
}
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
eventHandler Pointer to the event handler function.
context The value of parameter will be passed back to the client unchanged, when the eventHandler
function is called. It can be used to identify any client specific data object that identifies the
instance of the client module (for example, it may be a pointer to the client module's state
structure).
Function
void DRV_AK7755_CommandEventHandlerSet
(
DRV_HANDLE handle,
const DRV_AK7755_COMMAND_EVENT_HANDLER eventHandler,
const uintptr_t contextHandle
)
DRV_AK7755_SamplingRateSet Function
This function sets the sampling rate of the media stream.
File
drv_ak7755.h
C
void DRV_AK7755_SamplingRateSet(DRV_HANDLE handle, uint32_t samplingRate);
Returns
None.
Description
This function sets the media sampling rate for the client handle.
Remarks
None.
Preconditions
The DRV_AK7755_Initialize function must have been called for the specified AK7755 Codec Driver instance.
DRV_AK7755_Open must have been called to obtain a valid opened device handle.
Example
// myAK7755Handle is the handle returned
// by the DRV_AK7755_Open function.
DRV_AK7755_SamplingRateSet(myAK7755Handle, 48000); //Sets 48000 media sampling rate
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
samplingRate Sampling frequency in Hz
Function
void DRV_AK7755_SamplingRateSet( DRV_HANDLE handle, uint32_t samplingRate)
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 295
DRV_AK7755_SetAudioCommunicationMode Function
This function provides a run time audio format configuration
File
drv_ak7755.h
C
void DRV_AK7755_SetAudioCommunicationMode(DRV_HANDLE handle, const DATA_LENGTH dl, const SAMPLE_LENGTH sl);
Returns
None
Description
This function sets up audio mode in I2S protocol
Remarks
None.
Preconditions
The DRV_AK7755_Initialize routine must have been called for the specified AK7755 driver instance.
DRV_AK7755_Open must have been called to obtain a valid opened device handle.
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
dl Data length for I2S audio interface
sl Left/Right Sample Length for I2S audio interface
Function
void DRV_AK7755_SetAudioCommunicationMode
(
DRV_HANDLE handle,
const DATA_LENGTH dl,
const SAMPLE_LENGTH sl
)
b) Status Functions
DRV_AK7755_SamplingRateGet Function
This function gets the sampling rate set on the AK7755.
Implementation: Dynamic
File
drv_ak7755.h
C
uint32_t DRV_AK7755_SamplingRateGet(DRV_HANDLE handle);
Description
This function gets the sampling rate set on the DAC AK7755.
Remarks
None.
Example
uint32_t baudRate;
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 296
// myAK7755Handle is the handle returned
// by the DRV_AK7755_Open function.
baudRate = DRV_AK7755_SamplingRateGet(myAK7755Handle);
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
Function
uint32_t DRV_AK7755_SamplingRateGet( DRV_HANDLE handle)
DRV_AK7755_Status Function
Gets the current status of the AK7755 Codec Driver module.
File
drv_ak7755.h
C
SYS_STATUS DRV_AK7755_Status(SYS_MODULE_OBJ object);
Returns
• SYS_STATUS_DEINITIALIZED - Indicates that the driver has been deinitialized
• SYS_STATUS_READY - Indicates that any previous module operation for the specified module has completed
• SYS_STATUS_BUSY - Indicates that a previous module operation for the specified module has not yet completed
• SYS_STATUS_ERROR - Indicates that the specified module is in an error state
Description
This function provides the current status of the AK7755 Codec Driver module.
Remarks
A driver can be opened only when its status is SYS_STATUS_READY.
Preconditions
The DRV_AK7755_Initialize function should have been called before calling this function.
Example
SYS_MODULE_OBJ object; // Returned from DRV_AK7755_Initialize
SYS_STATUS AK7755Status;
AK7755Status = DRV_AK7755_Status(object);
if (SYS_STATUS_READY == AK7755Status)
{
// This means the driver can be opened using the
// DRV_AK7755_Open function.
}
Parameters
Parameters Description
object Driver object handle, returned from the DRV_AK4642_Initialize routine
Function
SYS_STATUS DRV_AK7755_Status( SYS_MODULE_OBJ object)
DRV_AK7755_VersionGet Function
Returns the version of the AK7755 Codec Driver.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 297
File
drv_ak7755.h
C
uint32_t DRV_AK7755_VersionGet();
Returns
Returns the version of the AK7755 Codec Driver.
Description
The version number returned from the DRV_AK7755_VersionGet function is an unsigned integer in the following decimal format:
• * 10000 + * 100 +
Where the numbers are represented in decimal and the meaning is the same as above. Note that there is no numerical representation of release
type.
Remarks
None.
Preconditions
None.
Example 1
• For version "0.03a", return: 0 * 10000 + 3 * 100 + 0
• For version "1.00", return: 1 * 100000 + 0 * 100 + 0
Example 2
uint32_t AK7755version;
AK7755version = DRV_AK7755_VersionGet();
Function
uint32_t DRV_AK7755_VersionGet( void )
DRV_AK7755_VersionStrGet Function
This function returns the version of AK7755 Codec Driver in string format.
File
drv_ak7755.h
C
int8_t* DRV_AK7755_VersionStrGet();
Returns
returns a string containing the version of the AK7755 Codec Driver.
Description
The DRV_AK7755_VersionStrGet function returns a string in the format: ".[.][]" Where:
• is the AK7755 Codec Driver's version number.
• is the AK7755 Codec Driver's version number.
• is an optional "patch" or "dot" release number (which is not
included in the string if it equals "00").
• is an optional release type ("a" for alpha, "b" for beta ?
not the entire word spelled out) that is not included if the release is a production version (I.e. Not an alpha or beta).
The String does not contain any spaces. For example, "0.03a" "1.00"
Remarks
None
Preconditions
None.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 298
Example
int8_t *AK7755string;
AK7755string = DRV_AK7755_VersionStrGet();
Function
int8_t* DRV_AK7755_VersionStrGet(void)
DRV_AK7755_VolumeGet Function
Gets the volume for the AK7755 Codec Driver.
File
drv_ak7755.h
C
uint8_t DRV_AK7755_VolumeGet(DRV_HANDLE handle, DRV_AK7755_CHANNEL channel);
Returns
None.
Description
This functions gets the current volume programmed to the AK7755 Codec Driver.
Remarks
None.
Preconditions
The DRV_AK7755_Initialize function must have been called for the specified AK7755 Codec Driver instance.
DRV_AK7755_Open must have been called to obtain a valid opened device handle.
Example
// myAppObj is an application specific object.
MY_APP_OBJ myAppObj;
uint8_t volume;
// myAK7755Handle is the handle returned
// by the DRV_AK7755_Open function.
volume = DRV_AK7755_VolumeGet(myAK7755Handle, DRV_AK7755_CHANNEL_LEFT);
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
channel argument indicating Left or Right or Both channel volume to be modified
Function
uint8_t DRV_AK7755_VolumeGet( DRV_HANDLE handle, DRV_AK7755_CHANNEL channel)
c) Other Functions
DRV_AK7755_VolumeSet Function
This function sets the volume for AK7755 CODEC.
File
drv_ak7755.h
C
void DRV_AK7755_VolumeSet(DRV_HANDLE handle, DRV_AK7755_CHANNEL channel, uint8_t volume);
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 299
Returns
None
Description
This functions sets the volume value from 0-255, which can attenuate from -115 dB to +12 dB. All decibels below approximately -50 dB are
inaudible.
Remarks
None.
Preconditions
The DRV_AK7755_Initialize function must have been called for the specified AK7755 Codec Driver instance.
DRV_AK7755_Open must have been called to obtain a valid opened device handle.
Example
// myAppObj is an application specific object.
MY_APP_OBJ myAppObj;
uint8_t mybuffer[MY_BUFFER_SIZE];
DRV_BUFFER_HANDLE bufferHandle;
// myAK7755Handle is the handle returned
// by the DRV_AK7755_Open function.
DRV_AK7755_VolumeSet(myAK7755Handle,DRV_AK7755_CHANNEL_LEFT, 120); //Step 120 volume
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's Open function
channel argument indicating Left or Right or Both channel volume to be modified
volume Updated volume specified in the range 0-255
Function
void DRV_AK7755_VolumeSet( DRV_HANDLE handle, DRV_AK7755_CHANNEL channel, uint8_t volume);
DRV_AK7755_BufferAddRead Function
Schedule a non-blocking driver read operation.
File
drv_ak7755.h
C
void DRV_AK7755_BufferAddRead(const DRV_HANDLE handle, DRV_AK7755_BUFFER_HANDLE * bufferHandle, void *
buffer, size_t size);
Returns
The bufferHandle parameter will contain the return buffer handle. This will be DRV_AK7755_BUFFER_HANDLE_INVALID if the function was not
successful.
Description
This function schedules a non-blocking read operation. The function returns with a valid buffer handle in the bufferHandle argument if the read
request was scheduled successfully. The function adds the request to the hardware instance receive queue and returns immediately. While the
request is in the queue, the application buffer is owned by the driver and should not be modified. The function returns
DRV_AK7755_BUFFER_HANDLE_INVALID
• if a buffer could not be allocated to the request
• if the input buffer pointer is NULL
• if the buffer size is 0.
• if the queue is full or the queue depth is insufficient
If the requesting client registered an event callback with the driver, the driver will issue a DRV_AK7755_BUFFER_EVENT_COMPLETE event if
the buffer was processed successfully of DRV_AK7755_BUFFER_EVENT_ERROR event if the buffer was not processed successfully.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 300
Remarks
This function is thread safe in a RTOS application. It can be called from within the AK7755 Driver Buffer Event Handler that is registered by this
client. It should not be called in the event handler associated with another AK7755 Codec Driver instance. It should not otherwise be called directly
in an ISR.
Preconditions
The DRV_AK7755_Initialize function must have been called for the specified AK7755 device instance and the DRV_AK7755_Status must have
returned SYS_STATUS_READY.
DRV_AK7755_Open must have been called to obtain a valid opened device handle.
DRV_IO_INTENT_READ must have been specified in the DRV_AK7755_Open call.
Parameters
Parameters Description
handle Handle of the AK7755 instance as return by the DRV_AK7755_Open function.
buffer Data to be transmitted.
size Buffer size in bytes.
bufferHandle Pointer to an argument that will contain the return buffer handle.
Function
void DRV_AK7755_BufferAddRead
(
const DRV_HANDLE handle,
DRV_AK7755_BUFFER_HANDLE *bufferHandle,
void *buffer, size_t size
)
DRV_AK7755_BufferAddWrite Function
Schedule a non-blocking driver write operation.
File
drv_ak7755.h
C
void DRV_AK7755_BufferAddWrite(const DRV_HANDLE handle, DRV_AK7755_BUFFER_HANDLE * bufferHandle, void *
buffer, size_t size);
Returns
The bufferHandle parameter will contain the return buffer handle. This will be DRV_AK7755_BUFFER_HANDLE_INVALID if the function was not
successful.
Description
This function schedules a non-blocking write operation. The function returns with a valid buffer handle in the bufferHandle argument if the write
request was scheduled successfully. The function adds the request to the hardware instance transmit queue and returns immediately. While the
request is in the queue, the application buffer is owned by the driver and should not be modified. The function returns
DRV_AK7755_BUFFER_HANDLE_INVALID:
• if a buffer could not be allocated to the request
• if the input buffer pointer is NULL
• if the buffer size is 0
• if the queue is full or the queue depth is insufficient
If the requesting client registered an event callback with the driver, the driver will issue a DRV_AK7755_BUFFER_EVENT_COMPLETE event if
the buffer was processed successfully of DRV_AK7755_BUFFER_EVENT_ERROR event if the buffer was not processed successfully.
Remarks
This function is thread safe in a RTOS application. It can be called from within the AK7755 Driver Buffer Event Handler that is registered by this
client. It should not be called in the event handler associated with another AK7755 Codec Driver instance. It should not otherwise be called directly
in an ISR.
Preconditions
The DRV_AK7755_Initialize function must have been called for the specified AK7755 device instance and the DRV_AK7755_Status must have
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 301
returned SYS_STATUS_READY.
DRV_AK7755_Open must have been called to obtain a valid opened device handle.
DRV_IO_INTENT_WRITE must have been specified in the DRV_AK7755_Open call.
Example
MY_APP_OBJ myAppObj;
uint8_t mybuffer[MY_BUFFER_SIZE];
DRV_AK7755_BUFFER_HANDLE bufferHandle;
// myAK7755Handle is the handle returned
// by the DRV_AK7755_Open function.
// Client registers an event handler with driver
DRV_AK7755_BufferEventHandlerSet(myAK7755Handle,
APP_AK7755BufferEventHandler, (uintptr_t)&myAppObj);
DRV_AK7755_BufferAddWrite(myAK7755handle, &bufferHandle
myBuffer, MY_BUFFER_SIZE);
if(DRV_AK7755_BUFFER_HANDLE_INVALID == bufferHandle)
{
// Error handling here
}
// Event is received when the buffer is processed.
void APP_AK7755BufferEventHandler(DRV_AK7755_BUFFER_EVENT event,
DRV_AK7755_BUFFER_HANDLE bufferHandle, uintptr_t contextHandle)
{
// contextHandle points to myAppObj.
switch(event)
{
case DRV_AK7755_BUFFER_EVENT_COMPLETE:
// This means the data was transferred.
break;
case DRV_AK7755_BUFFER_EVENT_ERROR:
// Error handling here.
break;
default:
break;
}
}
Parameters
Parameters Description
handle Handle of the AK7755 instance as return by the DRV_AK7755_Open function.
buffer Data to be transmitted.
size Buffer size in bytes.
bufferHandle Pointer to an argument that will contain the return buffer handle.
Function
void DRV_AK7755_BufferAddWrite
(
const DRV_HANDLE handle,
DRV_AK7755_BUFFER_HANDLE *bufferHandle,
void *buffer, size_t size
)
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 302
DRV_AK7755_BufferAddWriteRead Function
File
drv_ak7755.h
C
void DRV_AK7755_BufferAddWriteRead(const DRV_HANDLE handle, DRV_AK7755_BUFFER_HANDLE * bufferHandle, void *
transmitBuffer, void * receiveBuffer, size_t size);
Description
This is function DRV_AK7755_BufferAddWriteRead.
DRV_AK7755_IntExtMicSet Function
Sets up the codec for the internal or the external microphone use.
File
drv_ak7755.h
C
void DRV_AK7755_IntExtMicSet(DRV_HANDLE handle, DRV_AK7755_INT_EXT_MIC micInput);
Returns
None.
Description
This function sets up the codec for the internal or the external microphone use.
Remarks
None.
Preconditions
The DRV_AK7755_Initialize function must have been called for the specified AK7755 Codec Driver instance.
DRV_AK7755_Open must have been called to obtain a valid opened device handle.
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
micInput Internal vs. External microphone input
Function
void DRV_AK7755_IntExtMicSet( DRV_HANDLE handle);
DRV_AK7755_MonoStereoMicSet Function
Sets up the codec for the Mono or Stereo microphone mode.
File
drv_ak7755.h
C
void DRV_AK7755_MonoStereoMicSet(DRV_HANDLE handle, DRV_AK7755_MONO_STEREO_MIC mono_stereo_mic);
Returns
None.
Description
This function sets up the codec for the Mono or Stereo microphone mode.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 303
Remarks
None.
Preconditions
The DRV_AK7755_Initialize function must have been called for the specified AK7755 Codec Driver instance.
DRV_AK7755_Open must have been called to obtain a valid opened device handle.
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
mono_stereo_mic Mono/Stereo microphone setup
Function
void DRV_AK7755_MonoStereoMicSet( DRV_HANDLE handle);
DRV_AK7755_MuteOff Function
Disables AK7755 output for soft mute.
File
drv_ak7755.h
C
void DRV_AK7755_MuteOff(DRV_HANDLE handle);
Returns
None.
Description
This function disables AK7755 output for soft mute.
Remarks
None.
Preconditions
The DRV_AK7755_Initialize function must have been called for the specified AK7755 Codec Driver instance.
DRV_AK7755_Open must have been called to obtain a valid opened device handle.
Example
// myAppObj is an application specific object.
MY_APP_OBJ myAppObj;
uint8_t mybuffer[MY_BUFFER_SIZE];
DRV_BUFFER_HANDLE bufferHandle;
// myAK7755Handle is the handle returned
// by the DRV_AK7755_Open function.
DRV_AK7755_MuteOff(myAK7755Handle); //AK7755 output soft mute disabled
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
Function
void DRV_AK7755_MuteOff( DRV_HANDLE handle)
DRV_AK7755_MuteOn Function
Allows AK7755 output for soft mute on.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 304
File
drv_ak7755.h
C
void DRV_AK7755_MuteOn(DRV_HANDLE handle);
Returns
None.
Description
This function enables AK7755 output for soft mute.
Remarks
None.
Preconditions
The DRV_AK7755_Initialize function must have been called for the specified AK7755 Codec Driver instance.
DRV_AK7755_Open must have been called to obtain a valid opened device handle.
Example
// myAppObj is an application specific object.
MY_APP_OBJ myAppObj;
uint8_t mybuffer[MY_BUFFER_SIZE];
DRV_BUFFER_HANDLE bufferHandle;
// myAK7755Handle is the handle returned
// by the DRV_AK7755_Open function.
DRV_AK7755_MuteOn(myAK7755Handle); //AK7755 output soft muted
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
Function
void DRV_AK7755_MuteOn( DRV_HANDLE handle);
d) Data Types and Constants
_DRV_AK7755_H Macro
File
drv_ak7755.h
C
#define _DRV_AK7755_H
Description
Include files.
DRV_AK7755_BUFFER_HANDLE_INVALID Macro
Definition of an invalid buffer handle.
File
drv_ak7755.h
C
#define DRV_AK7755_BUFFER_HANDLE_INVALID ((DRV_AK7755_BUFFER_HANDLE)(-1))
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 305
Description
AK7755 Driver Invalid Buffer Handle
This is the definition of an invalid buffer handle. An invalid buffer handle is returned by DRV_AK7755_BufferAddWrite and the
DRV_AK7755_BufferAddRead function if the buffer add request was not successful.
Remarks
None.
DRV_AK7755_COUNT Macro
Number of valid AK7755 Codec Driver indices
File
drv_ak7755.h
C
#define DRV_AK7755_COUNT
Description
AK7755 Driver Module Count
This constant identifies the maximum number of AK7755 Codec Driver instances that should be defined by the application. Defining more
instances than this constant will waste RAM memory space.
This constant can also be used by the application to identify the number of AK7755 instances on this microcontroller.
Remarks
This value is device-specific.
DRV_AK7755_INDEX_0 Macro
AK7755 driver index definitions
File
drv_ak7755.h
C
#define DRV_AK7755_INDEX_0 0
Description
Driver AK7755 Module Index
These constants provide AK7755 Codec Driver index definition.
Remarks
These constants should be used in place of hard-coded numeric literals. These values should be passed into the DRV_AK7755_Initialize and
DRV_AK7755_Open functions to identify the driver instance in use.
DRV_AK7755_INDEX_1 Macro
File
drv_ak7755.h
C
#define DRV_AK7755_INDEX_1 1
Description
This is macro DRV_AK7755_INDEX_1.
DRV_AK7755_INDEX_2 Macro
File
drv_ak7755.h
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 306
C
#define DRV_AK7755_INDEX_2 2
Description
This is macro DRV_AK7755_INDEX_2.
DRV_AK7755_INDEX_3 Macro
File
drv_ak7755.h
C
#define DRV_AK7755_INDEX_3 3
Description
This is macro DRV_AK7755_INDEX_3.
DRV_AK7755_INDEX_4 Macro
File
drv_ak7755.h
C
#define DRV_AK7755_INDEX_4 4
Description
This is macro DRV_AK7755_INDEX_4.
DRV_AK7755_INDEX_5 Macro
File
drv_ak7755.h
C
#define DRV_AK7755_INDEX_5 5
Description
This is macro DRV_AK7755_INDEX_5.
DRV_AK7755_BICK_FS_FORMAT Enumeration
File
drv_ak7755.h
C
typedef enum {
DRV_AK7755_BICK_64FS,
DRV_AK7755_BICK_48FS,
DRV_AK7755_BICK_32FS,
DRV_AK7755_BICK_256FS
} DRV_AK7755_BICK_FS_FORMAT;
Description
This is type DRV_AK7755_BICK_FS_FORMAT.
DRV_AK7755_BUFFER_EVENT Enumeration
Identifies the possible events that can result from a buffer add request.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 307
File
drv_ak7755.h
C
typedef enum {
DRV_AK7755_BUFFER_EVENT_COMPLETE,
DRV_AK7755_BUFFER_EVENT_ERROR,
DRV_AK7755_BUFFER_EVENT_ABORT
} DRV_AK7755_BUFFER_EVENT;
Members
Members Description
DRV_AK7755_BUFFER_EVENT_COMPLETE Data was transferred successfully.
DRV_AK7755_BUFFER_EVENT_ERROR Error while processing the request
DRV_AK7755_BUFFER_EVENT_ABORT Data transfer aborted (Applicable in DMA mode)
Description
AK7755 Driver Events
This enumeration identifies the possible events that can result from a buffer add request caused by the client calling either the
DRV_AK7755_BufferAddWrite or the DRV_AK7755_BufferAddRead function.
Remarks
One of these values is passed in the "event" parameter of the event handling callback function that the client registered with the driver by calling
the DRV_AK7755_BufferEventHandlerSet function when a buffer transfer request is completed.
DRV_AK7755_BUFFER_EVENT_HANDLER Type
Pointer to a AK7755 Driver Buffer Event handler function.
File
drv_ak7755.h
C
typedef void (* DRV_AK7755_BUFFER_EVENT_HANDLER)(DRV_AK7755_BUFFER_EVENT event, DRV_AK7755_BUFFER_HANDLE
bufferHandle, uintptr_t contextHandle);
Returns
None.
Description
AK7755 Driver Buffer Event Handler Function
This data type defines the required function signature for the AK7755 Codec Driver buffer event handling callback function. A client must register a
pointer to a buffer event handling function whose function signature (parameter and return value types) match the types specified by this function
pointer in order to receive buffer related event calls back from the driver.
The parameters and return values are described here and a partial example implementation is provided.
Remarks
If the event is DRV_AK7755_BUFFER_EVENT_COMPLETE, this means that the data was transferred successfully.
If the event is DRV_AK7755_BUFFER_EVENT_ERROR, this means that the data was not transferred successfully. The bufferHandle parameter
contains the buffer handle of the buffer that failed. The DRV_AK7755_BufferProcessedSizeGet function can be called to find out how many bytes
were processed.
The bufferHandle parameter contains the buffer handle of the buffer that associated with the event.
The context parameter contains a handle to the client context, provided at the time the event handling function was registered using the
DRV_AK7755_BufferEventHandlerSet function. This context handle value is passed back to the client as the "context" parameter. It can be any
value necessary to identify the client context or instance (such as a pointer to the client's data) instance of the client that made the buffer add
request.
The buffer handle in bufferHandle expires after this event handler exits. In that the buffer object that was allocated is deallocated by the driver after
the event handler exits.
The event handler function executes in the data driver (i.e., I2S) peripheral's interrupt context when the driver is configured for interrupt mode
operation. It is recommended of the application to not perform process intensive or blocking operations with in this function.
DRV_AK7755_BufferAddWrite function can be called in the event handler to add a buffer to the driver queue.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 308
Example
void APP_MyBufferEventHandler( DRV_AK7755_BUFFER_EVENT event,
DRV_AK7755_BUFFER_HANDLE bufferHandle,
uintptr_t context )
{
MY_APP_DATA_STRUCT pAppData = (MY_APP_DATA_STRUCT) context;
switch(event)
{
case DRV_AK7755_BUFFER_EVENT_COMPLETE:
// Handle the completed buffer.
break;
case DRV_AK7755_BUFFER_EVENT_ERROR:
default:
// Handle error.
break;
}
}
Parameters
Parameters Description
event Identifies the type of event
bufferHandle Handle identifying the buffer to which the event relates
context Value identifying the context of the application that registered the event handling function.
DRV_AK7755_BUFFER_HANDLE Type
Handle identifying a write buffer passed to the driver.
File
drv_ak7755.h
C
typedef uintptr_t DRV_AK7755_BUFFER_HANDLE;
Description
AK7755 Driver Buffer Handle
A buffer handle value is returned by a call to the DRV_AK7755_BufferAddWrite or DRV_AK7755_BufferAddRead function. This handle is
associated with the buffer passed into the function and it allows the application to track the completion of the data from (or into) that buffer. The
buffer handle value returned from the "buffer add" function is returned back to the client by the "event handler callback" function registered with the
driver.
The buffer handle assigned to a client request expires when the client has been notified of the completion of the buffer transfer (after event handler
function that notifies the client returns) or after the buffer has been retired by the driver if no event handler callback was set.
Remarks
None.
DRV_AK7755_CHANNEL Enumeration
Identifies left/right audio channel.
File
drv_ak7755.h
C
typedef enum {
DRV_AK7755_CHANNEL_LEFT,
DRV_AK7755_CHANNEL_RIGHT,
DRV_AK7755_CHANNEL_LEFT_RIGHT,
DRV_AK7755_NUMBER_OF_CHANNELS
} DRV_AK7755_CHANNEL;
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 309
Description
AK7755 Audio Channel
This enumeration identifies the left/right audio channel.
Remarks
None.
DRV_AK7755_COMMAND_EVENT_HANDLER Type
Pointer to a AK7755 Codec Driver command event handler function.
File
drv_ak7755.h
C
typedef void (* DRV_AK7755_COMMAND_EVENT_HANDLER)(uintptr_t contextHandle);
Returns
None.
Description
AK7755 Driver Command Event Handler Function
This data type defines the required function signature for the AK7755 Codec Driver command event handling callback function.
A command is a control instruction to the AK7755 Codec. For example, Mute ON/OFF, Zero Detect Enable/Disable, etc.
A client must register a pointer to a command event handling function whose function signature (parameter and return value types) match the
types specified by this function pointer in order to receive command related event calls back from the driver.
The parameters and return values are described here and a partial example implementation is provided.
Remarks
The occurrence of this call back means that the last control command was transferred successfully.
The context parameter contains a handle to the client context, provided at the time the event handling function was registered using the
DRV_AK7755_CommandEventHandlerSet function. This context handle value is passed back to the client as the "context" parameter. It can be
any value necessary to identify the client context or instance (such as a pointer to the client's data) instance of the client that made the buffer add
request.
The event handler function executes in the control data driver interrupt context. It is recommended of the application to not perform process
intensive or blocking operations with in this function.
Example
void APP_AK7755CommandEventHandler( uintptr_t context )
{
MY_APP_DATA_STRUCT pAppData = (MY_APP_DATA_STRUCT) context;
// Last Submitted command is completed.
// Perform further processing here
}
Parameters
Parameters Description
context Value identifying the context of the application that registered the event handling function.
DRV_AK7755_DAC_INPUT_FORMAT Enumeration
Identifies the Serial Audio data interface format.
File
drv_ak7755.h
C
typedef enum {
DRV_AK7755_DAC_INPUT_24BITMSB,
DRV_AK7755_DAC_INPUT_24BITLSB,
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 310
DRV_AK7755_DAC_INPUT_20BITLSB,
DRV_AK7755_DAC_INPUT_16BITLSB
} DRV_AK7755_DAC_INPUT_FORMAT;
Members
Members Description
DRV_AK7755_DAC_INPUT_20BITLSB not supported
Description
AK7755 Audio Data Format
This enumeration identifies the Serial Audio data interface format.
DRV_AK7755_DSP_DIN1_INPUT_FORMAT Enumeration
File
drv_ak7755.h
C
typedef enum {
DRV_AK7755_DSP_DIN1_INPUT_24BITMSB,
DRV_AK7755_DSP_DIN1_INPUT_24BITLSB,
DRV_AK7755_DSP_DIN1_INPUT_20BITLSB,
DRV_AK7755_DSP_DIN1_INPUT_16BITLSB
} DRV_AK7755_DSP_DIN1_INPUT_FORMAT;
Description
This is type DRV_AK7755_DSP_DIN1_INPUT_FORMAT.
DRV_AK7755_DSP_DOUT1_OUTPUT_FORMAT Enumeration
File
drv_ak7755.h
C
typedef enum {
DRV_AK7755_DSP_DOUT1_OUTPUT_24BITMSB,
DRV_AK7755_DSP_DOUT1_OUTPUT_24BITLSB,
DRV_AK7755_DSP_DOUT1_OUTPUT_20BITLSB,
DRV_AK7755_DSP_DOUT1_OUTPUT_16BITLSB
} DRV_AK7755_DSP_DOUT1_OUTPUT_FORMAT;
Description
This is type DRV_AK7755_DSP_DOUT1_OUTPUT_FORMAT.
DRV_AK7755_DSP_DOUT4_OUTPUT_FORMAT Enumeration
File
drv_ak7755.h
C
typedef enum {
DRV_AK7755_DSP_DOUT4_OUTPUT_24BITMSB,
DRV_AK7755_DSP_DOUT4_OUTPUT_24BITLSB,
DRV_AK7755_DSP_DOUT4_OUTPUT_20BITLSB,
DRV_AK7755_DSP_DOUT4_OUTPUT_16BITLSB
} DRV_AK7755_DSP_DOUT4_OUTPUT_FORMAT;
Description
This is type DRV_AK7755_DSP_DOUT4_OUTPUT_FORMAT.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 311
DRV_AK7755_DSP_PROGRAM Enumeration
File
drv_ak7755.h
C
typedef enum {
DRV_AK7755_DSP_ECHO_CANCELLATION,
DRV_AK7755_DSP_REGULAR
} DRV_AK7755_DSP_PROGRAM;
Description
This is type DRV_AK7755_DSP_PROGRAM.
DRV_AK7755_INIT Structure
Defines the data required to initialize or reinitialize the AK7755 Codec Driver.
File
drv_ak7755.h
C
typedef struct {
SYS_MODULE_INIT moduleInit;
SYS_MODULE_INDEX i2sDriverModuleIndex;
SYS_MODULE_INDEX i2cDriverModuleIndex;
uint32_t samplingRate;
uint8_t volume;
} DRV_AK7755_INIT;
Members
Members Description
SYS_MODULE_INIT moduleInit; System module initialization
SYS_MODULE_INDEX i2sDriverModuleIndex; Identifies data module (I2S) driver ID for data interface of CODEC
SYS_MODULE_INDEX i2cDriverModuleIndex; Identifies data module (I2C) driver ID for control interface of CODEC
uint32_t samplingRate; Sampling rate
uint8_t volume; Volume
Description
AK7755 Driver Initialization Data
This data type defines the data required to initialize or reinitialize the AK7755 Codec Driver.
Remarks
None.
DRV_AK7755_INT_EXT_MIC Enumeration
Identifies the Mic input source.
File
drv_ak7755.h
C
typedef enum {
INT_MIC,
EXT_MIC
} DRV_AK7755_INT_EXT_MIC;
Description
AK7755 Mic Internal / External Input
This enumeration identifies the Mic input source.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 312
Remarks
None.
DRV_AK7755_LRCK_IF_FORMAT Enumeration
File
drv_ak7755.h
C
typedef enum {
DRV_AK7755_LRCK_IF_STANDARD,
DRV_AK7755_LRCK_IF_I2S_COMPATIBLE,
DRV_AK7755_LRCK_IF_PCM_SHORT_FRAME,
DRV_AK7755_LRCK_IF_PCM_LONG_FRAME
} DRV_AK7755_LRCK_IF_FORMAT;
Description
This is type DRV_AK7755_LRCK_IF_FORMAT.
DRV_AK7755_MONO_STEREO_MIC Enumeration
Identifies the Mic input as Mono/Stereo.
File
drv_ak7755.h
C
typedef enum {
ALL_ZEROS,
MONO_RIGHT_CHANNEL,
MONO_LEFT_CHANNEL,
STEREO
} DRV_AK7755_MONO_STEREO_MIC;
Description
AK7755 Mic Mono/Stereo Input
This enumeration identifies the Mic input as Mono/Stereo.
Remarks
None.
DRV_I2C_INDEX Macro
File
drv_wm8904.h
C
#define DRV_I2C_INDEX DRV_WM8904_I2C_INSTANCES_NUMBER
Description
This is macro DRV_I2C_INDEX.
DATA_LENGTH Enumeration
File
drv_wm8904.h
C
typedef enum {
DATA_LENGTH_16,
DATA_LENGTH_24,
DATA_LENGTH_32
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 313
} DATA_LENGTH;
Description
in bits
SAMPLE_LENGTH Enumeration
File
drv_ak7755.h
C
typedef enum {
SAMPLE_LENGTH_16,
SAMPLE_LENGTH_32
} SAMPLE_LENGTH;
Description
in bits
Files
Files
Name Description
drv_ak7755.h AK7755 CODEC Driver Interface header file
drv_ak7755_config_template.h AK7755 Codec Driver configuration template.
Description
This section lists the source and header files used by the AK7755Codec Driver Library.
drv_ak7755.h
AK7755 CODEC Driver Interface header file
Enumerations
Name Description
DRV_AK7755_BICK_FS_FORMAT This is type DRV_AK7755_BICK_FS_FORMAT.
DRV_AK7755_BUFFER_EVENT Identifies the possible events that can result from a buffer add request.
DRV_AK7755_CHANNEL Identifies left/right audio channel.
DRV_AK7755_DAC_INPUT_FORMAT Identifies the Serial Audio data interface format.
DRV_AK7755_DSP_DIN1_INPUT_FORMAT This is type DRV_AK7755_DSP_DIN1_INPUT_FORMAT.
DRV_AK7755_DSP_DOUT1_OUTPUT_FORMAT This is type DRV_AK7755_DSP_DOUT1_OUTPUT_FORMAT.
DRV_AK7755_DSP_DOUT4_OUTPUT_FORMAT This is type DRV_AK7755_DSP_DOUT4_OUTPUT_FORMAT.
DRV_AK7755_DSP_PROGRAM This is type DRV_AK7755_DSP_PROGRAM.
DRV_AK7755_INT_EXT_MIC Identifies the Mic input source.
DRV_AK7755_LRCK_IF_FORMAT This is type DRV_AK7755_LRCK_IF_FORMAT.
DRV_AK7755_MONO_STEREO_MIC Identifies the Mic input as Mono/Stereo.
SAMPLE_LENGTH in bits
Functions
Name Description
DRV_AK7755_BufferAddRead Schedule a non-blocking driver read operation.
DRV_AK7755_BufferAddWrite Schedule a non-blocking driver write operation.
DRV_AK7755_BufferAddWriteRead This is function DRV_AK7755_BufferAddWriteRead.
DRV_AK7755_BufferEventHandlerSet This function allows a client to identify a buffer event handling function for the driver
to call back when queued buffer transfers have finished.
DRV_AK7755_Close Closes an opened-instance of the AK7755 Codec Driver.
DRV_AK7755_CommandEventHandlerSet Allows a client to identify a command event handling function for the driver to call
back when the last submitted command have finished.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 314
DRV_AK7755_Deinitialize Deinitializes the specified instance of the AK7755 Codec Driver module.
DRV_AK7755_Initialize Initializes hardware and data for the instance of the AK7755 DAC module
DRV_AK7755_IntExtMicSet Sets up the codec for the internal or the external microphone use.
DRV_AK7755_MonoStereoMicSet Sets up the codec for the Mono or Stereo microphone mode.
DRV_AK7755_MuteOff Disables AK7755 output for soft mute.
DRV_AK7755_MuteOn Allows AK7755 output for soft mute on.
DRV_AK7755_Open Opens the specified AK7755 Codec Driver instance and returns a handle to it
DRV_AK7755_SamplingRateGet This function gets the sampling rate set on the AK7755.
Implementation: Dynamic
DRV_AK7755_SamplingRateSet This function sets the sampling rate of the media stream.
DRV_AK7755_SetAudioCommunicationMode This function provides a run time audio format configuration
DRV_AK7755_Status Gets the current status of the AK7755 Codec Driver module.
DRV_AK7755_Tasks Maintains the driver's control and data interface state machine.
DRV_AK7755_VersionGet Returns the version of the AK7755 Codec Driver.
DRV_AK7755_VersionStrGet This function returns the version of AK7755 Codec Driver in string format.
DRV_AK7755_VolumeGet Gets the volume for the AK7755 Codec Driver.
DRV_AK7755_VolumeSet This function sets the volume for AK7755 CODEC.
Macros
Name Description
_DRV_AK7755_H Include files.
DRV_AK7755_BUFFER_HANDLE_INVALID Definition of an invalid buffer handle.
DRV_AK7755_COUNT Number of valid AK7755 Codec Driver indices
DRV_AK7755_INDEX_0 AK7755 driver index definitions
DRV_AK7755_INDEX_1 This is macro DRV_AK7755_INDEX_1.
DRV_AK7755_INDEX_2 This is macro DRV_AK7755_INDEX_2.
DRV_AK7755_INDEX_3 This is macro DRV_AK7755_INDEX_3.
DRV_AK7755_INDEX_4 This is macro DRV_AK7755_INDEX_4.
DRV_AK7755_INDEX_5 This is macro DRV_AK7755_INDEX_5.
Structures
Name Description
DRV_AK7755_INIT Defines the data required to initialize or reinitialize the AK7755 Codec Driver.
Types
Name Description
DRV_AK7755_BUFFER_EVENT_HANDLER Pointer to a AK7755 Driver Buffer Event handler function.
DRV_AK7755_BUFFER_HANDLE Handle identifying a write buffer passed to the driver.
DRV_AK7755_COMMAND_EVENT_HANDLER Pointer to a AK7755 Codec Driver command event handler function.
Description
AK7755 CODEC Driver Interface
The AK7755 CODEC device driver interface provides a simple interface to manage the AK7755 16/24-Bit Codec that can be interfaced Microchip
Microcontroller. This file provides the interface definition for the AK7755 Codec device driver.
File Name
drv_ak7755.h
Company
Microchip Technology Inc.
drv_ak7755_config_template.h
AK7755 Codec Driver configuration template.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 315
Macros
Name Description
DRV_AK7755_BCLK_BIT_CLK_DIVISOR Sets up the BCLK to LRCK ratio to generate the audio stream for the
specified sampling frequency.
DRV_AK7755_CLIENTS_NUMBER Sets up the maximum number of clients that can be connected to any
hardware instance.
DRV_AK7755_INPUT_REFCLOCK Identifies the input REFCLOCK source to generate the MCLK to the codec.
DRV_AK7755_INSTANCES_NUMBER Sets up the maximum number of hardware instances that can be supported
DRV_AK7755_MCLK_SAMPLE_FREQ_MULTPLIER Sets up the MCLK to LRCK ratio to generate the audio stream for the
specified sampling frequency.
DRV_AK7755_MCLK_SOURCE Indicates the input clock frequency to generate the MCLK to the codec.
Description
AK7755 Codec Driver Configuration Template
These file provides the list of all the configurations that can be used with the driver. This file should not be included in the driver.
File Name
drv_ak7755_config_template.h
Company
Microchip Technology Inc.
WM8904 Codec Driver Library
This topic describes the WM8904 Codec Driver Library.
Introduction
This library provides an Applications Programming Interface (API) to manage the WM8904 Codec that is serially interfaced to the I2C and I2S
peripherals of a Microchip PIC32 microcontroller for the purpose of providing audio solutions.
Description
The WM8904 module is 24-bit Audio Codec from Cirrus Logic, which can operate in 16-, 20-, 24-, and 32-bit audio modes. The WM8904 can be
interfaced to Microchip microcontrollers through I2C and I2S serial interfaces. The I2C interface is used to send commands and receive status,
and the I2S interface is used for audio data output (to headphones or line-out) and input (from microphone or line-in).
The WM8904 can be configured as either an I2S clock slave (receives all clocks from the host), or I2S clock master (generates I2S clocks from a
master clock input MCLK). Currently the driver only supports master mode with headphone output and (optionally) microphone input.
A typical interface of WM8904 to a Microchip PIC32 device using an I2C and SSC interface (configured as I2S), with the WM8904 set up as the
I2S clock master, is provided in the following diagram:
Features
The WM8904 Codec supports the following features:
• Audio Interface Format: 16-/20-/24-/32-bit interface, LSB justified or I2S format
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 316
• Sampling Frequency Range: 8 kHz to 96 kHz
• Digital Volume Control: -71.625 to 0 dB in 192 steps
• Soft mute capability
Using the Library
This topic describes the basic architecture of the WM8904 Codec Driver Library and provides information and examples on its use.
Description
Interface Header File: drv_WM8904.h
The interface to the WM8904 Codec Driver library is defined in the drv_WM8904.h header file. Any C language source (.c) file that uses the
WM8904 Codec Driver library should include this header.
Please refer to the What is MPLAB Harmony? section for how the driver interacts with the framework.
Abstraction Model
This library provides a low-level abstraction of the WM8904 Codec Driver Library on the Microchip family microcontrollers with a convenient C
language interface. This topic describes how that abstraction is modeled in software and introduces the library's interface.
Description
The abstraction model shown in the following diagram depicts how the WM8904 Codec Driver is positioned in the MPLAB Harmony framework.
The WM8904 Codec Driver uses the I2C and I2S drivers for control and audio data transfers to the WM8904 module.
WM8904 Driver Abstraction Model
Library Overview
Refer to the Driver Library Overview section for information on how the driver operates in a system.
The WM8904 Codec Driver Library provides an API interface to transfer control commands and digital audio data to the serially interfaced
WM8904 Codec module. The library interface routines are divided into various sub-sections, which address one of the blocks or the overall
operation of the WM8904 Codec Driver Library.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 317
Library Interface Section Description
System Functions Provides system module interfaces, device initialization, deinitialization,
reinitialization, tasks and status functions.
Client Setup Functions Provides open and close functions.
Data Transfer Functions Provides data transfer functions, such as Buffer Read and Write.
Settings Functions Provides driver specific functions for settings, such as volume control and sampling
rate.
Other Functions Miscellaneous functions, such as getting the driver’s version number.
Data Types and Constants These data types and constants are required while interacting and setting up the
WM8904 Codec Driver Library.
Note:
All functions and constants in this section are named with the format DRV_ WM8904_xxx, where 'xxx' is a function name or
constant. These names are redefined in the appropriate configuration’s system_config.h file to the format DRV_CODEC_xxx
using #defines so that code in the application that references the library can be written as generically as possible (e.g., by
writing DRV_CODEC_Open instead of DRV_ WM8904_Open etc.). This allows the codec type to be changed in the MHC without
having to modify the application’s source code.
How the Library Works
The library provides interfaces to support:
• System Functionality
• Client Functionality
System Access
This topic describes system initialization, implementations, and includes a system access code example.
Description
System Initialization
The system performs the initialization of the device driver with settings that affect only the instance of the device that is being initialized. During
system initialization in the system_init.c file, each instance of the WM8904 module would be initialized with the following configuration settings
(either passed dynamically at run time using DRV_WM8904_INIT or by using Initialization Overrides) that are supported by the specific WM8904
device hardware:
• Device requested power state: one of the System Module Power States. For specific details please refer to Data Types and Constants in the
Library Interface section.
• I2C driver module index. The module index should be same as the one used in initializing the I2C Driver
• I2S driver module index. The module index should be same as the one used in initializing the I2S Driver
• Sampling rate
• Volume
• Audio data format. The audio data format should match with the audio data format settings done in I2S driver initialization
• Determines whether or not the microphone input is enabled
The DRV_WM8904_Initialize API returns an object handle of the type SYS_MODULE_OBJ. The object handle returned by the Initialize interface
would be used by the other system interfaces such as DRV_ WM8904_Deinitialize, DRV_ WM8904_Status and DRV_I2S_Tasks.
Implementations
The WM8904 Codec Driver can has the following implementation:
Description MPLAB Harmony Components
Dedicated hardware for control (I2C) and data (I2S) interface. Standard MPLAB Harmony drivers for I2C and I2S interfaces.
Example:
SYS_STATUS status;
status = DRV_CODEC_Status(sysObjdrvCodec0); // see if codec is done initializing
if (SYS_STATUS_READY == status)
{
// The driver can now be opened.
codecData->codecClient.handle = DRV_CODEC_Open
(DRV_CODEC_INDEX_0, DRV_IO_INTENT_WRITE | DRV_IO_INTENT_EXCLUSIVE);
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 318
if(appData.wm8904Client.handle != DRV_HANDLE_INVALID)
{
appData.state = APP_STATE_WM8904_SET_BUFFER_HANDLER;
}
else
{
SYS_DEBUG(0, "Find out what's wrong \r\n");
}
}
else
{
/* driver is not ready */
}
Task Routine
The DRV_WM8904_Tasks will be called from the System Task Service.
Client Access
This topic describes driver initialization and provides a code example.
Description
For the application to start using an instance of the module, it must call the DRV_WM8904_Open function. The DRV_WM8904_Open function
provides a driver handle to the WM8904 Codec Driver instance for operations. If the driver is deinitialized using the function
DRV_WM8904_Deinitialize, the application must call the DRV_WM8904_Open function again to set up the instance of the driver.
For the various options available for IO_INTENT, please refer to Data Types and Constants in the Library Interface section.
Note:
It is necessary to check the status of driver initialization before opening a driver instance. The status of the WM8904 Codec Driver
can be known by calling DRV_ WM8904_Status.
Example:
DRV_HANDLE handle;
SYS_STATUS wm8904Status;
wm8904Status Status = DRV_WM8904_Status(sysObjects.wm8904Status DevObject);
if (SYS_STATUS_READY == wm8904Status)
{
// The driver can now be opened.
appData.wm8904Client.handle = DRV_WM8904_Open
(DRV_WM8904_INDEX_0, DRV_IO_INTENT_EXCLUSIVE);
if(appData.wm8904Client.handle != DRV_HANDLE_INVALID)
{
appData.state = APP_STATE_WM8904_SET_BUFFER_HANDLER;
}
else
{
SYS_DEBUG(0, "Find out what's wrong \r\n");
}
}
else
{
/* WM8904 Driver Is not ready */
}
Client Operations
This topic provides information on client operations and includes a control command and audio buffered data operation flow diagram.
Description
Client operations provide the API interface for control command and audio data transfer to the WM8904 Codec.
The following WM8904 Codec specific control command functions are provided:
• DRV_WM8904_SamplingRateSet
• DRV_WM8904_SamplingRateGet
• DRV_WM8904_VolumeSet
• DRV_WM8904_VolumeGet
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 319
• DRV_WM8904_MuteOn
• DRV_WM8904_MuteOff
These functions schedule a non-blocking control command transfer operation. These functions submit the control command request to the
WM8904 Codec. These functions submit the control command request to I2C Driver transmit queue, the request is processed immediately if it is
the first request, or processed when the previous request is complete.
DRV_WM8904_BufferAddWrite, DRV_WM8904_BufferAddRead, and DRV_WM8904_BufferAddWriteRead are buffered data operation functions.
These functions schedule non-blocking audio data transfer operations. These functions add the request to I2S Driver transmit or receive buffer
queue depends on the request type, and are executed immediately if it is the first buffer, or executed later when the previous buffer is complete.
The driver notifies the client with DRV_WM8904_BUFFER_EVENT_COMPLETE, DRV_WM8904_BUFFER_EVENT_ERROR, or
DRV_WM8904_BUFFER_EVENT_ABORT events.
Note:
It is not necessary to close and reopen the client between multiple transfers.
Configuring the Library
Enumerations
Name Description
DRV_WM8904_AUDIO_DATA_FORMAT Identifies the Serial Audio data interface format.
Macros
Name Description
_DRV_WM8904_CONFIG_TEMPLATE_H This is macro _DRV_WM8904_CONFIG_TEMPLATE_H.
DRV_CODEC_WM8904_MODE Specifies if codec is in Master or Slave mode.
DRV_WM8904_BAUD_RATE Specifies the initial baud rate for the codec.
DRV_WM8904_CLIENTS_NUMBER Sets up the maximum number of clients that can be connected to any hardware
instance.
DRV_WM8904_ENABLE_MIC_INPUT Specifies whether to enable the microphone input.
DRV_WM8904_INSTANCES_NUMBER Sets up the maximum number of hardware instances that can be supported
DRV_WM8904_VOLUME Specifies the initial volume level.
Description
The configuration of the WM8904 Codec Driver is based on the file system_config.h.
This header file contains the configuration selection for the WM8904 Codec Driver. Based on the selections made, the driver may support the
selected features. These configuration settings will apply to all instances of the WM8904 Codec Driver.
This header can be placed anywhere, the path of this header needs to be present in the include search path for a successful build. Refer to the
Applications Help section for more details.
_DRV_WM8904_CONFIG_TEMPLATE_H Macro
File
drv_wm8904_config_template.h
C
#define _DRV_WM8904_CONFIG_TEMPLATE_H
Description
This is macro _DRV_WM8904_CONFIG_TEMPLATE_H.
DRV_CODEC_WM8904_MODE Macro
Specifies if codec is in Master or Slave mode.
File
drv_wm8904_config_template.h
C
#define DRV_CODEC_WM8904_MODE
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 320
Description
WM8904 Codec Master/Slave Mode
Indicates whether the codec is to be operating in a Master mode (generating word and bit clock as outputs) or Slave mode receiving word and bit
clock as inputs).
Remarks
Only Master mode is supported at this time.
DRV_WM8904_AUDIO_DATA_FORMAT Enumeration
Identifies the Serial Audio data interface format.
File
drv_wm8904.h
C
typedef enum {
DATA_16_BIT_LEFT_JUSTIFIED,
DATA_16_BIT_I2S,
DATA_32_BIT_LEFT_JUSTIFIED,
DATA_32_BIT_I2S
} DRV_WM8904_AUDIO_DATA_FORMAT;
Description
WM8904 Audio data format
This enumeration identifies Serial Audio data interface format.
DRV_WM8904_BAUD_RATE Macro
Specifies the initial baud rate for the codec.
File
drv_wm8904_config_template.h
C
#define DRV_WM8904_BAUD_RATE
Description
WM8904 Baud Rate
Sets the initial baud rate (sampling rate) for the codec. Typical values are 8000, 16000, 44100, 48000, 88200 and 96000.
Remarks
None.
DRV_WM8904_CLIENTS_NUMBER Macro
Sets up the maximum number of clients that can be connected to any hardware instance.
File
drv_wm8904_config_template.h
C
#define DRV_WM8904_CLIENTS_NUMBER
Description
WM8904 Client Count Configuration
Sets up the maximum number of clients that can be connected to any hardware instance. Typically only one client could be connected to one
hardware instance. This value represents the total number of clients to be supported across all hardware instances.
Remarks
None.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 321
DRV_WM8904_ENABLE_MIC_INPUT Macro
Specifies whether to enable the microphone input.
File
drv_wm8904_config_template.h
C
#define DRV_WM8904_ENABLE_MIC_INPUT
Description
WM8904 Microphone Enable
Indicates whether the ADC inputs for the two microphone channels (L-R) should be enabled.
Remarks
None.
DRV_WM8904_INSTANCES_NUMBER Macro
Sets up the maximum number of hardware instances that can be supported
File
drv_wm8904_config_template.h
C
#define DRV_WM8904_INSTANCES_NUMBER
Description
WM8904 driver objects configuration
Sets up the maximum number of hardware instances that can be supported. It is recommended that this number be set exactly equal to the
number of WM8904 Codec modules that are needed by an application, namely one.
Remarks
None.
DRV_WM8904_VOLUME Macro
Specifies the initial volume level.
File
drv_wm8904_config_template.h
C
#define DRV_WM8904_VOLUME
Description
WM8904 Volume
Sets the initial volume level, in the range 0-255.
Remarks
The value is mapped to an internal WM8904 volume level in the range 0-192 using a logarithmic table so the input scale appears linear (128 is half
volume).
Configuring the MHC
Provides examples on how to configure the MPLAB Harmony Configurator (MHC) for a specific driver.
Description
The following figure shows an example of an MHC configuration for the WM8904 Codec Driver.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 322
Building the Library
This section lists the files that are available in the WM8904 Codec Driver Library.
Description
This section list the files that are available in the /src folder of the WM8904 Codec Driver. It lists which files need to be included in the build
based on either a hardware feature present on the board or configuration option selected by the system.
The following three tables list and describe the header (.h) and source (.c) files that implement this library. The parent folder for these files is
/framework/driver/codec/wm8904.
Interface File(s)
This table lists and describes the header files that must be included (i.e., using #include) by any code that uses this library.
Source File Name Description
/drv_wm8904.h Header file that exports the driver API.
Required File(s)
All of the required files listed in the following table are automatically added into the MPLAB X IDE project by the MHC
when the library is selected for use.
This table lists and describes the source and header files that must always be included in the MPLAB X IDE project to build this library.
Source File Name Description
/src/dynamic/drv_wm8904.c This file contains implementation of the WM8904 Codec Driver.
Optional File(s)
This table lists and describes the source and header files that may optionally be included if required for the desired implementation.
Source File Name Description
N/A No optional files are available for this library.
Module Dependencies
The WM8904 Codec Driver Library depends on the following modules:
• I2S Driver Library
• I2C Driver Library
Library Interface
a) System Interaction Functions
Name Description
DRV_WM8904_Initialize Initializes hardware and data for the instance of the WM8904 DAC module
DRV_WM8904_Deinitialize Deinitializes the specified instance of the WM8904 driver module
DRV_WM8904_Status Gets the current status of the WM8904 driver module.
DRV_WM8904_Tasks Maintains the driver's control and data interface state machine.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 323
b) Client Setup Functions
Name Description
DRV_WM8904_Open Opens the specified WM8904 driver instance and returns a handle to it
DRV_WM8904_Close Closes an opened-instance of the WM8904 driver
DRV_WM8904_BufferEventHandlerSet This function allows a client to identify a buffer event handling function for the driver to
call back when queued buffer transfers have finished.
DRV_WM8904_CommandEventHandlerSet This function allows a client to identify a command event handling function for the
driver to call back when the last submitted command have finished.
c) Data Transfer Functions
Name Description
DRV_WM8904_BufferAddRead Schedule a non-blocking driver read operation.
DRV_WM8904_BufferAddWrite Schedule a non-blocking driver write operation.
DRV_WM8904_BufferAddWriteRead Schedule a non-blocking driver write-read operation.
Implementation: Dynamic
d) Settings Functions
Name Description
DRV_WM8904_MuteOff This function disables WM8904 output for soft mute.
DRV_WM8904_MuteOn This function allows WM8904 output for soft mute on.
DRV_WM8904_SamplingRateGet This function gets the sampling rate set on the WM8904.
Implementation: Dynamic
DRV_WM8904_SamplingRateSet This function sets the sampling rate of the media stream.
DRV_WM8904_SetAudioCommunicationMode This function provides a run time audio format configuration
DRV_WM8904_VolumeGet This function gets the volume for WM8904 Codec.
DRV_WM8904_VolumeSet This function sets the volume for WM8904 Codec.
e) Other Functions
Name Description
DRV_WM8904_VersionGet This function returns the version of WM8904 driver
DRV_WM8904_VersionStrGet This function returns the version of WM8904 driver in string format.
f) Data Types and Constants
Name Description
_DRV_WM8904_H Include files.
DRV_WM8904_BUFFER_HANDLE_INVALID Definition of an invalid buffer handle.
DRV_WM8904_COUNT Number of valid WM8904 driver indices
DRV_WM8904_INDEX_0 WM8904 driver index definitions
DRV_WM8904_INDEX_1 This is macro DRV_WM8904_INDEX_1.
DRV_WM8904_INDEX_2 This is macro DRV_WM8904_INDEX_2.
DRV_WM8904_INDEX_3 This is macro DRV_WM8904_INDEX_3.
DRV_WM8904_INDEX_4 This is macro DRV_WM8904_INDEX_4.
DRV_WM8904_INDEX_5 This is macro DRV_WM8904_INDEX_5.
DRV_WM8904_BUFFER_EVENT Identifies the possible events that can result from a buffer add request.
DRV_WM8904_BUFFER_EVENT_HANDLER Pointer to a WM8904 Driver Buffer Event handler function
DRV_WM8904_BUFFER_HANDLE Handle identifying a write buffer passed to the driver.
DRV_WM8904_CHANNEL Identifies Left/Right Audio channel
DRV_WM8904_COMMAND_EVENT_HANDLER Pointer to a WM8904 Driver Command Event Handler Function
DRV_WM8904_INIT Defines the data required to initialize or reinitialize the WM8904 driver
Description
This section describes the API functions of the WM8904 Codec Driver library.
Refer to each section for a detailed description.
a) System Interaction Functions
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 324
DRV_WM8904_Initialize Function
Initializes hardware and data for the instance of the WM8904 DAC module
File
drv_wm8904.h
C
SYS_MODULE_OBJ DRV_WM8904_Initialize(const SYS_MODULE_INDEX drvIndex, const SYS_MODULE_INIT * const init);
Returns
If successful, returns a valid handle to a driver instance object. Otherwise, it returns SYS_MODULE_OBJ_INVALID.
Description
This routine initializes the WM8904 driver instance for the specified driver index, making it ready for clients to open and use it. The initialization
data is specified by the init parameter. The initialization may fail if the number of driver objects allocated are insufficient or if the specified driver
instance is already initialized.
Remarks
This routine must be called before any other WM8904 routine is called.
This routine should only be called once during system initialization unless DRV_WM8904_Deinitialize is called to deinitialize the driver instance.
This routine will NEVER block for hardware access.
Preconditions
DRV_I2S_Initialize must be called before calling this function to initialize the data interface of this Codec driver. DRV_I2C_Initialize must be called
if SPI driver is used for handling the control interface of this Codec driver.
Example
DRV_WM8904_INIT init;
SYS_MODULE_OBJ objectHandle;
init->inUse = true;
init->status = SYS_STATUS_BUSY;
init->numClients = 0;
init->i2sDriverModuleIndex = wm8904Init->i2sDriverModuleIndex;
init->i2cDriverModuleIndex = wm8904Init->i2cDriverModuleIndex;
init->samplingRate = DRV_WM8904_AUDIO_SAMPLING_RATE;
init->audioDataFormat = DRV_WM8904_AUDIO_DATA_FORMAT_MACRO;
init->isInInterruptContext = false;
init->commandCompleteCallback = (DRV_WM8904_COMMAND_EVENT_HANDLER)0;
init->commandContextData = 0;
init->mclk_multiplier = DRV_WM8904_MCLK_SAMPLE_FREQ_MULTPLIER;
objectHandle = DRV_WM8904_Initialize(DRV_WM8904_0, (SYS_MODULE_INIT*)init);
if (SYS_MODULE_OBJ_INVALID == objectHandle)
{
// Handle error
}
Parameters
Parameters Description
drvIndex Identifier for the driver instance to be initialized
init Pointer to the data structure containing any data necessary to initialize the hardware. This
pointer may be null if no data is required and default initialization is to be used.
Function
SYS_MODULE_OBJ DRV_WM8904_Initialize
(
const SYS_MODULE_INDEX drvIndex,
const SYS_MODULE_INIT *const init
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 325
);
DRV_WM8904_Deinitialize Function
Deinitializes the specified instance of the WM8904 driver module
File
drv_wm8904.h
C
void DRV_WM8904_Deinitialize(SYS_MODULE_OBJ object);
Returns
None.
Description
Deinitializes the specified instance of the WM8904 driver module, disabling its operation (and any hardware). Invalidates all the internal data.
Remarks
Once the Initialize operation has been called, the De-initialize operation must be called before the Initialize operation can be called again. This
routine will NEVER block waiting for hardware.
Preconditions
Function DRV_WM8904_Initialize should have been called before calling this function.
Example
SYS_MODULE_OBJ object; // Returned from DRV_WM8904_Initialize
SYS_STATUS status;
DRV_WM8904_Deinitialize(object);
status = DRV_WM8904_Status(object);
if (SYS_MODULE_DEINITIALIZED != status)
{
// Check again later if you need to know
// when the driver is deinitialized.
}
Parameters
Parameters Description
object Driver object handle, returned from the DRV_WM8904_Initialize routine
Function
void DRV_WM8904_Deinitialize( SYS_MODULE_OBJ object)
DRV_WM8904_Status Function
Gets the current status of the WM8904 driver module.
File
drv_wm8904.h
C
SYS_STATUS DRV_WM8904_Status(SYS_MODULE_OBJ object);
Returns
SYS_STATUS_DEINITIALIZED - Indicates that the driver has been deinitialized
SYS_STATUS_READY - Indicates that any previous module operation for the specified module has completed
SYS_STATUS_BUSY - Indicates that a previous module operation for the specified module has not yet completed
SYS_STATUS_ERROR - Indicates that the specified module is in an error state
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 326
Description
This routine provides the current status of the WM8904 driver module.
Remarks
A driver can opened only when its status is SYS_STATUS_READY.
Preconditions
Function DRV_WM8904_Initialize should have been called before calling this function.
Example
SYS_MODULE_OBJ object; // Returned from DRV_WM8904_Initialize
SYS_STATUS WM8904Status;
WM8904Status = DRV_WM8904_Status(object);
if (SYS_STATUS_READY == WM8904Status)
{
// This means the driver can be opened using the
// DRV_WM8904_Open() function.
}
Parameters
Parameters Description
object Driver object handle, returned from the DRV_WM8904_Initialize routine
Function
SYS_STATUS DRV_WM8904_Status( SYS_MODULE_OBJ object)
DRV_WM8904_Tasks Function
Maintains the driver's control and data interface state machine.
File
drv_wm8904.h
C
void DRV_WM8904_Tasks(SYS_MODULE_OBJ object);
Returns
None.
Description
This routine is used to maintain the driver's internal control and data interface state machine and implement its control and data interface
implementations. This function should be called from the SYS_Tasks() function.
Remarks
This routine is normally not called directly by an application. It is called by the system's Tasks routine (SYS_Tasks).
Preconditions
The DRV_WM8904_Initialize routine must have been called for the specified WM8904 driver instance.
Example
SYS_MODULE_OBJ object; // Returned from DRV_WM8904_Initialize
while (true)
{
DRV_WM8904_Tasks (object);
// Do other tasks
}
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 327
Parameters
Parameters Description
object Object handle for the specified driver instance (returned from DRV_WM8904_Initialize)
Function
void DRV_WM8904_Tasks(SYS_MODULE_OBJ object);
b) Client Setup Functions
DRV_WM8904_Open Function
Opens the specified WM8904 driver instance and returns a handle to it
File
drv_wm8904.h
C
DRV_HANDLE DRV_WM8904_Open(const SYS_MODULE_INDEX iDriver, const DRV_IO_INTENT ioIntent);
Returns
If successful, the routine returns a valid open-instance handle (a number identifying both the caller and the module instance).
If an error occurs, the return value is DRV_HANDLE_INVALID. Error can occur
• if the number of client objects allocated via DRV_WM8904_CLIENTS_NUMBER is insufficient.
• if the client is trying to open the driver but driver has been opened exclusively by another client.
• if the driver hardware instance being opened is not initialized or is invalid.
• if the ioIntent options passed are not relevant to this driver.
Description
This routine opens the specified WM8904 driver instance and provides a handle that must be provided to all other client-level operations to identify
the caller and the instance of the driver. The ioIntent parameter defines how the client interacts with this driver instance.
The DRV_IO_INTENT_BLOCKING and DRV_IO_INTENT_NONBLOCKING ioIntent options are not relevant to this driver. All the data transfer
functions of this driver are non blocking.
WM8904 can be opened with DRV_IO_INTENT_WRITE, or DRV_IO_INTENT_READ or DRV_IO_INTENT_WRITEREAD io_intent option. This
decides whether the driver is used for headphone output, or microphone input or both modes simultaneously.
Specifying a DRV_IO_INTENT_EXCLUSIVE will cause the driver to provide exclusive access to this client. The driver cannot be opened by any
other client.
Remarks
The handle returned is valid until the DRV_WM8904_Close routine is called. This routine will NEVER block waiting for hardware.If the requested
intent flags are not supported, the routine will return DRV_HANDLE_INVALID. This function is thread safe in a RTOS application. It should not be
called in an ISR.
Preconditions
Function DRV_WM8904_Initialize must have been called before calling this function.
Example
DRV_HANDLE handle;
handle = DRV_WM8904_Open(DRV_WM8904_INDEX_0, DRV_IO_INTENT_WRITEREAD | DRV_IO_INTENT_EXCLUSIVE);
if (DRV_HANDLE_INVALID == handle)
{
// Unable to open the driver
// May be the driver is not initialized or the initialization
// is not complete.
}
Parameters
Parameters Description
drvIndex Identifier for the object instance to be opened
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 328
ioIntent Zero or more of the values from the enumeration DRV_IO_INTENT "ORed" together to
indicate the intended use of the driver. See function description for details.
Function
DRV_HANDLE DRV_WM8904_Open
(
const SYS_MODULE_INDEX drvIndex,
const DRV_IO_INTENT ioIntent
)
DRV_WM8904_Close Function
Closes an opened-instance of the WM8904 driver
File
drv_wm8904.h
C
void DRV_WM8904_Close(const DRV_HANDLE handle);
Returns
• None
Description
This routine closes an opened-instance of the WM8904 driver, invalidating the handle. Any buffers in the driver queue that were submitted by this
client will be removed. After calling this routine, the handle passed in "handle" must not be used with any of the remaining driver routines. A new
handle must be obtained by calling DRV_WM8904_Open before the caller may use the driver again
Remarks
Usually there is no need for the driver client to verify that the Close operation has completed. The driver will abort any ongoing operations when
this routine is called.
Preconditions
The DRV_WM8904_Initialize routine must have been called for the specified WM8904 driver instance.
DRV_WM8904_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE handle; // Returned from DRV_WM8904_Open
DRV_WM8904_Close(handle);
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
void DRV_WM8904_Close( DRV_Handle handle )
DRV_WM8904_BufferEventHandlerSet Function
This function allows a client to identify a buffer event handling function for the driver to call back when queued buffer transfers have finished.
File
drv_wm8904.h
C
void DRV_WM8904_BufferEventHandlerSet(DRV_HANDLE handle, const DRV_WM8904_BUFFER_EVENT_HANDLER
eventHandler, const uintptr_t contextHandle);
Returns
None.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 329
Description
This function allows a client to identify a buffer event handling function for the driver to call back when queued buffer transfers have finished. When
a client calls DRV_WM8904_BufferAddWrite function, it is provided with a handle identifying the buffer that was added to the driver's buffer queue.
The driver will pass this handle back to the client by calling "eventHandler" function when the buffer transfer has completed.
The event handler should be set before the client performs any "buffer add" operations that could generate events. The event handler once set,
persists until the client closes the driver or sets another event handler (which could be a "NULL" pointer to indicate no callback).
Remarks
If the client does not want to be notified when the queued buffer transfer has completed, it does not need to register a callback.
Preconditions
The DRV_WM8904_Initialize routine must have been called for the specified WM8904 driver instance.
DRV_WM8904_Open must have been called to obtain a valid opened device handle.
Example
MY_APP_OBJ myAppObj;
uint8_t mybuffer[MY_BUFFER_SIZE];
DRV_WM8904_BUFFER_HANDLE bufferHandle;
// myWM8904Handle is the handle returned
// by the DRV_WM8904_Open function.
// Client registers an event handler with driver
DRV_WM8904_BufferEventHandlerSet(myWM8904Handle,
APP_WM8904BufferEventHandler, (uintptr_t)&myAppObj);
DRV_WM8904_BufferAddWrite(myWM8904handle, &bufferHandle
myBuffer, MY_BUFFER_SIZE);
if(DRV_WM8904_BUFFER_HANDLE_INVALID == bufferHandle)
{
// Error handling here
}
// Event is received when
// the buffer is processed.
void APP_WM8904BufferEventHandler(DRV_WM8904_BUFFER_EVENT event,
DRV_WM8904_BUFFER_HANDLE bufferHandle, uintptr_t contextHandle)
{
// contextHandle points to myAppObj.
switch(event)
{
case DRV_WM8904_BUFFER_EVENT_COMPLETE:
// This means the data was transferred.
break;
case DRV_WM8904_BUFFER_EVENT_ERROR:
// Error handling here.
break;
default:
break;
}
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
eventHandler Pointer to the event handler function.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 330
context The value of parameter will be passed back to the client unchanged, when the eventHandler
function is called. It can be used to identify any client specific data object that identifies the
instance of the client module (for example, it may be a pointer to the client module's state
structure).
Function
void DRV_WM8904_BufferEventHandlerSet
(
DRV_HANDLE handle,
const DRV_WM8904_BUFFER_EVENT_HANDLER eventHandler,
const uintptr_t contextHandle
)
DRV_WM8904_CommandEventHandlerSet Function
This function allows a client to identify a command event handling function for the driver to call back when the last submitted command have
finished.
File
drv_wm8904.h
C
void DRV_WM8904_CommandEventHandlerSet(DRV_HANDLE handle, const DRV_WM8904_COMMAND_EVENT_HANDLER
eventHandler, const uintptr_t contextHandle);
Returns
None.
Description
This function allows a client to identify a command event handling function for the driver to call back when the last submitted command have
finished.
The event handler should be set before the client performs any "WM8904 Codec Specific Client Routines" operations that could generate events.
The event handler once set, persists until the client closes the driver or sets another event handler (which could be a "NULL" pointer to indicate no
callback).
Remarks
If the client does not want to be notified when the command has completed, it does not need to register a callback.
Preconditions
The DRV_WM8904_Initialize routine must have been called for the specified WM8904 driver instance.
DRV_WM8904_Open must have been called to obtain a valid opened device handle.
Example
MY_APP_OBJ myAppObj;
uint8_t mybuffer[MY_BUFFER_SIZE];
DRV_WM8904_BUFFER_HANDLE bufferHandle;
// myWM8904Handle is the handle returned
// by the DRV_WM8904_Open function.
// Client registers an event handler with driver
DRV_WM8904_CommandEventHandlerSet(myWM8904Handle,
APP_WM8904CommandEventHandler, (uintptr_t)&myAppObj);
DRV_WM8904_DeEmphasisFilterSet(myWM8904Handle, DRV_WM8904_DEEMPHASIS_FILTER_44_1KHZ)
// Event is received when
// the buffer is processed.
void APP_WM8904CommandEventHandler(uintptr_t contextHandle)
{
// contextHandle points to myAppObj.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 331
switch(event)
{
// Last Submitted command is completed.
// Perform further processing here
}
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
eventHandler Pointer to the event handler function.
context The value of parameter will be passed back to the client unchanged, when the eventHandler
function is called. It can be used to identify any client specific data object that identifies the
instance of the client module (for example, it may be a pointer to the client module's state
structure).
Function
void DRV_WM8904_CommandEventHandlerSet
(
DRV_HANDLE handle,
const DRV_WM8904_COMMAND_EVENT_HANDLER eventHandler,
const uintptr_t contextHandle
)
c) Data Transfer Functions
DRV_WM8904_BufferAddRead Function
Schedule a non-blocking driver read operation.
File
drv_wm8904.h
C
void DRV_WM8904_BufferAddRead(const DRV_HANDLE handle, DRV_WM8904_BUFFER_HANDLE * bufferHandle, void *
buffer, size_t size);
Returns
The bufferHandle parameter will contain the return buffer handle. This will be DRV_WM8904_BUFFER_HANDLE_INVALID if the function was not
successful.
Description
This function schedules a non-blocking read operation. The function returns with a valid buffer handle in the bufferHandle argument if the read
request was scheduled successfully. The function adds the request to the hardware instance receive queue and returns immediately. While the
request is in the queue, the application buffer is owned by the driver and should not be modified. The function returns
DRV_WM8904_BUFFER_HANDLE_INVALID
• if a buffer could not be allocated to the request
• if the input buffer pointer is NULL
• if the buffer size is 0.
• if the queue is full or the queue depth is insufficient
If the requesting client registered an event callback with the driver, the driver will issue a DRV_WM8904_BUFFER_EVENT_COMPLETE event if
the buffer was processed successfully of DRV_WM8904_BUFFER_EVENT_ERROR event if the buffer was not processed successfully.
Remarks
This function is thread safe in a RTOS application. It can be called from within the WM8904 Driver Buffer Event Handler that is registered by this
client. It should not be called in the event handler associated with another WM8904 driver instance. It should not otherwise be called directly in an
ISR.
Preconditions
The DRV_WM8904_Initialize routine must have been called for the specified WM8904 device instance and the DRV_WM8904_Status must have
returned SYS_STATUS_READY.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 332
DRV_WM8904_Open must have been called to obtain a valid opened device handle.
DRV_IO_INTENT_READ must have been specified in the DRV_WM8904_Open call.
Parameters
Parameters Description
handle Handle of the WM8904 instance as return by the DRV_WM8904_Open function.
buffer Data to be transmitted.
size Buffer size in bytes.
bufferHandle Pointer to an argument that will contain the return buffer handle.
Function
void DRV_WM8904_BufferAddRead
(
const DRV_HANDLE handle,
DRV_WM8904_BUFFER_HANDLE *bufferHandle,
void *buffer, size_t size
)
DRV_WM8904_BufferAddWrite Function
Schedule a non-blocking driver write operation.
File
drv_wm8904.h
C
void DRV_WM8904_BufferAddWrite(const DRV_HANDLE handle, DRV_WM8904_BUFFER_HANDLE * bufferHandle, void *
buffer, size_t size);
Returns
The bufferHandle parameter will contain the return buffer handle. This will be DRV_WM8904_BUFFER_HANDLE_INVALID if the function was not
successful.
Description
This function schedules a non-blocking write operation. The function returns with a valid buffer handle in the bufferHandle argument if the write
request was scheduled successfully. The function adds the request to the hardware instance transmit queue and returns immediately. While the
request is in the queue, the application buffer is owned by the driver and should not be modified. The function returns
DRV_WM8904_BUFFER_HANDLE_INVALID:
• if a buffer could not be allocated to the request
• if the input buffer pointer is NULL
• if the buffer size is 0.
• if the queue is full or the queue depth is insufficient
If the requesting client registered an event callback with the driver, the driver will issue a DRV_WM8904_BUFFER_EVENT_COMPLETE event if
the buffer was processed successfully of DRV_WM8904_BUFFER_EVENT_ERROR event if the buffer was not processed successfully.
Remarks
This function is thread safe in a RTOS application. It can be called from within the WM8904 Driver Buffer Event Handler that is registered by this
client. It should not be called in the event handler associated with another WM8904 driver instance. It should not otherwise be called directly in an
ISR.
Preconditions
The DRV_WM8904_Initialize routine must have been called for the specified WM8904 device instance and the DRV_WM8904_Status must have
returned SYS_STATUS_READY.
DRV_WM8904_Open must have been called to obtain a valid opened device handle.
DRV_IO_INTENT_WRITE must have been specified in the DRV_WM8904_Open call.
Example
MY_APP_OBJ myAppObj;
uint8_t mybuffer[MY_BUFFER_SIZE];
DRV_WM8904_BUFFER_HANDLE bufferHandle;
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 333
// myWM8904Handle is the handle returned
// by the DRV_WM8904_Open function.
// Client registers an event handler with driver
DRV_WM8904_BufferEventHandlerSet(myWM8904Handle,
APP_WM8904BufferEventHandler, (uintptr_t)&myAppObj);
DRV_WM8904_BufferAddWrite(myWM8904handle, &bufferHandle
myBuffer, MY_BUFFER_SIZE);
if(DRV_WM8904_BUFFER_HANDLE_INVALID == bufferHandle)
{
// Error handling here
}
// Event is received when
// the buffer is processed.
void APP_WM8904BufferEventHandler(DRV_WM8904_BUFFER_EVENT event,
DRV_WM8904_BUFFER_HANDLE bufferHandle, uintptr_t contextHandle)
{
// contextHandle points to myAppObj.
switch(event)
{
case DRV_WM8904_BUFFER_EVENT_COMPLETE:
// This means the data was transferred.
break;
case DRV_WM8904_BUFFER_EVENT_ERROR:
// Error handling here.
break;
default:
break;
}
}
Parameters
Parameters Description
handle Handle of the WM8904 instance as return by the DRV_WM8904_Open function.
buffer Data to be transmitted.
size Buffer size in bytes.
bufferHandle Pointer to an argument that will contain the return buffer handle.
Function
void DRV_WM8904_BufferAddWrite
(
const DRV_HANDLE handle,
DRV_WM8904_BUFFER_HANDLE *bufferHandle,
void *buffer, size_t size
)
DRV_WM8904_BufferAddWriteRead Function
Schedule a non-blocking driver write-read operation.
Implementation: Dynamic
File
drv_wm8904.h
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 334
C
void DRV_WM8904_BufferAddWriteRead(const DRV_HANDLE handle, DRV_WM8904_BUFFER_HANDLE * bufferHandle, void *
transmitBuffer, void * receiveBuffer, size_t size);
Returns
The bufferHandle parameter will contain the return buffer handle. This will be DRV_WM8904_BUFFER_HANDLE_INVALID if the function was not
successful.
Description
This function schedules a non-blocking write-read operation. The function returns with a valid buffer handle in the bufferHandle argument if the
write-read request was scheduled successfully. The function adds the request to the hardware instance queue and returns immediately. While the
request is in the queue, the application buffer is owned by the driver and should not be modified. The function returns
DRV_WM8904_BUFFER_EVENT_COMPLETE:
• if a buffer could not be allocated to the request
• if the input buffer pointer is NULL
• if the client opened the driver for read only or write only
• if the buffer size is 0
• if the queue is full or the queue depth is insufficient
If the requesting client registered an event callback with the driver, the driver will issue a DRV_WM8904_BUFFER_EVENT_COMPLETE event if
the buffer was processed successfully of DRV_WM8904_BUFFER_EVENT_ERROR event if the buffer was not processed successfully.
Remarks
This function is thread safe in a RTOS application. It can be called from within the WM8904 Driver Buffer Event Handler that is registered by this
client. It should not be called in the event handler associated with another WM8904 driver instance. It should not otherwise be called directly in an
ISR.
This function is useful when there is valid read expected for every WM8904 write. The transmit and receive size must be same.
Preconditions
The DRV_WM8904_Initialize routine must have been called for the specified WM8904 device instance and the DRV_WM8904_Status must have
returned SYS_STATUS_READY.
DRV_WM8904_Open must have been called to obtain a valid opened device handle.
DRV_IO_INTENT_READWRITE must have been specified in the DRV_WM8904_Open call.
Example
MY_APP_OBJ myAppObj;
uint8_t mybufferTx[MY_BUFFER_SIZE];
uint8_t mybufferRx[MY_BUFFER_SIZE];
DRV_WM8904_BUFFER_HANDLE bufferHandle;
// mywm8904Handle is the handle returned
// by the DRV_WM8904_Open function.
// Client registers an event handler with driver
DRV_WM8904_BufferEventHandlerSet(mywm8904Handle,
APP_WM8904BufferEventHandler, (uintptr_t)&myAppObj);
DRV_WM8904_BufferAddWriteRead(mywm8904handle, &bufferHandle,
mybufferTx,mybufferRx,MY_BUFFER_SIZE);
if(DRV_WM8904_BUFFER_HANDLE_INVALID == bufferHandle)
{
// Error handling here
}
// Event is received when
// the buffer is processed.
void APP_WM8904BufferEventHandler(DRV_WM8904_BUFFER_EVENT event,
DRV_WM8904_BUFFER_HANDLE bufferHandle, uintptr_t contextHandle)
{
// contextHandle points to myAppObj.
switch(event)
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 335
{
case DRV_WM8904_BUFFER_EVENT_COMPLETE:
// This means the data was transferred.
break;
case DRV_WM8904_BUFFER_EVENT_ERROR:
// Error handling here.
break;
default:
break;
}
}
Parameters
Parameters Description
handle Handle of the WM8904 instance as returned by the DRV_WM8904_Open function
bufferHandle Pointer to an argument that will contain the return buffer handle
transmitBuffer The buffer where the transmit data will be stored
receiveBuffer The buffer where the received data will be stored
size Buffer size in bytes
Function
void DRV_WM8904_BufferAddWriteRead
(
const DRV_HANDLE handle,
DRV_WM8904_BUFFER_HANDLE *bufferHandle,
void *transmitBuffer,
void *receiveBuffer,
size_t size
)
d) Settings Functions
DRV_WM8904_MuteOff Function
This function disables WM8904 output for soft mute.
File
drv_wm8904.h
C
void DRV_WM8904_MuteOff(DRV_HANDLE handle);
Returns
None.
Description
This function disables WM8904 output for soft mute.
Remarks
None.
Preconditions
The DRV_WM8904_Initialize routine must have been called for the specified WM8904 driver instance.
DRV_WM8904_Open must have been called to obtain a valid opened device handle.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 336
Example
// myAppObj is an application specific object.
MY_APP_OBJ myAppObj;
uint8_t mybuffer[MY_BUFFER_SIZE];
DRV_BUFFER_HANDLE bufferHandle;
// myWM8904Handle is the handle returned
// by the DRV_WM8904_Open function.
DRV_WM8904_MuteOff(myWM8904Handle); //WM8904 output soft mute disabled
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
void DRV_WM8904_MuteOff( DRV_HANDLE handle)
DRV_WM8904_MuteOn Function
This function allows WM8904 output for soft mute on.
File
drv_wm8904.h
C
void DRV_WM8904_MuteOn(DRV_HANDLE handle);
Returns
None.
Description
This function Enables WM8904 output for soft mute.
Remarks
None.
Preconditions
The DRV_WM8904_Initialize routine must have been called for the specified WM8904 driver instance.
DRV_WM8904_Open must have been called to obtain a valid opened device handle.
Example
// myAppObj is an application specific object.
MY_APP_OBJ myAppObj;
uint8_t mybuffer[MY_BUFFER_SIZE];
DRV_BUFFER_HANDLE bufferHandle;
// myWM8904Handle is the handle returned
// by the DRV_WM8904_Open function.
DRV_WM8904_MuteOn(myWM8904Handle); //WM8904 output soft muted
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
void DRV_WM8904_MuteOn( DRV_HANDLE handle);
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 337
DRV_WM8904_SamplingRateGet Function
This function gets the sampling rate set on the WM8904.
Implementation: Dynamic
File
drv_wm8904.h
C
uint32_t DRV_WM8904_SamplingRateGet(DRV_HANDLE handle);
Description
This function gets the sampling rate set on the DAC WM8904.
Remarks
None.
Example
uint32_t baudRate;
// myWM8904Handle is the handle returned
// by the DRV_WM8904_Open function.
baudRate = DRV_WM8904_SamplingRateGet(myWM8904Handle);
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
uint32_t DRV_WM8904_SamplingRateGet( DRV_HANDLE handle)
DRV_WM8904_SamplingRateSet Function
This function sets the sampling rate of the media stream.
File
drv_wm8904.h
C
void DRV_WM8904_SamplingRateSet(DRV_HANDLE handle, uint32_t samplingRate);
Returns
None.
Description
This function sets the media sampling rate for the client handle.
Remarks
None.
Preconditions
The DRV_WM8904_Initialize routine must have been called for the specified WM8904 driver instance.
DRV_WM8904_Open must have been called to obtain a valid opened device handle.
Example
// myWM8904Handle is the handle returned
// by the DRV_WM8904_Open function.
DRV_WM8904_SamplingRateSet(myWM8904Handle, 48000); //Sets 48000 media sampling rate
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 338
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
samplingRate Sampling frequency in Hz
Function
void DRV_WM8904_SamplingRateSet( DRV_HANDLE handle, uint32_t samplingRate)
DRV_WM8904_SetAudioCommunicationMode Function
This function provides a run time audio format configuration
File
drv_wm8904.h
C
void DRV_WM8904_SetAudioCommunicationMode(DRV_HANDLE handle, const DATA_LENGTH dl, const SAMPLE_LENGTH sl);
Returns
None
Description
This function sets up audio mode in I2S protocol
Remarks
None.
Preconditions
The DRV_WM8904_Initialize routine must have been called for the specified WM8904 driver instance.
DRV_WM8904_Open must have been called to obtain a valid opened device handle.
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
dl Data length for I2S audio interface
sl Left/Right Sample Length for I2S audio interface
Function
void DRV_WM8904_SetAudioCommunicationMode
(
DRV_HANDLE handle,
const DATA_LENGTH dl,
const SAMPLE_LENGTH sl
)
DRV_WM8904_VolumeGet Function
This function gets the volume for WM8904 Codec.
File
drv_wm8904.h
C
uint8_t DRV_WM8904_VolumeGet(DRV_HANDLE handle, DRV_WM8904_CHANNEL channel);
Returns
None.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 339
Description
This functions gets the current volume programmed to the Codec WM8904.
Remarks
None.
Preconditions
The DRV_WM8904_Initialize routine must have been called for the specified WM8904 driver instance.
DRV_WM8904_Open must have been called to obtain a valid opened device handle.
Example
// myAppObj is an application specific object.
MY_APP_OBJ myAppObj;
uint8_t volume;
// myWM8904Handle is the handle returned
// by the DRV_WM8904_Open function.
volume = DRV_WM8904_VolumeGet(myWM8904Handle, DRV_WM8904_CHANNEL_LEFT);
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
channel argument indicating Left or Right or Both channel volume to be modified
Function
uint8_t DRV_WM8904_VolumeGet( DRV_HANDLE handle, DRV_WM8904_CHANNEL channel)
DRV_WM8904_VolumeSet Function
This function sets the volume for WM8904 Codec.
File
drv_wm8904.h
C
void DRV_WM8904_VolumeSet(DRV_HANDLE handle, DRV_WM8904_CHANNEL channel, uint8_t volume);
Returns
None
Description
This functions sets the volume value from 0-255. The codec has DAC value to volume range mapping as :- 00 H : +12dB FF H : -115dB In order to
make the volume value to dB mapping monotonically increasing from 00 to FF, re-mapping is introduced which reverses the volume value to dB
mapping as well as normalizes the volume range to a more audible dB range. The current driver implementation assumes that all dB values under
-60 dB are inaudible to the human ear. Re-Mapped values 00 H : -60 dB FF H : +12 dB
Remarks
None.
Preconditions
The DRV_WM8904_Initialize routine must have been called for the specified WM8904 driver instance.
DRV_WM8904_Open must have been called to obtain a valid opened device handle.
Example
// myAppObj is an application specific object.
MY_APP_OBJ myAppObj;
uint8_t mybuffer[MY_BUFFER_SIZE];
DRV_BUFFER_HANDLE bufferHandle;
// myWM8904Handle is the handle returned
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 340
// by the DRV_WM8904_Open function.
DRV_WM8904_VolumeSet(myWM8904Handle,DRV_WM8904_CHANNEL_LEFT, 120);
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
channel argument indicating Left or Right or Both channel volume to be modified
volume volume value specified in the range 0-255 (0x00 to 0xFF)
Function
void DRV_WM8904_VolumeSet( DRV_HANDLE handle, DRV_WM8904_CHANNEL channel, uint8_t volume);
e) Other Functions
DRV_WM8904_VersionGet Function
This function returns the version of WM8904 driver
File
drv_wm8904.h
C
uint32_t DRV_WM8904_VersionGet();
Returns
returns the version of WM8904 driver.
Description
The version number returned from the DRV_WM8904_VersionGet function is an unsigned integer in the following decimal format. * 10000 + * 100
+ Where the numbers are represented in decimal and the meaning is the same as above. Note that there is no numerical representation of
release type.
Remarks
None.
Preconditions
None.
Example 1
For version "0.03a", return: 0 * 10000 + 3 * 100 + 0 For version "1.00", return: 1 * 100000 + 0 * 100 + 0
Example 2
uint32_t WM8904version;
WM8904version = DRV_WM8904_VersionGet();
Function
uint32_t DRV_WM8904_VersionGet( void )
DRV_WM8904_VersionStrGet Function
This function returns the version of WM8904 driver in string format.
File
drv_wm8904.h
C
int8_t* DRV_WM8904_VersionStrGet();
Returns
returns a string containing the version of WM8904 driver.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 341
Description
The DRV_WM8904_VersionStrGet function returns a string in the format: ".[.][]" Where: is the WM8904 driver's version number. is the WM8904
driver's version number. is an optional "patch" or "dot" release number (which is not included in the string if it equals "00"). is an optional release
type ("a" for alpha, "b" for beta ? not the entire word spelled out) that is not included if the release is a production version (I.e. Not an alpha or beta).
The String does not contain any spaces. For example, "0.03a" "1.00"
Remarks
None
Preconditions
None.
Example
int8_t *WM8904string;
WM8904string = DRV_WM8904_VersionStrGet();
Function
int8_t* DRV_WM8904_VersionStrGet(void)
f) Data Types and Constants
_DRV_WM8904_H Macro
File
drv_wm8904.h
C
#define _DRV_WM8904_H
Description
Include files.
DRV_WM8904_BUFFER_HANDLE_INVALID Macro
Definition of an invalid buffer handle.
File
drv_wm8904.h
C
#define DRV_WM8904_BUFFER_HANDLE_INVALID ((DRV_WM8904_BUFFER_HANDLE)(-1))
Description
WM8904 Driver Invalid Buffer Handle
This is the definition of an invalid buffer handle. An invalid buffer handle is returned by DRV_WM8904_BufferAddWrite() and the
DRV_WM8904_BufferAddRead() function if the buffer add request was not successful.
Remarks
None.
DRV_WM8904_COUNT Macro
Number of valid WM8904 driver indices
File
drv_wm8904.h
C
#define DRV_WM8904_COUNT
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 342
Description
WM8904 Driver Module Count
This constant identifies the maximum number of WM8904 Driver instances that should be defined by the application. Defining more instances than
this constant will waste RAM memory space.
This constant can also be used by the application to identify the number of WM8904 instances on this microcontroller.
Remarks
This value is part-specific.
DRV_WM8904_INDEX_0 Macro
WM8904 driver index definitions
File
drv_wm8904.h
C
#define DRV_WM8904_INDEX_0 0
Description
Driver WM8904 Module Index
These constants provide WM8904 driver index definition.
Remarks
These constants should be used in place of hard-coded numeric literals. These values should be passed into the DRV_WM8904_Initialize and
DRV_WM8904_Open routines to identify the driver instance in use.
DRV_WM8904_INDEX_1 Macro
File
drv_wm8904.h
C
#define DRV_WM8904_INDEX_1 1
Description
This is macro DRV_WM8904_INDEX_1.
DRV_WM8904_INDEX_2 Macro
File
drv_wm8904.h
C
#define DRV_WM8904_INDEX_2 2
Description
This is macro DRV_WM8904_INDEX_2.
DRV_WM8904_INDEX_3 Macro
File
drv_wm8904.h
C
#define DRV_WM8904_INDEX_3 3
Description
This is macro DRV_WM8904_INDEX_3.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 343
DRV_WM8904_INDEX_4 Macro
File
drv_wm8904.h
C
#define DRV_WM8904_INDEX_4 4
Description
This is macro DRV_WM8904_INDEX_4.
DRV_WM8904_INDEX_5 Macro
File
drv_wm8904.h
C
#define DRV_WM8904_INDEX_5 5
Description
This is macro DRV_WM8904_INDEX_5.
DRV_WM8904_BUFFER_EVENT Enumeration
Identifies the possible events that can result from a buffer add request.
File
drv_wm8904.h
C
typedef enum {
DRV_WM8904_BUFFER_EVENT_COMPLETE,
DRV_WM8904_BUFFER_EVENT_ERROR,
DRV_WM8904_BUFFER_EVENT_ABORT
} DRV_WM8904_BUFFER_EVENT;
Members
Members Description
DRV_WM8904_BUFFER_EVENT_COMPLETE Data was transferred successfully.
DRV_WM8904_BUFFER_EVENT_ERROR Error while processing the request
DRV_WM8904_BUFFER_EVENT_ABORT Data transfer aborted (Applicable in DMA mode)
Description
WM8904 Driver Events
This enumeration identifies the possible events that can result from a buffer add request caused by the client calling either the
DRV_WM8904_BufferAddWrite() or the DRV_WM8904_BufferAddRead() function.
Remarks
One of these values is passed in the "event" parameter of the event handling callback function that the client registered with the driver by calling
the DRV_WM8904_BufferEventHandlerSet function when a buffer transfer request is completed.
DRV_WM8904_BUFFER_EVENT_HANDLER Type
Pointer to a WM8904 Driver Buffer Event handler function
File
drv_wm8904.h
C
typedef void (* DRV_WM8904_BUFFER_EVENT_HANDLER)(DRV_WM8904_BUFFER_EVENT event, DRV_WM8904_BUFFER_HANDLE
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 344
bufferHandle, uintptr_t contextHandle);
Returns
None.
Description
WM8904 Driver Buffer Event Handler Function
This data type defines the required function signature for the WM8904 driver buffer event handling callback function. A client must register a
pointer to a buffer event handling function who's function signature (parameter and return value types) match the types specified by this function
pointer in order to receive buffer related event calls back from the driver.
The parameters and return values are described here and a partial example implementation is provided.
Remarks
If the event is DRV_WM8904_BUFFER_EVENT_COMPLETE, this means that the data was transferred successfully.
If the event is DRV_WM8904_BUFFER_EVENT_ERROR, this means that the data was not transferred successfully. The bufferHandle parameter
contains the buffer handle of the buffer that failed. The DRV_WM8904_BufferProcessedSizeGet() function can be called to find out how many
bytes were processed.
The bufferHandle parameter contains the buffer handle of the buffer that associated with the event.
The context parameter contains a handle to the client context, provided at the time the event handling function was registered using the
DRV_WM8904_BufferEventHandlerSet function. This context handle value is passed back to the client as the "context" parameter. It can be any
value necessary to identify the client context or instance (such as a pointer to the client's data) instance of the client that made the buffer add
request.
The buffer handle in bufferHandle expires after this event handler exits. In that the buffer object that was allocated is deallocated by the driver after
the event handler exits.
The event handler function executes in the data driver(i2S) peripheral's interrupt context when the driver is configured for interrupt mode operation.
It is recommended of the application to not perform process intensive or blocking operations with in this function.
DRV_WM8904_BufferAddWrite function can be called in the event handler to add a buffer to the driver queue.
Example
void APP_MyBufferEventHandler( DRV_WM8904_BUFFER_EVENT event,
DRV_WM8904_BUFFER_HANDLE bufferHandle,
uintptr_t context )
{
MY_APP_DATA_STRUCT pAppData = (MY_APP_DATA_STRUCT) context;
switch(event)
{
case DRV_WM8904_BUFFER_EVENT_COMPLETE:
// Handle the completed buffer.
break;
case DRV_WM8904_BUFFER_EVENT_ERROR:
default:
// Handle error.
break;
}
}
Parameters
Parameters Description
event Identifies the type of event
bufferHandle Handle identifying the buffer to which the event relates
context Value identifying the context of the application that registered the event handling function.
DRV_WM8904_BUFFER_HANDLE Type
Handle identifying a write buffer passed to the driver.
File
drv_wm8904.h
C
typedef uintptr_t DRV_WM8904_BUFFER_HANDLE;
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 345
Description
WM8904 Driver Buffer Handle
A buffer handle value is returned by a call to the DRV_WM8904_BufferAddWrite() or DRV_WM8904_BufferAddRead() function. This handle is
associated with the buffer passed into the function and it allows the application to track the completion of the data from (or into) that buffer.
The buffer handle value returned from the "buffer add" function is returned back to the client by the "event handler callback" function registered
with the driver.
The buffer handle assigned to a client request expires when the client has been notified of the completion of the buffer transfer (after event handler
function that notifies the client returns) or after the buffer has been retired by the driver if no event handler callback was set.
Remarks
None
DRV_WM8904_CHANNEL Enumeration
Identifies Left/Right Audio channel
File
drv_wm8904.h
C
typedef enum {
DRV_WM8904_CHANNEL_LEFT,
DRV_WM8904_CHANNEL_RIGHT,
DRV_WM8904_CHANNEL_LEFT_RIGHT,
DRV_WM8904_NUMBER_OF_CHANNELS
} DRV_WM8904_CHANNEL;
Description
WM8904 Audio Channel
This enumeration identifies Left/Right Audio channel
Remarks
None.
DRV_WM8904_COMMAND_EVENT_HANDLER Type
Pointer to a WM8904 Driver Command Event Handler Function
File
drv_wm8904.h
C
typedef void (* DRV_WM8904_COMMAND_EVENT_HANDLER)(uintptr_t contextHandle);
Returns
None.
Description
WM8904 Driver Command Event Handler Function
This data type defines the required function signature for the WM8904 driver command event handling callback function.
A command is a control instruction to the WM8904 Codec. Example Mute ON/OFF, Zero Detect Enable/Disable etc.
A client must register a pointer to a command event handling function who's function signature (parameter and return value types) match the types
specified by this function pointer in order to receive command related event calls back from the driver.
The parameters and return values are described here and a partial example implementation is provided.
Remarks
The occurrence of this call back means that the last control command was transferred successfully.
The context parameter contains a handle to the client context, provided at the time the event handling function was registered using the
DRV_WM8904_CommandEventHandlerSet function. This context handle value is passed back to the client as the "context" parameter. It can be
any value necessary to identify the client context or instance (such as a pointer to the client's data) instance of the client that made the buffer add
request.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 346
The event handler function executes in the control data driver interrupt context. It is recommended of the application to not perform process
intensive or blocking operations with in this function.
Example
void APP_WM8904CommandEventHandler( uintptr_t context )
{
MY_APP_DATA_STRUCT pAppData = (MY_APP_DATA_STRUCT) context;
// Last Submitted command is completed.
// Perform further processing here
}
Parameters
Parameters Description
context Value identifying the context of the application that registered the event handling function.
DRV_WM8904_INIT Structure
Defines the data required to initialize or reinitialize the WM8904 driver
File
drv_wm8904.h
C
typedef struct {
SYS_MODULE_INIT moduleInit;
SYS_MODULE_INDEX i2sDriverModuleIndex;
SYS_MODULE_INDEX i2cDriverModuleIndex;
uint32_t samplingRate;
uint8_t volume;
DRV_WM8904_AUDIO_DATA_FORMAT audioDataFormat;
bool enableMicInput;
} DRV_WM8904_INIT;
Members
Members Description
SYS_MODULE_INIT moduleInit; System module initialization
SYS_MODULE_INDEX i2sDriverModuleIndex; Identifies data module(I2S) driver ID for data interface of Codec
SYS_MODULE_INDEX i2cDriverModuleIndex; Identifies data module(I2C) driver ID for control interface of Codec
uint32_t samplingRate; Sampling rate
uint8_t volume; Volume
DRV_WM8904_AUDIO_DATA_FORMAT
audioDataFormat;
Identifies the Audio data format
bool enableMicInput; true if mic input path enabled
Description
WM8904 Driver Initialization Data
This data type defines the data required to initialize or reinitialize the WM8904 Codec driver.
Remarks
None.
Files
Files
Name Description
drv_wm8904_config_template.h WM8904 Codec Driver Configuration Template.
drv_wm8904.h WM8904 Codec Driver Interface header file
Description
This section lists the source and header files used by the WM8904Codec Driver Library.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 347
drv_wm8904_config_template.h
WM8904 Codec Driver Configuration Template.
Macros
Name Description
_DRV_WM8904_CONFIG_TEMPLATE_H This is macro _DRV_WM8904_CONFIG_TEMPLATE_H.
DRV_CODEC_WM8904_MODE Specifies if codec is in Master or Slave mode.
DRV_WM8904_BAUD_RATE Specifies the initial baud rate for the codec.
DRV_WM8904_CLIENTS_NUMBER Sets up the maximum number of clients that can be connected to any hardware
instance.
DRV_WM8904_ENABLE_MIC_INPUT Specifies whether to enable the microphone input.
DRV_WM8904_INSTANCES_NUMBER Sets up the maximum number of hardware instances that can be supported
DRV_WM8904_VOLUME Specifies the initial volume level.
Description
WM8904 Codec Driver Configuration Template
These file provides the list of all the configurations that can be used with the driver. This file should not be included in the driver.
File Name
drv_wm8904_config_template.h
Company
Microchip Technology Inc.
drv_wm8904.h
WM8904 Codec Driver Interface header file
Enumerations
Name Description
DATA_LENGTH in bits
DRV_WM8904_AUDIO_DATA_FORMAT Identifies the Serial Audio data interface format.
DRV_WM8904_BUFFER_EVENT Identifies the possible events that can result from a buffer add request.
DRV_WM8904_CHANNEL Identifies Left/Right Audio channel
Functions
Name Description
DRV_WM8904_BufferAddRead Schedule a non-blocking driver read operation.
DRV_WM8904_BufferAddWrite Schedule a non-blocking driver write operation.
DRV_WM8904_BufferAddWriteRead Schedule a non-blocking driver write-read operation.
Implementation: Dynamic
DRV_WM8904_BufferEventHandlerSet This function allows a client to identify a buffer event handling function for the
driver to call back when queued buffer transfers have finished.
DRV_WM8904_Close Closes an opened-instance of the WM8904 driver
DRV_WM8904_CommandEventHandlerSet This function allows a client to identify a command event handling function for the
driver to call back when the last submitted command have finished.
DRV_WM8904_Deinitialize Deinitializes the specified instance of the WM8904 driver module
DRV_WM8904_Initialize Initializes hardware and data for the instance of the WM8904 DAC module
DRV_WM8904_MuteOff This function disables WM8904 output for soft mute.
DRV_WM8904_MuteOn This function allows WM8904 output for soft mute on.
DRV_WM8904_Open Opens the specified WM8904 driver instance and returns a handle to it
DRV_WM8904_SamplingRateGet This function gets the sampling rate set on the WM8904.
Implementation: Dynamic
DRV_WM8904_SamplingRateSet This function sets the sampling rate of the media stream.
DRV_WM8904_SetAudioCommunicationMode This function provides a run time audio format configuration
DRV_WM8904_Status Gets the current status of the WM8904 driver module.
Volume V: MPLAB Harmony Framework Driver Libraries Help Codec Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 348
DRV_WM8904_Tasks Maintains the driver's control and data interface state machine.
DRV_WM8904_VersionGet This function returns the version of WM8904 driver
DRV_WM8904_VersionStrGet This function returns the version of WM8904 driver in string format.
DRV_WM8904_VolumeGet This function gets the volume for WM8904 Codec.
DRV_WM8904_VolumeSet This function sets the volume for WM8904 Codec.
Macros
Name Description
_DRV_WM8904_H Include files.
DRV_I2C_INDEX This is macro DRV_I2C_INDEX.
DRV_WM8904_BUFFER_HANDLE_INVALID Definition of an invalid buffer handle.
DRV_WM8904_COUNT Number of valid WM8904 driver indices
DRV_WM8904_INDEX_0 WM8904 driver index definitions
DRV_WM8904_INDEX_1 This is macro DRV_WM8904_INDEX_1.
DRV_WM8904_INDEX_2 This is macro DRV_WM8904_INDEX_2.
DRV_WM8904_INDEX_3 This is macro DRV_WM8904_INDEX_3.
DRV_WM8904_INDEX_4 This is macro DRV_WM8904_INDEX_4.
DRV_WM8904_INDEX_5 This is macro DRV_WM8904_INDEX_5.
Structures
Name Description
DRV_WM8904_INIT Defines the data required to initialize or reinitialize the WM8904 driver
Types
Name Description
DRV_WM8904_BUFFER_EVENT_HANDLER Pointer to a WM8904 Driver Buffer Event handler function
DRV_WM8904_BUFFER_HANDLE Handle identifying a write buffer passed to the driver.
DRV_WM8904_COMMAND_EVENT_HANDLER Pointer to a WM8904 Driver Command Event Handler Function
Description
WM8904 Codec Driver Interface
The WM8904 Codec device driver interface provides a simple interface to manage the WM8904 16/24/32-Bit Codec that can be interfaced to a
Microchip microcontroller. This file provides the public interface definitions for the WM8904 Codec device driver.
File Name
drv_wm8904.h
Company
Microchip Technology Inc.
Comparator Driver Library
This section describes the Comparator Driver Library.
Introduction
The Comparator Static Driver provides a high-level interface to manage the Comparator module on the Microchip family of microcontrollers.
Description
Through MHC, this driver provides an API to initialize the Comparator module, as well as reference channels, CVREF, inputs, and interrupts.
Library Interface
Function(s)
Name Description
DRV_CMP_Initialize Initializes the Comparator instance for the specified driver index.
Implementation: Static
Volume V: MPLAB Harmony Framework Driver Libraries Help Comparator Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 349
Description
This section describes the Application Programming Interface (API) functions of the Comparator Driver Library.
Function(s)
DRV_CMP_Initialize Function
Initializes the Comparator instance for the specified driver index.
Implementation: Static
File
help_drv_cmp.h
C
void DRV_CMP_Initialize();
Returns
None.
Description
This routine initializes the Comparator driver instance for the specified driver instance, making it ready for clients to use it. The initialization routine
is specified by the MHC parameters. The driver instance index is independent of the Comparator module ID. For example, driver instance 0 can be
assigned to Comparator 2.
Remarks
This routine must be called before any other Comparator routine is called. This routine should only be called once during system initialization.
Preconditions
None.
Function
void DRV_CMP_Initialize( void )
CPLD XC2C64A Driver Library
This section describes the CPLD XC2C64A Driver Library.
Introduction
This library provides an interface to manage the CPLD XC2C64A devices on Microchip starter kits.
Description
A CPLD is provided on the Multimedia Expansion Board (MEB), which can be used to configure the graphics controller bus interface, SPI channel
and Chip Selects used for SPI Flash, the MRF24WBOMA, and the expansion slot. The general I/O inputs are used to change the configuration,
which can be done at run-time.
Specific CPLD configuration information is available in the "Multimedia Expansion Board (MEB) User's Guide" (DS60001160), which is available
from the MEB product page: http://www.microchip.com/Developmenttools/ProductDetails.aspx?PartNO=DM320005
Using the Library
This topic describes the basic architecture of the CPLD XC2C64A Driver Library and provides information and examples on its use.
Description
Interface Header File: drv_xc2c64a.h
The interface to the CPLD XC2C64A Driver Library is defined in the drv_xc2c64a.h header file. Any C language source (.c) file that uses the
CPLD XC2C64A Driver library should include this header.
Please refer to the What is MPLAB Harmony? section for how the driver interacts with the framework.
Volume V: MPLAB Harmony Framework Driver Libraries Help CPLD XC2C64A Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 350
Library Overview
Refer to the Driver Library Overview section for information on how the driver operates in a system.
The library interface routines are divided into various sub-sections, which address one of the blocks or the overall operation of the CPLD XC2C64A
Driver.
Library Interface Section Description
Functions Provides CPLD XC2C64A initialization and configuration functions.
Configuring the Library
The configuration of the CPLD XC2C64A Driver is based on the file system_config.h.
This header file contains the configuration selection for the CPLD XC2C64A Driver. Based on the selections made, the CPLD XC2C64A may
support the selected features. These configuration settings will apply to all instances of the CPLD XC2C64A Driver.
This header can be placed anywhere, the path of this header needs to be present in the include search path for a successful build. Refer to the
Applications Help section for more details.
Building the Library
This section lists the files that are available in the CPLD XC2C64A Driver Library.
Description
This section list the files that are available in the /src folder of the CPLD XC2C64A Driver. It lists which files need to be included in the build
based on either a hardware feature present on the board or configuration option selected by the system.
The following three tables list and describe the header (.h) and source (.c) files that implement this library. The parent folder for these files is
/framework/driver/cpld/xc2c64a.
Interface File(s)
This table lists and describes the header files that must be included (i.e., using #include) by any code that uses this library.
Source File Name Description
/drv_xc2c64a.h Header file that exports the CPLD XC2C64A Driver API.
Required File(s)
All of the required files listed in the following table are automatically added into the MPLAB X IDE project by the MHC
when the library is selected for use.
This table lists and describes the source and header files that must always be included in the MPLAB X IDE project to build this library.
Source File Name Description
/src/dynamic/drv_xc2c64a.c Basic CPLD XC2C64A Driver implementation file.
Optional File(s)
This table lists and describes the source and header files that may optionally be included if required for the desired implementation.
Source File Name Description
N/A No optional files are available for this library
Module Dependencies
The CPLD XC2C64A Driver Library is not dependent on other modules.
Library Interface
a) Functions
Name Description
CPLDGetDeviceConfiguration Returns the selected device.
Implementation: Static
Volume V: MPLAB Harmony Framework Driver Libraries Help CPLD XC2C64A Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 351
CPLDGetGraphicsConfiguration Returns the selected PMP bus, 8 or 16-bit, interface to the graphics controller.
Implementation: Static
CPLDGetSPIConfiguration Returns the selected SPI Channel.
Implementation: Static
CPLDInitialize Initializes the control I/O to the CPLD and places the CPLD in a known state.
Implementation: Static
CPLDSetGraphicsConfiguration Selects the PMP bus, 8 or 16-bit, interface to the graphic controller.
Implementation: Static
CPLDSetSPIFlashConfiguration Selects the SPI Flash device.
Implementation: Static
CPLDSetWiFiConfiguration Selects the Wi-Fi device.
Implementation: Static
CPLDSetZigBeeConfiguration Selects the ZigBee/MiWi device.
Implementation: Static
b) Data Types and Constants
Name Description
CPLD_DEVICE_CONFIGURATION CPLD device configuration.
CPLD_GFX_CONFIGURATION CPLD graphics controller PMP bus configuration.
CPLD_SPI_CONFIGURATION CPLD SPI channel selection.
Description
This section describes the API functions of the CPLD XC2C64A Driver Library.
Refer to each section for a detailed description.
a) Functions
CPLDGetDeviceConfiguration Function
Returns the selected device.
Implementation: Static
File
drv_xc2c64a.h
C
CPLD_DEVICE_CONFIGURATION CPLDGetDeviceConfiguration();
Returns
• CPLD_DEVICE_SPI_FLASH - SPI Flash.
• CPLD_DEVICE_WiFi - Zero G 802.11 Wi-Fi.
• CPLD_DEVICE_ZIGBEE - ZigBee/MiWi.
Description
This routine returns the selected CPLD device.
Remarks
None.
Preconditions
The initialization routine, CPLDInitialize, must be called.
Example
// Initialize the CPLD
CPLDInitialize();
if(CPLDGetDeviceConfiguration() != CPLD_DEVICE_SPI_FLASH)
{
// error - not setup as default
Volume V: MPLAB Harmony Framework Driver Libraries Help CPLD XC2C64A Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 352
}
Function
CPLD_DEVICE_CONFIGURATION CPLDGetDeviceConfiguration(void)
CPLDGetGraphicsConfiguration Function
Returns the selected PMP bus, 8 or 16-bit, interface to the graphics controller.
Implementation: Static
File
drv_xc2c64a.h
C
CPLD_GFX_CONFIGURATION CPLDGetGraphicsConfiguration();
Returns
• CPLD_GFX_CONFIG_8BIT - Graphics controller is configured for 8-bit PMP data bus interface.
• CPLD_GFX_CONFIG_16BIT - Graphics controller is configured for 16-bit PMP data bus interface.
Description
This routine gets the configuration of the PMP, 8 or 16-bit, data bus interface.
Remarks
None.
Preconditions
The initialization routine, CPLDInitialize, must be called.
Example
// Initialize the CPLD
CPLDInitialize();
if(CPLDGetGraphicsConfiguration() != CPLD_GFX_CONFIG_8BIT)
{
// error - not setup as default
}
Function
CPLD_GFX_CONFIGURATION CPLDGetGraphicsConfiguration(void)
CPLDGetSPIConfiguration Function
Returns the selected SPI Channel.
Implementation: Static
File
drv_xc2c64a.h
C
CPLD_SPI_CONFIGURATION CPLDGetSPIConfiguration();
Returns
• CPLD_SPI2A - SPI Channel 2A with chip select PORT G bit 9 and external interrupt 1 or 3
• CPLD_SPI3A - SPI Channel 3A with chip select PORT F bit 12 and change notice 9
• CPLD_SPI2 - SPI Channel 2 with chip select PORT G bit 9 and external interrupt 1 or 3
Description
This routine returns the selected SPI channel.
Volume V: MPLAB Harmony Framework Driver Libraries Help CPLD XC2C64A Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 353
Remarks
SPI channels 2 and 2A are located on the same pins. SPI channels 2A and 3A are only available on PIC32MX5xx/6xx/7xx series parts.
Preconditions
The initialization routine, CPLDInitialize, must be called.
Example
// Initialize the CPLD
CPLDInitialize();
if(CPLDGetSPIConfiguration() != CPLD_SPI2A)
{
// error - not setup as default
}
Function
CPLD_SPI_CONFIGURATION CPLDGetSPIConfiguration(void)
CPLDInitialize Function
Initializes the control I/O to the CPLD and places the CPLD in a known state.
Implementation: Static
File
drv_xc2c64a.h
C
void CPLDInitialize();
Returns
None.
Description
This routine configures the control I/O and places the CPLD in a known state.
• Graphics Controller Bus - 8-bit PMP data interface.
• SPI Channel - SPI2/SPI2A.
• Chip Select - PORT G bit 9.
• External Interrupt 1 or 3
• Device - SPI Flash.
Remarks
None.
Preconditions
None.
Example
// Initialize the CPLD
CPLDInitialize();
// CPLD is configured in the default state
Function
void CPLDInitialize(void)
CPLDSetGraphicsConfiguration Function
Selects the PMP bus, 8 or 16-bit, interface to the graphic controller.
Volume V: MPLAB Harmony Framework Driver Libraries Help CPLD XC2C64A Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 354
Implementation: Static
File
drv_xc2c64a.h
C
void CPLDSetGraphicsConfiguration(CPLD_GFX_CONFIGURATION configuration);
Returns
None.
Description
This routine sets the configuration pins on the graphics controller to select between an 8 or 16-bit data bus interface.
Remarks
The graphics controller interface configuration must be done before initializing the graphics controller.
Preconditions
The initialization routine, CPLDInitialize, must be called.
Example
Setting the graphics controller to a 16-bit interface
// Initialize the CPLD
CPLDInitialize();
// configure the graphics controller for a 16-bit PMP interface.
CPLDSetGraphicsConfiguration(CPLD_GFX_CONFIG_16BIT);
Setting the graphics controller to a 8-bit interface
// Initialize the CPLD
CPLDInitialize();
// configure the graphics controller for a 8-bit PMP interface.
CPLDSetGraphicsConfiguration(CPLD_GFX_CONFIG_8BIT);
Parameters
Parameters Description
configuration the type of interface configuration.
Function
void CPLDSetGraphicsConfiguration( CPLD_GFX_CONFIGURATION configuration)
CPLDSetSPIFlashConfiguration Function
Selects the SPI Flash device.
Implementation: Static
File
drv_xc2c64a.h
C
void CPLDSetSPIFlashConfiguration(CPLD_SPI_CONFIGURATION configuration);
Returns
None.
Description
This routine configures the CPLD to communicate to the SPI Flash device with the selected SPI channel and Chip Select.
Remarks
SPI channels 2 and 2A are located on the same pins. SPI channels 2A and 3A are only available on PIC32MX5xx/6xx/7xx series parts.
Volume V: MPLAB Harmony Framework Driver Libraries Help CPLD XC2C64A Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 355
Preconditions
The initialization routine, CPLDInitialize, must be called.
Example
Setting CPLD to SPI Flash using SPI channel 2 and chip select PORT G bit 9
// Initialize the CPLD
CPLDInitialize();
// configure the SPI Flash to use SPI channel 2 and chip select PORT G bit 9
CPLDSetSPIFlashConfiguration(CPLD_SPI2);
Setting CPLD to SPI Flash using SPI channel 2A and chip select PORT G bit 9
// Initialize the CPLD
CPLDInitialize();
// configure the SPI Flash to use SPI channel 2A and chip select PORT G bit 9
CPLDSetSPIFlashConfiguration(CPLD_SPI2A);
Setting CPLD to SPI Flash using SPI channel 3A and chip select PORT F bit 12
// Initialize the CPLD
CPLDInitialize();
// configure the SPI Flash to use SPI channel 3A and chip select PORT F bit 12
CPLDSetSPIFlashConfiguration(CPLD_SPI3A);
Parameters
Parameters Description
configuration the type of SPI channel used by the SPI Flash device.
Function
void CPLDSetSPIFlashConfiguration( CPLD_SPI_CONFIGURATION configuration)
CPLDSetWiFiConfiguration Function
Selects the Wi-Fi device.
Implementation: Static
File
drv_xc2c64a.h
C
void CPLDSetWiFiConfiguration(CPLD_SPI_CONFIGURATION configuration);
Returns
None.
Description
This routine configures the CPLD to communicate to the Wi-Fi device with the selected SPI channel, chip select and external interrupt or change
notice.
Remarks
SPI channels 2 and 2A are located on the same pins. SPI channels 2A and 3A are only available on PIC32MX5xx/6xx/7xx series parts.
Preconditions
The initialization routine, CPLDInitialize, must be called.
Example
Setting CPLD to Wi-Fi using SPI channel 2, chip select PORT G bit 9 and external interrupt 3
// Initialize the CPLD
CPLDInitialize();
// configure the Wi-Fi to use SPI channel 2, chip select PORT G bit 9 and external interrupt 3
CPLDSetWiFiConfiguration(CPLD_SPI2);
Volume V: MPLAB Harmony Framework Driver Libraries Help CPLD XC2C64A Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 356
Setting CPLD to Wi-Fi using SPI channel 2A, chip select PORT G bit 9 and external interrupt 3
// Initialize the CPLD
CPLDInitialize();
// configure the Wi-Fi to use SPI channel 2A, chip select PORT G bit 9 and external interrupt 3
CPLDSetWiFiConfiguration(CPLD_SPI2A);
Setting CPLD to Wi-Fi using SPI channel 3A, chip select PORT F bit 12 and change notice 9
// Initialize the CPLD
CPLDInitialize();
// configure the Wi-Fi to use SPI channel 3A, chip select PORT F bit 12 and change notice 9
CPLDSetWiFiConfiguration(CPLD_SPI3A);
Parameters
Parameters Description
configuration the type of SPI channel used by the Wi-Fi device.
Function
void CPLDSetWiFiConfiguration( CPLD_SPI_CONFIGURATION configuration)
CPLDSetZigBeeConfiguration Function
Selects the ZigBee/MiWi device.
Implementation: Static
File
drv_xc2c64a.h
C
void CPLDSetZigBeeConfiguration(CPLD_SPI_CONFIGURATION configuration);
Returns
None.
Description
This routine configures the CPLD to communicate to the ZigBee/MiWi device with the selected SPI channel, chip select and external interrupt or
change notice.
Remarks
SPI channels 2 and 2A are located on the same pins. SPI channels 2A and 3A are only available on PIC32MX5xx/6xx/7xx series parts.
Preconditions
The initialization routine, CPLDInitialize, must be called.
Example
Setting CPLD to ZigBee/MiWi using SPI channel 2, chip select PORT G bit 9 and external interrupt 3
// Initialize the CPLD
CPLDInitialize();
// configure the ZigBee/MiWi to use SPI channel 2, chip select PORT G bit 9 and external interrupt 3
CPLDSetZigBeeConfiguration(CPLD_SPI2);
Setting CPLD to ZigBee/MiWi using SPI channel 2A, chip select PORT G bit 9 and external interrupt 3
// Initialize the CPLD
CPLDInitialize();
// configure the ZigBee/MiWi to use SPI channel 2A, chip select PORT G bit 9 and external interrupt 3
CPLDSetZigBeeConfiguration(CPLD_SPI2A);
Setting CPLD to ZigBee/MiWi using SPI channel 3A, chip select PORT F bit 12 and change notice 9
// Initialize the CPLD
CPLDInitialize();
// configure the ZigBee/MiWi to use SPI channel 3A, chip select PORT F bit 12 and change notice 9
CPLDSetZigBeeConfiguration(CPLD_SPI3A);
Volume V: MPLAB Harmony Framework Driver Libraries Help CPLD XC2C64A Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 357
Parameters
Parameters Description
configuration the type of SPI channel used by the ZigBee/MiWi device.
Function
void CPLDSetZigBeeConfiguration( CPLD_SPI_CONFIGURATION configuration)
b) Data Types and Constants
CPLD_DEVICE_CONFIGURATION Enumeration
CPLD device configuration.
File
drv_xc2c64a.h
C
typedef enum {
CPLD_DEVICE_SPI_FLASH,
CPLD_DEVICE_WiFi,
CPLD_DEVICE_ZIGBEE
} CPLD_DEVICE_CONFIGURATION;
Members
Members Description
CPLD_DEVICE_SPI_FLASH SPI Flash
CPLD_DEVICE_WiFi Zero G Wi-Fi
CPLD_DEVICE_ZIGBEE ZigBee/MiWi
Description
The CPLD can be configured to communicate to three different devices. The application may call routine, CPLDGetDeviceConfiguration, to obtain
what device the CPLD is configured to communicate with.
Remarks
None.
Example
// select 16-bit PMP data bus
if(CPLDGetDeviceConfiguration() != CPLD_DEVICE_SPI_FLASH)
{
// error - not default configuration
}
CPLD_GFX_CONFIGURATION Enumeration
CPLD graphics controller PMP bus configuration.
File
drv_xc2c64a.h
C
typedef enum {
CPLD_GFX_CONFIG_8BIT,
CPLD_GFX_CONFIG_16BIT
} CPLD_GFX_CONFIGURATION;
Members
Members Description
CPLD_GFX_CONFIG_8BIT Configure the Graphics Controller to use 8-bit PMP data bus
Volume V: MPLAB Harmony Framework Driver Libraries Help CPLD XC2C64A Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 358
CPLD_GFX_CONFIG_16BIT Configure the Graphics Controller to use 16-bit PMP data bus
Description
The application can select what PMP bus configuration, 8 or 16-bit data bus, when interfacing with the graphics controller.
Remarks
None.
Example
// select 16-bit PMP data bus
CPLDSetGraphicsConfiguration(CPLD_GFX_CONFIG_16BIT);
CPLD_SPI_CONFIGURATION Enumeration
CPLD SPI channel selection.
File
drv_xc2c64a.h
C
typedef enum {
CPLD_SPI2A,
CPLD_SPI3A,
CPLD_SPI2
} CPLD_SPI_CONFIGURATION;
Members
Members Description
CPLD_SPI2A PIC32 SPI Channel 2A and chip select PORT G bit 9
CPLD_SPI3A PIC32 SPI Channel 3A and chip select PORT F bit 12
CPLD_SPI2 PIC32 SPI Channel 2 and chip select PORT G bit 9
Description
The application can select what SPI channel will be used as the communication interface. It will also select the Chip Select use for the device.
Remarks
Only one SPI channel can be select for a device. SPI channels 2 and 2A are located on the same pins. SPI channels 2A and 3A are only available
on PIC32MX5xx/6xx/7xx series devices.
Example
// select SPI channel two for SPI Flash
CPLDSetSPIFlashConfiguration(CPLD_SPI2);
Files
Files
Name Description
drv_xc2c64a.h This file contains the interface definition for the CUPLD controller.
Description
This section lists the source and header files used by the SPI Flash Driver Library.
drv_xc2c64a.h
This file contains the interface definition for the CUPLD controller.
Enumerations
Name Description
CPLD_DEVICE_CONFIGURATION CPLD device configuration.
CPLD_GFX_CONFIGURATION CPLD graphics controller PMP bus configuration.
Volume V: MPLAB Harmony Framework Driver Libraries Help CPLD XC2C64A Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 359
CPLD_SPI_CONFIGURATION CPLD SPI channel selection.
Functions
Name Description
CPLDGetDeviceConfiguration Returns the selected device.
Implementation: Static
CPLDGetGraphicsConfiguration Returns the selected PMP bus, 8 or 16-bit, interface to the graphics controller.
Implementation: Static
CPLDGetSPIConfiguration Returns the selected SPI Channel.
Implementation: Static
CPLDInitialize Initializes the control I/O to the CPLD and places the CPLD in a known state.
Implementation: Static
CPLDSetGraphicsConfiguration Selects the PMP bus, 8 or 16-bit, interface to the graphic controller.
Implementation: Static
CPLDSetSPIFlashConfiguration Selects the SPI Flash device.
Implementation: Static
CPLDSetWiFiConfiguration Selects the Wi-Fi device.
Implementation: Static
CPLDSetZigBeeConfiguration Selects the ZigBee/MiWi device.
Implementation: Static
Description
CUPLD Controller Interface File.
This library provides a low-level abstraction of the CUPLD device. It can be used to simplify low-level access to the device without the necessity of
interacting directly with the communication module's registers, thus hiding differences from one serial device variant to another.
File Name
drv_xc2c64a.h
Company
Microchip Technology Inc.
CTR Driver Library
This section describes the Cycle Time Register (CTR) Driver Library.
Introduction
This library provides a low-level abstraction of the Cycle Time Register (CTR) module on Microchip microcontrollers with a convenient C language
interface. It can be used to simplify low-level access to the module without the necessity of interacting directly with the module's registers, thus
hiding differences from one microcontroller variant to another.
Description
The CTR is a hardware block that can be used to track specific signals from subsystems to internally log corresponding system time. Subsystems
can include network clock synchronization, Media Clock synchronization, USB start of frame (SoF), and so on.
Using the Library
This section describes the basic architecture of the CTR Driver Library and provides information and examples on its use.
Description
Interface Header File: drv_ctr.h
The interface to the CTR Module Library is defined in the drv_ctr.h header file. Any C language source (.c) file that uses the CTR Driver
Library should include this header.
Refer to the What is MPLAB Harmony? section for how the driver interacts with the framework.
Abstraction Model
This library provides a low-level abstraction of the CTR Driver Library on the Microchip family microcontrollers with a convenient C language
interface. This topic describes how that abstraction is modeled in software and introduces the library's interface.
Volume V: MPLAB Harmony Framework Driver Libraries Help CTR Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 360
Description
The CTR driver provides an interface to perform a one-time configuration of the CTR peripheral. Initialization steps include selecting the mode of
operation, interrupt and trigger sources, latch configurations, and so on.
In addition, the driver allows the client to register a callback that is executed when the desired event has been triggered.
Library Overview
Refer to the Driver Library Overview section for information on how the driver operates in a system.
The library interface routines are divided into various sub-sections, which address one of the blocks or the overall operation of the CTR module.
Library Interface Section Description
System Interaction Functions Provides system module interfaces, device initialization, deinitialization,
reinitialization, tasks and status functions.
Other Functions Provides driver miscellaneous functions, data transfer status function, version
identification functions, and so on.
Data Types and Constants Provides data types and macros.
How the Library Works
The library provides interfaces to support:
• System Functionality
• Client Functionality
Note:
Not all modes are available on all devices, please refer to the specific device data sheet to determine the modes that are
supported for your device.
Configuring the Library
The configuration of the driver is based on the file system_config.h.
Description
The header file contains the configuration selection for the driver. Based on the selections made, the driver may support the selected features.
These configuration settings will apply to all instances of the driver.
This header can be placed anywhere, the path of this header needs to be present in the include search path for a successful build. Refer to the
Applications Help section for more details.
Building the Library
This section lists the files that are available in the CTR Driver Library.
Description
This section list the files that are available in the /src folder of the CTR Driver Library. It lists which files need to be included in the build based on
either a hardware feature present on the board or configuration option selected by the system.
The following three tables list and describe the header (.h) and source (.c) files that implement this library. The parent folder for these files is
/framework/driver/ctr/.
Interface File(s)
This table lists and describes the header files that must be included (i.e., using #include) by any code that uses this library.
Source File Name Description
/drv_ctr.h Header file that exports the driver API.
Required File(s)
All of the required files listed in the following table are automatically added into the MPLAB X IDE project by the MHC
when the library is selected for use.
This table lists and describes the source and header files that must always be included in the MPLAB X IDE project to build this library.
Volume V: MPLAB Harmony Framework Driver Libraries Help CTR Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 361
Source File Name Description
/src/dynamic/drv_ctr.c Basic CTR Driver implementation file.
Optional File(s)
This table lists and describes the source and header files that may optionally be included if required for the desired implementation.
Source File Name Description
N/A No optional files are available for this library
Module Dependencies
The CTR Driver Library depends on the following modules:
• Clock System Service Library
Optional Dependencies
• DMA System Service Library (used when operating in DMA mode)
• Interrupt System Service Library (used when task is running in Interrupt mode)
Library Interface
This section describes the API functions of the CTR Driver Library.
Refer to each section for a detailed description.
a) System Interaction Functions
Functions
Name Description
DRV_CTR_Deinitialize Deinitializes the specified instance of the CTR driver module.
Implementation: Dynamic
DRV_CTR_Initialize Initializes the CTR Driver instance for the specified driver index.
Implementation: Dynamic
DRV_CTR_Status Gets the current status of the CTR Driver module.
Implementation: Dynamic
Description
DRV_CTR_Deinitialize Function
Deinitializes the specified instance of the CTR driver module.
Implementation: Dynamic
File
drv_ctr.h
C
void DRV_CTR_Deinitialize(SYS_MODULE_OBJ object);
Returns
None.
Description
Deinitializes the specified instance of the CTR Driver module, disabling its operation (and any hardware) and invalidates all of the internal data.
Remarks
Once the Initialize operation has been called, the Deinitialize operation must be called before the Initialize operation can be called again. This
function will NEVER block waiting for hardware.
Preconditions
Function DRV_CTR_Initialize should have been called before calling this function.
Volume V: MPLAB Harmony Framework Driver Libraries Help CTR Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 362
Example
// This code snippet shows an example of deinitializing the driver.
SYS_MODULE_OBJ object; // Returned from DRV_CTR_Initialize
SYS_STATUS status;
DRV_CTR_Deinitialize(object);
status = DRV_CTR_Status(object);
if (SYS_STATUS_UNINITIALIZED != status)
{
// Check again later if you need to know
// when the driver is deinitialized.
}
Parameters
Parameters Description
object Driver object handle, returned from the DRV_CTR_Initialize
Function
void DRV_CTR_Deinitialize( SYS_MODULE_OBJ object )
DRV_CTR_Initialize Function
Initializes the CTR Driver instance for the specified driver index.
Implementation: Dynamic
File
drv_ctr.h
C
SYS_MODULE_OBJ DRV_CTR_Initialize(const SYS_MODULE_INDEX index, const SYS_MODULE_INIT * const init);
Returns
If successful, returns a valid handle to a driver instance object. Otherwise, it returns SYS_MODULE_OBJ_INVALID.
Description
This function initializes the CTR driver instance for the specified driver index, making it ready for clients to open and use it.
Remarks
This function must be called before any other CTR function is called.
This function should only be called once during system initialization unless DRV_CTR_Deinitialize is called to deinitialize the driver instance.
Preconditions
None.
Example
// This code snippet shows an example of initializing the CTR Driver. All
the CTR initialization is done in #defines mentioned, and the init structure
is initialized with corresponding #defines and then passed to initialize
function.
// *****************************************************************************
// CTR Driver Configuration Options
#define DRV_CTR_POWER_STATE SYS_MODULE_POWER_RUN_FULL
#define DRV_CTR_MODULE_ID CTR_ID_0
#define DRV_CTR_CLIENTS_NUMBER 1
#define DRV_CTR_INSTANCES_NUMBER 1
#define DRV_CTR_EVENT_INTERRUPT_SOURCE INT_SOURCE_CTR1_EVENT
#define DRV_CTR_EVENT_INTERRUPT_MODE CTR_LATCH_TRIG
Volume V: MPLAB Harmony Framework Driver Libraries Help CTR Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 363
#define DRV_CTR_TRIGGER_INTERRUPT_SOURCE INT_SOURCE_CTR1_TRG
#define DRV_CTR_M_0 0x000000
#define DRV_CTR_N_0 0x000000
#define DRV_CTR_LSB_0 0x00
#define DRV_CTR_MODE_0 CTR_US
#define DRV_CTR_M_1 0x000000
#define DRV_CTR_N_1 0x000000
#define DRV_CTR_LSB_1 0x00
#define DRV_CTR_MODE_1 CTR_US
#define DRV_CTR_COUNTER_SEL CTR_CTR0_LIN
#define DRV_CTR_DIVIDER 0
#define DRIVER_MODE WIFI_MODE
#define DRV_CTR_LATCH0_TRIG CTR_WIFI_TM_1
#define DRV_CTR_LATCH1_TRIG CTR_WIFI_TM_2
#define DRV_CTR_LATCH2_TRIG CTR_WIFI_TM_3
#define DRV_CTR_LATCH3_TRIG CTR_WIFI_TM_4
#define DRV_CTR_TRIGGER_SOURCE CTR_CTR0_LIN
#define DRV_CTR_TRIGGER_PHASE 0x000
DRV_CTR_INIT CTRInitData;
SYS_MODULE_OBJ objectHandle;
CTRInitData.moduleInit = DRV_CTR_POWER_STATE,
CTRInitData.ctrEventInterruptSource = DRV_CTR_EVENT_INTERRUPT_SOURCE,
CTRInitData.ctrLatchEventMode = DRV_CTR_EVENT_INTERRUPT_MODE,
CTRInitData.ctrTriggerInterruptSource = DRV_CTR_TRIGGER_INTERRUPT_SOURCE,
CTRInitData.ctrCounter[0].M = DRV_CTR_M_0,
CTRInitData.ctrCounter[0].N = DRV_CTR_N_0,
CTRInitData.ctrCounter[0].LSB = DRV_CTR_LSB_0,
CTRInitData.ctrCounter[1].M = DRV_CTR_M_1,
CTRInitData.ctrCounter[1].N = DRV_CTR_N_1,
CTRInitData.ctrCounter[1].LSB = DRV_CTR_LSB_1,
CTRInitData.ctrLatch[0].ctrSel = DRV_CTR_COUNTER_SEL,
CTRInitData.ctrLatch[1].ctrSel = DRV_CTR_COUNTER_SEL,
CTRInitData.ctrLatch[2].ctrSel = DRV_CTR_COUNTER_SEL,
CTRInitData.ctrLatch[3].ctrSel = DRV_CTR_COUNTER_SEL,
CTRInitData.ctrLatch[0].trigSel = DRV_CTR_LATCH0_TRIG,
CTRInitData.ctrLatch[1].trigSel = DRV_CTR_LATCH1_TRIG,
CTRInitData.ctrLatch[2].trigSel = DRV_CTR_LATCH2_TRIG,
CTRInitData.ctrLatch[3].trigSel = DRV_CTR_LATCH3_TRIG,
CTRInitData.ctrLatch[0].divider = DRV_CTR_DIVIDER,
CTRInitData.ctrLatch[1].divider = DRV_CTR_DIVIDER,
CTRInitData.ctrLatch[2].divider = DRV_CTR_DIVIDER,
CTRInitData.ctrLatch[3].divider = DRV_CTR_DIVIDER,
CTRInitData.ctrTrigger.trigSource = DRV_CTR_TRIGGER_SOURCE,
CTRInitData.ctrTrigger.phase = DRV_CTR_TRIGGER_PHASE,
CTRInitData.drvMode = DRIVER_MODE
objectHandle = DRV_CTR_Initialize(DRV_CTR_INDEX_0,
(SYS_MODULE_INIT*)CTRInitData);
if (SYS_MODULE_OBJ_INVALID == objectHandle)
{
// Handle error
}
Parameters
Parameters Description
index Identifier for the instance to be initialized
init Pointer to a data structure containing data necessary to initialize the driver.
Function
SYS_MODULE_OBJ DRV_CTR_Initialize
(
const SYS_MODULE_INDEX index,
const SYS_MODULE_INIT * const init
);
Volume V: MPLAB Harmony Framework Driver Libraries Help CTR Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 364
DRV_CTR_Status Function
Gets the current status of the CTR Driver module.
Implementation: Dynamic
File
drv_ctr.h
C
SYS_STATUS DRV_CTR_Status(SYS_MODULE_OBJ object);
Returns
SYS_STATUS_READY - Indicates that the driver is ready and accept requests for new operations
SYS_STATUS_UNINITIALIZED - Indicates that the driver is not initialized
Description
This function provides the current status of the CTR Driver module.
Remarks
A driver can only be opened when its status is SYS_STATUS_READY.
Preconditions
Function DRV_CTR_Initialize should have been called before calling this function.
Example
SYS_MODULE_OBJ object; // Returned from DRV_CTR_Initialize
SYS_STATUS CTRStatus;
CTRStatus = DRV_CTR_Status(object);
if (SYS_STATUS_ERROR == CTRStatus)
{
// Handle error
}
Parameters
Parameters Description
object Driver object handle, returned from the DRV_CTR_Initialize
Function
SYS_STATUS DRV_CTR_Status( SYS_MODULE_OBJ object )
b) Other Functions
Functions
Name Description
DRV_CTR_Adjust Sets the adjust value for a given CTR counter.
Implementation: Dynamic
DRV_CTR_ClientStatus Gets current client-specific status of the CTR driver.
Implementation: Dynamic
DRV_CTR_Close Closes an opened-instance of the CTR driver.
Implementation: Dynamic
DRV_CTR_Drift Sets the drift value for a given CTR counter.
Implementation: Dynamic
DRV_CTR_EventISR Interrupt Service Routine called for the CTR event interrupt.
Implementation: Dynamic
DRV_CTR_Open Opens the specified CTR driver instance and returns a handle to it.
Implementation: Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help CTR Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 365
DRV_CTR_RegisterCallBack Registers a callback function for the event interrupt of CTR.
Implementation: Dynamic
DRV_CTR_TriggerISR Interrupt Service Routine called for the CTR Trigger interrupt.
Implementation: Dynamic
Description
DRV_CTR_Adjust Function
Sets the adjust value for a given CTR counter.
Implementation: Dynamic
File
drv_ctr.h
C
void DRV_CTR_Adjust(DRV_HANDLE handle, CTR_LATCH_CTR_SELECT ctrSel, uint16_t adjustVal);
Returns
None.
Description
This function sets the adjust value for a given CTR counter.
Preconditions
The DRV_CTR_Initialize function must have been called.
DRV_CTR_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE handle; // handle returned by open function
uint16_t adjustVal = 0xFFF;
DRV_CTR_Adjust(handle, CTR_CTR0_LIN, adjustVal);
Parameters
Parameters Description
handle A valid open instance handle, returned from the driver's open
Function
void DRV_CTR_Adjust( DRV_HANDLE handle, CTR_LATCH_CTR_SELECT ctrSel,
uint16_t adjustVal);
ctrSel - CTR counter to be selected out of the 4 counters available.
adjustVal - Adjust value to be set
DRV_CTR_ClientStatus Function
Gets current client-specific status of the CTR driver.
Implementation: Dynamic
File
drv_ctr.h
C
DRV_CTR_CLIENT_STATUS DRV_CTR_ClientStatus(const DRV_HANDLE handle);
Returns
A DRV_CTR_CLIENT_STATUS value describing the current status of the driver.
Volume V: MPLAB Harmony Framework Driver Libraries Help CTR Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 366
Description
This function gets the client-specific status of the CTR driver associated with the given handle.
Remarks
This function will not block for hardware access and will immediately return the current status.
Preconditions
The DRV_CTR_Initialize function must have been called.
DRV_CTR_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE handle; // Returned from DRV_CTR_Open
DRV_CTR_CLIENT_STATUS clientStatus;
clientStatus = DRV_CTR_ClientStatus(handle);
if(DRV_CTR_CLIENT_STATUS_READY == clientStatus)
{
// do the tasks
}
Parameters
Parameters Description
handle A valid open instance handle, returned from the driver's open
Function
DRV_CTR_CLIENT_STATUS DRV_CTR_ClientStatus(DRV_HANDLE handle);
DRV_CTR_Close Function
Closes an opened-instance of the CTR driver.
Implementation: Dynamic
File
drv_ctr.h
C
void DRV_CTR_Close(const DRV_HANDLE handle);
Returns
None.
Description
This function closes an opened-instance of the CTR driver, invalidating the handle.
Remarks
After calling this function, the handle passed in "handle" must not be used with any of the remaining driver routines. A new handle must be
obtained by calling DRV_CTR_Open before the caller may use the driver again.
Usually, there is no need for the driver client to verify that the Close operation has completed.
Preconditions
The DRV_CTR_Initialize function must have been called for the specified CTR driver instance.
DRV_CTR_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE handle; // Returned from DRV_CTR_Open
DRV_CTR_Close(handle);
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
Volume V: MPLAB Harmony Framework Driver Libraries Help CTR Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 367
Function
void DRV_CTR_Close( DRV_Handle handle );
DRV_CTR_Drift Function
Sets the drift value for a given CTR counter.
Implementation: Dynamic
File
drv_ctr.h
C
void DRV_CTR_Drift(DRV_HANDLE handle, CTR_LATCH_CTR_SELECT ctrSel, uint32_t driftVal);
Returns
None.
Description
This function sets the drift value for a given CTR counter.
Preconditions
The DRV_CTR_Initialize function must have been called.
DRV_CTR_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE handle; // handle returned by open function
uint16_t driftVal = 0xFFF;
DRV_CTR_Drift(handle, CTR_CTR0_LIN, driftVal);
Parameters
Parameters Description
handle A valid open instance handle, returned from the driver's open
Function
void DRV_CTR_Drift( DRV_HANDLE handle, CTR_LATCH_CTR_SELECT ctrSel,
uint16_t driftVal);
ctrSel - CTR counter to be selected out of the 4 counters available.
adjustVal - Drift value to be set
DRV_CTR_EventISR Function
Interrupt Service Routine called for the CTR event interrupt.
Implementation: Dynamic
File
drv_ctr.h
C
void DRV_CTR_EventISR(SYS_MODULE_OBJ object);
Returns
None.
Description
This function is called when the interrupt is generated for CTR event interrupt. The latch buffers are read and stored in a local buffer, and all the
registered client callback functions will be called from this function. The number of latches to be read depends upon the use-case configured. For
wifi, 4 latches are read, and for USBSoF and GPIO, only 1 latch is read. Number of buffers to read in each latch depends on the interrupt mode
configuration. For Full, all 4 buffers needs to be read, whereas for half-full, only 2 buffers needs to be read and for every trigger, only 1 buffer is
Volume V: MPLAB Harmony Framework Driver Libraries Help CTR Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 368
read.
Remarks
All the handling specific for a client should be done in the respective callback functions. This function should not be modified.
Preconditions
None.
Example
This function is not called from clients/system. This function will be called when the interrupt for event is generated.
Parameters
Parameters Description
object The driver instance handle returned after the initialization.
Function
void DRV_CTR_EventISR(SYS_MODULE_OBJ object);
DRV_CTR_Open Function
Opens the specified CTR driver instance and returns a handle to it.
Implementation: Dynamic
File
drv_ctr.h
C
DRV_HANDLE DRV_CTR_Open(const SYS_MODULE_INDEX drvIndex, const DRV_IO_INTENT ioIntent);
Returns
If successful, the function returns a valid open-instance handle (a number identifying both the caller and the module instance).
If an error occurs, the return value is DRV_HANDLE_INVALID. Errors can occur under the following circumstances:
• if the number of client objects allocated via DRV_CTR_CLIENTS_NUMBER is insufficient
• if the client is trying to open the driver but driver has been opened exclusively by another client
• if the driver hardware instance being opened is not initialized or is invalid
• if the client is trying to open the driver exclusively, but has already been opened in a non exclusive mode by another client.
• if the driver status is not ready.
Description
This function opens the specified CTR driver instance and provides a handle that must be provided to all other client-level operations to identify the
caller and the instance of the driver.
Remarks
The driver will always work in Non-Blocking mode even if IO-intent is selected as blocking.
The handle returned is valid until the DRV_CTR_Close function is called.
This function will NEVER block waiting for hardware.
Preconditions
Function DRV_CTR_Initialize must have been called before calling this function.
Example
DRV_HANDLE handle;
handle = DRV_CTR_Open(DRV_CTR_INDEX_0, DRV_IO_INTENT_EXCLUSIVE);
if (DRV_HANDLE_INVALID == handle)
{
// Unable to open the driver
}
Volume V: MPLAB Harmony Framework Driver Libraries Help CTR Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 369
Parameters
Parameters Description
drvIndex Identifier for the object instance to be opened
ioIntent Zero or more of the values from the enumeration DRV_IO_INTENT "ORed" together to
indicate the intended use of the driver
Function
DRV_HANDLE DRV_CTR_Open
(
const SYS_MODULE_INDEX drvIndex,
const DRV_IO_INTENT ioIntent
);
DRV_CTR_RegisterCallBack Function
Registers a callback function for the event interrupt of CTR.
Implementation: Dynamic
File
drv_ctr.h
C
void DRV_CTR_RegisterCallBack(const DRV_HANDLE handle, const DRV_CTR_CALLBACK callback, const bool
oneTimeCallback, const uintptr_t context);
Returns
None.
Description
This function registers a client callback function for the event interrupt associated with the use-case. For Wifi usecase, Only Latch 3 interrupt will
be enabled, as the last event timestamp will be filled in latch 3 for IEEE 802.11v. For USBSoF and GPIO use-cases, only one latch is needed and
the interrupt will be enabled for the same latch. As per user's configuration of interrupt mode for full, half-full or every trigger, the interrupt will be
generated and the client callback functions will be called from the ISR. The flag oneTimeCallback is passed as an argument for this function. If the
value of this flag is TRUE, then the callback will be called only once. If client needs one more callback, he needs to register the callback once
more. If this value is false, then whenever interrupt is generated, the callback function will be called until the client call the close function.
Remarks
The registered callback function will be called from ISR. So, it is recommended to keep the callback functions light and not process intensive.
Preconditions
The DRV_CTR_Initialize function must have been called.
DRV_CTR_Open must have been called to obtain a valid opened device handle.
Example
#define CLIENT_ID 0x01
DRV_HANDLE handle; // Returned from DRV_CTR_Open
void ClientCallack( uintptr_t context, uint32_t * timestampbuffer,
uint8_t BufferSize);
DRV_CTR_RegisterCallBack(handle, ClientCallack, FALSE, CLIENT_ID);
Parameters
Parameters Description
handle A valid open instance handle, returned from the driver's open
Function
void DRV_CTR_RegisterCallBack(
const DRV_HANDLE handle,
const DRV_CTR_CALLBACK callback,
const bool oneTimeCallback,
Volume V: MPLAB Harmony Framework Driver Libraries Help CTR Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 370
const uintptr_t context
);
callback - A function pointer for client callback function
oneTimeCallback - If client needs callback to be called only once, then
this flag must be true.
context - The value of parameter will be passed back to the client
unchanged, when the callback function is called. It can
be used to identify any client specific data object that
identifies the instance of the client module (for example,
it may be a pointer to the client module's state structure).
DRV_CTR_TriggerISR Function
Interrupt Service Routine called for the CTR Trigger interrupt.
Implementation: Dynamic
File
drv_ctr.h
C
void DRV_CTR_TriggerISR(SYS_MODULE_OBJ object);
Returns
None.
Description
This function is called when the interrupt is generated for CTR trigger interrupt. The interrupt handling for this interrupt is application specific. So,
this function is kept open for the clients to modify.
Remarks
Specific interrupt handling can be taken care of by application developer, as the need for this interrupt is application specific.
Preconditions
None.
Example
This function is not called from clients/system. This function will be called when the interrupt for event is generated.
Parameters
Parameters Description
object The driver instance handle returned after the initialization.
Function
void DRV_CTR_TriggerISR(SYS_MODULE_OBJ object);
c) Data Types and Constants
Enumerations
Name Description
DRV_CTR_CLIENT_STATUS Defines the client status.
Implementation: Dynamic
DRV_MODE Defines the driver mode.
Implementation: Dynamic
Macros
Name Description
DRV_CTR_COUNTER_NUM Number of counters in CTR module
Volume V: MPLAB Harmony Framework Driver Libraries Help CTR Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 371
DRV_CTR_INDEX_0 CTR driver index definitions
DRV_CTR_LATCH_FIFO_CNT FIFO size for each latch in CTR module
DRV_CTR_LATCH_NUM Number of latches in CTR module
Structures
Name Description
DRV_CTR_COUNTER Contains all the data necessary to initialize the CTR counter.
Implementation: Dynamic
DRV_CTR_INIT Contains all the data necessary to initialize the CTR.
Implementation: Dynamic
DRV_CTR_LATCH Contains all the data necessary to initialize the CTR Latches.
Implementation: Dynamic
DRV_CTR_TRIGGER Contains all the data necessary to initialize the CTR Triggers.
Implementation: Dynamic
Types
Name Description
DRV_CTR_CALLBACK Callback function definition for CTR event interrupt.
Implementation: Dynamic
Description
DRV_CTR_CALLBACK Type
Callback function definition for CTR event interrupt.
Implementation: Dynamic
File
drv_ctr.h
C
typedef void (* DRV_CTR_CALLBACK)(uintptr_t context, uint32_t * timestampbuffer, uint8_t BufferSize);
Description
CTR Event interrupt callback function
The clients must define their callback functions in the same prototype as DRV_CTR_CALLBACK. All the registered callbacks will be called from
drive ISR for CTR event.
Remarks
This structure is a part of initialization structure, which is used to initialize the CTR module.
DRV_CTR_CLIENT_STATUS Enumeration
Defines the client status.
Implementation: Dynamic
File
drv_ctr.h
C
typedef enum {
DRV_CTR_CLIENT_STATUS_READY = DRV_CLIENT_STATUS_READY+0,
DRV_CTR_CLIENT_STATUS_BUSY = DRV_CLIENT_STATUS_BUSY,
DRV_CTR_CLIENT_STATUS_CLOSED = DRV_CLIENT_STATUS_CLOSED,
DRV_CTR_CLIENT_STATUS_ERROR = DRV_CLIENT_STATUS_ERROR
} DRV_CTR_CLIENT_STATUS;
Volume V: MPLAB Harmony Framework Driver Libraries Help CTR Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 372
Members
Members Description
DRV_CTR_CLIENT_STATUS_READY =
DRV_CLIENT_STATUS_READY+0
Up and running, ready to start new operations
DRV_CTR_CLIENT_STATUS_BUSY =
DRV_CLIENT_STATUS_BUSY
Operation in progress, unable to start a new one
DRV_CTR_CLIENT_STATUS_CLOSED =
DRV_CLIENT_STATUS_CLOSED
Client is closed
DRV_CTR_CLIENT_STATUS_ERROR =
DRV_CLIENT_STATUS_ERROR
Client Error
Description
CTR Client Status
Defines the various client status codes.
Remarks
None.
DRV_CTR_COUNTER Structure
Contains all the data necessary to initialize the CTR counter.
Implementation: Dynamic
File
drv_ctr.h
C
typedef struct {
uint32_t M;
uint32_t N;
uint8_t LSB;
CTR_MODE_SELECT Mode;
} DRV_CTR_COUNTER;
Description
CTR Counter init structure
This structure contains all of the data necessary to initialize the CTR counter increment steps and the resolution.
Remarks
This structure is a part of initialization structure, which is used to initialize the CTR module.
DRV_CTR_INIT Structure
Contains all the data necessary to initialize the CTR.
Implementation: Dynamic
File
drv_ctr.h
C
typedef struct {
SYS_MODULE_INIT moduleInit;
CTR_MODULE_ID ctrId;
INT_SOURCE ctrEventInterruptSource;
CTR_LATCH_INT_MODE ctrLatchEventMode;
INT_SOURCE ctrTriggerInterruptSource;
DRV_CTR_COUNTER ctrCounter[DRV_CTR_COUNTER_NUM];
DRV_CTR_LATCH ctrLatch[DRV_CTR_LATCH_NUM];
DRV_CTR_TRIGGER ctrTrigger;
DRV_MODE drvMode;
} DRV_CTR_INIT;
Volume V: MPLAB Harmony Framework Driver Libraries Help CTR Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 373
Members
Members Description
SYS_MODULE_INIT moduleInit; System module initialization
CTR_MODULE_ID ctrId; Identifies the CTR peripheral instance
INT_SOURCE ctrEventInterruptSource; CTR Event Interrupt Source
CTR_LATCH_INT_MODE ctrLatchEventMode; CTR Event Interrupt Mode
INT_SOURCE ctrTriggerInterruptSource; CTR Triggetr Interrupt Source
DRV_CTR_COUNTER
ctrCounter[DRV_CTR_COUNTER_NUM];
Counter Init Data
DRV_CTR_LATCH
ctrLatch[DRV_CTR_LATCH_NUM];
Latch Init Data
DRV_MODE drvMode; Driver Mode
Description
CTR Driver Initialization Data
This structure contains all of the data necessary to initialize the CTR.
Remarks
A pointer to a structure of this format containing the desired initialization data must be passed into the DRV_CTR_Initialize function.
DRV_CTR_LATCH Structure
Contains all the data necessary to initialize the CTR Latches.
Implementation: Dynamic
File
drv_ctr.h
C
typedef struct {
CTR_LATCH_TRIGGER_SELECT trigSel;
CTR_LATCH_CTR_SELECT ctrSel;
uint8_t divider;
} DRV_CTR_LATCH;
Description
CTR Latch init structure
This structure contains all of the data necessary to initialize the CTR Latches for mapping the trigger source and counter for a given latch.
Remarks
This structure is a part of initialization structure, which is used to initialize the CTR module.
DRV_CTR_TRIGGER Structure
Contains all the data necessary to initialize the CTR Triggers.
Implementation: Dynamic
File
drv_ctr.h
C
typedef struct {
CTR_LATCH_CTR_SELECT trigSource;
uint16_t phase;
} DRV_CTR_TRIGGER;
Description
CTR Trigger init structure
This structure contains all of the data necessary to initialize the CTR Triggers for generating triggers from CTR.
Volume V: MPLAB Harmony Framework Driver Libraries Help CTR Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 374
Remarks
This structure is a part of initialization structure, which is used to initialize the CTR module.
DRV_MODE Enumeration
Defines the driver mode.
Implementation: Dynamic
File
drv_ctr.h
C
typedef enum {
WIFI_MODE = 0,
USB_MODE,
GPIO_MODE
} DRV_MODE;
Description
CTR Driver mode
Driver can be configured to use for either of Wifi, USB or GPIO.
Remarks
None.
DRV_CTR_COUNTER_NUM Macro
Number of counters in CTR module
File
drv_ctr.h
C
#define DRV_CTR_COUNTER_NUM 2
Description
Counters present in the CTR module
These constants provide Number of counters in CTR module.
Remarks
These constants should be used in place of hard-coded numeric literals.
DRV_CTR_INDEX_0 Macro
CTR driver index definitions
File
drv_ctr.h
C
#define DRV_CTR_INDEX_0 0
Description
Driver CTR Module Index reference
These constants provide CTR driver index definitions.
Remarks
These constants should be used in place of hard-coded numeric literals.
These values should be passed into the DRV_CTR_Initialize and DRV_CTR_Open routines to identify the driver instance in use.
Volume V: MPLAB Harmony Framework Driver Libraries Help CTR Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 375
DRV_CTR_LATCH_FIFO_CNT Macro
FIFO size for each latch in CTR module
File
drv_ctr.h
C
#define DRV_CTR_LATCH_FIFO_CNT 4
Description
FIFO size for each latch in the CTR module
These constants provide Number of FIFO location available in each latch in CTR module.
Remarks
These constants should be used in place of hard-coded numeric literals.
DRV_CTR_LATCH_NUM Macro
Number of latches in CTR module
File
drv_ctr.h
C
#define DRV_CTR_LATCH_NUM 6
Description
Latches present in the CTR module
These constants provide Number of latches in CTR module.
Remarks
These constants should be used in place of hard-coded numeric literals.
Files
Files
Name Description
drv_ctr.h CTR Driver Interface Definition
Description
This section lists the source and header files used by the CTR Driver Library.
drv_ctr.h
CTR Driver Interface Definition
Enumerations
Name Description
DRV_CTR_CLIENT_STATUS Defines the client status.
Implementation: Dynamic
DRV_MODE Defines the driver mode.
Implementation: Dynamic
Functions
Name Description
DRV_CTR_Adjust Sets the adjust value for a given CTR counter.
Implementation: Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help CTR Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 376
DRV_CTR_ClientStatus Gets current client-specific status of the CTR driver.
Implementation: Dynamic
DRV_CTR_Close Closes an opened-instance of the CTR driver.
Implementation: Dynamic
DRV_CTR_Deinitialize Deinitializes the specified instance of the CTR driver module.
Implementation: Dynamic
DRV_CTR_Drift Sets the drift value for a given CTR counter.
Implementation: Dynamic
DRV_CTR_EventISR Interrupt Service Routine called for the CTR event interrupt.
Implementation: Dynamic
DRV_CTR_Initialize Initializes the CTR Driver instance for the specified driver index.
Implementation: Dynamic
DRV_CTR_Open Opens the specified CTR driver instance and returns a handle to it.
Implementation: Dynamic
DRV_CTR_RegisterCallBack Registers a callback function for the event interrupt of CTR.
Implementation: Dynamic
DRV_CTR_Status Gets the current status of the CTR Driver module.
Implementation: Dynamic
DRV_CTR_TriggerISR Interrupt Service Routine called for the CTR Trigger interrupt.
Implementation: Dynamic
Macros
Name Description
DRV_CTR_COUNTER_NUM Number of counters in CTR module
DRV_CTR_INDEX_0 CTR driver index definitions
DRV_CTR_LATCH_FIFO_CNT FIFO size for each latch in CTR module
DRV_CTR_LATCH_NUM Number of latches in CTR module
Structures
Name Description
DRV_CTR_COUNTER Contains all the data necessary to initialize the CTR counter.
Implementation: Dynamic
DRV_CTR_INIT Contains all the data necessary to initialize the CTR.
Implementation: Dynamic
DRV_CTR_LATCH Contains all the data necessary to initialize the CTR Latches.
Implementation: Dynamic
DRV_CTR_TRIGGER Contains all the data necessary to initialize the CTR Triggers.
Implementation: Dynamic
Types
Name Description
DRV_CTR_CALLBACK Callback function definition for CTR event interrupt.
Implementation: Dynamic
Description
CTR Driver Interface Definition
The CTR device driver provides a simple interface to manage the CTR Module This file defines the interface definition for the CTR Driver.
File Name
drv_CTR.h
Company
Microchip Technology Inc.
Data EEPROM Driver Library
This section describes the Data EEPROM Driver Library.
Volume V: MPLAB Harmony Framework Driver Libraries Help Data EEPROM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 377
Introduction
The MPLAB Harmony Data EEPROM Driver provides a high-level interface to manage the Data EEPROM module on the Microchip family of
microcontrollers.
Description
The Data EEPROM Driver provides the following features:
• Application-ready routines to perform block operations on the Data EEPROM
• Multi-client operation support
• Data transfer events
• Supports Non-blocking mode of operation only
The Data EEPROM Driver supports multi-client operation, which allows multiple application clients to access the same memory device. Multiple
instances of the driver can be used when multiple EEPROM devices are required to be part of the system.
Using the Library
This topic describes the basic architecture of the Data EEPROM Driver Library and provides information and examples on its use.
Description
Interface Header File: drv_eeprom.h
The interface to the EEPROM Driver Library is defined in the drv_eeprom.h header file. Any C language source (.c) file that uses the Data
EPROM Driver Library should include drv_eeprom.h.
Please refer to the What is MPLAB Harmony? section for how the driver interacts with the framework.
Abstraction Model
This library provides a low-level abstraction of the Data EEPROM Driver Library on the Microchip family of microcontrollers with a convenient C
language interface. This topic describes how that abstraction is modeled in software and introduces the library's interface.
Description
The Data EEPROM driver provides a set of APIs that can be used to perform Erase, Write, and Read operations. The following diagram depicts
the communication between different modules. As shown in the diagram, the Data EEPROM Driver sits between the Peripheral Libraries and the
application or system layer to facilitate block and file access to the EEPROM.
Data EEPROM Driver Abstraction Model
Volume V: MPLAB Harmony Framework Driver Libraries Help Data EEPROM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 378
Library Overview
Refer to the Driver Library Overview section for information on how the driver operates in a system.
The library interface routines are divided into various sub-sections, which address one of the blocks or the overall operation of the Data EEPROM
Driver.
Library Interface Section Description
System Interaction Functions Provides system module interfaces, device initialization, deinitialization, tasks, and
status functions.
Client Core Functions Provides open, close, and other setup functions.
Block Operation Functions Provides read, write, and erase functions to perform data transfer operations on the
EEPROM device.
Media Interface Functions Provides functions to query the EEPROM geometry and media status.
How the Library Works
Provides information on system, client core, block operation, and media interface functions.
Description
System Functions
Data EEPROM Driver Initialization
The system performs the initialization of the device driver with settings that affect only the instance of the device that is being initialized. During
Volume V: MPLAB Harmony Framework Driver Libraries Help Data EEPROM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 379
system initialization, each instance of the Data EEPROM Driver would be initialized with the following configuration settings passed dynamically at
run time using DRV_EEPROM_INIT, that are supported by the specific EEPROM driver:
• Device requested power state: One of the system module power states. For specific details please refer to "Data Types and Constants" in the
Library Interfacesection.
• The actual peripheral ID enumerated as the PLIB level module ID (e.g., NVM_ID_0)
• EEPROM Media Geometry
The DRV_EEPROM_Initialize function configures and initializes the EEPROM driver using the configuration information provided. It returns an
object handle of the type SYS_MODULE_OBJ. This object handle would be used by other system interfaces such as DRV_EEPROM_Status,
DRV_EEPROM_Tasks and DRV_EEPROM_Deinitialize.
Example:
/*** Data EEPROM Driver Initialization Data ***/
SYS_FS_MEDIA_REGION_GEOMETRY EEPROMGeometryTable[3] =
{
{
.blockSize = 4,
.numBlocks = (DRV_EEPROM_MEDIA_SIZE * 1024),
},
{
.blockSize = 4,
.numBlocks = ((DRV_EEPROM_MEDIA_SIZE * 1024)/4)
},
{
.blockSize = 4,
.numBlocks = ((DRV_EEPROM_MEDIA_SIZE * 1024)/4)
}
};
const SYS_FS_MEDIA_GEOMETRY EEPROMGeometry =
{
.mediaProperty = SYS_FS_MEDIA_WRITE_IS_BLOCKING,
.numReadRegions = 1,
.numWriteRegions = 1,
.numEraseRegions = 1,
.geometryTable = (SYS_FS_MEDIA_REGION_GEOMETRY *)&EEPROMGeometryTable
};
const DRV_EEPROM_INIT drvEepromInit =
{
.moduleInit.sys.powerState = SYS_MODULE_POWER_RUN_FULL,
.eepromId = NVM_ID_0,
.eepromMediaGeometry = (SYS_FS_MEDIA_GEOMETRY *)&EEPROMGeometry
};
/* Initialize the Data EEPROM Driver */
sysObj.drvEeprom = DRV_EEPROM_Initialize(DRV_EEPROM_INDEX_0, (SYS_MODULE_INIT *)&drvEepromInit);
Data EEPROM Driver Task Routine
The Data EEPROM Driver task routine DRV_EEPROM_Tasks, will be called from the system task routine, SYS_Tasks. The driver task routine is
responsible maintaining the driver state machine. The block operation requests from the application or from other modules are added to the driver
queue.
Data EEPROM Driver Status
DRV_EEPROM_Status() returns the current status of the Data EEPROM Driver and is called by the MPLAB Harmony System. The application
may not find the need to call this function directly.
Example:
SYS_MODULE_OBJ object;
// Returned from DRV_EEPROM_Initialize
SYS_STATUS eepromStatus;
eepromStatus = DRV_EEPROM_Status(object);
if (SYS_STATUS_ERROR >= eepromStatus)
{
// Handle error
}
Volume V: MPLAB Harmony Framework Driver Libraries Help Data EEPROM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 380
Client Core Functions
Opening the Driver
For the application to start using an instance of the module, it must call the DRV_EEPROM_Open function repeatedly until a valid handle is
returned by the driver. The application client uses this driver handle to access the driver functions.
For the various options available for I/O INTENT please refer to Data Types and Constants in the Library Interface section.
Example:
eepromHandle = DRV_EEPROM_Open(DRV_EEPROM_INDEX_0, DRV_IO_INTENT_READWRITE);
if (DRV_HANDLE_INVALID == eepromHandle)
{
/* Call until the function returns a valid handle. */
}
else
{
/* Do further processing. */
}
Closing the Driver
Closes an opened-instance of the Data EEPROM Driver. This invalidates the driver handle. The application must open the driver again to obtain a
valid handle.
Example:
DRV_HANDLE eepromHandle; // Returned from DRV_EEPROM_Open
DRV_EEPROM_Close(eepromHandle);
Client Block Operation Functions
The driver provides client interfaces to perform operations in terms of blocks. A block is a unit that represents the minimum amount of data that
can be erased, written, or read. The block sizes may differ for Erase, Write, and Read operations. The DRV_EEPROM_GeometryGet function can
be used to read out the geometry of the EEPROM device. The geometry indicates the number of read, write and erase regions, blocks per region
and the size of each block.
The DRV_EEPROM_Erase, DRV_EEPROM_Write, and DRV_EEPROM_Read functions are used to erase, write, and read the data to/from
EEPROM devices. In addition to these functions, the driver also provides the DRV_EEPROM_BulkErase function that erases the entire EEPROM.
These functions are non-blocking in nature and queue the operation request into the driver queue. All of the requests in the queue are executed by
the DRV_EEPROM_Tasks function one-by-one. A command handle associated with the operation request is returned to the application client
when the operation request is queued at the driver. This handle allows the application client to track the request as it progresses through the
queue. The handle expires when the request processing is complete. The driver provides events (DRV_EEPROM_EVENT) that indicate the
completion of the requests.
The following steps can be performed for a simple Block Data Operation:
1. The system should have completed necessary initialization of the Data EEPROM Driver, and the DRV_EEPROM_Tasks function should be
running in a polled environment.
2. Open the driver using DRV_EEPROM_Open with the necessary intent.
3. Set an event handler callback using the function DRV_EEPROM_EventHandlerSet.
4. Request for block operations using the functions, DRV_EEPROM_Erase, DRV_EEPROM_Write, DRV_EEPROM_Read and
DRV_EEPROM_BulkErase with the appropriate parameters.
5. Wait for event handler callback to occur and check the status of the block operation using the callback function parameter of type
DRV_EEPROM_ EVENT.
6. After performing the required block operations, the client can close the driver using the function , DRV_EEPROM_Close .
Example:
// myAppObj is an application specific state data object.
MY_APP_OBJ myAppObj;
uint8_t myBuffer[MY_BUFFER_SIZE];
uint32_t blockStart, nBlock;
DRV_EEPROM_COMMAND_HANDLE commandHandle;
// drvEEPROMHandle is the handle returned by the DRV_EEPROM_Open // function. Client registers an event
handler with driver. This // is done once.
DRV_EEPROM_EventHandlerSet(drvEEPROMHandle, APP_EEPROMEventHandler, (uintptr_t)&myAppObj);
DRV_EEPROM_Read(drvEEPROMHandle, &commandHandle, &myBuffer, blockStart, nBlock);
if(DRV_EEPROM_COMMAND_HANDLE_INVALID == commandHandle)
{
// Error handling here
Volume V: MPLAB Harmony Framework Driver Libraries Help Data EEPROM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 381
}
// Event Processing Technique. Event is received when operation // is done.
void APP_EEPROMEventHandler
(
DRV_EEPROM_EVENT event,
DRV_EEPROM_COMMAND_HANDLE commandHandle,
uintptr_t contextHandle
)
{
// The context handle was set to an application specific
// object. It is now retrievable easily in the event
// handler.
MY_APP_OBJ myAppObj = (MY_APP_OBJ *) context;
switch(event)
{
case DRV_EEPROM_EVENT_COMMAND_COMPLETE:
// Operation completed successfully.
break;
case DRV_EEPROM_EVENT_COMMAND_ERROR:
// Error handling here.
break;
default:
break;
}
}
Media Interface Functions
Reading the Device Geometry
The application can call the DRV_EEPROM_GeometryGet function to obtain the geometry of the EEPROM device. The geometry indicates the
number of read, write and erase regions, number of blocks per region and the size of each block.
Example:
SYS_FS_MEDIA_GEOMETRY * eepromGeometry;
uint32_t readBlockSize, writeBlockSize, eraseBlockSize;
uint32_t nReadBlocks, nReadRegions, totalSize;
eepromGeometry = DRV_EEPROM_GeometryGet(eepromOpenHandle1);
readBlockSize = eepromGeometry->geometryTable->blockSize;
nReadBlocks = eepromGeometry->geometryTable->numBlocks;
nReadRegions = eepromGeometry->numReadRegions;
writeBlockSize = (eepromGeometry->geometryTable +1)->blockSize;
eraseBlockSize = (eepromGeometry->geometryTable +2)->blockSize;
//The below expression provides the EEPROM memory size.
totalSize = readBlockSize * nReadBlocks * nReadRegions;
Configuring the Library
Macros
Name Description
DRV_EEPROM_BUFFER_OBJECT_NUMBER Selects the maximum number of buffer objects
DRV_EEPROM_CLIENTS_NUMBER Selects the maximum number of clients
DRV_EEPROM_INSTANCES_NUMBER Selects the maximum number of Driver instances that can be supported by the
dynamic driver.
DRV_EEPROM_MEDIA_SIZE Specifies the EEPROM Media size.
DRV_EEPROM_SYS_FS_REGISTER Register to use with the File system
Volume V: MPLAB Harmony Framework Driver Libraries Help Data EEPROM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 382
Description
The configuration of the Data EEPROM Driver is based on the file system_config.h.
This header file contains the configuration selection for the Data EEPROM Driver. Based on the selections made, the Data EEPROM Driver may
support the selected features. These configuration settings will apply to all instances of the Data EEPROM Driver.
This header can be placed anywhere, the path of this header needs to be present in the include search path for a successful build. Refer to the
Applications Help section for more details.
DRV_EEPROM_BUFFER_OBJECT_NUMBER Macro
Selects the maximum number of buffer objects
File
drv_eeprom_config_template.h
C
#define DRV_EEPROM_BUFFER_OBJECT_NUMBER 5
Description
EEPROM Driver maximum number of buffer objects
This definition selects the maximum number of buffer objects. This indirectly also specifies the queue depth. The EEPROM Driver can queue up to
DRV_EEPROM_BUFFER_OBJECT_NUMBER of read/write requests before returning a DRV_EEPROM_BUFFER_HANDLE_INVALID due to the
queue being full. Buffer objects are shared by all instances of the driver. Increasing this number increases the RAM requirement of the driver.
Remarks
This macro is mandatory when building the driver for dynamic operation.
DRV_EEPROM_CLIENTS_NUMBER Macro
Selects the maximum number of clients
File
drv_eeprom_config_template.h
C
#define DRV_EEPROM_CLIENTS_NUMBER 1
Description
EEPROM maximum number of clients
This definition selects the maximum number of clients that the EEPROM driver can support at run time. This constant defines the total number of
EEPROM driver clients that will be available to all instances of the EEPROM driver.
Remarks
This macro is mandatory when building the driver for dynamic operation.
DRV_EEPROM_INSTANCES_NUMBER Macro
Selects the maximum number of Driver instances that can be supported by the dynamic driver.
File
drv_eeprom_config_template.h
C
#define DRV_EEPROM_INSTANCES_NUMBER 1
Description
EEPROM Driver instance configuration
This definition selects the maximum number of Driver instances that can be supported by the dynamic driver. In case of this driver, multiple
instances of the driver could use the same hardware instance.
Remarks
This macro is mandatory when building the driver for dynamic operation.
Volume V: MPLAB Harmony Framework Driver Libraries Help Data EEPROM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 383
DRV_EEPROM_MEDIA_SIZE Macro
Specifies the EEPROM Media size.
File
drv_eeprom_config_template.h
C
#define DRV_EEPROM_MEDIA_SIZE 32
Description
EEPROM Media Size
This definition specifies the EEPROM Media Size to be used. The size is specified in number of Kilo Bytes. The media size MUST never exceed
physical available EEPROM Memory size. Application code requirements should be kept in mind while defining this parameter.
Remarks
This macro is mandatory when building the driver for dynamic operation.
DRV_EEPROM_SYS_FS_REGISTER Macro
Register to use with the File system
File
drv_eeprom_config_template.h
C
#define DRV_EEPROM_SYS_FS_REGISTER
Description
EEPROM Driver Register with File System
Specifying this macro enables the EEPROM driver to register its services with the SYS FS.
Remarks
This macro is optional and should be specified only if the EEPROM driver is to be used with the File System.
Building the Library
This section lists the files that are available in the Data EEPROM Driver Library.
Description
This section lists the files that are available in the \src folder of the Data EEPROM Driver. It lists which files need to be included in the build
based on either a hardware feature present on the board or configuration option selected by the system.
The following three tables list and describe the header (.h) and source (.c) files that implement this library. The parent folder for these files is
/framework/driver/eeprom.
Interface File(s)
This table lists and describes the header files that must be included (i.e., using #include) by any code that uses this library.
Source File Name Description
/drv_eeprom.h Header file that exports the driver API.
Required File(s)
All of the required files listed in the following table are automatically added into the MPLAB X IDE project by the MHC
when the library is selected for use.
This table lists and describes the source and header files that must always be included in the MPLAB X IDE project to build this library.
Source File Name Description
/src/dynamic/drv_eeprom.c Basic Data EEPROM Driver implementation file.
Volume V: MPLAB Harmony Framework Driver Libraries Help Data EEPROM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 384
Optional File(s)
This table lists and describes the source and header files that may optionally be included if required for the desired implementation.
Source File Name Description
N/A No optional files are available for this library
Module Dependencies
The Data EEPROM Driver Library is not dependent upon any modules.
Library Interface
a) System Functions
Name Description
DRV_EEPROM_Initialize Initializes the EEPROM instance for the specified driver index.
DRV_EEPROM_Deinitialize Deinitializes the specified instance of the EEPROM driver module
DRV_EEPROM_Status Gets the current status of the EEPROM driver module.
DRV_EEPROM_Tasks Handles the read or write requests queued to the driver.
b) Client Core Functions
Name Description
DRV_EEPROM_Close Closes an opened-instance of the EEPROM driver
DRV_EEPROM_Open Opens the specified EEPROM driver instance and returns a handle to it
c) Block Operation Functions
Name Description
DRV_EEPROM_BulkErase Performs a bulk erase of the entire Data EEPROM.
DRV_EEPROM_Erase Erases blocks of data starting from the specified block address.
DRV_EEPROM_Read Reads blocks of data from the specified address in EEPROM memory.
DRV_EEPROM_Write Writes blocks of data starting from the specified address in EEPROM memory.
d) Media Interface Functions
Name Description
DRV_EEPROM_AddressGet Returns the EEPROM media start address
DRV_EEPROM_CommandStatus Gets the current status of the command.
DRV_EEPROM_EventHandlerSet Allows a client to identify an event handling function for the driver to call back when queued
operation has completed.
DRV_EEPROM_GeometryGet Returns the geometry of the device.
DRV_EEPROM_IsAttached Returns the physical attach status of the EEPROM.
DRV_EEPROM_IsWriteProtected Returns the write protect status of the EEPROM.
e) Data Types and Constants
Name Description
DRV_EEPROM_COMMAND_HANDLE_INVALID This value defines the EEPROM Driver's Invalid Command Handle.
DRV_EEPROM_INDEX_0 EEPROM driver index definition
DRV_EEPROM_COMMAND_HANDLE Handle identifying commands queued in the driver.
DRV_EEPROM_COMMAND_STATUS Specifies the status of the command for read or write requests.
DRV_EEPROM_EVENT Identifies the possible events that can result from a request.
DRV_EEPROM_EVENT_HANDLER Pointer to a EEPROM Driver Event handler function
DRV_EEPROM_INIT Defines the data required to initialize the EEPROM driver
Description
This section describes the Application Programming Interface (API) functions of the Data EEPROM Driver Library.
a) System Functions
Volume V: MPLAB Harmony Framework Driver Libraries Help Data EEPROM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 385
DRV_EEPROM_Initialize Function
Initializes the EEPROM instance for the specified driver index.
File
drv_eeprom.h
C
SYS_MODULE_OBJ DRV_EEPROM_Initialize(const SYS_MODULE_INDEX index, const SYS_MODULE_INIT * const init);
Returns
If successful, returns a valid handle to a driver instance object. Otherwise it returns SYS_MODULE_OBJ_INVALID.
Description
This routine initializes the EEPROM driver instance for the specified driver index, making it ready for clients to open and use it.
Remarks
This routine must be called before any other EEPROM routine is called.
This routine should only be called once during system initialization unless DRV_EEPROM_Deinitialize is called to deinitialize the driver instance.
This routine will NEVER block for hardware access. The system must use DRV_EEPROM_Status to find out when the driver is in the ready state.
Build configuration options may be used to statically override options in the "init" structure and will take precedence over initialization data passed
using this routine.
Preconditions
None.
Example
// This code snippet shows an example of initializing the EEPROM Driver.
SYS_MODULE_OBJ objectHandle;
SYS_FS_MEDIA_REGION_GEOMETRY EEPROMGeometryTable[3] =
{
{
.blockSize = 4,
.numBlocks = (DRV_EEPROM_MEDIA_SIZE * 1024),
},
{
.blockSize = 4,
.numBlocks = ((DRV_EEPROM_MEDIA_SIZE * 1024)/4)
},
{
.blockSize = 4,
.numBlocks = ((DRV_EEPROM_MEDIA_SIZE * 1024)/4)
}
};
const SYS_FS_MEDIA_GEOMETRY EEPROMGeometry =
{
.mediaProperty = SYS_FS_MEDIA_WRITE_IS_BLOCKING,
.numReadRegions = 1,
.numWriteRegions = 1,
.numEraseRegions = 1,
.geometryTable = (SYS_FS_MEDIA_REGION_GEOMETRY *)&EEPROMGeometryTable
};
// EEPROM Driver Initialization Data
const DRV_EEPROM_INIT drvEepromInit =
{
.moduleInit.sys.powerState = SYS_MODULE_POWER_RUN_FULL,
.eepromId = NVM_ID_0,
.eepromMediaGeometry = (SYS_FS_MEDIA_GEOMETRY *)&EEPROMGeometry
};
Volume V: MPLAB Harmony Framework Driver Libraries Help Data EEPROM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 386
objectHandle = DRV_EEPROM_Initialize(DRV_EEPROM_INDEX_0, (SYS_MODULE_INIT*)&drvEepromInit);
if (SYS_MODULE_OBJ_INVALID == objectHandle)
{
// Handle error
}
Parameters
Parameters Description
index Identifier for the instance to be initialized.
init Pointer to a data structure containing any data necessary to initialize the driver.
Function
SYS_MODULE_OBJ DRV_EEPROM_Initialize
(
const SYS_MODULE_INDEX index,
const SYS_MODULE_INIT * const init
);
DRV_EEPROM_Deinitialize Function
Deinitializes the specified instance of the EEPROM driver module
File
drv_eeprom.h
C
void DRV_EEPROM_Deinitialize(SYS_MODULE_OBJ object);
Returns
None.
Description
Deinitializes the specified instance of the EEPROM driver module, disabling its operation. Invalidates all the internal data.
Remarks
Once the Initialize operation has been called, the Deinitialize operation must be called before the Initialize operation can be called again.
Preconditions
Function DRV_EEPROM_Initialize should have been called before calling this function.
Parameter: object - Driver object handle, returned from the DRV_EEPROM_Initialize routine
Example
// This code snippet shows an example of deinitializing the driver.
SYS_MODULE_OBJ object; // Returned from DRV_EEPROM_Initialize
SYS_STATUS status;
DRV_EEPROM_Deinitialize(object);
status = DRV_EEPROM_Status(object);
if (SYS_MODULE_DEINITIALIZED != status)
{
// Check again later if you need to know when the driver is
// deinitialized.
}
Function
void DRV_EEPROM_Deinitialize
(
SYS_MODULE_OBJ object
);
Volume V: MPLAB Harmony Framework Driver Libraries Help Data EEPROM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 387
DRV_EEPROM_Status Function
Gets the current status of the EEPROM driver module.
File
drv_eeprom.h
C
SYS_STATUS DRV_EEPROM_Status(SYS_MODULE_OBJ object);
Returns
SYS_STATUS_READY - Indicates that the driver is ready and accept requests for new operations.
SYS_STATUS_UNINITIALIZED - Indicates the driver is not initialized.
Description
This routine provides the current status of the EEPROM driver module.
Remarks
None.
Preconditions
Function DRV_EEPROM_Initialize should have been called before calling this function.
Example
SYS_MODULE_OBJ object; // Returned from DRV_EEPROM_Initialize
SYS_STATUS EEPROMStatus;
EEPROMStatus = DRV_EEPROM_Status(object);
if (EEPROMStatus == SYS_STATUS_READY)
{
// Driver is ready to perform operations.
}
else
{
// Driver is not ready.
}
Parameters
Parameters Description
object Driver object handle, returned from the DRV_EEPROM_Initialize routine
Function
SYS_STATUS DRV_EEPROM_Status
(
SYS_MODULE_OBJ object
);
DRV_EEPROM_Tasks Function
Handles the read or write requests queued to the driver.
File
drv_eeprom.h
C
void DRV_EEPROM_Tasks(SYS_MODULE_OBJ object);
Returns
None.
Volume V: MPLAB Harmony Framework Driver Libraries Help Data EEPROM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 388
Description
This routine is used to handle the read or write requests queued to the driver.
Remarks
This routine is normally not called directly by an application. It is called by the system's Tasks routine (SYS_Tasks).
Preconditions
The DRV_EEPROM_Initialize routine must have been called for the specified EEPROM driver instance.
Example
SYS_MODULE_OBJ object; // Returned from DRV_EEPROM_Initialize
while (true)
{
DRV_EEPROM_Tasks (object);
// Do other tasks
}
Parameters
Parameters Description
object Object handle for the specified driver instance (returned from DRV_EEPROM_Initialize)
Function
void DRV_EEPROM_Tasks
(
SYS_MODULE_OBJ object
);
b) Client Core Functions
DRV_EEPROM_Close Function
Closes an opened-instance of the EEPROM driver
File
drv_eeprom.h
C
void DRV_EEPROM_Close(const DRV_HANDLE handle);
Returns
None
Description
This routine closes an opened-instance of the EEPROM driver, invalidating the handle.
Remarks
After calling this routine, the handle passed in "handle" must not be used with any of the remaining driver routines. A new handle must be obtained
by calling DRV_EEPROM_Open before the caller may use the driver again. Usually there is no need for the driver client to verify that the Close
operation has completed.
Preconditions
The DRV_EEPROM_Initialize routine must have been called for the specified EEPROM driver instance.
DRV_EEPROM_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE handle; // Returned from DRV_EEPROM_Open
DRV_EEPROM_Close(handle);
Volume V: MPLAB Harmony Framework Driver Libraries Help Data EEPROM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 389
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
void DRV_EEPROM_Close
(
const DRV_HANDLE handle
);
DRV_EEPROM_Open Function
Opens the specified EEPROM driver instance and returns a handle to it
File
drv_eeprom.h
C
DRV_HANDLE DRV_EEPROM_Open(const SYS_MODULE_INDEX index, const DRV_IO_INTENT ioIntent);
Returns
If successful, the routine returns a valid open-instance handle (a number identifying both the caller and the module instance).
If an error occurs, DRV_HANDLE_INVALID is returned. Errors can occur under the following circumstances:
• if the number of client objects allocated via DRV_EEPROM_CLIENTS_NUMBER is insufficient
• if the client is trying to open the driver but driver has been opened exclusively by another client
• if the client is trying to open the driver exclusively, but has already been opened in a non exclusive mode by another client.
• if the driver hardware instance being opened is invalid
Description
This routine opens the specified EEPROM driver instance and provides a handle. This handle must be provided to all other client-level operations
to identify the caller and the instance of the driver.
Remarks
The handle returned is valid until the DRV_EEPROM_Close routine is called. This routine will NEVER block waiting for hardware. If the driver has
already been opened, it cannot be opened exclusively.
Preconditions
DRV_EEPROM_Initialize must have been called before calling this function.
Example
DRV_HANDLE handle;
handle = DRV_EEPROM_Open(DRV_EEPROM_INDEX_0, DRV_IO_INTENT_EXCLUSIVE);
if (DRV_HANDLE_INVALID == handle)
{
// Unable to open the driver
}
Parameters
Parameters Description
index Identifier for the object instance to be opened
intent Zero or more of the values from the enumeration DRV_IO_INTENT "ORed" together to
indicate the intended use of the driver
Function
DRV_HANDLE DRV_EEPROM_Open
(
const SYS_MODULE_INDEX index,
const DRV_IO_INTENT ioIntent
);
Volume V: MPLAB Harmony Framework Driver Libraries Help Data EEPROM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 390
c) Block Operation Functions
DRV_EEPROM_BulkErase Function
Performs a bulk erase of the entire Data EEPROM.
File
drv_eeprom.h
C
void DRV_EEPROM_BulkErase(const DRV_HANDLE handle, DRV_EEPROM_COMMAND_HANDLE * commandHandle);
Returns
If the request was queued successfully then a valid command handle is returned in the commandHandle argument. Otherwise
DRV_EEPROM_COMMAND_HANDLE_INVALID is returned if the request was not successful.
Description
This function schedules a non-blocking bulk erase operation of the entire Data EEPROM. The function returns with a valid handle in the
commandHandle argument if the erase request was scheduled successfully. The function adds the request to the hardware instance queue and
returns immediately. The function returns DRV_EEPROM_COMMAND_HANDLE_INVALID in the commandHandle argument under the following
circumstances:
• if a buffer object could not be allocated to the request
• if the client opened the driver for read only
• if the driver handle is invalid
If the requesting client registered an event callback with the driver, the driver will issue a DRV_EEPROM_EVENT_COMMAND_COMPLETE event
if the command was processed successfully or DRV_EEPROM_EVENT_COMMAND_ERROR event if the command was not processed
successfully.
Remarks
None
Refer to drv_eeprom.h for usage information.
Preconditions
The DRV_EEPROM_Initialize() routine must have been called for the specified EEPROM driver instance.
DRV_EEPROM_Open() routine must have been called to obtain a valid opened device handle. DRV_IO_INTENT_WRITE or
DRV_IO_INTENT_READWRITE must have been specified as a parameter to this routine.
Example
DRV_EEPROM_COMMAND_HANDLE commandHandle;
MY_APP_OBJ myAppObj;
// myEEPROMHandle is the handle returned by the DRV_EEPROM_Open function.
// Client registers an event handler with driver
DRV_EEPROM_EventHandlerSet(myEEPROMHandle, APP_EEPROMEventHandler, (uintptr_t)&myAppObj);
DRV_EEPROM_BulkErase(myEEPROMHandle, &commandHandle);
if(DRV_EEPROM_COMMAND_HANDLE_INVALID == commandHandle)
{
// Error handling here
}
// Event is received when the buffer is processed.
void APP_EEPROMEventHandler
(
DRV_EEPROM_EVENT event,
DRV_EEPROM_COMMAND_HANDLE commandHandle,
uintptr_t context
)
{
Volume V: MPLAB Harmony Framework Driver Libraries Help Data EEPROM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 391
// context points to myAppObj.
switch(event)
{
case DRV_EEPROM_EVENT_COMMAND_COMPLETE:
// Bulk Erase operation is complete.
break;
case DRV_EEPROM_EVENT_COMMAND_ERROR:
// Bulk Erase operation failed.
break;
default:
break;
}
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
commandHandle Pointer to an argument that will contain the return buffer handle
Function
void DRV_EEPROM_BulkErase
(
const DRV_HANDLE handle,
DRV_EEPROM_COMMAND_HANDLE * commandHandle
);
DRV_EEPROM_Erase Function
Erases blocks of data starting from the specified block address.
File
drv_eeprom.h
C
void DRV_EEPROM_Erase(const DRV_HANDLE handle, DRV_EEPROM_COMMAND_HANDLE * commandHandle, uint32_t
blockStart, uint32_t nBlock);
Returns
If the request was queued successfully then a valid command handle is returned in the commandHandle argument. Otherwise
DRV_EEPROM_COMMAND_HANDLE_INVALID is returned if the request was not successful.
Description
This function schedules a non-blocking erase operation for erasing blocks of memory. The function returns with a valid handle in the
commandHandle argument if the erase request was scheduled successfully. The function adds the request to the hardware instance queue and
returns immediately. The function returns DRV_EEPROM_COMMAND_HANDLE_INVALID in the commandHandle argument under the following
circumstances:
• if a buffer object could not be allocated to the request
• if the client opened the driver for read only
• if the number of blocks to be erased is either zero or more than the number of blocks actually available
• if the driver handle is invalid
If the requesting client registered an event callback with the driver, the driver will issue a DRV_EEPROM_EVENT_COMMAND_COMPLETE event
if the command was processed successfully or DRV_EEPROM_EVENT_COMMAND_ERROR event if the command was not processed
successfully.
Remarks
None
Preconditions
The DRV_EEPROM_Initialize() routine must have been called for the specified EEPROM driver instance.
Volume V: MPLAB Harmony Framework Driver Libraries Help Data EEPROM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 392
DRV_EEPROM_Open() routine must have been called to obtain a valid opened device handle. DRV_IO_INTENT_WRITE or
DRV_IO_INTENT_READWRITE must have been specified as a parameter to this routine.
Example
uint32_t blockStart = 0;
uint32_t nBlock = 2;
DRV_EEPROM_COMMAND_HANDLE commandHandle;
MY_APP_OBJ myAppObj;
// myEEPROMHandle is the handle returned by the DRV_EEPROM_Open function.
// Client registers an event handler with driver
DRV_EEPROM_EventHandlerSet(myEEPROMHandle, APP_EEPROMEventHandler, (uintptr_t)&myAppObj);
DRV_EEPROM_Erase(myEEPROMHandle, &commandHandle, blockStart, nBlock);
if(DRV_EEPROM_COMMAND_HANDLE_INVALID == commandHandle)
{
// Error handling here
}
// Event is received when the buffer is processed.
void APP_EEPROMEventHandler
(
DRV_EEPROM_EVENT event,
DRV_EEPROM_COMMAND_HANDLE commandHandle,
uintptr_t context
)
{
// context points to myAppObj.
switch(event)
{
case DRV_EEPROM_EVENT_COMMAND_COMPLETE:
// Erase operation is complete.
break;
case DRV_EEPROM_EVENT_COMMAND_ERROR:
// Erase operation failed.
break;
default:
break;
}
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
commandHandle Pointer to an argument that will contain the return buffer handle
blockStart block start addess for the erase operation.
nBlock Total number of blocks to be erased.
Function
void DRV_EEPROM_Erase
(
const DRV_HANDLE handle,
DRV_EEPROM_COMMAND_HANDLE * commandHandle,
uint32_t blockStart,
uint32_t nBlock
);
Volume V: MPLAB Harmony Framework Driver Libraries Help Data EEPROM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 393
DRV_EEPROM_Read Function
Reads blocks of data from the specified address in EEPROM memory.
File
drv_eeprom.h
C
void DRV_EEPROM_Read(const DRV_HANDLE handle, DRV_EEPROM_COMMAND_HANDLE * commandHandle, void * buffer,
uint32_t blockStart, uint32_t nBlock);
Returns
If the request was queued successfully then a valid command handle is returned in the commandHandle argument. Otherwise
DRV_EEPROM_COMMAND_HANDLE_INVALID is returned if the request was not successful.
Description
This function schedules a non-blocking read operation for reading blocks of data from the EEPROM memory. The function returns with a valid
handle in the commandHandle argument if the read request was scheduled successfully. The function adds the request to the driver instance
queue and returns immediately. While the request is in the queue, the application buffer is owned by the driver and should not be modified. The
function returns DRV_EEPROM_COMMAND_HANDLE_INVALID in the commandHandle argument under the following circumstances:
• if a buffer object could not be allocated to the request
• if the buffer pointer is NULL
• if the queue size is full or queue depth is insufficient
• if the driver handle is invalid
• if the number of blocks to be read is zero or more than the actual number of blocks available
• if the client opened the driver in write only mode
If the requesting client registered an event callback with the driver, the driver will issue a DRV_EEPROM_EVENT_COMMAND_COMPLETE event
if the command was processed successfully or DRV_EEPROM_EVENT_COMMAND_ERROR event if the command was not processed
successfully.
Remarks
None.
Preconditions
The DRV_EEPROM_Initialize routine must have been called for the specified EEPROM driver instance.
DRV_EEPROM_Open must have been called with DRV_IO_INTENT_READ or DRV_IO_INTENT_READWRITE as the ioIntent to obtain a valid
opened device handle.
Example
uint8_t myBuffer[MY_BUFFER_SIZE];
// address should be block aligned.
uint32_t blockStart = EEPROM_BASE_ADDRESS_TO_READ_FROM;
uint32_t nBlock = 2;
DRV_EEPROM_COMMAND_HANDLE commandHandle;
MY_APP_OBJ myAppObj;
// myEEPROMHandle is the handle returned by the DRV_EEPROM_Open function.
DRV_EEPROM_EventHandlerSet(myEEPROMHandle, APP_EEPROMEventHandler, (uintptr_t)&myAppObj);
DRV_EEPROM_Read(myEEPROMHandle, &commandHandle, &myBuffer, blockStart, nBlock);
if(DRV_EEPROM_COMMAND_HANDLE_INVALID == commandHandle)
{
// Error handling here
}
else
{
// Read queued successfully.
}
// Event is received when the buffer is processed.
void APP_EEPROMEventHandler
(
DRV_EEPROM_EVENT event,
Volume V: MPLAB Harmony Framework Driver Libraries Help Data EEPROM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 394
DRV_EEPROM_COMMAND_HANDLE commandHandle,
uintptr_t context
)
{
// context points to myAppObj.
switch(event)
{
case DRV_EEPROM_EVENT_COMMAND_COMPLETE:
// This means the data was transferred.
break;
case DRV_EEPROM_EVENT_COMMAND_ERROR:
// Error handling here.
break;
default:
break;
}
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
commandHandle Pointer to an argument that will contain the return buffer handle
buffer Buffer into which the data read from the EEPROM memory will be placed
blockStart Start block address in EEPROM memory from where the read should begin.
nBlock Total number of blocks to be read.
Function
void DRV_EEPROM_Read
(
const DRV_HANDLE handle,
DRV_EEPROM_COMMAND_HANDLE * commandHandle,
void * buffer,
uint32_t blockStart,
uint32_t nBlock
);
DRV_EEPROM_Write Function
Writes blocks of data starting from the specified address in EEPROM memory.
File
drv_eeprom.h
C
void DRV_EEPROM_Write(const DRV_HANDLE handle, DRV_EEPROM_COMMAND_HANDLE * commandHandle, void * buffer,
uint32_t blockStart, uint32_t nBlock);
Returns
If the request was queued successfully then a valid command handle is returned in the commandHandle argument. Otherwise
DRV_EEPROM_COMMAND_HANDLE_INVALID is returned if the request was not successful.
Description
This function schedules a non-blocking write operation for writing blocks of data into memory. The function returns with a valid handle in the
commandHandle argument if the write request was scheduled successfully. The function adds the request to the hardware instance queue and
returns immediately. While the request is in the queue, the application buffer is owned by the driver and should not be modified. The function
returns DRV_EEPROM_COMMAND_HANDLE_INVALID in the commandHandle argument under the following circumstances:
• if a buffer object could not be allocated to the request
• if the buffer pointer is NULL
Volume V: MPLAB Harmony Framework Driver Libraries Help Data EEPROM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 395
• if the client opened the driver for read only
• if the number of blocks to be written is either zero or more than the number of blocks actually available
• if the write queue size is full or queue depth is insufficient
• if the driver handle is invalid
If the requesting client registered an event callback with the driver, the driver will issue a DRV_EEPROM_EVENT_COMMAND_COMPLETE event
if the command was processed successfully or DRV_EEPROM_EVENT_COMMAND_ERROR event if the command was not processed
successfully.
Remarks
None
Preconditions
The DRV_EEPROM_Initialize() routine must have been called for the specified EEPROM driver instance.
DRV_EEPROM_Open() routine must have been called to obtain a valid opened device handle. DRV_IO_INTENT_WRITE or
DRV_IO_INTENT_READWRITE must have been specified as a parameter to this routine.
Example
uint8_t myBuffer[MY_BUFFER_SIZE];
uint32_t blockStart = EEPROM_BASE_ADDRESS_TO_WRITE_TO;
uint32_t nBlock = 2;
DRV_EEPROM_COMMAND_HANDLE commandHandle;
MY_APP_OBJ myAppObj;
// myEEPROMHandle is the handle returned by the DRV_EEPROM_Open function.
// Client registers an event handler with driver
DRV_EEPROM_EventHandlerSet(myEEPROMHandle, APP_EEPROMEventHandler, (uintptr_t)&myAppObj);
DRV_EEPROM_Write(myEEPROMHandle, &commandHandle, &myBuffer, blockStart, nBlock);
if(DRV_EEPROM_COMMAND_HANDLE_INVALID == commandHandle)
{
// Error handling here
}
// Event is received when the buffer is processed.
void APP_EEPROMEventHandler
(
DRV_EEPROM_EVENT event,
DRV_EEPROM_COMMAND_HANDLE commandHandle,
uintptr_t context
)
{
// context points to myAppObj.
switch(event)
{
case DRV_EEPROM_EVENT_COMMAND_COMPLETE:
// This means the data was transferred.
break;
case DRV_EEPROM_EVENT_COMMAND_ERROR:
// Error handling here.
break;
default:
break;
}
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
commandHandle Pointer to an argument that will contain the return buffer handle
Volume V: MPLAB Harmony Framework Driver Libraries Help Data EEPROM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 396
buffer The buffer containing data to be programmed into EEPROM memory
blockStart Start block address of EEPROM memory where the write should begin.
nBlock Total number of blocks to be written.
Function
void DRV_EEPROM_Write
(
const DRV_HANDLE handle,
DRV_EEPROM_COMMAND_HANDLE * commandHandle,
void * buffer,
uint32_t blockStart,
uint32_t nBlock
);
d) Media Interface Functions
DRV_EEPROM_AddressGet Function
Returns the EEPROM media start address
File
drv_eeprom.h
C
uintptr_t DRV_EEPROM_AddressGet(const DRV_HANDLE handle);
Returns
Start address of the EEPROM Media if the handle is valid otherwise NULL.
Description
This function returns the EEPROM Media start address.
Remarks
None.
Preconditions
The DRV_EEPROM_Initialize() routine must have been called for the specified EEPROM driver instance.
The DRV_EEPROM_Open() routine must have been called to obtain a valid opened device handle.
Example
uintptr_t startAddress;
startAddress = DRV_EEPROM_AddressGet(drvEEPROMHandle);
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
Function
uintptr_t DRV_EEPROM_AddressGet
(
const DRV_HANDLE handle
);
DRV_EEPROM_CommandStatus Function
Gets the current status of the command.
Volume V: MPLAB Harmony Framework Driver Libraries Help Data EEPROM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 397
File
drv_eeprom.h
C
DRV_EEPROM_COMMAND_STATUS DRV_EEPROM_CommandStatus(const DRV_HANDLE handle, const DRV_EEPROM_COMMAND_HANDLE
commandHandle);
Returns
A DRV_EEPROM_COMMAND_STATUS value describing the current status of the command.
Description
This routine gets the current status of the command. The application must use this routine where the status of a scheduled command needs to be
polled on. The function may return DRV_EEPROM_COMMAND_HANDLE_INVALID in a case where the command handle has expired. A
command handle expires when the internal buffer object is re-assigned to another read, write or erase request. It is recommended that this
function be called regularly in order to track the command status correctly.
The application can alternatively register an event handler to receive read, write or erase operation completion events.
Remarks
This routine will not block for hardware access and will immediately return the current status.
Preconditions
The DRV_EEPROM_Initialize() routine must have been called.
The DRV_EEPROM_Open() must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE handle; // Returned from DRV_EEPROM_Open
DRV_EEPROM_COMMAND_HANDLE commandHandle;
DRV_EEPROM_COMMAND_STATUS status;
status = DRV_EEPROM_CommandStatus(handle, commandHandle);
if(status == DRV_EEPROM_COMMAND_COMPLETED)
{
// Operation Done
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
commandHandle A valid command handle returned from read, write or erase request.
Function
DRV_EEPROM_COMMAND_STATUS DRV_EEPROM_CommandStatus
(
const DRV_HANDLE handle,
const DRV_EEPROM_COMMAND_HANDLE commandHandle
);
DRV_EEPROM_EventHandlerSet Function
Allows a client to identify an event handling function for the driver to call back when queued operation has completed.
File
drv_eeprom.h
C
void DRV_EEPROM_EventHandlerSet(const DRV_HANDLE handle, const void * eventHandler, const uintptr_t
context);
Returns
None.
Volume V: MPLAB Harmony Framework Driver Libraries Help Data EEPROM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 398
Description
This function allows a client to identify an event handling function for the driver to call back when queued operation has completed. When a client
calls a read, write or a erase function, it is provided with a handle identifying the command that was added to the driver's command queue. The
driver will pass this handle back to the client by calling "eventHandler" function when the queued operation has completed.
The event handler should be set before the client performs any read, write or erase operations that could generate events. The event handler once
set, persists until the client closes the driver or sets another event handler (which could be a "NULL" pointer to indicate no callback).
Remarks
If the client does not want to be notified when the queued operation has completed, it does not need to register a callback.
Preconditions
The DRV_EEPROM_Initialize() routine must have been called for the specified EEPROM driver instance.
The DRV_EEPROM_Open() routine must have been called to obtain a valid opened device handle.
Example
// myAppObj is an application specific state data object.
MY_APP_OBJ myAppObj;
uint8_t myBuffer[MY_BUFFER_SIZE];
uint32_t blockStart, nBlock;
DRV_EEPROM_COMMAND_HANDLE commandHandle;
// drvEEPROMHandle is the handle returned by the DRV_EEPROM_Open function.
// Client registers an event handler with driver. This is done once.
DRV_EEPROM_EventHandlerSet(drvEEPROMHandle, APP_EEPROMEventHandler, (uintptr_t)&myAppObj);
DRV_EEPROM_Read(drvEEPROMHandle, &commandHandle, &myBuffer, blockStart, nBlock);
if(DRV_EEPROM_COMMAND_HANDLE_INVALID == commandHandle)
{
// Error handling here
}
// Event Processing Technique. Event is received when operation is done.
void APP_EEPROMEventHandler
(
DRV_EEPROM_EVENT event,
DRV_EEPROM_COMMAND_HANDLE commandHandle,
uintptr_t context
)
{
// The context handle was set to an application specific
// object. It is now retrievable easily in the event handler.
MY_APP_OBJ myAppObj = (MY_APP_OBJ *) context;
switch(event)
{
case DRV_EEPROM_EVENT_COMMAND_COMPLETE:
// This means the data was transferred.
break;
case DRV_EEPROM_EVENT_COMMAND_ERROR:
// Error handling here.
break;
default:
break;
}
}
Volume V: MPLAB Harmony Framework Driver Libraries Help Data EEPROM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 399
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
eventHandler Pointer to the event handler function implemented by the user
context The value of parameter will be passed back to the client unchanged, when the eventHandler
function is called. It can be used to identify any client specific data object that identifies the
instance of the client module (for example, it may be a pointer to the client module's state
structure).
Function
void DRV_EEPROM_EventHandlerSet
(
const DRV_HANDLE handle,
const void * eventHandler,
const uintptr_t context
);
DRV_EEPROM_GeometryGet Function
Returns the geometry of the device.
File
drv_eeprom.h
C
SYS_FS_MEDIA_GEOMETRY * DRV_EEPROM_GeometryGet(const DRV_HANDLE handle);
Returns
SYS_FS_MEDIA_GEOMETRY - Pointer to structure which holds the media geometry information.
Description
This API gives the following geometrical details of the EEPROM memory:
• Media Property
• Number of Read/Write/Erase regions
• Number of Blocks and their size in each region of the device
Remarks
None.
Preconditions
The DRV_EEPROM_Initialize() routine must have been called for the specified EEPROM driver instance.
The DRV_EEPROM_Open() routine must have been called to obtain a valid opened device handle.
Example
SYS_FS_MEDIA_GEOMETRY * eepromGeometry;
uint32_t readBlockSize, writeBlockSize, eraseBlockSize;
uint32_t nReadBlocks, nReadRegions, totalSize;
eepromGeometry = DRV_EEPROM_GeometryGet(eepromOpenHandle1);
readBlockSize = eepromGeometry->geometryTable->blockSize;
nReadBlocks = eepromGeometry->geometryTable->numBlocks;
nReadRegions = eepromGeometry->numReadRegions;
writeBlockSize = (eepromGeometry->geometryTable +1)->blockSize;
eraseBlockSize = (eepromGeometry->geometryTable +2)->blockSize;
totalSize = readBlockSize * nReadBlocks * nReadRegions;
Volume V: MPLAB Harmony Framework Driver Libraries Help Data EEPROM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 400
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
Function
SYS_FS_MEDIA_GEOMETRY * DRV_EEPROM_GeometryGet
(
const DRV_HANDLE handle
);
DRV_EEPROM_IsAttached Function
Returns the physical attach status of the EEPROM.
File
drv_eeprom.h
C
bool DRV_EEPROM_IsAttached(const DRV_HANDLE handle);
Returns
Returns true always
Description
This function returns the physical attach status of the EEPROM.
Remarks
None.
Preconditions
The DRV_EEPROM_Initialize() routine must have been called for the specified EEPROM driver instance.
The DRV_EEPROM_Open() routine must have been called to obtain a valid opened device handle.
Example
// The EEPROM media is always attached and so the below always returns
// true.
bool isEEPROMAttached;
isEEPROMAttached = DRV_EEPROM_isAttached(drvEEPROMHandle);
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
Function
bool DRV_EEPROM_IsAttached
(
const DRV_HANDLE handle
);
DRV_EEPROM_IsWriteProtected Function
Returns the write protect status of the EEPROM.
File
drv_eeprom.h
C
bool DRV_EEPROM_IsWriteProtected(const DRV_HANDLE handle);
Volume V: MPLAB Harmony Framework Driver Libraries Help Data EEPROM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 401
Returns
Always returns false.
Description
This function returns the physical attach status of the EEPROM. This function always returns false.
Remarks
None.
Preconditions
The DRV_EEPROM_Initialize() routine must have been called for the specified EEPROM driver instance.
The DRV_EEPROM_Open() routine must have been called to obtain a valid opened device handle.
Example
// The EEPROM media is treated as always writeable.
bool isWriteProtected;
isWriteProtected = DRV_EEPROM_IsWriteProtected(drvEEPROMHandle);
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
Function
bool DRV_EEPROM_IsWriteProtected
(
const DRV_HANDLE handle
);
e) Data Types and Constants
DRV_EEPROM_COMMAND_HANDLE_INVALID Macro
This value defines the EEPROM Driver's Invalid Command Handle.
File
drv_eeprom.h
C
#define DRV_EEPROM_COMMAND_HANDLE_INVALID SYS_FS_MEDIA_BLOCK_COMMAND_HANDLE_INVALID
Description
EEPROM Driver Invalid Command Handle.
This value defines the EEPROM Driver Invalid Command Handle. This value is returned by read or write routines when the command request was
not accepted.
Remarks
None.
DRV_EEPROM_INDEX_0 Macro
EEPROM driver index definition
File
drv_eeprom.h
C
#define DRV_EEPROM_INDEX_0 0
Volume V: MPLAB Harmony Framework Driver Libraries Help Data EEPROM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 402
Description
Driver EEPROM Module Index reference
This constant provides EEPROM driver index definition.
Remarks
This constant should be used in place of hard-coded numeric literals. This value should be passed into the DRV_EEPROM_Initialize and
DRV_EEPROM_Open routines to identify the driver instance in use.
DRV_EEPROM_COMMAND_HANDLE Type
Handle identifying commands queued in the driver.
File
drv_eeprom.h
C
typedef SYS_FS_MEDIA_BLOCK_COMMAND_HANDLE DRV_EEPROM_COMMAND_HANDLE;
Description
EEPROM Driver command handle.
A command handle is returned by a call to the read or write functions. This handle allows the application to track the completion of the operation.
This command handle is also returned to the client along with the event that has occurred with respect to the command. This allows the application
to connect the event to a specific command in case where multiple commands are queued.
The command handle associated with the command request expires when the client has been notified of the completion of the command (after
event handler function that notifies the client returns) or after the command has been retired by the driver if no event handler callback was set.
Remarks
None.
DRV_EEPROM_COMMAND_STATUS Enumeration
Specifies the status of the command for read or write requests.
File
drv_eeprom.h
C
typedef enum {
DRV_EEPROM_COMMAND_COMPLETED = SYS_FS_MEDIA_COMMAND_COMPLETED,
DRV_EEPROM_COMMAND_QUEUED = SYS_FS_MEDIA_COMMAND_QUEUED,
DRV_EEPROM_COMMAND_IN_PROGRESS = SYS_FS_MEDIA_COMMAND_IN_PROGRESS,
DRV_EEPROM_COMMAND_ERROR_UNKNOWN = SYS_FS_MEDIA_COMMAND_UNKNOWN
} DRV_EEPROM_COMMAND_STATUS;
Members
Members Description
DRV_EEPROM_COMMAND_COMPLETED =
SYS_FS_MEDIA_COMMAND_COMPLETED
Done OK and ready
DRV_EEPROM_COMMAND_QUEUED =
SYS_FS_MEDIA_COMMAND_QUEUED
Scheduled but not started
DRV_EEPROM_COMMAND_IN_PROGRESS =
SYS_FS_MEDIA_COMMAND_IN_PROGRESS
Currently being in transfer
DRV_EEPROM_COMMAND_ERROR_UNKNOWN
= SYS_FS_MEDIA_COMMAND_UNKNOWN
Unknown Command
Description
EEPROM Driver Command Status
EEPROM Driver command Status
This type specifies the status of the command for the read or write requests.
Volume V: MPLAB Harmony Framework Driver Libraries Help Data EEPROM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 403
Remarks
None.
DRV_EEPROM_EVENT Enumeration
Identifies the possible events that can result from a request.
File
drv_eeprom.h
C
typedef enum {
DRV_EEPROM_EVENT_COMMAND_COMPLETE = SYS_FS_MEDIA_EVENT_BLOCK_COMMAND_COMPLETE,
DRV_EEPROM_EVENT_COMMAND_ERROR = SYS_FS_MEDIA_EVENT_BLOCK_COMMAND_ERROR
} DRV_EEPROM_EVENT;
Members
Members Description
DRV_EEPROM_EVENT_COMMAND_COMPLETE =
SYS_FS_MEDIA_EVENT_BLOCK_COMMAND_COMPLETE
Operation has been completed successfully.
DRV_EEPROM_EVENT_COMMAND_ERROR =
SYS_FS_MEDIA_EVENT_BLOCK_COMMAND_ERROR
There was an error during the operation
Description
EEPROM Driver Events
This enumeration identifies the possible events that can result from a read or write request caused by the client.
Remarks
One of these values is passed in the "event" parameter of the event handling callback function that client registered with the driver by calling the
DRV_EEPROM_EventHandlerSet function when a request is completed.
DRV_EEPROM_EVENT_HANDLER Type
Pointer to a EEPROM Driver Event handler function
File
drv_eeprom.h
C
typedef SYS_FS_MEDIA_EVENT_HANDLER DRV_EEPROM_EVENT_HANDLER;
Returns
None.
Description
EEPROM Driver Event Handler Function Pointer
This data type defines the required function signature for the EEPROM event handling callback function. A client must register a pointer to an
event handling function whose function signature (parameter and return value types) match the types specified by this function pointer in order to
receive event callbacks from the driver.
The parameters and return values are described here and a partial example implementation is provided.
Remarks
If the event is DRV_EEPROM_EVENT_COMMAND_COMPLETE, it means that the scheduled operation was completed successfully.
If the event is DRV_EEPROM_EVENT_COMMAND_ERROR, it means that the scheduled operation was not completed successfully.
The context parameter contains the handle to the client context, provided at the time the event handling function was registered using the
DRV_EEPROM_EventHandlerSet function. This context handle value is passed back to the client as the "context" parameter. It can be any value
necessary to identify the client context or instance (such as a pointer to the client's data) instance of the client that scheduled the request.
The event handler function executes in the driver's context. It is recommended of the application to not perform process intensive or blocking
operations within this function.
Volume V: MPLAB Harmony Framework Driver Libraries Help Data EEPROM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 404
Example
void APP_MyEepromEventHandler
(
DRV_EEPROM_EVENT event,
DRV_EEPROM_COMMAND_HANDLE commandHandle,
uintptr_t context
)
{
MY_APP_DATA_STRUCT pAppData = (MY_APP_DATA_STRUCT) context;
switch(event)
{
case DRV_EEPROM_EVENT_COMMAND_COMPLETE:
// Handle the completed buffer.
break;
case DRV_EEPROM_EVENT_COMMAND_ERROR:
default:
// Handle error.
break;
}
}
Parameters
Parameters Description
event Identifies the type of event
commandHandle Handle returned from the Read or Write requests
context Value identifying the context of the application that registered the event handling function
DRV_EEPROM_INIT Structure
Defines the data required to initialize the EEPROM driver
File
drv_eeprom.h
C
typedef struct {
SYS_MODULE_INIT moduleInit;
NVM_MODULE_ID eepromId;
const SYS_FS_MEDIA_GEOMETRY * eepromMediaGeometry;
} DRV_EEPROM_INIT;
Members
Members Description
SYS_MODULE_INIT moduleInit; System module initialization
NVM_MODULE_ID eepromId; Identifies hardware module (PLIB-level) ID
const SYS_FS_MEDIA_GEOMETRY *
eepromMediaGeometry;
EEPROM Media geometry object.
Description
EEPROM Driver Initialization Data
This data type defines the data required to initialize the EEPROM driver.
Remarks
None.
Volume V: MPLAB Harmony Framework Driver Libraries Help Data EEPROM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 405
Files
Files
Name Description
drv_eeprom.h EEPROM Driver Interface Definition
drv_eeprom_config_template.h EEPROM driver configuration definitions.
Description
drv_eeprom.h
EEPROM Driver Interface Definition
Enumerations
Name Description
DRV_EEPROM_COMMAND_STATUS Specifies the status of the command for read or write requests.
DRV_EEPROM_EVENT Identifies the possible events that can result from a request.
Functions
Name Description
DRV_EEPROM_AddressGet Returns the EEPROM media start address
DRV_EEPROM_BulkErase Performs a bulk erase of the entire Data EEPROM.
DRV_EEPROM_Close Closes an opened-instance of the EEPROM driver
DRV_EEPROM_CommandStatus Gets the current status of the command.
DRV_EEPROM_Deinitialize Deinitializes the specified instance of the EEPROM driver module
DRV_EEPROM_Erase Erases blocks of data starting from the specified block address.
DRV_EEPROM_EventHandlerSet Allows a client to identify an event handling function for the driver to call back when queued
operation has completed.
DRV_EEPROM_GeometryGet Returns the geometry of the device.
DRV_EEPROM_Initialize Initializes the EEPROM instance for the specified driver index.
DRV_EEPROM_IsAttached Returns the physical attach status of the EEPROM.
DRV_EEPROM_IsWriteProtected Returns the write protect status of the EEPROM.
DRV_EEPROM_Open Opens the specified EEPROM driver instance and returns a handle to it
DRV_EEPROM_Read Reads blocks of data from the specified address in EEPROM memory.
DRV_EEPROM_Status Gets the current status of the EEPROM driver module.
DRV_EEPROM_Tasks Handles the read or write requests queued to the driver.
DRV_EEPROM_Write Writes blocks of data starting from the specified address in EEPROM memory.
Macros
Name Description
DRV_EEPROM_COMMAND_HANDLE_INVALID This value defines the EEPROM Driver's Invalid Command Handle.
DRV_EEPROM_INDEX_0 EEPROM driver index definition
Structures
Name Description
DRV_EEPROM_INIT Defines the data required to initialize the EEPROM driver
Types
Name Description
DRV_EEPROM_COMMAND_HANDLE Handle identifying commands queued in the driver.
DRV_EEPROM_EVENT_HANDLER Pointer to a EEPROM Driver Event handler function
Description
EEPROM Driver Interface Definition
The EEPROM driver provides a simple interface to manage the EEPROM Memory on Microchip microcontrollers. This file defines the interface
Volume V: MPLAB Harmony Framework Driver Libraries Help Data EEPROM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 406
definition for the EEPROM driver.
File Name
drv_eeprom.h
Company
Microchip Technology Inc.
drv_eeprom_config_template.h
EEPROM driver configuration definitions.
Macros
Name Description
DRV_EEPROM_BUFFER_OBJECT_NUMBER Selects the maximum number of buffer objects
DRV_EEPROM_CLIENTS_NUMBER Selects the maximum number of clients
DRV_EEPROM_INSTANCES_NUMBER Selects the maximum number of Driver instances that can be supported by the
dynamic driver.
DRV_EEPROM_MEDIA_SIZE Specifies the EEPROM Media size.
DRV_EEPROM_SYS_FS_REGISTER Register to use with the File system
Description
EEPROM Driver Configuration Template Header file.
This template file describes all the mandatory and optional configuration macros that are needed for building the EEPROM driver. Do not include
this file in source code.
File Name
drv_eeprom_config_template.h
Company
Microchip Technology Inc.
ENC28J60 Driver Library Help
This section provides information on the ENC28J60 Driver Library.
Introduction
This library provides a driver-level abstraction of the ENC28J60 integrated Ethernet MAC and 10Base-T PHY that can be connected to the PIC32.
The driver implements the virtual MAC driver model that the MPLAB Harmony TCP/IP Stack requires. Please see the TCP/IP Stack Library MAC
Driver Module for details.
The "Host-To-Network"_layer of a TCP/IP stack organization covers the Data Link and Physical Layers of the standard OSI stack. The Ethernet
Controller provides the Data Link or Media Access Control Layer, in addition to other functions discussed in this section.
Description
The ENC28J60 External MAC and PHY is an external module to the PIC32 that is connected through a Serial Peripheral Interface (SPI). This
driver interfaces with the SPI driver to communicate with the external device to implement a complete Ethernet node in a system.
The following are some of the key features of this module:
• Supports 10 Mbps physical-to-physical layer Ethernet data transfer
• Full-Duplex and Half-Duplex operation
• Broadcast, Multicast and Unicast packets
• Hardware flow control for both Full and Half-Duplex mode
• Fully configurable interrupts
• Configurable receive packet filtering using:
• 64-bit Hash Table
• 64-byte Pattern Match
• Magic Packet™ Filtering
• Supports Packet Payload Checksum calculation
• CRC Check
• Supports SPI interface
Volume V: MPLAB Harmony Framework Driver Libraries Help ENC28J60 Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 407
Using the Library
This topic describes the basic architecture and functionality of the software driver for the ENC28J60 stand-alone Ethernet Controller with SPI, and
is meant for advanced users or TCP/IP stack driver developers.
Description
The user of this driver is the MPLAB Harmony TCP/IP stack. This Ethernet driver is not intended as a system-wide driver that the application or
other system modules may use. It is intended for the sole use of the MPLAB Harmony TCP/IP stack and implements the virtual MAC model
required by the stack.
Interface Header File: drv_enc28j60.h
The interface to the ENC28J60 Driver Library is defined in the drv_enc28j60.h header file. Any C language source (.c) file that uses the
ENC28J60 Driver Library should include drv_enc28j60.h.
Library File: The ENC28J60 Driver Library archive (.a) file is installed with MPLAB Harmony.
Please refer to the Understanding MPLAB Harmony section for how the driver interacts with the framework.
Abstraction Model
The ENC28J60 Driver Library provides the low-level abstraction of the communications protocol to communicate to the ENC28J60 external MAC
though the SPI peripheral on the Microchip family of microcontrollers with a convenient C language interface. This topic describes how that
abstraction is modeled in the software and introduces the ENC28J60 Driver Library interface.
Description
The ENC28J60 Driver library has several different layers to it, as illustrated in the following figure. The interface layer has two main sections that
are used the most often: The Tasks function, and the TCP/IP Send and Receive functions.
The Tasks function manages the internal state machine which detects, resets, and then configures the ENC28J60 External MAC. It also handles
the monitoring of the hardware status, sending and receiving packets.
The TCP/IP Send and Receive functions interact with the RAM-based queue of packets that are queued to send and packets that have been
queued waiting for pick-up by the stack.
The main state machine does not interface directly to the SPI bus, but instead, interfaces to a virtual bus abstraction layer that allows for the
replacement of the specific underlying bus implementation.
Abstraction Model
Volume V: MPLAB Harmony Framework Driver Libraries Help ENC28J60 Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 408
Library Overview
Refer to the section Driver Overview for how the driver operates in a system.
The library interface routines are divided into various sub-sections, each sub-section addresses one of the blocks or the overall operation of the
ENC28J60 Driver Library.
Library Interface Section Description
System Interaction Functions Provides system module interfaces, device initialization, deinitialization,
reinitialization, tasks and status functions.
Data Transfer Functions Provides data transfer functions available in the configuration.
Status Functions Provides status functions.
Miscellaneous Functions Provides miscellaneous driver functions.
How the Library Works
The library provides interfaces to support the TCP/IP virtual MAC interface.
Configuring the SPI Driver
This section describes the configuration settings for the ENC28J60 Driver Library.
Description
Configuration
The ENC hardware requires a specific configuration of the SPI driver to work correctly. Inside the MHC SPI Driver configuration be sure to select:
• Run the SPI at frequencies of at least 8 MHz
• Clock mode of DRV_SPI_CLOCK_MODE_IDLE_LOW_EDGE_FALL
• Input phase of SPI_INPUT_SAMPLING_PHASE_AT_END
Recommended Settings
• Interrupt Driver mode
• Enhanced Buffer mode
• DMA mode enabled:
• DMA block transfer size of at least 1600 bytes
• Size of DMA buffer for dummy data of at least 1600 bytes
• Ensure when setting up DMA in interrupt mode that the DMA interrupts are a higher priority than the SPI Driver interrupt
Example:
/*** SPI Driver Static Allocation Options ***/
#define DRV_SPI_INSTANCES_NUMBER 1
#define DRV_SPI_CLIENTS_NUMBER 1
#define DRV_SPI_ELEMENTS_PER_QUEUE 30
/*** SPI Driver DMA Options ***/
#define DRV_SPI_DMA_TXFER_SIZE 2048
#define DRV_SPI_DMA_DUMMY_BUFFER_SIZE 2048
/* SPI Driver Instance 0 Configuration */
#define DRV_SPI_SPI_ID_IDX0 SPI_ID_1
#define DRV_SPI_TASK_MODE_IDX0 DRV_SPI_TASK_MODE_ISR
#define DRV_SPI_SPI_MODE_IDX0 DRV_SPI_MODE_MASTER
#define DRV_SPI_ALLOW_IDLE_RUN_IDX0 false
#define DRV_SPI_SPI_PROTOCOL_TYPE_IDX0 DRV_SPI_PROTOCOL_TYPE_STANDARD
#define DRV_SPI_SPI_PROTOCOL_TYPE_IDX0 DRV_SPI_PROTOCOL_TYPE_STANDARD
#define DRV_SPI_COMM_WIDTH_IDX0 SPI_COMMUNICATION_WIDTH_8BITS
#define DRV_SPI_SPI_CLOCK_IDX0 CLK_BUS_PERIPHERAL_2
#define DRV_SPI_BAUD_RATE_IDX0 13333333
#define DRV_SPI_BUFFER_TYPE_IDX0 DRV_SPI_BUFFER_TYPE_ENHANCED
#define DRV_SPI_CLOCK_MODE_IDX0 DRV_SPI_CLOCK_MODE_IDLE_LOW_EDGE_FALL
#define DRV_SPI_INPUT_PHASE_IDX0 SPI_INPUT_SAMPLING_PHASE_AT_END
#define DRV_SPI_TX_INT_SOURCE_IDX0 INT_SOURCE_SPI_1_TRANSMIT
Volume V: MPLAB Harmony Framework Driver Libraries Help ENC28J60 Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 409
#define DRV_SPI_RX_INT_SOURCE_IDX0 INT_SOURCE_SPI_1_RECEIVE
#define DRV_SPI_ERROR_INT_SOURCE_IDX0 INT_SOURCE_SPI_1_ERROR
#define DRV_SPI_INT_VECTOR_IDX0 INT_VECTOR_SPI1
#define DRV_SPI_INT_PRIORITY_IDX0 INT_PRIORITY_LEVEL1
#define DRV_SPI_INT_SUB_PRIORITY_IDX0 INT_SUBPRIORITY_LEVEL0
#define DRV_SPI_QUEUE_SIZE_IDX0 30
#define DRV_SPI_RESERVED_JOB_IDX0 1
#define DRV_SPI_TX_DMA_CHANNEL_IDX0 DMA_CHANNEL_1
#define DRV_SPI_TX_DMA_THRESHOLD_IDX0 16
#define DRV_SPI_RX_DMA_CHANNEL_IDX0 DMA_CHANNEL_0
#define DRV_SPI_RX_DMA_THRESHOLD_IDX0 16 Driver Library
Configuring the Library
Macros
Name Description
DRV_ENC28J60_CLIENT_INSTANCES Selects the maximum number of clients.
DRV_ENC28J60_INSTANCES_NUMBER Selects the maximum number of hardware instances that can be supported by the
dynamic driver.
Description
The configuration of the ENC28J60 Driver Library is based on the file sys_config.h.
This header file contains the configuration selection for the ENC28J60 Driver Library. Based on the selections made, the ENC28J60 Driver Library
may support the selected features. These configuration settings will apply to all instances of the ENC28J60 Driver Library.
This header can be placed anywhere; however, the path of this header needs to be present in the include search path for a successful build. Refer
to the Applications Help section for more details.
DRV_ENC28J60_CLIENT_INSTANCES Macro
Selects the maximum number of clients.
File
drv_enc28j60_config_template.h
C
#define DRV_ENC28J60_CLIENT_INSTANCES 1
Description
enc28j60 maximum number of clients
This definition selects the maximum number of clients that the enc28j60 driver can support at run-time.
Remarks
Mandatory definition.
DRV_ENC28J60_INSTANCES_NUMBER Macro
Selects the maximum number of hardware instances that can be supported by the dynamic driver.
File
drv_enc28j60_config_template.h
C
#define DRV_ENC28J60_INSTANCES_NUMBER 1
Description
enc28j60 hardware instance configuration
This definition selects the maximum number of hardware instances that can be supported by the dynamic driver.
Remarks
Mandatory definition.
Volume V: MPLAB Harmony Framework Driver Libraries Help ENC28J60 Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 410
Building the Library
This section lists the files that are available in the ENC28J60 Driver Library.
Description
The following three tables list and describe the header (.h) and source (.c) files that implement this library. The parent folder for these files is
/framework/driver/enc28j60.
Interface File(s)
This table lists and describes the header files that must be included (i.e., using #include) by any code that uses this library.
Source Folder Name Description
/drv_enc28j60.h This file provides the interface definitions of the ENC28J60 Driver.
Required File(s)
This table lists and describes the source and header files that must always be included in the MPLAB X IDE project to build this library.
All of the required files listed in the following table are automatically loaded into the MPLAB X IDE project by the
MHC.
Source Folder Name Description
/src/dynamic/drv_drv_enc28j60_api.c This file contains the API function
implementations.
/src/dynamic/drv_enc28j60_main_state.c This file contains the main state machine
functions.
/src/dynamic/drv_enc28j60_utils.c This file contains functions that are used
throughout the driver.
/src/dynamic/bus/spi/drv_enc28j60_spi_bus.c This file contains the functions to interface with
the SPI bus.
/src/dynamic/closed_state/drv_enc28j60_closed_state.c This file contains the functions for handling the
driver closed state.
/src/dynamic/initialization_state/drv_enc28j60_configure_state.c This file contains the functions for configuring the
ENC hardware.
/src/dynamic/initialization_state/drv_enc28j60_detect_state.c This file contains the functions for detecting the
ENC hardware.
/src/dynamic/initialization_state/drv_enc28j60_initialization_state.c This file contains the functions for the initialization
state machine.
/src/dynamic/initialization_state/drv_enc28j60_reset_state.c This file contains the functions for resetting the
ENC hardware.
/src/dynamic/packet/drv_enc28j60_rx_packet.c This file contains the functions for receiving a
packet from the ENC hardware.
/src/dynamic/packet/drv_enc28j60_tx_packet.c This file contains the functions for sending a
packet to the ENC hardware.
/src/dynamic/running_state/drv_enc28j60_change_duplex_state.c This file contains the functions for configuring the
duplex mode of the ENC hardware.
/src/dynamic/running_state/drv_enc28j60_check_int_state.c This file contains the functions for checking and
processing the ENC hardware interrupts.
/src/dynamic/running_state/drv_enc28j60_check_status_state.c This file contains the functions for checking the
status of the ENC hardware.
/src/dynamic/running_state/drv_enc28j60_check_tx_status_state.c This file contains the functions for checking the
status of a transmitted packet.
/src/dynamic/running_state/drv_enc28j60_running_state.c This file contains the functions for managing the
running state machine.
/src/dynamic/running_state/drv_enc28j60_reset_rx_state.c This file contains the functions for managing the
RX state machine reset requirement during
run-time.
Volume V: MPLAB Harmony Framework Driver Libraries Help ENC28J60 Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 411
Optional File(s)
This table lists and describes the source and header files that may optionally be included if required for the desired implementation.
Source Folder Name Description
N/A No optional files exist for this library.
Module Dependencies
The ENC28J60 Driver Library depends on the following modules:
• SPI Driver Library
• TCP/IP Stack Library
• TCP/IP Stack MAC Driver Module
Library Interface
a) System Interaction Functions
Name Description
DRV_ENC28J60_Deinitialize Deinitializes the ENC28J60 Driver Instance.
Implementation: Dynamic
DRV_ENC28J60_Initialize Initializes the ENC28J60 Driver Instance, with the configuration data.
Implementation: Dynamic
DRV_ENC28J60_Process Additional processing that happens outside the tasks function.
Implementation: Dynamic
DRV_ENC28J60_Reinitialize Reinitializes the instance of the ENC28J60 driver.
Implementation: Dynamic
DRV_ENC28J60_SetMacCtrlInfo This function sets the MAC control information for the driver.
Implementation: Dynamic
DRV_ENC28J60_StackInitialize This function initializes the driver with a TCPIP_MAC_INIT object.
Implementation: Dynamic
DRV_ENC28J60_Tasks Main task function for the driver.
Implementation: Dynamic
b) Client Level Functions
Name Description
DRV_ENC28J60_Close Closes a client handle to the driver.
Implementation: Dynamic
DRV_ENC28J60_ConfigGet Gets the current configuration.
Implementation: Dynamic
DRV_ENC28J60_LinkCheck This function returns the status of the link.
Implementation: Dynamic
DRV_ENC28J60_Open This function is called by the client to open a handle to a driver instance.
Implementation: Dynamic
DRV_ENC28J60_ParametersGet Get the parameters of the device.
Implementation: Dynamic
DRV_ENC28J60_PowerMode This function sets the power mode of the device.
Implementation: Dynamic
DRV_ENC28J60_RegisterStatisticsGet Get the register statistics.
Implementation: Dynamic
DRV_ENC28J60_StatisticsGet Retrieve the devices statistics.
Implementation: Dynamic
DRV_ENC28J60_Status Gets the current status of the driver.
Implementation: Dynamic
c) Receive Functions
Name Description
DRV_ENC28J60_PacketRx Receive a packet from the driver.
Implementation: Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help ENC28J60 Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 412
DRV_ENC28J60_RxFilterHashTableEntrySet This function adds an entry to the hash table.
Implementation: Dynamic
d) Transmit Functions
Name Description
DRV_ENC28J60_PacketTx This function queues a packet for transmission.
Implementation: Dynamic
e) Event Functions
Name Description
DRV_ENC28J60_EventAcknowledge Acknowledges an event.
Implementation: Dynamic
DRV_ENC28J60_EventMaskSet Sets the event mask.
Implementation: Dynamic
DRV_ENC28J60_EventPendingGet Gets the current events.
Implementation: Dynamic
f) Data Types and Constants
Name Description
_DRV_ENC28J60_Configuration Defines the data required to initialize or reinitialize the ENC28J60 Driver.
DRV_ENC28J60_Configuration Defines the data required to initialize or reinitialize the ENC28J60 Driver.
DRV_ENC28J60_MDIX_TYPE Defines the enumeration for controlling the MDIX select.
DRV_ENC28J60_MACObject ENC28J60 External MAC Virtualization Table
Description
This section describes the Application Programming Interface (API) functions of the ENC28J60 Driver Library.
Refer to each section for a detailed description.
a) System Interaction Functions
DRV_ENC28J60_Deinitialize Function
Deinitializes the ENC28J60 Driver Instance.
Implementation: Dynamic
File
drv_enc28j60.h
C
void DRV_ENC28J60_Deinitialize(SYS_MODULE_OBJ object);
Returns
None.
Description
ENC28J60 Deinitialization
This function deallocates any resources allocated by the initialization function.
Preconditions
The driver had to be successfully initialized with DRV_ENC28J60_Initialize.
Parameters
Parameters Description
Object the valid object returned from DRV_ENC28J60_Initialize
Volume V: MPLAB Harmony Framework Driver Libraries Help ENC28J60 Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 413
DRV_ENC28J60_Initialize Function
Initializes the ENC28J60 Driver Instance, with the configuration data.
Implementation: Dynamic
File
drv_enc28j60.h
C
SYS_MODULE_OBJ DRV_ENC28J60_Initialize(SYS_MODULE_INDEX index, SYS_MODULE_INIT * init);
Returns
• Valid handle to the driver instance - If successful
• SYS_MODULE_OBJ_INVALID - If unsuccessful
Description
ENC28J60 Initialization
This function initializes the ENC28J60 Driver with configuration data passed into it by either the system_init function or by the
DRV_ENC28J60_StackInitialize function. Calling this function alone is not enough to initialize the driver, DRV_ENC28J60_SetMacCtrlInfo must be
called with valid data before the driver is ready to be opened.
Preconditions
None.
Parameters
Parameters Description
index This is the index of the driver instance to be initialized. The definition
DRV_ENC28J60_NUM_DRV_INSTANCES controls how many instances are available.
init This is a pointer to a DRV_ENC28J60_CONFIG structure.
DRV_ENC28J60_Process Function
Additional processing that happens outside the tasks function.
Implementation: Dynamic
File
drv_enc28j60.h
C
TCPIP_MAC_RES DRV_ENC28J60_Process(DRV_HANDLE hMac);
Returns
• TCPIP_MAC_RES_TYPE_ERR - if the hMac is invalid
• TCPIP_MAC_RES_OP_ERR - if the hMac is valid
Description
ENC28J60 Process
This function does additional processing that is not done inside the tasks function.
Remarks
This function does nothing in the first release.
Preconditions
The client had to be successfully opened with DRV_ENC28J60_Open.
Parameters
Parameters Description
hMac the successfully opened handle
Volume V: MPLAB Harmony Framework Driver Libraries Help ENC28J60 Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 414
DRV_ENC28J60_Reinitialize Function
Reinitializes the instance of the ENC28J60 driver.
Implementation: Dynamic
File
drv_enc28j60.h
C
void DRV_ENC28J60_Reinitialize(SYS_MODULE_OBJ object, const SYS_MODULE_INIT * const init);
Returns
None
Description
ENC28J60 Reinitialization
This function will deinitialize and initialize the driver instance. As with DRV_ENC28J60_Initialize DRV_ENC28J60_SetMacCtrlInfo must be called
for the driver to be useful.
Remarks
This function is not planned to be implemented for the first release.
Preconditions
The driver had to be successfully initialized with DRV_ENC28J60_Initialize.
DRV_ENC28J60_SetMacCtrlInfo Function
This function sets the MAC control information for the driver.
Implementation: Dynamic
File
drv_enc28j60.h
C
void DRV_ENC28J60_SetMacCtrlInfo(SYS_MODULE_OBJ object, TCPIP_MAC_MODULE_CTRL * init);
Returns
None.
Description
ENC28J60 Set MAC Control Information
This function is used to pass in the TCPIP_MAC_CONTROL_INIT information that is used for allocation and deallocation of memory, event
signaling, etc. This function is needed to be called so that the driver can enter initialization state when the tasks function is called.
Preconditions
The driver had to be successfully initialized with ENC28J60_Initialize.
DRV_ENC28J60_StackInitialize Function
This function initializes the driver with a TCPIP_MAC_INIT object.
Implementation: Dynamic
File
drv_enc28j60.h
C
SYS_MODULE_OBJ DRV_ENC28J60_StackInitialize(SYS_MODULE_INDEX index, const SYS_MODULE_INIT * const init);
Returns
Returns a valid handle to the driver instance - If successful SYS_MODULE_OBJ_INVALID - If unsuccessful
Volume V: MPLAB Harmony Framework Driver Libraries Help ENC28J60 Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 415
Description
ENC28J60 Stack Initialization
This function is used by the TCP/IP stack to fully initialize the driver with both the ENC28J60 specific configuration and the MAC control
information. With this function there is no need to call DRV_ENC28J60_SetMacCtrlInfo.
Preconditions
None.
Parameters
Parameters Description
index This is the index of the driver instance to be initialized. The definition
DRV_ENC28J60_NUM_DRV_INSTANCES controls how many instances are available.
init This is a pointer to a TCPIP_MAC_INIT structure.
DRV_ENC28J60_Tasks Function
Main task function for the driver.
Implementation: Dynamic
File
drv_enc28j60.h
C
void DRV_ENC28J60_Tasks(SYS_MODULE_OBJ object);
Returns
None.
Description
ENC28J60 Tasks
This function will execute the main state machine for the ENC28J60 driver.
Preconditions
The driver had to be successfully initialized with DRV_ENC28J60_Initialize.
Parameters
Parameters Description
object The object valid passed back to DRV_ENC28J60_Initialize
b) Client Level Functions
DRV_ENC28J60_Close Function
Closes a client handle to the driver.
Implementation: Dynamic
File
drv_enc28j60.h
C
void DRV_ENC28J60_Close(DRV_HANDLE handle);
Returns
None.
Description
ENC28J60 Close
This function closes a handle to the driver. If it is the last client open, the driver will send an RX Disable command to the ENC hardware and move
Volume V: MPLAB Harmony Framework Driver Libraries Help ENC28J60 Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 416
to the closed state.
Preconditions
The client had to be successfully opened with DRV_ENC28J60_Open.
Parameters
Parameters Description
handle The successfully opened handle
DRV_ENC28J60_ConfigGet Function
Gets the current configuration.
Implementation: Dynamic
File
drv_enc28j60.h
C
size_t DRV_ENC28J60_ConfigGet(DRV_HANDLE hMac, void* configBuff, size_t buffSize, size_t* pConfigSize);
Returns
Number of bytes copied to the buffer
Description
ENC28J60 Get Configuration
Gets the current configuration.
Remarks
This function does nothing in the first release.
Preconditions
The client had to be successfully opened with DRV_ENC28J60_Open.
Parameters
Parameters Description
hMac the successfully opened handle
configBuff location to copy the configuration too
buffSize buffer size
pConfigSize configuration size needed
DRV_ENC28J60_LinkCheck Function
This function returns the status of the link.
Implementation: Dynamic
File
drv_enc28j60.h
C
bool DRV_ENC28J60_LinkCheck(DRV_HANDLE hMac);
Returns
• true - if the link is active
• false - all other times
Description
ENC28J60 Link Check
This function checks the status of the link and returns it to the caller.
Volume V: MPLAB Harmony Framework Driver Libraries Help ENC28J60 Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 417
Preconditions
The client had to be successfully opened with DRV_ENC28J60_Open.
Parameters
Parameters Description
hMac the successfully opened handle
DRV_ENC28J60_Open Function
This function is called by the client to open a handle to a driver instance.
Implementation: Dynamic
File
drv_enc28j60.h
C
DRV_HANDLE DRV_ENC28J60_Open(SYS_MODULE_INDEX index, DRV_IO_INTENT intent);
Returns
Returns a valid handle - If successful INVALID_HANDLE - If unsuccessful
Description
ENC28J60 Open
The client will call this function to open a handle to the driver. When the first instance is opened than the driver will send the RX enabled command
to the ENC hardware.
Preconditions
The driver had to be successfully initialized with DRV_ENC28J60_Initialize.
Parameters
Parameters Description
index This is the index of the driver instance to be initialized. The definition
DRV_ENC28J60_NUM_DRV_INSTANCES controls how many instances are available.
intent The intent to use when opening the driver. Only exclusive is supported
DRV_ENC28J60_ParametersGet Function
Get the parameters of the device.
Implementation: Dynamic
File
drv_enc28j60.h
C
TCPIP_MAC_RES DRV_ENC28J60_ParametersGet(DRV_HANDLE hMac, TCPIP_MAC_PARAMETERS* pMacParams);
Returns
• TCPIP_MAC_RES_TYPE_ERR - if the hMac is invalid
• TCPIP_MAC_RES_OK - if the hMac is valid
Description
ENC28J60 Get Parameters
Get the parameters of the device, which includes that it is an Ethernet device and what it's MAC address is. Users of the ENC28J60 must generate
a unique MAC address for each controller used.
The client had to be successfully opened with DRV_ENC28J60_Open.
Parameters
Parameters Description
hMac the successfully opened handle
Volume V: MPLAB Harmony Framework Driver Libraries Help ENC28J60 Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 418
pMacParams pointer to put the parameters
DRV_ENC28J60_PowerMode Function
This function sets the power mode of the device.
Implementation: Dynamic
File
drv_enc28j60.h
C
bool DRV_ENC28J60_PowerMode(DRV_HANDLE hMac, TCPIP_MAC_POWER_MODE pwrMode);
Returns
• false - This functionality is not supported in this version of the driver
Description
ENC28J60 Power Mode
This function sets the power mode of the ENC28J60.
Remarks
This functionality is not implemented in the first release.
Preconditions
The client had to be successfully opened with DRV_ENC28J60_Open.
Parameters
Parameters Description
hMac the successfully opened handle
pwrMode the power mode to set
DRV_ENC28J60_RegisterStatisticsGet Function
Get the register statistics.
Implementation: Dynamic
File
drv_enc28j60.h
C
TCPIP_MAC_RES DRV_ENC28J60_RegisterStatisticsGet(DRV_HANDLE hMac, TCPIP_MAC_STATISTICS_REG_ENTRY*
pRegEntries, int nEntries, int* pHwEntries);
Returns
• TCPIP_MAC_RES_TYPE_ERR - if the hMac is invalid
• TCPIP_MAC_RES_OP_ERR - if the hMac is valid
Description
ENC28J60 Get Register Statistics
Get the device specific statistics.
Remarks
Statistics are not planned for the first release
Preconditions
The client had to be successfully opened with DRV_ENC28J60_Open.
Parameters
Parameters Description
hMac the successfully opened handle
Volume V: MPLAB Harmony Framework Driver Libraries Help ENC28J60 Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 419
pRegEntries
nEntries
pHwEntries
DRV_ENC28J60_StatisticsGet Function
Retrieve the devices statistics.
Implementation: Dynamic
File
drv_enc28j60.h
C
TCPIP_MAC_RES DRV_ENC28J60_StatisticsGet(DRV_HANDLE hMac, TCPIP_MAC_RX_STATISTICS* pRxStatistics,
TCPIP_MAC_TX_STATISTICS* pTxStatistics);
Returns
• TCPIP_MAC_RES_TYPE_ERR - if the hMac is invalid
• TCPIP_MAC_RES_OP_ERR - if the hMac is valid
Description
ENC28J60 Get Statistics
Get the current statistics stored in the driver.
Remarks
Statistics are not planned for the first release.
Preconditions
The client had to be successfully opened with DRV_ENC28J60_Open.
Parameters
Parameters Description
hMac the successfully opened handle
DRV_ENC28J60_Status Function
Gets the current status of the driver.
Implementation: Dynamic
File
drv_enc28j60.h
C
SYS_STATUS DRV_ENC28J60_Status(SYS_MODULE_OBJ obect);
Returns
• SYS_STATUS_ERROR - if an invalid handle has been passed in
• SYS_STATUS_UNINITIALIZED - if the driver has not completed initialization
• SYS_STATUS_BUSY - if the driver is closing and moving to the closed state
• SYS_STATUS_READY - if the driver is ready for client commands
Description
ENC28J60 Status
This function will get the status of the driver instance.
Preconditions
The driver had to be successfully initialized with DRV_ENC28J60_Initialize().
Volume V: MPLAB Harmony Framework Driver Libraries Help ENC28J60 Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 420
Parameters
Parameters Description
object The object valid passed back to DRV_ENC28J60_Initialize()
c) Receive Functions
DRV_ENC28J60_PacketRx Function
Receive a packet from the driver.
Implementation: Dynamic
File
drv_enc28j60.h
C
TCPIP_MAC_PACKET* DRV_ENC28J60_PacketRx(DRV_HANDLE hMac, TCPIP_MAC_RES* pRes, const
TCPIP_MAC_PACKET_RX_STAT** ppPktStat);
Returns
• Pointer to a valid packet - if successful
• NULL - if unsuccessful
Description
ENC28J60 Receive Packet
This function retrieves a packet from the driver. The packet needs to be acknowledged with the linked acknowledge function so it can be reused.
Remarks
ppPktStat is ignored in the first release.
Preconditions
The client had to be successfully opened with DRV_ENC28J60_Open.
Parameters
Parameters Description
hMac the successfully opened handle
pRes the result of the operation
ppPktStat pointer to the receive statistics
DRV_ENC28J60_RxFilterHashTableEntrySet Function
This function adds an entry to the hash table.
Implementation: Dynamic
File
drv_enc28j60.h
C
TCPIP_MAC_RES DRV_ENC28J60_RxFilterHashTableEntrySet(DRV_HANDLE hMac, const TCPIP_MAC_ADDR* DestMACAddr);
Returns
• TCPIP_MAC_RES_TYPE_ERR - if the hMac is invalid
• TCPIP_MAC_RES_OP_ERR - if the hMac is valid
Description
ENC28J60 Receive Filter Hash Table Entry Set
This function adds to the MAC's hash table for hash table matching.
Volume V: MPLAB Harmony Framework Driver Libraries Help ENC28J60 Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 421
Remarks
This functionality is not implemented in the first release.
Preconditions
The client had to be successfully opened with DRV_ENC28J60_Open.
Parameters
Parameters Description
hMac the successfully opened handle
DestMACAddr MAC address to add to the hash table
d) Transmit Functions
DRV_ENC28J60_PacketTx Function
This function queues a packet for transmission.
Implementation: Dynamic
File
drv_enc28j60.h
C
TCPIP_MAC_RES DRV_ENC28J60_PacketTx(DRV_HANDLE hMac, TCPIP_MAC_PACKET * ptrPacket);
Returns
• TCPIP_MAC_RES_OP_ERR - if the client handle is invalid
• TCPIP_MAC_RES_IS_BUSY - if the driver is not in the run state
• TCPIP_MAC_RES_QUEUE_TX_FULL - if there are no free descriptors
• TCPIP_MAC_RES_OK - on successful queuing of the packet
Description
ENC28J60 Packet Transmit
This function will take a packet and add it to the queue for transmission. When the packet has finished transmitting the driver will call the packets
acknowledge function. When that acknowledge function is complete the driver will forget about the packet.
Preconditions
The client had to be successfully opened with DRV_ENC28J60_Open.
Parameters
Parameters Description
hMac the successfully opened handle
ptrPacket pointer to the packet
e) Event Functions
DRV_ENC28J60_EventAcknowledge Function
Acknowledges an event.
Implementation: Dynamic
File
drv_enc28j60.h
C
bool DRV_ENC28J60_EventAcknowledge(DRV_HANDLE hMac, TCPIP_MAC_EVENT macEvents);
Volume V: MPLAB Harmony Framework Driver Libraries Help ENC28J60 Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 422
Returns
• true - if successful
• false - if not successful
Description
ENC28J60 Acknowledge Event
This function acknowledges an event.
Preconditions
The client had to be successfully opened with DRV_ENC28J60_Open.
Parameters
Parameters Description
hMac the successfully opened handle
macEvents the events to acknowledge
DRV_ENC28J60_EventMaskSet Function
Sets the event mask.
Implementation: Dynamic
File
drv_enc28j60.h
C
bool DRV_ENC28J60_EventMaskSet(DRV_HANDLE hMac, TCPIP_MAC_EVENT macEvents, bool enable);
Returns
• true - if the mask could be set
• false - if the mast could not be set
Description
ENC28J60 Set Event Mask
Sets the event mask to what is passed in.
Preconditions
The client had to be successfully opened with DRV_ENC28J60_Open.
Parameters
Parameters Description
hMac the successfully opened handle
macEvents the mask to enable or disable
enable to enable or disable events
DRV_ENC28J60_EventPendingGet Function
Gets the current events.
Implementation: Dynamic
File
drv_enc28j60.h
C
TCPIP_MAC_EVENT DRV_ENC28J60_EventPendingGet(DRV_HANDLE hMac);
Returns
• TCPIP_MAC_EV_NONE - Returned on an error
• List of events - Returned on event other than an error
Volume V: MPLAB Harmony Framework Driver Libraries Help ENC28J60 Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 423
Description
ENC28J60 Get Events
This function gets the current events.
Preconditions
The client had to be successfully opened with DRV_ENC28J60_Open.
Parameters
Parameters Description
hMac the successfully opened handle
f) Data Types and Constants
DRV_ENC28J60_Configuration Structure
Defines the data required to initialize or reinitialize the ENC28J60 Driver.
File
drv_enc28j60.h
C
typedef struct _DRV_ENC28J60_Configuration {
uint16_t txDescriptors;
uint16_t rxDescriptors;
uint16_t rxDescBufferSize;
SYS_MODULE_INDEX spiDrvIndex;
uint32_t spiBps;
uint16_t rxBufferSize;
uint16_t maxFrameSize;
PORTS_MODULE_ID spiSSPortModule;
PORTS_CHANNEL spiSSPortChannel;
PORTS_BIT_POS spiSSPortPin;
bool intEnable;
PORTS_MODULE_ID intPortModule;
PORTS_CHANNEL intPortChannel;
PORTS_BIT_POS intPortPin;
DRV_ENC28J60_MDIX_TYPE mdixControl;
PORTS_MODULE_ID mdixPortModule;
PORTS_CHANNEL mdixPortChannel;
PORTS_BIT_POS mdixPortPin;
} DRV_ENC28J60_Configuration;
Members
Members Description
uint16_t txDescriptors; Number of TX Descriptors to Allocate
uint16_t rxDescriptors; Number of RX Descriptors to Allocate
uint16_t rxDescBufferSize; Size of the buffer each RX Descriptor will use. Make sure its not smaller than maxFrameSize
SYS_MODULE_INDEX spiDrvIndex; Index of the SPI driver to use
uint32_t spiBps; Bus speed to use for the SPI interface. Section 1.0 of the ENC28J60 data sheets says the
maximum is 20000000 Hz. It is not recommended to go above this value.
uint16_t rxBufferSize; The ENC28J60 hardware has a 8 k dram. rxBufferSize defines how much of that memory is
used by the rxBuffer
uint16_t maxFrameSize; The maximum frame size to be supported by the hardware. 1536 is the default
PORTS_MODULE_ID spiSSPortModule; Port Module of the GPIO pin hooked up to the CS/SS pin of the ENC28J60
PORTS_CHANNEL spiSSPortChannel; Port Channel of the GPIO pin hooked up to the CS/SS pin of the ENC28J60
PORTS_BIT_POS spiSSPortPin; Pin position of the GPIO pin hooked up to the CS/SS pin of the ENC28J60
bool intEnable; Use Interrupts or not.
PORTS_MODULE_ID intPortModule; Port Module of the GPIO pin hooked up to the INT pin of the ENC28J60
PORTS_CHANNEL intPortChannel; Port Channel of the GPIO pin hooked up to the INT pin of the ENC28J60
PORTS_BIT_POS intPortPin; Pin Position of the GPIO pin hooked up to the INT pin of the ENC28J60
Volume V: MPLAB Harmony Framework Driver Libraries Help ENC28J60 Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 424
DRV_ENC28J60_MDIX_TYPE mdixControl; To select the control type of the MDIX. This is only needed for hooking up to switches that
don't have auto-mdix.
PORTS_MODULE_ID mdixPortModule; Port Module of the GPIO pin hooked up to the MDIX select pin
PORTS_CHANNEL mdixPortChannel; Port Channel of the GPIO pin hooked up to the MDIX select pin
PORTS_BIT_POS mdixPortPin; Pin Position of the GPIO pin hooked up to the MDIX select pin
Description
ENC28J60 Driver Initialization Data
This data type defines the data required to initialize or reinitialize the ENC28J60 driver. If the driver is built statically, the members of this data
structure are statically over-ridden by static override definitions in the system_config.h file.
Remarks
None.
DRV_ENC28J60_MDIX_TYPE Enumeration
Defines the enumeration for controlling the MDIX select.
File
drv_enc28j60.h
C
typedef enum {
DRV_ENC28J60_NO_CONTROL = 0,
DRV_ENC28J60_NORMAL,
DRV_ENC28J60_REVERSE = 0
} DRV_ENC28J60_MDIX_TYPE;
Members
Members Description
DRV_ENC28J60_NO_CONTROL = 0 No Control
DRV_ENC28J60_NORMAL Normal MDIX
DRV_ENC28J60_REVERSE = 0 Reverse MDIX
Description
ENC28J60 Driver MDIX Control type
This type defines the enumeration for controlling the MDIX select.
Remarks
None.
DRV_ENC28J60_MACObject Variable
File
drv_enc28j60.h
C
const TCPIP_MAC_OBJECT DRV_ENC28J60_MACObject;
Description
ENC28J60 External MAC Virtualization Table
Files
Files
Name Description
drv_enc28j60.h ENC28J60 Driver interface definition.
drv_enc28j60_config_template.h enc28j60 Driver configuration definitions template.
Volume V: MPLAB Harmony Framework Driver Libraries Help ENC28J60 Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 425
Description
drv_enc28j60.h
ENC28J60 Driver interface definition.
Enumerations
Name Description
DRV_ENC28J60_MDIX_TYPE Defines the enumeration for controlling the MDIX select.
Functions
Name Description
DRV_ENC28J60_Close Closes a client handle to the driver.
Implementation: Dynamic
DRV_ENC28J60_ConfigGet Gets the current configuration.
Implementation: Dynamic
DRV_ENC28J60_Deinitialize Deinitializes the ENC28J60 Driver Instance.
Implementation: Dynamic
DRV_ENC28J60_EventAcknowledge Acknowledges an event.
Implementation: Dynamic
DRV_ENC28J60_EventMaskSet Sets the event mask.
Implementation: Dynamic
DRV_ENC28J60_EventPendingGet Gets the current events.
Implementation: Dynamic
DRV_ENC28J60_Initialize Initializes the ENC28J60 Driver Instance, with the configuration data.
Implementation: Dynamic
DRV_ENC28J60_LinkCheck This function returns the status of the link.
Implementation: Dynamic
DRV_ENC28J60_Open This function is called by the client to open a handle to a driver instance.
Implementation: Dynamic
DRV_ENC28J60_PacketRx Receive a packet from the driver.
Implementation: Dynamic
DRV_ENC28J60_PacketTx This function queues a packet for transmission.
Implementation: Dynamic
DRV_ENC28J60_ParametersGet Get the parameters of the device.
Implementation: Dynamic
DRV_ENC28J60_PowerMode This function sets the power mode of the device.
Implementation: Dynamic
DRV_ENC28J60_Process Additional processing that happens outside the tasks function.
Implementation: Dynamic
DRV_ENC28J60_RegisterStatisticsGet Get the register statistics.
Implementation: Dynamic
DRV_ENC28J60_Reinitialize Reinitializes the instance of the ENC28J60 driver.
Implementation: Dynamic
DRV_ENC28J60_RxFilterHashTableEntrySet This function adds an entry to the hash table.
Implementation: Dynamic
DRV_ENC28J60_SetMacCtrlInfo This function sets the MAC control information for the driver.
Implementation: Dynamic
DRV_ENC28J60_StackInitialize This function initializes the driver with a TCPIP_MAC_INIT object.
Implementation: Dynamic
DRV_ENC28J60_StatisticsGet Retrieve the devices statistics.
Implementation: Dynamic
DRV_ENC28J60_Status Gets the current status of the driver.
Implementation: Dynamic
DRV_ENC28J60_Tasks Main task function for the driver.
Implementation: Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help ENC28J60 Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 426
Structures
Name Description
_DRV_ENC28J60_Configuration Defines the data required to initialize or reinitialize the ENC28J60 Driver.
DRV_ENC28J60_Configuration Defines the data required to initialize or reinitialize the ENC28J60 Driver.
Variables
Name Description
DRV_ENC28J60_MACObject ENC28J60 External MAC Virtualization Table
Description
ENC28J60 Driver Public Interface
This file defines the interface definition for the ENC28J60 Driver.
File Name
drv_enc28j60.h
Company
Microchip Technology Inc.
drv_enc28j60_config_template.h
enc28j60 Driver configuration definitions template.
Macros
Name Description
DRV_ENC28J60_CLIENT_INSTANCES Selects the maximum number of clients.
DRV_ENC28J60_INSTANCES_NUMBER Selects the maximum number of hardware instances that can be supported by the
dynamic driver.
Description
enc28j60 Driver Configuration Definitions for the Template Version
These definitions statically define the driver's mode of operation.
File Name
drv_enc28j60_config_template.h
Company
Microchip Technology Inc.
ENCx24J600 Driver Library Help
This section provides information on the ENCx24J600 Driver Library.
Introduction
This library provides a driver-level abstraction of the ENCx24J600 Ethernet MAC that can be connected to the PIC32. The driver implements the
virtual MAC driver model that the MPLAB Harmony TCP/IP Stack requires. Please see the TCP/IP Stack Library MAC Driver Module for details.
The "Host-To-Network"_layer of a TCP/IP stack organization covers the Data Link and Physical Layers of the standard OSI stack. The Ethernet
Controller provides the Data Link or Media Access Control Layer, in addition to other functions discussed in this section.
Description
The ENCx24J600 External MAC is an external module to the PIC32 that is connected through a SPI or PSP interface. This driver interfaces with
the SPI driver to communicate with the external device to implement a complete Ethernet node in a system.
The following are some of the key features of this module:
• Supports 10/100 Ethernet
• Full-Duplex and Half-Duplex operation
• Broadcast, Multicast and Unicast packets
• Manual and automatic flow control
• Supports Auto-MDIX
Volume V: MPLAB Harmony Framework Driver Libraries Help ENCx24J600 Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 427
• Fully configurable interrupts
• Configurable receive packet filtering using:
• 64-bit Hash Table
• 64-byte Pattern Match
• Magic Packet™ Filtering
• Runt Packet Detection and Filtering
• Supports Packet Payload Checksum calculation
• CRC Check
• Supports SPI interface
Using the Library
This topic describes the basic architecture and functionality of the Ethernet MAC driver and is meant for advanced users or TCP/IP stack driver
developers.
Description
The user of this driver is the MPLAB Harmony TCP/IP stack. This Ethernet driver is not intended as a system-wide driver that the application or
other system modules may use. It is intended for the sole use of the MPLAB Harmony TCP/IP stack and implements the virtual MAC model
required by the stack.
Interface Header File: drv_encx24j600.h
The interface to the ENCx24J600 Driver Library is defined in the drv_encx24j600.h header file. Any C language source (.c) file that uses the
ENCx24J600 Driver Library should include drv_encx24j600.h.
Library File: The ENCx24J600 Driver Library archive (.a) file is installed with MPLAB Harmony.
Please refer to the What is MPLAB Harmony? section for how the driver interacts with the framework.
Abstraction Model
The ENCx24J600 Driver Library provides the low-level abstraction of the communications protocol to communicate to the ENCx24J600 external
MAC though the SPI peripheral on the Microchip family of microcontrollers with a convenient C language interface. This topic describes how that
abstraction is modeled in the software and introduces the ENCx24J600 Driver Library interface.
Description
The ENCx24J600 Driver library has several different layers to it, as illustrated in the following figure. The interface layer has two main sections that
are used the most often: The Tasks function, and the TCP/IP Send and Receive functions.
The Tasks function manages the internal state machine which detects, resets, and then configures the ENCx24J600 External MAC. It also handles
the monitoring of the hardware status, sending and receiving packets.
The TCP/IP Send and Receive functions interact with the RAM-based queue of packets that are queued to send and packets that have been
queued waiting for pick-up by the stack.
The main state machine does not interface directly to the SPI bus, but instead, interfaces to a virtual bus abstraction layer that allows for the
replacement of the specific underlying bus implementation.
Abstraction Model
Volume V: MPLAB Harmony Framework Driver Libraries Help ENCx24J600 Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 428
Library Overview
Refer to the section Driver Overview for how the driver operates in a system.
The library interface routines are divided into various sub-sections, each sub-section addresses one of the blocks or the overall operation of the
ENCx24J600 Driver Library.
Library Interface Section Description
System Interaction Functions Provides system module interfaces, device initialization, deinitialization,
reinitialization, tasks and status functions.
Data Transfer Functions Provides data transfer functions available in the configuration.
Status Functions Provides status functions.
Miscellaneous Functions Provides miscellaneous driver functions.
How the Library Works
The library provides interfaces to support the TCP/IP virtual MAC interface.
Configuring the SPI Driver
This section describes the configuration settings for the ENCx24J600 Driver Library.
Description
Configuration
The ENC hardware requires a specific configuration of the SPI driver to work correctly. Inside the MHC SPI Driver configuration be sure to select:
• SPI clock rate of 14000000 or less. With a PB clock of 80 MHz, 13333333 is the clock rate.
• Clock mode of DRV_SPI_CLOCK_MODE_IDLE_LOW_EDGE_FALL
• Input phase of SPI_INPUT_SAMPLING_PHASE_AT_END
Volume V: MPLAB Harmony Framework Driver Libraries Help ENCx24J600 Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 429
Recommended Settings
• Interrupt Driver mode
• Enhanced Buffer mode
• DMA mode enabled:
• DMA block transfer size of at least 1600 bytes
• Size of DMA buffer for dummy data of at least 1600 bytes
• Ensure when setting up DMA in interrupt mode that the DMA interrupts are a higher priority than the SPI Driver interrupt
Example:
/*** SPI Driver Static Allocation Options ***/
#define DRV_SPI_INSTANCES_NUMBER 1
#define DRV_SPI_CLIENTS_NUMBER 1
#define DRV_SPI_ELEMENTS_PER_QUEUE 30
/*** SPI Driver DMA Options ***/
#define DRV_SPI_DMA_TXFER_SIZE 2048
#define DRV_SPI_DMA_DUMMY_BUFFER_SIZE 2048
/* SPI Driver Instance 0 Configuration */
#define DRV_SPI_SPI_ID_IDX0 SPI_ID_1
#define DRV_SPI_TASK_MODE_IDX0 DRV_SPI_TASK_MODE_ISR
#define DRV_SPI_SPI_MODE_IDX0 DRV_SPI_MODE_MASTER
#define DRV_SPI_ALLOW_IDLE_RUN_IDX0 false
#define DRV_SPI_SPI_PROTOCOL_TYPE_IDX0 DRV_SPI_PROTOCOL_TYPE_STANDARD
#define DRV_SPI_SPI_PROTOCOL_TYPE_IDX0 DRV_SPI_PROTOCOL_TYPE_STANDARD
#define DRV_SPI_COMM_WIDTH_IDX0 SPI_COMMUNICATION_WIDTH_8BITS
#define DRV_SPI_SPI_CLOCK_IDX0 CLK_BUS_PERIPHERAL_2
#define DRV_SPI_BAUD_RATE_IDX0 13333333
#define DRV_SPI_BUFFER_TYPE_IDX0 DRV_SPI_BUFFER_TYPE_ENHANCED
#define DRV_SPI_CLOCK_MODE_IDX0 DRV_SPI_CLOCK_MODE_IDLE_LOW_EDGE_FALL
#define DRV_SPI_INPUT_PHASE_IDX0 SPI_INPUT_SAMPLING_PHASE_AT_END
#define DRV_SPI_TX_INT_SOURCE_IDX0 INT_SOURCE_SPI_1_TRANSMIT
#define DRV_SPI_RX_INT_SOURCE_IDX0 INT_SOURCE_SPI_1_RECEIVE
#define DRV_SPI_ERROR_INT_SOURCE_IDX0 INT_SOURCE_SPI_1_ERROR
#define DRV_SPI_INT_VECTOR_IDX0 INT_VECTOR_SPI1
#define DRV_SPI_INT_PRIORITY_IDX0 INT_PRIORITY_LEVEL1
#define DRV_SPI_INT_SUB_PRIORITY_IDX0 INT_SUBPRIORITY_LEVEL0
#define DRV_SPI_QUEUE_SIZE_IDX0 30
#define DRV_SPI_RESERVED_JOB_IDX0 1
#define DRV_SPI_TX_DMA_CHANNEL_IDX0 DMA_CHANNEL_1
#define DRV_SPI_TX_DMA_THRESHOLD_IDX0 16
#define DRV_SPI_RX_DMA_CHANNEL_IDX0 DMA_CHANNEL_0
#define DRV_SPI_RX_DMA_THRESHOLD_IDX0 16 Driver Library
Configuring the Library
The configuration of the ENCx24J600 Driver Library is based on the file sys_config.h.
This header file contains the configuration selection for the ENCX24J600 Driver Library. Based on the selections made, the ENCx24J600 Driver
Library may support the selected features. These configuration settings will apply to all instances of the ENCx24J600 Driver Library.
This header can be placed anywhere; however, the path of this header needs to be present in the include search path for a successful build. Refer
to the Applications Help section for more details.
Building the Library
This section lists the files that are available in the ENCx24J600 Driver Library.
Description
The following three tables list and describe the header (.h) and source (.c) files that implement this library. The parent folder for these files is
/framework/driver/encx24j600.
Interface File(s)
This table lists and describes the header files that must be included (i.e., using #include) by any code that uses this library.
Volume V: MPLAB Harmony Framework Driver Libraries Help ENCx24J600 Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 430
Source Folder Name Description
/drv_encx24j600.h This file provides the interface definitions of the ENCx24J600 Driver.
Required File(s)
This table lists and describes the source and header files that must always be included in the MPLAB X IDE project to build this library.
All of the required files listed in the following table are automatically added into the MPLAB X IDE project by the MHC
when the library is selected for use.
Source Folder Name Description
/src/dynamic/drv_drv_encx24J600_api.c This file contains the API function
implementations.
/src/dynamic/drv_encx24J600_main_state.c This file contains the main state machine
functions.
/src/dynamic/drv_encx24J600_utils.c This file contains functions that are used
throughout the driver.
/src/dynamic/bus/spi/drv_encx24J600_spi_bus.c This file contains the functions to interface with
the SPI bus.
/src/dynamic/closed_state/drv_encx24J600_closed_state.c This file contains the functions for handling the
driver closed state.
/src/dynamic/initialization_state/drv_encx24J600_configure_state.c This file contains the functions for configuring
the ENC hardware.
/src/dynamic/initialization_state/drv_encx24J600_detect_state.c This file contains the functions for detecting the
ENC hardware.
/src/dynamic/initialization_state/drv_encx24J600_initialization_state.c This file contains the functions for the
initialization state machine.
/src/dynamic/initialization_state/drv_encx24J600_reset_state.c This file contains the functions for resetting the
ENC hardware.
/src/dynamic/packet/drv_encx24J600_rx_packet.c This file contains the functions for receiving a
packet from the ENC hardware.
/src/dynamic/packet/drv_encx24J600_tx_packet.c This file contains the functions for sending a
packet to the ENC hardware.
/src/dynamic/running_state/drv_encx24J600_change_duplex_state.c This file contains the functions for configuring
the duplex mode of the ENC hardware.
/src/dynamic/running_state/drv_encx24J600_check_int_state.c This file contains the functions for checking
and processing the ENC hardware interrupts.
/src/dynamic/running_state/drv_encx24J600_check_status_state.c This file contains the functions for checking the
status of the ENC hardware.
/src/dynamic/running_state/drv_encx24J600_check_tx_status_state.c This file contains the functions for checking the
status of a transmitted packet.
/src/dynamic/running_state/drv_encx24J600_running_state.c This file contains the functions for managing
the running state machine.
Optional File(s)
This table lists and describes the source and header files that may optionally be included if required for the desired implementation.
Source Folder Name Description
N/A No optional files exist for this library.
Module Dependencies
The ENCx24J600 Driver Library depends on the following modules:
• SPI Driver Library
• TCP/IP Stack Library
• TCP/IP Stack MAC Driver Module
Volume V: MPLAB Harmony Framework Driver Libraries Help ENCx24J600 Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 431
Library Interface
a) System Interaction Functions
Name Description
DRV_ENCX24J600_Deinitialize Deinitializes the ENCx24J600 Driver Instance.
Implementation: Dynamic
DRV_ENCX24J600_Initialize Initializes the ENCx24J600 Driver Instance, with the configuration data.
Implementation: Dynamic
DRV_ENCX24J600_Reinitialize Reinitializes the instance of the ENCX24J600 driver.
Implementation: Dynamic
DRV_ENCX24J600_Tasks Main task function for the driver.
Implementation: Dynamic
DRV_ENCX24J600_SetMacCtrlInfo This function sets the MAC control information for the driver.
Implementation: Dynamic
DRV_ENCX24J600_StackInitialize This function initializes the driver with a TCPIP_MAC_INIT object.
Implementation: Dynamic
DRV_ENCX24J600_Process Additional processing that happens outside the tasks function.
Implementation: Dynamic
b) Client Level Functions
Name Description
DRV_ENCX24J600_Close Closes a client handle to the driver.
Implementation: Dynamic
DRV_ENCX24J600_ConfigGet Gets the current configuration.
Implementation: Dynamic
DRV_ENCX24J600_LinkCheck This function returns the status of the link.
Implementation: Dynamic
DRV_ENCX24J600_Open This function is called by the client to open a handle to a driver instance.
Implementation: Dynamic
DRV_ENCX24J600_ParametersGet Get the parameters of the device.
Implementation: Dynamic
DRV_ENCX24J600_PowerMode This function sets the power mode of the device.
Implementation: Dynamic
DRV_ENCX24J600_RegisterStatisticsGet Get the register statistics.
Implementation: Dynamic
DRV_ENCX24J600_StatisticsGet Retrieve the devices statistics.
Implementation: Dynamic
DRV_ENCX24J600_Status Gets the current status of the driver.
Implementation: Dynamic
c) Receive Functions
Name Description
DRV_ENCX24J600_PacketRx Receive a packet from the driver.
Implementation: Dynamic
DRV_ENCX24J600_RxFilterHashTableEntrySet This function adds an entry to the hash table.
Implementation: Dynamic
d) Transmit Functions
Name Description
DRV_ENCX24J600_PacketTx This function queues a packet for transmission.
Implementation: Dynamic
e) Event Functions
Name Description
DRV_ENCX24J600_EventAcknowledge Acknowledges an event.
Implementation: Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help ENCx24J600 Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 432
DRV_ENCX24J600_EventMaskSet Sets the event mask.
Implementation: Dynamic
DRV_ENCX24J600_EventPendingGet Gets the current events.
Implementation: Dynamic
f) Data Types and Constants
Name Description
_DRV_ENCX24J600_Configuration Defines the data required to initialize or reinitialize the ENCX24J600 Driver.
DRV_ENCX24J600_Configuration Defines the data required to initialize or reinitialize the ENCX24J600 Driver.
DRV_ENCX24J600_MDIX_TYPE Defines the enumeration for controlling the MDIX select.
Description
This section describes the Application Programming Interface (API) functions of the ENCx24J600 Driver Library.
Refer to each section for a detailed description.
a) System Interaction Functions
DRV_ENCX24J600_Deinitialize Function
Deinitializes the ENCx24J600 Driver Instance.
Implementation: Dynamic
File
drv_encx24j600.h
C
void DRV_ENCX24J600_Deinitialize(SYS_MODULE_OBJ object);
Returns
None.
Description
ENCX24J600 Deinitialization
This function deallocates any resources allocated by the initialization function.
Preconditions
The driver had to be successfully initialized with DRV_ENCX24J600_Initialize.
Parameters
Parameters Description
Object the valid object returned from DRV_ENCX24J600_Initialize
DRV_ENCX24J600_Initialize Function
Initializes the ENCx24J600 Driver Instance, with the configuration data.
Implementation: Dynamic
File
drv_encx24j600.h
C
SYS_MODULE_OBJ DRV_ENCX24J600_Initialize(SYS_MODULE_INDEX index, SYS_MODULE_INIT * init);
Returns
• Valid handle to the driver instance - If successful
• SYS_MODULE_OBJ_INVALID - If unsuccessful
Volume V: MPLAB Harmony Framework Driver Libraries Help ENCx24J600 Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 433
Description
ENCX24J600 Initialization
This function initializes the ENCx24J600 Driver with configuration data passed into it by either the system_init function or by the
DRV_ENCX24J600_StackInitialize function. Calling this function alone is not enough to initialize the driver, DRV_ENCX24J600_SetMacCtrlInfo
must be called with valid data before the driver is ready to be opened.
Preconditions
None.
Parameters
Parameters Description
index This is the index of the driver instance to be initialized. The definition
DRV_ENCX24J600_NUM_DRV_INSTANCES controls how many instances are available.
init This is a pointer to a DRV_ENX24J600_CONFIG structure.
DRV_ENCX24J600_Reinitialize Function
Reinitializes the instance of the ENCX24J600 driver.
Implementation: Dynamic
File
drv_encx24j600.h
C
void DRV_ENCX24J600_Reinitialize(SYS_MODULE_OBJ object, const SYS_MODULE_INIT * const init);
Returns
None
Description
ENCX24J600 Reinitialization
This function will deinitialize and initialize the driver instance. As with DRV_ENCX24J600_Initialize DRV_ENCX24J600_SetMacCtrlInfo must be
called for the driver to be useful.
Remarks
This function is not planned to be implemented for the first release.
Preconditions
The driver had to be successfully initialized with DRV_ENCX24J600_Initialize.
DRV_ENCX24J600_Tasks Function
Main task function for the driver.
Implementation: Dynamic
File
drv_encx24j600.h
C
void DRV_ENCX24J600_Tasks(SYS_MODULE_OBJ object);
Returns
None.
Description
ENCX24J600 Tasks
This function will execute the main state machine for the ENCX24J600 driver.
Preconditions
The driver had to be successfully initialized with DRV_ENCX24J600_Initialize.
Volume V: MPLAB Harmony Framework Driver Libraries Help ENCx24J600 Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 434
Parameters
Parameters Description
object The object valid passed back to DRV_ENCX24J600_Initialize
DRV_ENCX24J600_SetMacCtrlInfo Function
This function sets the MAC control information for the driver.
Implementation: Dynamic
File
drv_encx24j600.h
C
void DRV_ENCX24J600_SetMacCtrlInfo(SYS_MODULE_OBJ object, TCPIP_MAC_MODULE_CTRL * init);
Returns
None.
Description
ENCX24J600 Set MAC Control Information
This function is used to pass in the TCPIP_MAC_CONTROL_INIT information that is used for allocation and deallocation of memory, event
signaling, etc. This function is needed to be called so that the driver can enter initialization state when the tasks function is called.
Preconditions
The driver had to be successfully initialized with DRV_ENCX24J600_Initialize.
DRV_ENCX24J600_StackInitialize Function
This function initializes the driver with a TCPIP_MAC_INIT object.
Implementation: Dynamic
File
drv_encx24j600.h
C
SYS_MODULE_OBJ DRV_ENCX24J600_StackInitialize(SYS_MODULE_INDEX index, const SYS_MODULE_INIT * const init);
Returns
Returns a valid handle to the driver instance - If successful SYS_MODULE_OBJ_INVALID - If unsuccessful
Description
ENCX24J600 Stack Initialization
This function is used by the TCP/IP stack to fully initialize the driver with both the ENCX24J600 specific configuration and the MAC control
information. With this function there is no need to call DRV_ENCX24J600_SetMacCtrlInfo.
Preconditions
None.
Parameters
Parameters Description
index This is the index of the driver instance to be initialized. The definition
DRV_ENCX24J600_NUM_DRV_INSTANCES controls how many instances are available.
init This is a pointer to a TCPIP_MAC_INIT structure.
DRV_ENCX24J600_Process Function
Additional processing that happens outside the tasks function.
Implementation: Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help ENCx24J600 Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 435
File
drv_encx24j600.h
C
TCPIP_MAC_RES DRV_ENCX24J600_Process(DRV_HANDLE hMac);
Returns
• TCPIP_MAC_RES_TYPE_ERR - if the hMac is invalid
• TCPIP_MAC_RES_OP_ERR - if the hMac is valid
Description
ENCX24J600 Process
This function does additional processing that is not done inside the tasks function.
Remarks
This function does nothing in the first release.
Preconditions
The client had to be successfully opened with DRV_ENCX24J600_Open.
Parameters
Parameters Description
hMac the successfully opened handle
b) Client Level Functions
DRV_ENCX24J600_Close Function
Closes a client handle to the driver.
Implementation: Dynamic
File
drv_encx24j600.h
C
void DRV_ENCX24J600_Close(DRV_HANDLE handle);
Returns
None.
Description
ENCX24J600 Close
This function closes a handle to the driver. If it is the last client open, the driver will send an RX Disable command to the ENC hardware and move
to the closed state.
Preconditions
The client had to be successfully opened with DRV_ENCX24J600_Open.
Parameters
Parameters Description
handle The successfully opened handle
DRV_ENCX24J600_ConfigGet Function
Gets the current configuration.
Implementation: Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help ENCx24J600 Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 436
File
drv_encx24j600.h
C
size_t DRV_ENCX24J600_ConfigGet(DRV_HANDLE hMac, void* configBuff, size_t buffSize, size_t* pConfigSize);
Returns
Number of bytes copied to the buffer
Description
ENCX24J600 Get Configuration
Gets the current configuration.
Remarks
This function does nothing in the first release.
Preconditions
The client had to be successfully opened with DRV_ENCX24J600_Open.
Parameters
Parameters Description
hMac the successfully opened handle
configBuff location to copy the configuration too
buffSize buffer size
pConfigSize configuration size needed
DRV_ENCX24J600_LinkCheck Function
This function returns the status of the link.
Implementation: Dynamic
File
drv_encx24j600.h
C
bool DRV_ENCX24J600_LinkCheck(DRV_HANDLE hMac);
Returns
• true - if the link is active
• false - all other times
Description
ENCX24J600 Link Check
This function checks the status of the link and returns it to the caller.
Preconditions
The client had to be successfully opened with DRV_ENCX24J600_Open.
Parameters
Parameters Description
hMac the successfully opened handle
DRV_ENCX24J600_Open Function
This function is called by the client to open a handle to a driver instance.
Implementation: Dynamic
File
drv_encx24j600.h
Volume V: MPLAB Harmony Framework Driver Libraries Help ENCx24J600 Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 437
C
DRV_HANDLE DRV_ENCX24J600_Open(SYS_MODULE_INDEX index, DRV_IO_INTENT intent);
Returns
Returns a valid handle - If successful INVALID_HANDLE - If unsuccessful
Description
ENCX24J600 Open
The client will call this function to open a handle to the driver. When the first instance is opened than the driver will send the RX enabled command
to the ENC hardware.
Preconditions
The driver had to be successfully initialized with DRV_ENCX24J600_Initialize.
Parameters
Parameters Description
index This is the index of the driver instance to be initialized. The definition
DRV_ENCX24J600_NUM_DRV_INSTANCES controls how many instances are available.
intent The intent to use when opening the driver. Only exclusive is supported
DRV_ENCX24J600_ParametersGet Function
Get the parameters of the device.
Implementation: Dynamic
File
drv_encx24j600.h
C
TCPIP_MAC_RES DRV_ENCX24J600_ParametersGet(DRV_HANDLE hMac, TCPIP_MAC_PARAMETERS* pMacParams);
Returns
• TCPIP_MAC_RES_TYPE_ERR - if the hMac is invalid
• TCPIP_MAC_RES_OK - if the hMac is valid
Description
ENCX24J600 Get Parameters
Get the parameters of the device, which includes that it is an Ethernet device and what it's MAC address is.
Preconditions
The client had to be successfully opened with DRV_ENCX24J600_Open.
Parameters
Parameters Description
hMac the successfully opened handle
pMacParams pointer to put the parameters
DRV_ENCX24J600_PowerMode Function
This function sets the power mode of the device.
Implementation: Dynamic
File
drv_encx24j600.h
C
bool DRV_ENCX24J600_PowerMode(DRV_HANDLE hMac, TCPIP_MAC_POWER_MODE pwrMode);
Volume V: MPLAB Harmony Framework Driver Libraries Help ENCx24J600 Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 438
Returns
• false - This functionality is not supported in this version of the driver
Description
ENCX24J600 Power Mode
This function sets the power mode of the ENCX24J600.
Remarks
This functionality is not implemented in the first release.
Preconditions
The client had to be successfully opened with DRV_ENCX24J600_Open.
Parameters
Parameters Description
hMac the successfully opened handle
pwrMode the power mode to set
DRV_ENCX24J600_RegisterStatisticsGet Function
Get the register statistics.
Implementation: Dynamic
File
drv_encx24j600.h
C
TCPIP_MAC_RES DRV_ENCX24J600_RegisterStatisticsGet(DRV_HANDLE hMac, TCPIP_MAC_STATISTICS_REG_ENTRY*
pRegEntries, int nEntries, int* pHwEntries);
Returns
• TCPIP_MAC_RES_TYPE_ERR - if the hMac is invalid
• TCPIP_MAC_RES_OP_ERR - if the hMac is valid
Description
ENCX24J600 Get Register Statistics
Get the device specific statistics.
Remarks
Statistics are not planned for the first release
Preconditions
The client had to be successfully opened with DRV_ENCX24J600_Open.
Parameters
Parameters Description
hMac the successfully opened handle
pRegEntries
nEntries
pHwEntries
DRV_ENCX24J600_StatisticsGet Function
Retrieve the devices statistics.
Implementation: Dynamic
File
drv_encx24j600.h
Volume V: MPLAB Harmony Framework Driver Libraries Help ENCx24J600 Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 439
C
TCPIP_MAC_RES DRV_ENCX24J600_StatisticsGet(DRV_HANDLE hMac, TCPIP_MAC_RX_STATISTICS* pRxStatistics,
TCPIP_MAC_TX_STATISTICS* pTxStatistics);
Returns
• TCPIP_MAC_RES_TYPE_ERR - if the hMac is invalid
• TCPIP_MAC_RES_OP_ERR - if the hMac is valid
Description
ENCX24J600 Get Statistics
Get the current statistics stored in the driver.
Remarks
Statistics are not planned for the first release.
Preconditions
The client had to be successfully opened with DRV_ENCX24J600_Open.
Parameters
Parameters Description
hMac the successfully opened handle
DRV_ENCX24J600_Status Function
Gets the current status of the driver.
Implementation: Dynamic
File
drv_encx24j600.h
C
SYS_STATUS DRV_ENCX24J600_Status(SYS_MODULE_OBJ obect);
Returns
• SYS_STATUS_ERROR - if an invalid handle has been passed in
• SYS_STATUS_UNINITIALIZED - if the driver has not completed initialization
• SYS_STATUS_BUSY - if the driver is closing and moving to the closed state
• SYS_STATUS_READY - if the driver is ready for client commands
Description
ENCX24J600 Status
This function will get the status of the driver instance.
Preconditions
The driver had to be successfully initialized with DRV_ENCX24J600_Initialize().
Parameters
Parameters Description
object The object valid passed back to DRV_ENCX24J600_Initialize()
c) Receive Functions
DRV_ENCX24J600_PacketRx Function
Receive a packet from the driver.
Implementation: Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help ENCx24J600 Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 440
File
drv_encx24j600.h
C
TCPIP_MAC_PACKET* DRV_ENCX24J600_PacketRx(DRV_HANDLE hMac, TCPIP_MAC_RES* pRes, const
TCPIP_MAC_PACKET_RX_STAT** ppPktStat);
Returns
• Pointer to a valid packet - if successful
• NULL - if unsuccessful
Description
ENCX24J600 Receive Packet
This function retrieves a packet from the driver. The packet needs to be acknowledged with the linked acknowledge function so it can be reused.
Remarks
ppPktStat is ignored in the first release.
Preconditions
The client had to be successfully opened with DRV_ENCX24J600_Open.
Parameters
Parameters Description
hMac the successfully opened handle
pRes the result of the operation
ppPktStat pointer to the receive statistics
DRV_ENCX24J600_RxFilterHashTableEntrySet Function
This function adds an entry to the hash table.
Implementation: Dynamic
File
drv_encx24j600.h
C
TCPIP_MAC_RES DRV_ENCX24J600_RxFilterHashTableEntrySet(DRV_HANDLE hMac, const TCPIP_MAC_ADDR* DestMACAddr);
Returns
• TCPIP_MAC_RES_TYPE_ERR - if the hMac is invalid
• TCPIP_MAC_RES_OP_ERR - if the hMac is valid
Description
ENCX24J600 Receive Filter Hash Table Entry Set
This function adds to the MAC's hash table for hash table matching.
Remarks
This functionality is not implemented in the first release.
Preconditions
The client had to be successfully opened with DRV_ENCX24J600_Open.
Parameters
Parameters Description
hMac the successfully opened handle
DestMACAddr MAC address to add to the hash table
d) Transmit Functions
Volume V: MPLAB Harmony Framework Driver Libraries Help ENCx24J600 Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 441
DRV_ENCX24J600_PacketTx Function
This function queues a packet for transmission.
Implementation: Dynamic
File
drv_encx24j600.h
C
TCPIP_MAC_RES DRV_ENCX24J600_PacketTx(DRV_HANDLE hMac, TCPIP_MAC_PACKET * ptrPacket);
Returns
• TCPIP_MAC_RES_OP_ERR - if the client handle is invalid
• TCPIP_MAC_RES_IS_BUSY - if the driver is not in the run state
• TCPIP_MAC_RES_QUEUE_TX_FULL - if there are no free descriptors
• TCPIP_MAC_RES_OK - on successful queuing of the packet
Description
ENCX24J600 Packet Transmit
This function will take a packet and add it to the queue for transmission. When the packet has finished transmitting the driver will call the packets
acknowledge function. When that acknowledge function is complete the driver will forget about the packet.
Preconditions
The client had to be successfully opened with DRV_ENCX24J600_Open.
Parameters
Parameters Description
hMac the successfully opened handle
ptrPacket pointer to the packet
e) Event Functions
DRV_ENCX24J600_EventAcknowledge Function
Acknowledges an event.
Implementation: Dynamic
File
drv_encx24j600.h
C
bool DRV_ENCX24J600_EventAcknowledge(DRV_HANDLE hMac, TCPIP_MAC_EVENT macEvents);
Returns
• true - if successful
• false - if not successful
Description
ENCX24J600 Acknowledge Event
This function acknowledges an event.
Preconditions
The client had to be successfully opened with DRV_ENCX24J600_Open.
Parameters
Parameters Description
hMac the successfully opened handle
macEvents the events to acknowledge
Volume V: MPLAB Harmony Framework Driver Libraries Help ENCx24J600 Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 442
DRV_ENCX24J600_EventMaskSet Function
Sets the event mask.
Implementation: Dynamic
File
drv_encx24j600.h
C
bool DRV_ENCX24J600_EventMaskSet(DRV_HANDLE hMac, TCPIP_MAC_EVENT macEvents, bool enable);
Returns
• true - if the mask could be set
• false - if the mast could not be set
Description
ENCX24J600 Set Event Mask
Sets the event mask to what is passed in.
Preconditions
The client had to be successfully opened with DRV_ENCX24J600_Open.
Parameters
Parameters Description
hMac the successfully opened handle
macEvents the mask to enable or disable
enable to enable or disable events
DRV_ENCX24J600_EventPendingGet Function
Gets the current events.
Implementation: Dynamic
File
drv_encx24j600.h
C
TCPIP_MAC_EVENT DRV_ENCX24J600_EventPendingGet(DRV_HANDLE hMac);
Returns
• TCPIP_MAC_EV_NONE - Returned on an error
• List of events - Returned on event other than an error
Description
ENCX24J600 Get Events
This function gets the current events.
Preconditions
The client had to be successfully opened with DRV_ENCX24J600_Open.
Parameters
Parameters Description
hMac the successfully opened handle
f) Data Types and Constants
Volume V: MPLAB Harmony Framework Driver Libraries Help ENCx24J600 Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 443
DRV_ENCX24J600_Configuration Structure
Defines the data required to initialize or reinitialize the ENCX24J600 Driver.
File
drv_encx24j600.h
C
typedef struct _DRV_ENCX24J600_Configuration {
uint16_t txDescriptors;
uint16_t rxDescriptors;
uint16_t rxDescBufferSize;
SYS_MODULE_INDEX spiDrvIndex;
uint32_t spiBps;
uint16_t rxBufferSize;
uint16_t maxFrameSize;
PORTS_MODULE_ID spiSSPortModule;
PORTS_CHANNEL spiSSPortChannel;
PORTS_BIT_POS spiSSPortPin;
bool intEnable;
PORTS_MODULE_ID intPortModule;
PORTS_CHANNEL intPortChannel;
PORTS_BIT_POS intPortPin;
DRV_ENCX24J600_MDIX_TYPE mdixControl;
PORTS_MODULE_ID mdixPortModule;
PORTS_CHANNEL mdixPortChannel;
PORTS_BIT_POS mdixPortPin;
TCPIP_ETH_OPEN_FLAGS ethType;
TCPIP_ETH_OPEN_FLAGS dupMode;
} DRV_ENCX24J600_Configuration;
Members
Members Description
uint16_t txDescriptors; Number of TX Descriptors to Allocate
uint16_t rxDescriptors; Number of RX Descriptors to Allocate
uint16_t rxDescBufferSize; Size of the buffer each RX Descriptor will use. Make sure its not smaller that maxFrameSize
SYS_MODULE_INDEX spiDrvIndex; Index of the SPI driver to use
uint32_t spiBps; Bus speed to use for the SPI interface. Section 1.0 of the ENCX24J600 data sheets says the
maximum is 14000000 Hz. It is not recommended to go above this value.
uint16_t rxBufferSize; The ENCX24J600 hardware has a 22 k dram. rxBufferSize defines how much of that memory
is used by the rxBuffer
uint16_t maxFrameSize; The maximum frame size to be supported by the hardware. 1536 is the default
PORTS_MODULE_ID spiSSPortModule; Port Module of the GPIO pin hooked up to the CS/SS pin of the ENCX24J600
PORTS_CHANNEL spiSSPortChannel; Port Channel of the GPIO pin hooked up to the CS/SS pin of the ENCX24J600
PORTS_BIT_POS spiSSPortPin; Pin position of the GPIO pin hooked up to the CS/SS pin of the ENCX24J600
bool intEnable; Use Interrupts or not.
PORTS_MODULE_ID intPortModule; Port Module of the GPIO pin hooked up to the INT pin of the ENCX24J600
PORTS_CHANNEL intPortChannel; Port Channel of the GPIO pin hooked up to the INT pin of the ENCX24J600
PORTS_BIT_POS intPortPin; Pin Position of the GPIO pin hooked up to the INT pin of the ENCX24J600
DRV_ENCX24J600_MDIX_TYPE mdixControl; To select the control type of the MDIX. This is only needed for hooking up to switches that
don't have auto-mdix.
PORTS_MODULE_ID mdixPortModule; Port Module of the GPIO pin hooked up to the MDIX select pin
PORTS_CHANNEL mdixPortChannel; Port Channel of the GPIO pin hooked up to the MDIX select pin
PORTS_BIT_POS mdixPortPin; Pin Position of the GPIO pin hooked up to the MDIX select pin
TCPIP_ETH_OPEN_FLAGS ethType; Ethernet type
TCPIP_ETH_OPEN_FLAGS dupMode; Duplex Mode
Description
ENCX24J600 Driver Initialization Data
This data type defines the data required to initialize or reinitialize the ENCX24J600 driver. If the driver is built statically, the members of this data
structure are statically over-ridden by static override definitions in the system_config.h file.
Volume V: MPLAB Harmony Framework Driver Libraries Help ENCx24J600 Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 444
Remarks
None.
DRV_ENCX24J600_MDIX_TYPE Enumeration
Defines the enumeration for controlling the MDIX select.
File
drv_encx24j600.h
C
typedef enum {
DRV_ENCX24J600_NO_CONTROL = 0,
DRV_ENCX24J600_NORMAL,
DRV_ENCX24J600_REVERSE = 0
} DRV_ENCX24J600_MDIX_TYPE;
Members
Members Description
DRV_ENCX24J600_NO_CONTROL = 0 No Control
DRV_ENCX24J600_NORMAL Normal MDIX
DRV_ENCX24J600_REVERSE = 0 Reverse MDIX
Description
ENCX24J600 Driver MDIX Control type
This type defines the enumeration for controlling the MDIX select.
Remarks
None.
Files
Files
Name Description
drv_encx24j600.h ENCx24J600 Driver interface definition.
Description
drv_encx24j600.h
ENCx24J600 Driver interface definition.
Enumerations
Name Description
DRV_ENCX24J600_MDIX_TYPE Defines the enumeration for controlling the MDIX select.
Functions
Name Description
DRV_ENCX24J600_Close Closes a client handle to the driver.
Implementation: Dynamic
DRV_ENCX24J600_ConfigGet Gets the current configuration.
Implementation: Dynamic
DRV_ENCX24J600_Deinitialize Deinitializes the ENCx24J600 Driver Instance.
Implementation: Dynamic
DRV_ENCX24J600_EventAcknowledge Acknowledges an event.
Implementation: Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help ENCx24J600 Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 445
DRV_ENCX24J600_EventMaskSet Sets the event mask.
Implementation: Dynamic
DRV_ENCX24J600_EventPendingGet Gets the current events.
Implementation: Dynamic
DRV_ENCX24J600_Initialize Initializes the ENCx24J600 Driver Instance, with the configuration data.
Implementation: Dynamic
DRV_ENCX24J600_LinkCheck This function returns the status of the link.
Implementation: Dynamic
DRV_ENCX24J600_Open This function is called by the client to open a handle to a driver instance.
Implementation: Dynamic
DRV_ENCX24J600_PacketRx Receive a packet from the driver.
Implementation: Dynamic
DRV_ENCX24J600_PacketTx This function queues a packet for transmission.
Implementation: Dynamic
DRV_ENCX24J600_ParametersGet Get the parameters of the device.
Implementation: Dynamic
DRV_ENCX24J600_PowerMode This function sets the power mode of the device.
Implementation: Dynamic
DRV_ENCX24J600_Process Additional processing that happens outside the tasks function.
Implementation: Dynamic
DRV_ENCX24J600_RegisterStatisticsGet Get the register statistics.
Implementation: Dynamic
DRV_ENCX24J600_Reinitialize Reinitializes the instance of the ENCX24J600 driver.
Implementation: Dynamic
DRV_ENCX24J600_RxFilterHashTableEntrySet This function adds an entry to the hash table.
Implementation: Dynamic
DRV_ENCX24J600_SetMacCtrlInfo This function sets the MAC control information for the driver.
Implementation: Dynamic
DRV_ENCX24J600_StackInitialize This function initializes the driver with a TCPIP_MAC_INIT object.
Implementation: Dynamic
DRV_ENCX24J600_StatisticsGet Retrieve the devices statistics.
Implementation: Dynamic
DRV_ENCX24J600_Status Gets the current status of the driver.
Implementation: Dynamic
DRV_ENCX24J600_Tasks Main task function for the driver.
Implementation: Dynamic
Structures
Name Description
_DRV_ENCX24J600_Configuration Defines the data required to initialize or reinitialize the ENCX24J600 Driver.
DRV_ENCX24J600_Configuration Defines the data required to initialize or reinitialize the ENCX24J600 Driver.
Description
ENCx24J600 Driver Public Interface
This file defines the interface definition for the ENCx24J600 Driver.
File Name
drv_encx24j600.h
Company
Microchip Technology Inc.
Ethernet MAC Driver Library
This section describes the Ethernet MAC Driver Library.
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet MAC Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 446
Introduction
This library provides a driver-level abstraction of the on-chip Ethernet Controller found on many PIC32 devices. The driver implements the virtual
MAC driver model that the MPLAB Harmony TCP/IP Stack requires. Please see the TCP/IP Stack Library MAC Driver Module help for details.
The "Host-To-Network"_layer of a TCP/IP stack organization covers the Data Link and Physical Layers of the standard OSI stack. The Ethernet
Controller provides the Data Link or Media Access Control Layer, in addition to other functions discussed in this section. An external Ethernet
"PHY" provides the Physical_layer, providing conversion between the digital and analog.
Description
The PIC32 Ethernet Controller is a bus master module that interfaces with an off-chip PHY to implement a complete Ethernet node in a system.
The following are some of the key features of this module:
• Supports 10/100 Ethernet
• Full-Duplex and Half-Duplex operation
• Broadcast, Multicast and Unicast packets
• Manual and automatic flow control
• Supports Auto-MDIX enabled PHYs
• Reduced Media Independent Interface (RMII) and Media Independent Interface (MII) PHY data interfaces
• Performance statistics metrics in hardware.
• RAM descriptor based DMA operation for both receive and transmit path
• Fully configurable interrupts
• Configurable receive packet filtering using:
• 64-bit Hash Table
• 64-byte Pattern Match
• Magic Packet™ Filtering
• Runt Packet Detection and Filtering
• Supports Packet Payload Checksum calculation
• CRC Check
Support for the Serial Management Interface (SMI) (also known as the MIIM interface) is provided by the Ethernet PHY Driver Library.
Using the Library
The user of this driver is the MPLAB Harmony TCP/IP stack. This Ethernet driver is not intended as a system wide driver that the application or
other system modules may use. It is intended for the sole use of the MPLAB Harmony TCP/IP stack and implements the virtual MAC model
required by the stack.
This topic describes the basic architecture and functionality of the Ethernet MAC driver and is meant for advanced users or TCP/IP stack driver
developers.
Interface Header File: drv_ethmac.h
The interface to the Ethernet MAC library is defined in the drv_ethmac.h header file, which is included by the MPLAB Harmony TCP/IP stack.
Please refer to the What is MPLAB Harmony? section for how the library interacts with the framework.
Abstraction Model
This library provides a low-level abstraction of the Ethernet MAC Driver Library on Microchip's microcontrollers with a convenient C language
interface. This topic describes how that abstraction is modeled in software and introduces the library's interface.
Description
The Ethernet Controller provides the modules needed to implement a 10/100 Mbps Ethernet node using an external Ethernet PHY chip. The PHY
chip provides a digital-analog interface as part of the Physical Layer and the controller provides the Media Access Controller (MAC)_layer above
the PHY.
As shown in Figure 1, the Ethernet Controller consists of the following modules:
• Media Access Control (MAC) block: Responsible for implementing the MAC functions of the Ethernet IEEE 802.3 Specification
• Flow Control (FC) block: Responsible for control of the transmission of PAUSE frames. (Reception of PAUSE frames is handled within the
MAC.)
• RX Filter (RXF) block: This module performs filtering on every receive packet to determine whether each packet should be accepted or rejected
• TX DMA/TX Buffer Management Engine: The TX DMA and TX Buffer Management engines perform data transfers from the memory (using
descriptor tables) to the MAC Transmit Interface
• RX DMA/RX Buffer Management Engine: The RX DMA and RX Buffer Management engines transfer receive packets from the MAC to the
memory (using descriptor tables)
Figure 1: Ethernet Controller Block Diagram
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet MAC Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 447
For completeness, we also need to look at the interface diagram of a representative Ethernet PHY. As shown in Figure 2, the PHY has two
interfaces, one for configuring and managing the PHY (SMI/MIIM) and another for transmit and receive data (RMII or MII). The SMI/MIIM interface
is the responsibility of the Ethernet PHY Driver Library. When setting up the Ethernet PHY, this Ethernet driver calls primitives from the Ethernet
PHY Driver library. The RMII/MII data interface is the responsibility of the Ethernet MAC Driver Library (this library).
Figure 2: Ethernet PHY Interfaces
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet MAC Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 448
Library Overview
Refer to the Driver Library Overview section for information on how the driver operates in a system. Refer to the TCP/IP Stack Library MAC Driver
Module help for the interface that the Ethernet driver has to implement in a MPLAB Harmony system.
The library interface routines are divided into various sub-sections, which address one of the blocks or the overall operation of the Ethernet MAC
Driver Library.
Library Interface Section Description
Client Level Functions DRV_ETHMAC_PIC32MACOpen, DRV_ETHMAC_PIC32MACClose, and
DRV_ETHMAC_PIC32MACSetup to support the TCP/IP Stack. Plus link status and
power options.
Receive Functions Receive routines.
Transmit Functions Transmit routines.
Event Functions Ethernet event support routines.
Other Functions Additional routines.
Data Types and Constants Typedefs and #defines.
Configuring the Library
Macros
Name Description
DRV_ETHMAC_CLIENTS_NUMBER Selects the maximum number of clients.
DRV_ETHMAC_INDEX Ethernet MAC static index selection.
DRV_ETHMAC_INSTANCES_NUMBER Selects the maximum number of hardware instances that can be supported by the
dynamic driver.
DRV_ETHMAC_INTERRUPT_MODE Controls operation of the driver in the interrupt or polled mode.
DRV_ETHMAC_INTERRUPT_SOURCE Defines an override of the interrupt source in case of static driver.
DRV_ETHMAC_PERIPHERAL_ID Defines an override of the peripheral ID.
DRV_ETHMAC_POWER_STATE Defines an override of the power state of the Ethernet MAC driver.
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet MAC Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 449
Description
The configuration of the Ethernet MAC driver is done as part of the MPLAB Harmony TCP/IP Stack configuration and is based on the
system_config.h file, which may include the tcpip_mac_config.h. See the TCP/IP Stack Library MAC Driver Module help file for
configuration options.
This header file contains the configuration selection for the Ethernet MAC Driver.
This header can be placed anywhere; however, the path of this header needs to be present in the include search path for a successful build. Refer
to the Applications Help section for more details.
DRV_ETHMAC_CLIENTS_NUMBER Macro
Selects the maximum number of clients.
File
drv_ethmac_config.h
C
#define DRV_ETHMAC_CLIENTS_NUMBER 1
Description
Ethernet MAC Maximum Number of Clients
This definition select the maximum number of clients that the Ethernet MAC driver can support at run time.
Remarks
The MAC driver is not a true multi-client driver. Under normal usage, the only client of the MAC driver is the TCP/IP stack. After the MAC driver
provided an DRV_HANDLE as a result of an Open operation, any other attempt to call Open will return a invalid handle. Default value should be 1.
However, for allowing other modules to interface directly with the MAC driver while the TCP/IP stack currently uses the the MAC driver this symbol
can have a value greater than 1. But the returned handle is the same one as the TCP/IP stack uses.
DRV_ETHMAC_INDEX Macro
Ethernet MAC static index selection.
File
drv_ethmac_config.h
C
#define DRV_ETHMAC_INDEX DRV_ETHMAC_INDEX_1
Description
Ethernet MAC Static Index Selection
This definition selects the Ethernet MAC static index for the driver object reference
Remarks
This index is required to make a reference to the driver object.
DRV_ETHMAC_INSTANCES_NUMBER Macro
Selects the maximum number of hardware instances that can be supported by the dynamic driver.
File
drv_ethmac_config.h
C
#define DRV_ETHMAC_INSTANCES_NUMBER 1
Description
Ethernet MAC hardware instance configuration
This definition selects the maximum number of hardware instances that can be supported by the dynamic driver. Not defining it means using a
static driver.
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet MAC Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 450
Remarks
None.
DRV_ETHMAC_INTERRUPT_MODE Macro
Controls operation of the driver in the interrupt or polled mode.
File
drv_ethmac_config.h
C
#define DRV_ETHMAC_INTERRUPT_MODE true
Description
Ethernet MAC Interrupt And Polled Mode Operation Control
This macro controls the operation of the driver in the interrupt mode of operation. The possible values of this macro are:
• true - Select if interrupt mode of timer operation is desired
• false - Select if polling mode of timer operation is desired
Not defining this option to true or false will result in a build error.
Remarks
None.
DRV_ETHMAC_INTERRUPT_SOURCE Macro
Defines an override of the interrupt source in case of static driver.
File
drv_ethmac_config.h
C
#define DRV_ETHMAC_INTERRUPT_SOURCE INT_SOURCE_ETH_1
Description
Ethernet MAC Interrupt Source
Defines an override of the interrupt source in case of static driver.
Remarks
Refer to the INT PLIB document for more information on INT_SOURCE enumeration.
DRV_ETHMAC_PERIPHERAL_ID Macro
Defines an override of the peripheral ID.
File
drv_ethmac_config.h
C
#define DRV_ETHMAC_PERIPHERAL_ID ETHMAC_ID_1
Description
Ethernet MAC Peripheral ID Selection
Defines an override of the peripheral ID, using macros.
Remarks
Some devices also support ETHMAC_ID_0
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet MAC Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 451
DRV_ETHMAC_POWER_STATE Macro
Defines an override of the power state of the Ethernet MAC driver.
File
drv_ethmac_config.h
C
#define DRV_ETHMAC_POWER_STATE SYS_MODULE_POWER_IDLE_STOP
Description
Ethernet MAC power state configuration
Defines an override of the power state of the Ethernet MAC driver.
Remarks
This feature may not be available in the device or the Ethernet MAC module selected.
Building the Library
This section lists the files that are available in the Ethernet MAC Driver Library.
Description
The following three tables list and describe the header (.h) and source (.c) files that implement this library. The parent folder for these files is
/framework/driver/ethmac.
Interface File(s)
This table lists and describes the header files that must be included (i.e., using #include) by any code that uses this library.
Source File Name Description
/drv_ethmac.h Header file that exports the driver API.
Required File(s)
All of the required files listed in the following table are automatically added into the MPLAB X IDE project by the MHC
when the library is selected for use.
This table lists and describes the source and header files that must always be included in the MPLAB X IDE project to build this library.
Source File Name Description
/src/dynamic/drv_ethmac.c PIC32 internal Ethernet driver virtual MAC implementation file.
/src/dynamic/drv_ethmac_lib.c PIC32 internal Ethernet driver controller implementation file.
Optional File(s)
This table lists and describes the source and header files that may optionally be included if required for the desired implementation.
Source File Name Description
N/A No optional files are available for this library
Module Dependencies
The Ethernet MAC Driver Library depends on the following modules:
• Ethernet PHY Driver Library
• Interrupt System Service Library
• Timer System Service Library
• Ethernet Peripheral Library
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet MAC Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 452
Library Interface
a) Client Level Functions
Name Description
DRV_ETHMAC_PIC32MACClose Closes a client instance of the PIC32 MAC Driver.
Implementation: Dynamic
DRV_ETHMAC_PIC32MACDeinitialize Deinitializes the PIC32 Ethernet MAC.
Implementation: Dynamic
DRV_ETHMAC_PIC32MACInitialize Initializes the PIC32 Ethernet MAC.
Implementation: Dynamic
DRV_ETHMAC_PIC32MACLinkCheck Checks current link status.
Implementation: Dynamic
DRV_ETHMAC_PIC32MACOpen Opens a client instance of the PIC32 MAC Driver.
Implementation: Dynamic
DRV_ETHMAC_PIC32MACParametersGet MAC parameter get function.
Implementation: Dynamic
DRV_ETHMAC_PIC32MACPowerMode Selects the current power mode for the Ethernet MAC.
Implementation: Dynamic
DRV_ETHMAC_PIC32MACProcess MAC periodic processing function.
Implementation: Dynamic
DRV_ETHMAC_PIC32MACStatisticsGet Gets the current MAC statistics.
Implementation: Dynamic
DRV_ETHMAC_PIC32MACStatus Provides the current status of the MAC driver module.
Implementation: Dynamic
DRV_ETHMAC_PIC32MACConfigGet Gets the current MAC driver configuration.
Implementation: Dynamic
DRV_ETHMAC_PIC32MACRegisterStatisticsGet Gets the current MAC hardware statistics registers.
Implementation: Dynamic
DRV_ETHMAC_PIC32MACReinitialize Reinitializes the PIC32 Ethernet MAC.
Implementation: Dynamic
b) Receive Functions
Name Description
DRV_ETHMAC_PIC32MACPacketRx This is the MAC receive function.
Implementation: Dynamic
DRV_ETHMAC_PIC32MACRxFilterHashTableEntrySet Sets the current MAC hash table receive filter.
Implementation: Dynamic
c) Transmit Functions
Name Description
DRV_ETHMAC_PIC32MACPacketTx MAC driver transmit function.
Implementation: Dynamic
d) Event Functions
Name Description
DRV_ETHMAC_PIC32MACEventAcknowledge Acknowledges and re-enables processed events.
Implementation: Dynamic
DRV_ETHMAC_PIC32MACEventMaskSet Enables/disables the MAC events.
Implementation: Dynamic
DRV_ETHMAC_PIC32MACEventPendingGet Returns the currently pending events.
Implementation: Dynamic
e) Other Functions
Name Description
DRV_ETHMAC_Tasks_ISR Ethernet MAC driver interrupt function.
Implementation: Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet MAC Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 453
DRV_ETHMAC_PIC32MACTasks Maintains the EThernet MAC driver's state machine.
Implementation: Dynamic
f) Data Types and Constants
Name Description
DRV_ETHMAC_INDEX_1 This is macro DRV_ETHMAC_INDEX_1.
DRV_ETHMAC_INDEX_0 Ethernet driver index definitions.
DRV_ETHMAC_INDEX_COUNT Number of valid Ethernet driver indices.
Description
This section lists the interface routines, data types, constants and macros for the library.
a) Client Level Functions
DRV_ETHMAC_PIC32MACClose Function
Closes a client instance of the PIC32 MAC Driver.
Implementation: Dynamic
File
drv_ethmac.h
C
void DRV_ETHMAC_PIC32MACClose(DRV_HANDLE hMac);
Returns
None
Description
This function closes a client instance of the PIC32 MAC Driver.
Remarks
None
Preconditions
DRV_ETHMAC_PIC32MACOpen() should have been called.
Example
Parameters
Parameters Description
hMac valid MAC handle, obtained by a call to DRV_ETHMAC_PIC32MACOpen
Function
void DRV_ETHMAC_PIC32MACClose( DRV_HANDLE hMac )
DRV_ETHMAC_PIC32MACDeinitialize Function
Deinitializes the PIC32 Ethernet MAC.
Implementation: Dynamic
File
drv_ethmac.h
C
void DRV_ETHMAC_PIC32MACDeinitialize(SYS_MODULE_OBJ object);
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet MAC Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 454
Returns
None.
Description
This function supports teardown of the PIC32 Ethernet MAC (opposite of set up). Used by tcpip_module_manager.
Remarks
This function deinitializes the Ethernet controller, the MAC and the associated PHY. It should be called to be release any resources allocated by
the initialization and return the MAC and the PHY to the idle/power down state.
Preconditions
DRV_ETHMAC_PIC32MACInitialize must have been called to set up the driver.
Example
Function
void DRV_ETHMAC_PIC32MACDeinitialize(SYS_MODULE_OBJ object);
DRV_ETHMAC_PIC32MACInitialize Function
Initializes the PIC32 Ethernet MAC.
Implementation: Dynamic
File
drv_ethmac.h
C
SYS_MODULE_OBJ DRV_ETHMAC_PIC32MACInitialize(const SYS_MODULE_INDEX index, const SYS_MODULE_INIT * const
init);
Returns
• a valid handle to a driver object, if successful.
• SYS_MODULE_OBJ_INVALID if initialization failed.
Description
This function supports the initialization of the PIC32 Ethernet MAC. Used by tcpip_module_manager.
Remarks
This function initializes the Ethernet controller, the MAC and the associated PHY. It should be called to be able to schedule any Ethernet transmit
or receive operation.
Preconditions
None
Example
Function
SYS_MODULE_OBJ DRV_ETHMAC_PIC32MACInitialize(const SYS_MODULE_INDEX index, const SYS_MODULE_INIT * const init);
DRV_ETHMAC_PIC32MACLinkCheck Function
Checks current link status.
Implementation: Dynamic
File
drv_ethmac.h
C
bool DRV_ETHMAC_PIC32MACLinkCheck(DRV_HANDLE hMac);
Returns
• true - If the link is up
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet MAC Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 455
• false - If the link is not up
Description
This function checks the link status of the associated network interface.
Remarks
The function will automatically perform a MAC reconfiguration if the link went up after being down and the PHY auto negotiation is enabled.
Preconditions
DRV_ETHMAC_PIC32MACInitialize must have been called to set up the driver. DRV_ETHMAC_PIC32MACOpen() should have been called to
obtain a valid handle.
Example
Parameters
Parameters Description
hMac Ethernet MAC client handle
Function
bool DRV_ETHMAC_PIC32MACLinkCheck( DRV_HANDLE hMac )
DRV_ETHMAC_PIC32MACOpen Function
Opens a client instance of the PIC32 MAC Driver.
Implementation: Dynamic
File
drv_ethmac.h
C
DRV_HANDLE DRV_ETHMAC_PIC32MACOpen(const SYS_MODULE_INDEX drvIndex, const DRV_IO_INTENT intent);
Returns
• DRV_HANDLE - handle (pointer) to MAC client
• 0 if call failed
Description
This function opens a client instance of the PIC32 MAC Driver. Used by tcpip_module_manager.
Remarks
The intent parameter is not used in the current implementation and is maintained only for compatibility with the generic driver Open function
signature.
Preconditions
DRV_ETHMAC_PIC32MACInitialize() should have been called.
Example
Function
DRV_HANDLE DRV_ETHMAC_PIC32MACOpen(const SYS_MODULE_INDEX drvIndex, const DRV_IO_INTENT intent);
DRV_ETHMAC_PIC32MACParametersGet Function
MAC parameter get function.
Implementation: Dynamic
File
drv_ethmac.h
C
TCPIP_MAC_RES DRV_ETHMAC_PIC32MACParametersGet(DRV_HANDLE hMac, TCPIP_MAC_PARAMETERS* pMacParams);
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet MAC Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 456
Returns
• TCPIP_MAC_RES_OK if pMacParams updated properly
• a TCPIP_MAC_RES error code if processing failed for some reason
Description
MAC Parameter Get function TCPIP_MAC_RES DRV_ETHMAC_PIC32MACParametersGet(DRV_HANDLE hMac, TCPIP_MAC_PARAMETERS*
pMacParams);
This is a function that returns the run time parameters of the MAC driver.
Remarks
None.
Preconditions
DRV_ETHMAC_PIC32MACInitialize() should have been called. DRV_ETHMAC_PIC32MACOpen() should have been called to obtain a valid
handle.
DRV_ETHMAC_PIC32MACPowerMode Function
Selects the current power mode for the Ethernet MAC.
Implementation: Dynamic
File
drv_ethmac.h
C
bool DRV_ETHMAC_PIC32MACPowerMode(DRV_HANDLE hMac, TCPIP_MAC_POWER_MODE pwrMode);
Returns
• true if the call succeeded.
• false if the call failed
Description
This function sets the power mode for the Ethernet MAC.
Remarks
This function is not currently supported by the Ethernet MAC and will always return true.
Preconditions
DRV_ETHMAC_PIC32MACInitialize must have been called to set up the driver. DRV_ETHMAC_PIC32MACOpen() should have been called to
obtain a valid handle.
Example
Function
bool DRV_ETHMAC_PIC32MACPowerMode( DRV_HANDLE hMac, TCPIP_MAC_POWER_MODE pwrMode )
DRV_ETHMAC_PIC32MACProcess Function
MAC periodic processing function.
Implementation: Dynamic
File
drv_ethmac.h
C
TCPIP_MAC_RES DRV_ETHMAC_PIC32MACProcess(DRV_HANDLE hMac);
Returns
• TCPIP_MAC_RES_OK if all processing went on OK
• a TCPIP_MAC_RES error code if processing failed for some reason
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet MAC Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 457
Description
This is a function that allows for internal processing by the MAC driver. It is meant for processing that cannot be done from within ISR.
Normally this function will be called in response to an TX and/or RX event signaled by the driver. This is specified by the MAC driver at initialization
time using TCPIP_MAC_MODULE_CTRL.
Remarks
• The MAC driver may use the DRV_ETHMAC_PIC32MACProcess() for:
• Processing its pending TX queues
• RX buffers replenishing functionality. If the number of packets in the RX queue falls below a specified limit, the MAC driver may use this
function to allocate some extra RX packets. Similarly, if there are too many allocated RX packets, the MAC driver can free some of them.
Preconditions
DRV_ETHMAC_PIC32MACInitialize() should have been called. DRV_ETHMAC_PIC32MACOpen() should have been called to obtain a valid
handle.
Example
Parameters
Parameters Description
hMac Ethernet MAC client handle
Function
TCPIP_MAC_RES DRV_ETHMAC_PIC32MACProcess( DRV_HANDLE hMac);
DRV_ETHMAC_PIC32MACStatisticsGet Function
Gets the current MAC statistics.
Implementation: Dynamic
File
drv_ethmac.h
C
TCPIP_MAC_RES DRV_ETHMAC_PIC32MACStatisticsGet(DRV_HANDLE hMac, TCPIP_MAC_RX_STATISTICS* pRxStatistics,
TCPIP_MAC_TX_STATISTICS* pTxStatistics);
Returns
• TCPIP_MAC_RES_OK if all processing went on OK.
• TCPIP_MAC_RES_OP_ERR error code if function not supported by the driver.
Description
This function will get the current value of the statistic counters maintained by the MAC driver.
Remarks
• The reported values are info only and change dynamically.
Preconditions
DRV_ETHMAC_PIC32MACInitialize() should have been called. DRV_ETHMAC_PIC32MACOpen() should have been called to obtain a valid
handle.
Example
Function
TCPIP_MAC_RES DRV_ETHMAC_PIC32MACStatisticsGet( DRV_HANDLE hMac, TCPIP_MAC_RX_STATISTICS* pRxStatistics,
TCPIP_MAC_TX_STATISTICS* pTxStatistics);
DRV_ETHMAC_PIC32MACStatus Function
Provides the current status of the MAC driver module.
Implementation: Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet MAC Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 458
File
drv_ethmac.h
C
SYS_STATUS DRV_ETHMAC_PIC32MACStatus(SYS_MODULE_OBJ object);
Returns
• SYS_STATUS_READY - Indicates that any previous module operation for the specified module has completed
• SYS_STATUS_BUSY - Indicates that a previous module operation for the specified module has not yet completed
• SYS_STATUS_ERROR - Indicates that the specified module is in an error state
Description
This function provides the current status of the MAC driver module.
Remarks
None.
Preconditions
The DRV_ETHMAC_PIC32MACInitialize function must have been called before calling this function.
Example
Parameters
Parameters Description
object Driver object handle, returned from DRV_ETHMAC_PIC32MACInitialize
Function
SYS_STATUS DRV_ETHMAC_PIC32MACStatus ( SYS_MODULE_OBJ object )
DRV_ETHMAC_PIC32MACConfigGet Function
Gets the current MAC driver configuration.
Implementation: Dynamic
File
drv_ethmac.h
C
size_t DRV_ETHMAC_PIC32MACConfigGet(DRV_HANDLE hMac, void* configBuff, size_t buffSize, size_t*
pConfigSize);
Returns
• number of bytes copied into the supplied storage buffer
Description
This function will get the current MAC driver configuration and store it into a supplied buffer.
Remarks
• None
Preconditions
DRV_ETHMAC_PIC32MACInitialize() should have been called. DRV_ETHMAC_PIC32MACOpen() should have been called to obtain a valid
handle.
Example
Function
size_t DRV_ETHMAC_PIC32MACConfigGet( DRV_HANDLE hMac, void* configBuff, size_t buffSize, size_t* pConfigSize);
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet MAC Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 459
DRV_ETHMAC_PIC32MACRegisterStatisticsGet Function
Gets the current MAC hardware statistics registers.
Implementation: Dynamic
File
drv_ethmac.h
C
TCPIP_MAC_RES DRV_ETHMAC_PIC32MACRegisterStatisticsGet(DRV_HANDLE hMac, TCPIP_MAC_STATISTICS_REG_ENTRY*
pRegEntries, int nEntries, int* pHwEntries);
Returns
• TCPIP_MAC_RES_OK if all processing went on OK.
• TCPIP_MAC_RES_OP_ERR error code if function not supported by the driver.
Description
This function will get the current value of the statistic registers of the associated MAC controller.
Remarks
• The reported values are info only and change dynamically.
Preconditions
DRV_ETHMAC_PIC32MACInitialize() should have been called. DRV_ETHMAC_PIC32MACOpen() should have been called to obtain a valid
handle.
Example
Function
TCPIP_MAC_RES DRV_ETHMAC_PIC32MACRegisterStatisticsGet( DRV_HANDLE hMac, TCPIP_MAC_STATISTICS_REG_ENTRY*
pRegEntries, int nEntries, int* pHwEntries);
DRV_ETHMAC_PIC32MACReinitialize Function
Reinitializes the PIC32 Ethernet MAC.
Implementation: Dynamic
File
drv_ethmac.h
C
void DRV_ETHMAC_PIC32MACReinitialize(SYS_MODULE_OBJ object, const SYS_MODULE_INIT * const init);
Returns
None.
Description
This function supports re-initialization of the PIC32 Ethernet MAC (opposite of set up).
Remarks
This function is not supported yet.
Preconditions
DRV_ETHMAC_PIC32MACInitialize must have been called to set up the driver.
Example
Function
void DRV_ETHMAC_PIC32MACReinitialize(SYS_MODULE_OBJ object, const SYS_MODULE_INIT * const init);
b) Receive Functions
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet MAC Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 460
DRV_ETHMAC_PIC32MACPacketRx Function
This is the MAC receive function.
Implementation: Dynamic
File
drv_ethmac.h
C
TCPIP_MAC_PACKET* DRV_ETHMAC_PIC32MACPacketRx(DRV_HANDLE hMac, TCPIP_MAC_RES* pRes, const
TCPIP_MAC_PACKET_RX_STAT** ppPktStat);
Returns
• a valid pointer to an available RX packet
• 0 if no packet pending/available
Description
This function will return a packet if such a pending packet exists.
Additional information about the packet is available by providing the pRes and ppPktStat fields.
Remarks
• Once a pending packet is available in the MAC driver internal RX queues this function will dequeue the packet and hand it over to the MAC
driver's client - i.e., the stack - for further processing.
• The flags for a RX packet are updated by the MAC driver:
• TCPIP_MAC_PKT_FLAG_RX will be set
• TCPIP_MAC_PKT_FLAG_UNICAST is set if that packet is a unicast packet
• TCPIP_MAC_PKT_FLAG_BCAST is set if that packet is a broadcast packet
• TCPIP_MAC_PKT_FLAG_MCAST is set if that packet is a multicast packet
• TCPIP_MAC_PKT_FLAG_QUEUED is set
• TCPIP_MAC_PKT_FLAG_SPLIT is set if the packet has multiple data segments
• The MAC driver dequeues and return to the caller just one single packet. That is the packets are not chained.
• The packet buffers are allocated by the Ethernet MAC driver itself, Once the higher level layers in the stack are done with processing the RX
packet, they have to call the corresponding packet acknowledgment function that tells the MAC driver that it can resume control of that packet.
• Once the stack modules are done processing the RX packets and the acknowledge function is called the MAC driver will reuse the RX packets.
• The MAC driver may use the DRV_ETHMAC_PIC32MACProcess() for obtaining new RX packets if needed.
Preconditions
DRV_ETHMAC_PIC32MACInitialize() should have been called. DRV_ETHMAC_PIC32MACOpen() should have been called to obtain a valid
handle.
Example
Function
TCPIP_MAC_PACKET* DRV_ETHMAC_PIC32MACPacketRx ( DRV_HANDLE hMac, TCPIP_MAC_RES* pRes, const
TCPIP_MAC_PACKET_RX_STAT** ppPktStat);
DRV_ETHMAC_PIC32MACRxFilterHashTableEntrySet Function
Sets the current MAC hash table receive filter.
Implementation: Dynamic
File
drv_ethmac.h
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet MAC Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 461
C
TCPIP_MAC_RES DRV_ETHMAC_PIC32MACRxFilterHashTableEntrySet(DRV_HANDLE hMac, const TCPIP_MAC_ADDR*
DestMACAddr);
Returns
• TCPIP_MAC_RES_OK if success
• a TCPIP_MAC_RES error value if failed
Description
This function sets the MAC hash table filtering to allow packets sent to DestMACAddr to be received. It calculates a CRC-32 using polynomial
0x4C11DB7 over the 6 byte MAC address and then, using bits 28:23 of the CRC, will set the appropriate bits in the hash table filter registers (
ETHHT0-ETHHT1).
The function will enable/disable the Hash Table receive filter if needed.
Remarks
• Sets the appropriate bit in the ETHHT0/1 registers to allow packets sent to DestMACAddr to be received and enabled the Hash Table receive
filter.
• There is no way to individually remove destination MAC addresses from the hash table since it is possible to have a hash collision and
therefore multiple MAC addresses relying on the same hash table bit.
• A workaround is to have the stack store each enabled MAC address and to perform the comparison at run time.
• A call to DRV_ETHMAC_PIC32MACRxFilterHashTableEntrySet() using a 00-00-00-00-00-00 destination MAC address, which will clear the
entire hash table and disable the hash table filter. This will allow the receive of all packets, regardless of their destination
Preconditions
DRV_ETHMAC_PIC32MACInitialize() should have been called. DRV_ETHMAC_PIC32MACOpen() should have been called to obtain a valid
handle.
Example
Function
TCPIP_MAC_RES DRV_ETHMAC_PIC32MACRxFilterHashTableEntrySet( DRV_HANDLE hMac, const TCPIP_MAC_ADDR* DestMACAddr)
c) Transmit Functions
DRV_ETHMAC_PIC32MACPacketTx Function
MAC driver transmit function.
Implementation: Dynamic
File
drv_ethmac.h
C
TCPIP_MAC_RES DRV_ETHMAC_PIC32MACPacketTx(DRV_HANDLE hMac, TCPIP_MAC_PACKET * ptrPacket);
Returns
• TCPIP_MAC_RES_OK if success
• a TCPIP_MAC_RES error value if failed
Description
This is the MAC transmit function. Using this function a packet is submitted to the MAC driver for transmission.
Remarks
• The MAC driver supports internal queuing. A packet is rejected only if it's not properly formatted. Otherwise it will be scheduled for transmission
and queued internally if needed.
• Once the packet is scheduled for transmission the MAC driver will set the TCPIP_MAC_PKT_FLAG_QUEUED flag so that the stack is aware
that this packet is under processing and cannot be modified.
• Once the packet is transmitted, the TCPIP_MAC_PKT_FLAG_QUEUED will be cleared, the proper packet acknowledgment result (ackRes) will
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet MAC Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 462
be set and the packet acknowledgment function (ackFunc) will be called.
Preconditions
DRV_ETHMAC_PIC32MACInitialize() should have been called. DRV_ETHMAC_PIC32MACOpen() should have been called to obtain a valid
handle.
Example
Function
TCPIP_MAC_RES DRV_ETHMAC_PIC32MACPacketTx( DRV_HANDLE hMac, TCPIP_MAC_PACKET * ptrPacket);
d) Event Functions
DRV_ETHMAC_PIC32MACEventAcknowledge Function
Acknowledges and re-enables processed events.
Implementation: Dynamic
File
drv_ethmac.h
C
bool DRV_ETHMAC_PIC32MACEventAcknowledge(DRV_HANDLE hMac, TCPIP_MAC_EVENT tcpAckEv);
Returns
• true if events acknowledged
• false if no events to be acknowledged
Description
This function acknowledges and re-enables processed events. Multiple events can be ORed together as they are processed together. The events
acknowledged by this function should be the events that have been retrieved from the stack by calling
DRV_ETHMAC_PIC32MACEventPendingGet() or have been passed to the stack by the driver using the registered notification handler and have
been processed and have to be re-enabled.
Remarks
• All events should be acknowledged, in order to be re-enabled.
• Some events are fatal errors and should not be acknowledged ( TCPIP_MAC_EV_RX_BUSERR, TCPIP_MAC_EV_TX_BUSERR).
Driver/stack re-initialization is needed under such circumstances.
• Some events are just system/application behavior and they are intended only as simple info (TCPIP_MAC_EV_RX_OVFLOW,
TCPIP_MAC_EV_RX_BUFNA, TCPIP_MAC_EV_TX_ABORT, TCPIP_MAC_EV_RX_ACT).
• The TCPIP_MAC_EV_RX_FWMARK and TCPIP_MAC_EV_RX_EWMARK events are part of the normal flow control operation (if auto flow
control was enabled). They should be enabled alternatively, if needed.
• The events are persistent. They shouldn't be re-enabled unless they have been processed and the condition that generated them was
removed. Re-enabling them immediately without proper processing will have dramatic effects on system performance.
Preconditions
DRV_ETHMAC_PIC32MACInitialize() should have been called. DRV_ETHMAC_PIC32MACOpen() should have been called to obtain a valid
handle.
Example
DRV_ETHMAC_PIC32MACEventAcknowledge( hMac, stackNewEvents );
Function
bool DRV_ETHMAC_PIC32MACEventAcknowledge( DRV_HANDLE hMac, TCPIP_MAC_EVENT tcpAckEv);
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet MAC Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 463
DRV_ETHMAC_PIC32MACEventMaskSet Function
Enables/disables the MAC events.
Implementation: Dynamic
File
drv_ethmac.h
C
bool DRV_ETHMAC_PIC32MACEventMaskSet(DRV_HANDLE hMac, TCPIP_MAC_EVENT macEvents, bool enable);
Returns
always true, operation succeeded.
Description
This is a function that enables or disables the events to be reported to the Ethernet MAC client (TCP/IP stack).
All events that are to be enabled will be added to the notification process. All events that are to be disabled will be removed from the notification
process. The stack has to catch the events that are notified and process them. After that the stack should call
DRV_ETHMAC_PIC32MACEventAcknowledge() so that the events can be re-enable
The stack should process at least the following transfer events:
• TCPIP_MAC_EV_RX_PKTPEND
• TCPIP_MAC_EV_RX_DONE
• TCPIP_MAC_EV_TX_DONE
Remarks
• The event notification system enables the user of the TCP/IP stack to call into the stack for processing only when there are relevant events
rather than being forced to periodically call from within a loop.
• If the notification events are nil, the interrupt processing will be disabled. Otherwise, the event notification will be enabled and the interrupts
relating to the requested events will be enabled.
• Note that once an event has been caught by the stack ISR (and reported if a notification handler is in place) it will be disabled until the
DRV_ETHMAC_PIC32MACEventAcknowledge() is called.
Preconditions
DRV_ETHMAC_PIC32MACInitialize() should have been called. DRV_ETHMAC_PIC32MACOpen() should have been called to obtain a valid
handle.
Example
DRV_ETHMAC_PIC32MACEventMaskSet( hMac, TCPIP_MAC_EV_RX_OVFLOW | TCPIP_MAC_EV_RX_BUFNA, true );
Function
bool DRV_ETHMAC_PIC32MACEventMaskSet( DRV_HANDLE hMac, TCPIP_MAC_EVENT macEvents, bool enable);
DRV_ETHMAC_PIC32MACEventPendingGet Function
Returns the currently pending events.
Implementation: Dynamic
File
drv_ethmac.h
C
TCPIP_MAC_EVENT DRV_ETHMAC_PIC32MACEventPendingGet(DRV_HANDLE hMac);
Returns
The currently stack pending events.
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet MAC Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 464
Description
This function returns the currently pending Ethernet MAC events. Multiple events will be ORed together as they accumulate. The stack should
perform processing whenever a transmission related event (TCPIP_MAC_EV_RX_PKTPEND, TCPIP_MAC_EV_TX_DONE) is present. The
other, non critical events, may not be managed by the stack and passed to an user. They will have to be eventually acknowledged if re-enabling is
needed.
Remarks
• This is the preferred method to get the current pending MAC events. The stack maintains a proper image of the events from their occurrence to
their acknowledgment.
• Even with a notification handler in place it's better to use this function to get the current pending events rather than using the events passed by
the notification handler which could be stale.
• The events are persistent. They shouldn't be re-enabled unless they have been processed and the condition that generated them was
removed. Re-enabling them immediately without proper processing will have dramatic effects on system performance.
• The returned value is just a momentary value. The pending events can change any time.
Preconditions
DRV_ETHMAC_PIC32MACInitialize() should have been called. DRV_ETHMAC_PIC32MACOpen() should have been called to obtain a valid
handle.
Example
TCPIP_MAC_EVENT currEvents = DRV_ETHMAC_PIC32MACEventPendingGet( hMac);
Function
TCPIP_MAC_EVENT DRV_ETHMAC_PIC32MACEventPendingGet( DRV_HANDLE hMac)
e) Other Functions
DRV_ETHMAC_Tasks_ISR Function
Ethernet MAC driver interrupt function.
Implementation: Dynamic
File
drv_ethmac.h
C
void DRV_ETHMAC_Tasks_ISR(SYS_MODULE_OBJ macIndex);
Returns
None.
Description
This is the Ethernet MAC driver interrupt service routine. It processes the Ethernet related interrupts and notifies the events to the driver user (the
TCP/IP stack).
Remarks
None.
Preconditions
DRV_ETHMAC_PIC32MACInitialize() should have been called. The TCP/IP stack event notification should be enabled.
Function
void DRV_ETHMAC_Tasks_ISR( SYS_MODULE_OBJ macIndex )
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet MAC Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 465
DRV_ETHMAC_PIC32MACTasks Function
Maintains the EThernet MAC driver's state machine.
Implementation: Dynamic
File
drv_ethmac.h
C
void DRV_ETHMAC_PIC32MACTasks(SYS_MODULE_OBJ object);
Returns
None
Description
This function is used to maintain the driver's internal state machine
Remarks
None.
Preconditions
The DRV_ETHMAC_PIC32MACInitialize routine must have been called for the specified MAC driver instance.
Example
Function
void DRV_ETHMAC_PIC32MACTasks( SYS_MODULE_OBJ object )
f) Data Types and Constants
DRV_ETHMAC_INDEX_1 Macro
File
drv_ethmac.h
C
#define DRV_ETHMAC_INDEX_1 1
Description
This is macro DRV_ETHMAC_INDEX_1.
DRV_ETHMAC_INDEX_0 Macro
Ethernet driver index definitions.
File
drv_ethmac.h
C
#define DRV_ETHMAC_INDEX_0 0
Description
Ethernet Driver Module Index Numbers
These constants provide Ethernet driver index definitions.
Remarks
These constants should be used in place of hard-coded numeric literals.
These values should be passed into the MAC initialization routines to identify the driver instance in use.
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet MAC Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 466
DRV_ETHMAC_INDEX_COUNT Macro
Number of valid Ethernet driver indices.
File
drv_ethmac.h
C
#define DRV_ETHMAC_INDEX_COUNT ETH_NUMBER_OF_MODULES
Description
Ethernet Driver Module Index Count
This constant identifies number of valid Ethernet driver indices.
Remarks
This constant should be used in place of hard-coded numeric literals.
This value is derived from part-specific header files defined as part of the peripheral libraries.
Files
Files
Name Description
drv_ethmac.h Ethernet MAC device driver interface file
drv_ethmac_config.h Ethernet MAC driver configuration definitions template.
Description
This section lists the source and header files used by the Ethernet MAC Driver Library.
drv_ethmac.h
Ethernet MAC device driver interface file
Functions
Name Description
DRV_ETHMAC_PIC32MACClose Closes a client instance of the PIC32 MAC Driver.
Implementation: Dynamic
DRV_ETHMAC_PIC32MACConfigGet Gets the current MAC driver configuration.
Implementation: Dynamic
DRV_ETHMAC_PIC32MACDeinitialize Deinitializes the PIC32 Ethernet MAC.
Implementation: Dynamic
DRV_ETHMAC_PIC32MACEventAcknowledge Acknowledges and re-enables processed events.
Implementation: Dynamic
DRV_ETHMAC_PIC32MACEventMaskSet Enables/disables the MAC events.
Implementation: Dynamic
DRV_ETHMAC_PIC32MACEventPendingGet Returns the currently pending events.
Implementation: Dynamic
DRV_ETHMAC_PIC32MACInitialize Initializes the PIC32 Ethernet MAC.
Implementation: Dynamic
DRV_ETHMAC_PIC32MACLinkCheck Checks current link status.
Implementation: Dynamic
DRV_ETHMAC_PIC32MACOpen Opens a client instance of the PIC32 MAC Driver.
Implementation: Dynamic
DRV_ETHMAC_PIC32MACPacketRx This is the MAC receive function.
Implementation: Dynamic
DRV_ETHMAC_PIC32MACPacketTx MAC driver transmit function.
Implementation: Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet MAC Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 467
DRV_ETHMAC_PIC32MACParametersGet MAC parameter get function.
Implementation: Dynamic
DRV_ETHMAC_PIC32MACPowerMode Selects the current power mode for the Ethernet MAC.
Implementation: Dynamic
DRV_ETHMAC_PIC32MACProcess MAC periodic processing function.
Implementation: Dynamic
DRV_ETHMAC_PIC32MACRegisterStatisticsGet Gets the current MAC hardware statistics registers.
Implementation: Dynamic
DRV_ETHMAC_PIC32MACReinitialize Reinitializes the PIC32 Ethernet MAC.
Implementation: Dynamic
DRV_ETHMAC_PIC32MACRxFilterHashTableEntrySet Sets the current MAC hash table receive filter.
Implementation: Dynamic
DRV_ETHMAC_PIC32MACStatisticsGet Gets the current MAC statistics.
Implementation: Dynamic
DRV_ETHMAC_PIC32MACStatus Provides the current status of the MAC driver module.
Implementation: Dynamic
DRV_ETHMAC_PIC32MACTasks Maintains the EThernet MAC driver's state machine.
Implementation: Dynamic
DRV_ETHMAC_Tasks_ISR Ethernet MAC driver interrupt function.
Implementation: Dynamic
Macros
Name Description
DRV_ETHMAC_INDEX_0 Ethernet driver index definitions.
DRV_ETHMAC_INDEX_1 This is macro DRV_ETHMAC_INDEX_1.
DRV_ETHMAC_INDEX_COUNT Number of valid Ethernet driver indices.
Description
Ethernet MAC Device Driver Interface
The Ethernet MAC device driver provides a simple interface to manage the Ethernet peripheral. This file defines the interface definitions and
prototypes for the Ethernet MAC driver.
File Name
drv_ethmac.h
Company
Microchip Technology Inc.
drv_ethmac_config.h
Ethernet MAC driver configuration definitions template.
Macros
Name Description
DRV_ETHMAC_CLIENTS_NUMBER Selects the maximum number of clients.
DRV_ETHMAC_INDEX Ethernet MAC static index selection.
DRV_ETHMAC_INSTANCES_NUMBER Selects the maximum number of hardware instances that can be supported by the
dynamic driver.
DRV_ETHMAC_INTERRUPT_MODE Controls operation of the driver in the interrupt or polled mode.
DRV_ETHMAC_INTERRUPT_SOURCE Defines an override of the interrupt source in case of static driver.
DRV_ETHMAC_PERIPHERAL_ID Defines an override of the peripheral ID.
DRV_ETHMAC_POWER_STATE Defines an override of the power state of the Ethernet MAC driver.
Description
ETHMAC Driver Configuration Definitions for the template version
These definitions statically define the driver's mode of operation.
File Name
drv_ethmac_config.h
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet MAC Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 468
Company
Microchip Technology Inc.
Ethernet PHY Driver Library
This section describes the Ethernet PHY Driver Library.
Introduction
This library provides a low-level abstraction of the Ethernet PHY Driver Library that is available on the Microchip family of microcontrollers with a
convenient C language interface. It can be used to simplify low-level access to the module without the necessity of interacting directly with the
module's registers, there by hiding differences from one microcontroller variant to another.
Description
This library provides a software abstraction for configuring external Ethernet PHY devices for use with the on-chip PIC32 Ethernet Controller.
Using the Library
The user of this driver is the MPLAB Harmony TCP/IP Stack through its Ethernet MAC driver. This Ethernet PHY driver is not intended as a
system wide driver that the application or other system modules may use. It is intended for the sole use of the MPLAB Harmony TCP/IP stack and
implements the PHY driver required by the Ethernet MAC.
This topic describes the basic architecture and functionality of the Ethernet PHY driver and is meant for advanced users or TCP/IP Stack driver
developers.
Interface Header File: drv_ethphy.h
The interface to the Ethernet PHY library is defined in the drv_ethphy.h header file, which is included by the MPLAB Harmony TCP/IP stack.
Please refer to the What is MPLAB Harmony? section for how the library interacts with the framework.
Abstraction Model
This library provides a low-level abstraction of the Ethernet PHY Driver Library on Microchip's microcontrollers with a convenient C language
interface. This topic describes how that abstraction is modeled in software and introduces the library's interface.
Description
To understand how this library works you must first understand how an external Ethernet PHY interfaces with the Ethernet Controller. As shown in
Figure 1, the PHY has two interfaces, one for managing the PHY, known as the Serial Management Interface (SMI), for configuring the device and
a second, known as the Reduced Media Independent Interface (RMII), for transmit and receive data.
Figure 1: Typical External PHY Interface
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet PHY Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 469
The block diagram also shows an interrupt signal (nINT) going to a external interrupt pin on the host device and signals going to on-board LEDs to
show link state and link activity.
The SMI interface is also known as the MII Management (MIIM) interface. This control interface is standardized for all PHYs by Clause 22 of the
802.3 standard. It provides up to 32 16-bit registers on the PHY. The following table provides a summary of all 32 registers. Consult the data sheet
for the PHY device for the specific bit fields in each register.
Register
Address
Register Name Register Type
0 Control Basic
1 Status Basic
2, 3 PHY Identifier Extended
4 Auto-Negotiation
Advertisement
Extended
5 Auto-Negotiation Link
Partner Base Page
Ability
Extended
6 Auto-Negotiation
Expansion
Extended
7 Auto-Negotiation Next
Page Transmit
Extended
8 Auto-Negotiation Link
Partner Received
Next Page
Extended
9 MASTER-SLAVE
Control Register
Extended
10 MASTER-SLAVE
Status Register
Extended
11-14 Reserved Extended
15 Extended Status Reserved
16-31 Vendor Specific Extended
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet PHY Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 470
Library Overview
Refer to the Driver Library Overview section for information on how the driver operates in a system.
The library interface routines are divided into various sub-sections, which address one of the blocks or the overall operation of the Ethernet PHY
Driver Library
Library Interface Section Description
System Level Functions Routines that integrate the driver into the MPLAB Harmony framework.
Client Level Functions Open, Close, Link Status, Auto Negotiation.
SMI/MIIM Functions SMI/MIIM Management Interface.
External PHY Support Functions Provides the API for PHY support routines that the driver will call when setting up the
PHY. The driver library provides support for four PHYs.
Other Functions Functions that provide software version information.
Data Types and Constants C language typedefs and enums used by this library.
Configuring the Library
Macros
Name Description
DRV_ETHPHY_CLIENTS_NUMBER Selects the maximum number of clients.
DRV_ETHPHY_INDEX Ethernet PHY static index selection.
DRV_ETHPHY_INSTANCES_NUMBER Selects the maximum number of hardware instances that can be supported by the
dynamic driver.
DRV_ETHPHY_PERIPHERAL_ID Defines an override of the peripheral ID.
DRV_ETHPHY_NEG_DONE_TMO Value of the PHY negotiation complete time out as per IEEE 802.3 spec.
DRV_ETHPHY_NEG_INIT_TMO Value of the PHY negotiation initiation time out as per IEEE 802.3 spec.
DRV_ETHPHY_RESET_CLR_TMO Value of the PHY Reset self clear time out as per IEEE 802.3 spec.
Description
The configuration of the Ethernet PHY Driver Library is based on the file system_config.h.
This header file contains the configuration selection for the Ethernet PHY Driver Library. Based on the selections made, the Ethernet PHY Driver
Library may support the selected features.
This header can be placed anywhere; however, the path of this header needs to be present in the include search path for a successful build. Refer
to the Applications Help section for more details.
DRV_ETHPHY_CLIENTS_NUMBER Macro
Selects the maximum number of clients.
File
drv_ethphy_config.h
C
#define DRV_ETHPHY_CLIENTS_NUMBER 1
Description
Ethernet PHY Maximum Number of Clients This definition select the maximum number of clients that the Ethernet PHY driver can support at run
time. Not defining it means using a single client.
Remarks
The MAC driver is the client of the PHY driver. Multiple clients may be needed when access to MIIM bus (for PHY vendor specific functionality) is
needed through the PHY driver.
However MIIM operations are not supported when the PHY driver uses the MIIM driver for MIIM bus accesses. In this case the number of clients
should be 1 and the DRV_MIIM should be used for accessing the MIIM bus.
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet PHY Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 471
DRV_ETHPHY_INDEX Macro
Ethernet PHY static index selection.
File
drv_ethphy_config.h
C
#define DRV_ETHPHY_INDEX DRV_ETHPHY_INDEX_1
Description
Ethernet PHY Static Index Selection
This definition selects the Ethernet PHY static index for the driver object reference.
Remarks
This index is required to make a reference to the driver object.
DRV_ETHPHY_INSTANCES_NUMBER Macro
Selects the maximum number of hardware instances that can be supported by the dynamic driver.
File
drv_ethphy_config.h
C
#define DRV_ETHPHY_INSTANCES_NUMBER 1
Description
Ethernet PHY hardware instance configuration
This definition selects the maximum number of hardware instances that can be supported by the dynamic driver. Not defining it means using a
static driver.
Remarks
None.
DRV_ETHPHY_PERIPHERAL_ID Macro
Defines an override of the peripheral ID.
File
drv_ethphy_config.h
C
#define DRV_ETHPHY_PERIPHERAL_ID ETHPHY_ID_1
Description
Ethernet PHY Peripheral ID Selection
Defines an override of the peripheral ID, using macros.
Remarks
Some devices also support ETHPHY_ID_0
DRV_ETHPHY_NEG_DONE_TMO Macro
Value of the PHY negotiation complete time out as per IEEE 802.3 spec.
File
drv_ethphy_config.h
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet PHY Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 472
C
#define DRV_ETHPHY_NEG_DONE_TMO (2000)
Description
Ethernet PHY Negotiation Complete time out
This definition sets the time out of the PHY negotiation complete, in ms.
Remarks
See IEEE 802.3 Clause 28 Table 28-9 autoneg_wait_timer value (max 1s).
DRV_ETHPHY_NEG_INIT_TMO Macro
Value of the PHY negotiation initiation time out as per IEEE 802.3 spec.
File
drv_ethphy_config.h
C
#define DRV_ETHPHY_NEG_INIT_TMO (1)
Description
Ethernet PHY Negotiation Initiation time out
This definition sets the time out of the PHY negotiation initiation, in ms.
Remarks
None.
DRV_ETHPHY_RESET_CLR_TMO Macro
Value of the PHY Reset self clear time out as per IEEE 802.3 spec.
File
drv_ethphy_config.h
C
#define DRV_ETHPHY_RESET_CLR_TMO (500)
Description
Ethernet PHY Reset self clear time out
This definition sets the time out of the PHY Reset self clear, in ms.
Remarks
See IEEE 802.3 Clause 22 Table 22-7 and paragraph "22.2.4.1.1 Reset" (max 0.5s)
Building the Library
This section lists the files that are available in the Ethernet PHY Driver Library.
Description
The following three tables list and describe the header (.h) and source (.c) files that implement this library. The parent folder for these files is
/framework/driver/ethphy.
Interface File(s)
This table lists and describes the header files that must be included (i.e., using #include) by any code that uses this library.
Source File Name Description
/drv_ethphy.h Header file that exports the driver API.
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet PHY Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 473
Required File(s)
All of the required files listed in the following table are automatically added into the MPLAB X IDE project by the MHC
when the library is selected for use.
This table lists and describes the source and header files that must always be included in the MPLAB X IDE project to build this library.
Source File Name Description
/src/dynamic/drv_extphy.c Basic PHY driver implementation file.
Optional File(s)
This table lists and describes the source and header files that may optionally be included if required for the desired implementation.
Source File Name Description
/src/dynamic/drv_extphy_smsc8700.c SMSC 8700 PHY implementation file.
/src/dynamic/drv_extphy_smsc8720.c SMSC 8720 PHY implementation file.
/src/dynamic/drv_extphy_smsc8720.c SMSC 8740 PHY implementation file.
/src/dynamic/drv_extphy_ip101gr.c IP101GR PHY implementation file.
/src/dynamic/drv_extphy_dp83640.c National DP83640 PHY implementation file.
/src/dynamic/drv_extphy_dp83848.c National DP83848 PHY implementation file.
Module Dependencies
The Ethernet MAC Driver Library depends on the following modules:
• Ethernet MAC Driver Library
• Clock System Service Library
• Ports System Service Library
• Timer System Service Library
• Ethernet Peripheral Library
Library Interface
a) System Level Functions
Name Description
DRV_ETHPHY_Initialize Initializes the Ethernet PHY driver.
Implementation: Dynamic
DRV_ETHPHY_Deinitialize Deinitializes the specified instance of the Ethernet PHY driver module.
Implementation: Dynamic
DRV_ETHPHY_Reinitialize Reinitializes the driver and refreshes any associated hardware settings.
Implementation: Dynamic
DRV_ETHPHY_Status Provides the current status of the Ethernet PHY driver module.
Implementation: Dynamic
DRV_ETHPHY_Tasks Maintains the driver's state machine and implements its ISR.
Implementation: Dynamic
DRV_ETHPHY_HWConfigFlagsGet Returns the current Ethernet PHY hardware MII/RMII and ALTERNATE/DEFAULT
configuration flags.
Implementation: Dynamic
DRV_ETHPHY_Setup Initializes Ethernet PHY configuration and set up procedure.
Implementation: Dynamic
b) Client Level Functions
Name Description
DRV_ETHPHY_ClientStatus Gets the current client-specific status the Ethernet PHY driver.
Implementation: Dynamic
DRV_ETHPHY_Close Closes an opened instance of the Ethernet PHY driver.
Implementation: Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet PHY Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 474
DRV_ETHPHY_Open Opens the specified Ethernet PHY driver instance and returns a handle to it.
Implementation: Dynamic
DRV_ETHPHY_Reset Immediately resets the Ethernet PHY.
Implementation: Dynamic
DRV_ETHPHY_ClientOperationAbort Aborts a current client operation initiated by the Ethernet PHY driver.
Implementation: Dynamic
DRV_ETHPHY_ClientOperationResult Gets the result of a client operation initiated by the Ethernet PHY driver.
Implementation: Dynamic
c) SMI/MIIM Functions
Name Description
DRV_ETHPHY_SMIScanStatusGet Gets the status of the SMI/MIIM scan data.
Implementation: Dynamic
DRV_ETHPHY_SMIScanStop Stops the scan of a previously requested SMI/MIIM register.
Implementation: Dynamic
DRV_ETHPHY_SMIClockSet Sets the SMI/MIIM interface clock.
Implementation: Dynamic
DRV_ETHPHY_SMIScanStart Starts the scan of a requested SMI/MIIM register.
Implementation: Dynamic
DRV_ETHPHY_SMIRead Initiates a SMI/MIIM read transaction.
Implementation: Dynamic
DRV_ETHPHY_SMIScanDataGet Gets the latest SMI/MIIM scan data result.
Implementation: Dynamic
DRV_ETHPHY_SMIStatus Returns the current status of the SMI/MIIM interface.
Implementation: Dynamic
DRV_ETHPHY_SMIWrite Initiates a SMI/MIIM write transaction.
Implementation: Dynamic
d) Vendor Functions
Name Description
DRV_ETHPHY_VendorDataGet Returns the current value of the vendor data.
Implementation: Dynamic
DRV_ETHPHY_VendorDataSet Returns the current value of the vendor data.
Implementation: Dynamic
DRV_ETHPHY_VendorSMIReadResultGet Reads the result of a previous vendor initiated SMI read transfer with
DRV_ETHPHY_VendorSMIReadStart.
Implementation: Dynamic
DRV_ETHPHY_VendorSMIReadStart Starts a vendor SMI read transfer. Data will be available with
DRV_ETHPHY_VendorSMIReadResultGet.
Implementation: Dynamic
DRV_ETHPHY_VendorSMIWriteStart Starts a vendor SMI write transfer.
Implementation: Dynamic
e) Other Functions
Name Description
DRV_ETHPHY_LinkStatusGet Returns the current link status.
Implementation: Dynamic
DRV_ETHPHY_NegotiationIsComplete Returns the results of a previously initiated Ethernet PHY negotiation.
Implementation: Dynamic
DRV_ETHPHY_NegotiationResultGet Returns the result of a completed negotiation.
Implementation: Dynamic
DRV_ETHPHY_PhyAddressGet Returns the PHY address.
Implementation: Dynamic
DRV_ETHPHY_RestartNegotiation Restarts auto-negotiation of the Ethernet PHY link.
Implementation: Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet PHY Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 475
f) Data Types and Constants
Name Description
DRV_ETHPHY_CLIENT_STATUS Identifies the client-specific status of the Ethernet PHY driver.
DRV_ETHPHY_INIT Contains all the data necessary to initialize the Ethernet PHY device.
DRV_ETHPHY_NEGOTIATION_RESULT Contains all the data necessary to get the Ethernet PHY negotiation result
DRV_ETHPHY_SETUP Contains all the data necessary to set up the Ethernet PHY device.
DRV_ETHPHY_VENDOR_MDIX_CONFIGURE Pointer to function that configures the MDIX mode for the Ethernet PHY.
DRV_ETHPHY_VENDOR_MII_CONFIGURE Pointer to function to configure the Ethernet PHY in one of the MII/RMII operation
modes.
DRV_ETHPHY_VENDOR_SMI_CLOCK_GET Pointer to a function to return the SMI/MIIM maximum clock speed in Hz of the
Ethernet PHY.
DRV_ETHPHY_INDEX_0 Ethernet PHY driver index definitions.
DRV_ETHPHY_INDEX_1 This is macro DRV_ETHPHY_INDEX_1.
DRV_ETHPHY_INDEX_COUNT Number of valid Ethernet PHY driver indices.
DRV_ETHPHY_LINK_STATUS Defines the possible status flags of PHY Ethernet link.
DRV_ETHPHY_CONFIG_FLAGS Defines configuration options for the Ethernet PHY.
DRV_ETHPHY_OBJECT Identifies the interface of a Ethernet PHY vendor driver.
DRV_ETHPHY_VENDOR_WOL_CONFIGURE Pointer to a function to configure the PHY WOL functionality
DRV_ETHPHY_OBJECT_BASE_TYPE Identifies the base interface of a Ethernet PHY driver.
DRV_ETHPHY_OBJECT_BASE Identifies the base interface of a Ethernet PHY driver.
DRV_ETHPHY_RESET_FUNCTION Pointer to a function to perform an additional PHY reset
DRV_ETHPHY_RESULT Defines the possible results of Ethernet operations that can succeed or fail
DRV_ETHPHY_USE_DRV_MIIM Defines the way the PHY driver accesses the MIIM bus to communicate with the
PHY.
DRV_ETHPHY_INTERFACE_INDEX Defines the index type for a PHY interface.
DRV_ETHPHY_INTERFACE_TYPE Defines the type of interface a PHY supports.
Description
This section describes the Application Programming Interface (API) functions of the Ethernet PHY Driver Library.
Refer to each section for a detailed description.
a) System Level Functions
DRV_ETHPHY_Initialize Function
Initializes the Ethernet PHY driver.
Implementation: Dynamic
File
drv_ethphy.h
C
SYS_MODULE_OBJ DRV_ETHPHY_Initialize(const SYS_MODULE_INDEX index, const SYS_MODULE_INIT * const init);
Returns
• a valid handle to a driver object, if successful.
• SYS_MODULE_OBJ_INVALID if initialization failed.
Description
This function initializes the Ethernet PHY driver, making it ready for clients to open and use it.
Remarks
• This function must be called before any other Ethernet PHY routine is called.
• This function should only be called once during system initialization unless DRV_ETHPHY_Deinitialize is called to deinitialize the driver
instance.
• The returned object must be passed as argument to DRV_ETHPHY_Reinitialize, DRV_ETHPHY_Deinitialize, DRV_ETHPHY_Tasks and
DRV_ETHPHY_Status routines.
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet PHY Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 476
Preconditions
None.
Example
DRV_ETHPHY_INIT init;
SYS_MODULE_OBJ objectHandle;
// Populate the Ethernet PHY initialization structure
init.phyId = ETHPHY_ID_0;
// Populate the Ethernet PHY initialization structure
init.phyId = ETHPHY_ID_2;
init.pPhyObject = &DRV_ETHPHY_OBJECT_SMSC_LAN8720;
// Do something
objectHandle = DRV_ETHPHY_Initialize(DRV_ETHPHY_INDEX_0, (SYS_MODULE_INIT*)&init);
if (SYS_MODULE_OBJ_INVALID == objectHandle)
{
// Handle error
}
Function
SYS_MODULE_OBJ DRV_ETHPHY_Initialize( const SYS_MODULE_INDEX index,
const SYS_MODULE_INIT * const init )
DRV_ETHPHY_Deinitialize Function
Deinitializes the specified instance of the Ethernet PHY driver module.
Implementation: Dynamic
File
drv_ethphy.h
C
void DRV_ETHPHY_Deinitialize(SYS_MODULE_OBJ object);
Returns
None.
Description
This function deinitializes the specified instance of the Ethernet PHY driver module, disabling its operation (and any hardware) and invalidates all
of the internal data.
Remarks
• Once the Initialize operation has been called, the Deinitialize operation must be called before the Initialize operation can be called again.
Preconditions
The DRV_ETHPHY_Initialize function must have been called before calling this routine and a valid SYS_MODULE_OBJ must have been returned.
Example
SYS_MODULE_OBJ object; // Returned from DRV_ETHPHY_Initialize
SYS_STATUS status;
DRV_ETHPHY_Deinitialize(object);
status = DRV_ETHPHY_Status(object);
if (SYS_MODULE_DEINITIALIZED != status)
{
// Check again later if you need to know
// when the driver is deinitialized.
}
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet PHY Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 477
Function
void DRV_ETHPHY_Deinitialize ( SYS_MODULE_OBJ object )
DRV_ETHPHY_Reinitialize Function
Reinitializes the driver and refreshes any associated hardware settings.
Implementation: Dynamic
File
drv_ethphy.h
C
void DRV_ETHPHY_Reinitialize(SYS_MODULE_OBJ object, const SYS_MODULE_INIT * const init);
Returns
None.
Description
This function reinitializes the driver and refreshes any associated hardware settings using the initialization data given, but it will not interrupt any
ongoing operations.
Remarks
• This function can be called multiple times to reinitialize the module.
• This operation can be used to refresh any supported hardware registers as specified by the initialization data or to change the power state of
the module.
Preconditions
The DRV_ETHPHY_Initialize function must have been called before calling this routine and a valid SYS_MODULE_OBJ must have been returned.
Example
DRV_ETHPHY_INIT init;
SYS_MODULE_OBJ objectHandle;
// Populate the Ethernet PHY initialization structure
init.phyId = ETHPHY_ID_2;
init.pPhyObject = &DRV_ETHPHY_OBJECT_SMSC_LAN8720;
DRV_ETHPHY_Reinitialize(objectHandle, (SYS_MODULE_INIT*)&init);
phyStatus = DRV_ETHPHY_Status(objectHandle);
if (SYS_STATUS_BUSY == phyStatus)
{
// Check again later to ensure the driver is ready
}
else if (SYS_STATUS_ERROR >= phyStatus)
{
// Handle error
}
Function
void DRV_ETHPHY_Reinitialize( SYS_MODULE_OBJ object,
const SYS_MODULE_INIT * const init )
DRV_ETHPHY_Status Function
Provides the current status of the Ethernet PHY driver module.
Implementation: Dynamic
File
drv_ethphy.h
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet PHY Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 478
C
SYS_STATUS DRV_ETHPHY_Status(SYS_MODULE_OBJ object);
Returns
• SYS_STATUS_READY - Indicates that any previous module operation for the specified module has completed
• SYS_STATUS_BUSY - Indicates that a previous module operation for the specified module has not yet completed
• SYS_STATUS_ERROR - Indicates that the specified module is in an error state
Description
This function provides the current status of the Ethernet PHY driver module.
Remarks
• Any value greater than SYS_STATUS_READY is also a normal running state in which the driver is ready to accept new operations.
• SYS_STATUS_BUSY - Indicates that the driver is busy with a previous system level operation and cannot start another
• SYS_STATUS_ERROR - Indicates that the driver is in an error state
• Any value less than SYS_STATUS_ERROR is also an error state.
• SYS_MODULE_DEINITIALIZED - Indicates that the driver has been deinitialized
• The this operation can be used to determine when any of the driver's module level operations has completed.
• If the status operation returns SYS_STATUS_BUSY, the a previous operation has not yet completed. Once the status operation returns
SYS_STATUS_READY, any previous operations have completed.
• The value of SYS_STATUS_ERROR is negative (-1). Any value less than that is also an error state.
• This function will NEVER block waiting for hardware.
• If the Status operation returns an error value, the error may be cleared by calling the reinitialize operation. If that fails, the deinitialize operation
will need to be called, followed by the initialize operation to return to normal operations.
Preconditions
The DRV_ETHPHY_Initialize function must have been called before calling this function.
Example
SYS_MODULE_OBJ object; // Returned from DRV_ETHPHY_Initialize
SYS_STATUS status;
status = DRV_ETHPHY_Status(object);
if (SYS_STATUS_ERROR >= status)
{
// Handle error
}
Parameters
Parameters Description
object Driver object handle, returned from DRV_ETHPHY_Initialize
Function
SYS_STATUS DRV_ETHPHY_Status ( SYS_MODULE_OBJ object )
DRV_ETHPHY_Tasks Function
Maintains the driver's state machine and implements its ISR.
Implementation: Dynamic
File
drv_ethphy.h
C
void DRV_ETHPHY_Tasks(SYS_MODULE_OBJ object);
Returns
None
Description
This function is used to maintain the driver's internal state machine and implement its ISR for interrupt-driven implementations.
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet PHY Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 479
Remarks
• This function is normally not called directly by an application. It is called by the system's Tasks routine (SYS_Tasks)
• This function will never block or access any resources that may cause it to block.
Preconditions
The DRV_ETHPHY_Initialize routine must have been called for the specified Ethernet PHY driver instance.
Example
SYS_MODULE_OBJ object; // Returned from DRV_ETHPHY_Initialize
while (true)
{
DRV_ETHPHY_Tasks (object);
// Do other tasks
}
Function
void DRV_ETHPHY_Tasks( SYS_MODULE_OBJ object )
DRV_ETHPHY_HWConfigFlagsGet Function
Returns the current Ethernet PHY hardware MII/RMII and ALTERNATE/DEFAULT configuration flags.
Implementation: Dynamic
File
drv_ethphy.h
C
DRV_ETHPHY_RESULT DRV_ETHPHY_HWConfigFlagsGet(DRV_HANDLE handle, DRV_ETHPHY_CONFIG_FLAGS* pFlags);
Returns
DRV_ETHPHY_RES_OK - if the configuration flags successfully stored at pFlags DRV_ETHPHY_RESULT error code otherwise
Description
This function returns the current Ethernet PHY hardware MII/RMII and ALTERNATE/DEFAULT configuration flags from the Device Configuration
Fuse bits.
Remarks
None.
Preconditions
• The DRV_ETHPHY_Initialize routine must have been called.
• DRV_ETHPHY_Open must have been called to obtain a valid device handle.
• DRV_ETHPHY_Setup must have been called to properly configure the PHY
Example
Parameters
Parameters Description
handle Client's driver handle (returned from DRV_ETHPHY_Open)
pFlags address to store the hardware configuration
Function
DRV_ETHPHY_RESULT DRV_ETHPHY_HWConfigFlagsGet( DRV_HANDLE handle, DRV_ETHPHY_CONFIG_FLAGS* pFlags )
DRV_ETHPHY_Setup Function
Initializes Ethernet PHY configuration and set up procedure.
Implementation: Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet PHY Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 480
File
drv_ethphy.h
C
DRV_ETHPHY_RESULT DRV_ETHPHY_Setup(DRV_HANDLE handle, DRV_ETHPHY_SETUP* pSetUp, TCPIP_ETH_OPEN_FLAGS*
pSetupFlags);
Returns
• DRV_ETHPHY_RES_PENDING operation has been scheduled successfully
• an DRV_ETHPHY_RESULT error code if the set up procedure failed.
Description
This function initializes the Ethernet PHY communication. It tries to detect the external Ethernet PHY, to read the capabilities and find a match with
the requested features. Then, it programs the Ethernet PHY accordingly.
Remarks
PHY configuration may be a lengthy operation due to active negotiation that the PHY has to perform with the link party. The
DRV_ETHPHY_ClientStatus will repeatedly return DRV_ETHPHY_CLIENT_STATUS_BUSY until the set up procedure is complete (unless an
error detected at which an error code will be returned immediately).
Use DRV_ETHPHY_ClientStatus() and DRV_ETHPHY_ClientOperationResult() to check when the operation was completed and its outcome.
Preconditions
• The DRV_ETHPHY_Initialize routine must have been called.
• DRV_ETHPHY_Open must have been called to obtain a valid device handle.
Example
Function
DRV_ETHPHY_RESULT DRV_ETHPHY_Setup( DRV_HANDLE handle, DRV_ETHPHY_SETUP* pSetUp, TCPIP_ETH_OPEN_FLAGS*
pSetupFlags)
b) Client Level Functions
DRV_ETHPHY_ClientStatus Function
Gets the current client-specific status the Ethernet PHY driver.
Implementation: Dynamic
File
drv_ethphy.h
C
DRV_ETHPHY_CLIENT_STATUS DRV_ETHPHY_ClientStatus(DRV_HANDLE handle);
Returns
• DRV_ETHPHY_CLIENT_STATUS value describing the current status of the driver.
Description
This function gets the client-specific status of the Ethernet PHY driver associated with the given handle.
Remarks
This function will not block for hardware access and will immediately return the current status.
This function has to be used to check that a driver operation has completed. It will return DRV_ETHPHY_CLIENT_STATUS_BUSY when an
operation is in progress. It will return DRV_ETHPHY_CLIENT_STATUS_READY when the operation has completed.
Preconditions
• The DRV_ETHPHY_Initialize routine must have been called.
• DRV_ETHPHY_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE phyHandle; // Returned from DRV_ETHPHY_Open
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet PHY Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 481
DRV_ETHPHY_CLIENT_STATUS phyClientStatus;
phyClientStatus = DRV_ETHPHY_ClientStatus(phyHandle);
if(DRV_ETHPHY_CLIENT_STATUS_ERROR >= phyClientStatus)
{
// Handle the error
}
Function
DRV_ETHPHY_CLIENT_STATUS DRV_ETHPHY_ClientStatus( DRV_HANDLE handle )
DRV_ETHPHY_Close Function
Closes an opened instance of the Ethernet PHY driver.
Implementation: Dynamic
File
drv_ethphy.h
C
void DRV_ETHPHY_Close(DRV_HANDLE handle);
Returns
None
Description
This function closes an opened instance of the Ethernet PHY driver, invalidating the handle.
Remarks
• After calling this routine, the handle passed in "handle" must not be used with any of the remaining driver routines. A new handle must be
obtained by calling DRV_ETHPHY_Open before the caller may use the driver again.
• Usually there is no need for the driver client to verify that the Close operation has completed.
Preconditions
The DRV_ETHPHY_Initialize routine must have been called for the specified Ethernet PHY driver instance.
DRV_ETHPHY_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE handle; // Returned from DRV_ETHPHY_Open
DRV_ETHPHY_Close(handle);
Function
void DRV_ETHPHY_Close( DRV_HANDLE handle )
DRV_ETHPHY_Open Function
Opens the specified Ethernet PHY driver instance and returns a handle to it.
Implementation: Dynamic
File
drv_ethphy.h
C
DRV_HANDLE DRV_ETHPHY_Open(const SYS_MODULE_INDEX drvIndex, const DRV_IO_INTENT intent);
Returns
• valid open-instance handle if successful (a number identifying both the caller and the module instance).
• DRV_HANDLE_INVALID if an error occurs
Description
This function opens the specified Ethernet PHY driver instance and provides a handle that must be provided to all other client-level operations to
identify the caller and the instance of the driver.
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet PHY Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 482
Remarks
The handle returned is valid until the DRV_ETHPHY_Close routine is called.
This function will NEVER block waiting for hardware.
The intent parameter is not used. The PHY driver implements a non-blocking behavior.
Preconditions
The DRV_ETHPHY_Initialize function must have been called before calling this function.
Example
DRV_HANDLE handle;
handle = DRV_ETHPHY_Open(DRV_ETHPHY_INDEX_0, 0);
if (DRV_HANDLE_INVALID == handle)
{
// Unable to open the driver
}
Function
DRV_HANDLE DRV_ETHPHY_Open( const SYS_MODULE_INDEX drvIndex,
const DRV_IO_INTENT intent )
DRV_ETHPHY_Reset Function
Immediately resets the Ethernet PHY.
Implementation: Dynamic
File
drv_ethphy.h
C
DRV_ETHPHY_RESULT DRV_ETHPHY_Reset(DRV_HANDLE handle, bool waitComplete);
Returns
• DRV_ETHPHY_RES_PENDING for ongoing, in progress operation
• DRV_ETHPHY_RES_OPERATION_ERR - invalid parameter or operation in the current context
Description
This function immediately resets the Ethernet PHY, optionally waiting for a reset to complete.
Remarks
Use DRV_ETHPHY_ClientStatus() and DRV_ETHPHY_ClientOperationResult() to check when the operation was completed and its outcome.
When operation is completed but failed, DRV_ETHPHY_ClientOperationResult will return:
• DRV_ETHPHY_RES_DTCT_ERR if the PHY failed to respond
Preconditions
• The DRV_ETHPHY_Initialize routine must have been called.
• DRV_ETHPHY_Open must have been called to obtain a valid device handle.
• DRV_ETHPHY_Setup must have been called to properly configure the PHY
Example
Function
DRV_ETHPHY_RESULT DRV_ETHPHY_Reset( DRV_HANDLE handle, bool waitComplete )
DRV_ETHPHY_ClientOperationAbort Function
Aborts a current client operation initiated by the Ethernet PHY driver.
Implementation: Dynamic
File
drv_ethphy.h
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet PHY Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 483
C
DRV_ETHPHY_RESULT DRV_ETHPHY_ClientOperationAbort(DRV_HANDLE handle);
Returns
• DRV_ETHPHY_RESULT value describing the current operation result: DRV_ETHPHY_RES_OK for success; operation has been aborted an
DRV_ETHPHY_RESULT error code if the operation failed.
Description
Aborts a current client operation initiated by the Ethernet PHY driver.
Remarks
None
Preconditions
• The DRV_ETHPHY_Initialize routine must have been called.
• DRV_ETHPHY_Open must have been called to obtain a valid opened device handle.
• A driver operation was started
Example
Function
DRV_ETHPHY_RESULT DRV_ETHPHY_ClientOperationAbort( DRV_HANDLE handle)
DRV_ETHPHY_ClientOperationResult Function
Gets the result of a client operation initiated by the Ethernet PHY driver.
Implementation: Dynamic
File
drv_ethphy.h
C
DRV_ETHPHY_RESULT DRV_ETHPHY_ClientOperationResult(DRV_HANDLE handle);
Returns
• DRV_ETHPHY_RESULT value describing the current operation result: DRV_ETHPHY_RES_OK for success; operation has been completed
successfully DRV_ETHPHY_RES_PENDING operation is in progress an DRV_ETHPHY_RESULT error code if the operation failed.
Description
Returns the result of a client operation initiated by the Ethernet PHY driver.
Remarks
This function will not block for hardware access and will immediately return the current status.
This function returns the result of the last driver operation. It will return DRV_ETHPHY_RES_PENDING if an operation is still in progress.
Otherwise a DRV_ETHPHY_RESULT describing the operation outcome.
Preconditions
• The DRV_ETHPHY_Initialize routine must have been called.
• DRV_ETHPHY_Open must have been called to obtain a valid opened device handle.
• A driver operation was started and completed
Example
Function
DRV_ETHPHY_RESULT DRV_ETHPHY_ClientOperationResult( DRV_HANDLE handle)
c) SMI/MIIM Functions
DRV_ETHPHY_SMIScanStatusGet Function
Gets the status of the SMI/MIIM scan data.
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet PHY Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 484
Implementation: Dynamic
File
drv_ethphy.h
C
DRV_ETHPHY_RESULT DRV_ETHPHY_SMIScanStatusGet(DRV_HANDLE handle);
Returns
DRV_ETHPHY_RES_OPERATION_ERR - no scan operation currently in progress
DRV_ETHPHY_RES_OK - scan data is available
DRV_ETHPHY_RES_PENDING - scan data is not yet available
< 0 - an error has occurred and the operation could not be completed
Description
This function gets the status of the SMI/MIIM scan data.
Remarks
This operation is not supported when the PHY driver uses the MIIM driver for MIIM bus accesses. Use the DRV_MIIM for accessing the MIIM bus.
Preconditions
• The DRV_ETHPHY_Initialize routine must have been called.
• DRV_ETHPHY_Open must have been called to obtain a valid device handle.
• DRV_ETHPHY_Setup must have been called to properly configure the PHY
• DRV_ETHPHY_SMIScanStart() has been called.
Example
Function
DRV_ETHPHY_RESULT DRV_ETHPHY_SMIScanStatusGet( DRV_HANDLE handle )
DRV_ETHPHY_SMIScanStop Function
Stops the scan of a previously requested SMI/MIIM register.
Implementation: Dynamic
File
drv_ethphy.h
C
DRV_ETHPHY_RESULT DRV_ETHPHY_SMIScanStop(DRV_HANDLE handle);
Returns
DRV_ETHPHY_RES_OPERATION_ERR - no scan operation currently in progress
DRV_ETHPHY_RES_OK - the scan transaction has been stopped successfully < 0 - an error has occurred and the operation could not be
completed
Description
This function stops the current scan of a SMI/MIIM register.
Remarks
This operation is not supported when the PHY driver uses the MIIM driver for MIIM bus accesses. Use the DRV_MIIM for accessing the MIIM bus.
Preconditions
• The DRV_ETHPHY_Initialize routine must have been called.
• DRV_ETHPHY_Open must have been called to obtain a valid device handle.
• DRV_ETHPHY_Setup must have been called to properly configure the PHY
• DRV_ETHPHY_SMIScanStart was called to start a scan
Example
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet PHY Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 485
Function
DRV_ETHPHY_RESULT DRV_ETHPHY_SMIScanStop( DRV_HANDLE handle )
DRV_ETHPHY_SMIClockSet Function
Sets the SMI/MIIM interface clock.
Implementation: Dynamic
File
drv_ethphy.h
C
DRV_ETHPHY_RESULT DRV_ETHPHY_SMIClockSet(DRV_HANDLE handle, uint32_t hostClock, uint32_t maxSMIClock);
Returns
DRV_ETHPHY_RES_HANDLE_ERR - passed in handle was invalid
DRV_ETHPHY_RES_OK - operation successful
< 0 - an error has occurred and the operation could not be completed
Description
This function sets SMI/MIIM interface clock base on host clock and maximum supported SMI/MIIM interface clock speed.
Remarks
This operation is not supported when the PHY driver uses the MIIM driver for MIIM bus accesses. Use the DRV_MIIM for accessing the MIIM bus.
Preconditions
• The DRV_ETHPHY_Initialize routine must have been called.
• DRV_ETHPHY_Open must have been called to obtain a valid device handle.
• DRV_ETHPHY_Setup must have been called to properly configure the PHY
Example
Function
DRV_ETHPHY_RESULT DRV_ETHPHY_SMIClockSet( DRV_HANDLE handle,
uint32_t hostClock,
uint32_t maxSMIClock )
DRV_ETHPHY_SMIScanStart Function
Starts the scan of a requested SMI/MIIM register.
Implementation: Dynamic
File
drv_ethphy.h
C
DRV_ETHPHY_RESULT DRV_ETHPHY_SMIScanStart(DRV_HANDLE handle, unsigned int rIx);
Returns
DRV_ETHPHY_RES_PENDING - the scan transaction was initiated and is ongoing < 0 - an error has occurred and the operation could not be
completed
Description
This function starts the scan of a requested SMI/MIIM register.
Remarks
Use DRV_ETHPHY_ClientStatus() and DRV_ETHPHY_ClientOperationResult() to check when the operation was completed and its outcome.
However, the client status will always be DRV_ETHPHY_CLIENT_STATUS_BUSY and the client result will always show
DRV_ETHPHY_RES_PENDING for as long as the scan is active. Use DRV_ETHPHY_SMIScanStop() to stop a scan in progress. Use
DRV_ETHPHY_SMIScanStatusGet() to check is there is scan data available. Use DRV_ETHPHY_SMIScanDataGet() to retrieve the scan data.
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet PHY Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 486
This operation is not supported when the PHY driver uses the MIIM driver for MIIM bus accesses. Use the DRV_MIIM for accessing the MIIM bus.
Preconditions
• The DRV_ETHPHY_Initialize routine must have been called.
• DRV_ETHPHY_Open must have been called to obtain a valid device handle.
• DRV_ETHPHY_Setup must have been called to properly configure the PHY
Example
Function
DRV_ETHPHY_RESULT DRV_ETHPHY_SMIScanStart( DRV_HANDLE handle,
unsigned int rIx)
DRV_ETHPHY_SMIRead Function
Initiates a SMI/MIIM read transaction.
Implementation: Dynamic
File
drv_ethphy.h
C
DRV_ETHPHY_RESULT DRV_ETHPHY_SMIRead(DRV_HANDLE handle, unsigned int rIx, uint16_t* pSmiRes, int phyAdd);
Returns
DRV_ETHPHY_RES_PENDING - the transaction was initiated and is ongoing < 0 - an error has occurred and the operation could not be
completed
Description
This function initiates a SMI/MIIM read transaction for a given PHY register.
Remarks
In most situations the PHY address to be used for this function should be the one returned by DRV_ETHPHY_PhyAddressGet(). However this
function allows using a different PHY address for advanced operation.
Use DRV_ETHPHY_ClientStatus() and DRV_ETHPHY_ClientOperationResult() to check when the operation was completed and its outcome.
This operation is not supported when the PHY driver uses the MIIM driver for MIIM bus accesses. Use the DRV_MIIM for accessing the MIIM bus.
Preconditions
• The DRV_ETHPHY_Initialize routine must have been called.
• DRV_ETHPHY_Open must have been called to obtain a valid opened device handle.
• DRV_ETHPHY_Setup must have been called to properly configure the PHY
Example
Function
DRV_ETHPHY_RESULT DRV_ETHPHY_SMIRead( DRV_HANDLE handle, unsigned int rIx, uint16_t* pSmiRes, int phyAdd)
DRV_ETHPHY_SMIScanDataGet Function
Gets the latest SMI/MIIM scan data result.
Implementation: Dynamic
File
drv_ethphy.h
C
DRV_ETHPHY_RESULT DRV_ETHPHY_SMIScanDataGet(DRV_HANDLE handle, uint16_t* pScanRes);
Returns
DRV_ETHPHY_RES_OPERATION_ERR - no scan operation currently in progress
DRV_ETHPHY_RES_OK - scan data is available and stored at pScanRes DRV_ETHPHY_RES_PENDING - scan data is not yet available
< 0 - an error has occurred and the operation could not be completed
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet PHY Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 487
Description
This function gets the latest SMI/MIIM scan data result.
Remarks
This operation is not supported when the PHY driver uses the MIIM driver for MIIM bus accesses. Use the DRV_MIIM for accessing the MIIM bus.
Preconditions
• The DRV_ETHPHY_Initialize routine must have been called.
• DRV_ETHPHY_Open must have been called to obtain a valid device handle.
• DRV_ETHPHY_Setup must have been called to properly configure the PHY
• DRV_ETHPHY_SMIScanStart() has been called
• Data is available if DRV_ETHPHY_SMIScanStatusGet() previously returned DRV_ETHPHY_RES_OK
Example
Function
DRV_ETHPHY_RESULT DRV_ETHPHY_SMIScanDataGet( DRV_HANDLE handle, uint16_t* pScanRes )
DRV_ETHPHY_SMIStatus Function
Returns the current status of the SMI/MIIM interface.
Implementation: Dynamic
File
drv_ethphy.h
C
DRV_ETHPHY_RESULT DRV_ETHPHY_SMIStatus(DRV_HANDLE handle);
Returns
• DRV_ETHPHY_RES_BUSY - if the SMI/MIIM interface is busy
• DRV_ETHPHY_RES_OK - if the SMI/MIIM is not busy
< 0 - an error has occurred and the operation could not be completed
Description
This function checks if the SMI/MIIM interface is busy with a transaction.
Remarks
This function is info only and returns the momentary status of the SMI bus. Even if the bus is free there is no guarantee it will be free later on
especially if the driver is on going some operation.
This operation is not supported when the PHY driver uses the MIIM driver for MIIM bus accesses. Use the DRV_MIIM for accessing the MIIM bus.
Preconditions
• The DRV_ETHPHY_Initialize routine must have been called.
• DRV_ETHPHY_Open must have been called to obtain a valid device handle.
• DRV_ETHPHY_Setup must have been called to properly configure the PHY
Example
Function
DRV_ETHPHY_RESULT DRV_ETHPHY_SMIStatus( DRV_HANDLE handle )
DRV_ETHPHY_SMIWrite Function
Initiates a SMI/MIIM write transaction.
Implementation: Dynamic
File
drv_ethphy.h
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet PHY Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 488
C
DRV_ETHPHY_RESULT DRV_ETHPHY_SMIWrite(DRV_HANDLE handle, unsigned int rIx, uint16_t wData, int phyAdd, bool
waitComplete);
Returns
DRV_ETHPHY_RES_OK - the write transaction has been scheduled/completed successfully DRV_ETHPHY_RES_PENDING - the transaction
was initiated and is ongoing < 0 - an error has occurred and the operation could not be completed
Description
This function initiates a SMI/MIIM write transaction for a given PHY register.
Remarks
In most situations the PHY address to be used for this function should be the one returned by DRV_ETHPHY_PhyAddressGet(). However this
function allows using a different PHY address for advanced operation.
Use DRV_ETHPHY_ClientStatus() and DRV_ETHPHY_ClientOperationResult() to check when the operation was completed and its outcome.
This operation is not supported when the PHY driver uses the MIIM driver for MIIM bus accesses. Use the DRV_MIIM for accessing the MIIM bus.
Preconditions
• The DRV_ETHPHY_Initialize routine must have been called.
• DRV_ETHPHY_Open must have been called to obtain a valid device handle.
• DRV_ETHPHY_Setup must have been called to properly configure the PHY
Example
Function
DRV_ETHPHY_RESULT DRV_ETHPHY_SMIWrite( DRV_HANDLE handle, unsigned int rIx, uint16_t wData, int phyAdd, bool waitComplete)
d) Vendor Functions
DRV_ETHPHY_VendorDataGet Function
Returns the current value of the vendor data.
Implementation: Dynamic
File
drv_ethphy.h
C
DRV_ETHPHY_RESULT DRV_ETHPHY_VendorDataGet(DRV_HANDLE handle, uint32_t* pVendorData);
Returns
DRV_ETHPHY_RES_OK - if the vendor data is stored at the pVendorData address
DRV_ETHPHY_RES_HANDLE_ERR - handle error
Description
This function returns the current value of the vendor data. Each DRV_ETHPHY client object maintains data that could be used for vendor specific
operations. This routine allows retrieving of the vendor specific data.
Remarks
The PHY driver will clear the vendor specific data before any call to a vendor specific routine. Otherwise the PHY driver functions do not touch this
value.
The DRV_ETHPHY_VendorDataSet can be used for writing data into this field.
Currently only a 32 bit value is supported.
The function is intended for implementing vendor specific functions, like DRV_EXTPHY_MIIConfigure and DRV_EXTPHY_MDIXConfigure, that
need a way of maintaining their own data and state machine.
Preconditions
• The DRV_ETHPHY_Initialize routine must have been called.
• DRV_ETHPHY_Open must have been called to obtain a valid device handle.
• DRV_ETHPHY_Setup must have been called to properly configure the PHY
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet PHY Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 489
Example
Function
DRV_ETHPHY_RESULT DRV_ETHPHY_VendorDataGet( DRV_HANDLE handle, uint32_t* pVendorData )
DRV_ETHPHY_VendorDataSet Function
Returns the current value of the vendor data.
Implementation: Dynamic
File
drv_ethphy.h
C
DRV_ETHPHY_RESULT DRV_ETHPHY_VendorDataSet(DRV_HANDLE handle, uint32_t vendorData);
Returns
DRV_ETHPHY_RES_OK - if the vendor data is stored in the client object
DRV_ETHPHY_RES_HANDLE_ERR - handle error
Description
This function returns the current value of the vendor data. Each DRV_ETHPHY client object maintains data that could be used for vendor specific
operations. This routine allows retrieving of the vendor specific data.
Remarks
The PHY driver will clear the vendor specific data before any call to a vendor specific routine. Otherwise the PHY driver functions do not touch this
value.
The DRV_ETHPHY_VendorDataGet can be used for reading data into this field.
Currently only a 32 bit value is supported.
The function is intended for implementing vendor specific functions, like DRV_EXTPHY_MIIConfigure and DRV_EXTPHY_MDIXConfigure, that
need a way of maintaining their own data and state machine.
Preconditions
• The DRV_ETHPHY_Initialize routine must have been called.
• DRV_ETHPHY_Open must have been called to obtain a valid device handle.
• DRV_ETHPHY_Setup must have been called to properly configure the PHY
Example
Function
DRV_ETHPHY_RESULT DRV_ETHPHY_VendorDataSet( DRV_HANDLE handle, uint32_t vendorData )
DRV_ETHPHY_VendorSMIReadResultGet Function
Reads the result of a previous vendor initiated SMI read transfer with DRV_ETHPHY_VendorSMIReadStart.
Implementation: Dynamic
File
drv_ethphy.h
C
DRV_ETHPHY_RESULT DRV_ETHPHY_VendorSMIReadResultGet(DRV_HANDLE handle, uint16_t* pSmiRes);
Returns
DRV_ETHPHY_RES_OK - transaction complete and result deposited at pSmiRes.
DRV_ETHPHY_RES_PENDING - if the vendor transaction is still ongoing The call needs to be retried.
< 0 - some error and the DRV_EXTPHY_MIIConfigure/DRV_EXTPHY_MDIXConfigure has to return error to be aborted by the
DRV_ETHPHY_Setup
Description
This function will return the data of a SMI read transfer.
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet PHY Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 490
Remarks
The function is intended for implementing vendor SMI transfers within DRV_EXTPHY_MIIConfigure and DRV_EXTPHY_MDIXConfigure.
It has to be called from within the DRV_EXTPHY_MIIConfigure or DRV_EXTPHY_MDIXConfigure functions (which are called, in turn, by the
DRV_ETHPHY_Setup procedure) otherwise the call will fail.
The DRV_ETHPHY_RES_OK and DRV_ETHPHY_RES_PENDING significance is changed from the general driver API.
Preconditions
• The DRV_ETHPHY_Initialize routine must have been called.
• DRV_ETHPHY_Open must have been called to obtain a valid device handle.
• DRV_ETHPHY_Setup is in progress and configures the PHY
• The vendor implementation of the DRV_EXTPHY_MIIConfigure/DRV_EXTPHY_MDIXConfigure is running and a SMI transfer is needed
• DRV_ETHPHY_VendorSMIReadStart should have been called to initiate a transfer
Example
Function
DRV_ETHPHY_RESULT DRV_ETHPHY_VendorSMIReadResultGet( DRV_HANDLE handle, uint16_t* pSmiRes)
DRV_ETHPHY_VendorSMIReadStart Function
Starts a vendor SMI read transfer. Data will be available with DRV_ETHPHY_VendorSMIReadResultGet.
Implementation: Dynamic
File
drv_ethphy.h
C
DRV_ETHPHY_RESULT DRV_ETHPHY_VendorSMIReadStart(DRV_HANDLE handle, uint16_t rIx, int phyAddress);
Returns
DRV_ETHPHY_RES_OK - the vendor transaction is started DRV_ETHPHY_VendorSMIReadResultGet() needs to be called for the transaction to
complete and to retrieve the result
DRV_ETHPHY_RES_PENDING - the SMI bus is busy and the call needs to be retried
< 0 - some error and the DRV_EXTPHY_MIIConfigure/DRV_EXTPHY_MDIXConfigure has to return error to be aborted by the
DRV_ETHPHY_Setup
Description
This function will start a SMI read transfer.
Remarks
The function is intended for implementing vendor SMI transfers within DRV_EXTPHY_MIIConfigure and DRV_EXTPHY_MDIXConfigure.
It has to be called from within the DRV_EXTPHY_MIIConfigure or DRV_EXTPHY_MDIXConfigure functions (which are called, in turn, by the
DRV_ETHPHY_Setup procedure) otherwise the call will fail.
The DRV_ETHPHY_RES_OK and DRV_ETHPHY_RES_PENDING significance is changed from the general driver API.
Preconditions
• The DRV_ETHPHY_Initialize routine must have been called.
• DRV_ETHPHY_Open must have been called to obtain a valid device handle.
• DRV_ETHPHY_Setup is in progress and configures the PHY
• The vendor implementation of the DRV_EXTPHY_MIIConfigure/DRV_EXTPHY_MDIXConfigure is running and a SMI transfer is needed
Example
Function
DRV_ETHPHY_RESULT DRV_ETHPHY_VendorSMIReadStart( DRV_HANDLE handle, uint16_t rIx, int phyAddress )
DRV_ETHPHY_VendorSMIWriteStart Function
Starts a vendor SMI write transfer.
Implementation: Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet PHY Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 491
File
drv_ethphy.h
C
DRV_ETHPHY_RESULT DRV_ETHPHY_VendorSMIWriteStart(DRV_HANDLE handle, uint16_t rIx, uint16_t wData, int
phyAddress);
Returns
DRV_ETHPHY_RES_OK - if the vendor SMI write transfer is started
DRV_ETHPHY_RES_PENDING - the SMI bus was busy and the call needs to be retried
< 0 - some error and the DRV_EXTPHY_MIIConfigure/DRV_EXTPHY_MDIXConfigure has to return error to be aborted by the
DRV_ETHPHY_Setup
Description
This function will start a SMI write transfer.
Remarks
The function is intended for implementing vendor SMI transfers within DRV_EXTPHY_MIIConfigure and DRV_EXTPHY_MDIXConfigure.
It has to be called from within the DRV_EXTPHY_MIIConfigure or DRV_EXTPHY_MDIXConfigure functions (which are called, in turn, by the
DRV_ETHPHY_Setup procedure) otherwise the call will fail.
The DRV_ETHPHY_RES_OK and DRV_ETHPHY_RES_PENDING significance is changed from the general driver API.
Preconditions
• The DRV_ETHPHY_Initialize routine must have been called.
• DRV_ETHPHY_Open must have been called to obtain a valid device handle.
• DRV_ETHPHY_Setup is in progress and configures the PHY
• The vendor implementation of the DRV_EXTPHY_MIIConfigure/DRV_EXTPHY_MDIXConfigure is running and a SMI transfer is needed
Example
Function
DRV_ETHPHY_RESULT DRV_ETHPHY_VendorSMIWriteStart( DRV_HANDLE handle, uint16_t rIx, uint16_t wData, int phyAddress )
e) Other Functions
DRV_ETHPHY_LinkStatusGet Function
Returns the current link status.
Implementation: Dynamic
File
drv_ethphy.h
C
DRV_ETHPHY_RESULT DRV_ETHPHY_LinkStatusGet(DRV_HANDLE handle, DRV_ETHPHY_INTERFACE_INDEX portIndex,
DRV_ETHPHY_LINK_STATUS* pLinkStat, bool refresh);
Returns
• DRV_ETHPHY_RES_PENDING for ongoing, in progress operation
• an DRV_ETHPHY_RESULT error code if the link status get procedure failed.
Description
This function returns the current link status.
Remarks
This function reads the Ethernet PHY to get current link status. If refresh is specified then, if the link is down a second read will be performed to
return the current link status.
Use DRV_ETHPHY_ClientStatus() and DRV_ETHPHY_ClientOperationResult() to check when the operation was completed and its outcome.
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet PHY Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 492
Preconditions
• The DRV_ETHPHY_Initialize routine must have been called.
• DRV_ETHPHY_Open must have been called to obtain a valid device handle.
• DRV_ETHPHY_Setup must have been called to properly configure the PHY
Example
Function
DRV_ETHPHY_RESULT DRV_ETHPHY_LinkStatusGet( DRV_HANDLE handle, DRV_ETHPHY_LINK_STATUS* pLinkStat, bool refresh )
DRV_ETHPHY_NegotiationIsComplete Function
Returns the results of a previously initiated Ethernet PHY negotiation.
Implementation: Dynamic
File
drv_ethphy.h
C
DRV_ETHPHY_RESULT DRV_ETHPHY_NegotiationIsComplete(DRV_HANDLE handle, DRV_ETHPHY_INTERFACE_INDEX portIndex,
bool waitComplete);
Returns
• DRV_ETHPHY_RES_PENDING operation is ongoing
• an DRV_ETHPHY_RESULT error code if the procedure failed.
Description
This function returns the results of a previously initiated Ethernet PHY negotiation.
Remarks
Use DRV_ETHPHY_ClientStatus() and DRV_ETHPHY_ClientOperationResult() to check when the operation was completed and its outcome.
When operation is completed but negotiation has failed, DRV_ETHPHY_ClientOperationResult will return:
• DRV_ETHPHY_RES_NEGOTIATION_INACTIVE if no negotiation in progress
• DRV_ETHPHY_RES_NEGOTIATION_NOT_STARTED if negotiation not yet started yet (means time out if waitComplete was requested)
• DRV_ETHPHY_RES_NEGOTIATION_ACTIVE if negotiation ongoing
(means time out if waitComplete was requested).
See also DRV_ETHPHY_NegotiationResultGet.
Preconditions
• The DRV_ETHPHY_Initialize routine must have been called.
• DRV_ETHPHY_Open must have been called to obtain a valid device handle.
• DRV_ETHPHY_Setup must have been called to properly configure the PHY
• DRV_ETHPHY_RestartNegotiation should have been called.
Example
Function
DRV_ETHPHY_RESULT DRV_ETHPHY_NegotiationIsComplete( DRV_HANDLE handle, bool waitComplete )
DRV_ETHPHY_NegotiationResultGet Function
Returns the result of a completed negotiation.
Implementation: Dynamic
File
drv_ethphy.h
C
DRV_ETHPHY_RESULT DRV_ETHPHY_NegotiationResultGet(DRV_HANDLE handle, DRV_ETHPHY_INTERFACE_INDEX portIndex,
DRV_ETHPHY_NEGOTIATION_RESULT* pNegResult);
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet PHY Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 493
Returns
• DRV_ETHPHY_RES_PENDING operation is ongoing
• an DRV_ETHPHY_RESULT error code if the procedure failed.
Description
This function returns the PHY negotiation data gathered after a completed negotiation.
Remarks
Use DRV_ETHPHY_ClientStatus() and DRV_ETHPHY_ClientOperationResult() to check when the operation was completed and its outcome.
When operation is completed but negotiation has failed, DRV_ETHPHY_ClientOperationResult will return:
• DRV_ETHPHY_RES_NEGOTIATION_INACTIVE if no negotiation in progress
• DRV_ETHPHY_RES_NEGOTIATION_NOT_STARTED if negotiation not yet started yet (means time out if waitComplete was requested)
• DRV_ETHPHY_RES_NEGOTIATION_ACTIVE if negotiation ongoing
The returned value for the negotiation flags is valid only if the negotiation was completed successfully.
Preconditions
• The DRV_ETHPHY_Initialize routine must have been called.
• DRV_ETHPHY_Open must have been called to obtain a valid device handle.
• DRV_ETHPHY_Setup must have been called to properly configure the PHY
• DRV_ETHPHY_RestartNegotiation, and DRV_ETHPHY_NegotiationIsComplete should have been called.
Example
Function
DRV_ETHPHY_RESULT DRV_ETHPHY_NegotiationResultGet( DRV_HANDLE handle, DRV_ETHPHY_NEGOTIATION_RESULT*
pNegResult)
DRV_ETHPHY_PhyAddressGet Function
Returns the PHY address.
Implementation: Dynamic
File
drv_ethphy.h
C
DRV_ETHPHY_RESULT DRV_ETHPHY_PhyAddressGet(DRV_HANDLE handle, DRV_ETHPHY_INTERFACE_INDEX portIndex, int*
pPhyAddress);
Returns
DRV_ETHPHY_RES_OK - operation successful and the PHY address stored at
DRV_ETHPHY_RES_HANDLE_ERR - passed in handle was invalid pPhyAddress
Description
This function returns the current PHY address as set by the DRV_ETHPHY_Setup procedure.
Remarks
None.
Preconditions
• The DRV_ETHPHY_Initialize routine must have been called.
• DRV_ETHPHY_Open must have been called to obtain a valid device handle.
• DRV_ETHPHY_Setup must have been called to properly configure the PHY
Example
Function
DRV_ETHPHY_RESULT DRV_ETHPHY_PhyAddressGet( DRV_HANDLE handle, int* pPhyAddress);
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet PHY Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 494
DRV_ETHPHY_RestartNegotiation Function
Restarts auto-negotiation of the Ethernet PHY link.
Implementation: Dynamic
File
drv_ethphy.h
C
DRV_ETHPHY_RESULT DRV_ETHPHY_RestartNegotiation(DRV_HANDLE handle, DRV_ETHPHY_INTERFACE_INDEX portIndex);
Returns
• DRV_ETHPHY_RES_PENDING operation has been scheduled successfully
• an DRV_ETHPHY_RESULT error code if the procedure failed.
Description
This function restarts auto-negotiation of the Ethernet PHY link.
Remarks
Use DRV_ETHPHY_ClientStatus() and DRV_ETHPHY_ClientOperationResult() to check when the operation was completed and its outcome.
Preconditions
• The DRV_ETHPHY_Initialize routine must have been called.
• DRV_ETHPHY_Open must have been called to obtain a valid device handle.
• DRV_ETHPHY_Setup must have been called to properly configure the PHY
Example
Function
DRV_ETHPHY_RESULT DRV_ETHPHY_RestartNegotiation( DRV_HANDLE handle )
f) Data Types and Constants
DRV_ETHPHY_CLIENT_STATUS Enumeration
Identifies the client-specific status of the Ethernet PHY driver.
File
drv_ethphy.h
C
typedef enum {
DRV_ETHPHY_CLIENT_STATUS_ERROR,
DRV_ETHPHY_CLIENT_STATUS_CLOSED,
DRV_ETHPHY_CLIENT_STATUS_BUSY,
DRV_ETHPHY_CLIENT_STATUS_READY
} DRV_ETHPHY_CLIENT_STATUS;
Members
Members Description
DRV_ETHPHY_CLIENT_STATUS_ERROR Unspecified error condition
DRV_ETHPHY_CLIENT_STATUS_CLOSED Client is not open
DRV_ETHPHY_CLIENT_STATUS_BUSY An operation is currently in progress
DRV_ETHPHY_CLIENT_STATUS_READY Up and running, no operations running
Description
Ethernet PHY Driver Client Status
This enumeration identifies the client-specific status of the Ethernet PHY driver.
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet PHY Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 495
Remarks
None.
DRV_ETHPHY_INIT Structure
Contains all the data necessary to initialize the Ethernet PHY device.
File
drv_ethphy.h
C
struct DRV_ETHPHY_INIT {
SYS_MODULE_INIT moduleInit;
uintptr_t ethphyId;
uint16_t phyAddress;
DRV_ETHPHY_CONFIG_FLAGS phyFlags;
const DRV_ETHPHY_OBJECT* pPhyObject;
DRV_ETHPHY_RESET_FUNCTION resetFunction;
const struct DRV_MIIM_OBJECT_BASE* pMiimObject;
const struct DRV_MIIM_INIT* pMiimInit;
SYS_MODULE_INDEX miimIndex;
};
Members
Members Description
SYS_MODULE_INIT moduleInit; System module initialization
uintptr_t ethphyId; Identifies peripheral (PLIB-level) ID
uint16_t phyAddress; PHY address, as configured on the board. All PHYs respond to address 0
DRV_ETHPHY_CONFIG_FLAGS phyFlags; PHY configuration
const DRV_ETHPHY_OBJECT* pPhyObject; Non-volatile pointer to the PHY object providing vendor functions for this PHY
DRV_ETHPHY_RESET_FUNCTION
resetFunction;
Function to be called when the PHY is reset/initialized. Could be NULL if no special reset
functionality needed - default
const struct DRV_MIIM_OBJECT_BASE*
pMiimObject;
Non-volatile pointer to the DRV_MIIM object providing MIIM access for this PHY Could be
NULL if the MIIM driver is not used
const struct DRV_MIIM_INIT* pMiimInit; Non-volatile pointer to the DRV_MIIM initialization data Could be NULL if the MIIM driver is
not used
SYS_MODULE_INDEX miimIndex; MIIM module index to be used Not needed if the MIIM driver is not used
Description
Ethernet PHY Device Driver Initialization Data
This data structure contains all the data necessary to initialize the Ethernet PHY device.
Remarks
A pointer to a structure of this format containing the desired initialization data must be passed into the DRV_ETHPHY_Initialize routine.
DRV_ETHPHY_NEGOTIATION_RESULT Structure
Contains all the data necessary to get the Ethernet PHY negotiation result
File
drv_ethphy.h
C
typedef struct {
DRV_ETHPHY_LINK_STATUS linkStatus;
TCPIP_ETH_OPEN_FLAGS linkFlags;
TCPIP_ETH_PAUSE_TYPE pauseType;
} DRV_ETHPHY_NEGOTIATION_RESULT;
Members
Members Description
DRV_ETHPHY_LINK_STATUS linkStatus; link status after a completed negotiation
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet PHY Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 496
TCPIP_ETH_OPEN_FLAGS linkFlags; the negotiation result flags
TCPIP_ETH_PAUSE_TYPE pauseType; pause type supported by the link partner
Description
Ethernet PHY Device Driver Negotiation result Data
Contains all the data necessary to get the Ethernet PHY negotiation result
Remarks
A pointer to a structure of this format must be passed into the DRV_ETHPHY_NegotiationResultGet routine.
DRV_ETHPHY_SETUP Structure
Contains all the data necessary to set up the Ethernet PHY device.
File
drv_ethphy.h
C
typedef struct {
int phyAddress;
TCPIP_ETH_OPEN_FLAGS openFlags;
DRV_ETHPHY_CONFIG_FLAGS configFlags;
TCPIP_ETH_PAUSE_TYPE macPauseType;
DRV_ETHPHY_RESET_FUNCTION resetFunction;
} DRV_ETHPHY_SETUP;
Members
Members Description
int phyAddress; the address the PHY is configured for
TCPIP_ETH_OPEN_FLAGS openFlags; the capability flags: FD/HD, 100/100Mbps, etc.
DRV_ETHPHY_CONFIG_FLAGS configFlags; configuration flags: MII/RMII, I/O setup
TCPIP_ETH_PAUSE_TYPE macPauseType; MAC requested pause type
DRV_ETHPHY_RESET_FUNCTION
resetFunction;
If ! NULL, function to be called when the PHY is reset/initialized
Description
Ethernet PHY Device Driver Set up Data
This data structure contains all the data necessary to configure the Ethernet PHY device.
Remarks
A pointer to a structure of this format containing the desired initialization data must be passed into the DRV_ETHPHY_Setup routine.
DRV_ETHPHY_VENDOR_MDIX_CONFIGURE Type
Pointer to function that configures the MDIX mode for the Ethernet PHY.
File
drv_ethphy.h
C
typedef DRV_ETHPHY_RESULT (* DRV_ETHPHY_VENDOR_MDIX_CONFIGURE)(const struct DRV_ETHPHY_OBJECT_BASE_TYPE*
pBaseObj, DRV_HANDLE handle, TCPIP_ETH_OPEN_FLAGS oFlags);
Returns
• DRV_ETHPHY_RES_OK - if success, operation complete
• DRV_ETHPHY_RES_PENDING - if function needs to be called again
< 0 - on failure: configuration not supported or some other error
Description
Pointer To Function: typedef DRV_ETHPHY_RESULT (* DRV_ETHPHY_VENDOR_MDIX_CONFIGURE) ( const struct
DRV_ETHPHY_OBJECT_BASE_TYPE* pBaseObj, DRV_HANDLE handle, TCPIP_ETH_OPEN_FLAGS oFlags );
This type describes a pointer to a function that configures the MDIX mode for the Ethernet PHY. This configuration function is PHY specific and
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet PHY Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 497
every PHY driver has to provide their own implementation.
Remarks
The PHY driver consists of 2 modules:
• the main/base PHY driver which uses standard IEEE PHY registers
• the vendor specific functionality
This function provides vendor specific functionality. Every PHY driver has to expose this vendor specific function as part of its interface.
Traditionally the name used for this function is DRV_EXTPHY_MDIXConfigure but any name can be used.
The function can use all the vendor specific functions to store/retrieve specific data or start SMI transactions (see Vendor Interface Routines).
The function should not block but return DRV_ETHPHY_RES_PENDING if waiting for SMI transactions.
Preconditions
Communication to the PHY should have been established.
DRV_ETHPHY_VENDOR_MII_CONFIGURE Type
Pointer to function to configure the Ethernet PHY in one of the MII/RMII operation modes.
File
drv_ethphy.h
C
typedef DRV_ETHPHY_RESULT (* DRV_ETHPHY_VENDOR_MII_CONFIGURE)(const struct DRV_ETHPHY_OBJECT_BASE_TYPE*
pBaseObj, DRV_HANDLE handle, DRV_ETHPHY_CONFIG_FLAGS cFlags);
Returns
• DRV_ETHPHY_RES_OK - if success, operation complete
• DRV_ETHPHY_RES_PENDING - if function needs to be called again
< 0 - on failure: configuration not supported or some other error
Description
Pointer To Function: typedef DRV_ETHPHY_RESULT (* DRV_ETHPHY_VENDOR_MII_CONFIGURE) (const struct
DRV_ETHPHY_OBJECT_BASE_TYPE* pBaseObj, DRV_HANDLE handle, DRV_ETHPHY_CONFIG_FLAGS cFlags );
This type describes a pointer to a function that configures the Ethernet PHY in one of the MII/RMII operation modes. This configuration function is
PHY specific and every PHY driver has to provide their own implementation.
Remarks
The PHY driver consists of 2 modules:
• the main/base PHY driver which uses standard IEEE PHY registers
• the vendor specific functionality
This function provides vendor specific functionality. Every PHY driver has to expose this vendor specific function as part of its interface.
Traditionally the name used for this function is DRV_EXTPHY_MIIConfigure but any name can be used.
The PHY driver will call the vendor set up functions after the communication to the PHY has been established.
The function can use all the vendor specific functions to store/retrieve specific data or start SMI transactions (see Vendor Interface Routines).
The function should not block but return DRV_ETHPHY_RES_PENDING if waiting for SMI transactions.
Preconditions
Communication to the PHY should have been established.
DRV_ETHPHY_VENDOR_SMI_CLOCK_GET Type
Pointer to a function to return the SMI/MIIM maximum clock speed in Hz of the Ethernet PHY.
File
drv_ethphy.h
C
typedef unsigned int (* DRV_ETHPHY_VENDOR_SMI_CLOCK_GET)(const struct DRV_ETHPHY_OBJECT_BASE_TYPE*
pBaseObj, DRV_HANDLE handle);
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet PHY Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 498
Returns
The maximum SMI/MIIM clock speed as an unsigned integer.
Description
Pointer to Function: typedef unsigned int (* DRV_ETHPHY_VENDOR_SMI_CLOCK_GET) ( const struct DRV_ETHPHY_OBJECT_BASE_TYPE*
pBaseObj, DRV_HANDLE handle );
This type describes a pointer to a function that returns the SMI/MIIM maximum clock speed in Hz of the Ethernet PHY. This configuration function
is PHY specific and every PHY driver has to provide their own implementation.
Remarks
The PHY driver consists of 2 modules:
• the main/base PHY driver which uses standard IEEE PHY registers
• the vendor specific functionality
This function provides vendor specific functionality. Every PHY driver has to expose this vendor specific function as part of its interface.
This value is PHY specific. All PHYs are requested to support 2.5 MHz.
Traditionally the name used for this function is DRV_EXTPHY_SMIClockGet but any name can be used.
The PHY driver will call the vendor set up functions after the communication to the PHY has been established.
The function should not block but return immediately. The function cannot start SMI transactions and cannot use the vendor specific functions to
store/retrieve specific data (see Vendor Interface Routines).
Preconditions
Communication to the PHY should have been established.
DRV_ETHPHY_INDEX_0 Macro
Ethernet PHY driver index definitions.
File
drv_ethphy.h
C
#define DRV_ETHPHY_INDEX_0 0
Description
Ethernet PHY Driver Module Index Numbers
These constants provide the Ethernet PHY driver index definitions.
Remarks
These constants should be used in place of hard-coded numeric literals.
These values should be passed into the DRV_ETHPHY_Initialize and DRV_ETHPHY_Open routines to identify the driver instance in use.
DRV_ETHPHY_INDEX_1 Macro
File
drv_ethphy.h
C
#define DRV_ETHPHY_INDEX_1 1
Description
This is macro DRV_ETHPHY_INDEX_1.
DRV_ETHPHY_INDEX_COUNT Macro
Number of valid Ethernet PHY driver indices.
File
drv_ethphy.h
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet PHY Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 499
C
#define DRV_ETHPHY_INDEX_COUNT 1
Description
Ethernet PHY Driver Module Index Count
This constant identifies the number of valid Ethernet PHY driver indices.
Remarks
This constant should be used in place of hard-coded numeric literals.
This value is derived from part-specific header files defined as part of the peripheral libraries.
DRV_ETHPHY_LINK_STATUS Enumeration
Defines the possible status flags of PHY Ethernet link.
File
drv_ethphy.h
C
typedef enum {
DRV_ETHPHY_LINK_ST_DOWN,
DRV_ETHPHY_LINK_ST_UP,
DRV_ETHPHY_LINK_ST_LP_NEG_UNABLE,
DRV_ETHPHY_LINK_ST_REMOTE_FAULT,
DRV_ETHPHY_LINK_ST_PDF,
DRV_ETHPHY_LINK_ST_LP_PAUSE,
DRV_ETHPHY_LINK_ST_LP_ASM_DIR,
DRV_ETHPHY_LINK_ST_NEG_TMO,
DRV_ETHPHY_LINK_ST_NEG_FATAL_ERR
} DRV_ETHPHY_LINK_STATUS;
Members
Members Description
DRV_ETHPHY_LINK_ST_DOWN No connection to the LinkPartner
DRV_ETHPHY_LINK_ST_UP Link is up
DRV_ETHPHY_LINK_ST_LP_NEG_UNABLE LP non negotiation able
DRV_ETHPHY_LINK_ST_REMOTE_FAULT LP fault during negotiation
DRV_ETHPHY_LINK_ST_PDF Parallel Detection Fault encountered (when DRV_ETHPHY_LINK_ST_LP_NEG_UNABLE)
DRV_ETHPHY_LINK_ST_LP_PAUSE LP supports symmetric pause
DRV_ETHPHY_LINK_ST_LP_ASM_DIR LP supports asymmetric TX/RX pause operation
DRV_ETHPHY_LINK_ST_NEG_TMO LP not there
DRV_ETHPHY_LINK_ST_NEG_FATAL_ERR An unexpected fatal error occurred during the negotiation
Description
Ethernet PHY Device Link Status Codes
This enumeration defines the flags describing the status of the PHY Ethernet link.
Remarks
Multiple flags can be set.
DRV_ETHPHY_CONFIG_FLAGS Enumeration
Defines configuration options for the Ethernet PHY.
File
drv_ethphy.h
C
typedef enum {
DRV_ETHPHY_CFG_RMII,
DRV_ETHPHY_CFG_MII,
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet PHY Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 500
DRV_ETHPHY_CFG_ALTERNATE,
DRV_ETHPHY_CFG_DEFAULT,
DRV_ETHPHY_CFG_AUTO
} DRV_ETHPHY_CONFIG_FLAGS;
Members
Members Description
DRV_ETHPHY_CFG_RMII RMII data interface in configuration fuses.
DRV_ETHPHY_CFG_MII MII data interface in configuration fuses.
DRV_ETHPHY_CFG_ALTERNATE Configuration fuses is ALT
DRV_ETHPHY_CFG_DEFAULT Configuration fuses is DEFAULT
DRV_ETHPHY_CFG_AUTO Use the fuses configuration to detect if you are RMII/MII and ALT/DEFAULT configuration
Description
Ethernet PHY Configuration Flags
This enumeration defines configuration options for the Ethernet PHY. Used by: DRV_ETHPHY_MIIConfigure, DRV_ETHPHY_INIT structure,
DRV_ETHPHY_Setup, Returned by: DRV_ETHPHY_HWConfigFlagsGet
DRV_ETHPHY_OBJECT Structure
Identifies the interface of a Ethernet PHY vendor driver.
File
drv_ethphy.h
C
typedef struct {
DRV_ETHPHY_VENDOR_MII_CONFIGURE miiConfigure;
DRV_ETHPHY_VENDOR_MDIX_CONFIGURE mdixConfigure;
DRV_ETHPHY_VENDOR_SMI_CLOCK_GET smiClockGet;
DRV_ETHPHY_VENDOR_WOL_CONFIGURE wolConfigure;
} DRV_ETHPHY_OBJECT;
Members
Members Description
DRV_ETHPHY_VENDOR_MII_CONFIGURE
miiConfigure;
PHY driver function to configure the operation mode: MII/RMII
DRV_ETHPHY_VENDOR_MDIX_CONFIGURE
mdixConfigure;
PHY driver function to configure the MDIX mode
DRV_ETHPHY_VENDOR_SMI_CLOCK_GET
smiClockGet;
PHY driver function to get the SMI clock rate
DRV_ETHPHY_VENDOR_WOL_CONFIGURE
wolConfigure;
PHY driver function to configure the WOL functionality
Description
Ethernet PHY Driver Vendor Object
This data structure identifies the required interface of the Ethernet PHY driver. Any PHY vendor driver has to export this interface.
Remarks
The PHY driver consists of 2 modules:
• the main/base PHY driver which uses standard IEEE PHY registers
• the vendor specific functionality
This object provides vendor specific functionality. Every PHY driver has to expose this vendor specific functionality as part of its interface.
DRV_ETHPHY_VENDOR_WOL_CONFIGURE Type
Pointer to a function to configure the PHY WOL functionality
File
drv_ethphy.h
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet PHY Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 501
C
typedef void (* DRV_ETHPHY_VENDOR_WOL_CONFIGURE)(const struct DRV_ETHPHY_OBJECT_BASE_TYPE* pBaseObj,
DRV_HANDLE handle, unsigned char bAddr[]);
Returns
None
Description
Pointer to Function: typedef void (* DRV_ETHPHY_VENDOR_WOL_CONFIGURE) ( const struct DRV_ETHPHY_OBJECT_BASE_TYPE*
pBaseObj, DRV_HANDLE handle, unsigned char bAddr[]);
This type describes a pointer to a function that configures the PHY WOL functionality of the Ethernet PHY. Configures the WOL of the PHY with a
Source MAC address or a 6 byte magic packet mac address.
This configuration function is PHY specific and every PHY driver has to provide their own implementation.
Remarks
The PHY driver consists of 2 modules:
• the main/base PHY driver which uses standard IEEE PHY registers
• the vendor specific functionality
This function provides vendor specific functionality. Every PHY driver has to expose this vendor specific function as part of its interface.
Traditionally the name used for this function is DRV_EXTPHY_WOLConfiguration but any name can be used.
The PHY driver will call the vendor set up functions after the communication to the PHY has been established.
The function can use all the vendor specific functions to store/retrieve specific data or start SMI transactions (see Vendor Interface Routines).
The function should not block but return DRV_ETHPHY_RES_PENDING if waiting for SMI transactions.
This feature is not currently supported for all PHYs.
Preconditions
Communication to the PHY should have been established.
DRV_ETHPHY_OBJECT_BASE Structure
Identifies the base interface of a Ethernet PHY driver.
File
drv_ethphy.h
C
typedef struct DRV_ETHPHY_OBJECT_BASE_TYPE {
SYS_MODULE_OBJ (* DRV_ETHPHY_Initialize)(const SYS_MODULE_INDEX index, const SYS_MODULE_INIT * const
init);
void (* DRV_ETHPHY_Reinitialize)(SYS_MODULE_OBJ object, const SYS_MODULE_INIT * const init);
void (* DRV_ETHPHY_Deinitialize)(SYS_MODULE_OBJ object);
SYS_STATUS (* DRV_ETHPHY_Status)(SYS_MODULE_OBJ object);
void (* DRV_ETHPHY_Tasks)(SYS_MODULE_OBJ object);
DRV_HANDLE (* DRV_ETHPHY_Open)(const SYS_MODULE_INDEX drvIndex, const DRV_IO_INTENT intent);
void (* DRV_ETHPHY_Close)(DRV_HANDLE handle);
DRV_ETHPHY_CLIENT_STATUS (* DRV_ETHPHY_ClientStatus)(DRV_HANDLE handle);
DRV_ETHPHY_RESULT (* DRV_ETHPHY_ClientOperationResult)(DRV_HANDLE handle);
DRV_ETHPHY_RESULT (* DRV_ETHPHY_ClientOperationAbort)(DRV_HANDLE handle);
DRV_ETHPHY_RESULT (* DRV_ETHPHY_SMIRead)(DRV_HANDLE handle, unsigned int rIx, uint16_t* pSmiRes, int
phyAdd);
DRV_ETHPHY_RESULT (* DRV_ETHPHY_SMIWrite)(DRV_HANDLE handle, unsigned int rIx, uint16_t wData, int
phyAdd, bool waitComplete);
DRV_ETHPHY_RESULT (* DRV_ETHPHY_SMIScanStart)(DRV_HANDLE handle, unsigned int rIx);
DRV_ETHPHY_RESULT (* DRV_ETHPHY_SMIScanStop)(DRV_HANDLE handle);
DRV_ETHPHY_RESULT (* DRV_ETHPHY_SMIScanStatusGet)(DRV_HANDLE handle);
DRV_ETHPHY_RESULT (* DRV_ETHPHY_SMIScanDataGet)(DRV_HANDLE handle, uint16_t* pScanRes);
DRV_ETHPHY_RESULT (* DRV_ETHPHY_SMIStatus)(DRV_HANDLE handle);
DRV_ETHPHY_RESULT (* DRV_ETHPHY_SMIClockSet)(DRV_HANDLE handle, uint32_t hostClock, uint32_t maxSMIClock);
DRV_ETHPHY_RESULT (* DRV_ETHPHY_PhyAddressGet)(DRV_HANDLE handle, DRV_ETHPHY_INTERFACE_INDEX portIndex,
int* pPhyAddress);
DRV_ETHPHY_RESULT (* DRV_ETHPHY_Setup)(DRV_HANDLE handle, DRV_ETHPHY_SETUP* pSetUp, TCPIP_ETH_OPEN_FLAGS*
pSetupFlags);
DRV_ETHPHY_RESULT (* DRV_ETHPHY_RestartNegotiation)(DRV_HANDLE handle, DRV_ETHPHY_INTERFACE_INDEX
portIndex);
DRV_ETHPHY_RESULT (* DRV_ETHPHY_HWConfigFlagsGet)(DRV_HANDLE handle, DRV_ETHPHY_CONFIG_FLAGS* pFlags);
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet PHY Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 502
DRV_ETHPHY_RESULT (* DRV_ETHPHY_NegotiationIsComplete)(DRV_HANDLE handle, DRV_ETHPHY_INTERFACE_INDEX
portIndex, bool waitComplete);
DRV_ETHPHY_RESULT (* DRV_ETHPHY_NegotiationResultGet)(DRV_HANDLE handle, DRV_ETHPHY_INTERFACE_INDEX
portIndex, DRV_ETHPHY_NEGOTIATION_RESULT* pNegResult);
DRV_ETHPHY_RESULT (* DRV_ETHPHY_LinkStatusGet)(DRV_HANDLE handle, DRV_ETHPHY_INTERFACE_INDEX portIndex,
DRV_ETHPHY_LINK_STATUS* pLinkStat, bool refresh);
DRV_ETHPHY_RESULT (* DRV_ETHPHY_Reset)(DRV_HANDLE handle, bool waitComplete);
DRV_ETHPHY_RESULT (* DRV_ETHPHY_VendorDataGet)(DRV_HANDLE handle, uint32_t* pVendorData);
DRV_ETHPHY_RESULT (* DRV_ETHPHY_VendorDataSet)(DRV_HANDLE handle, uint32_t vendorData);
DRV_ETHPHY_RESULT (* DRV_ETHPHY_VendorSMIReadStart)(DRV_HANDLE handle, uint16_t rIx, int phyAddress);
DRV_ETHPHY_RESULT (* DRV_ETHPHY_VendorSMIReadResultGet)(DRV_HANDLE handle, uint16_t* pSmiRes);
DRV_ETHPHY_RESULT (* DRV_ETHPHY_VendorSMIWriteStart)(DRV_HANDLE handle, uint16_t rIx, uint16_t wData, int
phyAddress);
} DRV_ETHPHY_OBJECT_BASE;
Description
Ethernet PHY Driver Base Object
This data structure identifies the required interface of the Ethernet PHY driver. Any dynamic PHY driver has to export this interface.
Remarks
The PHY driver consists of 2 modules:
• the main/base PHY driver which uses standard IEEE PHY registers
• the vendor specific functionality
This object provides the base functionality. Every dynamic PHY driver has to expose this basic functionality as part of its interface.
See above the description of each function that's part of the base PHY driver.
DRV_ETHPHY_RESET_FUNCTION Type
Pointer to a function to perform an additional PHY reset
File
drv_ethphy.h
C
typedef void (* DRV_ETHPHY_RESET_FUNCTION)(const struct DRV_ETHPHY_OBJECT_BASE_TYPE* pBaseObj);
Returns
None
Description
Pointer to Function: typedef void (* DRV_ETHPHY_RESET_FUNCTION) ( const struct DRV_ETHPHY_OBJECT_BASE_TYPE* pBaseObj);
This type describes a pointer to a function that is called by the driver before starting the detection and initialization process to the PHY - as a result
of the DRV_ETHPHY_Setup call.
Remarks
The PHY driver will call this function as part of its detection and initialization procedure. It can be used for implementing extra steps that the user
needs, before the driver starts talking to the PHY. For example, if a hard reset needs to be applied to the PHY.
The function should be short and not block. It is meant just for short I/O operations, not for lengthy processing.
Preconditions
None
DRV_ETHPHY_RESULT Enumeration
Defines the possible results of Ethernet operations that can succeed or fail
File
drv_ethphy.h
C
typedef enum {
} DRV_ETHPHY_RESULT;
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet PHY Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 503
Description
Ethernet PHY Driver Operation Result *
PHY Driver Operation Result Codes
This enumeration defines the possible results of any of the PHY driver operations that have the possibility of failing. This result should be checked
to ensure that the operation achieved the desired result.
DRV_ETHPHY_USE_DRV_MIIM Macro
Defines the way the PHY driver accesses the MIIM bus to communicate with the PHY.
File
drv_ethphy_config.h
C
#define DRV_ETHPHY_USE_DRV_MIIM true
Description
Ethernet MIIM access configuration
Defines the way the PHY driver accesses the MIIM bus to communicate with the PHY:
• either using direct access to the ETH plibs
• using the MIIM driver - preferred way
Remarks
Using the MIIM driver to perform MIIM bus operations is more versatile and preferred.
DRV_ETHPHY_INTERFACE_INDEX Enumeration
Defines the index type for a PHY interface.
File
drv_ethphy.h
C
typedef enum {
DRV_ETHPHY_INF_IDX_ALL_EXTERNAL,
DRV_ETHPHY_INF_IDX_PORT_0,
DRV_ETHPHY_INF_IDX_PORT_1,
DRV_ETHPHY_INF_IDX_PORT_2,
DRV_ETHPHY_INF_IDX_PORT_3,
DRV_ETHPHY_INF_IDX_PORT_4,
DRV_ETHPHY_INF_IDX_PORT_5
} DRV_ETHPHY_INTERFACE_INDEX;
Members
Members Description
DRV_ETHPHY_INF_IDX_ALL_EXTERNAL All External Interfaces
DRV_ETHPHY_INF_IDX_PORT_0 Port 0 interface
DRV_ETHPHY_INF_IDX_PORT_1 Port 1 interface
DRV_ETHPHY_INF_IDX_PORT_2 Port 2 interface
DRV_ETHPHY_INF_IDX_PORT_3 Port 3 interface
DRV_ETHPHY_INF_IDX_PORT_4 Port 4 interface
DRV_ETHPHY_INF_IDX_PORT_5 Port 5 interface
Description
Ethernet PHY Interface Index
This enumeration defines the index type supported by the PHY Used by: DRV_ETHPHY_PhyAddressGet, DRV_ETHPHY_RestartNegotiation,
DRV_ETHPHY_NegotiationIsComplete, DRV_ETHPHY_LinkStatusGet
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet PHY Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 504
DRV_ETHPHY_INTERFACE_TYPE Enumeration
Defines the type of interface a PHY supports.
File
drv_ethphy.h
C
typedef enum {
DRV_ETHPHY_INF_TYPE_EXTERNAL,
DRV_ETHPHY_INF_TYPE_INTERNAL,
DRV_ETHPHY_INF_TYPE_NOT_SUPPORTED
} DRV_ETHPHY_INTERFACE_TYPE;
Members
Members Description
DRV_ETHPHY_INF_TYPE_EXTERNAL External Interface
DRV_ETHPHY_INF_TYPE_INTERNAL Internal Interface
DRV_ETHPHY_INF_TYPE_NOT_SUPPORTED Not Supported
Description
Ethernet PHY Interface Type
This enumeration defines the type of interface supported by the PHY Returned by: DRV_ETHPHY_GetInterfaceType
Files
Files
Name Description
drv_ethphy.h Ethernet ETHPHY Device Driver Interface File
drv_ethphy_config.h Ethernet PHY driver configuration definitions template.
Description
This section lists the source and header files used by the Ethernet PHY Driver Library.
drv_ethphy.h
Ethernet ETHPHY Device Driver Interface File
Enumerations
Name Description
DRV_ETHPHY_CLIENT_STATUS Identifies the client-specific status of the Ethernet PHY driver.
DRV_ETHPHY_CONFIG_FLAGS Defines configuration options for the Ethernet PHY.
DRV_ETHPHY_INTERFACE_INDEX Defines the index type for a PHY interface.
DRV_ETHPHY_INTERFACE_TYPE Defines the type of interface a PHY supports.
DRV_ETHPHY_LINK_STATUS Defines the possible status flags of PHY Ethernet link.
DRV_ETHPHY_RESULT Defines the possible results of Ethernet operations that can succeed or fail
Functions
Name Description
DRV_ETHPHY_ClientOperationAbort Aborts a current client operation initiated by the Ethernet PHY driver.
Implementation: Dynamic
DRV_ETHPHY_ClientOperationResult Gets the result of a client operation initiated by the Ethernet PHY driver.
Implementation: Dynamic
DRV_ETHPHY_ClientStatus Gets the current client-specific status the Ethernet PHY driver.
Implementation: Dynamic
DRV_ETHPHY_Close Closes an opened instance of the Ethernet PHY driver.
Implementation: Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet PHY Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 505
DRV_ETHPHY_Deinitialize Deinitializes the specified instance of the Ethernet PHY driver module.
Implementation: Dynamic
DRV_ETHPHY_HWConfigFlagsGet Returns the current Ethernet PHY hardware MII/RMII and ALTERNATE/DEFAULT
configuration flags.
Implementation: Dynamic
DRV_ETHPHY_Initialize Initializes the Ethernet PHY driver.
Implementation: Dynamic
DRV_ETHPHY_LinkStatusGet Returns the current link status.
Implementation: Dynamic
DRV_ETHPHY_NegotiationIsComplete Returns the results of a previously initiated Ethernet PHY negotiation.
Implementation: Dynamic
DRV_ETHPHY_NegotiationResultGet Returns the result of a completed negotiation.
Implementation: Dynamic
DRV_ETHPHY_Open Opens the specified Ethernet PHY driver instance and returns a handle to it.
Implementation: Dynamic
DRV_ETHPHY_PhyAddressGet Returns the PHY address.
Implementation: Dynamic
DRV_ETHPHY_Reinitialize Reinitializes the driver and refreshes any associated hardware settings.
Implementation: Dynamic
DRV_ETHPHY_Reset Immediately resets the Ethernet PHY.
Implementation: Dynamic
DRV_ETHPHY_RestartNegotiation Restarts auto-negotiation of the Ethernet PHY link.
Implementation: Dynamic
DRV_ETHPHY_Setup Initializes Ethernet PHY configuration and set up procedure.
Implementation: Dynamic
DRV_ETHPHY_SMIClockSet Sets the SMI/MIIM interface clock.
Implementation: Dynamic
DRV_ETHPHY_SMIRead Initiates a SMI/MIIM read transaction.
Implementation: Dynamic
DRV_ETHPHY_SMIScanDataGet Gets the latest SMI/MIIM scan data result.
Implementation: Dynamic
DRV_ETHPHY_SMIScanStart Starts the scan of a requested SMI/MIIM register.
Implementation: Dynamic
DRV_ETHPHY_SMIScanStatusGet Gets the status of the SMI/MIIM scan data.
Implementation: Dynamic
DRV_ETHPHY_SMIScanStop Stops the scan of a previously requested SMI/MIIM register.
Implementation: Dynamic
DRV_ETHPHY_SMIStatus Returns the current status of the SMI/MIIM interface.
Implementation: Dynamic
DRV_ETHPHY_SMIWrite Initiates a SMI/MIIM write transaction.
Implementation: Dynamic
DRV_ETHPHY_Status Provides the current status of the Ethernet PHY driver module.
Implementation: Dynamic
DRV_ETHPHY_Tasks Maintains the driver's state machine and implements its ISR.
Implementation: Dynamic
DRV_ETHPHY_VendorDataGet Returns the current value of the vendor data.
Implementation: Dynamic
DRV_ETHPHY_VendorDataSet Returns the current value of the vendor data.
Implementation: Dynamic
DRV_ETHPHY_VendorSMIReadResultGet Reads the result of a previous vendor initiated SMI read transfer with
DRV_ETHPHY_VendorSMIReadStart.
Implementation: Dynamic
DRV_ETHPHY_VendorSMIReadStart Starts a vendor SMI read transfer. Data will be available with
DRV_ETHPHY_VendorSMIReadResultGet.
Implementation: Dynamic
DRV_ETHPHY_VendorSMIWriteStart Starts a vendor SMI write transfer.
Implementation: Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet PHY Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 506
Macros
Name Description
DRV_ETHPHY_INDEX_0 Ethernet PHY driver index definitions.
DRV_ETHPHY_INDEX_1 This is macro DRV_ETHPHY_INDEX_1.
DRV_ETHPHY_INDEX_COUNT Number of valid Ethernet PHY driver indices.
Structures
Name Description
DRV_ETHPHY_INIT Contains all the data necessary to initialize the Ethernet PHY device.
DRV_ETHPHY_OBJECT_BASE_TYPE Identifies the base interface of a Ethernet PHY driver.
DRV_ETHPHY_NEGOTIATION_RESULT Contains all the data necessary to get the Ethernet PHY negotiation result
DRV_ETHPHY_OBJECT Identifies the interface of a Ethernet PHY vendor driver.
DRV_ETHPHY_OBJECT_BASE Identifies the base interface of a Ethernet PHY driver.
DRV_ETHPHY_SETUP Contains all the data necessary to set up the Ethernet PHY device.
Types
Name Description
DRV_ETHPHY_RESET_FUNCTION Pointer to a function to perform an additional PHY reset
DRV_ETHPHY_VENDOR_MDIX_CONFIGURE Pointer to function that configures the MDIX mode for the Ethernet PHY.
DRV_ETHPHY_VENDOR_MII_CONFIGURE Pointer to function to configure the Ethernet PHY in one of the MII/RMII operation
modes.
DRV_ETHPHY_VENDOR_SMI_CLOCK_GET Pointer to a function to return the SMI/MIIM maximum clock speed in Hz of the
Ethernet PHY.
DRV_ETHPHY_VENDOR_WOL_CONFIGURE Pointer to a function to configure the PHY WOL functionality
Description
Ethernet ETHPHY Device Driver Interface
The Ethernet ETHPHY device driver provides a simple interface to manage an Ethernet ETHPHY peripheral using MIIM (or SMI) interface. This
file defines the interface definitions and prototypes for the Ethernet ETHPHY driver.
File Name
drv_ethphy.h
Company
Microchip Technology Inc.
drv_ethphy_config.h
Ethernet PHY driver configuration definitions template.
Macros
Name Description
DRV_ETHPHY_CLIENTS_NUMBER Selects the maximum number of clients.
DRV_ETHPHY_INDEX Ethernet PHY static index selection.
DRV_ETHPHY_INSTANCES_NUMBER Selects the maximum number of hardware instances that can be supported by the
dynamic driver.
DRV_ETHPHY_NEG_DONE_TMO Value of the PHY negotiation complete time out as per IEEE 802.3 spec.
DRV_ETHPHY_NEG_INIT_TMO Value of the PHY negotiation initiation time out as per IEEE 802.3 spec.
DRV_ETHPHY_PERIPHERAL_ID Defines an override of the peripheral ID.
DRV_ETHPHY_RESET_CLR_TMO Value of the PHY Reset self clear time out as per IEEE 802.3 spec.
DRV_ETHPHY_USE_DRV_MIIM Defines the way the PHY driver accesses the MIIM bus to communicate with the PHY.
Description
Ethernet PHY Driver Configuration Definitions for the Template Version
These definitions statically define the driver's mode of operation.
File Name
drv_ethphy_config.h
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet PHY Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 507
Company
Microchip Technology Inc.
Flash Driver Library
This section describes the Flash Driver Library.
Introduction
The Flash Driver Library provides functions that allow low-level interface with the on-chip Flash.
Description
Through MHC, this driver provides low-level functions for writing and erasing sections of the Flash memory.
Flash Program Memory
The Flash Program Memory is readable, writeable, and erasable during normal operation over the entire operating voltage range.
A read from program memory is executed at one byte/word at a time depending on the width of the data bus.
A write to the program memory is executed in either blocks of specific sizes or a single word depending on the type of processor used.
An erase is performed in blocks. A bulk erase may be performed from user code depending on the type of processor supporting the operation.
Writing or erasing program memory will cease instruction fetches until the operation is complete, restricting memory access, and therefore
preventing code execution. This is controlled by an internal programming timer.
Library Interface
Functions
Name Description
DRV_FLASH_ErasePage Erases a page of Flash.
Implementation: Static
DRV_FLASH_GetPageSize Returns the size in bytes of a single "Page" which can be erased in the flash.
Implementation: Static
DRV_FLASH_GetRowSize Returns the size in bytes of a single "Row" which can be written to the flash.
Implementation: Static
DRV_FLASH_Initialize Initializes the Flash instance for the specified driver index.
Implementation: Static
DRV_FLASH_IsBusy Returns true if the Flash device is still busy writing or is erasing.
Implementation: Static
DRV_FLASH_Open Initializes a channel to the appropriate flash device.
DRV_FLASH_WriteQuadWord Writes four 4-byte words to the Flash at the (word-aligned) flashAddr.
Implementation: Static
DRV_FLASH_WriteRow Writes an DRV_FLASH_ROW_SIZE bytes to the Flash at the (word-aligned) flashAddr.
Implementation: Static
DRV_FLASH_WriteWord Writes a 4-byte Word to the Flash at the (word-aligned) flashAddr.
Implementation: Static
Data Types and Constants
Name Description
DRV_FLASH_INDEX_0 FLASH driver index definitions
DRV_FLASH_PAGE_SIZE Specifies the FLASH Driver Program Page Size in bytes.
DRV_FLASH_ROW_SIZE Specifies the FLASH Driver Program Row Size in bytes.
Description
This section describes the Application Programming Interface (API) functions of the Flash Driver Library.
Refer to each section for a detailed description.
Functions
Volume V: MPLAB Harmony Framework Driver Libraries Help Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 508
DRV_FLASH_ErasePage Function
Erases a page of Flash.
Implementation: Static
File
drv_flash.h
C
void DRV_FLASH_ErasePage(const DRV_HANDLE handle, uint32_t flashAddr);
Returns
None.
Description
This function starts the process of erasing a page of Flash. It does not wait for the erase operation to be done. That is left to the user. It does not
verify that the erase was successful. That is left to the user. It always erases a single page. The size of a page in bytes will vary by device. It will
be available in the DRV_FLASH_PAGE_SIZE parameter.
Remarks
Most devices will be running for code stored in the Flash. This means that any erases of the Flash will necessarily be writes to program space. As
such, they will prevent the CPU from reading further instructions until the write is done. However, some devices may have more than one Flash
such that it can run from one while writing to another. Additionally, if the application is small enough, it may run out of a cache. In any case, it is up
to the user to wait for an operation to complete and or to decide that such a wait is unnecessary.
Preconditions
The flashAddr is taken as a valid Flash address. No range checking occurs. Any previous Flash operations (write or erase) must be completed or
this will fail silently. The Flash must be correctly erased at flashAddr.
Example
flashAddr = 0x9d008000;
DRV_FLASH_Erase_Page(handle, flashAddr);
Function
void DRV_FLASH_Erase_Page(uint32_t flashAddr);
DRV_FLASH_GetPageSize Function
Returns the size in bytes of a single "Page" which can be erased in the flash.
Implementation: Static
File
drv_flash.h
C
uint32_t DRV_FLASH_GetPageSize(const DRV_HANDLE handle);
Returns
None.
Description
This function allows the user to get the size of a flash Page.
Remarks
None.
Preconditions
None
Function
uint32_t DRV_FLASH_GetPageSize( const DRV_HANDLE handle )
Volume V: MPLAB Harmony Framework Driver Libraries Help Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 509
DRV_FLASH_GetRowSize Function
Returns the size in bytes of a single "Row" which can be written to the flash.
Implementation: Static
File
drv_flash.h
C
uint32_t DRV_FLASH_GetRowSize(const DRV_HANDLE handle);
Returns
None.
Description
This function allows the user to get the size of a flash Row.
Remarks
None.
Preconditions
None
Function
uint32_t DRV_FLASH_GetRowSize( const DRV_HANDLE handle )
DRV_FLASH_Initialize Function
Initializes the Flash instance for the specified driver index.
Implementation: Static
File
drv_flash.h
C
SYS_MODULE_OBJ DRV_FLASH_Initialize(const SYS_MODULE_INDEX index, const SYS_MODULE_INIT * const init);
Returns
If successful, returns a valid handle to a driver instance object. Otherwise, returns SYS_MODULE_OBJ_INVALID.
Description
This function initializes the Flash Driver instance for the specified driver instance, making it ready for clients to use it. The initialization routine is
specified by the MHC parameters.
Remarks
This function must be called before any other Flash function is called. This function should only be called once during system initialization.
Preconditions
None.
Parameters
Parameters Description
index Identifier for the instance to be initialized
init Pointer to a data structure containing any data necessary to initialize the driver.
Function
SYS_MODULE_OBJ DRV_FLASH_Initialize(
const SYS_MODULE_INDEX index,
const SYS_MODULE_INIT * const init
)
Volume V: MPLAB Harmony Framework Driver Libraries Help Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 510
DRV_FLASH_IsBusy Function
Returns true if the Flash device is still busy writing or is erasing.
Implementation: Static
File
drv_flash.h
C
bool DRV_FLASH_IsBusy(const DRV_HANDLE handle);
Returns
• true - Indicates the Flash is busy
• false - Indicates the Flash is not busy
Description
This function checks whether the process of programming a Word into the Flash is still operating.
Remarks
Most devices will be running for code stored in the Flash. This means that any writes to the Flash will necessarily be writes to program space. As
such, they will prevent the CPU from reading further instructions until the write is done. However, some devices may have more than one Flash
such that it can run from one while writing to another. Additionally, if the application is small enough, it may run out of a cache. In any case, it is up
to the user to wait for an operation to complete and or to decide that such a wait is unnecessary.
Preconditions
None.
Example
flashAddr = 0x9d008000;
sourceData = 0x12345678;
DRV_FLASH_Write_Word(flashAddr, sourceData);
DRV_FLASH_IsBusy( void );
Function
bool DRV_FLASH_IsBusy( void )
DRV_FLASH_Open Function
Initializes a channel to the appropriate flash device.
File
drv_flash.h
C
DRV_HANDLE DRV_FLASH_Open(const SYS_MODULE_INDEX index, const DRV_IO_INTENT ioIntent);
Returns
Handle for future calls to the driver's operations.
Preconditions
None
Function
DRV_HANDLE DRV_FLASH_Open(
const SYS_MODULE_INDEX index,
const DRV_IO_INTENT ioIntent
);
DRV_FLASH_WriteQuadWord Function
Writes four 4-byte words to the Flash at the (word-aligned) flashAddr.
Volume V: MPLAB Harmony Framework Driver Libraries Help Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 511
Implementation: Static
File
drv_flash.h
C
void DRV_FLASH_WriteQuadWord(const DRV_HANDLE handle, uint32_t flashAddr, uint32_t * sourceData);
Returns
None.
Description
This function starts the process of programming a word into the Flash. It does not wait for the write operation to be done, which is left to the user. It
does not verify that the write was successful, which is left to the user.
Remarks
Most devices will be running for code stored in the Flash. This means that any writes to the Flash will necessarily be writes to program space. As
such, they will prevent the CPU from reading further instructions until the write is done. However, some devices may have more than one Flash
such that it can run from one while writing to another. Additionally, if the application is small enough, it may run out of a cache. In any case, it is up
to the user to wait for an operation to complete and or to decide that such a wait is unnecessary.
Preconditions
The flashAddr is taken as a valid Flash address. No range checking occurs. Any previous Flash operations (write or erase) must be completed or
this will fail silently. The Flash must be correctly erased at flashAddr.
Example
flashAddr = 0x9d008000;
sourceData[4] = {0x12345678,0x9ABCDEF0,0x55AAAA55,0x11111111};
DRV_FLASH_WriteQuadWord(handle, flashAddr, sourceData);
Function
void DRV_FLASH_WriteQuadWord( const DRV_HANDLE handle, uint32_t flashAddr, uint32_t sourceData)
DRV_FLASH_WriteRow Function
Writes an DRV_FLASH_ROW_SIZE bytes to the Flash at the (word-aligned) flashAddr.
Implementation: Static
File
drv_flash.h
C
void DRV_FLASH_WriteRow(const DRV_HANDLE handle, uint32_t flashAddr, uint32_t sourceData);
Returns
None.
Description
This function starts the process of programming a buffer into the Flash. It does not wait for the write operation to be done, which is left to the user.
It does not verify that the write was successful, which is left to the user.
Remarks
Most devices will be running for code stored in the Flash. This means that any writes to the Flash will necessarily be writes to program space. As
such, they will prevent the CPU from reading further instructions until the write is done. However, some devices may have more than one Flash
such that it can run from one while writing to another. Additionally, if the application is small enough, it may run out of a cache. In any case, it is up
to the user to wait for an operation to complete and or to decide that such a wait is unnecessary.
Preconditions
The flashAddr is taken as a valid Flash address. No range checking occurs. The memory pointed to by sourceData must be valid memory for at
least DRV_FLASH_ROW_SIZE bytes. Any previous Flash operations (write or erase) must be completed or this will fail silently. The Flash must be
correctly erased at flashAddr.
Example
flashAddr = 0x9d008000;
Volume V: MPLAB Harmony Framework Driver Libraries Help Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 512
uint32_t dataStore[DRV_FLASH_ROW_SIZE] = {0,1,2,3,4,5};
DRV_FLASH_Write_Row( const DRV_HANDLE handle, flashAddr, dataStore);
Function
void DRV_FLASH_WriteRow( const DRV_HANDLE handle, uint32_t flashAddr, uint32_t sourceData)
DRV_FLASH_WriteWord Function
Writes a 4-byte Word to the Flash at the (word-aligned) flashAddr.
Implementation: Static
File
drv_flash.h
C
void DRV_FLASH_WriteWord(const DRV_HANDLE handle, uint32_t flashAddr, uint32_t sourceData);
Returns
None.
Description
This function starts the process of programming a Word into the Flash. It does not wait for the write operation to be done, which is left to the user.
It does not verify that the write was successful, which is left to the user.
Remarks
Most devices will be running for code stored in the Flash. This means that any writes to the Flash will necessarily be writes to program space. As
such, they will prevent the CPU from reading further instructions until the write is done. However, some devices may have more than one Flash
such that it can run from one while writing to another. Additionally, if the application is small enough, it may run out of a cache. In any case, it is up
to the user to wait for an operation to complete and or to decide that such a wait is unnecessary.
Preconditions
The flashAddr is taken as a valid Flash address. No range checking occurs. Any previous Flash operations (write or erase) must be completed or
this will fail silently. The Flash must be correctly erased at flashAddr.
Example
flashAddr = 0x9d008000;
sourceData = 0x12345678;
DRV_FLASH_WriteWord(handle, flashAddr, sourceData);
Function
void DRV_FLASH_WriteWord( const DRV_HANDLE handle, uint32_t flashAddr, uint32_t sourceData)
Data Types and Constants
DRV_FLASH_INDEX_0 Macro
FLASH driver index definitions
File
drv_flash.h
C
#define DRV_FLASH_INDEX_0 0
Description
These constants provide FLASH driver index definitions.
Remarks
These constants should be used in place of hard-coded numeric literals. These values should be passed into the DRV_FLASH_Initialize and
DRV_FLASH_Open routines to identify the driver instance in use.
Volume V: MPLAB Harmony Framework Driver Libraries Help Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 513
Section
Constants
************************************************************************
************************************************************************
***************************************************************************
Driver FLASH Module Index
DRV_FLASH_PAGE_SIZE Macro
Specifies the FLASH Driver Program Page Size in bytes.
File
drv_flash.h
C
#define DRV_FLASH_PAGE_SIZE (NVM_PAGE_SIZE)
Description
FLASH Driver Program Page Size.
This definition specifies the FLASH Driver Program Page Size in bytes. This parameter is device specific and is obtained from the device specific
processor header file.
Remarks
None
DRV_FLASH_ROW_SIZE Macro
Specifies the FLASH Driver Program Row Size in bytes.
File
drv_flash.h
C
#define DRV_FLASH_ROW_SIZE (NVM_ROW_SIZE)
Description
FLASH Driver Program Row Size.
This definition specifies the FLASH Driver Program Row Size in bytes. This parameter is device specific and is obtained from the device specific
processor header file. The Program Row Size is the maximum block size that can be programmed in one program operation.
Remarks
None
Files
Files
Name Description
drv_flash.h Flash Driver interface declarations for the static single instance driver.
Description
drv_flash.h
Flash Driver interface declarations for the static single instance driver.
Volume V: MPLAB Harmony Framework Driver Libraries Help Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 514
Functions
Name Description
DRV_FLASH_ErasePage Erases a page of Flash.
Implementation: Static
DRV_FLASH_GetPageSize Returns the size in bytes of a single "Page" which can be erased in the flash.
Implementation: Static
DRV_FLASH_GetRowSize Returns the size in bytes of a single "Row" which can be written to the flash.
Implementation: Static
DRV_FLASH_Initialize Initializes the Flash instance for the specified driver index.
Implementation: Static
DRV_FLASH_IsBusy Returns true if the Flash device is still busy writing or is erasing.
Implementation: Static
DRV_FLASH_Open Initializes a channel to the appropriate flash device.
DRV_FLASH_WriteQuadWord Writes four 4-byte words to the Flash at the (word-aligned) flashAddr.
Implementation: Static
DRV_FLASH_WriteRow Writes an DRV_FLASH_ROW_SIZE bytes to the Flash at the (word-aligned) flashAddr.
Implementation: Static
DRV_FLASH_WriteWord Writes a 4-byte Word to the Flash at the (word-aligned) flashAddr.
Implementation: Static
Macros
Name Description
DRV_FLASH_INDEX_0 FLASH driver index definitions
DRV_FLASH_PAGE_SIZE Specifies the FLASH Driver Program Page Size in bytes.
DRV_FLASH_ROW_SIZE Specifies the FLASH Driver Program Row Size in bytes.
Description
Flash Driver Interface Declarations for Static Single Instance Driver
The Flash device driver provides a simple interface to manage the Flash Controller on Microchip microcontrollers. This file defines the interface
Declarations for the Flash driver.
Remarks
Static interfaces incorporate the driver instance number within the names of the routines, eliminating the need for an object ID or object handle.
Static single-open interfaces also eliminate the need for the open handle.
File Name
drv_flash.h
Company
Microchip Technology Inc.
Ethernet GMAC Driver Library
This section describes the Ethernet MAC Driver Library.
Introduction
This library provides a driver-level abstraction of the on-chip Ethernet Controller found on many PIC32 devices. The driver implements the virtual
MAC driver model that the MPLAB Harmony TCP/IP Stack requires. Please see the TCP/IP Stack Library MAC Driver Module help for details.
The "Host-To-Network"_layer of a TCP/IP stack organization covers the Data Link and Physical Layers of the standard OSI stack. The Ethernet
Controller provides the Data Link or Media Access Control Layer, in addition to other functions discussed in this section. An external Ethernet
"PHY" provides the Physical_layer, providing conversion between the digital and analog.
Description
The Ethernet Media Access Controller (GMAC) module implements a 10/100 Mbps Ethernet MAC, compatible with the IEEE 802.3 standard. The
GMAC can operate in either half or full duplex mode at all supported speeds.
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet GMAC Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 515
Embedded Characteristics
• Compatible with IEEE Standard 802.3
• 10, 100 Mbps operation
• Full and half duplex operation at all supported speeds of operation
• Statistics Counter Registers for RMON/MIB
• MII interface to the physical layer
• Integrated physical coding
• Direct memory access (DMA) interface to external memory
• Support for 6 priority queues in DMA
• 8 KB transmit RAM and 4 KB receive RAM
• Programmable burst length and endianism for DMA
• Interrupt generation to signal receive and transmit completion, errors or other events
• Automatic pad and cyclic redundancy check (CRC) generation on transmitted frames
• Automatic discard of frames received with errors
• Receive and transmit IP, TCP and UDP checksum offload. Both IPv4 and IPv6 packet types supported
• Address checking logic for four specific 48-bit addresses, four type IDs, promiscuous mode, hash matching of unicast and multicast destination
addresses and Wake-on-LAN
• Management Data Input/Output (MDIO) interface for physical layer management
• Support for jumbo frames up to 10240 Bytes
• Full duplex flow control with recognition of incoming pause frames and hardware generation of transmitted pause frames
• Half duplex flow control by forcing collisions on incoming frames
• Support for 802.1Q VLAN tagging with recognition of incoming VLAN and priority tagged frames
• Support for 802.1Qbb priority-based flow control
• Programmable Inter Packet Gap (IPG) Stretch
• Recognition of IEEE 1588 PTP frames
• IEEE 1588 time stamp unit (TSU)
• Support for 802.1AS timing and synchronization
• Supports 802.1Qav traffic shaping on two highest priority queues
Using the Library
The user of this driver is the MPLAB Harmony TCP/IP stack. This Ethernet driver is not intended as a system wide driver that the application or
other system modules may use. It is intended for the sole use of the MPLAB Harmony TCP/IP stack and implements the virtual MAC model
required by the stack.
This topic describes the basic architecture and functionality of the Ethernet MAC driver and is meant for advanced users or TCP/IP stack driver
developers.
Interface Header File: drv_gmac.h
The interface to the Ethernet MAC library is defined in the drv_gmac.h header file, which is included by the MPLAB Harmony TCP/IP stack.
Please refer to the What is MPLAB Harmony? section for how the library interacts with the framework.
Abstraction Model
This library provides a low-level abstraction of the Ethernet GMAC Driver Library on Microchip's microcontrollers with a convenient C language
interface. This topic describes how that abstraction is modeled in software and introduces the library's interface.
Description
The Ethernet Controller provides the modules needed to implement a 10/100 Mbps Ethernet node using an external Ethernet PHY chip. The PHY
chip provides a digital-analog interface as part of the Physical Layer and the controller provides the Media Access Controller (MAC)_layer above
the PHY.
As shown in Figure 1, the Ethernet Controller consists of the following modules:
• Media Access Control (MAC) block: Responsible for implementing the MAC functions of the Ethernet IEEE 802.3 Specification
• Flow Control (FC) block: Responsible for control of the transmission of PAUSE frames. (Reception of PAUSE frames is handled within the
MAC.)
• RX Filter (RXF) block: This module performs filtering on every receive packet to determine whether each packet should be accepted or rejected
• TX DMA/TX Buffer Management Engine: The TX DMA and TX Buffer Management engines perform data transfers from the memory (using
descriptor tables) to the MAC Transmit Interface
• RX DMA/RX Buffer Management Engine: The RX DMA and RX Buffer Management engines transfer receive packets from the MAC to the
memory (using descriptor tables)
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet GMAC Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 516
Figure 1: Ethernet Controller Block Diagram
For completeness, we also need to look at the interface diagram of a representative Ethernet PHY. As shown in Figure 2, the PHY has two
interfaces, one for configuring and managing the PHY (SMI/MIIM) and another for transmit and receive data (RMII or MII). The SMI/MIIM interface
is the responsibility of the Ethernet PHY Driver Library. When setting up the Ethernet PHY, this Ethernet driver calls primitives from the Ethernet
PHY Driver library. The RMII/MII data interface is the responsibility of the Ethernet MAC Driver Library (this library).
Figure 2: Ethernet PHY Interfaces
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet GMAC Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 517
Library Overview
Refer to the Driver Library Overview section for information on how the driver operates in a system. Refer to the TCP/IP Stack Library MAC Driver
Module help for the interface that the Ethernet driver has to implement in a MPLAB Harmony system.
The library interface routines are divided into various sub-sections, which address one of the blocks or the overall operation of the Ethernet GMAC
Driver Library.
Library Interface Section Description
Client Level Functions Open, Close, Initialize, Reinitialize, and Deinitialize functions to support the TCP/IP
Stack. Plus link status and power options.
Receive Functions Receive routines.
Transmit Functions Transmit routines.
Event Functions Ethernet event support routines.
Other Functions Additional routines.
Data Types and Constants Typedefs and #defines.
Configuring the Library
The configuration of the Ethernet MAC driver is done as part of the MPLAB Harmony TCP/IP Stack configuration and is based on the
system_config.h file, which may include the tcpip_mac_config.h. See the TCP/IP Stack Library MAC Driver Module help file for
configuration options.
This header file contains the configuration selection for the Ethernet GMAC Driver.
This header can be placed anywhere; however, the path of this header needs to be present in the include search path for a successful build. Refer
to the Applications Help section for more details.
Building the Library
This section lists the files that are available in the Ethernet GMAC Driver Library.
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet GMAC Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 518
Description
The following three tables list and describe the header (.h) and source (.c) files that implement this library. The parent folder for these files is
/framework/driver/gmac.
Interface File(s)
This table lists and describes the header files that must be included (i.e., using #include) by any code that uses this library.
Source File Name Description
/drv_gmac.h Header file that exports the driver API.
Required File(s)
All of the required files listed in the following table are automatically added into the MPLAB X IDE project by the MHC
when the library is selected for use.
This table lists and describes the source and header files that must always be included in the MPLAB X IDE project to build this library.
Source File Name Description
/src/dynamic/drv_gmac.c PIC32 internal Ethernet driver virtual GMAC implementation file.
/src/dynamic/drv_gmac_lib.c PIC32 internal Ethernet driver controller implementation file.
Optional File(s)
This table lists and describes the source and header files that may optionally be included if required for the desired implementation.
Source File Name Description
N/A No optional files are available for this library
Module Dependencies
The Ethernet MAC Driver Library depends on the following modules:
• Ethernet PHY Driver Library
• Interrupt System Service Library
• Timer System Service Library
• Ethernet Peripheral Library
Library Interface
This section lists the interface routines, data types, constants and macros for the library.
a) Client Level Functions
b) Receive Functions
c) Transmit Functions
d) Event Functions
e) Other Functions
f) Data Types and Constants
Volume V: MPLAB Harmony Framework Driver Libraries Help Ethernet GMAC Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 519
Files
Files
Name Description
drv_gmac.h This is file drv_gmac.h.
Description
This section lists the source and header files used by the Ethernet MAC Driver Library.
drv_gmac.h
This is file drv_gmac.h.
I2C Driver Library Help
This section describes the I2C Driver Library.
Introduction
This library provides an interface to manage the data transfer operations using the I2C module on the Microchip family of microcontrollers.
Description
The driver communicates using the concept of transactions. In instances where the I2C operates in Master mode, the driver sends the start signal,
followed by a slave device address (including a Read/Write bit), followed by a number of bytes written to or read from the slave. The transaction is
completed by sending the stop signal. When the driver operates in the Slave mode, it will either read data or write data to the master.
This driver library provides application ready routines to read and write data using the I2C protocol, thus minimizing developer’s awareness of the
working of the I2C protocol.
• Provides read/write and buffer data transfer models
• Supports interrupt and Polled modes of operation
• Support multi-client and multi-instance operation
• Provides data transfer events
• Supports blocking and non-blocking operation
• Supports baud rate setting
• Supports bit bang mode.
Using the Library
This topic describes the basic architecture of the I2C Driver Library and provides information and examples on its use.
Description
Interface Header File: drv_i2c.h
The interface to the I2C Driver Library is defined in the drv_i2c.h header file. Any C language source (.c) file that uses the I2C Driver Library
should include drv_i2c.h.
Library File: The I2C Driver Library archive (.a) file is installed with MPLAB Harmony.
Please refer to the What is MPLAB Harmony? section for how the driver interacts with the framework.
Abstraction Model
The I2C Driver Library provides the low-level abstraction of the I2C module on the Microchip family of microcontrollers with a convenient C
language interface. This topic describes how that abstraction is modeled in the software and introduces the I2C Driver Library interface.
Description
The I2C Driver Library features routines to perform two functions, driver maintenance and data transfer:
Driver Maintenance
The Driver initialization routines allow the application to initialize the driver. The initialization data configures the I2C module as a Master or a Slave
and sets the necessary parameters required for operation in the particular mode. The driver must be initialized before it can be used by the
application. After the end of operation, the driver can be deinitialized.
Volume V: MPLAB Harmony Framework Driver Libraries Help I2C Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 520
Data Transfer
Data transfer is accomplished by separate Write and Read functions through a data buffer. The read and write function makes the user transparent
to the internal working of the I2C protocol. The user can use callback mechanisms or use polling to check status of transfer.
The following diagrams illustrate the model used by the I2C Driver for transmitter and receiver.
Note:
The driver can be configured to use either the SOC peripheral, or in Bit Bang mode. Bit Bang mode uses CPU resources to
process the data bits onto or off of the I2C I/O pins. Be aware that and I2C driver configured this way uses a large amount of CPU
resources.
Receiver Abstraction Model
Transmitter Abstraction Model
Library Overview
The library interface routines are divided into various sub-sections, which address one of the blocks or the overall operation of the I2C Driver
Library.
Library Interface Section Description
System Interaction Functions Provides system module interfaces, device initialization, deinitialization,
reinitialization, tasks and status functions.
Client Setup Functions Provides open, close, status and other setup functions.
Data Transfer Functions Provides data transfer functions available in the configuration.
Miscellaneous Functions Provides miscellaneous driver functions.
How the Library Works
The library provides interfaces to support:
• System Functionality
• Client Functionality
Volume V: MPLAB Harmony Framework Driver Libraries Help I2C Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 521
System Access
This section provides information on system access.
Description
System Access
The system performs the initialization of the device driver with settings that affect only the instance of the device that is being initialized. During
system initialization, each instance of the I2C module would be initialized with the following configuration settings (either passed dynamically at
run-time using DRV_I2C_INIT or by using initialization overrides) that are supported by the specific I2C device hardware:
• Device requested power state: one of the System Module Power States. For specific details please refer to Data Types and Constants in the
Library Interface section.
• The actual peripheral ID enumerated as the PLIB level module ID (e.g., I2C_ID_2)
• Master or Slave mode of operation and their associated parameters
• Defining the respective interrupt sources for Master, Slave, and Error Interrupt
The DRV_I2C_Initialize API returns an object handle of the type SYS_MODULE_OBJ. After this, the object handle returned by the Initialize
interface would be used by the other system interfaces like DRV_I2C_Deinitialize, DRV_I2C_Status, and DRV_I2C_Tasks.
Note:
The system initialization settings, only affect the instance of the peripheral that is being initialized.
Example:
DRV_I2C_INIT i2c_init_data;
SYS_MODULE_OBJ objectHandle;
i2c_init_data.i2cId = DRV_I2C_PERIPHERAL_ID_IDX0,
i2c_init_data.i2cMode = DRV_I2C_MODE_MASTER,
OR
i2c_init_data.i2cMode = DRV_I2C_MODE_SLAVE,
/* Master mode parameters */
i2c_init_data.baudRate = 100000,
i2c_init_data.busspeed = DRV_I2C_SLEW_RATE_CONTROL_IDX0,
i2c_init_data.buslevel = DRV_I2C_SMBus_SPECIFICATION_IDX0,
/* Master mode parameters */
i2c_init_data.addWidth = DRV_I2C_7BIT_SLAVE,
i2c_init_data.reservedaddenable = false,
i2c_init_data.generalcalladdress = false,
i2c_init_data.slaveaddvalue = 0x0060,
//interrupt sources
i2c_init_data.mstrInterruptSource = INT_SOURCE_I2C_2_MASTER,
i2c_init_data.slaveInterruptSource = INT_SOURCE_I2C_2_ERROR,
i2c_init_data.errInterruptSource = INT_SOURCE_I2C_2_ERROR,
i2c_init_data.queueSize = 1,
/* callback for Master (Master mode can use callbacks if needed) */
i2c_init_data.operationStarting = NULL,
/* Slave mode callbacks needed */
i2c_init_data.operationStarting = APP_I2CSlaveFunction,
objectHandle = DRV_I2C_Initialize(DRV_I2C_INDEX_0, (SYS_MODULE_INIT *)&drvI2C0InitData)
if (SYS_MODULE_OBJ_INVALID == objectHandle)
{
// Handle error
}
Since the I2C bus is controlled by the Master, the Slave should respond to a read or write request whenever the Master makes the request. Thus,
the slave does not have driver states like the Master. The operation of the I2C Driver when used in Slave mode is handled using callbacks. The
callback, OperationStarting, must be configured during system initialization when in Slave mode. This callback is provided so that the application
can respond appropriately when a read or write request is received from the Master.
Volume V: MPLAB Harmony Framework Driver Libraries Help I2C Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 522
Client Access
This section provides information on client access.
Description
For the application to start using an instance of the module, it must call the DRV_I2C_Open function. This provides the configuration required to
open the I2C instance for operation. If the driver is deinitialized using the function DRV_I2C_Deinitialize, the application must call the
DRV_I2C_Open function again to set up the instance of the I2C.
For the various options available for IO_INTENT, please refer to Data Types and Constants in the Library Interface section.
After a client instance is opened, DRV_I2C_ClientSetup can be called to set up client-specific parameters. In I2C Slave mode, this is used to
set-up the IRQ logic so that the slave can toggle this line to request Master to send a Read command.
As during initialization, when the I2C module operates in the Slave mode, only the Master can terminate a transaction with the Slave. In this case,
the driver provides a callback to the application after the reception of each byte from the Master or after transmission of a byte to the Master.
Example:
/* I2C Driver Handle */
DRV_HANDLE drvI2CHandle;
/* Open the I2C Driver */
appData.drvI2CHandle = DRV_I2C_Open( DRV_I2C_INDEX_0,DRV_IO_INTENT_WRITE );
if (drvI2CHandle != DRV_HANDLE_VALID)
{
//Client cannot open instance
}
Client Transfer
This section provides information on client transfer functionality.
Description
Core Functionality
Client basic functionality provides an extremely basic interface for the driver operation.
The following diagram illustrates the byte/word model used for the data transfer.
Volume V: MPLAB Harmony Framework Driver Libraries Help I2C Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 523
Client Data Transfer Functionality
Applications using the I2C driver need to perform the following:
1. The system should have completed necessary initialization and the DRV_I2C_Tasks should either be running in polled environment, or in an
interrupt environment.
2. Open the driver using DRV_I2C_Open with the necessary intent.
3. Add a buffer using the DRV_I2C_Receive, DRV_I2C_Transmit, and DRV_I2C_TransmitThenReceive functions. An optional callback can be
provided that will be called when the buffer/job is complete using DRV_I2C_BufferEventHandlerSet.
4. Check for the current transfer status using DRV_I2C_TransferStatusGet or wait for the callback to be called with buffer transfer status set to
DRV_I2C_BUFFER_EVENT_COMPLETE or DRV_I2C_BUFFER_EVENT_ERROR.
5. Buffer status DRV_I2C_BUFFER_EVENT_COMPLETE implies that the I2C transaction has been completed without any errors. Buffer status
DRV_I2C_BUFFER_EVENT_ERROR indicates that the I2C transaction was aborted and the entire contents of the buffer were not transferred.
6. In Master mode, common cases for DRV_I2C_BUFFER_EVENT_ERROR to be set are:
• Slave is non-operational
• Slave is performing an internal operation and cannot accept any more I2C messages from the Master until the operation completes. In such
a case, if the Master tries to address the Slave and is attempting to transfer data, the Slave NACKs the transfer. This will result in the Master
prematurely terminating the transaction and setting the DRV_I2C_BUFFER_EVENT_FLAG. In the application level, the Master can
continuously attempt to send the transaction until transfer status changes from for DRV_I2C_BUFFER_EVENT_ERROR to
DRV_I2C_BUFFER_EVENT_COMPLETE. This will in effect perform the so-called "Acknowledge Polling". An example of a Slave device
that depicts this behavior is an EEPROM.
Volume V: MPLAB Harmony Framework Driver Libraries Help I2C Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 524
7. The client will be able to close the driver using DRV_I2C_Close when required.
Example:
/* This example demonstrates the I2C driver setup of one instance of I2C acting
as a Master to another instance of the I2C Driver acting as a Slave.
In the Slave initialization data structure in system_init.c, the member
operationStarting should be assigned a function pointer. This function will
be called when the Slave receives an address match. Based on the R/W bit in
the address, the transmit or receive function will be called by the Slave
(e.g., .operationStarting = APP_SlaveDataforMaster) */
SYS_MODULE_OBJ i2cMasterObject;
SYS_MODULE_OBJ i2cSlaveObject;
/* function prototype of callback function */
void I2CMasterOpStatusCb ( DRV_I2C_BUFFER_EVENT event,
DRV_I2C_BUFFER_HANDLE bufferHandle,
uintptr_t context);
int main( void )
{
while ( 1 )
{
appTask ();
}
}
void appTask ()
{
#define MY_BUFFER_SIZE 5
#define RTCC_SLAVE_ADDRESS 0xDE
/* initialize slave address value */
unsigned char address = RTCC_SLAVE_ADDRESS;
/*Initialize myBuffer with MY_BUFFER_SIZE bytes of valid data */
char myBuffer[MY_BUFFER_SIZE] = { 11, 22, 33, 44, 55};
unsigned int numBytes;
DRV_HANDLE drvI2CMasterHandle; //Returned from DRV_I2C_Open for I2C Master
DRV_I2C_BUFFER_HANDLE bufHandle_M1; //Returned from calling a Data Transfer function
uintptr_t i2cOpStatus; //Operation status of I2C operation returned from callback
DRV_HANDLE drvI2CSlaveHandle; //Returned from DRV_I2C_Open for I2C Slave
DRV_I2C_BUFFER_HANDLE bufHandle_S1; //Returned from calling a Data Transfer function
DRV_I2C_BUFFER_HANDLE bufHandle_S2; //Returned from calling a Data Transfer function
while( 1 )
{
switch( state )
{
case APP_STATE_INIT:
{
/* Initialize the Master I2C Driver */
i2cMasterObject = DRV_I2C_Initialize( DRV_I2C_INDEX_0, (SYS_MODULE_INIT *)&drvI2C0InitData
);
/* Initialize the Slave I2C Driver */
i2cSlaveObject = DRV_I2C_Initialize(DRV_I2C_INDEX_1, (SYS_MODULE_INIT *)&drvI2C1InitData);
/* Check for the System Status */
if( SYS_STATUS_READY != DRV_I2C_Status( i2cObject ) )
return 0;
/* Open the Driver for I2C Master */
drvI2CMasterHandle = DRV_I2C_Open( DRV_I2C_INDEX_0,DRV_IO_INTENT_WRITE );
Volume V: MPLAB Harmony Framework Driver Libraries Help I2C Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 525
if ( drvI2CMasterHandle != (DRV_HANDLE)NULL )
{
/* event-handler set up receive callback from DRV_I2C_Tasks */
/* Event handler need to be set up only if needed */
DRV_I2C_BufferEventHandlerSet(drvI2CMasterHandle, I2CMasterOpStatusCb, i2cOpStatus );
/* Update the state to transfer data */
state = APP_STATE_DATA_PUT;
}
else
{
state = APP_STATE_ERROR;
}
/* Open the I2C Driver for Slave on the same device */
drvI2CSlaveHandle = DRV_I2C_Open( DRV_I2C_INDEX_1,DRV_IO_INTENT_WRITE );
if ( drvI2CMasterHandle != (DRV_HANDLE)NULL )
{
/* event-handler set up receive callback from DRV_I2C_Tasks */
/* Event handler need to be set up only if needed */
DRV_I2C_BufferEventHandlerSet(drvI2CMasterHandle, I2CMasterOpStatusCb, i2cOpStatus );
/* Update the state to transfer data */
state = APP_STATE_DATA_PUT;
}
else
{
state = APP_STATE_ERROR;
}
break;
}
case APP_STATE_DATA_PUT:
{
/* I2C master writes data onto I2C bus */
bufHandle_M1 = DRV_I2C_Transmit ( drvI2CMasterHandle , address, &myBuffer[], 5, NULL );
/* Update the state to status check */
state = APP_STATE_DATA_CHECK;
break;
}
case APP_STATE_DATA_CHECK:
{
/* Check for the successful data transfer */
if( DRV_I2C_BUFFER_EVENT_COMPLETE == DRV_I2C_TransferStatusGet
(drvI2CMasterHandle, bufHandle_M1) )
{
/* Do this repeatedly */
state = APP_STATE_DATA_PUT;
}
break;
}
case APP_STATE_ERROR:
{
//include any error handling routines here
break;
}
default:
{
break;
}
}
}
Volume V: MPLAB Harmony Framework Driver Libraries Help I2C Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 526
/****************************************************************************/
// Function: I2CMasterOpStatusCb
//
// Callback called in Master mode from the DRV_I2C_Tasks function. This
// callback is invoked when the Master has to indicate to the application
// that the BUFFER event is COMPLETE or there was an error in transmission.
//****************************************************************************/
void I2CMasterOpStatusCb ( DRV_I2C_BUFFER_EVENT event,
DRV_I2C_BUFFER_HANDLE bufferHandle,
uintptr_t context)
{
switch(event)
{
case DRV_I2C_BUFFER_EVENT_COMPLETE:
//this indicates that the I2C transaction has completed
//DRV_I2C_BUFFER_EVENT_COMPLETE can be handled in the callback
//or by checking for this event using the API DRV_I2C_BufferStatus
/* include any callback event handling code here if needed */
break;
case DRV_I2C_BUFFER_EVENT_ERROR:
//this indicates that the I2C transaction has completed
//and a STOP condition has been asserted on the bus.
//However the slave has NACKED either the address or data
//byte.
/* include any callback event handling code here if needed */
default:
break;
}
}
//****************************************************************************/
// Function: APP_SlaveDataforMaster
//
// Callback function from DRV_I2C_Tasks when operating as a Slave. When an
// address match is received by the Slave, this callback is executed and
// the buffer event depends on the R/W bit. If R/W = 0, DRV_I2C_Receive is
// called implying the Slave is going to read data send from the Master.
// If R/W = 1, DRV_I2C_Transmit is called implying the Slave is going to send
// data to the Master.
//****************************************************************************/
void APP_SlaveDataforMaster(DRV_I2C_BUFFER_EVENT event, void * context)
{
switch (event)
{
case DRV_I2C_BUFFER_SLAVE_READ_REQUESTED:
deviceAddressPIC32 = PIC32_SLAVE_ADDRESS;
bufHandle_S1 = DRV_I2C_Receive( drvI2CSlaveHandle,
deviceAddressPIC32,
&SlaveRxbuffer[0],
NUMBER_OF_UNKNOWN_BYTES_TO_SLAVE,
NULL );
break;
case DRV_I2C_BUFFER_SLAVE_WRITE_REQUESTED:
deviceAddressPIC32 = PIC32_SLAVE_ADDRESS;
bufHandle_S2 = DRV_I2C_Transmit ( drvI2CSlaveHandle,
deviceAddressPIC32,
&SlaveTxbuffer[0],
NUMBER_OF_UNKNOWN_BYTES_TO_SLAVE,
NULL );
break;
default:
break;
}
Volume V: MPLAB Harmony Framework Driver Libraries Help I2C Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 527
}
void __ISR(_I2C_2_VECTOR, ipl4AUTO) _IntHandlerDrvI2CInstance0(void)
{
DRV_I2C_Tasks(i2cMasterObject);
}
void __ISR(_I2C1_SLAVE_VECTOR, ipl6AUTO) _IntHandlerDrvI2CSlaveInstance1(void)
{
DRV_I2C_Tasks(i2cSlaveObject);
}
Configuring the Library
Macros
Name Description
DRV_DYNAMIC_BUILD Dynamic driver build, dynamic device instance
parameters.
DRV_I2C_CONFIG_BUILD_TYPE Selects static or dynamic driver build configuration.
DRV_I2C_CONFIG_SUPPORT_OPERATION_MODE_BASIC Enables the device driver to support basic transfer
mode.
DRV_I2C_CONFIG_SUPPORT_OPERATION_MODE_BLOCKING Enables the device driver to support blocking operations.
DRV_I2C_CONFIG_SUPPORT_OPERATION_MODE_EXCLUSIVE Enables the device driver to support operation in
Exclusive mode.
DRV_I2C_CONFIG_SUPPORT_OPERATION_MODE_MASTER Enables the device driver to support operation in Master
mode.
DRV_I2C_CONFIG_SUPPORT_OPERATION_MODE_NON_BLOCKING Enables the device driver to support non-blocking
during operations
DRV_I2C_CONFIG_SUPPORT_OPERATION_MODE_READ Enables the device driver to support read operations.
DRV_I2C_CONFIG_SUPPORT_OPERATION_MODE_SLAVE Enables the device driver to support operation in Slave
mode.
DRV_I2C_CONFIG_SUPPORT_OPERATION_MODE_WRITE Enables the device driver to support write operations.
DRV_I2C_CONFIG_SUPPORT_OPERATION_MODE_WRITE_READ Enables the device driver to support write followed by
read.
DRV_STATIC_BUILD Static driver build, static device instance parameters.
DRV_I2C_FORCED_WRITE Includes function that writes to slave irrespective of
whether receiving a ACK or NACK from slave
I2C_STATIC_DRIVER_MODE Selects the type of STATIC driver
Description
The configuration of the I2C Driver Library is based on the file sys_config.h.
This header file contains the configuration selection for the I2C Driver Library. Based on the selections made, the I2C Driver Library may support
the selected features. These configuration settings will apply to all instances of the I2C Driver Library.
This header can be placed anywhere; however, the path of this header needs to be present in the include search path for a successful build. Refer
to the Applications Help section for more details.
DRV_DYNAMIC_BUILD Macro
Dynamic driver build, dynamic device instance parameters.
File
drv_i2c_config_template.h
C
#define DRV_DYNAMIC_BUILD 1
Description
Dynamic Driver Build Configuration
This value, if used to identify the build type for a driver, will cause the driver to be built to dynamically, identify the instance of the peripheral at
run-time using the parameter passed into its API routines.
Volume V: MPLAB Harmony Framework Driver Libraries Help I2C Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 528
DRV_I2C_CONFIG_BUILD_TYPE Macro
Selects static or dynamic driver build configuration.
File
drv_i2c_config_template.h
C
#define DRV_I2C_CONFIG_BUILD_TYPE DRV_DYNAMIC_BUILD
Description
I2C Driver Build Configuration Type
This definition selects if I2C device driver is to be used with static or dynamic build parameters. Must be equated to one of the following values:
• DRV_STATIC_BUILD - Build the driver using static accesses to the peripheral identified by the DRV_I2C_INSTANCE macro
• DRV_DYNAMIC_BUILD - Build the driver using dynamic accesses to the peripherals
Affects all the drv_i2c.h driver functions.
DRV_I2C_CONFIG_SUPPORT_OPERATION_MODE_BASIC Macro
Enables the device driver to support basic transfer mode.
File
drv_i2c_config_template.h
C
#define DRV_I2C_CONFIG_SUPPORT_OPERATION_MODE_BASIC
Description
Support Basic Transfer Mode
This definition enables the device driver to support basic transfer mode.
Remarks
The device driver can support multiple modes within a single build.
This definition affects the following functions:
• DRV_I2C_TransmitThenReceive
Refer to the description of each function in the corresponding help file for details.
DRV_I2C_CONFIG_SUPPORT_OPERATION_MODE_BLOCKING Macro
Enables the device driver to support blocking operations.
File
drv_i2c_config_template.h
C
#define DRV_I2C_CONFIG_SUPPORT_OPERATION_MODE_BLOCKING
Description
Support Blocking Operations
This definition enables the device driver to support blocking operations.
Remarks
The device driver can support multiple modes within a single build.
This definition affects the following functions:
• DRV_I2C_Open
• DRV_I2C_Close
• DRV_I2C_Receive
Volume V: MPLAB Harmony Framework Driver Libraries Help I2C Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 529
• DRV_I2C_Transmit
• DRV_I2C_TransmitThenReceive
Refer to the description of each function in the corresponding help file for details.
DRV_I2C_CONFIG_SUPPORT_OPERATION_MODE_EXCLUSIVE Macro
Enables the device driver to support operation in Exclusive mode.
File
drv_i2c_config_template.h
C
#define DRV_I2C_CONFIG_SUPPORT_OPERATION_MODE_EXCLUSIVE
Description
Support Exclusive Mode
This definition enables the device driver to support operation in Exclusive mode.
Remarks
The device driver can support multiple modes within a single build.
This definition affects the following functions:
• DRV_I2C_Open
Refer to the description of each function in the corresponding help file for details.
DRV_I2C_CONFIG_SUPPORT_OPERATION_MODE_MASTER Macro
Enables the device driver to support operation in Master mode.
File
drv_i2c_config_template.h
C
#define DRV_I2C_CONFIG_SUPPORT_OPERATION_MODE_MASTER
Description
Support Master Mode
This definition enables the device driver to support operation in Master mode.
Remarks
During the configuration phase, the driver selects a list of operation modes that can be supported. While initializing a hardware instance, the
device driver will properly perform the initialization base on the selected modes.
The device driver can support multiple modes within a single build.
Refer to the description of each function in the corresponding help file for details.
DRV_I2C_CONFIG_SUPPORT_OPERATION_MODE_NON_BLOCKING Macro
Enables the device driver to support non-blocking during operations
File
drv_i2c_config_template.h
C
#define DRV_I2C_CONFIG_SUPPORT_OPERATION_MODE_NON_BLOCKING
Description
Support Non-Blocking Operations
This definition enables the device driver to support non-blocking operations.
Remarks
The device driver can support multiple modes within a single build.
This definition affects the following functions:
Volume V: MPLAB Harmony Framework Driver Libraries Help I2C Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 530
• DRV_I2C_Open
• DRV_I2C_Close
Refer to the description of each function in the corresponding help file for details.
DRV_I2C_CONFIG_SUPPORT_OPERATION_MODE_READ Macro
Enables the device driver to support read operations.
File
drv_i2c_config_template.h
C
#define DRV_I2C_CONFIG_SUPPORT_OPERATION_MODE_READ
Description
Support Read Mode
This definition enables the device driver to support read operations.
Remarks
The device driver can support multiple modes within a single build.
This definition affects the following functions:
• DRV_I2C_Receive
Refer to the description of each function in the corresponding help file for details.
DRV_I2C_CONFIG_SUPPORT_OPERATION_MODE_SLAVE Macro
Enables the device driver to support operation in Slave mode.
File
drv_i2c_config_template.h
C
#define DRV_I2C_CONFIG_SUPPORT_OPERATION_MODE_SLAVE
Description
Support Slave Mode
This definition enables the device driver to support operation in Slave mode.
Remarks
During the configuration phase, the driver selects a list of operation modes that can be supported. While initializing a hardware instance, the
device driver will properly perform the initialization base on the selected modes.
The device driver can support multiple modes within a single build.
Refer to the description of each function in the corresponding help file for details.
DRV_I2C_CONFIG_SUPPORT_OPERATION_MODE_WRITE Macro
Enables the device driver to support write operations.
File
drv_i2c_config_template.h
C
#define DRV_I2C_CONFIG_SUPPORT_OPERATION_MODE_WRITE
Description
Support Write Mode
This definition enables the device driver to support write operations.
Remarks
The device driver can support multiple modes within a single build.
This definition affects the following functions:
Volume V: MPLAB Harmony Framework Driver Libraries Help I2C Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 531
• DRV_I2C_Transmit
Refer to the description of each function in the corresponding help file for details.
DRV_I2C_CONFIG_SUPPORT_OPERATION_MODE_WRITE_READ Macro
Enables the device driver to support write followed by read.
File
drv_i2c_config_template.h
C
#define DRV_I2C_CONFIG_SUPPORT_OPERATION_MODE_WRITE_READ
Description
Support Write followed by a Read using Restart
This definition enables the device driver to support write followed by read without relinquishing control of the bus. Restart is issued instead of Stop
at the end of write. Stop is issued after read operation.
Remarks
The device driver can support multiple modes within a single build.
This definition affects the following functions:
• DRV_I2C_TransmitThenReceive
Refer to the description of each function in the corresponding help file for details.
DRV_STATIC_BUILD Macro
Static driver build, static device instance parameters.
File
drv_i2c_config_template.h
C
#define DRV_STATIC_BUILD 0
Description
Static Driver Build Configuration
This value, if used to identify the build type for a driver, will cause the driver to be built using a specific statically identified instance of the peripheral.
DRV_I2C_FORCED_WRITE Macro
Includes function that writes to slave irrespective of whether receiving a ACK or NACK from slave
File
drv_i2c_config_template.h
C
#define DRV_I2C_FORCED_WRITE true
Description
I2C driver objects configuration
When this option is checked, this will include Forced Write function. The Force Write function will send all data bytes to the slave irrespective of
receiving ACK or NACK from slave. If writing data to the slave is invoked using DRV_I2C_Transfer, the transaction will be aborted if the Slave
NACKs address or any data byte and a STOP condition will be send. This function is typically included for Slaves that require a special reset
sequence.
Remarks
None
I2C_STATIC_DRIVER_MODE Macro
Selects the type of STATIC driver
Volume V: MPLAB Harmony Framework Driver Libraries Help I2C Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 532
File
drv_i2c_config_template.h
C
#define I2C_STATIC_DRIVER_MODE BUFFER_MODEL_STATIC
Description
I2C Static Driver type
This selects either the BYTE_MODEL_STATIC or BUFFER_MODEL_STATIC version of I2C driver. The BYTE_MODEL_STATIC version is
equivalent to and is referred to as STATIC driver implementation in Harmony Versions 1.06.02 and below. This version of STATIC driver is not
recommended for new design and will be deprecated in future release. The BUFFER_MODEL_STATIC supports transfer of buffers and is API
compatible with the DYNAMIC implementation of I2C.
Building the Library
This section lists the files that are available in the I2C Driver Library.
Description
The following three tables list and describe the header (.h) and source (.c) files that implement this library. The parent folder for these files is
/framework/driver/i2c.
Interface File(s)
This table lists and describes the header files that must be included (i.e., using #include) by any code that uses this library.
Source File Name Description
/drv_i2c.h This file provides the interface definitions of the I2C driver.
/drv_i2c_bb.h This file provides interface definitions that are transparent to the user when the I2C Driver is used in Bit-bang
mode.
/src/drv_i2c_local.h This file provides definitions of the data types that are used in the driver object.
Required File(s)
All of the required files listed in the following table are automatically added into the MPLAB X IDE project by the MHC
when the library is selected for use.
This table lists and describes the source and header files that must always be included in the MPLAB X IDE project to build this library.
Source File Name Description
/src/dynamic/drv_i2c.c This file contains the core implementation of the I2C driver.
/src/dynamic/drv_i2c_bb.c This file implements the I2C Driver in Bit-bang mode.
Optional File(s)
This table lists and describes the source and header files that may optionally be included if required for the desired implementation.
Source File Name Description
N/A No optional files exist for this library.
Module Dependencies
The I2C Driver Library depends on the following modules:
• Clock System Service Library
Library Interface
a) System Interaction Functions
Name Description
DRV_I2C_Deinitialize Deinitializes the index instance of the I2C module.
Implementation: Static/Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help I2C Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 533
DRV_I2C_Initialize Initializes hardware and data for the index instance of the I2C module.
Implementation: Static/Dynamic
DRV_I2C_Tasks Maintains the State Machine of the I2C driver and performs all the protocol level actions.
Implementation: Dynamic
b) Client Setup Functions
Name Description
DRV_I2C_Close Closes an opened instance of an I2C module driver.
Implementation: Dynamic
DRV_I2C_Open Opens the specified instance of the I2C driver for use and provides an "open-instance"
handle.
Implementation: Dynamic
c) Data Transfer Functions
Name Description
DRV_I2C_BufferEventHandlerSet Allows a client to identify a buffer event handling function for the driver to call back when
queued buffer transfers have finished.
Implementation: Dynamic
DRV_I2C_BytesTransferred Returns the number of bytes transmitted or received in a particular I2C transaction. The
transaction is identified by the handle.
DRV_I2C_Receive This function reads data written from either Master or Slave.
Implementation: Dynamic
DRV_I2C_Transmit This function writes data to Master or Slave.
Implementation: Dynamic
DRV_I2C_TransmitThenReceive This function writes data to Slave, inserts restart and requests read from slave.
Implementation: Dynamic
DRV_I2C_TransmitForced This function writes data to Master or Slave.
Implementation: Dynamic
d) Status Functions
Name Description
DRV_I2C_TransferStatusGet Returns status of data transfer when Master or Slave acts either as a transmitter or a receiver.
Implementation: Dynamic
DRV_I2C_Status Provides the current status of the index instance of the I2C module.
Implementation: Dynamic
e) Miscellaneous Functions
Name Description
DRV_I2C_QueueFlush The existing transactions in the queue are voided and the queue pointers are reset to their
initial state. This renders the queue empty.
DRV_I2C_SlaveCallbackSet Allows a client to identify a Slave Callback function for the driver to call back when drivers
needs to initiate a read or write operation.
f) Data Types and Constants
Name Description
DRV_I2C_BUFFER_QUEUE_SUPPORT Specifies if the Buffer Queue support should be enabled.
DRV_I2C_INSTANCES_NUMBER Sets up the maximum number of hardware instances that can be supported
DRV_I2C_INTERRUPT_MODE Macro controls interrupt based operation of the driver
DRV_I2C_QUEUE_DEPTH_COMBINED Number of entries of all queues in all instances of the driver.
DRV_I2C_BB_H This is macro DRV_I2C_BB_H.
Description
This section describes the Application Programming Interface (API) functions of the I2C Driver Library.
Refer to each section for a detailed description.
a) System Interaction Functions
Volume V: MPLAB Harmony Framework Driver Libraries Help I2C Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 534
DRV_I2C_Deinitialize Function
Deinitializes the index instance of the I2C module.
Implementation: Static/Dynamic
File
drv_i2c.h
C
void DRV_I2C_Deinitialize(SYS_MODULE_OBJ object);
Returns
None.
Description
This function deinitializes the index instance of the I2C module, disabling its operation (and any hardware for driver modules). It deinitializes only
the specified module instance. It also resets all the internal data structures and fields for the specified instance to the default settings.
Remarks
If the module instance has to be used again, DRV_I2C_Initialize should be called again to initialize the module instance structures.
This function may block if the driver is running in an OS environment that supports blocking operations and the driver requires system resources
access. However, the routine will NEVER block for hardware I2C access. If the operation requires time to allow the hardware to complete, this will
be reported by the DRV_I2C_Status operation. The driver client must always use DRV_I2C_Status to find out when the module is in the ready
state.
Preconditions
The DRV_I2C_Initialize function should have been called before calling this function.
Example
SYS_STATUS i2c_status;
DRV_I2C_Deinitialize(I2C_ID_1);
i2c_status = DRV_I2C_Status(I2C_ID_1);
if (SYS_STATUS_BUSY == i2c_status)
{
// Do something else and check back later
}
else if (SYS_STATUS_ERROR >= i2c_status)
{
// Handle error
}
Parameters
Parameters Description
index Index, identifying the instance of the I2C module to be deinitialized
Function
void DRV_I2C_Deinitialize ( SYS_MODULE_OBJ object )
DRV_I2C_Initialize Function
Initializes hardware and data for the index instance of the I2C module.
Implementation: Static/Dynamic
File
drv_i2c.h
C
SYS_MODULE_OBJ DRV_I2C_Initialize(const SYS_MODULE_INDEX index, const SYS_MODULE_INIT * const init);
Volume V: MPLAB Harmony Framework Driver Libraries Help I2C Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 535
Returns
None.
Description
This function initializes hardware for the index instance of the I2C module, using the hardware initialization given data. It also initializes any internal
driver data structures making the driver ready to be opened.
Remarks
This function must be called before any other I2C function is called.
This function should only be called once during system initialization unless DRV_I2C_Deinitialize is first called to deinitialize the device instance
before reinitializing it.
This function may block if the driver is running in an OS environment that supports blocking operations and the driver requires system resources
access. However, the routine will NEVER block for hardware I2C access. If the operation requires time to allow the hardware to complete, this will
be reported by the DRV_I2C_Status operation. The driver client must always use DRV_I2C_Status to find out when the module is in the ready
state.
Whenever a call to DRV_I2C_Initialize is made with a SYS_MODULE_INIT* data == 0 the following default configuration will be used. Adjust this
configuration at build time as needed.
Preconditions
None.
Example
DRV_I2C_INIT i2c_init_data;
SYS_MODULE_OBJ objectHandle;
i2c_init_data.i2cId = DRV_I2C_PERIPHERAL_ID_IDX0,
i2c_init_data.i2cMode = DRV_I2C_MODE_MASTER,
OR
i2c_init_data.i2cMode = DRV_I2C_MODE_SLAVE,
//Master mode parameters
i2c_init_data.baudRate = 100000,
i2c_init_data.busspeed = DRV_I2C_SLEW_RATE_CONTROL_IDX0,
i2c_init_data.buslevel = DRV_I2C_SMBus_SPECIFICATION_IDX0,
//Slave mode parameters
i2c_init_data.addWidth = DRV_I2C_7BIT_SLAVE,
i2c_init_data.reservedaddenable = false,
i2c_init_data.generalcalladdress = false,
i2c_init_data.slaveaddvalue = 0x0060,
//interrupt sources
i2c_init_data.mstrInterruptSource = INT_SOURCE_I2C_2_MASTER,
i2c_init_data.slaveInterruptSource = INT_SOURCE_I2C_2_ERROR,
i2c_init_data.errInterruptSource = INT_SOURCE_I2C_2_ERROR,
i2c_init_data.queueSize = 1,
//callback for Master (Master mode can use callbacks if needed)
i2c_init_data.operationStarting = NULL,
// Slave mode callbacks needed
i2c_init_data.operationStarting = APP_I2CSlaveFunction(),
i2c_init_data.operationEnded = NULL
objectHandle = DRV_I2C_Initialize(DRV_I2C_INDEX_0, (SYS_MODULE_INIT *)&drvI2C0InitData)
if (SYS_MODULE_OBJ_INVALID == objectHandle)
{
// Handle error
}
Parameters
Parameters Description
index Index, identifying the instance of the I2C module to be initialized
Volume V: MPLAB Harmony Framework Driver Libraries Help I2C Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 536
data Pointer to the data structure containing any data necessary to initialize the hardware. This
pointer may be null if no data is required and the default initialization is to be used.
Function
void DRV_I2C_Initialize ( const I2C_MODULE_ID index,
const SYS_MODULE_INIT *const data )
DRV_I2C_Tasks Function
Maintains the State Machine of the I2C driver and performs all the protocol level actions.
Implementation: Dynamic
File
drv_i2c.h
C
void DRV_I2C_Tasks(SYS_MODULE_OBJ object);
Description
This functions maintains the internal state machine of the I2C driver. This function acts as the I2C Master or Slave ISR. When used in polling
mode, this function needs to be called repeatedly to achieve I2C data transfer. This function implements all the protocol level details like setting the
START condition, sending the address with with R/W request, writing data to the SFR, checking for acknowledge and setting the STOP condition.
Preconditions
The DRV_I2C_Initialize routine must have been called for the specified I2C device instance.
Example
SYS_MODULE_OBJ object;
while (true) { DRV_I2C_Tasks ( object );
Function
void DRV_I2C_Tasks (SYS_MODULE_OBJ object)
b) Client Setup Functions
DRV_I2C_Close Function
Closes an opened instance of an I2C module driver.
Implementation: Dynamic
File
drv_i2c.h
C
void DRV_I2C_Close(DRV_HANDLE handle);
Returns
None.
Description
This function closes an opened instance of an I2C module driver, making the specified handle invalid.
Remarks
After calling This function, the handle passed into drvHandle must not be used with any of the remaining driver routines. A new handle must be
obtained by calling DRV_I2C_Open before the caller may use the driver again.
Preconditions
The DRV_I2C_Initialize routine must have been called for the specified I2C device instance and the DRV_I2C_Status must have returned
SYS_STATUS_READY.
DRV_I2C_Open must have been called to obtain a valid opened device handle.
Volume V: MPLAB Harmony Framework Driver Libraries Help I2C Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 537
Example
myI2CHandle = DRV_I2C_Open(I2C_ID_1, DRV_IO_INTENT_NONBLOCKING|DRV_IO_INTENT_READWRITE);
// Perform data transfer operations
DRV_I2C_Close(myI2CHandle);
Parameters
Parameters Description
drvHandle A valid open-instance handle, returned from the driver's open routine
Function
void DRV_I2C_Close ( const DRV_HANDLE drvHandle )
DRV_I2C_Open Function
Opens the specified instance of the I2C driver for use and provides an "open-instance" handle.
Implementation: Dynamic
File
drv_i2c.h
C
DRV_HANDLE DRV_I2C_Open(const SYS_MODULE_INDEX index, const DRV_IO_INTENT intent);
Returns
If successful, the routine returns a valid open-instance handle (a value identifying both the caller and the module instance). If an error occurs, the
returned value is DRV_HANDLE_INVALID.
If an error occurs, the return value is DRV_HANDLE_INVALID. An error can occur when the following is true:
• if the number of client objects allocated via DRV_I2C_INSTANCES_NUMBER is insufficient
• if the client is trying to open the driver but driver has been opened exclusively by another client
• if the driver hardware instance being opened is not initialized or is invalid
Description
This function opens the specified instance of the I2C module for use and provides a handle that is required to use the remaining driver routines.
This function opens a specified instance of the I2C module driver for use by any client module and provides an "open-instance" handle that must
be provided to any of the other I2C driver operations to identify the caller and the instance of the I2C driver/hardware module.
Remarks
The handle returned is valid until the DRV_I2C_Close routine is called.
This function may block if the driver is running in an OS environment that supports blocking operations and the driver requires system resources
access. Regarding the hardware I2C access the operation will behave as instructed by the DRV_IO_INTENT parameter.
Preconditions
The DRV_I2C_Initialize routine must have been called for the specified I2C device instance and the DRV_I2C_Status must have returned
SYS_STATUS_READY.
Example
DRV_HANDLE i2c_handle;
i2c_handle = DRV_I2C_Open(I2C_ID_1, DRV_IO_INTENT_NONBLOCKING|DRV_IO_INTENT_READWRITE);
if (DRV_HANDLE_INVALID == i2c_handle)
{
// Handle open error
}
// Close the device when it is no longer needed.
DRV_I2C_Close(i2c_handle);
Volume V: MPLAB Harmony Framework Driver Libraries Help I2C Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 538
Parameters
Parameters Description
index Index, identifying the instance of the I2C module to be opened.
intent Flags parameter identifying the intended usage and behavior of the driver. Multiple flags may
be ORed together to specify the intended usage of the device. See the DRV_IO_INTENT
definition.
Function
DRV_HANDLE DRV_I2C_Open ( const I2C_MODULE_ID index,
const DRV_IO_INTENT intent )
c) Data Transfer Functions
DRV_I2C_BufferEventHandlerSet Function
Allows a client to identify a buffer event handling function for the driver to call back when queued buffer transfers have finished.
Implementation: Dynamic
File
drv_i2c.h
C
void DRV_I2C_BufferEventHandlerSet(const DRV_HANDLE handle, const DRV_I2C_BUFFER_EVENT_HANDLER
eventHandler, const uintptr_t context);
Returns
None.
Description
This function allows a client to identify a buffer event handling function for the driver to call back when a queued buffer transfer has finished. When
a client calls either the DRV_I2C_Receive, DRV_I2C_Transmit or DRV_I2C_TransmiThenReceive function, it is provided with a handle identifying
the buffer that was added to the driver's buffer queue. The driver will pass this handle back to the client by calling "eventHandler" function when
the buffer transfer has completed.
The event handler should be set before the client performs any transmision or reception operations that could generate events. The event handler
once set, persists until the client closes the driver or sets another event handler (which could be a "NULL" pointer to indicate no callback).
When in Master mode, a callback event is registered to let the application know that the buffer has been transmitted.
DRV_I2C_BUFFER_EVENT_COMPLETE is set when the buffer has been transmitted without any errors. DRV_I2C_BUFFER_EVENT_ERROR is
set when buffer transmission or reception has been aborted.
When in Slave mode, since the Master controls when a transmit or receive operation is terminated, a callback is registered every time a byte is
written or read from the slave.
Remarks
If the client does not want to be notified when the queued buffer transfer has completed, it does not need to register a callback. This function is
thread safe when called in a RTOS application.
Preconditions
The DRV_I2C_Initialize routine must have been called for the specified I2C driver instance.
DRV_I2C_Open must have been called to obtain a valid opened device handle.
Example
#define MY_BUFFER_SIZE 10
// function prototype of Event Handler Function
void APP_I2CBufferEventFunction ( DRV_I2C_BUFFER_EVENT event,
DRV_I2C_BUFFER_HANDLE bufferHandle,
uintptr_t context );
//Returned from DRV_I2C_Open
DRV_HANDLE drvI2Chandle;
// myAppObj is an application specific state data object.
Volume V: MPLAB Harmony Framework Driver Libraries Help I2C Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 539
DRV_I2C_BUFFER_EVENT operationStatus;
uint8_t appBuffer[MY_BUFFER_SIZE];
DRV_I2C_BUFFER_HANDLE drvI2CRDBUFHandle
// Opens an instance of I2C driver
drvI2Chandle = DRV_I2C_Open( DRV_I2C_INDEX_0,DRV_IO_INTENT_WRITE );
// Client registers an event handler with driver. This is done once.
DRV_I2C_BufferEventHandlerSet( drvI2Chandle,
APP_I2CBufferEventFunction,
operationStatus );
drvI2CRDBUFHandle = DRV_I2C_Receive ( drvI2CHandle,
slaveaddress
&appBuffer[],
MY_BUFFER_SIZE,
NULL );
if(NULL == drvI2CRDBUFHandle)
{
// Error handling here
}
// Event Processing Technique. Event is received when
// the buffer is processed.
void APP_I2CBufferEventFunction( DRV_I2C_BUFFER_EVENT event,
DRV_I2C_BUFFER_HANDLE handle,
uintptr_t context)
{
switch(event)
{
case DRV_I2C_BUFFER_EVENT_COMPLETE:
//perform appropriate action
break;
case DRV_I2C_BUFFER_EVENT_ERROR:
// Error handling here.
break;
default:
break;
}
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
eventHandler Pointer to the event handler function.
context The value of parameter will be passed back to the client unchanged, when the eventHandler
function is called. It can be used to identify any client specific data object that identifies the
instance of the client module (for example, it may be a pointer to the client module's state
structure).
Function
void DRV_I2C_BufferEventHandlerSet (
const DRV_HANDLE handle,
const DRV_I2C_BUFFER_EVENT_HANDLER eventHandler,
const uintptr_t context )
DRV_I2C_BytesTransferred Function
Returns the number of bytes transmitted or received in a particular I2C transaction. The transaction is identified by the handle.
Volume V: MPLAB Harmony Framework Driver Libraries Help I2C Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 540
File
drv_i2c.h
C
uint32_t DRV_I2C_BytesTransferred(DRV_HANDLE handle, DRV_I2C_BUFFER_HANDLE bufferHandle);
Returns
The number of bytes transferred in a particular I2C transaction.
numOfBytes = DRV_I2C_BytesTransferred (drvI2CHandle_Master,drvBufferHandle);
Description
This returns the transmitter and receiver transfer status.
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
bufferHandle A valid buffer handle obtained when calling
Transmit/Receive/TransmitThenReceive/TransmitForced or
BufferAddRead/BufferAddWrite/BufferAddReadWrite function
Function
uint32_t DRV_I2C_BytesTransferred ( DRV_I2C_BUFFER_HANDLE bufferHandle )
DRV_I2C_Receive Function
This function reads data written from either Master or Slave.
Implementation: Dynamic
File
drv_i2c.h
C
DRV_I2C_BUFFER_HANDLE DRV_I2C_Receive(DRV_HANDLE handle, uint16_t address, void * buffer, size_t size, void
* callbackContext);
Returns
A valid BUFFER HANDLE, NULL if the handle is not obtained.
Description
Master calls this function to read data send by Slave. The Slave calls this function to read data send by Master. In case of Master, a START
condition is initiated on the I2C bus.
Remarks
The handle that is passed into the function, drvI2CHandle is obtained by calling the DRV_I2C_OPEN function. If the function could not return a
valid buffer handle, then a NULL value is returned. If the slave NACKs the address byte, then further read is not attempted. Master asserts STOP
condition and DRV_I2C_BUFFER_EVENT_ERROR is set as the buffer-status. If all the requisite number of bytes have been read then
DRV_I2C_BUFFER_EVENT_COMPLETE is set as the buffer status.
Preconditions
The DRV_I2C_Initialize routine must have been called for the specified I2C device instance and the DRV_I2C_Status must have returned
SYS_STATUS_READY.
DRV_I2C_Open must have been called to obtain a valid opened device handle.
Example
drvI2CRDBUFHandle = DRV_I2C_Receive( drvI2CHandle,
deviceaddress,
&rxbuffer[0],
num_of_bytes,
NULL );
Volume V: MPLAB Harmony Framework Driver Libraries Help I2C Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 541
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
address Device address of slave shifted so that bits 7 - 1 are address
bits A6 A0. This value is Ignored in slave mode.
buffer This buffer holds data is received
size The number of bytes that the Master expects to read from Slave. This value can be kept as
the MAX BUFFER SIZE for slave. This is because the Master controls when the READ
operation is terminated.
callbackContext Not implemented, future expansion
Function
DRV_I2C_BUFFER_HANDLE DRV_I2C_Receive ( DRV_HANDLE handle,
uint16_t slaveaddress,
void *rxBuffer,
size_t size,
void * callbackContext )
DRV_I2C_Transmit Function
This function writes data to Master or Slave.
Implementation: Dynamic
File
drv_i2c.h
C
DRV_I2C_BUFFER_HANDLE DRV_I2C_Transmit(DRV_HANDLE handle, uint16_t slaveaddress, void * buffer, size_t
size, void * context);
Returns
A valid BUFFER HANDLE, NULL if the handle is not obtained.
Description
Master calls this function to write data to Slave. The Slave calls this function to write data to Master.
Remarks
The handle that is passed into the function, drvI2CHandle is obtained by calling the DRV_I2C_OPEN function. If the function could not return a
valid buffer handle, then a NULL value is returned. If the slave NACKs the address byte or any data bytes, then further write is not attempted.
Master asserts STOP condition and DRV_I2C_BUFFER_EVENT_ERROR is set as the buffer-status. If all the requisite number of bytes have been
transmitted to the Slave, then DRV_I2C_BUFFER_EVENT_COMPLETE is set as the buffer status.
Preconditions
The DRV_I2C_Initialize routine must have been called for the specified I2C device instance and the DRV_I2C_Status must have returned
SYS_STATUS_READY.
DRV_I2C_Open must have been called to obtain a valid opened device handle.
Example
drvI2CWRBUFHandle = DRV_I2C_Transmit( drvI2CHandle,
deviceaddress,
&txBuffer[0],
num_of_bytes,
NULL);
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
address Device address of slave shifted so that bits 7 - 1 are address
bits A6 A0. This value is Ignored in slave mode.
buffer Contains data to be transferred
Volume V: MPLAB Harmony Framework Driver Libraries Help I2C Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 542
size The number of bytes that the Master expects to write to Slave. This value can be kept as the
MAX BUFFER SIZE for slave. This is because the Master controls when the WRITE operation
is terminated.
callbackContext Not implemented, future expansion
Function
DRV_I2C_BUFFER_HANDLE DRV_I2C_Transmit( DRV_HANDLE handle,
uint16_t slaveaddress,
void *txBuffer,
size_t size,
void *context);
DRV_I2C_TransmitThenReceive Function
This function writes data to Slave, inserts restart and requests read from slave.
Implementation: Dynamic
File
drv_i2c.h
C
DRV_I2C_BUFFER_HANDLE DRV_I2C_TransmitThenReceive(DRV_HANDLE handle, uint16_t address, void * writeBuffer,
size_t writeSize, void * readBuffer, size_t readSize, void * callbackContext);
Returns
A valid BUFFER HANDLE, NULL if the handle is not obtained.
Description
Master calls this function to send a register address value to the slave and then queries the slave with a read request to read the contents indexed
by the register location. The Master sends a restart condition after the initial write before sending the device address with R/W = 1. The restart
condition prevents the Master from relinquishing the control of the bus. The slave should not use this function.
Remarks
The handle that is passed into the function, drvI2CHandle is obtained by calling the DRV_I2C_OPEN function. If the function could not return a
valid buffer handle, then a NULL value is returned. If there is any error condition during transmission then further transmission or reception is not
attempted and STOP condition is asserted on the bus. In case of error condition, DRV_I2C_BUFFER_EVENT_ERROR is set as the buffer-status.
If the I2C bus transaction is completed as requested then the buffer status, is set as DRV_I2C_BUFFER_EVENT_COMPLETE.
Preconditions
The DRV_I2C_Initialize routine must have been called for the specified I2C device instance and the DRV_I2C_Status must have returned
SYS_STATUS_READY.
DRV_I2C_Open must have been called to obtain a valid opened device handle.
Example
drvI2CRDBUFHandle = DRV_I2C_TransmiThenReceive( appData.drvI2CHandle,
deviceaddress,
&drvI2CTXbuffer[0],
registerbytesize,
rxbuffer,
num_of_bytes,
NULL );
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
address Device address of slave shifted so that bits 7 - 1 are address
bits A6 A0. This value is Ignored in slave mode.
writeBuffer Contains data to be transferred
writeSize The number of bytes that the Master expects to write to Slave. This value can be kept as the
MAX BUFFER SIZE for slave. This is because the Master controls when the WRITE operation
is terminated.
readBuffer This buffer holds data that is send back from slave after read operation.
Volume V: MPLAB Harmony Framework Driver Libraries Help I2C Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 543
readSize The number of bytes the Master expects to be read from the slave
callbackContext Not implemented, future expansion
Function
DRV_I2C_BUFFER_HANDLE DRV_I2C_TransmiThenReceive ( DRV_HANDLE handle,
uint16_t deviceaddress,
void *txBuffer,
size_t writeSize,
void *rxBuffer,
size_t readSize,
void *context)
DRV_I2C_TransmitForced Function
This function writes data to Master or Slave.
Implementation: Dynamic
File
drv_i2c.h
C
DRV_I2C_BUFFER_HANDLE DRV_I2C_TransmitForced(DRV_HANDLE handle, uint16_t deviceaddress, void* txBuffer,
size_t txbuflen, DRV_I2C_BUS_ERROR_EVENT eventFlag, void * calbackContext);
Returns
A valid BUFFER HANDLE, NULL if the handle is not obtained.
Description
Master calls this function to transmit the entire buffer to the slave even if the slave ACKs or NACKs the address or any of the data bytes. This is
typically used for slaves that have to initiate a reset sequence by sending a dummy I2C transaction. Since the slave is still in reset, any or all the
bytes can be NACKed. In the normal operation of the driver if the address or data byte is NACKed, then the transmission is aborted and a STOP
condition is asserted on the bus.
Remarks
The handle that is passed into the function, drvI2CHandle is obtained by calling the DRV_I2C_OPEN function. If the function could not return a
valid buffer handle, then a NULl value is returned. Once all the bytes are transferred the buffer status is set as then
DRV_I2C_BUFFER_EVENT_COMPLETE .
Preconditions
The DRV_I2C_Initialize routine must have been called for the specified I2C device instance and the DRV_I2C_Status must have returned
SYS_STATUS_READY.
DRV_I2C_Open must have been called to obtain a valid opened device handle.
Example
drvI2CWRBUFHandle = DRV_I2C_TransmitForced ( handle,
deviceaddress,
&txBuffer[0],
txbuflen,
NULL,
NULL)
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
address Device address of slave shifted so that bits 7 - 1 are address
bits A6 A0. This value is Ignored in slave mode.
buffer Contains data to be transferred
size The number of bytes that the Master expects to write to Slave. This value can be kept as the
MAX BUFFER SIZE for slave. This is because the Master controls when the WRITE operation
is terminated.
eventFlag This field is left for future implementation
Volume V: MPLAB Harmony Framework Driver Libraries Help I2C Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 544
callbackContext Not implemented, future expansion
Function
DRV_I2C_BUFFER_HANDLE DRV_I2C_TransmitForced ( DRV_HANDLE handle,
uint16_t deviceaddress,
uint8_t* txBuffer,
uint16_t txbuflen,
DRV_I2C_BUS_ERROR_EVENT eventFlag,
void * calbackContext)
d) Status Functions
DRV_I2C_TransferStatusGet Function
Returns status of data transfer when Master or Slave acts either as a transmitter or a receiver.
Implementation: Dynamic
File
drv_i2c.h
C
DRV_I2C_BUFFER_EVENT DRV_I2C_TransferStatusGet(DRV_HANDLE handle, DRV_I2C_BUFFER_HANDLE bufferHandle);
Returns
A DRV_I2C_TRANSFER_STATUS value describing the current status of the transfer.
Description
The bufferHandle parameter contains the buffer handle of the buffer that associated with the event. If the event is
DRV_I2C_BUFFER_EVENT_COMPLETE, it means that the data was transferred successfully. If the event is
DRV_I2C_BUFFER_EVENT_ERROR, it means that the data was not transferred successfully.
Remarks
The handle that is passed into the function, drvI2CBUFHandle is obtained by calling one of the data transfer functions. The drvI2CBUFHandle
should be a valid handle and not a NULL value. The DRV_I2C_BufferStatus can be called to check the progress of the data transfer operation. If
the buffer is transferred without any error, then DRV_I2C_BUFFER_EVENT_COMPLETE is returned. If an error condition is present, then
DRV_I2C_BUFFER_EVENT_ERROR is returned.
Example
if(DRV_I2C_BUFFER_EVENT_COMPLETE == DRV_I2C_TransferStatusGet ( handle,
bufferHandle ))
{
//perform action
return true;
}
else
{
//perform action
return false;
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
bufferHandle A valid buffer handle obtained when calling
Transmit/Receive/TransmitThenReceive/TransmitForced or
BufferAddRead/BufferAddWrite/BufferAddReadWrite function
Function
DRV_I2C_BUFFER_EVENT DRV_I2C_TransferStatusGet ( DRV_HANDLE handle,
DRV_I2C_BUFFER_HANDLE bufferHandle )
Volume V: MPLAB Harmony Framework Driver Libraries Help I2C Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 545
DRV_I2C_Status Function
Provides the current status of the index instance of the I2C module.
Implementation: Dynamic
File
drv_i2c.h
C
SYS_STATUS DRV_I2C_Status(SYS_MODULE_OBJ object);
Returns
• SYS_STATUS_READY - Indicates that any previous module operation for the specified I2Cmodule has completed.
• SYS_STATUS_BUSY - Indicates that a previous module operation for the specified I2C module has not yet completed
• SYS_STATUS_ERROR - Indicates that the specified I2C module is in an error state
Description
This function provides the current status of the index instance of the I2C module.
Remarks
The DRV_I2C_Status operation can be used to determine when any of the I2C module level operations has completed. The value returned by the
DRV_I2C_Status routine hast to be checked after calling any of the I2C module operations to find out when they have completed.
If the DRV_I2C_Status operation returns SYS_STATUS_BUSY, the previous operation has not yet completed. Once the DRV_I2C_Status
operation return SYS_STATUS_READY, any previous operations have completed.
The DRV_I2C_Status function will NEVER block.
If the DRV_I2C_Status operation returns an error value, the error may be cleared by calling the DRV_I2C_Initialize operation. If that fails, the
DRV_I2C_Deinitialize operation will need to be called, followed by the DRV_I2C_Initialize operation to return to normal operations.
Preconditions
The DRV_I2C_Initialize function should have been called before calling this function.
Example
SYS_MODULE_OBJ object;
SYS_STATUS i2c_status;
i2c_status = DRV_I2C_Status(object);
if (SYS_STATUS_BUSY == i2c_status)
{
// Do something else and check back later
}
else if (SYS_STATUS_ERROR >= status)
{
// Handle error
}
Parameters
Parameters Description
index Index, identifying the instance of the I2C module to get status for.
Function
SYS_STATUS DRV_I2C_Status ( SYS_MODULE_OBJ object )
e) Miscellaneous Functions
DRV_I2C_QueueFlush Function
The existing transactions in the queue are voided and the queue pointers are reset to their initial state. This renders the queue empty.
Volume V: MPLAB Harmony Framework Driver Libraries Help I2C Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 546
File
drv_i2c.h
C
void DRV_I2C_QueueFlush(DRV_HANDLE handle);
Returns
None
//Opens an instance of I2C driver
drvI2Chandle = DRV_I2C_Open( DRV_I2C_INDEX_0,DRV_IO_INTENT_WRITE );
DRV_I2C_QueueFlush ( drvI2CHandle );
Description
The existing transactions in the queue are voided and the queue pointers are reset to their initial state. This renders the queue empty.
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
void DRV_I2C_QueueFlush ( DRV_HANDLE handle )
DRV_I2C_SlaveCallbackSet Function
Allows a client to identify a Slave Callback function for the driver to call back when drivers needs to initiate a read or write operation.
File
drv_i2c.h
C
void DRV_I2C_SlaveCallbackSet(const DRV_HANDLE handle, const DRV_I2C_CallBack callback, const uintptr_t
context);
Returns
None
#define APP_I2C_BUFFER_SIZE 10
void APP_I2C_SlaveTransferCallback( DRV_I2C_BUFFER_EVENT event, void * context );
uint8_t slaveBuffer[ APP_I2C_BUFFER_SIZE ];
DRV_HANDLE drvI2CHandle;
void APP_I2C_SlaveTransferCallback( DRV_I2C_BUFFER_EVENT event, void * context )
{
switch (event)
{
case DRV_I2C_BUFFER_SLAVE_READ_REQUESTED:
{
appData.bufferReceive = DRV_I2C_Receive( drvI2CHandle,
0,
&slaveBuffer[0],
APP_I2C_BUFFER_SIZE,
NULL );
break;
}
case DRV_I2C_BUFFER_SLAVE_WRITE_REQUESTED:
{
appData.bufferTransmit = DRV_I2C_Transmit ( drvI2CHandle,
0,
&slaveBuffer[0],
APP_I2C_BUFFER_SIZE,
Volume V: MPLAB Harmony Framework Driver Libraries Help I2C Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 547
NULL );
break;
}
default:
{
break;
}
}
return;
}
// Opens an instance of I2C driver
drvI2Chandle = DRV_I2C_Open( DRV_I2C_INDEX_0, DRV_IO_INTENT_READWRITE );
// Set the operation callback
DRV_I2C_SlaveCallbackSet( drvI2Chandle, APP_I2C_SlaveTransferCallback, 0);
Description
This function allows a client to identify a Slave Callback function for the driver to call back when drivers needs to initiate a read or write operation.
When the I2C Slave driver receives a read or write event from master the callback is called to initiate the user defined action. The callback should
be set before the master requests for read or write operations. The event handler once set, persists until the client closes the driver or sets another
event handler.
In Slave mode, a callback event is registered to let the application know that master has requested for either read or write operation.
DRV_I2C_BUFFER_SLAVE_READ_REQUESTED is set when the master sends data and wants slave to read.
DRV_I2C_BUFFER_SLAVE_WRITE_REQUESTED is set when the master tries to read data from slave and wants slave to send the data.
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
callback pointer to the callback function.
context The value of parameter will be passed back to the client unchanged, when the callback
function is called. It can be used to identify any client specific data
Function
void DRV_I2C_SlaveCallbackSet ( const DRV_HANDLE handle,
const DRV_I2C_CallBack callback,
const uintptr_t context )
f) Data Types and Constants
DRV_I2C_BUFFER_QUEUE_SUPPORT Macro
Specifies if the Buffer Queue support should be enabled.
File
drv_i2c_config_template.h
C
#define DRV_I2C_BUFFER_QUEUE_SUPPORT false
Description
I2C Driver Buffer Queue Support
This macro defines if Buffer Queue support should be enabled. Setting this macro to true will enable buffer queue support and all buffer related
driver function.
Remarks
None
Volume V: MPLAB Harmony Framework Driver Libraries Help I2C Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 548
DRV_I2C_INSTANCES_NUMBER Macro
Sets up the maximum number of hardware instances that can be supported
File
drv_i2c_config_template.h
C
#define DRV_I2C_INSTANCES_NUMBER 5
Description
I2C driver objects configuration
Sets up the maximum number of hardware instances that can be supported. It is recommended that this number be set exactly equal to the
number of I2C modules that are needed by the application. Hardware Instance support consumes RAM memory space. If this macro is not
defined, then the driver will be built statically.
Remarks
None
DRV_I2C_INTERRUPT_MODE Macro
Macro controls interrupt based operation of the driver
File
drv_i2c_config_template.h
C
#define DRV_I2C_INTERRUPT_MODE true
Description
I2C Interrupt Mode Operation Control
This macro controls the interrupt based operation of the driver. The possible values it can take are
• true - Enables the interrupt mode
• false - Enables the polling mode
If the macro value is true, then Interrupt Service Routine for the interrupt should be defined in the application. The DRV_I2C_Tasks() routine
should be called in the ISR.
Remarks
None
DRV_I2C_QUEUE_DEPTH_COMBINED Macro
Number of entries of all queues in all instances of the driver.
File
drv_i2c_config_template.h
C
#define DRV_I2C_QUEUE_DEPTH_COMBINED 7
Description
I2C Driver Instance combined queue depth.
This macro defines the number of entries of all queues in all instances of the driver.
Each hardware instance supports a buffer queue for transmit and receive operations. The size of queue is specified either in driver initialization (for
dynamic build) or by macros (for static build). The hardware instance transmit buffer queue will queue transmit buffers submitted by the
DRV_I2C_Transmit() function. The hardware instance receive buffer queue will queue receive buffers submitted by the DRV_I2C_Receive()
function.
A buffer queue will contain buffer queue entries, each related to a BufferAdd request. This configuration macro defines total number of buffer
entries that will be available for use between all I2C driver hardware instances. The buffer queue entries are allocated to individual hardware
instances as requested by hardware instances. Once the request is processed, the buffer queue entry is free for use by other hardware instances.
Volume V: MPLAB Harmony Framework Driver Libraries Help I2C Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 549
The total number of buffer entries in the system determines the ability of the driver to service non blocking read and write requests. If a free buffer
entry is not available, the driver will not add the request and will return an invalid buffer handle. More the number of buffer entries, greater the
ability of the driver to service and add requests to its queue. A hardware instance additionally can queue up as many buffer entries as specified by
its transmit and receive buffer queue size.
As an example, consider the case of static single client driver application where full duplex non blocking operation is desired without queuing, the
minimum transmit queue depth and minimum receive queue depth should be 1. Hence the total number of buffer entries should be 2.
In the current implementation of I2C driver, queueing of Buffers is not supported. This will be added in a future release.
Remarks
None
DRV_I2C_BB_H Macro
File
drv_i2c_bb.h
C
#define DRV_I2C_BB_H
Description
This is macro DRV_I2C_BB_H.
Files
Files
Name Description
drv_i2c.h I2C module driver interface header.
drv_i2c_bb.h Contains prototypes for the I2C functions
drv_i2c_config_template.h I2C device driver configuration file.
Description
drv_i2c.h
I2C module driver interface header.
Functions
Name Description
DRV_I2C_BufferEventHandlerSet Allows a client to identify a buffer event handling function for the driver to call back when
queued buffer transfers have finished.
Implementation: Dynamic
DRV_I2C_BytesTransferred Returns the number of bytes transmitted or received in a particular I2C transaction. The
transaction is identified by the handle.
DRV_I2C_Close Closes an opened instance of an I2C module driver.
Implementation: Dynamic
DRV_I2C_Deinitialize Deinitializes the index instance of the I2C module.
Implementation: Static/Dynamic
DRV_I2C_Initialize Initializes hardware and data for the index instance of the I2C module.
Implementation: Static/Dynamic
DRV_I2C_Open Opens the specified instance of the I2C driver for use and provides an "open-instance"
handle.
Implementation: Dynamic
DRV_I2C_QueueFlush The existing transactions in the queue are voided and the queue pointers are reset to their
initial state. This renders the queue empty.
DRV_I2C_Receive This function reads data written from either Master or Slave.
Implementation: Dynamic
DRV_I2C_SlaveCallbackSet Allows a client to identify a Slave Callback function for the driver to call back when drivers
needs to initiate a read or write operation.
Volume V: MPLAB Harmony Framework Driver Libraries Help I2C Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 550
DRV_I2C_Status Provides the current status of the index instance of the I2C module.
Implementation: Dynamic
DRV_I2C_Tasks Maintains the State Machine of the I2C driver and performs all the protocol level actions.
Implementation: Dynamic
DRV_I2C_TransferStatusGet Returns status of data transfer when Master or Slave acts either as a transmitter or a receiver.
Implementation: Dynamic
DRV_I2C_Transmit This function writes data to Master or Slave.
Implementation: Dynamic
DRV_I2C_TransmitForced This function writes data to Master or Slave.
Implementation: Dynamic
DRV_I2C_TransmitThenReceive This function writes data to Slave, inserts restart and requests read from slave.
Implementation: Dynamic
Description
I2C Device Driver Interface Header File
This header file contains the function prototypes and definitions of the data types and constants that make up the interface to the I2C module
driver.
File Name
drv_i2c.h
Company
Microchip Technology Inc.
drv_i2c_bb.h
Contains prototypes for the I2C functions
Macros
Name Description
DRV_I2C_BB_H This is macro DRV_I2C_BB_H.
Description
I2C Bit Bang Functions Header File
File Name
drv_i2c_bb.h
Company
Microchip Technology Inc.
drv_i2c_config_template.h
I2C device driver configuration file.
Macros
Name Description
DRV_DYNAMIC_BUILD Dynamic driver build, dynamic device instance
parameters.
DRV_I2C_BUFFER_QUEUE_SUPPORT Specifies if the Buffer Queue support should be enabled.
DRV_I2C_CONFIG_BUILD_TYPE Selects static or dynamic driver build configuration.
DRV_I2C_CONFIG_SUPPORT_OPERATION_MODE_BASIC Enables the device driver to support basic transfer
mode.
DRV_I2C_CONFIG_SUPPORT_OPERATION_MODE_BLOCKING Enables the device driver to support blocking operations.
DRV_I2C_CONFIG_SUPPORT_OPERATION_MODE_EXCLUSIVE Enables the device driver to support operation in
Exclusive mode.
DRV_I2C_CONFIG_SUPPORT_OPERATION_MODE_MASTER Enables the device driver to support operation in Master
mode.
DRV_I2C_CONFIG_SUPPORT_OPERATION_MODE_NON_BLOCKING Enables the device driver to support non-blocking
during operations
Volume V: MPLAB Harmony Framework Driver Libraries Help I2C Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 551
DRV_I2C_CONFIG_SUPPORT_OPERATION_MODE_READ Enables the device driver to support read operations.
DRV_I2C_CONFIG_SUPPORT_OPERATION_MODE_SLAVE Enables the device driver to support operation in Slave
mode.
DRV_I2C_CONFIG_SUPPORT_OPERATION_MODE_WRITE Enables the device driver to support write operations.
DRV_I2C_CONFIG_SUPPORT_OPERATION_MODE_WRITE_READ Enables the device driver to support write followed by
read.
DRV_I2C_FORCED_WRITE Includes function that writes to slave irrespective of
whether receiving a ACK or NACK from slave
DRV_I2C_INSTANCES_NUMBER Sets up the maximum number of hardware instances
that can be supported
DRV_I2C_INTERRUPT_MODE Macro controls interrupt based operation of the driver
DRV_I2C_QUEUE_DEPTH_COMBINED Number of entries of all queues in all instances of the
driver.
DRV_STATIC_BUILD Static driver build, static device instance parameters.
I2C_STATIC_DRIVER_MODE Selects the type of STATIC driver
Description
I2C Device Driver Configuration
These file provides the list of all the configurations that can be used with the driver. This file should not be included in the driver.
File Name
drv_i2c_config.h
Company
Microchip Technology Inc.
I2S Driver Library Help
This section describes the I2S Driver Library.
Introduction
This library provides an interface to manage the Audio Protocol Interface Modes of the Serial Peripheral Interface (SPI) module on the Microchip
family of microcontrollers.
Description
The SPI module can be interfaced to most available codec devices to provide microcontroller-based audio solutions. The SPI module provides
support to the audio protocol functionality via four standard I/O pins. The four pins that make up the audio protocol interface modes are:
• SDIx: Serial Data Input for receiving sample digital audio data (ADCDAT)
• SDOx: Serial Data Output for transmitting digital audio data (DACDAT)
• SCKx: Serial Clock, also known as bit clock (BCLK)
• /SSx: Left/Right Channel Clock (LRCK)
BCLK provides the clock required to drive the data out or into the module, while LRCK provides the synchronization of the frame based on the
protocol mode selected.
In Master mode, the module generates both the BCLK on the SCKx pin and the LRCK on the /SSx pin. In certain devices, while in Slave mode, the
module receives these two clocks from its I2S partner, which is operating in Master mode.
When configured in Master mode, the leading edge of SCK and the LRCK are driven out within one SCK period of starting the audio protocol.
Serial data is shifted in or out with timings determined by the protocol mode set.
In Slave mode, the peripheral drives zeros out SDO, but does not transmit the contents of the transmit FIFO until it sees the leading edge of the
LRCK, after which time it starts receiving data.
Master Mode
Master Generating its Own Clock – Output BCLK and LRCK
Volume V: MPLAB Harmony Framework Driver Libraries Help I2S Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 552
Slave Mode
Codec Device as Master Derives MCLK from PIC32 Reference Clock Out
Audio Protocol Modes
The SPI module supports four audio protocol modes and can be operated in any one of these modes:
• I2S mode
• Left-Justified mode
• Right-Justified mode
• PCM/DSP mode
Using the Library
This topic describes the basic architecture of the I2S Driver Library and provides information and examples on its use.
Description
Interface Header File: drv_i2s.h
The interface to the I2S Driver Library is defined in the drv_i2s.h header file. Any C language source (.c) file that uses the I2S Driver Library
should include drv_i2s.h.
Please refer to the What is MPLAB Harmony? section for how the driver interacts with the framework.
Abstraction Model
The SPI Peripheral Library provides the low-level abstraction of the SPI module on the Microchip family of microcontrollers with a convenient C
language interface. This topic describes how that abstraction is modeled in the software and introduces the I2S Driver Library interface.
Description
I2S Software Abstraction Block Diagram
Different types of SPIs are available on Microchip microcontrollers. Some have an internal buffer mechanism and some do not. The buffer depth
varies across part families. The SPI Peripheral Library provides the ability to access these buffers. The I2S Driver Library abstracts out these
differences and provides a unified model for audio data transfer across different types of SPI modules.
Both the transmitter and receiver provide a buffer in the driver, which transmits and receives data to/from the hardware. The I2S Driver Library
provides a set of interfaces to perform the read and the write.
The following diagrams illustrate the model used by the I2S Driver Library for the transmitter and receiver.
Receiver Abstraction Model
Volume V: MPLAB Harmony Framework Driver Libraries Help I2S Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 553
Transmitter Abstraction Model
Library Overview
Refer to the Driver Library Overview section for information on how the driver operates in a system.
The I2S driver library provides an API interface to transfer/receive digital audio data using supported Audio protocols. The library interface routines
are divided into various sub-sections, which address one of the blocks or the overall operation of the I2S Driver Library.
Library Interface Section Description
System Interaction Functions Provides system module interfaces, device initialization, deinitialization,
reinitialization, tasks and status functions.
Client Setup Functions Provides open and close functions.
Data Transfer Functions Provides data transfer functions.
Miscellaneous Functions Provides driver miscellaneous functions such as baud rate setting, get error functions,
etc.
Data Types and Constants These data types and constants are required while interacting and setting up the I2S
Driver Library.
How the Library Works
The library provides interfaces to support:
• System Functionality
• Client Functionality
Note:
Not all modes are available on all devices. Please refer to the specific device data sheet to determine the supported modes.
System Access
This section provides information on system access.
Volume V: MPLAB Harmony Framework Driver Libraries Help I2S Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 554
Description
System Initialization
The system performs the initialization of the device driver with settings that affect only the instance of the device that is being initialized. During
system initialization, each instance of the I2S module would be initialized with the following configuration settings (either passed dynamically at run
time using DRV_I2S_INIT or by using Initialization Overrides) that are supported by the specific I2S device hardware:
• Device requested power state: one of the System Module Power States. For specific details please refer to Data Types and Constants in the
Library Interface section.
• The actual peripheral ID enumerated as the PLIB level module ID (e.g., SPI_ID_2)
• Defining the respective interrupt sources for TX, RX, DMA TX Channel, DMA RX Channel and Error Interrupt
The DRV_I2S_Initialize API returns an object handle of the type SYS_MODULE_OBJ. The object handle returned by the Initialize interface would
be used by the other system interfaces such as DRV_I2S_Deinitialize, DRV_I2S_Status, DRV_I2S_Tasks, and DRV_I2S_TasksError.
Notes:
1. The system initialization setting only effect the instance of the peripheral that is being initialized.
2. Configuration of the dynamic driver for DMA mode(uses DMA channel for data transfer) or Non DMA mode can be performed
by appropriately setting the 'dmaChannelTransmit' and 'dmaChannelReceive' variables of the DRV_I2S_INIT structure. For
example the TX will be in DMA mode when 'dmaChannelTransmit' is initialized to a valid supported channel number from the
enum DMA_CHANNEL. TX will be in Non DMA mode when 'dmaChannelTransmit' is initialized to 'DMA_CHANNEL_NONE'.
Example:
DRV_I2S_INIT init;
SYS_MODULE_OBJ objectHandle;
init.moduleInit.value = SYS_MODULE_POWER_RUN_FULL;
init.spiID = SPI_ID_1;
init.usageMode = DRV_I2S_MODE_MASTER;
init.baudClock = SPI_BAUD_RATE_MCLK_CLOCK;
init.baud = 48000;
init.clockMode = DRV_I2S_CLOCK_MODE_IDLE_HIGH_EDGE_FALL;
init.audioCommWidth = SPI_AUDIO_COMMUNICATION_24DATA_32FIFO_32CHANNEL;
init.audioTransmitMode = SPI_AUDIO_TRANSMIT_STEREO;
init.inputSamplePhase = SPI_INPUT_SAMPLING_PHASE_IN_MIDDLE;
init.protocolMode = DRV_I2S_AUDIO_I2S;
init.txInterruptSource = INT_SOURCE_SPI_1_TRANSMIT;
init.rxInterruptSource = INT_SOURCE_SPI_1_RECEIVE;
init.errorInterruptSource = INT_SOURCE_SPI_1_ERROR;
init.queueSizeTransmit = 3;
init.queueSizeReceive = 2;
init.dmaChannelTransmit = DMA_CHANNEL_NONE;
init.dmaChannelReceive = DMA_CHANNEL_NONE;
objectHandle = DRV_I2S_Initialize(DRV_I2S_INDEX_1, (SYS_MODULE_INIT*)init);
if (SYS_MODULE_OBJ_INVALID == objectHandle)
{
// Handle error
}
Task Routine
In a polled environment, the system will call DRV_I2S_Tasks and DRV_I2S_TasksError from the System Task Service. In an interrupt-based
implementation, DRV_I2S_Tasks and DRV_I2S_TasksError will be called from the Interrupt Service Routine of the I2S. When a DMA channel is
used for transmission/reception DRV_I2S_Tasks and DRV_I2S_TasksError will be internally called by the driver from the DMA channel event
handler.
Client Access
This section provides information on general client operation.
Description
General Client Operation
For the application to start using an instance of the module, it must call the DRV_I2S_Open function. This provides the settings required to open
the I2S instance for operation. If the driver is deinitialized using the function DRV_I2S_Deinitialize, the application must call the DRV_I2S_Open
function again to set up the instance of the I2S.
For the various options available for IO_INTENT, please refer to Data Types and Constants in the Library Interface section.
Volume V: MPLAB Harmony Framework Driver Libraries Help I2S Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 555
Example:
DRV_HANDLE handle;
handle = DRV_I2S_Open(DRV_I2S_INDEX_0, (DRV_IO_INTENT_WRITE | DRV_IO_INTENT_NONBLOCKING));
if (DRV_HANDLE_INVALID == handle)
{
// Unable to open the driver
// May be the driver is not initialized or the initialization
// is not complete.
}
Client Operations - Buffered
This section provides information on buffered client operations.
Description
Client Operations - Buffered
Client buffered operations provide a the typical audio interface. The functions DRV_I2S_BufferAddRead, DRV_I2S_BufferAddWrite, and
DRV_I2S_BufferAddWriteRead are the buffered data operation functions. The buffered functions schedules non-blocking operations. The function
adds the request to the hardware instance queues and returns a buffer handle. The requesting client also registers a callback event with the driver.
The driver notifies the client with DRV_I2S_BUFFER_EVENT_COMPLETE, DRV_I2S_BUFFER_EVENT_ERROR or
DRV_I2S_BUFFER_EVENT_ABORT events.
The buffer add requests are processed under DRV_I2S_Tasks, DRV_I2S_TasksError functions. These functions are called from the I2S channel
ISR in interrupt mode or from SYS_Tasks routine in Polled mode. When a DMA channel is used for transmission/reception DRV_I2S_Tasks and
DRV_I2S_TasksError will be internally called by the driver from the DMA channel event handler.
The following diagram illustrates the buffered data operations
Volume V: MPLAB Harmony Framework Driver Libraries Help I2S Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 556
Note:
It is not necessary to close and reopen the client between multiple transfers.
An application using the buffered functionality needs to perform the following steps:
1. The system should have completed necessary setup and initializations.
2. If DMA mode is desired, the DMA should be initialized by calling SYS_DMA_Initialize.
3. The necessary ports setup and remapping must be done for I2S lines: ADCDAT, DACDAT, BCLK, LRCK and MCLK (if required).
4. The driver object should have been initialized by calling DRV_I2S_Initialize. If DMA mode is desired, related attributes in the init structure must
be set.
5. Open the driver using DRV_I2S_Open with the necessary ioIntent to get a client handle.
6. The necessary BCLK, LRCK, and MCLK should be set up so as to generate the required media bit rate.
7. The necessary Baud rate value should be set up by calling DRV_I2S_BaudrateSet.
8. The Register and event handler for the client handle should be set up by calling DRV_I2S_BufferEventHandlerSet.
9. Add a buffer to initiate the data transfer by calling DRV_I2S_BufferAddWrite/DRV_I2S_BufferAddRead/DRV_I2S_BufferAddWriteRead.
10. Based on polling or interrupt mode service the data processing should be set up by calling DRV_I2S_Tasks, DRV_I2S_TasksError from
system tasks or I2S ISR. When a DMA channel is used for transmission/reception system calls SYS_DMA_Tasks(), SYS_DMA_TasksError()
from the system tasks or DMA channel ISR, DRV_I2S_Tasks and DRV_I2S_TasksError will be internally called by the driver from the DMA
channel event handler.
11. Repeat step 9 through step 10 to handle multiple buffer transmission and reception.
Volume V: MPLAB Harmony Framework Driver Libraries Help I2S Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 557
12. When the client is done it can use DRV_I2S_Close to close the client handle.
Example 1:
// The following is an example for a Polled mode buffered transmit
#define SYS_I2S_DRIVER_INDEX DRV_I2S_1 // I2S Uses SPI Hardware
#define BUFFER_SIZE 1000
// I2S initialization structure.
// This should be populated with necessary settings.
// attributes dmaChannelTransmit/dmaChannelReceive
// and dmaInterruptTransmitSource/dmaInterruptReceiveSource
// must be set if DMA mode of operation is desired.
DRV_I2S_INIT i2sInit;
SYS_MODULE_OBJ sysObj; //I2S module object
DRV_HANDLE handle; //Client handle
uint32_t i2sClock; //BCLK frequency
uint32_t baudrate; //baudrate
uint16_t myAudioBuffer[BUFFER_SIZE]; //Audio buffer to be transmitted
DRV_I2S_BUFFER_HANDLE bufferHandle;
APP_DATA_S state; //Application specific state
uintptr_t contextHandle;
void SYS_Initialize ( void* data )
{
// The system should have completed necessary setup and initializations.
// Necessary ports setup and remapping must be done for I2S lines ADCDAT,
// DACDAT, BCLK, LRCK and MCLK
sysObj = DRV_I2S_Initialize(SYS_I2S_DRIVER_INDEX, (SYS_MODULE_INIT*)&i2sInit);
if (SYS_MODULE_OBJ_INVALID == sysObj)
{
// Handle error
}
}
void App_Task(void)
{
switch(state)
{
case APP_STATE_INIT:
{
handle = DRV_I2S_Open(SYS_I2S_DRIVER_INDEX, (DRV_IO_INTENT_WRITE |
DRV_IO_INTENT_NONBLOCKING));
if(handle != DRV_HANDLE_INVALID )
{
/* Update the state */
state = APP_STATE_WAIT_FOR_READY;
}
}
break;
case APP_STATE_WAIT_FOR_READY:
{
// Necessary clock settings must be done to generate
// required MCLK, BCLK and LRCK
DRV_I2S_BaudrateSet(handle, i2sClock, baudrate);
/* Set the Event handler */
DRV_I2S_BufferEventHandlerSet(handle,App_BufferEventHandler,
contextHandle);
/* Add a buffer to write*/
DRV_I2S_BufferAddWrite(handle, &bufferHandle
myAudioBuffer, BUFFER_SIZE);
if(DRV_I2S_BUFFER_HANDLE_INVALID == bufferHandle)
{
// Error handling here
Volume V: MPLAB Harmony Framework Driver Libraries Help I2S Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 558
}
state = APP_STATE_IDLE;
}
break;
case APP_STATE_WAIT_FOR_DONE:
state = APP_STATE_DONE;
break;
case APP_STATE_DONE:
// Close done
DRV_I2S_Close(handle);
break;
case APP_STATE_IDLE:
// Do nothing
break;
default:
break;
}
}
void App_BufferEventHandler(DRV_I2S_BUFFER_EVENT event,
DRV_I2S_BUFFER_HANDLE bufferHandle, uintptr_t contextHandle)
{
uint8_t temp;
if(DRV_I2S_BUFFER_EVENT_COMPLETE == event)
{
// Can set state = APP_STATE_WAIT_FOR_DONE;
// Take Action as needed
}
else if(DRV_I2S_BUFFER_EVENT_ERROR == event)
{
// Take Action as needed
}
else if(DRV_I2S_BUFFER_EVENT_ABORT == event)
{
// Take Action as needed
}
else
{
// Do nothing
}
}
void SYS_Tasks ( void )
{
DRV_I2S_Tasks((SYS_MODULE_OBJ)sysObj);
DRV_I2S_TasksError((SYS_MODULE_OBJ)sysObj);
/* Call the application's tasks routine */
APP_Tasks ( );
}
Example 2:
// The following is an example for interrupt mode buffered transmit
#define SYS_I2S_DRIVER_INDEX DRV_I2S_1 // I2S Uses SPI Hardware
#define BUFFER_SIZE 1000
// I2S initialization structure.
// This should be populated with necessary settings.
// attributes dmaChannelTransmit/dmaChannelReceive
// and dmaInterruptTransmitSource/dmaInterruptReceiveSource
// must be set if DMA mode of operation is desired.
Volume V: MPLAB Harmony Framework Driver Libraries Help I2S Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 559
DRV_I2S_INIT i2sInit;
SYS_MODULE_OBJ sysObj; //I2S module object
DRV_HANDLE handle; //Client handle
uint32_t i2sClock; //BCLK frequency
uint32_t baudrate; //baudrate
uint16_t myAudioBuffer[BUFFER_SIZE]; //Audio buffer to be transmitted
DRV_I2S_BUFFER_HANDLE bufferHandle;
APP_DATA_S state; //Application specific state
uintptr_t contextHandle;
void SYS_Initialize ( void* data )
{
// The system should have completed necessary setup and initializations.
// Necessary ports setup and remapping must be done for I2S lines ADCDAT,
// DACDAT, BCLK, LRCK and MCLK
sysObj = DRV_I2S_Initialize(SYS_I2S_DRIVER_INDEX, (SYS_MODULE_INIT*)&i2sInit);
if (SYS_MODULE_OBJ_INVALID == sysObj)
{
// Handle error
}
}
void App_Task(void)
{
switch(state)
{
case APP_STATE_INIT:
{
handle = DRV_I2S_Open(SYS_I2S_DRIVER_INDEX, (DRV_IO_INTENT_WRITE |
DRV_IO_INTENT_NONBLOCKING));
if(handle != DRV_HANDLE_INVALID )
{
/* Update the state */
state = APP_STATE_WAIT_FOR_READY;
}
}
break;
case APP_STATE_WAIT_FOR_READY:
{
// Necessary clock settings must be done to generate
// required MCLK, BCLK and LRCK
DRV_I2S_BaudrateSet(handle, i2sClock, baudrate);
/* Set the Event handler */
DRV_I2S_BufferEventHandlerSet(handle,App_BufferEventHandler,
contextHandle);
/* Add a buffer to write*/
DRV_I2S_BufferAddWrite(handle, &bufferHandle
myAudioBuffer, BUFFER_SIZE);
if(DRV_I2S_BUFFER_HANDLE_INVALID == bufferHandle)
{
// Error handling here
}
state = APP_STATE_IDLE;
}
break;
case APP_STATE_WAIT_FOR_DONE:
state = APP_STATE_DONE;
break;
case APP_STATE_DONE:
{
Volume V: MPLAB Harmony Framework Driver Libraries Help I2S Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 560
// Close done
DRV_I2S_Close(handle);
}
break;
case APP_STATE_IDLE:
// Do nothing
break;
default:
break;
}
}
void App_BufferEventHandler(DRV_I2S_BUFFER_EVENT event,
DRV_I2S_BUFFER_HANDLE bufferHandle, uintptr_t contextHandle)
{
uint8_t temp;
if(DRV_I2S_BUFFER_EVENT_COMPLETE == event)
{
// Can set state = APP_STATE_WAIT_FOR_DONE;
// Take Action as needed
}
else if(DRV_I2S_BUFFER_EVENT_ERROR == event)
{
// Take Action as needed
}
else if(DRV_I2S_BUFFER_EVENT_ABORT == event)
{
// Take Action as needed
}
else
{
// Do nothing
}
}
void SYS_Tasks ( void )
{
/* Call the application's tasks routine */
APP_Tasks ( );
}
void __ISR ( _SPI1_VECTOR ) _InterruptHandler_I2S1 ( void )
{
// Call the "tasks" functions for I2S module
DRV_I2S_Tasks((SYS_MODULE_OBJ)sysObj);
DRV_I2S_TasksError((SYS_MODULE_OBJ)sysObj);
}
// If DMA Channel 1 was setup during initialization instead of the previous I2S ISR, the following should
be implemented
void __ISR ( _DMA1_VECTOR ) _InterruptHandler_DMA_CHANNEL_1 ( void )
{
// Call the DMA system tasks which internally will call the I2S Tasks.
SYS_DMA_Tasks((SYS_MODULE_OBJ)sysObj);
SYS_DMA_TasksError((SYS_MODULE_OBJ)sysObj);
}
Client Operations - Non-buffered
This section provides information on non-buffered client operations.
Volume V: MPLAB Harmony Framework Driver Libraries Help I2S Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 561
Description
Client Operations - Non-buffered
Client non-buffered operations provide a basic interface for the driver operation. This interface could be used by applications which have do not
have buffered data transfer requirements. The functions DRV_I2S_Read and DRV_I2S_Write are the non-buffered data operation functions. The
non-buffered functions are blocking/non-blocking depending upon the mode (ioIntent) the client was opened. If the client was opened for blocking
mode these functions will only return when (or will block until) the specified data operation is completed or if an error occurred. If the client was
opened for non-blocking mode, these functions will return with the number of bytes that were actually accepted for operation. The function will not
wait until the data operation has completed.
Note:
Non-buffered functions do not support interrupt/DMA mode.
The following diagram illustrates the non-buffered data operations
Note:
It is not necessary to close and reopen the client between multiple transfers.
An application using the non-buffered functionality needs to perform the following steps:
1. The system should have completed necessary setup and initializations.
2. The necessary ports setup and remapping must be done for I2S lines: ADCDAT, DACDAT, BCLK, LRCK and MCLK (if required).
3. The driver object should have been initialized by calling DRV_I2S_Initialize.
4. Open the driver using DRV_I2S_Open with the necessary ioIntent to get a client handle.
5. The necessary BCLK, LRCK, and MCLK should be set up so as to generate the required media bit rate.
6. The necessary Baud rate value should be set up by calling DRV_I2S_BaudrateSet.
7. The Transmit/Receive data should be set up by calling DRV_I2S_Write/DRV_I2S_Read.
8. Repeat step 5 through step 7 to handle multiple buffer transmission and reception.
Volume V: MPLAB Harmony Framework Driver Libraries Help I2S Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 562
9. When the client is done it can use DRV_I2S_Close to close the client handle.
Example 1:
// The following is an example for a blocking transmit
#define SYS_I2S_DRIVER_INDEX DRV_I2S_1 // I2S Uses SPI Hardware
#define BUFFER_SIZE 1000
DRV_I2S_INIT i2sInit; //I2S initialization structure
//This should be populated with necessary settings
SYS_MODULE_OBJ sysObj; //I2S module object
APP_DATA_S state; //Application specific state
DRV_HANDLE handle; //Client handle
uint32_t i2sClock; //BCLK frequency
uint32_t baudrate; //baudrate
uint16_t myAudioBuffer[BUFFER_SIZE]; //Audio buffer to be transmitted
uint32_t count;
// The system should have completed necessary setup and initializations.
// Necessary ports setup and remapping must be done for
// I2S lines ADCDAT, DACDAT, BCLK, LRCK and MCLK
sysObj = DRV_I2S_Initialize(SYS_I2S_DRIVER_INDEX, (SYS_MODULE_INIT*)&i2sInit);
if (SYS_MODULE_OBJ_INVALID == sysObj)
{
// Handle error
}
while(1)
{
switch(state)
{
case APP_STATE_INIT:
{
handle = DRV_I2S_Open(SYS_I2S_DRIVER_INDEX, (DRV_IO_INTENT_WRITE | DRV_IO_INTENT_BLOCKING));
if(handle != DRV_HANDLE_INVALID )
{
/* Update the state */
state = APP_STATE_WAIT_FOR_READY;
}
}
break;
case APP_STATE_WAIT_FOR_READY:
{
// Necessary clock settings must be done to generate
// required MCLK, BCLK and LRCK
DRV_I2S_BaudrateSet(handle, i2sClock, baudrate);
// Blocks here and transfer the buffer
count = DRV_I2S_Write(handle, &myAudioBuffer,BUFFER_SIZE);
if(count == DRV_I2S_WRITE_ERROR)
{
//Handle Error
} else
{
// Transfer Done
state = APP_STATE_DONE;
}
}
break;
case APP_STATE_DONE:
{
// Close done
DRV_I2S_Close(handle);
}
break;
default:
break;
}
}
Volume V: MPLAB Harmony Framework Driver Libraries Help I2S Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 563
Example 2:
// Following is an example for a non blocking transmit
#define SYS_I2S_DRIVER_INDEX DRV_I2S_1 //I2S Uses SPI Hardware
#define BUFFER_SIZE 1000
DRV_I2S_INIT i2sInit; //I2S initialization structure.
// This should be populated with necessary settings
SYS_MODULE_OBJ sysObj; //I2S module object
APP_DATA_S state; //Application specific state
DRV_HANDLE handle; //Client handle
uint32_t i2sClock; //BCLK frequency
uint32_t baudrate; //baudrate
uint16_t myAudioBuffer[BUFFER_SIZE]; //Audio buffer to be transmitted
uint32_t count,total,size;
total = 0;
size = BUFFER_SIZE;
// The system should have completed necessary setup and initializations.
// Necessary ports setup and remapping must be done for I2S lines ADCDAT,
// DACDAT, BCLK, LRCK and MCLK
sysObj = DRV_I2S_Initialize(SYS_I2S_DRIVER_INDEX, (SYS_MODULE_INIT*)&i2sInit);
if (SYS_MODULE_OBJ_INVALID == sysObj)
{
// Handle error
}
while(1)
{
switch(state)
{
case APP_STATE_INIT:
{
handle = DRV_I2S_Open(SYS_I2S_DRIVER_INDEX, (DRV_IO_INTENT_WRITE |
DRV_IO_INTENT_NONBLOCKING));
if(handle != DRV_HANDLE_INVALID )
{
/* Update the state */
state = APP_STATE_WAIT_FOR_READY;
}
}
break;
case APP_STATE_WAIT_FOR_READY:
{
// Necessary clock settings must be done to generate
// required MCLK, BCLK and LRCK
DRV_I2S_BaudrateSet(handle, i2sClock, baudrate);
// Transfer whatever possible number of bytes
count = DRV_I2S_Write(handle, &myAudioBuffer,size);
if(count == DRV_I2S_WRITE_ERROR)
{
//Handle Error
} else
{
// 'count' bytes transferred
state = APP_STATE_WAIT_FOR_DONE;
}
}
break;
case APP_STATE_WAIT_FOR_DONE:
// Can perform other Application tasks here
// .........................
// .........................
// .........................
size = size - count;
if(size!=0)
{
Volume V: MPLAB Harmony Framework Driver Libraries Help I2S Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 564
// Change the state so as to submit
// another possible transmission
state = APP_STATE_WAIT_FOR_READY;
}
else
{
// We are done
state = APP_STATE_DONE;
}
break;
case APP_STATE_DONE:
{
if(DRV_I2S_CLOSE_FAILURE == DRV_I2S_Close(handle))
{
// Handle error
}
else
{
// Close done
}
}
break;
default:
break;
}
}
Configuring the Library
Client Configuration
Name Description
DRV_I2S_CLIENTS_NUMBER Sets up the maximum number of clients that can be connected to any hardware instance.
DRV_I2S_QUEUE_DEPTH_COMBINED Number of entries of all queues in all instances of the driver.
System Configuration
Name Description
DRV_I2S_INDEX I2S Static Index selection
DRV_I2S_INSTANCES_NUMBER Sets up the maximum number of hardware instances that can be supported
DRV_I2S_INTERRUPT_MODE Macro controls interrupt based operation of the driver
DRV_I2S_INTERRUPT_SOURCE_ERROR Defines the interrupt source for the error interrupt
DRV_I2S_INTERRUPT_SOURCE_RECEIVE Macro to define the Receive interrupt source in case of static driver
DRV_I2S_INTERRUPT_SOURCE_TRANSMIT Macro to define the Transmit interrupt source in case of static driver
DRV_I2S_PERIPHERAL_ID Configures the I2S PLIB Module ID
DRV_I2S_RECEIVE_DMA_CHANNEL Macro to defines the I2S Driver Receive DMA Channel in case of static driver
DRV_I2S_STOP_IN_IDLE Identifies whether the driver should stop operations in stop in Idle mode.
DRV_I2S_TRANSMIT_DMA_CHANNEL Macro to defines the I2S Driver Transmit DMA Channel in case of static driver
DRV_I2S_RECEIVE_DMA_CHAINING_CHANNEL Macro to defines the I2S Driver Receive DMA Chaining Channel in case of
static driver
Description
The configuration of the I2S Driver Library is based on the file sys_config.h.
This header file contains the configuration selection for the I2S Driver Library. Based on the selections made, the I2S Driver Library may support
the selected features. These configuration settings will apply to all instances of the I2S Driver Library.
This header can be placed anywhere; however, the path of this header needs to be present in the include search path for a successful build. Refer
to the Applications Help section for more details.
System Configuration
Volume V: MPLAB Harmony Framework Driver Libraries Help I2S Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 565
DRV_I2S_INDEX Macro
I2S Static Index selection
File
drv_i2s_config_template.h
C
#define DRV_I2S_INDEX
Description
Index - Used for static drivers
I2S Static Index selection for the driver object reference. This macro defines the driver index in case of static and static multi-client build. For
example, if this macro is set to DRV_I2S_INDEX_2, then static driver APIs would be DRV_I2S2_Initialize(), DRV_I2S2_Open() etc. When building
static drivers, this macro should be different for each static build of the I2S driver that needs to be included in the project.
Remarks
This index is required to make a reference to the driver object
DRV_I2S_INSTANCES_NUMBER Macro
Sets up the maximum number of hardware instances that can be supported
File
drv_i2s_config_template.h
C
#define DRV_I2S_INSTANCES_NUMBER
Description
I2S driver objects configuration
Sets up the maximum number of hardware instances that can be supported. It is recommended that this number be set exactly equal to the
number of I2S modules that are needed by the application. Hardware Instance support consumes RAM memory space. If this macro is not
defined, then the driver will be built statically.
Remarks
None
DRV_I2S_INTERRUPT_MODE Macro
Macro controls interrupt based operation of the driver
File
drv_i2s_config_template.h
C
#define DRV_I2S_INTERRUPT_MODE
Description
I2S Interrupt Mode Operation Control
This macro controls the interrupt based operation of the driver. The possible values it can take are
• true - Enables the interrupt mode
• false - Enables the polling mode
If the macro value is true, then Interrupt Service Routine for the interrupt should be defined in the application. The DRV_I2S_Tasks() routine
should be called in the ISR.
DRV_I2S_INTERRUPT_SOURCE_ERROR Macro
Defines the interrupt source for the error interrupt
Volume V: MPLAB Harmony Framework Driver Libraries Help I2S Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 566
File
drv_i2s_config_template.h
C
#define DRV_I2S_INTERRUPT_SOURCE_ERROR
Description
Error Interrupt Source
Macro to define the Error interrupt source in case of static driver. The interrupt source defined by this macro will override the errorInterruptSource
member of the DRV_I2S_INIT initialization data structure in the driver initialization routine. This value should be set to the I2S module error
interrupt enumeration in the Interrupt PLIB for the microcontroller.
DRV_I2S_INTERRUPT_SOURCE_RECEIVE Macro
Macro to define the Receive interrupt source in case of static driver
File
drv_i2s_config_template.h
C
#define DRV_I2S_INTERRUPT_SOURCE_RECEIVE
Description
Receive Interrupt Source
Macro to define the Receive interrupt source in case of static driver. The interrupt source defined by this macro will override the rxInterruptSource
member of the DRV_I2S_INIT initialization data structure in the driver initialization routine. This value should be set to the I2S module receive
interrupt enumeration in the Interrupt PLIB for the microcontroller.
Remarks
None.
DRV_I2S_INTERRUPT_SOURCE_TRANSMIT Macro
Macro to define the Transmit interrupt source in case of static driver
File
drv_i2s_config_template.h
C
#define DRV_I2S_INTERRUPT_SOURCE_TRANSMIT
Description
Transmit Interrupt Source
Macro to define the TX interrupt source in case of static driver. The interrupt source defined by this macro will override the txInterruptSource
member of the DRV_I2S_INIT initialization data structure in the driver initialization routine. This value should be set to the I2S module transmit
interrupt enumeration in the Interrupt PLIB for the microcontroller.
Remarks
None.
DRV_I2S_PERIPHERAL_ID Macro
Configures the I2S PLIB Module ID
File
drv_i2s_config_template.h
C
#define DRV_I2S_PERIPHERAL_ID
Volume V: MPLAB Harmony Framework Driver Libraries Help I2S Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 567
Description
I2S Peripheral Library Module ID
This macro configures the PLIB ID if the driver is built statically. This value will override the I2SID member of the DRV_I2S_INIT initialization data
structure. In that when the driver is built statically, the I2SID member of the DRV_I2S_INIT data structure will be ignored by the driver initialization
routine and this macro will be considered. This should be set to the PLIB ID of I2S module (I2S_ID_1, I2S_ID_2 and so on).
DRV_I2S_RECEIVE_DMA_CHANNEL Macro
Macro to defines the I2S Driver Receive DMA Channel in case of static driver
File
drv_i2s_config_template.h
C
#define DRV_I2S_RECEIVE_DMA_CHANNEL
Description
I2S Driver Receive DMA Channel
Macro to define the I2S Receive DMA Channel in case of static driver. The DMA channel defined by this macro will override the
dmaChannelReceive member of the DRV_I2S_INIT initialization data structure in the driver initialization routine. This value should be set to the
DMA channel in the DMA PLIB for the microcontroller.
Remarks
None.
DRV_I2S_STOP_IN_IDLE Macro
Identifies whether the driver should stop operations in stop in Idle mode.
File
drv_i2s_config_template.h
C
#define DRV_I2S_STOP_IN_IDLE
Description
I2S driver objects configuration
Identifies whether the driver should stop operations in stop in Idle mode. true - Indicates stop in idle mode. false - Indicates do not stop in Idle
mode.
Remarks
None
DRV_I2S_TRANSMIT_DMA_CHANNEL Macro
Macro to defines the I2S Driver Transmit DMA Channel in case of static driver
File
drv_i2s_config_template.h
C
#define DRV_I2S_TRANSMIT_DMA_CHANNEL
Description
I2S Driver Transmit DMA Channel
Macro to define the I2S Transmit DMA Channel in case of static driver. The DMA channel defined by this macro will override the
dmaChannelTransmit member of the DRV_I2S_INIT initialization data structure in the driver initialization routine. This value should be set to the
DMA channel in the DMA PLIB for the microcontroller.
Remarks
None.
Volume V: MPLAB Harmony Framework Driver Libraries Help I2S Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 568
DRV_I2S_RECEIVE_DMA_CHAINING_CHANNEL Macro
Macro to defines the I2S Driver Receive DMA Chaining Channel in case of static driver
File
drv_i2s_config_template.h
C
#define DRV_I2S_RECEIVE_DMA_CHAINING_CHANNEL
Description
I2S Driver Receive DMA Chaining Channel
Macro to define the I2S Receive DMA Chaining Channel in case of static driver. The DMA channel defined by this macro will override the
dmaChaningChannelReceive member of the DRV_I2S_INIT initialization data structure in the driver initialization routine. This value should be set
to the DMA channel in the DMA PLIB for the microcontroller.
Remarks
None.
Client Configuration
DRV_I2S_CLIENTS_NUMBER Macro
Sets up the maximum number of clients that can be connected to any hardware instance.
File
drv_i2s_config_template.h
C
#define DRV_I2S_CLIENTS_NUMBER
Description
I2S Client Count Configuration
Sets up the maximum number of clients that can be connected to any hardware instance. This value represents the total number of clients to be
supported across all hardware instances. So if I2S1 will be accessed by 2 clients and I2S2 will accessed by 3 clients, then this number should be
5. It is recommended that this be set exactly equal to the number of expected clients. Client support consumes RAM memory space. If this macro
is not defined and the DRV_I2S_INSTANCES_NUMBER macro is not defined, then the driver will be built for static - single client operation. If this
macro is defined and the DRV_I2S_INSTANCES_NUMBER macro is not defined, then the driver will be built for static - multi client operation.
Remarks
None
DRV_I2S_QUEUE_DEPTH_COMBINED Macro
Number of entries of all queues in all instances of the driver.
File
drv_i2s_config_template.h
C
#define DRV_I2S_QUEUE_DEPTH_COMBINED
Description
I2S Driver Buffer Queue Entries
This macro defined the number of entries of all queues in all instances of the driver.
Each hardware instance supports a buffer queue for transmit and receive operations. The size of queue is specified either in driver initialization (for
dynamic build) or by macros (for static build). The hardware instance transmit buffer queue will queue transmit buffers submitted by the
DRV_I2S_BufferAddWrite() function. The hardware instance receive buffer queue will queue receive buffers submitted by the
DRV_I2S_BufferAddRead() function.
A buffer queue will contains buffer queue entries, each related to a BufferAdd request. This configuration macro defines total number of buffer
Volume V: MPLAB Harmony Framework Driver Libraries Help I2S Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 569
entries that will be available for use between all I2S driver hardware instances. The buffer queue entries are allocated to individual hardware
instances as requested by hardware instances. Once the request is processed, the buffer queue entry is free for use by other hardware instances.
The total number of buffer entries in the system determines the ability of the driver to service non blocking read and write requests. If a free buffer
entry is not available, the driver will not add the request and will return an invalid buffer handle. More the number of buffer entries, greater the
ability of the driver to service and add requests to its queue. A hardware instance additionally can queue up as many buffer entries as specified by
its transmit and receive buffer queue size.
As an example, consider the case of static single client driver application where full duplex non blocking operation is desired without queuing, the
minimum transmit queue depth and minimum receive queue depth should be 1. Hence the total number of buffer entries should be 2.
As an example, consider the case of a dynamic driver (say 2 instances) where instance 1 will queue up to 3 write requests and up to 2 read
requests, and instance 2 will queue up to 2 write requests and up to 6 read requests, the value of this macro should be 13 (2 + 3 + 2 + 6).
Remarks
The maximum combined queue depth should not be greater than 0xFFFF(ie 65535)
Building the Library
This section lists the files that are available in the I2S Driver Library.
Description
The following three tables list and describe the header (.h) and source (.c) files that implement this library. The parent folder for these files is
/framework/driver/i2s.
Interface File(s)
This table lists and describes the header files that must be included (i.e., using #include) by any code that uses this library.
Source File Name Description
/drv_i2s.h This file provides the interface definitions of the I2S driver.
Required File(s)
All of the required files listed in the following table are automatically added into the MPLAB X IDE project by the MHC
when the library is selected for use.
This table lists and describes the source and header files that must always be included in the MPLAB X IDE project to build this library.
Source File Name Description
/src/dynamic/drv_i2s_dma.c This file contains the core implementation of the I2S driver with DMA support.
Optional File(s)
This table lists and describes the source and header files that may optionally be included if required for the desired implementation.
Source File Name Description
/src/dynamic/drv_i2s_dma_advanced.c This file contains the implementation of the I2S driver with DMA support using the channel
chaining feature.
/src/dynamic/drv_i2s.c This file contains the implementation of the I2S driver without DMA support.
/src/dynamic/drv_i2s_read_write.c This file contains the basic read/write implementation of the I2S driver.
Module Dependencies
The I2S Driver Library depends on the following modules:
• SPI Peripheral Library
• DMA Peripheral Library
Library Interface
a) System Interaction Functions
Name Description
DRV_I2S_Deinitialize Deinitializes the specified instance of the I2S driver module.
Implementation: Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help I2S Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 570
DRV_I2S_Initialize Initializes hardware and data for the instance of the I2S module.
Implementation: Dynamic
DRV_I2S_Status Gets the current status of the I2S driver module.
Implementation: Dynamic
DRV_I2S_Tasks Maintains the driver's receive state machine and implements its ISR.
Implementation: Dynamic
DRV_I2S_TasksError Maintains the driver's error state machine and implements its ISR.
Implementation: Dynamic
b) Client Setup Functions
Name Description
DRV_I2S_Close Closes an opened-instance of the I2S driver.
Implementation: Dynamic
DRV_I2S_Open Opens the specified I2S driver instance and returns a handle to it.
Implementation: Dynamic
c) Data Transfer Functions
Name Description
DRV_I2S_BufferAddRead Schedule a non-blocking driver read operation.
Implementation: Dynamic
DRV_I2S_BufferAddWrite Schedule a non-blocking driver write operation.
Implementation: Dynamic
DRV_I2S_BufferAddWriteRead Schedule a non-blocking driver write-read operation.
Implementation: Dynamic
DRV_I2S_BufferEventHandlerSet This function allows a client to identify a buffer event handling function for the driver to
call back when queued buffer transfers have finished.
Implementation: Dynamic
DRV_I2S_BufferCombinedQueueSizeGet This function returns the number of bytes queued (to be processed) in the buffer queue.
Implementation: Dynamic
DRV_I2S_BufferQueueFlush This function flushes off the buffers associated with the client object.
Implementation: Dynamic
DRV_I2S_Read Reads data from the I2S.
Implementation: Dynamic
DRV_I2S_Write Writes data to the I2S.
Implementation: Dynamic
DRV_I2S_BufferProcessedSizeGet This function returns number of bytes that have been processed for the specified buffer.
Implementation: Dynamic
d) Miscellaneous Functions
Name Description
DRV_I2S_BaudSet This function sets the baud.
Implementation: Dynamic
DRV_I2S_ErrorGet This function returns the error(if any) associated with the last client request.
Implementation: Dynamic
DRV_I2S_ReceiveErrorIgnore This function enable/disable ignoring of the receive overflow error.
Implementation: Dynamic
DRV_I2S_TransmitErrorIgnore This function enable/disable ignoring of the transmit underrun error.
Implementation: Dynamic
e) Data Types and Constants
Name Description
DRV_I2S_AUDIO_PROTOCOL_MODE Identifies the Audio Protocol Mode of the I2S module.
DRV_I2S_BUFFER_EVENT Identifies the possible events that can result from a buffer add request.
DRV_I2S_BUFFER_EVENT_HANDLER Pointer to a I2S Driver Buffer Event handler function
DRV_I2S_BUFFER_HANDLE Handle identifying a read or write buffer passed to the driver.
DRV_I2S_CLOCK_MODE Identifies the various clock modes of the I2S module.
DRV_I2S_DATA16 Defines the left and right channel data for 16-bit audio data
DRV_I2S_DATA24 Defines the left and right channel data for 24-bit audio data
Volume V: MPLAB Harmony Framework Driver Libraries Help I2S Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 571
DRV_I2S_DATA32 Defines the left and right channel data for 32-bit audio data
DRV_I2S_ERROR Defines the possible errors that can occur during driver operation.
DRV_I2S_MODE Identifies the usage modes of the I2S module.
DRV_I2S_BUFFER_HANDLE_INVALID Definition of an invalid buffer handle.
DRV_I2S_COUNT Number of valid I2S driver indices
DRV_I2S_READ_ERROR I2S Driver Read Error.
DRV_I2S_WRITE_ERROR I2S Driver Write Error.
DRV_I2S_INDEX_0 I2S driver index definitions
DRV_I2S_INDEX_1 This is macro DRV_I2S_INDEX_1.
DRV_I2S_INDEX_2 This is macro DRV_I2S_INDEX_2.
DRV_I2S_INDEX_3 This is macro DRV_I2S_INDEX_3.
DRV_I2S_INDEX_4 This is macro DRV_I2S_INDEX_4.
DRV_I2S_INDEX_5 This is macro DRV_I2S_INDEX_5.
DRV_I2S_INTERFACE This structure defines a structure of I2S Driver function pointers.
Description
This section describes the Application Programming Interface (API) functions of the I2S Driver Library.
Refer to each section for a detailed description.
a) System Interaction Functions
DRV_I2S_Deinitialize Function
Deinitializes the specified instance of the I2S driver module.
Implementation: Dynamic
File
drv_i2s.h
C
void DRV_I2S_Deinitialize(SYS_MODULE_OBJ object);
Returns
None.
Description
Deinitializes the specified instance of the I2S driver module, disabling its operation (and any hardware). Invalidates all the internal data.
Remarks
Once the Initialize operation has been called, the Deinitialize operation must be called before the Initialize operation can be called again. This
routine will NEVER block waiting for hardware.
Preconditions
Function DRV_I2S_Initialize should have been called before calling this function.
Example
SYS_MODULE_OBJ object; // Returned from DRV_I2S_Initialize
SYS_STATUS status;
DRV_I2S_Deinitialize(object);
status = DRV_I2S_Status(object);
if (SYS_MODULE_DEINITIALIZED != status)
{
// Check again later if you need to know
// when the driver is deinitialized.
}
Volume V: MPLAB Harmony Framework Driver Libraries Help I2S Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 572
Parameters
Parameters Description
object Driver object handle, returned from the DRV_I2S_Initialize routine
Function
void DRV_I2S_Deinitialize( SYS_MODULE_OBJ object )
DRV_I2S_Initialize Function
Initializes hardware and data for the instance of the I2S module.
Implementation: Dynamic
File
drv_i2s.h
C
SYS_MODULE_OBJ DRV_I2S_Initialize(const SYS_MODULE_INDEX drvIndex, const SYS_MODULE_INIT *const init);
Returns
If successful, returns a valid handle to a driver instance object. Otherwise, it returns SYS_MODULE_OBJ_INVALID.
Description
This routine initializes the I2S driver instance for the specified driver index, making it ready for clients to open and use it. The initialization data is
specified by the init parameter. The initialization may fail if the number of driver objects allocated are insufficient or if the specified driver instance is
already initialized. The driver instance index is independent of the I2S module ID. For example, driver instance 0 can be assigned to I2S2. If the
driver is built statically, then some of the initialization parameters are overridden by configuration macros. Refer to the description of the
DRV_I2S_INIT data structure for more details on which members on this data structure are overridden.
Remarks
This routine must be called before any other I2S routine is called.
This routine should only be called once during system initialization unless DRV_I2S_Deinitialize is called to deinitialize the driver instance. This
routine will NEVER block for hardware access.
To Enable the DMA mode of operation the init parameters 'dmaChannelTransmit' /'dmaChannelReceive' must be set to valid DMA channel. When
DMA mode of operation is enabled, the normal mode(Usual TX and RX) operation is inhibited. When 'dmaChannelTransmit'/'dmaChannelReceive'
are set to valid channel numbers the related DMA interrupt source parameters 'dmaInterruptTransmitSource'/ 'dmaInterruptReceiveSource' must
be set with appropriate DMA channel interrupt source.
Preconditions
If DMA mode of operation is intended, SYS_DMA_Initialize should have been called before calling this function.
Example
DRV_I2S_INIT init;
SYS_MODULE_OBJ objectHandle;
init.moduleInit.value = SYS_MODULE_POWER_RUN_FULL;
init.spiID = SPI_ID_1;
init.usageMode = DRV_I2S_MODE_MASTER;
init.baudClock = SPI_BAUD_RATE_MCLK_CLOCK;
init.baud = 48000;
init.clockMode = DRV_I2S_CLOCK_MODE_IDLE_HIGH_EDGE_FALL;
init.audioCommWidth = SPI_AUDIO_COMMUNICATION_24DATA_32FIFO_32CHANNEL;
init.audioTransmitMode = SPI_AUDIO_TRANSMIT_STEREO;
init.inputSamplePhase = SPI_INPUT_SAMPLING_PHASE_IN_MIDDLE;
init.protocolMode = DRV_I2S_AUDIO_I2S;
init.txInterruptSource = INT_SOURCE_SPI_1_TRANSMIT;
init.rxInterruptSource = INT_SOURCE_SPI_1_RECEIVE;
init.errorInterruptSource = INT_SOURCE_SPI_1_ERROR;
init.queueSizeTransmit = 3;
init.queueSizeReceive = 2;
init.dmaChannelTransmit = DMA_CHANNEL_NONE;
init.dmaChannelReceive = DMA_CHANNEL_NONE;
objectHandle = DRV_I2S_Initialize(DRV_I2S_INDEX_1, (SYS_MODULE_INIT*)init);
Volume V: MPLAB Harmony Framework Driver Libraries Help I2S Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 573
if (SYS_MODULE_OBJ_INVALID == objectHandle)
{
// Handle error
}
Parameters
Parameters Description
drvIndex Identifier for the driver instance to be initialized
init Pointer to the data structure containing any data necessary to initialize the hardware. This
pointer may be null if no data is required and default initialization is to be used.
Function
SYS_MODULE_OBJ DRV_I2S_Initialize
(
const SYS_MODULE_INDEX drvIndex,
const SYS_MODULE_INIT *const init
);
DRV_I2S_Status Function
Gets the current status of the I2S driver module.
Implementation: Dynamic
File
drv_i2s.h
C
SYS_STATUS DRV_I2S_Status(SYS_MODULE_OBJ object);
Returns
SYS_STATUS_DEINITIALIZED - Indicates that the driver has been deinitialized
SYS_STATUS_READY - Indicates that any previous module operation for the specified module has completed
SYS_STATUS_BUSY - Indicates that a previous module operation for the specified module has not yet completed
SYS_STATUS_ERROR - Indicates that the specified module is in an error state
Description
This routine provides the current status of the I2S driver module.
Remarks
A driver can opened only when its status is SYS_STATUS_READY.
Preconditions
Function DRV_I2S_Initialize should have been called before calling this function.
Example
SYS_MODULE_OBJ object; // Returned from DRV_I2S_Initialize
SYS_STATUS i2sStatus;
i2sStatus = DRV_I2S_Status(object);
if (SYS_STATUS_READY == i2sStatus)
{
// This means the driver can be opened using the
// DRV_I2S_Open() function.
}
Parameters
Parameters Description
object Driver object handle, returned from the DRV_I2S_Initialize routine
Function
SYS_STATUS DRV_I2S_Status( SYS_MODULE_OBJ object )
Volume V: MPLAB Harmony Framework Driver Libraries Help I2S Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 574
DRV_I2S_Tasks Function
Maintains the driver's receive state machine and implements its ISR.
Implementation: Dynamic
File
drv_i2s.h
C
void DRV_I2S_Tasks(SYS_MODULE_OBJ object);
Returns
None.
Description
This routine is used to maintain the driver's internal receive state machine and implement its transmit and receive ISR for interrupt-driven
implementations. In polling mode, this function should be called from the SYS_Tasks function. In interrupt mode, this function should be called
from the interrupt service routine of the I2S that is associated with this I2S driver hardware instance.
In DMA mode of operation, this function should be called from the interrupt service routine of the channel associated with the
transmission/reception of the I2s driver hardware instance.
Remarks
This routine is normally not called directly by an application. It is called by the system's Tasks routine (SYS_Tasks) or by the appropriate raw ISR.
This routine may execute in an ISR context and will never block or access any resources that may cause it to block.
Preconditions
The DRV_I2S_Initialize routine must have been called for the specified I2S driver instance.
Example
SYS_MODULE_OBJ object; // Returned from DRV_I2S_Initialize
while (true)
{
DRV_I2S_Tasks (object);
// Do other tasks
}
Parameters
Parameters Description
object Object handle for the specified driver instance (returned from DRV_I2S_Initialize)
Function
void DRV_I2S_Tasks(SYS_MODULE_OBJ object )
DRV_I2S_TasksError Function
Maintains the driver's error state machine and implements its ISR.
Implementation: Dynamic
File
drv_i2s.h
C
void DRV_I2S_TasksError(SYS_MODULE_OBJ object);
Returns
None.
Description
This routine is used to maintain the driver's internal error state machine and implement its error ISR for interrupt-driven implementations. In polling
Volume V: MPLAB Harmony Framework Driver Libraries Help I2S Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 575
mode, this function should be called from the SYS_Tasks() function. In interrupt mode, this function should be called in the error interrupt service
routine of the I2S that is associated with this I2S driver hardware instance.
In DMA mode of operation, this function should be called from the interrupt service routine of the channel associated with the
transmission/reception of the I2s driver hardware instance.
Remarks
This routine is normally not called directly by an application. It is called by the system's Tasks routine (SYS_Tasks) or by the appropriate raw ISR.
This routine may execute in an ISR context and will never block or access any resources that may cause it to block.
Preconditions
The DRV_I2S_Initialize routine must have been called for the specified I2S driver instance.
Example
SYS_MODULE_OBJ object; // Returned from DRV_I2S_Initialize
while (true)
{
DRV_I2S_TasksError (object);
// Do other tasks
}
Parameters
Parameters Description
object Object handle for the specified driver instance (returned from DRV_I2S_Initialize)
Function
void DRV_I2S_TasksError (SYS_MODULE_OBJ object )
b) Client Setup Functions
DRV_I2S_Close Function
Closes an opened-instance of the I2S driver.
Implementation: Dynamic
File
drv_i2s.h
C
void DRV_I2S_Close(const DRV_HANDLE handle);
Returns
• None
Description
This routine closes an opened-instance of the I2S driver, invalidating the handle. Any buffers in the driver queue that were submitted by this client
will be removed. After calling this routine, the handle passed in "handle" must not be used with any of the remaining driver routines. A new handle
must be obtained by calling DRV_I2S_Open before the caller may use the driver again
Remarks
Usually there is no need for the driver client to verify that the Close operation has completed. The driver will abort any ongoing operations when
this routine is called.
Preconditions
The DRV_I2S_Initialize routine must have been called for the specified I2S driver instance.
DRV_I2S_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE handle; // Returned from DRV_I2S_Open
Volume V: MPLAB Harmony Framework Driver Libraries Help I2S Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 576
DRV_I2S_Close(handle);
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
void DRV_I2S_Close( DRV_Handle handle )
DRV_I2S_Open Function
Opens the specified I2S driver instance and returns a handle to it.
Implementation: Dynamic
File
drv_i2s.h
C
DRV_HANDLE DRV_I2S_Open(const SYS_MODULE_INDEX iDriver, const DRV_IO_INTENT ioIntent);
Returns
If successful, the routine returns a valid open-instance handle (a number identifying both the caller and the module instance).
If an error occurs, the return value is DRV_HANDLE_INVALID. Error can occur
• if the number of client objects allocated via DRV_I2S_CLIENTS_NUMBER is
insufficient.
• if the client is trying to open the driver but driver has been opened
exclusively by another client.
• if the driver hardware instance being opened is not initialized or is
invalid.
Description
This routine opens the specified I2S driver instance and provides a handle that must be provided to all other client-level operations to identify the
caller and the instance of the driver. The ioIntent parameter defines how the client interacts with this driver instance.
The DRV_IO_INTENT_BLOCKING and DRV_IO_INTENT_NONBLOCKING ioIntent options additionally affect the behavior of the
DRV_I2S_Read() and DRV_I2S_Write() functions. If the ioIntent is DRV_IO_INTENT_NONBLOCKING, then these function will not block even if
the required amount of data could not be processed. If the ioIntent is DRV_IO_INTENT_BLOCKING, these functions will block until the required
amount of data is processed.
If ioIntent is DRV_IO_INTENT_READ, the client will only be read from the driver. If ioIntent is DRV_IO_INTENT_WRITE, the client will only be able
to write to the driver. If the ioIntent in DRV_IO_INTENT_READWRITE, the client will be able to do both, read and write.
Specifying a DRV_IO_INTENT_EXCLUSIVE will cause the driver to provide exclusive access to this client. The driver cannot be opened by any
other client.
Remarks
The handle returned is valid until the DRV_I2S_Close routine is called. This routine will NEVER block waiting for hardware.If the requested intent
flags are not supported, the routine will return DRV_HANDLE_INVALID. This function is thread safe in a RTOS application. It should not be called
in an ISR.
Preconditions
Function DRV_I2S_Initialize must have been called before calling this function.
Example
DRV_HANDLE handle;
handle = DRV_I2S_Open(DRV_I2S_INDEX_0, DRV_IO_INTENT_EXCLUSIVE);
if (DRV_HANDLE_INVALID == handle)
{
// Unable to open the driver
// May be the driver is not initialized or the initialization
// is not complete.
}
Volume V: MPLAB Harmony Framework Driver Libraries Help I2S Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 577
Parameters
Parameters Description
drvIndex Identifier for the object instance to be opened
ioIntent Zero or more of the values from the enumeration DRV_IO_INTENT "ORed" together to
indicate the intended use of the driver. See function description for details.
Function
DRV_HANDLE DRV_I2S_Open
(
const SYS_MODULE_INDEX drvIndex,
const DRV_IO_INTENT ioIntent
)
c) Data Transfer Functions
DRV_I2S_BufferAddRead Function
Schedule a non-blocking driver read operation.
Implementation: Dynamic
File
drv_i2s.h
C
void DRV_I2S_BufferAddRead(const DRV_HANDLE handle, DRV_I2S_BUFFER_HANDLE * bufferHandle, void * buffer,
size_t size);
Returns
The bufferHandle parameter will contain the return buffer handle. This will be DRV_I2S_BUFFER_HANDLE_INVALID if the function was not
successful.
Description
This function schedules a non-blocking read operation. The function returns with a valid buffer handle in the bufferHandle argument if the read
request was scheduled successfully. The function adds the request to the hardware instance receive queue and returns immediately. While the
request is in the queue, the application buffer is owned by the driver and should not be modified. The function returns
DRV_I2S_BUFFER_HANDLE_INVALID:
• if a buffer could not be allocated to the request
• if the input buffer pointer is NULL
• if the client opened the driver for write-only
• if the buffer size is 0
• if the queue is full or the queue depth is insufficient
If the requesting client registered an event callback with the driver, the driver will issue a DRV_I2S_BUFFER_EVENT_COMPLETE event if the
buffer was processed successfully of DRV_I2S_BUFFER_EVENT_ERROR event if the buffer was not processed successfully.
Remarks
This function is thread safe in a RTOS application. It can be called from within the I2S Driver Buffer Event Handler that is registered by this client. It
should not be called in the event handler associated with another I2S driver instance. It should not otherwise be called directly in an ISR.
This function supports DMA mode of operation.
Preconditions
The DRV_I2S_Initialize routine must have been called for the specified I2S device instance and the DRV_I2S_Status must have returned
SYS_STATUS_READY.
DRV_I2S_Open must have been called to obtain a valid opened device handle.
DRV_IO_INTENT_READ or DRV_IO_INTENT_READWRITE must have been specified in the DRV_I2S_Open call.
Example
MY_APP_OBJ myAppObj;
uint8_t mybuffer[MY_BUFFER_SIZE];
DRV_I2S_BUFFER_HANDLE bufferHandle;
Volume V: MPLAB Harmony Framework Driver Libraries Help I2S Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 578
// myI2SHandle is the handle returned
// by the DRV_I2S_Open function.
// Client registers an event handler with driver
DRV_I2S_BufferEventHandlerSet(myI2SHandle,
APP_I2SBufferEventHandler, (uintptr_t)&myAppObj);
DRV_I2S_BufferAddRead(myI2Shandle, &bufferHandle,
myBuffer, MY_BUFFER_SIZE);
if(DRV_I2S_BUFFER_HANDLE_INVALID == bufferHandle)
{
// Error handling here
}
// Event is received when
// the buffer is processed.
void APP_I2SBufferEventHandler(DRV_I2S_BUFFER_EVENT event,
DRV_I2S_BUFFER_HANDLE bufferHandle, uintptr_t contextHandle)
{
// contextHandle points to myAppObj.
switch(event)
{
case DRV_I2S_BUFFER_EVENT_COMPLETE:
// This means the data was transferred.
break;
case DRV_I2S_BUFFER_EVENT_ERROR:
// Error handling here.
break;
default:
break;
}
}
Parameters
Parameters Description
handle Handle of the I2S instance as returned by the DRV_I2S_Open function
buffer Buffer where the received data will be stored.
size Buffer size in bytes
bufferHandle Pointer to an argument that will contain the return buffer handle
Function
void DRV_I2S_BufferAddRead
(
const DRV_HANDLE handle,
DRV_I2S_BUFFER_HANDLE *bufferHandle,
void * buffer, size_t size
)
DRV_I2S_BufferAddWrite Function
Schedule a non-blocking driver write operation.
Implementation: Dynamic
File
drv_i2s.h
Volume V: MPLAB Harmony Framework Driver Libraries Help I2S Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 579
C
void DRV_I2S_BufferAddWrite(const DRV_HANDLE handle, DRV_I2S_BUFFER_HANDLE * bufferHandle, void * buffer,
size_t size);
Returns
The bufferHandle parameter will contain the return buffer handle. This will be DRV_I2S_BUFFER_HANDLE_INVALID if the function was not
successful.
Description
This function schedules a non-blocking write operation. The function returns with a valid buffer handle in the bufferHandle argument if the write
request was scheduled successfully. The function adds the request to the hardware instance transmit queue and returns immediately. While the
request is in the queue, the application buffer is owned by the driver and should not be modified. The function returns
DRV_I2S_BUFFER_HANDLE_INVALID:
• if a buffer could not be allocated to the request
• if the input buffer pointer is NULL
• if the client opened the driver for read-only
• if the buffer size is 0
• if the queue is full or the queue depth is insufficient
If the requesting client registered an event callback with the driver, the driver will issue a DRV_I2S_BUFFER_EVENT_COMPLETE event if the
buffer was processed successfully of DRV_I2S_BUFFER_EVENT_ERROR event if the buffer was not processed successfully.
Remarks
This function is thread safe in a RTOS application. It can be called from within the I2S Driver Buffer Event Handler that is registered by this client. It
should not be called in the event handler associated with another I2S driver instance. It should not otherwise be called directly in an ISR.
This function supports DMA mode of operation.
Preconditions
The DRV_I2S_Initialize routine must have been called for the specified I2S device instance and the DRV_I2S_Status must have returned
SYS_STATUS_READY.
DRV_I2S_Open must have been called to obtain a valid opened device handle.
DRV_IO_INTENT_WRITE or DRV_IO_INTENT_READWRITE must have been specified in the DRV_I2S_Open call.
Example
MY_APP_OBJ myAppObj;
uint8_t mybuffer[MY_BUFFER_SIZE];
DRV_I2S_BUFFER_HANDLE bufferHandle;
// myI2SHandle is the handle returned
// by the DRV_I2S_Open function.
// Client registers an event handler with driver
DRV_I2S_BufferEventHandlerSet(myI2SHandle,
APP_I2SBufferEventHandler, (uintptr_t)&myAppObj);
DRV_I2S_BufferAddWrite(myI2Shandle, &bufferHandle
myBuffer, MY_BUFFER_SIZE);
if(DRV_I2S_BUFFER_HANDLE_INVALID == bufferHandle)
{
// Error handling here
}
// Event is received when
// the buffer is processed.
void APP_I2SBufferEventHandler(DRV_I2S_BUFFER_EVENT event,
DRV_I2S_BUFFER_HANDLE bufferHandle, uintptr_t contextHandle)
{
// contextHandle points to myAppObj.
switch(event)
{
case DRV_I2S_BUFFER_EVENT_COMPLETE:
Volume V: MPLAB Harmony Framework Driver Libraries Help I2S Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 580
// This means the data was transferred.
break;
case DRV_I2S_BUFFER_EVENT_ERROR:
// Error handling here.
break;
default:
break;
}
}
Parameters
Parameters Description
handle Handle of the I2S instance as return by the DRV_I2S_Open function
buffer Data to be transmitted
size Buffer size in bytes
bufferHandle Pointer to an argument that will contain the return buffer handle
Function
void DRV_I2S_BufferAddWrite
(
const DRV_HANDLE handle,
DRV_I2S_BUFFER_HANDLE *bufferHandle,
void * buffer, size_t size
);
DRV_I2S_BufferAddWriteRead Function
Schedule a non-blocking driver write-read operation.
Implementation: Dynamic
File
drv_i2s.h
C
void DRV_I2S_BufferAddWriteRead(const DRV_HANDLE handle, DRV_I2S_BUFFER_HANDLE * bufferHandle, void *
transmitBuffer, void * receiveBuffer, size_t size);
Returns
The bufferHandle parameter will contain the return buffer handle. This will be DRV_I2S_BUFFER_HANDLE_INVALID if the function was not
successful.
Description
This function schedules a non-blocking write-read operation. The function returns with a valid buffer handle in the bufferHandle argument if the
write-read request was scheduled successfully. The function adds the request to the hardware instance queue and returns immediately. While the
request is in the queue, the application buffer is owned by the driver and should not be modified. The function returns
DRV_I2S_BUFFER_HANDLE_INVALID:
• if a buffer could not be allocated to the request
• if the input buffer pointer is NULL
• if the client opened the driver for read only or write only
• if the buffer size is 0
• if the queue is full or the queue depth is insufficient
If the requesting client registered an event callback with the driver, the driver will issue a DRV_I2S_BUFFER_EVENT_COMPLETE event if the
buffer was processed successfully of DRV_I2S_BUFFER_EVENT_ERROR event if the buffer was not processed successfully.
Remarks
This function is thread safe in a RTOS application. It can be called from within the I2S Driver Buffer Event Handler that is registered by this client. It
should not be called in the event handler associated with another I2S driver instance. It should not otherwise be called directly in an ISR.
This function is useful when there is valid read expected for every I2S write. The transmit and receive size must be same.
Volume V: MPLAB Harmony Framework Driver Libraries Help I2S Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 581
Preconditions
The DRV_I2S_Initialize routine must have been called for the specified I2S device instance and the DRV_I2S_Status must have returned
SYS_STATUS_READY.
DRV_I2S_Open must have been called to obtain a valid opened device handle.
DRV_IO_INTENT_READWRITE must have been specified in the DRV_I2S_Open call.
Example
MY_APP_OBJ myAppObj;
uint8_t mybufferTx[MY_BUFFER_SIZE];
uint8_t mybufferRx[MY_BUFFER_SIZE];
DRV_I2S_BUFFER_HANDLE bufferHandle;
// myI2SHandle is the handle returned
// by the DRV_I2S_Open function.
// Client registers an event handler with driver
DRV_I2S_BufferEventHandlerSet(myI2SHandle,
APP_I2SBufferEventHandler, (uintptr_t)&myAppObj);
DRV_I2S_BufferAddWriteRead(myI2Shandle, &bufferHandle,
mybufferTx,mybufferRx,MY_BUFFER_SIZE);
if(DRV_I2S_BUFFER_HANDLE_INVALID == bufferHandle)
{
// Error handling here
}
// Event is received when
// the buffer is processed.
void APP_I2SBufferEventHandler(DRV_I2S_BUFFER_EVENT event,
DRV_I2S_BUFFER_HANDLE bufferHandle, uintptr_t contextHandle)
{
// contextHandle points to myAppObj.
switch(event)
{
case DRV_I2S_BUFFER_EVENT_COMPLETE:
// This means the data was transferred.
break;
case DRV_I2S_BUFFER_EVENT_ERROR:
// Error handling here.
break;
default:
break;
}
}
Parameters
Parameters Description
handle Handle of the I2S instance as returned by the DRV_I2S_Open function
bufferHandle Pointer to an argument that will contain the return buffer handle
transmitBuffer Buffer where the transmit data will be stored
receiveBuffer Buffer where the received data will be stored
size Buffer size in bytes
Function
void DRV_I2S_BufferAddWriteRead
(
Volume V: MPLAB Harmony Framework Driver Libraries Help I2S Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 582
const DRV_HANDLE handle,
DRV_I2S_BUFFER_HANDLE *bufferHandle,
void *transmitBuffer, void *receiveBuffer,
size_t size
)
DRV_I2S_BufferEventHandlerSet Function
This function allows a client to identify a buffer event handling function for the driver to call back when queued buffer transfers have finished.
Implementation: Dynamic
File
drv_i2s.h
C
void DRV_I2S_BufferEventHandlerSet(DRV_HANDLE handle, const DRV_I2S_BUFFER_EVENT_HANDLER eventHandler,
const uintptr_t contextHandle);
Returns
None.
Description
This function allows a client to identify a buffer event handling function for the driver to call back when queued buffer transfers have finished. When
a client calls either the DRV_I2S_BufferAddRead, DRV_I2S_BufferAddWrite or DRV_I2S_BufferAddWriteRead function, it is provided with a
handle identifying the buffer that was added to the driver's buffer queue. The driver will pass this handle back to the client by calling "eventHandler"
function when the buffer transfer has completed.
The event handler should be set before the client performs any "buffer add" operations that could generate events. The event handler once set,
persists until the client closes the driver or sets another event handler (which could be a "NULL" pointer to indicate no callback).
Remarks
If the client does not want to be notified when the queued buffer transfer has completed, it does not need to register a callback.
Preconditions
The DRV_I2S_Initialize routine must have been called for the specified I2S driver instance.
DRV_I2S_Open must have been called to obtain a valid opened device handle.
Example
// myAppObj is an application specific object.
MY_APP_OBJ myAppObj;
uint8_t mybuffer[MY_BUFFER_SIZE];
DRV_I2S_BUFFER_HANDLE bufferHandle;
// myI2SHandle is the handle returned
// by the DRV_I2S_Open function.
// Client registers an event handler with driver. This is done once
DRV_I2S_BufferEventHandlerSet(myI2SHandle, APP_I2SBufferEventHandler,
(uintptr_t)&myAppObj);
DRV_I2S_BufferAddRead(myI2Shandle,&bufferHandle,
myBuffer, MY_BUFFER_SIZE);
if(DRV_I2S_BUFFER_HANDLE_INVALID == bufferHandle)
{
// Error handling here
}
// Event Processing Technique. Event is received when
// the buffer is processed.
void APP_I2SBufferEventHandler(DRV_I2S_BUFFER_EVENT event,
DRV_I2S_BUFFER_HANDLE handle, uintptr_t contextHandle)
Volume V: MPLAB Harmony Framework Driver Libraries Help I2S Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 583
{
// The context handle was set to an application specific
// object. It is now retrievable easily in the event handler.
MY_APP_OBJ myAppObj = (MY_APP_OBJ *) contextHandle;
switch(event)
{
case DRV_I2S_BUFFER_EVENT_COMPLETE:
// This means the data was transferred.
break;
case DRV_I2S_BUFFER_EVENT_ERROR:
// Error handling here.
break;
default:
break;
}
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
eventHandler Pointer to the event handler function.
context The value of parameter will be passed back to the client unchanged, when the eventHandler
function is called. It can be used to identify any client specific data object that identifies the
instance of the client module (for example, it may be a pointer to the client module's state
structure).
Function
void DRV_I2S_BufferEventHandlerSet
(
const DRV_HANDLE handle,
DRV_I2S_BUFFER_EVENT_HANDLER eventHandler,
uintptr_t contextHandle
)
DRV_I2S_BufferCombinedQueueSizeGet Function
This function returns the number of bytes queued (to be processed) in the buffer queue.
Implementation: Dynamic
File
drv_i2s.h
C
size_t DRV_I2S_BufferCombinedQueueSizeGet(DRV_HANDLE handle);
Returns
Returns the number of the bytes that have been processed for this buffer. Returns 0 for an invalid or an expired client handle.
Description
This function returns the number of bytes queued (to be processed) in the buffer queue of the driver instance associated with the calling client. The
client can use this function to know number of remaining bytes (from the buffers submitted by it)is in the queue to be transmitted.
Remarks
None.
Preconditions
The DRV_I2S_Initialize routine must have been called for the specified I2S driver instance.
DRV_I2S_Open must have been called to obtain a valid opened device handle.
Volume V: MPLAB Harmony Framework Driver Libraries Help I2S Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 584
One of DRV_I2S_BufferAddRead/DRV_I2S_BufferAddWrite function must have been called and buffers should have been queued for
transmission.
Example
// myAppObj is an application specific object.
MY_APP_OBJ myAppObj;
size_t bufferQueuedSize;
uint8_t mybuffer[MY_BUFFER_SIZE];
DRV_I2S_BUFFER_HANDLE bufferHandle;
// myI2SHandle is the handle returned
// by the DRV_I2S_Open function.
// Client registers an event handler with driver. This is done once
DRV_I2S_BufferEventHandlerSet(myI2SHandle, APP_I2SBufferEventHandle,
(uintptr_t)&myAppObj);
DRV_I2S_BufferAddRead(myI2Shandle,&bufferHandle,
myBuffer, MY_BUFFER_SIZE);
if(DRV_I2S_BUFFER_HANDLE_INVALID == bufferHandle)
{
// Error handling here
}
// The data is being processed after adding the buffer to the queue.
// The user can get to know dynamically available data in the queue to be
// transmitted by calling DRV_I2S_BufferCombinedQueueSizeGet
bufferQueuedSize = DRV_I2S_BufferCombinedQueueSizeGet(myI2SHandle);
Parameters
Parameters Description
handle Opened client handle associated with a driver object.
Function
size_t DRV_I2S_BufferCombinedQueueSizeGet( DRV_HANDLE handle)
DRV_I2S_BufferQueueFlush Function
This function flushes off the buffers associated with the client object.
Implementation: Dynamic
File
drv_i2s.h
C
void DRV_I2S_BufferQueueFlush(DRV_HANDLE handle);
Returns
None.
Description
This function flushes off the buffers associated with the client object and disables the DMA channel used for transmission.
Remarks
None.
Preconditions
The DRV_I2S_Initialize routine must have been called for the specified I2S driver instance.
DRV_I2S_Open must have been called to obtain a valid opened device handle.
One of DRV_I2S_BufferAddRead/DRV_I2S_BufferAddWrite function must have been called and buffers should have been queued for
transmission.
Volume V: MPLAB Harmony Framework Driver Libraries Help I2S Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 585
Example
// myAppObj is an application specific object.
MY_APP_OBJ myAppObj;
size_t bufferQueuedSize;
uint8_t mybuffer[MY_BUFFER_SIZE];
DRV_I2S_BUFFER_HANDLE bufferHandle;
// myI2SHandle is the handle returned
// by the DRV_I2S_Open function.
// Client registers an event handler with driver. This is done once
DRV_I2S_BufferEventHandlerSet(myI2SHandle, APP_I2SBufferEventHandle,
(uintptr_t)&myAppObj);
DRV_I2S_BufferAddRead(myI2Shandle,&bufferHandle,
myBuffer, MY_BUFFER_SIZE);
if(DRV_I2S_BUFFER_HANDLE_INVALID == bufferHandle)
{
// Error handling here
}
// The data is being processed after adding the buffer to the queue.
// The user can stop the data processing and flushoff the data
// in the queue by calling DRV_I2S_BufferQueueFlush
DRV_I2S_BufferQueueFlush(myI2SHandle);
Parameters
Parameters Description
handle Opened client handle associated with a driver object.
Function
void DRV_I2S_BufferQueueFlush( DRV_HANDLE handle)
DRV_I2S_Read Function
Reads data from the I2S.
Implementation: Dynamic
File
drv_i2s.h
C
size_t DRV_I2S_Read(const DRV_HANDLE handle, uint8_t * buffer, const size_t numBytes);
Returns
Number of bytes actually copied into the caller's buffer. Returns DRV_I2S_READ_ERROR in case of an error.
Description
This routine reads data from the I2S. This function is blocking if the driver was opened by the client for blocking operation. This function will not
block if the driver was opened by the client for non blocking operation. If the ioIntent parameter at the time of opening the driver was
DRV_IO_INTENT_BLOCKING, this function will only return when (or will block until) numBytes of bytes have been received or if an error occurred.
If the ioIntent parameter at the time of opening the driver was DRV_IO_INTENT_NON_BLOCKING, this function will return with the number of
bytes that were actually read. The function will not wait until numBytes of bytes have been read.
Remarks
This function is thread safe in a RTOS application. It is recommended that this function not be called in I2S Driver Event Handler due to the
potential blocking nature of the function. This function should not be called directly in an ISR. It should not be called in the event handler
associated with another I2S driver instance.
This function does not supports DMA mode of operation.
Volume V: MPLAB Harmony Framework Driver Libraries Help I2S Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 586
Preconditions
The DRV_I2S_Initialize routine must have been called for the specified I2S driver instance.
DRV_I2S_Open must have been called to obtain a valid opened device handle.
DRV_IO_INTENT_READ or DRV_IO_INTENT_READWRITE must have been specified in the DRV_I2S_Open call.
Example
DRV_HANDLE myI2SHandle; // Returned from DRV_I2S_Open
char myBuffer[MY_BUFFER_SIZE];
unsigned int count;
unsigned int total;
total = 0;
do
{
count = DRV_I2S_Read(myI2SHandle, &myBuffer[total],
MY_BUFFER_SIZE - total);
total += count;
if(count == DRV_I2S_READ_ERROR)
{
// Handle error ...
}
else
{
// Do what needs to be..
}
} while( total < MY_BUFFER_SIZE );
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
buffer Buffer into which the data read from the I2S instance will be placed.
numBytes Total number of bytes that need to be read from the module instance (must be equal to or
less than the size of the buffer)
Function
size_t DRV_I2S_Read
(
const DRV_HANDLE handle,
uint8_t *buffer,
const size_t numBytes
)
DRV_I2S_Write Function
Writes data to the I2S.
Implementation: Dynamic
File
drv_i2s.h
C
size_t DRV_I2S_Write(const DRV_HANDLE handle, uint8_t * buffer, const size_t numBytes);
Returns
Number of bytes actually written to the driver. Return DRV_I2S_WRITE_ERROR in case of an error.
Description
This routine writes data to the I2S. This function is blocking if the driver was opened by the client for blocking operation. This function will not block
if the driver was opened by the client for non blocking operation. If the ioIntent parameter at the time of opening the driver was
DRV_IO_INTENT_BLOCKING, this function will only return when (or will block until) numbytes of bytes have been transmitted or if an error
occurred.
Volume V: MPLAB Harmony Framework Driver Libraries Help I2S Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 587
If the ioIntent parameter at the time of opening the driver was DRV_IO_INTENT_NON_BLOCKING, this function will return with the number of
bytes that were actually accepted for transmission. The function will not wait until numBytes of bytes have been transmitted.
Remarks
This function is thread safe in a RTOS application. It is recommended that this function not be called in I2S Driver Event Handler due to the
potential blocking nature of the function. This function should not be called directly in an ISR. It should not be called in the event handler
associated with another USART driver instance.
This function does not supports DMA mode of operation.
Preconditions
The DRV_I2S_Initialize routine must have been called for the specified I2S driver instance.
DRV_I2S_Open must have been called to obtain a valid opened device handle.
DRV_IO_INTENT_WRITE or DRV_IO_INTENT_READWRITE must have been specified in the DRV_I2S_Open call.
Example
DRV_HANDLE myI2SHandle; // Returned from DRV_I2S_Open
char myBuffer[MY_BUFFER_SIZE];
int count;
unsigned int total;
total = 0;
do
{
count = DRV_I2S_Write(myI2SHandle, &myBuffer[total],
MY_BUFFER_SIZE - total);
total += count;
if(count == DRV_I2S_WRITE_ERROR)
{
// Handle error ...
}
else
{
// Do what needs to be ..
}
} while( total < MY_BUFFER_SIZE );
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
buffer Buffer containing the data to written.
numbytes size of the buffer
Function
size_t DRV_I2S_Write
(
const DRV_HANDLE handle,
void * buffer,
const size_t numbytes
)
DRV_I2S_BufferProcessedSizeGet Function
This function returns number of bytes that have been processed for the specified buffer.
Implementation: Dynamic
File
drv_i2s.h
C
size_t DRV_I2S_BufferProcessedSizeGet(DRV_HANDLE handle);
Returns
Returns the number of the bytes that have been processed for this buffer. Returns 0 for an invalid or an expired buffer handle.
Volume V: MPLAB Harmony Framework Driver Libraries Help I2S Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 588
Description
This function returns number of bytes that have been processed for the specified buffer. The client can use this function, in a case where the buffer
has terminated due to an error, to obtain the number of bytes that have been processed. If this function is called on a invalid buffer handle, or if the
buffer handle has expired, the function returns 0.
Remarks
None.
Preconditions
The DRV_I2S_Initialize routine must have been called for the specified I2S driver instance.
DRV_I2S_Open must have been called to obtain a valid opened device handle.
One of DRV_I2S_BufferAddRead, DRV_I2S_BufferAddWrite or DRV_I2S_BufferAddWriteRead function must have been called and a valid buffer
handle returned.
Example
// myAppObj is an application specific object.
MY_APP_OBJ myAppObj;
uint8_t mybuffer[MY_BUFFER_SIZE];
DRV_I2S_BUFFER_HANDLE bufferHandle;
// myI2SHandle is the handle returned
// by the DRV_I2S_Open function.
// Client registers an event handler with driver. This is done once
DRV_I2S_BufferEventHandlerSet(myI2SHandle, APP_I2SBufferEventHandle,
(uintptr_t)&myAppObj);
DRV_I2S_BufferAddRead(myI2Shandle,&bufferHandle,
myBuffer, MY_BUFFER_SIZE);
if(DRV_I2S_BUFFER_HANDLE_INVALID == bufferHandle)
{
// Error handling here
}
// Event Processing Technique. Event is received when
// the buffer is processed.
void APP_I2SBufferEventHandler(DRV_I2S_BUFFER_EVENT event,
DRV_I2S_BUFFER_HANDLE bufferHandle, uintptr_t contextHandle)
{
// The context handle was set to an application specific
// object. It is now retrievable easily in the event handler.
MY_APP_OBJ myAppObj = (MY_APP_OBJ *) contextHandle;
size_t processedBytes;
switch(event)
{
case DRV_I2S_BUFFER_EVENT_COMPLETE:
// This means the data was transferred.
break;
case DRV_I2S_BUFFER_EVENT_ERROR:
// Error handling here.
// We can find out how many bytes were processed in this
// buffer before the error occurred.
processedBytes = DRV_I2S_BufferProcessedSizeGet(myI2SHandle);
break;
default:
Volume V: MPLAB Harmony Framework Driver Libraries Help I2S Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 589
break;
}
}
Parameters
Parameters Description
bufferhandle Handle of the buffer of which the processed number of bytes to be obtained.
Function
size_t DRV_I2S_BufferProcessedSizeGet( DRV_HANDLE handle)
d) Miscellaneous Functions
DRV_I2S_BaudSet Function
This function sets the baud.
Implementation: Dynamic
File
drv_i2s.h
C
void DRV_I2S_BaudSet(DRV_HANDLE handle, uint32_t spiClock, uint32_t baud);
Returns
None
Description
This function sets the baud rate for the I2S operation.
Remarks
None.
Preconditions
The DRV_I2S_Initialize routine must have been called for the specified I2S driver instance.
DRV_I2S_Open must have been called to obtain a valid opened device handle.
Example
// myAppObj is an application specific object.
MY_APP_OBJ myAppObj;
uint8_t mybuffer[MY_BUFFER_SIZE];
DRV_HANDLE handle;
uint32_t baud;
uint32_t clock;
// myI2SHandle is the handle returned
// by the DRV_I2S_Open function.
// Client registers an event handler with driver. This is done once
DRV_I2S_BufferEventHandlerSet(myI2SHandle, APP_I2SBufferEventHandle,
(uintptr_t)&myAppObj);
// Sets the baud rate to a new value as below
baud = 115200;
clock = 40000000UL;
DRV_I2S_BaudSet(myI2SHandle, clock, baud);
// Further perform the operation needed
DRV_I2S_BufferAddRead(myI2Shandle,&bufferHandle,
myBuffer, MY_BUFFER_SIZE);
Volume V: MPLAB Harmony Framework Driver Libraries Help I2S Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 590
if(DRV_I2S_BUFFER_HANDLE_INVALID == bufferHandle)
{
// Error handling here
}
// Event Processing Technique. Event is received when
// the buffer is processed.
void APP_I2SBufferEventHandler(DRV_I2S_BUFFER_EVENT event,
DRV_I2S_BUFFER_HANDLE bufferHandle, uintptr_t contextHandle)
{
// The context handle was set to an application specific
// object. It is now retrievable easily in the event handler.
MY_APP_OBJ myAppObj = (MY_APP_OBJ *) contextHandle;
size_t processedBytes;
switch(event)
{
case DRV_I2S_BUFFER_EVENT_COMPLETE:
// This means the data was transferred.
break;
case DRV_I2S_BUFFER_EVENT_ERROR:
// Error handling here.
// We can find out how many bytes were processed in this
// buffer before the error occurred.
processedBytes = DRV_I2S_BufferProcessedSizeGet(myI2SHandle);
break;
default:
break;
}
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
i2sClock The Source clock frequency to the i2S module.
baud The baud to be set.
Function
void DRV_I2S_BaudSet( DRV_HANDLE handle, uint32_t spiClock, uint32_t baud)
DRV_I2S_ErrorGet Function
This function returns the error(if any) associated with the last client request.
Implementation: Dynamic
File
drv_i2s.h
C
DRV_I2S_ERROR DRV_I2S_ErrorGet(DRV_HANDLE handle);
Returns
A DRV_I2S_ERROR type indicating last known error status.
Description
This function returns the error(if any) associated with the last client request. The DRV_I2S_Read() and DRV_I2S_Write() will update the client
error status when these functions return DRV_I2S_READ_ERROR and DRV_I2S_WRITE_ERROR, respectively. If the driver send a
Volume V: MPLAB Harmony Framework Driver Libraries Help I2S Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 591
DRV_I2S_BUFFER_EVENT_ERROR to the client, the client can call this function to know the error cause. The error status will be updated on
every operation and should be read frequently (ideally immediately after the driver operation has completed) to know the relevant error status.
Remarks
It is the client's responsibility to make sure that the error status is obtained frequently. The driver will update the client error status regardless of
whether this has been examined by the client.
Preconditions
The DRV_I2S_Initialize routine must have been called for the specified I2S driver instance.
DRV_I2S_Open must have been called to obtain a valid opened device handle.
Example
// myAppObj is an application specific object.
MY_APP_OBJ myAppObj;
uint8_t mybuffer[MY_BUFFER_SIZE];
DRV_I2S_BUFFER_HANDLE bufferHandle;
// myI2SHandle is the handle returned
// by the DRV_I2S_Open function.
// Client registers an event handler with driver. This is done once
DRV_I2S_BufferEventHandlerSet( myI2SHandle, APP_I2SBufferEventHandle,
(uintptr_t)&myAppObj );
DRV_I2S_BufferAddRead( myI2Shandle,&bufferHandle,
myBuffer, MY_BUFFER_SIZE );
if(DRV_I2S_BUFFER_HANDLE_INVALID == bufferHandle)
{
// Error handling here
}
// Event Processing Technique. Event is received when
// the buffer is processed.
void APP_I2SBufferEventHandler( DRV_I2S_BUFFER_EVENT event,
DRV_I2S_BUFFER_HANDLE bufferHandle, uintptr_t contextHandle )
{
// The context handle was set to an application specific
// object. It is now retrievable easily in the event handler.
MY_APP_OBJ myAppObj = (MY_APP_OBJ *) contextHandle;
size_t processedBytes;
switch(event)
{
case DRV_I2S_BUFFER_EVENT_SUCCESS:
// This means the data was transferred.
break;
case DRV_I2S_BUFFER_EVENT_FAILURE:
// Error handling here.
// We can find out how many bytes were processed in this
// buffer before the error occurred. We can also find
// the error cause.
processedBytes = DRV_I2S_BufferProcessedSizeGet(myI2SHandle);
if(DRV_I2S_ERROR_RECEIVE_OVERRUN == DRV_I2S_ErrorGet(myI2SHandle))
{
// There was an receive over flow error.
// Do error handling here.
}
break;
Volume V: MPLAB Harmony Framework Driver Libraries Help I2S Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 592
default:
break;
}
}
Parameters
Parameters Description
bufferhandle Handle of the buffer of which the processed number of bytes to be obtained.
Function
DRV_I2S_ERROR DRV_I2S_ErrorGet(DRV_HANDLE handle)
DRV_I2S_ReceiveErrorIgnore Function
This function enable/disable ignoring of the receive overflow error.
Implementation: Dynamic
File
drv_i2s.h
C
void DRV_I2S_ReceiveErrorIgnore(DRV_HANDLE handle, bool errorEnable);
Returns
None
Description
A receive overflow is not a critical error; during receive overflow data in the FIFO is not overwritten by receive data. Ignore receive overflow is
needed for cases when there is a general performance problem in the system that software must handle properly.
Remarks
None.
Preconditions
The DRV_I2S_Initialize routine must have been called for the specified I2S driver instance.
DRV_I2S_Open must have been called to obtain a valid opened device handle.
Example
// myAppObj is an application specific object.
MY_APP_OBJ myAppObj;
uint8_t mybuffer[MY_BUFFER_SIZE];
DRV_HANDLE handle;
uint32_t baud;
uint32_t baud;*
// myI2SHandle is the handle returned
// by the DRV_I2S_Open function.
// Client registers an event handler with driver. This is done once
DRV_I2S_BufferEventHandlerSet(myI2SHandle, APP_I2SBufferEventHandle,
(uintptr_t)&myAppObj);
// Enable ignoring of receive overflow error
DRV_I2S_ReceiveErrorIgnore(myI2SHandle, true);
// Further perform the operation needed
DRV_I2S_BufferAddRead(myI2Shandle,&bufferHandle,
myBuffer, MY_BUFFER_SIZE);
if(DRV_I2S_BUFFER_HANDLE_INVALID == bufferHandle)
{
// Error handling here
}
Volume V: MPLAB Harmony Framework Driver Libraries Help I2S Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 593
// Event Processing Technique. Event is received when
// the buffer is processed.
void APP_I2SBufferEventHandler(DRV_I2S_BUFFER_EVENT event,
DRV_I2S_BUFFER_HANDLE bufferHandle, uintptr_t contextHandle)
{
// The context handle was set to an application specific
// object. It is now retrievable easily in the event handler.
MY_APP_OBJ myAppObj = (MY_APP_OBJ *) contextHandle;
size_t processedBytes;
switch(event)
{
case DRV_I2S_BUFFER_EVENT_COMPLETE:
// This means the data was transferred.
break;
case DRV_I2S_BUFFER_EVENT_ERROR:
// Error handling here.
// We can find out how many bytes were processed in this
// buffer before the error occurred.
processedBytes = DRV_I2S_BufferProcessedSizeGet(bufferHandle);
break;
default:
break;
}
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
errorIgnore When set to 'true' enables ignoring of transmit underrun error. When set to 'false' disables
ignoring of transmit underrun error.
Function
void DRV_I2S_ReceiveErrorIgnore( DRV_HANDLE handle, bool errorEnable)
DRV_I2S_TransmitErrorIgnore Function
This function enable/disable ignoring of the transmit underrun error.
Implementation: Dynamic
File
drv_i2s.h
C
void DRV_I2S_TransmitErrorIgnore(DRV_HANDLE handle, bool errorIgnore);
Returns
None
Description
A Transmit underrun error is not a critical error and zeros are transmitted until the SPIxTXB is not empty. Ignore Transmit underrun error is needed
for cases when software does not care or does not need to know about underrun conditions.
Remarks
None.
Volume V: MPLAB Harmony Framework Driver Libraries Help I2S Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 594
Preconditions
The DRV_I2S_Initialize routine must have been called for the specified I2S driver instance.
DRV_I2S_Open must have been called to obtain a valid opened device handle.
Example
// myAppObj is an application specific object.
MY_APP_OBJ myAppObj;
uint8_t mybuffer[MY_BUFFER_SIZE];
DRV_HANDLE handle;
uint32_t baud;
uint32_t baud;*
// myI2SHandle is the handle returned
// by the DRV_I2S_Open function.
// Client registers an event handler with driver. This is done once
DRV_I2S_BufferEventHandlerSet(myI2SHandle, APP_I2SBufferEventHandle,
(uintptr_t)&myAppObj);
// Enable ignoring of transmit underrun error
DRV_I2S_TransmitErrorIgnore(myI2SHandle, true);
// Further perform the operation needed
DRV_I2S_BufferAddRead(myI2Shandle,&bufferHandle,
myBuffer, MY_BUFFER_SIZE);
if(DRV_I2S_BUFFER_HANDLE_INVALID == bufferHandle)
{
// Error handling here
}
// Event Processing Technique. Event is received when
// the buffer is processed.
void APP_I2SBufferEventHandler(DRV_I2S_BUFFER_EVENT event,
DRV_I2S_BUFFER_HANDLE bufferHandle, uintptr_t contextHandle)
{
// The context handle was set to an application specific
// object. It is now retrievable easily in the event handler.
MY_APP_OBJ myAppObj = (MY_APP_OBJ *) contextHandle;
size_t processedBytes;
switch(event)
{
case DRV_I2S_BUFFER_EVENT_COMPLETE:
// This means the data was transferred.
break;
case DRV_I2S_BUFFER_EVENT_ERROR:
// Error handling here.
// We can find out how many bytes were processed in this
// buffer before the error occurred.
processedBytes = DRV_I2S_BufferProcessedSizeGet(bufferHandle);
break;
default:
break;
}
}
Volume V: MPLAB Harmony Framework Driver Libraries Help I2S Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 595
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
errorIgnore When set to 'true' enables ignoring of transmit underrun error. When set to 'false' disables
ignoring of transmit underrun error.
Function
void DRV_I2S_TransmitErrorIgnore( DRV_HANDLE handle, bool errorIgnore)
e) Data Types and Constants
DRV_I2S_AUDIO_PROTOCOL_MODE Enumeration
Identifies the Audio Protocol Mode of the I2S module.
File
drv_i2s.h
C
typedef enum {
DRV_I2S_AUDIO_I2S,
DRV_I2S_AUDIO_LFET_JUSTIFIED,
DRV_I2S_AUDIO_RIGHT_JUSTIFIED,
DRV_I2S_AUDIO_PCM_DSP
} DRV_I2S_AUDIO_PROTOCOL_MODE;
Members
Members Description
DRV_I2S_AUDIO_I2S I2S Audio Protocol
DRV_I2S_AUDIO_LFET_JUSTIFIED Left Justified Audio Protocol
DRV_I2S_AUDIO_RIGHT_JUSTIFIED Right Justified Audio Protocol
DRV_I2S_AUDIO_PCM_DSP PCM/DSP Audio Protocol
Description
I2S Audio Protocol Mode
This enumeration identifies Audio Protocol Mode of the I2S module.
Remarks
None.
DRV_I2S_BUFFER_EVENT Enumeration
Identifies the possible events that can result from a buffer add request.
File
drv_i2s.h
C
typedef enum {
DRV_I2S_BUFFER_EVENT_COMPLETE,
DRV_I2S_BUFFER_EVENT_ERROR,
DRV_I2S_BUFFER_EVENT_ABORT
} DRV_I2S_BUFFER_EVENT;
Members
Members Description
DRV_I2S_BUFFER_EVENT_COMPLETE Data was transferred successfully.
DRV_I2S_BUFFER_EVENT_ERROR Error while processing the request
DRV_I2S_BUFFER_EVENT_ABORT Data transfer aborted (Applicable in DMA mode)
Volume V: MPLAB Harmony Framework Driver Libraries Help I2S Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 596
Description
I2S Driver Events
This enumeration identifies the possible events that can result from a buffer add request caused by the client calling either the
DRV_I2S_BufferAddRead, DRV_I2S_BufferAddWrite or DRV_I2S_BufferAddWriteRead functions.
Remarks
One of these values is passed in the "event" parameter of the event handling callback function that the client registered with the driver by calling
the DRV_I2S_BufferEventHandlerSet function when a buffer transfer request is completed.
DRV_I2S_BUFFER_EVENT_HANDLER Type
Pointer to a I2S Driver Buffer Event handler function
File
drv_i2s.h
C
typedef void (* DRV_I2S_BUFFER_EVENT_HANDLER)(DRV_I2S_BUFFER_EVENT event, DRV_I2S_BUFFER_HANDLE
bufferHandle, uintptr_t contextHandle);
Returns
None.
Description
I2S Driver Buffer Event Handler Function
This data type defines the required function signature for the I2S driver buffer event handling callback function. A client must register a pointer to a
buffer event handling function whose function signature (parameter and return value types) match the types specified by this function pointer in
order to receive buffer related event calls back from the driver.
The parameters and return values are described here and a partial example implementation is provided.
Remarks
If the event is DRV_I2S_BUFFER_EVENT_COMPLETE, this means that the data was transferred successfully.
If the event is DRV_I2S_BUFFER_EVENT_ERROR, this means that the data was not transferred successfully. The bufferHandle parameter
contains the buffer handle of the buffer that failed. The DRV_I2S_ErrorGet function can be called to know the error. The
DRV_I2S_BufferProcessedSizeGet function can be called to find out how many bytes were processed.
The bufferHandle parameter contains the buffer handle of the buffer that associated with the event.
The context parameter contains a handle to the client context, provided at the time the event handling function was registered using the
DRV_I2S_BufferEventHandlerSet function. This context handle value is passed back to the client as the "context" parameter. It can be any value
necessary to identify the client context or instance (such as a pointer to the client's data) instance of the client that made the buffer add request.
The buffer handle in bufferHandle expires after this event handler exits. In that the buffer object that was allocated is deallocated by the driver after
the event handler exits.
The event handler function executes in the driver peripheral's interrupt context when the driver is configured for interrupt mode operation. It is
recommended of the application to not perform process intensive or blocking operations with in this function.
The DRV_I2S_BufferAddRead, DRV_I2S_BufferAddWrite and DRV_I2S_BufferAddWriteRead functions can be called in the event handler to add
a buffer to the driver queue. These functions can only be called to add buffers to the driver whose event handler is running. For example, buffers
cannot be added I2S2 driver in I2S1 driver event handler.
Example
void APP_MyBufferEventHandler
(
DRV_I2S_BUFFER_EVENT event,
DRV_I2S_BUFFER_HANDLE bufferHandle,
uintptr_t context
)
{
MY_APP_DATA_STRUCT pAppData = (MY_APP_DATA_STRUCT) context;
switch(event)
{
case DRV_I2S_BUFFER_EVENT_COMPLETE:
// Handle the completed buffer.
Volume V: MPLAB Harmony Framework Driver Libraries Help I2S Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 597
break;
case DRV_I2S_BUFFER_EVENT_ERROR:
default:
// Handle error.
break;
}
}
Parameters
Parameters Description
event Identifies the type of event
bufferHandle Handle identifying the buffer to which the event relates
context Value identifying the context of the application that registered the event handling function.
DRV_I2S_BUFFER_HANDLE Type
Handle identifying a read or write buffer passed to the driver.
File
drv_i2s.h
C
typedef uintptr_t DRV_I2S_BUFFER_HANDLE;
Description
I2S Driver Buffer Handle
A buffer handle value is returned by a call to the DRV_I2S_BufferAddRead, DRV_I2S_BufferAddWrite, and DRV_I2S_BufferAddWriteRead
functions. This handle is associated with the buffer passed into the function and it allows the application to track the completion of the data from (or
into) that buffer. The buffer handle value returned from the "buffer add" function is returned back to the client by the "event handler callback"
function registered with the driver.
The buffer handle assigned to a client request expires when the client has been notified of the completion of the buffer transfer (after event handler
function that notifies the client returns) or after the buffer has been retired by the driver if no event handler callback was set.
Remarks
None
DRV_I2S_CLOCK_MODE Enumeration
Identifies the various clock modes of the I2S module.
File
drv_i2s.h
C
typedef enum {
DRV_I2S_CLOCK_MODE_IDLE_LOW_EDGE_RISE,
DRV_I2S_CLOCK_MODE_IDLE_LOW_EDGE_FALL,
DRV_I2S_CLOCK_MODE_IDLE_HIGH_EDGE_FALL,
DRV_I2S_CLOCK_MODE_IDLE_HIGH_EDGE_RISE
} DRV_I2S_CLOCK_MODE;
Members
Members Description
DRV_I2S_CLOCK_MODE_IDLE_LOW_EDGE_RISE I2S Clock Mode 0 - Idle State Low & Sampling on Rising Edge
DRV_I2S_CLOCK_MODE_IDLE_LOW_EDGE_FALL I2S Clock Mode 1 - Idle State Low & Sampling on Falling Edge
DRV_I2S_CLOCK_MODE_IDLE_HIGH_EDGE_FALL I2S Clock Mode 2 - Idle State High & Sampling on Falling Edge
DRV_I2S_CLOCK_MODE_IDLE_HIGH_EDGE_RISE I2S Clock Mode 3 - Idle State High & Sampling on Rising Edge
Description
I2S Clock Mode Selection
Volume V: MPLAB Harmony Framework Driver Libraries Help I2S Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 598
This enumeration identifies the supported clock modes of the I2S module.
Remarks
None.
DRV_I2S_DATA16 Structure
Defines the left and right channel data for 16-bit audio data
File
drv_i2s.h
C
typedef struct {
int16_t leftData;
int16_t rightData;
} DRV_I2S_DATA16;
Members
Members Description
int16_t leftData; Left channel data
int16_t rightData; Right channel data
Description
I2S Driver Audio Data 16
Defines the left and right channel data for 16-bit audio data
Remarks
None.
DRV_I2S_DATA24 Structure
Defines the left and right channel data for 24-bit audio data
File
drv_i2s.h
C
typedef struct {
int32_t leftData : 24;
int32_t leftDataPad : 8;
int32_t rightData : 24;
int32_t rightDataPad : 8;
} DRV_I2S_DATA24;
Members
Members Description
int32_t leftData : 24; Left channel data
int32_t leftDataPad : 8; Left channel data pad
int32_t rightData : 24; Right channel data
int32_t rightDataPad : 8; Right channel data pad
Description
I2S Driver Audio Data 24
Defines the left and right channel data for 24-bit audio data
Remarks
None.
DRV_I2S_DATA32 Structure
Defines the left and right channel data for 32-bit audio data
Volume V: MPLAB Harmony Framework Driver Libraries Help I2S Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 599
File
drv_i2s.h
C
typedef struct {
int32_t leftData;
int32_t rightDataPad;
} DRV_I2S_DATA32;
Members
Members Description
int32_t leftData; Left channel data
int32_t rightDataPad; Right channel data
Description
I2S Driver Audio Data 32
Defines the left and right channel data for 32-bit audio data
Remarks
None.
DRV_I2S_ERROR Enumeration
Defines the possible errors that can occur during driver operation.
File
drv_i2s.h
C
typedef enum {
DRV_I2S_ERROR_NONE,
DRV_I2S_ERROR_RECEIVE_OVERFLOW,
DRV_I2S_ERROR_TRANSMIT_UNDERUN,
DRV_I2S_ERROR_FRAMING,
DRV_I2S_ERROR_ADDRESS
} DRV_I2S_ERROR;
Members
Members Description
DRV_I2S_ERROR_NONE Data was transferred successfully.
DRV_I2S_ERROR_RECEIVE_OVERFLOW Receive overflow error.
DRV_I2S_ERROR_TRANSMIT_UNDERUN Transmit underrun error.
DRV_I2S_ERROR_FRAMING Framing error.
DRV_I2S_ERROR_ADDRESS Channel address error (Applicable in DMA mode)
Description
I2S Driver Error
This data type defines the possible errors that can occur when occur during USART driver operation. These values are returned by
DRV_I2S_ErrorGet function.
Remarks
None.
DRV_I2S_MODE Enumeration
Identifies the usage modes of the I2S module.
File
drv_i2s.h
Volume V: MPLAB Harmony Framework Driver Libraries Help I2S Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 600
C
typedef enum {
DRV_I2S_MODE_SLAVE,
DRV_I2S_MODE_MASTER
} DRV_I2S_MODE;
Members
Members Description
DRV_I2S_MODE_SLAVE I2S Mode Slave
DRV_I2S_MODE_MASTER I2S Mode Master
Description
I2S Usage Modes Enumeration
This enumeration identifies the whether the I2S module will be used as a master or slave.
Remarks
None.
DRV_I2S_BUFFER_HANDLE_INVALID Macro
Definition of an invalid buffer handle.
File
drv_i2s.h
C
#define DRV_I2S_BUFFER_HANDLE_INVALID ((DRV_I2S_BUFFER_HANDLE)(-1))
Description
I2S Driver Invalid Buffer Handle
This is the definition of an invalid buffer handle. An invalid buffer handle is returned by DRV_I2S_BufferAddRead, DRV_I2S_BufferAddWrite and
DRV_I2S_BufferAddWriteRead functions if the buffer add request was not successful.
Remarks
None
DRV_I2S_COUNT Macro
Number of valid I2S driver indices
File
drv_i2s.h
C
#define DRV_I2S_COUNT
Description
I2S Driver Module Count
This constant identifies the maximum number of I2S Driver instances that should be defined by the application. Defining more instances than this
constant will waste RAM memory space.
This constant can also be used by the application to identify the number of I2S instances on this microcontroller.
Remarks
This value is part-specific.
DRV_I2S_READ_ERROR Macro
I2S Driver Read Error.
File
drv_i2s.h
Volume V: MPLAB Harmony Framework Driver Libraries Help I2S Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 601
C
#define DRV_I2S_READ_ERROR ((size_t)(-1))
Description
I2S Driver Read Error
This constant is returned by DRV_I2S_Read function when an error occurs.
Remarks
None.
DRV_I2S_WRITE_ERROR Macro
I2S Driver Write Error.
File
drv_i2s.h
C
#define DRV_I2S_WRITE_ERROR ((size_t)(-1))
Description
I2S Driver Write Error
This constant is returned by DRV_I2S_Write() function when an error occurs.
Remarks
None.
DRV_I2S_INDEX_0 Macro
I2S driver index definitions
File
drv_i2s.h
C
#define DRV_I2S_INDEX_0 0
Description
Driver I2S Module Index
These constants provide I2S driver index definition.
Remarks
These constants should be used in place of hard-coded numeric literals. These values should be passed into the DRV_I2S_Initialize and
DRV_I2S_Open routines to identify the driver instance in use.
DRV_I2S_INDEX_1 Macro
File
drv_i2s.h
C
#define DRV_I2S_INDEX_1 1
Description
This is macro DRV_I2S_INDEX_1.
Volume V: MPLAB Harmony Framework Driver Libraries Help I2S Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 602
DRV_I2S_INDEX_2 Macro
File
drv_i2s.h
C
#define DRV_I2S_INDEX_2 2
Description
This is macro DRV_I2S_INDEX_2.
DRV_I2S_INDEX_3 Macro
File
drv_i2s.h
C
#define DRV_I2S_INDEX_3 3
Description
This is macro DRV_I2S_INDEX_3.
DRV_I2S_INDEX_4 Macro
File
drv_i2s.h
C
#define DRV_I2S_INDEX_4 4
Description
This is macro DRV_I2S_INDEX_4.
DRV_I2S_INDEX_5 Macro
File
drv_i2s.h
C
#define DRV_I2S_INDEX_5 5
Description
This is macro DRV_I2S_INDEX_5.
DRV_I2S_INTERFACE Structure
This structure defines a structure of I2S Driver function pointers.
File
drv_i2s.h
C
typedef struct {
SYS_MODULE_OBJ (* initialize)(const SYS_MODULE_INDEX drvIndex, const SYS_MODULE_INIT * const init);
void (* deinitialize)(SYS_MODULE_OBJ);
SYS_STATUS (* status)(SYS_MODULE_OBJ object);
void (* tasks)(SYS_MODULE_OBJ object);
void (* tasksError)(SYS_MODULE_OBJ object);
DRV_HANDLE (* open)(const SYS_MODULE_INDEX iDriver, const DRV_IO_INTENT ioIntent);
Volume V: MPLAB Harmony Framework Driver Libraries Help I2S Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 603
void (* close)(const DRV_HANDLE handle);
void (* bufferAddWrite)(const DRV_HANDLE handle, DRV_I2S_BUFFER_HANDLE *bufferHandle, void *buffer,
size_t size);
void (* bufferAddRead)(const DRV_HANDLE handle, DRV_I2S_BUFFER_HANDLE *bufferHandle, void *buffer, size_t
size);
void (* bufferAddWriteRead)(const DRV_HANDLE handle, DRV_I2S_BUFFER_HANDLE *bufferHandle, void
*transmitBuffer, void *receiveBuffer, size_t size);
size_t (* read)(const DRV_HANDLE handle, uint8_t *buffer, const size_t numBytes);
size_t (* write)(const DRV_HANDLE handle, uint8_t *buffer, const size_t numBytes);
void (* eventHandlerSet)(DRV_HANDLE handle, const DRV_I2S_BUFFER_EVENT_HANDLER eventHandler, const
uintptr_t contextHandle);
size_t (* bufferProcessedSizeGet)(DRV_HANDLE handle);
size_t (* bufferCombinedQueueSizeGet)(DRV_HANDLE handle);
void (* bufferQueueFlush)(DRV_HANDLE handle);
DRV_I2S_ERROR (* errorGet)(DRV_HANDLE handle);
void (* baudSet)(DRV_HANDLE handle, uint32_t peripheralClock, uint32_t baud);
void (* setAudioCommunicationMode)(DRV_HANDLE handle, uint8_t audioCommWidth);
void (* transmitErrorIgnore)(DRV_HANDLE handle, bool errorIgnore);
void (* receiveErrorIgnore)(DRV_HANDLE handle, bool errorEnable);
} DRV_I2S_INTERFACE;
Members
Members Description
SYS_MODULE_OBJ (* initialize)(const
SYS_MODULE_INDEX drvIndex, const
SYS_MODULE_INIT * const init);
Pointer to the driver Initialization function
void (* deinitialize)(SYS_MODULE_OBJ); Pointer to the driver Deinitialization function
SYS_STATUS (* status)(SYS_MODULE_OBJ
object);
Pointer to the driver Status function
void (* tasks)(SYS_MODULE_OBJ object); Pointer to the Tasks function
void (* tasksError)(SYS_MODULE_OBJ object); Pointer to the Error Tasks function
DRV_HANDLE (* open)(const
SYS_MODULE_INDEX iDriver, const
DRV_IO_INTENT ioIntent);
Pointer to the Open function
void (* close)(const DRV_HANDLE handle); Pointer to the Close function
void (* bufferAddWrite)(const DRV_HANDLE
handle, DRV_I2S_BUFFER_HANDLE
*bufferHandle, void *buffer, size_t size);
Pointer to the Buffer Add Write function
void (* bufferAddRead)(const DRV_HANDLE
handle, DRV_I2S_BUFFER_HANDLE
*bufferHandle, void *buffer, size_t size);
Pointer to the Buffer Add Read function
void (* bufferAddWriteRead)(const
DRV_HANDLE handle,
DRV_I2S_BUFFER_HANDLE *bufferHandle,
void *transmitBuffer, void *receiveBuffer, size_t
size);
Pointer to the buffer Add Read Write function
size_t (* read)(const DRV_HANDLE handle,
uint8_t *buffer, const size_t numBytes);
Pointer to the driver Read function
size_t (* write)(const DRV_HANDLE handle,
uint8_t *buffer, const size_t numBytes);
Pointer to the driver Write function
void (* eventHandlerSet)(DRV_HANDLE handle,
const DRV_I2S_BUFFER_EVENT_HANDLER
eventHandler, const uintptr_t contextHandle);
Pointer to the driver Buffer Event Handler Set function
size_t (*
bufferProcessedSizeGet)(DRV_HANDLE handle);
Pointer to the driver Buffer Processed Size Get function
size_t (*
bufferCombinedQueueSizeGet)(DRV_HANDLE
handle);
Pointer to the driver Buffer Combined Queue Size Get Function
void (* bufferQueueFlush)(DRV_HANDLE
handle);
Pointer to the driver Buffer Queue Flush Function
DRV_I2S_ERROR (* errorGet)(DRV_HANDLE
handle);
Pointer to the driver Error Get function
void (* baudSet)(DRV_HANDLE handle, uint32_t
peripheralClock, uint32_t baud);
Pointer to the driver Baud Set function
void (*
setAudioCommunicationMode)(DRV_HANDLE
handle, uint8_t audioCommWidth);
Pointer to the driver Set Audio Communication mode function
Volume V: MPLAB Harmony Framework Driver Libraries Help I2S Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 604
void (* transmitErrorIgnore)(DRV_HANDLE
handle, bool errorIgnore);
Pointer to the driver Transmit Error Ignore function
void (* receiveErrorIgnore)(DRV_HANDLE
handle, bool errorEnable);
Pointer to the driver Receive Error Ignore function
Description
I2S Driver Interface
This structure defines a structure of I2S Driver function pointers. A driver of any peripheral that supports the I2S protocol can export such a
structure. The top level I2S Driver abstraction layer will then use this structure to map a I2S Driver call to underlying peripheral driver.
Remarks
None.
Files
Files
Name Description
drv_i2s.h I2S Driver Interface header file
drv_i2s_config_template.h I2S Driver Configuration Template.
Description
drv_i2s.h
I2S Driver Interface header file
Enumerations
Name Description
DRV_I2S_AUDIO_PROTOCOL_MODE Identifies the Audio Protocol Mode of the I2S module.
DRV_I2S_BUFFER_EVENT Identifies the possible events that can result from a buffer add request.
DRV_I2S_CLOCK_MODE Identifies the various clock modes of the I2S module.
DRV_I2S_ERROR Defines the possible errors that can occur during driver operation.
DRV_I2S_MODE Identifies the usage modes of the I2S module.
Functions
Name Description
DRV_I2S_BaudSet This function sets the baud.
Implementation: Dynamic
DRV_I2S_BufferAddRead Schedule a non-blocking driver read operation.
Implementation: Dynamic
DRV_I2S_BufferAddWrite Schedule a non-blocking driver write operation.
Implementation: Dynamic
DRV_I2S_BufferAddWriteRead Schedule a non-blocking driver write-read operation.
Implementation: Dynamic
DRV_I2S_BufferCombinedQueueSizeGet This function returns the number of bytes queued (to be processed) in the buffer queue.
Implementation: Dynamic
DRV_I2S_BufferEventHandlerSet This function allows a client to identify a buffer event handling function for the driver to
call back when queued buffer transfers have finished.
Implementation: Dynamic
DRV_I2S_BufferProcessedSizeGet This function returns number of bytes that have been processed for the specified buffer.
Implementation: Dynamic
DRV_I2S_BufferQueueFlush This function flushes off the buffers associated with the client object.
Implementation: Dynamic
DRV_I2S_Close Closes an opened-instance of the I2S driver.
Implementation: Dynamic
DRV_I2S_Deinitialize Deinitializes the specified instance of the I2S driver module.
Implementation: Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help I2S Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 605
DRV_I2S_ErrorGet This function returns the error(if any) associated with the last client request.
Implementation: Dynamic
DRV_I2S_Initialize Initializes hardware and data for the instance of the I2S module.
Implementation: Dynamic
DRV_I2S_Open Opens the specified I2S driver instance and returns a handle to it.
Implementation: Dynamic
DRV_I2S_Read Reads data from the I2S.
Implementation: Dynamic
DRV_I2S_ReceiveErrorIgnore This function enable/disable ignoring of the receive overflow error.
Implementation: Dynamic
DRV_I2S_Status Gets the current status of the I2S driver module.
Implementation: Dynamic
DRV_I2S_Tasks Maintains the driver's receive state machine and implements its ISR.
Implementation: Dynamic
DRV_I2S_TasksError Maintains the driver's error state machine and implements its ISR.
Implementation: Dynamic
DRV_I2S_TransmitErrorIgnore This function enable/disable ignoring of the transmit underrun error.
Implementation: Dynamic
DRV_I2S_Write Writes data to the I2S.
Implementation: Dynamic
Macros
Name Description
DRV_I2S_BUFFER_HANDLE_INVALID Definition of an invalid buffer handle.
DRV_I2S_COUNT Number of valid I2S driver indices
DRV_I2S_INDEX_0 I2S driver index definitions
DRV_I2S_INDEX_1 This is macro DRV_I2S_INDEX_1.
DRV_I2S_INDEX_2 This is macro DRV_I2S_INDEX_2.
DRV_I2S_INDEX_3 This is macro DRV_I2S_INDEX_3.
DRV_I2S_INDEX_4 This is macro DRV_I2S_INDEX_4.
DRV_I2S_INDEX_5 This is macro DRV_I2S_INDEX_5.
DRV_I2S_READ_ERROR I2S Driver Read Error.
DRV_I2S_WRITE_ERROR I2S Driver Write Error.
Structures
Name Description
DRV_I2S_DATA16 Defines the left and right channel data for 16-bit audio data
DRV_I2S_DATA24 Defines the left and right channel data for 24-bit audio data
DRV_I2S_DATA32 Defines the left and right channel data for 32-bit audio data
DRV_I2S_INTERFACE This structure defines a structure of I2S Driver function pointers.
Types
Name Description
DRV_I2S_BUFFER_EVENT_HANDLER Pointer to a I2S Driver Buffer Event handler function
DRV_I2S_BUFFER_HANDLE Handle identifying a read or write buffer passed to the driver.
Description
I2S Driver Interface
The I2S device driver provides a simple interface to manage the I2S module on Microchip microcontrollers. This file provides the interface
definition for the I2S driver.
File Name
drv_i2s.h
Company
Microchip Technology Inc.
Volume V: MPLAB Harmony Framework Driver Libraries Help I2S Driver Library Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 606
drv_i2s_config_template.h
I2S Driver Configuration Template.
Macros
Name Description
DRV_I2S_CLIENTS_NUMBER Sets up the maximum number of clients that can be connected to any
hardware instance.
DRV_I2S_INDEX I2S Static Index selection
DRV_I2S_INSTANCES_NUMBER Sets up the maximum number of hardware instances that can be supported
DRV_I2S_INTERRUPT_MODE Macro controls interrupt based operation of the driver
DRV_I2S_INTERRUPT_SOURCE_ERROR Defines the interrupt source for the error interrupt
DRV_I2S_INTERRUPT_SOURCE_RECEIVE Macro to define the Receive interrupt source in case of static driver
DRV_I2S_INTERRUPT_SOURCE_TRANSMIT Macro to define the Transmit interrupt source in case of static driver
DRV_I2S_PERIPHERAL_ID Configures the I2S PLIB Module ID
DRV_I2S_QUEUE_DEPTH_COMBINED Number of entries of all queues in all instances of the driver.
DRV_I2S_RECEIVE_DMA_CHAINING_CHANNEL Macro to defines the I2S Driver Receive DMA Chaining Channel in case of
static driver
DRV_I2S_RECEIVE_DMA_CHANNEL Macro to defines the I2S Driver Receive DMA Channel in case of static driver
DRV_I2S_STOP_IN_IDLE Identifies whether the driver should stop operations in stop in Idle mode.
DRV_I2S_TRANSMIT_DMA_CHANNEL Macro to defines the I2S Driver Transmit DMA Channel in case of static driver
Description
I2S Driver Configuration Template
These file provides the list of all the configurations that can be used with the driver. This file should not be included in the driver.
File Name
drv_i2s_config_template.h
Company
Microchip Technology Inc.
Input Capture Driver Library
This section describes the Input Capture Driver Library.
Introduction
The Input Capture Static Driver provides a high-level interface to manage the Input Capture module on the Microchip family of microcontrollers.
Description
Through the MHC, this driver provides APIs for the following:
• Initializing the module
• Starting/Stopping of the capture
• 16/32-bit data reads
• Buffer empty status
Library Interface
Functions
Name Description
DRV_IC_Initialize Initializes the Input Capture instance for the specified driver index.
Implementation: Static
DRV_IC_BufferIsEmpty Returns the Input Capture instance buffer empty status for the specified driver index.
Implementation: Static
DRV_IC_Capture16BitDataRead Reads the 16-bit Input Capture for the specified driver index.
Implementation: Static
Volume V: MPLAB Harmony Framework Driver Libraries Help Input Capture Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 607
DRV_IC_Capture32BitDataRead Reads the 32-bit Input Capture for the specified driver index.
Implementation: Static
DRV_IC_Start Starts the Input Capture instance for the specified driver index.
Implementation: Static
DRV_IC_Stop Stops the Input Capture instance for the specified driver index.
Implementation: Static
Description
This section describes the Application Programming Interface (API) functions of the Input Capture Driver Library.
Functions
DRV_IC_Initialize Function
Initializes the Input Capture instance for the specified driver index.
Implementation: Static
File
help_drv_ic.h
C
void DRV_IC_Initialize();
Returns
None.
Description
This routine initializes the Input Capture driver instance for the specified driver instance, making it ready for clients to use it. The initialization
routine is specified by the MHC parameters. The driver instance index is independent of the Input Capture module ID. For example, driver instance
0 can be assigned to Input Capture 2.
Remarks
This routine must be called before any other Input Capture routine is called. This routine should only be called once during system initialization.
Preconditions
None.
Function
void DRV_IC_Initialize( void )
DRV_IC_BufferIsEmpty Function
Returns the Input Capture instance buffer empty status for the specified driver index.
Implementation: Static
File
help_drv_ic.h
C
bool DRV_IC_BufferIsEmpty();
Returns
Boolean
• 1 - Buffer is empty
• 0 - Buffer is not empty
Description
Returns the Input Capture instance buffer empty status for the specified driver index. The function should be called to determine whether or not the
IC buffer has data.
Volume V: MPLAB Harmony Framework Driver Libraries Help Input Capture Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 608
Remarks
None.
Preconditions
DRV_IC_Initialize has been called.
Function
bool DRV_IC_BufferIsEmpty( void )
DRV_IC_Capture16BitDataRead Function
Reads the 16-bit Input Capture for the specified driver index.
Implementation: Static
File
help_drv_ic.h
C
uint16_t DRV_IC_Capture16BitDataRead();
Returns
uint16_t value of the data read from the Input Capture.
Description
This routine reads the 16-bit data for the specified driver index.
Remarks
None.
Preconditions
DRV_IC_Initialize has been called.
Function
uint16_t DRV_IC_Capture16BitDataRead( void )
DRV_IC_Capture32BitDataRead Function
Reads the 32-bit Input Capture for the specified driver index.
Implementation: Static
File
help_drv_ic.h
C
uint32_t DRV_IC_Capture32BitDataRead();
Returns
uint32_t value of the data read from the Input Capture.
Description
This routine reads the 32-bit data for the specified driver index
Remarks
None.
Preconditions
DRV_IC_Initialize has been called.
Function
uint32_t DRV_IC_Capture32BitDataRead( void )
Volume V: MPLAB Harmony Framework Driver Libraries Help Input Capture Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 609
DRV_IC_Start Function
Starts the Input Capture instance for the specified driver index.
Implementation: Static
File
help_drv_ic.h
C
void DRV_IC_Start();
Returns
None.
Description
This routine starts the Input Capture driver for the specified driver index, starting an input capture.
Remarks
None.
Preconditions
DRV_IC_Initialize has been called.
Function
void DRV_IC_Start( void )
DRV_IC_Stop Function
Stops the Input Capture instance for the specified driver index.
Implementation: Static
File
help_drv_ic.h
C
void DRV_IC_Stop();
Returns
None.
Description
This routine stops the Input Capture driver for the specified driver index, stopping an input capture.
Remarks
None.
Preconditions
DRV_IC_Initialize has been called.
Function
void DRV_IC_Stop( void )
Input System Service Touch Driver Library
This section describes the Touch Driver Libraries that support the Input System Service. These libraries are variants of libraries previously created
to support the Touch System Service, which is being deprecated by the Input System Service.
Touch Driver Libraries in service of the Touch System Service:
ADC Touch Driver Library This topic describes the ADC Touch Driver Library.
mXT336T Touch Driver Library This topic describes the mXT336T Touch Driver Library.
Volume V: MPLAB Harmony Framework Driver Libraries Help Input System Service Touch Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 610
Input System Service Touch ADC Driver Library
This touch driver library establishes a software resistive touch controller using the Analog-to-Digital Converter (ADC) module. This driver provides
application routines to read touch input data from the touch screen. Touch events are detected using an interrupt service routine rather than
polling. This driver also allows provides the capability to set translation coefficients that allow an application to map a raw screen values to actual
native display size using through 4-point calibration technique.
Using the Library
This topic describes the basic architecture of the Touch ADC Driver Library for the Input System Service and provides information and examples
on its use.
Interface Header File:
/firmware/src/system_config//driver/input/touch_adc/drv_touch_adc.h
The interface to the Touch ADC Driver library is defined in the drv_touch_adc.h header file related to the currently active project target
configuration. This file is automatically generated by MHGC. Any C language source (.c) file that uses the ADC Touch Driver library should
include this header.
Please refer to the What is MPLAB Harmony? section for how the driver interacts with the framework.
Abstraction Model
This topic describes the components of the Touch ADC solution in support of the Input System Service.
• Touch ADC Driver – Finite-State machine that biases the x-axis and y-axis analog pins to measure resistance on a touch screen. Identifies
touch events up, down or move. Forwards events to Harmony Service, Input System.
• ADC Driver – Provides the 4-wire resistive touch interface. It is used to driver hardware pin configuration to sample and measure touch screen
resistance.
• Input system Service – Client level service which makes available touch events to the graphics library.
Touch ADC Driver Abstraction Model.
Library Overview
Refer to the Driver Library Overview section for information on how the driver operates in a system.
The library interface routines are divided into various sub-sections, which address one of the blocks or the overall operation of the Touch ADC
Driver module.
Volume V: MPLAB Harmony Framework Driver Libraries Help Input System Service Touch Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 611
Library Interface Section Description
System Functions Provides system interfaces, device initialization, deinitialization, open, close, task, and status functions.
How the Library Works
The library provides interfaces to support:
• System functions, which provide system module interfaces, device initialization, deinitialization, open, close, and status functions.
• Timer – rate at which to detect a new position
Of note are the following routine, which are found in:
/firmware/src/system_config//driver/input/touch_adc/src/drv_touch_adc.c:
• DRV_TOUCH_ADC_Tasks() - sends a move, release, or press event to SYS_Input Services. It is called from system_tasks.c.
• DRV_TOUCH_ADC_PositionDetect() – performs resistance measurements to determine x and y positions.
• DRV_TOUCH_ADC_TouchGetX() – returns the x coordinate.
• DRV_TOUCH_ADC_TouchGetY() – returns the y coordinate.
• DRV_TOUCH_ADCCoefficientSet() – stores 4-translation calibrate coefficients
Initializing the Driver
Before the Touch ADC Driver can be opened, it must be configured and initialized. MHGC automatically includes the needed #define constants
and source code into the project’s system_init.c file.
The driver initialization is configured through the DRV_TOUCH_ADC_INIT data structure that is passed to the DRV_TOUCH_ADC_Initialize
function.
Opening the Driver
To use the Touch ADC Driver, the application must open the driver. This is done by calling the DRV_TOUCH_ADC_Open function. If successful, the
DRV_TOUCH_ADC_Open function will return a handle to the driver. This handle records the association between the client and the driver instance
that was opened. The DRV_TOUCH_ADC_Open function may return DRV_HANDLE_INVALID in the situation where the driver is not ready to be
opened. When this occurs, the application can try opening the driver again. Note that the open function may return an invalid handle in other
(error) cases as well. The following code shows an example of the driver being opened.
DRV_HANDLE handle;
handle = DRV_TOUCH_ADC_Open( DRV_TOUCH_ADC_INDEX_0,DRV_IO_INTENT_EXCLUSIVE );
if( DRV_HANDLE_INVALID == handle )
{
// Unable
}
Tasks Routine
This routine communicates with the System Input Service on the state of the current X and Y positions detected. The routine checks 4 different
conditions:
1. Invalid position – does not send an event upstream.
2. Same position – sends a still event to input system service
3. Move position – sends a move event to input system service.
4. Release condition – sends a release event to input system service
5. Press condition- sends a press event to input system service.
Touch Detection
This routine uses the services of the Touch ADC to establish a voltage divider on 4 ADC pins. The table below shows the pin configurations
required to read the x and y values. The X value is read by a bias on x-axis and a measurement on ADC Y+ pin. The Y value is read by a bias on
the y-axis and a measurement on ADC X+ pin.
Operation X+ Pin Action Y+Pin Action X-GPIO Pin State Y-GPIO Pin State
Get X Pin Output
(set)
Pin Input
(Read X value)
Pin Input Pin Output
(clear)
Get Y Pin Input
(read Y value)
Pin Output
(set)
Pin Output
(clear)
Pin Input
Volume V: MPLAB Harmony Framework Driver Libraries Help Input System Service Touch Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 612
(Here "set" means SYS_PORTS_PinSet() and "clear" means SYS_PORTS_PinClear().)
Configuring the Library
The configuration of the Touch ADC Driver is performed using the MPLAB Harmony Configurator.
Building the Library
The section lists the files that are available in the Touch ADC Library.
Description
The section lists which files need to be included in the build based on either a hardware feature present on the board or configuration option
selected by the system.
The following tables list and describe the header (.h) and source (.c) files that implement this library. The parent folder for these files is
/framework/driver/input/drv_touch_adc.h
Interface File(s)
This table lists and describes the header files that must be included (i.e., using #include) by any code that uses this library. Note this file is
automatically included in the project by MHGC.
Source File Name
/firmware/src/system_config//driver/input/touch_adc/drv_touch_adc.h
Required File(s)
All of the required files listed below are automatically added into the MPLAB X IDE project by the MHC when the library is selected for use.
This table lists and describes the source and header files that must always be included in the MPLAB X IDE project to build this library.
Source File Name
/firmware/src/system_config//driver/input/touch_adc/src/drv_touch_adc.c
Optional File(s)
This table lists and describes the source and header files that may optionally be included if required for the desired implementation.
Source File Name Description
N/A No optional files are available for this library.
Module Dependencies
The ADC Touch Driver Library depends on the following modules:
• Interrupt System Service Library
• Ports System Service Library
• Input System Service Library
• ADC Driver Library
Library Interface
Files
Files
Name Description
drv_touch_adc.h Touch ADC Driver interface file.
Volume V: MPLAB Harmony Framework Driver Libraries Help Input System Service Touch Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 613
Description
drv_touch_adc.h
Touch ADC Driver interface file.
Description
Touch ADC Driver Interface File
This is a simple 4-wire resistive touch screen driver. The file consist of touch controller ADC driver interfaces. It implements the driver interfaces
which read the touch input data from display overlay through the ADC peripheral.
Remarks
This driver is based on the MPLAB Harmony ADC driver.
File Name
drv_touch_adc.c
Input System Service mXT336T Touch Driver Library
This topic describes the mXT336T Touch Driver Library that supports theInput System Service.
The library provides an interface to manage the mXT336T Touch Driver module on the Microchip family of microcontrollers in different modes of
operation. It supports the Input System Service as a client by providing touch events detected by the maXTouch® mXT336T Capacitive Touch
Controller.
Description
The MPLAB Harmony mXT336T Touch Driver provides a high-level interface to the mXT336T Capacitive Touch Controller. This driver provides
application routines to read the touch input data from the touch screen. Currently, the mXT336T Touch Driver supports non-gestural
single-fingered and gestural two-finger touch inputs.
The mXT336T Capacitive Touch Controller notifies the host of the availability of touch input data through an external interrupt on the host. The
mXT336T driver allows the application to map a controller pin as the external interrupt pin used by the mXT336T.
The driver contains the standard MPLAB Harmony driver interfaces including: initialization, destruction, status, tasks, open, close, and
interrupt-driven read.
The driver contains no direct access to input events. All driver output is directed towards the MPLAB Harmony Input System Service and
applications desiring to listen to input events must register with that service.
The aria_quickstart demonstration interfaces with the mXT336T Touch Driver Library. Please refer to the What is MPLAB Harmony? section in
Volume I of MPLAB Harmony’s built-in documentation for how the driver interacts with the framework.
Using the Library
This topic describes the basis architecture of the mXT336T Touch Driver Library that supports the Input System Service and provides information
and examples on its use.
Description
Interface Header File: ./framework/driver/input/touch/mxt336t/drv_mxt336t.h
The interface to the mXT336T Touch Driver library is defined in the drv_mxt336t.h header file. Any C language source (.c) file that uses the
mXT336T Touch Driver library should include this header.
The mXT336T Touch Driver is based on the Object Protocol for the maXTouch® mXT336T Touchscreen Controller.
The aria_quickstart demonstration interfaces with the mXT336T Touch Driver Library. Please refer to the What is MPLAB Harmony? section for
how the driver interacts with the framework.
Abstraction Model
This library provides a low-level abstraction of the mXT336T Touch Driver Library on the Microchip family microcontrollers. This topic describes
how that abstraction is modeled in software and introduces the library's interface.
Description
The mXT336T Touch Driver has routines to perform the following operations:
• Sending read request
Volume V: MPLAB Harmony Framework Driver Libraries Help Input System Service Touch Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 614
• Reading the touch input data
• Access to the touch input data
The driver initialization routines allow the application to initialize the driver. The driver must be initialized before it can be used by application. Once
the touch input is available (by the assertion of the external interrupt input to the host) a touch input read request is sent to the mXT336t and input
data is retrieved in a buffer. The buffer data is then decoded to get the x and y coordinate of the touch screen in the form of the number of pixels.
After touch event data has been received it is propagated to the Input System Service which then distributes it to all interested parts of the
application.
mXT336T Driver Abstraction Model
Library Overview
This section contains information about how the Touch Driver operates in a system.
Description
The library interface routines are divided into various sub-sections, which address one of the blocks or the overall operation of the mXT336T
Touch Driver.
Library Interface Section Description
Device-Specific Functions Provides mXT336T-specific system module interfaces, device initialization, deinitialization, open, close, task, and
status functions.
Generic Functions Provides generic system module interfaces, device initialization, deinitialization, open, close, task, and status
functions.
How the Library Works
This section describes the workings of this Touch Driver library.
Volume V: MPLAB Harmony Framework Driver Libraries Help Input System Service Touch Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 615
Description
The library provides interfaces to support:
• System functions, which provide system module interfaces, device initialization, deinitialization, open, close, task, and status functions.
• Read Request function, which provides Touch input data read request function.
Initializing the Driver
Before the mXT336T Touch Driver can be opened, it must be configured and initialized. The driver build time configuration is defined by the
configuration macros. Refer to the Building the Library section for the location of and more information on the various configuration macros and
how these macros should be designed. The driver initialization is configured through the DRV_MXT336T_INIT data structure that is passed to the
DRV_MXT336T_Initialize function. The initialization parameters include the interrupt source, interrupt pin remap configuration and touch screen
resolution. The following code shows an example of initializing the mXT336T Touch Driver.
Example:
/* The following code shows an example of designing the
* DRV_TOUCH_INIT data structure. It also shows how an example
* usage of the DRV_TOUCH_MXT336T_Initialize function.
*/
This entire example section can be replaced with:
const DRV_MXT336T_INIT drvMXT336TInitData =
{
.drvOpen = DRV_I2C_Open,
.orientation = 0,
.horizontalResolution = 480,
.verticalResolution = 272,
};
sysObj.drvMXT336T = DRV_MXT336T_Initialize(0, (SYS_MODULE_INIT *)&drvMXT336TInitData);
Touch Input Read Request
To read the touch input from the mXT336T touch controller device, a read request must be registered. This is done by calling
DRV_MXT336T_ReadRequest. If successful, it registers a buffer read request to the I2C command queue. It also adds an input decode command
to the mXT336T command queue once the I2C returns with touch input data. It can return error if the driver instance object is invalid or the
mXT336T command queue is full. The read request is to be called from the mXT336T ISR. This ISR is triggered once the touch input is available.
The following code shows an example of a mXT336T read request registration:
SYS_MODULE_OBJ object; // Returned from DRV_TOUCH_MXT336T_Initialize
void ISR(_EXTERNAL_INT_VECTOR, ipl5) _IntHandlerDrvMxt336t(void)
{
DRV__MXT336T_ReadRequest ( object );
// Do Other Tasks
.
.
.
}
Tasks Routine
This routine processes the mXT336T commands from the command queue. If the state of the command is initialize or done it returns. If the read
request registration is successful the state of command is to decode input. The tasks routine decodes the input and updates the global variables
storing the touch input data in form of x and y coordinates. The mXT336T Touch Driver task routine is to be called from SYS_Tasks. The following
code shows an example:
SYS_MODULE_OBJ drvMXT336T;
SYS_MODULE_OBJ drvMxt0;; // Returned from DRV_TOUCH_MXT336T_Initialize
void SYS_Tasks( void )
{
DRV_MXT336T_Tasks(sysObj.drvMXT336T);
DRV_MXT_Tasks(sysObj.drvMxt0);
// Do other tasks
}
Volume V: MPLAB Harmony Framework Driver Libraries Help Input System Service Touch Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 616
Configuring in MPLAB Harmony Configurator
The graphics demo aria_quickstart has several target configurations that provide examples of driver setup. Any configuration ending in meb2 or
_meb2_wvga can be used.
The MPLAB Harmony Configurator Pin Settings tab should be configured to select the correct pin for the external interrupt. For example,
pic32mk_gp_db:
91 RF6 5V MXT336T_TOUCH_INT GPIO_CN
pic32mz_da_sk_extddr:
A14 RB1 - MXT336T_TOUCH_INT INT4
pic32mz_da_sk_intddr, pic32mz_da_noddr:
B9 RB1 - MXT336T_TOUCH_INT INT4
pic32mz_ef_sk:
23 RE8 - MXT336T_TOUCH_INT INT1
Library Interface
Files
Files
Name Description
drv_input_mxt336t.h Touch controller MXT336T Driver interface header file.
Description
drv_input_mxt336t.h
Touch controller MXT336T Driver interface header file.
Description
Touch Controller MXT336T Driver Interface File
This header file describes the macros, data structure and prototypes of the touch controller MXT336T driver interface.
File Name
drv_MXT336T.c
MIIM Driver Library
This section describes the MII Management (MIIM) Driver Library.
Introduction
The MIIM Driver library provides access to the MII Management interface (MIIM) of the Microchip PIC32 microcontrollers.
Description
The MIIM Driver is implemented as a driver object that provides APIs for:
• Asynchronous read/write and scan operations for accessing the external PHY registers
• Notification when MIIM operations have completed
Volume V: MPLAB Harmony Framework Driver Libraries Help MIIM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 617
• Driver status information
• Possibility to query or abort an ongoing operation.
Using the Library
This topic describes the basic architecture of the MIIM Driver Library and provides information and examples about its use.
Description
Interface Header File: drv_miim.h
The interface to the MIIM library is defined in the drv_miim.h header file.
Please refer to the What is MPLAB Harmony? section for how the driver interacts with the framework.
Abstraction Model
This library provides a low-level abstraction of the MIIM module on the Microchip family of microcontrollers with a convenient C language interface.
This topic describes how that abstraction is modeled in software and introduces the library's interface.
Description
The MIIM driver clients access PHY registers using the MIIM Driver API. The driver abstracts out the hardware details of the MIIM interface and
provides a PHY register access mechanism to the application. The MIIM Driver provides read, write, and scan access to the PHY registers,
together with driver and operation status APIs. The driver schedules operations requested by multiple clients and performs them sequentially,
informing the clients about the operations outcome.
The user can poll for a certain operation status or can register callbacks to be notified of the completion of a scheduled operation.
A scheduled operation can be aborted, if not yet started.
MIIM Driver Abstraction Model
Library Overview
Refer to the Driver Library Overview section for information about how the driver operates in a system.
Description
The library interface routines are divided into various sub-sections, which address one of the blocks or the overall operation of the MIIM module.
Library Interface Section Description
Functions This section provides general interface routines.
Volume V: MPLAB Harmony Framework Driver Libraries Help MIIM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 618
Data Types and Constants This section provides various definitions describing this API.
Configuring the Library
This section contains related configuration macros.
Macros
Name Description
DRV_MIIM_INDEX_0 MIIM driver index definitions.
DRV_MIIM_INDEX_COUNT Number of valid MIIM driver indices.
_DRV_MIIM_CONFIG_H This is macro _DRV_MIIM_CONFIG_H.
DRV_MIIM_CLIENT_OP_PROTECTION Enables/Disables Client Operation Protection feature.
DRV_MIIM_COMMANDS Enables/Disables MIIM commands feature.
DRV_MIIM_INSTANCE_CLIENTS Selects the maximum number of clients.
DRV_MIIM_INSTANCE_OPERATIONS Selects the maximum number of simultaneous operations for an instance.
DRV_MIIM_INSTANCES_NUMBER Selects the maximum number of hardware instances that can be supported by the
dynamic driver.
Description
The configuration of the MIIM Driver is based on the file system_config.h.
This header file contains the configuration selection for the MIIM Driver. Based on the selections made, the MIIM Driver may support the selected
features. These configuration settings will apply to all instances of the MIIM Driver.
This header can be placed anywhere; however, the path of this header needs to be present in the include search path for a successful build. Refer
to the Applications Help section for more details.
DRV_MIIM_INDEX_0 Macro
MIIM driver index definitions.
File
drv_miim.h
C
#define DRV_MIIM_INDEX_0 0
Description
MIIM Driver Module Index Numbers
These constants provide the MIIM driver index definitions.
Remarks
These constants should be used in place of hard-coded numeric literals.
These values should be passed into the DRV_MIIM_Initialize and DRV_MIIM_Open routines to identify the driver instance in use.
DRV_MIIM_INDEX_COUNT Macro
Number of valid MIIM driver indices.
File
drv_miim.h
C
#define DRV_MIIM_INDEX_COUNT 1
Description
MIIM Driver Module Index Count
This constant identifies the number of valid MIIM driver indices.
Volume V: MPLAB Harmony Framework Driver Libraries Help MIIM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 619
Remarks
This constant should be used in place of hard-coded numeric literals.
This value is derived from part-specific header files defined as part of the peripheral libraries.
_DRV_MIIM_CONFIG_H Macro
File
drv_miim_config.h
C
#define _DRV_MIIM_CONFIG_H
Description
This is macro _DRV_MIIM_CONFIG_H.
DRV_MIIM_CLIENT_OP_PROTECTION Macro
Enables/Disables Client Operation Protection feature.
File
drv_miim_config.h
C
#define DRV_MIIM_CLIENT_OP_PROTECTION 0
Description
MIIM client Operation Protection
Because of the recirculation of the operation handles and client handles the possibility exists that a misbehaved client inadvertently gets the results
of a previous completed operations that now belongs to a different client. When this feature is enabled, extra protection is added for an operation
handle to uniquely identify a client that has started the operation and extra check is done that operation belongs to the client that asks for the result.
Remarks
Set the value to 1 to enable, 0 to disable the feature.
Enabling this feature requires a small overhead in code and data size.
DRV_MIIM_COMMANDS Macro
Enables/Disables MIIM commands feature.
File
drv_miim_config.h
C
#define DRV_MIIM_COMMANDS 0
Description
MIIM PHY Commands
Adds a MIIM command to the TCP/IP command menu allowing to read/write a PHY register.
Remarks
Set the value to 1 to enable, 0 to disable the feature.
Currently the MIIM commands are integrated in the TCP/IP commands. To have the MIIM commands available the TCP/IP commands need to be
enabled.
DRV_MIIM_INSTANCE_CLIENTS Macro
Selects the maximum number of clients.
File
drv_miim_config.h
Volume V: MPLAB Harmony Framework Driver Libraries Help MIIM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 620
C
#define DRV_MIIM_INSTANCE_CLIENTS 2
Description
MIIM number of clients
This definition select the MIIM Maximum Number of Clients per instance.
Remarks
By default the 1st MIIM client is the DRV_ETHPHY. An extra client is allowed.
DRV_MIIM_INSTANCE_OPERATIONS Macro
Selects the maximum number of simultaneous operations for an instance.
File
drv_miim_config.h
C
#define DRV_MIIM_INSTANCE_OPERATIONS 4
Description
MIIM instance operations
This definition selects the maximum number of simultaneous operations that can be supported by this driver. Note that this represents operations
for all clients
Remarks
None.
DRV_MIIM_INSTANCES_NUMBER Macro
Selects the maximum number of hardware instances that can be supported by the dynamic driver.
File
drv_miim_config.h
C
#define DRV_MIIM_INSTANCES_NUMBER 1
Description
MIIM hardware instance configuration
This definition selects the maximum number of hardware instances that can be supported by the dynamic driver. Usually set to 1.
Remarks
None.
Building the Library
This section lists the files that are available in the MIIM Driver Library.
Description
The following three tables list and describe the header (.h) and source (.c) files that implement this library. The parent folder for these files is
/framework/driver/miim/.
Interface File(s)
This table lists and describes the header files that must be included (i.e., using #include) by any code that uses this library.
Source File Name Description
/drv_miim.h This is the MIIM Driver Library's interface header file.
/config/drv_miim.config.h This file contains the configuration macros.
Volume V: MPLAB Harmony Framework Driver Libraries Help MIIM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 621
Required File(s)
All of the required files listed in the following table are automatically added into the MPLAB X IDE project by the MHC
when the library is selected for use.
This table lists and describes the source and header files that must always be included in the MPLAB X IDE project to build this library.
Source File Name Description
/src/dynamic/drv_miim.c This file contains the source code for the dynamic implementation of the MIIM Driver.
Optional File(s)
This table lists and describes the source and header files that may optionally be included if required for the desired implementation.
Source File Name Description
N/A No optional files are available for this library.
Library Interface
This section describes the Application Programming Interface (API) functions of the MIIM Driver Library.
Refer to each section for a detailed description.
a) Functions
Name Description
DRV_MIIM_ClientStatus Gets the current client-specific status the MIIM driver.
DRV_MIIM_Close Closes an opened instance of the MIIM driver.
DRV_MIIM_Deinitialize Deinitializes the specified instance of the MIIM driver module.
DRV_MIIM_DeregisterCallback Deregisters an notification callback function for the client operations.
DRV_MIIM_Initialize Initializes the MIIM driver.
DRV_MIIM_Open Opens the specified MIIM driver instance and returns a handle to it.
DRV_MIIM_OperationAbort Aborts a current client operation initiated by the MIIM driver.
DRV_MIIM_OperationResult Gets the result of a client operation initiated by the MIIM driver.
DRV_MIIM_Read Initiates a SMI/MIIM read transaction.
DRV_MIIM_RegisterCallback Registers an notification callback function for the client operations.
DRV_MIIM_Reinitialize Reinitializes the driver and refreshes any associated hardware settings.
DRV_MIIM_Scan Initiates a SMI/MIIM scan (periodic read)transaction.
DRV_MIIM_Setup Sets up a MIIM client.
DRV_MIIM_Status Provides the current status of the MIIM driver module.
DRV_MIIM_Tasks Maintains the driver's state machine.
DRV_MIIM_Write Initiates a SMI/MIIM write transaction.
b) Data Types and Constants
Name Description
DRV_MIIM_INIT Contains all the data necessary to initialize the MIIM device.
DRV_MIIM_OBJECT_BASE Declaration of a MIIM base object.
DRV_MIIM_CALLBACK_HANDLE Handle that identifies a client registration operation.
DRV_MIIM_CLIENT_STATUS Defines the possible results of operations that can succeed or fail
DRV_MIIM_OPERATION_CALLBACK Notification function that will be called when a MIIM operation is completed and the driver
client needs to be notified.
DRV_MIIM_OPERATION_FLAGS List of flags that apply to a client operation.
DRV_MIIM_OPERATION_HANDLE MIIM operation handle.
DRV_MIIM_SETUP Contains all the data necessary to set up the MIIM device.
DRV_MIIM_SETUP_FLAGS List of flags that apply to a client setup operation.
DRV_MIIM_OBJECT_BASE_Default The supported basic MIIM driver (DRV_MIIM_OBJECT_BASE). This object is implemented
by default as using the standard MIIM interface. It can be overwritten dynamically when
needed.
Volume V: MPLAB Harmony Framework Driver Libraries Help MIIM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 622
a) Functions
DRV_MIIM_ClientStatus Function
Gets the current client-specific status the MIIM driver.
File
drv_miim.h
C
DRV_MIIM_CLIENT_STATUS DRV_MIIM_ClientStatus(DRV_HANDLE handle);
Returns
• DRV_MIIM_CLIENT_STATUS_READY - if the client handle represents a valid MIIM client
• DRV_MIIM_CLIENT_STATUS_ERROR - if the client handle is an invalid MIIM client
Description
This function gets the client-specific status of the MIIM driver associated with the given handle.
Remarks
This function can be used to check that a client handle points to a valid MIIM client. The MIIM driver queues operations so it will always return
DRV_MIIM_CLIENT_STATUS_READY.
Preconditions
• The DRV_MIIM_Initialize routine must have been called.
• DRV_MIIM_Open must have been called to obtain a valid opened device handle.
Example
Function
DRV_MIIM_CLIENT_STATUS DRV_MIIM_ClientStatus(DRV_HANDLE handle )
DRV_MIIM_Close Function
Closes an opened instance of the MIIM driver.
File
drv_miim.h
C
void DRV_MIIM_Close(DRV_HANDLE handle);
Returns
None
Description
This function closes an opened instance of the MIIM driver, invalidating the handle.
Remarks
• After calling this routine, the handle passed in "handle" must not be used with any of the remaining driver routines. A new handle must be
obtained by calling DRV_MIIM_Open before the caller may use the driver again.
• Usually there is no need for the driver client to verify that the Close operation has completed.
Preconditions
The DRV_MIIM_Initialize routine must have been called for the specified MIIM driver instance.
DRV_MIIM_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE handle; // Returned from DRV_MIIM_Open
Volume V: MPLAB Harmony Framework Driver Libraries Help MIIM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 623
DRV_MIIM_Close(handle);
Function
void DRV_MIIM_Close( DRV_HANDLE handle )
DRV_MIIM_Deinitialize Function
Deinitializes the specified instance of the MIIM driver module.
File
drv_miim.h
C
void DRV_MIIM_Deinitialize(SYS_MODULE_OBJ object);
Returns
None.
Description
This function deinitializes the specified instance of the MIIM driver module, disabling its operation (and any hardware)and invalidates all of the
internal data.
Remarks
• Once the Initialize operation has been called, the Deinitialize operation must be called before the Initialize operation can be called again.
Preconditions
The DRV_MIIM_Initialize function must have been called before calling this routine and a valid SYS_MODULE_OBJ must have been returned.
Example
Function
void DRV_MIIM_Deinitialize (SYS_MODULE_OBJ object )
DRV_MIIM_DeregisterCallback Function
Deregisters an notification callback function for the client operations.
File
drv_miim.h
C
DRV_MIIM_RESULT DRV_MIIM_DeregisterCallback(DRV_HANDLE handle, DRV_MIIM_CALLBACK_HANDLE cbHandle);
Returns
• DRV_MIIM_RES_OK if the operation succeeded.
• an error code otherwise
Description
This function deregisters a previously registered client notification callback function.
Remarks
There is only one notification callback function available per client. To register a new callback function use DRV_MIIM_DeregisterCallback first.
Preconditions
• The DRV_MIIM_Initialize routine must have been called.
• DRV_MIIM_Open must have been called to obtain a valid opened device handle.
Example
Function
DRV_MIIM_RESULT DRV_MIIM_DeregisterCallback( DRV_HANDLE handle, DRV_MIIM_CALLBACK_HANDLE cbHandle);
Volume V: MPLAB Harmony Framework Driver Libraries Help MIIM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 624
DRV_MIIM_Initialize Function
Initializes the MIIM driver.
File
drv_miim.h
C
SYS_MODULE_OBJ DRV_MIIM_Initialize(const SYS_MODULE_INDEX index, const SYS_MODULE_INIT * const init);
Returns
• a valid handle to a driver object, if successful.
• SYS_MODULE_OBJ_INVALID if initialization failed.
Description
This function initializes the MIIM driver, making it ready for clients to open and use it.
Remarks
• This function must be called before any other MIIM routine is called.
• This function should only be called once during system initialization unless DRV_MIIM_Deinitialize is called to deinitialize the driver instance.
• The returned object must be passed as argument to DRV_MIIM_Reinitialize, DRV_MIIM_Deinitialize, DRV_MIIM_Tasks and
DRV_MIIM_Status routines.
Preconditions
None.
Example
Function
SYS_MODULE_OBJ DRV_MIIM_Initialize(const SYS_MODULE_INDEX index, const SYS_MODULE_INIT * const init )
DRV_MIIM_Open Function
Opens the specified MIIM driver instance and returns a handle to it.
File
drv_miim.h
C
DRV_HANDLE DRV_MIIM_Open(const SYS_MODULE_INDEX drvIndex, const DRV_IO_INTENT intent);
Returns
• valid open-instance handle if successful (a number identifying both the caller and the module instance).
• DRV_HANDLE_INVALID if an error occurs
Description
This function opens the specified MIIM driver instance and provides a handle that must be provided to all other client-level operations to identify
the caller and the instance of the driver.
Remarks
The handle returned is valid until the DRV_MIIM_Close routine is called.
This function will NEVER block waiting for hardware.
Preconditions
The DRV_MIIM_Initialize function must have been called before calling this function.
Example
DRV_HANDLE handle;
handle = DRV_MIIM_Open(DRV_MIIM_INDEX_0, 0);
if (DRV_HANDLE_INVALID == handle)
Volume V: MPLAB Harmony Framework Driver Libraries Help MIIM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 625
{
// Unable to open the driver
}
Function
DRV_HANDLE DRV_MIIM_Open(const SYS_MODULE_INDEX drvIndex, const DRV_IO_INTENT intent )
DRV_MIIM_OperationAbort Function
Aborts a current client operation initiated by the MIIM driver.
File
drv_miim.h
C
DRV_MIIM_RESULT DRV_MIIM_OperationAbort(DRV_HANDLE handle, DRV_MIIM_OPERATION_HANDLE opHandle);
Returns
DRV_MIIM_RES_OK for success; operation has been aborted
< 0 - an error has occurred and the operation could not be completed
Description
Aborts a current client operation initiated by the MIIM driver.
Remarks
This operation will stop/abort a scan operation started by DRV_MIIM_Scan.
Preconditions
• The DRV_MIIM_Initialize routine must have been called.
• DRV_MIIM_Open must have been called to obtain a valid opened device handle.
• A driver operation was started
Example
Function
DRV_MIIM_RESULT DRV_MIIM_OperationAbort( DRV_HANDLE handle, DRV_MIIM_OPERATION_HANDLE opHandle)
DRV_MIIM_OperationResult Function
Gets the result of a client operation initiated by the MIIM driver.
File
drv_miim.h
C
DRV_MIIM_RESULT DRV_MIIM_OperationResult(DRV_HANDLE handle, DRV_MIIM_OPERATION_HANDLE opHandle, uint16_t*
pOpData);
Returns
• DRV_MIIM_RESULT value describing the current operation result: DRV_MIIM_RES_OK for success; operation has been completed
successfully and pOpData updated DRV_MIIM_RES_PENDING operation is in progress an DRV_MIIM_RESULT error code if the operation
failed.
Description
Returns the result of a client operation initiated by the MIIM driver.
Remarks
This function will not block for hardware access and will immediately return the current status.
This function returns the result of the last driver operation. It will return DRV_MIIM_RES_PENDING if an operation is still in progress. Otherwise a
DRV_MIIM_RESULT describing the operation outcome.
Note that for a scan operation DRV_MIIM_RES_PENDING will be returned when there's no new scan data available. DRV_MIIM_RES_OK means
the scan data is fresh.
Volume V: MPLAB Harmony Framework Driver Libraries Help MIIM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 626
Preconditions
• The DRV_MIIM_Initialize routine must have been called.
• DRV_MIIM_Open must have been called to obtain a valid opened device handle.
• A driver operation was started
Example
Function
DRV_MIIM_RESULT DRV_MIIM_OperationResult( DRV_HANDLE handle, DRV_MIIM_OPERATION_HANDLE opHandle, uint16_t* pOpData)
DRV_MIIM_Read Function
Initiates a SMI/MIIM read transaction.
File
drv_miim.h
C
DRV_MIIM_OPERATION_HANDLE DRV_MIIM_Read(DRV_HANDLE handle, unsigned int rIx, unsigned int phyAdd,
DRV_MIIM_OPERATION_FLAGS opFlags, DRV_MIIM_RESULT* pOpResult);
Returns
A not NULL DRV_MIIM_OPERATION_HANDLE if the operation was successfully scheduled. NULL if the operation failed. More details in
pOpResult.
Description
This function initiates a SMI/MIIM read transaction for a given MIIM register.
Remarks
If operation was scheduled successfully, the result will be DRV_MIIM_RES_PENDING. Otherwise an error code will be returned.
Upon the operation completion:
• If the operation is to be discarded (DRV_MIIM_OPERATION_FLAG_DISCARD is set) there will be no notification to the client. The operation
associated resources will be released.
• If the operation is not to be discarded, then:
• if the client has registered an operation notification callback (DRV_MIIM_RegisterCallback) then the callback will be called. After that the
operation associated resources will be released.
• if there is no notification callback the MIIM driver will wait for the client to poll and read the operation result using
DRV_MIIM_OperationResult(). Only then the operation will be released.
A completed non-discardable operation will remain available for returning the result until the client is somehow notified of the operation result.
When polling is used, DRV_MIIM_OperationResult() needs to be called to free the operation associated resources.
Preconditions
• The DRV_MIIM_Initialize routine must have been called.
• DRV_MIIM_Open must have been called to obtain a valid opened device handle.
Example
Function
DRV_MIIM_OPERATION_HANDLE DRV_MIIM_Read(DRV_HANDLE handle, unsigned int rIx, unsigned int phyAdd,
DRV_MIIM_OPERATION_FLAGS opFlags, DRV_MIIM_RESULT* pOpResult);
DRV_MIIM_RegisterCallback Function
Registers an notification callback function for the client operations.
File
drv_miim.h
Volume V: MPLAB Harmony Framework Driver Libraries Help MIIM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 627
C
DRV_MIIM_CALLBACK_HANDLE DRV_MIIM_RegisterCallback(DRV_HANDLE handle, DRV_MIIM_OPERATION_CALLBACK
cbFunction, DRV_MIIM_RESULT* pRegResult);
Returns
• a valid DRV_MIIM_CALLBACK_HANDLE if the operation succeeded.
• NULL otherwise
Description
This function registers a client callback function. The function will be called by the MIIM driver when a scheduled operation is completed.
Remarks
There is only one notification callback function available per client. To register a new callback function use DRV_MIIM_DeregisterCallback first.
Preconditions
• The DRV_MIIM_Initialize routine must have been called.
• DRV_MIIM_Open must have been called to obtain a valid opened device handle.
Example
Function
DRV_MIIM_CALLBACK_HANDLE DRV_MIIM_RegisterCallback(DRV_HANDLE handle, DRV_MIIM_OPERATION_CALLBACK cbFunction,
DRV_MIIM_RESULT* pRegResult);
DRV_MIIM_Reinitialize Function
Reinitializes the driver and refreshes any associated hardware settings.
File
drv_miim.h
C
void DRV_MIIM_Reinitialize(SYS_MODULE_OBJ object, const SYS_MODULE_INIT * const init);
Returns
None.
Description
This function reinitializes the driver and refreshes any associated hardware settings using the initialization data given, but it will not interrupt any
ongoing operations.
Remarks
• This function can be called multiple times to reinitialize the module.
• This operation can be used to refresh any supported hardware registers as specified by the initialization data or to change the power state of
the module.
• This function is currently NOT IMPLEMENTED.
Preconditions
The DRV_MIIM_Initialize function must have been called before calling this routine and a valid SYS_MODULE_OBJ must have been returned.
Example
Function
void DRV_MIIM_Reinitialize(SYS_MODULE_OBJ object, const SYS_MODULE_INIT * const init )
DRV_MIIM_Scan Function
Initiates a SMI/MIIM scan (periodic read)transaction.
Volume V: MPLAB Harmony Framework Driver Libraries Help MIIM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 628
File
drv_miim.h
C
DRV_MIIM_OPERATION_HANDLE DRV_MIIM_Scan(DRV_HANDLE handle, unsigned int rIx, unsigned int phyAdd,
DRV_MIIM_OPERATION_FLAGS opFlags, DRV_MIIM_RESULT* pOpResult);
Returns
A not NULL DRV_MIIM_OPERATION_HANDLE if the operation was successfully scheduled. NULL if the operation failed. More details in
pOpResult.
Description
This function initiates a SMI/MIIM scan transaction for a given MIIM register.
Remarks
If operation was scheduled successfully, the result will be DRV_MIIM_RES_PENDING. Otherwise an error code will be returned.
When a new scan result is available:
• If the operation is to be discarded (DRV_MIIM_OPERATION_FLAG_DISCARD is set) there will be no notification to the client.
• If the operation is not to be discarded, then:
• if the client has registered an operation notification callback (DRV_MIIM_RegisterCallback) then the notification callback will be called.
• if there is no notification callback the MIIM driver will wait for the client to poll and read the operation result using
DRV_MIIM_OperationResult(). Only then the operation will be released.
A scheduled scan operation will remain active in the background and will be available for returning the scan results. When polling is used,
DRV_MIIM_OperationResult()will return the latest scan result. The operation associated resources will be released and scan stopped only when
DRV_MIIM_OperationAbort() is called.
While scan is active all other transactions (including from other clients) will be inhibited! Use carefully!
Preconditions
• The DRV_MIIM_Initialize routine must have been called.
• DRV_MIIM_Open must have been called to obtain a valid opened device handle.
Example
Function
DRV_MIIM_OPERATION_HANDLE DRV_MIIM_Scan(DRV_HANDLE handle, unsigned int rIx, unsigned int phyAdd,
DRV_MIIM_OPERATION_FLAGS opFlags, DRV_MIIM_RESULT* pOpResult);
DRV_MIIM_Setup Function
Sets up a MIIM client.
File
drv_miim.h
C
DRV_MIIM_RESULT DRV_MIIM_Setup(DRV_HANDLE handle, const DRV_MIIM_SETUP* pSetUp);
Returns
• DRV_MIIM_RES_OK if the setup operation has been performed successfully
• an DRV_MIIM_RESULT error code if the set up procedure failed.
Description
This function performs the set up of a MIIM client. It programs the MIIM operation using the supplied frequencies.
Remarks
None.
Preconditions
• The DRV_MIIM_Initialize routine must have been called.
Volume V: MPLAB Harmony Framework Driver Libraries Help MIIM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 629
• DRV_MIIM_Open must have been called to obtain a valid device handle.
Example
Function
DRV_MIIM_RESULT DRV_MIIM_Setup( DRV_HANDLE handle, const DRV_MIIM_SETUP* pSetUp)
DRV_MIIM_Status Function
Provides the current status of the MIIM driver module.
File
drv_miim.h
C
SYS_STATUS DRV_MIIM_Status(SYS_MODULE_OBJ object);
Returns
• SYS_STATUS_READY - Indicates that any previous module operation for the specified module has completed
• SYS_STATUS_BUSY - Indicates that a previous module operation for the specified module has not yet completed
• SYS_STATUS_ERROR - Indicates that the specified module is in an error state
Description
This function provides the current status of the MIIM driver module.
Remarks
• Any value greater than SYS_STATUS_READY is also a normal running state in which the driver is ready to accept new operations.
• SYS_STATUS_BUSY - Indicates that the driver is busy with a previous system level operation and cannot start another
• SYS_STATUS_ERROR - Indicates that the driver is in an error state
• Any value less than SYS_STATUS_ERROR is also an error state.
• SYS_MODULE_DEINITIALIZED - Indicates that the driver has been deinitialized
• If the status operation returns SYS_STATUS_BUSY, the a previous system level operation has not yet completed. Once the status operation
returns SYS_STATUS_READY, any previous operations have completed.
• The value of SYS_STATUS_ERROR is negative (-1). Any value less than that is also an error state.
• This function will NEVER block waiting for hardware.
• If the Status operation returns an error value, the error may be cleared by calling the reinitialize operation. If that fails, the deinitialize operation
will need to be called, followed by the initialize operation to return to normal operations.
Preconditions
The DRV_MIIM_Initialize function must have been called before calling this function.
Example
SYS_MODULE_OBJ object; // Returned from DRV_MIIM_Initialize
SYS_STATUS status;
status = DRV_MIIM_Status(object);
if (SYS_STATUS_ERROR >= status)
{
// Handle error
}
Parameters
Parameters Description
object Driver object handle, returned from DRV_MIIM_Initialize
Function
SYS_STATUS DRV_MIIM_Status (SYS_MODULE_OBJ object )
Volume V: MPLAB Harmony Framework Driver Libraries Help MIIM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 630
DRV_MIIM_Tasks Function
Maintains the driver's state machine.
File
drv_miim.h
C
void DRV_MIIM_Tasks(SYS_MODULE_OBJ object);
Returns
None
Description
This function is used to maintain the driver's internal state machine.
Remarks
• This function is normally not called directly by an application. It is called by the system's Tasks routine (SYS_Tasks)
• This function will never block or access any resources that may cause it to block.
Preconditions
The DRV_MIIM_Initialize routine must have been called for the specified MIIM driver instance.
Example
SYS_MODULE_OBJ object; // Returned from DRV_MIIM_Initialize
while (true)
{
DRV_MIIM_Tasks (object);
// Do other tasks
}
Function
void DRV_MIIM_Tasks(SYS_MODULE_OBJ object )
DRV_MIIM_Write Function
Initiates a SMI/MIIM write transaction.
File
drv_miim.h
C
DRV_MIIM_OPERATION_HANDLE DRV_MIIM_Write(DRV_HANDLE handle, unsigned int rIx, unsigned int phyAdd, uint16_t
wData, DRV_MIIM_OPERATION_FLAGS opFlags, DRV_MIIM_RESULT* pOpResult);
Returns
A not NULL DRV_MIIM_OPERATION_HANDLE if the operation was successfully scheduled. NULL if the operation failed. More details in
pOpResult.
Description
This function initiates a SMI/MIIM write transaction for a given MIIM register.
Remarks
If operation was scheduled successfully, the result will be DRV_MIIM_RES_PENDING. Otherwise an error code will be returned.
Upon the operation completion:
• If the operation is to be discarded (DRV_MIIM_OPERATION_FLAG_DISCARD is set) there will be no notification to the client. The operation
associated resources will be released.
• If the operation is not to be discarded, then:
Volume V: MPLAB Harmony Framework Driver Libraries Help MIIM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 631
• if the client has registered an operation notification callback (DRV_MIIM_RegisterCallback) then the notification callback will be called. After
that the operation associated resources will be released.
• if there is no notification callback the MIIM driver will wait for the client to poll and read the operation result using
DRV_MIIM_OperationResult(). Only then the operation will be released.
A completed non-discardable operation will remain available for returning the result until the client is somehow notified of the operation result.
When polling is used, DRV_MIIM_OperationResult() needs to be called to free the operation associated resources.
A write operation normally uses DRV_MIIM_OPERATION_FLAG_DISCARD if it is not interested when the operation has completed.
Preconditions
• The DRV_MIIM_Initialize routine must have been called.
• DRV_MIIM_Open must have been called to obtain a valid opened device handle.
Example
Function
DRV_MIIM_OPERATION_HANDLE DRV_MIIM_Write(DRV_HANDLE handle, unsigned int rIx, unsigned int phyAdd, uint16_t wData,
DRV_MIIM_OPERATION_FLAGS opFlags, DRV_MIIM_RESULT* pOpResult);
b) Data Types and Constants
DRV_MIIM_INIT Structure
Contains all the data necessary to initialize the MIIM device.
File
drv_miim.h
C
struct DRV_MIIM_INIT {
SYS_MODULE_INIT moduleInit;
uintptr_t ethphyId;
};
Members
Members Description
SYS_MODULE_INIT moduleInit; System module initialization
uintptr_t ethphyId; Identifies peripheral (PLIB-level) ID
Description
MIIM Device Driver Initialization Data
This data structure contains all the data necessary to initialize the MIIM device.
Remarks
A pointer to a structure of this format containing the desired initialization data must be passed into the DRV_MIIM_Initialize routine.
DRV_MIIM_OBJECT_BASE Structure
Declaration of a MIIM base object.
File
drv_miim.h
C
struct DRV_MIIM_OBJECT_BASE {
SYS_MODULE_OBJ (* DRV_MIIM_Initialize)(const SYS_MODULE_INDEX index, const SYS_MODULE_INIT * const init);
void (* DRV_MIIM_Reinitialize)(SYS_MODULE_OBJ object, const SYS_MODULE_INIT * const init);
void (* DRV_MIIM_Deinitialize)(SYS_MODULE_OBJ object);
SYS_STATUS (* DRV_MIIM_Status)(SYS_MODULE_OBJ object);
void (* DRV_MIIM_Tasks)(SYS_MODULE_OBJ object);
DRV_HANDLE (* DRV_MIIM_Open)(const SYS_MODULE_INDEX drvIndex, const DRV_IO_INTENT intent);
DRV_MIIM_RESULT (* DRV_MIIM_Setup)(DRV_HANDLE handle, const DRV_MIIM_SETUP* pSetUp);
void (* DRV_MIIM_Close)(DRV_HANDLE handle);
Volume V: MPLAB Harmony Framework Driver Libraries Help MIIM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 632
DRV_MIIM_CLIENT_STATUS (* DRV_MIIM_ClientStatus)(DRV_HANDLE handle);
DRV_MIIM_CALLBACK_HANDLE (* DRV_MIIM_RegisterCallback)(DRV_HANDLE handle, DRV_MIIM_OPERATION_CALLBACK
cbFunction, DRV_MIIM_RESULT* pRegResult);
DRV_MIIM_RESULT (* DRV_MIIM_DeregisterCallback)(DRV_HANDLE handle, DRV_MIIM_CALLBACK_HANDLE cbHandle);
DRV_MIIM_OPERATION_HANDLE (* DRV_MIIM_Read)(DRV_HANDLE handle, unsigned int rIx, unsigned int phyAdd,
DRV_MIIM_OPERATION_FLAGS opFlags, DRV_MIIM_RESULT* pOpResult);
DRV_MIIM_OPERATION_HANDLE (* DRV_MIIM_Write)(DRV_HANDLE handle, unsigned int rIx, unsigned int phyAdd,
uint16_t wData, DRV_MIIM_OPERATION_FLAGS opFlags, DRV_MIIM_RESULT* pOpResult);
DRV_MIIM_OPERATION_HANDLE (* DRV_MIIM_Scan)(DRV_HANDLE handle, unsigned int rIx, unsigned int phyAdd,
DRV_MIIM_OPERATION_FLAGS opFlags, DRV_MIIM_RESULT* pOpResult);
DRV_MIIM_RESULT (* DRV_MIIM_OperationResult)(DRV_HANDLE handle, DRV_MIIM_OPERATION_HANDLE opHandle,
uint16_t* pOpData);
DRV_MIIM_RESULT (* DRV_MIIM_OperationAbort)(DRV_HANDLE handle, DRV_MIIM_OPERATION_HANDLE opHandle);
};
Description
MIIM Driver Base Object
This data structure identifies the required basic interface of the MIIM driver. Any dynamic MIIM driver has to export this interface.
Remarks
This object provides the basic MIIM functionality. Any derived driver can override the basic functionality while maintaining the required interface.
DRV_MIIM_CALLBACK_HANDLE Type
Handle that identifies a client registration operation.
File
drv_miim.h
C
typedef const void* DRV_MIIM_CALLBACK_HANDLE;
Description
Type: MIIM Callback Registration handle
A handle that a client obtains when calling DRV_MIIM_RegisterCallback. It can be used to deregister the notification callback:
DRV_MIIM_DeregisterCallback
Remarks
A valid registration handle is not NULL. An invalid registration handle == 0.
DRV_MIIM_CLIENT_STATUS Enumeration
Defines the possible results of operations that can succeed or fail
File
drv_miim.h
C
typedef enum {
DRV_MIIM_CLIENT_STATUS_ERROR,
DRV_MIIM_CLIENT_STATUS_READY
} DRV_MIIM_CLIENT_STATUS;
Members
Members Description
DRV_MIIM_CLIENT_STATUS_ERROR Unspecified error condition. Client does not exist
DRV_MIIM_CLIENT_STATUS_READY Up and running, can accept operations
Description
MIIM Driver Operation Result *
MIIM Driver Operation Result Codes
This enumeration defines the possible results of any of the MIIM driver operations that have the possibility of failing. This result should be checked
to ensure that the operation achieved the desired result.
Volume V: MPLAB Harmony Framework Driver Libraries Help MIIM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 633
DRV_MIIM_OPERATION_CALLBACK Type
Notification function that will be called when a MIIM operation is completed and the driver client needs to be notified.
File
drv_miim.h
C
typedef void (* DRV_MIIM_OPERATION_CALLBACK)(DRV_HANDLE cliHandle, DRV_MIIM_OPERATION_HANDLE opHandle,
DRV_MIIM_RESULT opResult, uint16_t opData);
Description
Type: MIIM Driver Operation Complete Callback
The format of an operation callback notification function registered with the MIIM driver.
Remarks
None.
Parameters
Parameters Description
cliHandle the client handle. This is the handle that identifies the client (obtained with DRV_MIIM_Open)
that initiated the operation.
opHandle the operation handle. This is the handle that identifies the operation (obtained with
DRV_MIIM_Read, DRV_MIIM_Write, etc.)
opResult operation result DRV_MIIM_RES_OK if operation completed successfully, otherwise an error
code
opData operation specific data, only if the result is DRV_MIIM_RES_OK For read/scan operation this
is the MIIM read data. For write operation this is that data that was written with MIIM.
DRV_MIIM_OPERATION_FLAGS Enumeration
List of flags that apply to a client operation.
File
drv_miim.h
C
typedef enum {
DRV_MIIM_OPERATION_FLAG_NONE,
DRV_MIIM_OPERATION_FLAG_DISCARD
} DRV_MIIM_OPERATION_FLAGS;
Members
Members Description
DRV_MIIM_OPERATION_FLAG_NONE No flag specified
DRV_MIIM_OPERATION_FLAG_DISCARD Upon completion discard the operation result. The client will not poll to check the result nor
will need notification This allows dummy operations, discarded as they complete
Description
MIIM Driver Operation flags
This enumeration identifies the operation-specific flags supported by the MIIM driver.
Remarks
Currently only 8 bit flags are supported.
Multiple flags can be simultaneously set.
DRV_MIIM_OPERATION_HANDLE Type
MIIM operation handle.
Volume V: MPLAB Harmony Framework Driver Libraries Help MIIM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 634
File
drv_miim.h
C
typedef const void* DRV_MIIM_OPERATION_HANDLE;
Description
Type: DRV_MIIM_OPERATION_HANDLE
A handle that identifies an operation started by a client. This handle can be used by the client to query the operation status, result, etc. It is also
used when the operation complete notification occurs.
Remarks
A valid operation handle is not NULL. An invalid operation handle == 0.
DRV_MIIM_SETUP Structure
Contains all the data necessary to set up the MIIM device.
File
drv_miim.h
C
typedef struct {
uint32_t hostClockFreq;
uint32_t maxBusFreq;
DRV_MIIM_SETUP_FLAGS setupFlags;
} DRV_MIIM_SETUP;
Members
Members Description
uint32_t hostClockFreq; The clock frequency on which this MIIM module operates on, Hz
uint32_t maxBusFreq; The MIIM bus maximum supported frequency, Hz This is a maximum value. The actual
generated value may differ.
DRV_MIIM_SETUP_FLAGS setupFlags; Setup flags
Description
MIIM Device Driver Set up Data
This data structure contains all the data necessary to configure the MIIM device.
Remarks
A pointer to a structure of this format containing the desired initialization data must be passed into the DRV_MIIM_Setup routine.
DRV_MIIM_SETUP_FLAGS Enumeration
List of flags that apply to a client setup operation.
File
drv_miim.h
C
typedef enum {
DRV_MIIM_SETUP_FLAG_NONE,
DRV_MIIM_SETUP_FLAG_PREAMBLE_SUPPRESSED,
DRV_MIIM_SETUP_FLAG_PREAMBLE_DEFAULT,
DRV_MIIM_SETUP_FLAG_SCAN_ADDRESS_INCREMENT,
DRV_MIIM_SETUP_FLAG_SCAN_ADDRESS_DEFAULT
} DRV_MIIM_SETUP_FLAGS;
Members
Members Description
DRV_MIIM_SETUP_FLAG_NONE No flag specified. Default value
Volume V: MPLAB Harmony Framework Driver Libraries Help MIIM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 635
DRV_MIIM_SETUP_FLAG_PREAMBLE_SUPPRESSED Suppress the normal 32 bit MIIM preamble field. Some PHYs support suppressed
preamble
DRV_MIIM_SETUP_FLAG_PREAMBLE_DEFAULT Include the 32 bit MIIM preamble field. Default operation.
DRV_MIIM_SETUP_FLAG_SCAN_ADDRESS_INCREMENT Scan operation will read across a range of PHY addresses Scan will start with
address 1 through the address set in the scan operation
DRV_MIIM_SETUP_FLAG_SCAN_ADDRESS_DEFAULT Scan operation will read just one PHY address. Default operation.
Description
MIIM Driver Set up flags
This enumeration identifies the setup specific flags supported by the MIIM driver.
Remarks
Multiple flags can be simultaneously set.
DRV_MIIM_OBJECT_BASE_Default Variable
File
drv_miim.h
C
const DRV_MIIM_OBJECT_BASE DRV_MIIM_OBJECT_BASE_Default;
Description
The supported basic MIIM driver (DRV_MIIM_OBJECT_BASE). This object is implemented by default as using the standard MIIM interface. It can
be overwritten dynamically when needed.
Files
Files
Name Description
drv_miim.h MIIM Device Driver Interface File
drv_miim_config.h MIIM driver configuration definitions template.
Description
This section lists the source and header files used by the Media Interface Independent Management (MIIM)Driver Library.
drv_miim.h
MIIM Device Driver Interface File
Enumerations
Name Description
DRV_MIIM_CLIENT_STATUS Defines the possible results of operations that can succeed or fail
DRV_MIIM_OPERATION_FLAGS List of flags that apply to a client operation.
DRV_MIIM_SETUP_FLAGS List of flags that apply to a client setup operation.
Functions
Name Description
DRV_MIIM_ClientStatus Gets the current client-specific status the MIIM driver.
DRV_MIIM_Close Closes an opened instance of the MIIM driver.
DRV_MIIM_Deinitialize Deinitializes the specified instance of the MIIM driver module.
DRV_MIIM_DeregisterCallback Deregisters an notification callback function for the client operations.
DRV_MIIM_Initialize Initializes the MIIM driver.
DRV_MIIM_Open Opens the specified MIIM driver instance and returns a handle to it.
DRV_MIIM_OperationAbort Aborts a current client operation initiated by the MIIM driver.
DRV_MIIM_OperationResult Gets the result of a client operation initiated by the MIIM driver.
DRV_MIIM_Read Initiates a SMI/MIIM read transaction.
Volume V: MPLAB Harmony Framework Driver Libraries Help MIIM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 636
DRV_MIIM_RegisterCallback Registers an notification callback function for the client operations.
DRV_MIIM_Reinitialize Reinitializes the driver and refreshes any associated hardware settings.
DRV_MIIM_Scan Initiates a SMI/MIIM scan (periodic read)transaction.
DRV_MIIM_Setup Sets up a MIIM client.
DRV_MIIM_Status Provides the current status of the MIIM driver module.
DRV_MIIM_Tasks Maintains the driver's state machine.
DRV_MIIM_Write Initiates a SMI/MIIM write transaction.
Macros
Name Description
DRV_MIIM_INDEX_0 MIIM driver index definitions.
DRV_MIIM_INDEX_COUNT Number of valid MIIM driver indices.
Structures
Name Description
DRV_MIIM_INIT Contains all the data necessary to initialize the MIIM device.
DRV_MIIM_OBJECT_BASE Declaration of a MIIM base object.
DRV_MIIM_SETUP Contains all the data necessary to set up the MIIM device.
Types
Name Description
DRV_MIIM_CALLBACK_HANDLE Handle that identifies a client registration operation.
DRV_MIIM_OPERATION_CALLBACK Notification function that will be called when a MIIM operation is completed and the driver
client needs to be notified.
DRV_MIIM_OPERATION_HANDLE MIIM operation handle.
Variables
Name Description
DRV_MIIM_OBJECT_BASE_Default The supported basic MIIM driver (DRV_MIIM_OBJECT_BASE). This object is implemented
by default as using the standard MIIM interface. It can be overwritten dynamically when
needed.
Description
MIIM Device Driver Interface
The MIIM device driver provides a simple interface to manage an MIIM peripheral using MIIM (SMI)interface. This file defines the interface
definitions and prototypes for the MIIM driver.
File Name
drv_miim.h
Company
Microchip Technology Inc.
drv_miim_config.h
MIIM driver configuration definitions template.
Macros
Name Description
_DRV_MIIM_CONFIG_H This is macro _DRV_MIIM_CONFIG_H.
DRV_MIIM_CLIENT_OP_PROTECTION Enables/Disables Client Operation Protection feature.
DRV_MIIM_COMMANDS Enables/Disables MIIM commands feature.
DRV_MIIM_INSTANCE_CLIENTS Selects the maximum number of clients.
DRV_MIIM_INSTANCE_OPERATIONS Selects the maximum number of simultaneous operations for an instance.
DRV_MIIM_INSTANCES_NUMBER Selects the maximum number of hardware instances that can be supported by the
dynamic driver.
Volume V: MPLAB Harmony Framework Driver Libraries Help MIIM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 637
Description
MIIM Driver Configuration Definitions for the Template Version
These definitions statically define the driver's mode of operation.
File Name
drv_miim_config.h
Company
Microchip Technology Inc.
Motor Control PWM (MCPWM) Driver Library
This section describes the MCPWM Driver Library.
Introduction
The MCPWM Static Driver provides a high-level interface to manage the MCPWM module on the Microchip family of microcontrollers.
Description
Through MHC, this driver provides APIs to initialize, enable, and disable the MCPWM module.
Library Interface
Function(s)
Name Description
DRV_MCPWM_Disable Disables the MCPWM instance for the specified driver index.
Implementation: Static
DRV_MCPWM_Enable Enables the MCPWM instance for the specified driver index.
Implementation: Static
DRV_MCPWM_Initialize Initializes the MCPWM instance for the specified driver index.
Implementation: Static
Description
This section describes the Application Programming Interface (API) functions of the MCPWM Driver Library.
Function(s)
DRV_MCPWM_Disable Function
Disables the MCPWM instance for the specified driver index.
Implementation: Static
File
drv_mcpwm.h
C
void DRV_MCPWM_Disable();
Returns
None.
Description
This routine disables the MCPWM Driver instance for the specified driver instance.
Preconditions
DRV_MCPWM_Initialize has been called.
Volume V: MPLAB Harmony Framework Driver Libraries Help Motor Control PWM (MCPWM) Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 638
Function
void DRV_MCPWM_Disable(void)
DRV_MCPWM_Enable Function
Enables the MCPWM instance for the specified driver index.
Implementation: Static
File
drv_mcpwm.h
C
void DRV_MCPWM_Enable();
Returns
None.
Description
This routine enables the MCPWM Driver instance for the specified driver instance, making it ready for clients to use it. The enable routine is
specified by the MHC parameters.
Preconditions
DRV_MCPWM_Initialize has been called.
Function
void DRV_MCPWM_Enable(void)
DRV_MCPWM_Initialize Function
Initializes the MCPWM instance for the specified driver index.
Implementation: Static
File
drv_mcpwm.h
C
void DRV_MCPWM_Initialize();
Returns
None.
Description
This routine initializes the MCPWM Driver instance for the specified driver instance, making it ready for clients to use it. The initialization routine is
specified by the MHC parameters.
Remarks
This routine must be called before any other MCPWM routine is called. This routine should only be called once during system initialization.
Preconditions
None.
Function
void DRV_MCPWM_Initialize(void)
Files
Files
Name Description
drv_mcpwm.h MCPWM driver interface declarations for the static single instance driver.
Volume V: MPLAB Harmony Framework Driver Libraries Help Motor Control PWM (MCPWM) Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 639
Description
drv_mcpwm.h
MCPWM driver interface declarations for the static single instance driver.
Functions
Name Description
DRV_MCPWM_Disable Disables the MCPWM instance for the specified driver index.
Implementation: Static
DRV_MCPWM_Enable Enables the MCPWM instance for the specified driver index.
Implementation: Static
DRV_MCPWM_Initialize Initializes the MCPWM instance for the specified driver index.
Implementation: Static
Description
Motor Control PWM (MCPWM) Driver Interface Declarations for Static Single Instance Driver
The MCPWM device driver provides a simple interface to manage the MCPWM module on Microchip microcontrollers. This file defines the
interface Declarations for the MCPWM driver.
Remarks
Static interfaces incorporate the driver instance number within the names of the routines, eliminating the need for an object ID or object handle.
Static single-open interfaces also eliminate the need for the open handle.
File Name
drv_mcpwm.h
Company
Microchip Technology Inc.
NVM Driver Library
This section describes the Non-volatile Memory (NVM) Driver Library.
Migrating Applications from v1.03.01 and Earlier Releases of MPLAB Harmony
Provides information on migrating applications from v1.03.01 and earlier releases of MPLAB Harmony to release v1.04 and later.
Description
The NVM Driver Library APIs have changed beginning with the v1.04 release of MPLAB Harmony. Applications that were developed using the
earlier version of the MPLAB Harmony NVM Driver (v1.03.01 and earlier) will not build unless the application calls to NVM Driver are updated.
While the MHC utility provides an option to continue creating applications using the v1.03.01 and earlier NVM Driver API, it is recommended that
existing applications migrate to the latest API to take advantage of the latest features in the NVM Driver. The following sections describe the API
changes and other considerations while updating the application for changes in the NVM Driver.
All NVM Driver Demonstration Applications and NVM Driver related documentation have been updated to the latest (new) API. The following
sections do not discuss changes in the NVM Driver configuration related code. This code is updated automatically when the project is regenerated
using the MHC utility. Only the application related API changes are discussed.
The following table shows the beta API and corresponding v1.04 and Later MPLAB Harmony NVM Driver API.
v1.03.01 and Earlier NVM Driver
API
v1.04 and Later NVM
Driver API
v1.04 and Later API Notes
DRV_NVM_Initialize DRV_NVM_Initialize The init structure now has additional members that allow the NVM media
address and geometry to be specified.
DRV_NVM_Deinitialize DRV_NVM_Deinitialize No change.
DRV_NVM_Status DRV_NVM_Status No change.
DRV_NVM_Open DRV_NVM_Open No change.
DRV_NVM_Close DRV_NVM_Close No change.
Volume V: MPLAB Harmony Framework Driver Libraries Help NVM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 640
DRV_NVM_Read DRV_NVM_Read Parameters have changed:
• Returns the command handle associated with the read operation as an
output parameter
• Data is now read in terms of blocks. The read block size is specified in
the NVM Geometry.
DRV_NVM_Write DRV_NVM_Write Parameters have changed:
• Returns the command handle associated with the write operation as an
output parameter
• Data is now written in terms of blocks. The write block size is specified in
the NVM Geometry.
DRV_NVM_Erase DRV_NVM_Erase Parameters have changed:
• Returns the command handle associated with the erase operation as an
output parameter
• NVM Flash is erased in terms of blocks. The erase block size is
specified in the NVM Geometry.
DRV_NVM_EraseWrite DRV_NVM_EraseWrite Parameters have changed:
• Returns the command handle associated with the Erase/Write operation
as an output parameter.
• Data is now written in terms of blocks. The write block size is specified in
the NVM Geometry.
DRV_NVM_BlockEventHandlerSet DRV_NVM_EventHandlerSet Function name and parameter type have changed.
DRV_NVM_ClientStatus Not Available This API is no longer available.
DRV_NVM_BufferStatus DRV_NVM_CommandStatus The DRV_NVM_Read, DRV_NVM_Write, DRV_NVM_Erase, and
DRV_NVM_EraseWrite functions now return a command handle associated
with the operation. The status of the operation can be checked by passing
the command handle to this function.
Not Available DRV_NVM_GeometryGet This API gives the following geometrical details of the NVM Flash:
• Media Property
• Number of Read/Write/Erase regions in the flash device
• Number of Blocks and their size in each region of the device
Not Available DRV_NVM_IsAttached Returns the physical attach status of the NVM Flash.
Not Available DRV_NVM_IsWriteProtected Returns the write protect status of the NVM Flash.
Not Available DRV_NVM_AddressGet Returns the NVM Media Start address.
NVM Driver Initialization
DRV_NVM_INIT now takes the following two additional initialization parameters:
• mediaStartAddress - NVM Media Start address. The driver treats this address as the start address for read, write and erase operations.
• nvmMediaGeometry - Indicates the layout of the media in terms of read, write and erase regions.
The following code examples show how the driver initialization was performed with 1.03 APIs and how it is performed with the 1.04 APIs:
Example 1: v1.03 and Earlier Code
const DRV_NVM_INIT drvNvmInit =
{
.moduleInit.sys.powerState = SYS_MODULE_POWER_RUN_FULL,
.nvmID = NVM_ID_0,
.interruptSource = INT_SOURCE_FLASH_CONTROL,
};
void SYS_Initialize (void *data)
{
.
.
// Initialize NVM Driver Layer
sysObj.drvNvm = DRV_NVM_Initialize(DRV_NVM_INDEX_0, (SYS_MODULE_INIT *)&drvNvmInit);
.
}
Example: v1.04 and Later Code
/* NVM Geometry structure */
SYS_FS_MEDIA_REGION_GEOMETRY NVMGeometryTable[3] =
{
{
.blockSize = 1,
Volume V: MPLAB Harmony Framework Driver Libraries Help NVM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 641
.numBlocks = (DRV_NVM_MEDIA_SIZE * 1024),
},
{
.blockSize = DRV_NVM_ROW_SIZE,
.numBlocks = ((DRV_NVM_MEDIA_SIZE * 1024)/DRV_NVM_ROW_SIZE)
},
{
.blockSize = DRV_NVM_PAGE_SIZE,
.numBlocks = ((DRV_NVM_MEDIA_SIZE * 1024)/DRV_NVM_PAGE_SIZE)
}
};
const SYS_FS_MEDIA_GEOMETRY NVMGeometry =
{
.mediaProperty = SYS_FS_MEDIA_WRITE_IS_BLOCKING,
.numReadRegions = 1,
.numWriteRegions = 1,
.numEraseRegions = 1,
.geometryTable = (SYS_FS_MEDIA_REGION_GEOMETRY *)&NVMGeometryTable
};
const DRV_NVM_INIT drvNvmInit =
{
.moduleInit.sys.powerState = SYS_MODULE_POWER_RUN_FULL,
.nvmID = NVM_ID_0,
.interruptSource = INT_SOURCE_FLASH_CONTROL,
.mediaStartAddress = 0x9D010000,
.nvmMediaGeometry = (SYS_FS_MEDIA_GEOMETRY *)&NVMGeometry
};
void SYS_Initialize (void *data)
{
.
.
// Initialize NVM Driver Layer
sysObj.drvNvm = DRV_NVM_Initialize(DRV_NVM_INDEX_0, (SYS_MODULE_INIT *)&drvNvmInit);
.
.
}
Addressing in NVM Driver
The v1.03.01 and earlier Read, Write, Erase and EraseWrite APIs took the actual address on which the operation was to be performed. The unit of
access was bytes.
In v1.04 the addressing mechanism has been modified. The media start address is set in the DRV_NVM_Initialize. This address is used as the
base address for the Read, Write, Erase and EraseWrite APIs. The unit of access is in terms of blocks. The NVM Geometry specifies the media
layout in terms of:
• Number of erase, read and write regions
• Block size for erase, read and write operations.
• Number of blocks in erase, read and write regions
For example, in PIC32MZ family devices:
• Read block size = 1 byte
• Write block size = ROW Size = 2048 bytes
• Erase block size = PAGE Size = 16384 bytes
If the size of media is 32 KB then the following table illustrates the address range and number of blocks for the read, write and erase regions:
Region Type Block Size Number of blocks Address range
Read Region 1 Byte 32 KB / Read block size = 32768 0–32767
Write Region 2048 Bytes 32 KB / Write block size = 16 blocks 0–15
Erase Region 16384 Bytes 32 KB / Erase block size = 2 blocks 0–1
Erasing Data on NVM Flash
The NVM Geometry indicates the number of erase blocks and the size of a single erase block. The Erase API takes in the erase block start
address and the number of blocks to be erased. The following code examples show how to perform the erase operation in v1.03.01 and earlier
and how to perform it with v1.04 and later.
Volume V: MPLAB Harmony Framework Driver Libraries Help NVM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 642
Example: v1.03.01 and Earlier Code
DRV_HANDLE myNVMHandle; // Returned from DRV_NVM_Open
DRV_NVM_BUFFER_HANDLE bufferHandle;
bufferHandle = DRV_NVM_Erase(myNVMHandle, (uint8_t*)NVM_BASE_ADDRESS, DRV_NVM_PAGE_SIZE);
if(DRV_NVM_BUFFER_HANDLE_INVALID == bufferHandle)
{
// Do error handling here
}
// Wait until the buffer completes. This should not
// be a while loop if a part of cooperative multi-tasking
// routine. In that case, it should be invoked in task
// state machine.
while(DRV_NVM_BufferStatus(bufferHandle) != DRV_NVM_BUFFER_COMPLETED);
Example: v1.04 and Later Code
/* This code example shows how to erase NVM Media data */
DRV_HANDLE nvmHandle;
DRV_NVM_COMMAND_HANDLE nvmCommandHandle;
DRV_NVM_COMMAND_STATUS commandStatus;
uint32_t blockAddress;
uint32_t nBlocks;
blockAddress = 0;
nBlocks = 1;
DRV_NVM_Erase(nvmHandle, &nvmCommandHandle, blockAddress, nBlocks);
if(DRV_NVM_COMMAND_HANDLE_INVALID == nvmCommandHandle)
{
/* Failed to queue the erase request. Handle the error. */
}
// Wait until the command completes. This should not
// be a while loop if a part of cooperative multi-tasking
// routine. In that case, it should be invoked in task
// state machine.
commandStatus = DRV_NVM_CommandStatus(nvmHandle, nvmCommandHandle);
if(DRV_NVM_COMMAND_COMPLETED == commandStatus)
{
/* Erase completed */
}
else if (DRV_NVM_COMMAND_ERROR_UNKNOWN == commandStatus)
{
/* Erase Failed */
}
Writing Data to NVM Flash
The NVM Geometry indicates the number of write blocks and the size of a single write block. The Write API takes in the write block start address
and the number of blocks to be written. The following code examples show how the write operation was performed in v1.03.01 and earlier and how
to perform it with v1.04 and later APIs:
Example : v1.03.01 and Earlier Code
DRV_HANDLE myNVMHandle; // Returned from DRV_NVM_Open
char myBuffer[2 * DRV_NVM_ROW_SIZE];
// Destination address should be row aligned.
char *destAddress = (char *)NVM_BASE_ADDRESS_TO_WRITE;
unsigned int count = 2 * MY_BUFFER_SIZE;
DRV_NVM_BUFFER_HANDLE bufferHandle;
bufferHandle = DRV_NVM_Write(myNVMHandle, destAddress, &myBuffer[total], count);
if(DRV_NVM_BUFFER_HANDLE_INVALID == bufferHandle)
{
// Do error handling here
}
// Wait until the buffer completes. This should not
// be a while loop if a part of cooperative multi-tasking
Volume V: MPLAB Harmony Framework Driver Libraries Help NVM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 643
// routine. In that case, it should be invoked in task
// state machine.
while(DRV_NVM_BufferStatus(bufferHandle) != DRV_NVM_BUFFER_COMPLETED);
Example: v1.04 and Later Code
/* This code example shows how to write data to NVM Media */
DRV_HANDLE nvmHandle;
DRV_NVM_COMMAND_HANDLE nvmCommandHandle;
DRV_NVM_COMMAND_STATUS commandStatus;
uint8_t writeBuf[DRV_NVM_ROW_SIZE];
uint32_t blockAddress;
uint32_t nBlocks;
blockAddress = 0;
nBlocks = 1;
DRV_NVM_Write(nvmHandle, &nvmCommandHandle, (uint8_t *)writeBuf, blockAddress, nBlocks);
if(DRV_NVM_COMMAND_HANDLE_INVALID == nvmCommandHandle)
{
/* Failed to queue the write request. Handle the error. */
}
// Wait until the command completes. This should not
// be a while loop if a part of cooperative multi-tasking
// routine. In that case, it should be invoked in task
// state machine.
commandStatus = DRV_NVM_CommandStatus(nvmHandle, nvmCommandHandle);
if(DRV_NVM_COMMAND_COMPLETED == commandStatus)
{
/* Write completed */
}
else if (DRV_NVM_COMMAND_ERROR_UNKNOWN == commandStatus)
{
/* Write Failed */
}
Reading Data from NVM Flash
The NVM Geometry indicates the number of read blocks and the size of a single read block. The Read API takes in the read block start address
and the number of blocks to be read. The following code examples show how the read operation was performed with v1.03.01 and earlier APIs
and how to perform the same with v1.04 and later APIs:
Example: v1.03.01 and Earlier Code
DRV_HANDLE myNVMHandle; // Returned from DRV_NVM_Open
char myBuffer[MY_BUFFER_SIZE];
char *srcAddress = NVM_BASE_ADDRESS_TO_READ_FROM;
unsigned int count = MY_BUFFER_SIZE;
DRV_NVM_BUFFER_HANDLE bufferHandle;
bufferHandle = DRV_NVM_Read(myNVMHandle, &myBuffer[total], srcAddress, count);
if(DRV_NVM_BUFFER_HANDLE_INVALID == bufferHandle)
{
// Do error handling here
}
// Wait until the buffer completes. This should not
// be a while loop if a part of cooperative multi-tasking
// routine. In that case, it should be invoked in task
// state machine.
while(DRV_NVM_BufferStatus(bufferHandle) != DRV_NVM_BUFFER_COMPLETED);
Example: v1.04 and Later Code
/* This code example shows how to read data from NVM Media */
DRV_HANDLE nvmHandle;
DRV_NVM_COMMAND_HANDLE nvmCommandHandle;
DRV_NVM_COMMAND_STATUS commandStatus;
uint8_t readBuf[DRV_NVM_ROW_SIZE];
uint32_t blockAddress;
uint32_t nBlocks;
blockAddress = 0;
Volume V: MPLAB Harmony Framework Driver Libraries Help NVM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 644
nBlocks = DRV_NVM_ROW_SIZE;
DRV_NVM_Read(nvmHandle, &nvmCommandHandle, (uint8_t *)readBuf, blockAddress, nBlocks);
if(DRV_NVM_COMMAND_HANDLE_INVALID == nvmCommandHandle)
{
/* Failed to queue the read request. Handle the error. */
}
// Wait until the command completes. This should not
// be a while loop if a part of cooperative multi-tasking
// routine. In that case, it should be invoked in task
// state machine.
commandStatus = DRV_NVM_CommandStatus(nvmHandle, nvmCommandHandle);
if(DRV_NVM_COMMAND_COMPLETED == commandStatus)
{
/* Read completed */
}
else if (DRV_NVM_COMMAND_ERROR_UNKNOWN == commandStatus)
{
/* Read Failed */
}
Introduction
The NVM Driver library provides APIs that can be used to interface with the NVM module (controller plus memory) for memory needs.
Description
The NVM Driver provides APIs for block access of the physical media through NVM Driver APIs. As shown in the NVM Driver Abstraction Model,
an application or a client can access the physical media using multiple methods, which eventually are facilitated through the NVM Driver.
Memory Devices for PIC Microcontrollers
Depending on the device, there are two primary forms of on-chip memory: Programmable Flash memory and data EEPROM memory. The access
mechanism for both of these types are varied.
Flash Program Memory
The Flash program memory is readable, writeable, and erasable during normal operation over the entire operating voltage range.
A read from program memory is executed at one byte/word at a time depending on the width of the data bus.
A write to the program memory is executed in either blocks of specific sizes or a single word depending on the type of processor used.
An erase is performed in blocks. A bulk erase may be performed from user code depending on the type of processor supporting the operation.
Writing or erasing program memory will cease instruction fetches until the operation is complete, restricting memory access, and therefore
preventing code execution. This is controlled by an internal programming timer.
There are three processor dependant methods for program memory modification:
• Run-Time Self-Programming (RTSP)
• In-Circuit Serial Programming (ICSP)
• EJTAG programming
This section describes the RTSP techniques.
Using the Library
This topic describes the basic architecture of the NVM Driver Library and provides information and examples on its use.
Description
Interface Header Files: drv_nvm.h
The interface to the NVM Driver Library is defined in the drv_nvm.h header file. Any C language source (.c) file that uses the NVM Driver library
should include drv_nvm.h.
Please refer to the What is MPLAB Harmony? section for how the driver interacts with the framework.
Abstraction Model
This library provides a low-level abstraction of the NVM module on the Microchip family of microcontrollers with a convenient C language interface.
This topic describes how that abstraction is modeled in software and introduces the library's interface.
Volume V: MPLAB Harmony Framework Driver Libraries Help NVM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 645
Description
NVM Driver Abstraction Model
Abstraction Model
As shown in the previous diagram, the NVM Driver sits between the Peripheral Libraries and the application or system layer to facilitate block and
file access to the NVM media (currently Flash). The application scenarios show how different layers can be accessed by different applications with
certain needs. For example, APP1 can access the NVM Driver directly to erase, write, or read NVM with direct addressing. APP2, in this case
TCP/IP, can bypass the system layer and access the NVM Driver layer if necessary to fulfill its robust data needs. Finally, APP3 accesses the
NVM Driver through the File System Layer using block access methods, so the application does not need to keep track of the physical layout of
the media.
Library Overview
Refer to the Driver Library Overview section for information on how the driver operates in a system.
The library interface routines are divided into various sub-sections, which address one of the blocks or the overall operation of the NVM module.
Library Interface Section Description
System Functions Provides system module interfaces, device initialization, deinitialization,
reinitialization, tasks and status functions.
Client Core Functions Provides open, close, status and other setup functions.
Client Block Transfer Functions Provides buffered data operation functions available in the core configuration.
Miscellaneous Functions Provides driver miscellaneous functions related to versions and others.
How the Library Works
The library provides interfaces to support:
• System Functionality
• Client Functionality
• Media Functionality
Volume V: MPLAB Harmony Framework Driver Libraries Help NVM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 646
Note:
Not all modes are available on all devices. Please refer to the specific device data sheet to determine the modes supported for
your device.
NVM System Initialization
This section provides information for system initialization and reinitialization.
Description
The system performs the initialization and the reinitialization of the device driver with settings that affect only the instance of the device that is
being initialized or reinitialized. During system initialization each instance of the NVM module would be initialized with the following configuration
settings (either passed dynamically at run time using DRV_NVM_INIT or by using initialization overrides) that are supported by the specific NVM
device hardware:
• Device requested power state: One of the system module power states. For specific details please refer to Data Types and Constants in the
Library Interface section.
• The actual peripheral ID enumerated as the PLIB level module ID (e.g., NVM_ID_0)
• Defining the respective interrupt sources
• NVM Media Start Address
• NVM Media Geometry
The DRV_NVM_Initialize function returns an object handle of the type SYS_MODULE_OBJ. After this, the object handle returned by the initialize
interface would be used by the other system interfaces, such as DRV_NVM_Deinitialize, DRV_NVM_Status, and DRV_NVM_Tasks.
Note:
The system initialization and the reinitialization settings, only affect the instance of the peripheral that is being initialized or
reinitialized.
The SYS_MODULE_INDEX is passed to the DRV_NVM_Initialize function to determine which type of memory is selected using:
DRV_NVM_INDEX_0 - FLASH
Example:
const DRV_NVM_INIT drvNvmInit =
{
.moduleInit.sys.powerState = SYS_MODULE_POWER_RUN_FULL,
.nvmID = NVM_ID_0,
.interruptSource = INT_SOURCE_FLASH_CONTROL,
.mediaStartAddress = 0x9D010000,
.nvmMediaGeometry = (SYS_FS_MEDIA_GEOMETRY *)&NVMGeometry
};
void SYS_Initialize (void *data)
{
.
.
.
// Initialize NVM Driver Layer
sysObj.drvNvm = DRV_NVM_Initialize(DRV_NVM_INDEX_0, (SYS_MODULE_INIT *)&drvNvmInit);
.
.
.
}
Tasks Routine
The system will call DRV_NVM_Tasks, from system task service (in a polled environment) or DRV_NVM_Tasks will be called from the Interrupt
Service Routine (ISR) of the NVM.
Client Access Operation
This section provides information for general client operation.
Description
General Client Operation
For the application to start using an instance of the module, it must call the DRV_NVM_Open function. This provides the configuration required to
open the NVM instance for operation. If the driver is deinitialized using the function DRV_NVM_Deinitialize, the application must call the
DRV_NVM_Open function again to set up the instance of the NVM.
For the various options available for I/O INTENT please refer to Data Types and Constants in the Library Interface section.
Volume V: MPLAB Harmony Framework Driver Libraries Help NVM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 647
Example:
DRV_HANDLE handle;
handle = DRV_NVM_Open(DRV_NVM_INDEX_0, DRV_IO_INTENT_EXCLUSIVE);
if (DRV_HANDLE_INVALID == handle)
{
// Unable to open the driver
}
Client Block Data Operation
This topic provides information on client block data operation.
Description
The NVM Driver provides a block interface to access the NVM media. The interface provides functionality to read, write, erase, and erase-write the
NVM media. These interface functions depend on the block sizes and boundaries of the individual devices. The interfaces are responsible for
keeping this information transparent from the application.
Erasing Data on the NVM:
The following steps outline the sequence for erasing data on the NVM media:
1. The system should have completed necessary initialization and DRV_NVM_Tasks should either be running in a polled environment, or in an
interrupt environment.
2. The driver should have been opened with the necessary intent.
3. Provide the block start address and the number of blocks to be erased and begin the erase process using the DRV_NVM_Erase.
4. The client can check the state of the erase request by invoking the DRV_NVM_CommandStatus and passing the command handle returned by
the erase request.
5. The client will be able to close itself by calling the DRV_NVM_Close.
Example:
// This code shows how to erase NVM Media data
DRV_HANDLE nvmHandle;
DRV_NVM_COMMAND_HANDLE nvmCommandHandle;
DRV_NVM_COMMAND_STATUS commandStatus;
uint32_t blockAddress;
uint32_t nBlocks;
blockAddress = 0;
nBlocks = 1;
DRV_NVM_Erase(nvmHandle, &nvmCommandHandle, blockAddress, nBlocks);
if(DRV_NVM_COMMAND_HANDLE_INVALID == nvmCommandHandle)
{
/* Failed to queue the erase request. Handle the error. */
}
// Wait until the command completes. This should not
// be a while loop if a part of cooperative multi-tasking
// routine. In that case, it should be invoked in task
// state machine.
commandStatus = DRV_NVM_CommandStatus(nvmHandle, nvmCommandHandle);
if(DRV_NVM_COMMAND_COMPLETED == commandStatus)
{
/* Erase completed */
}
else if (DRV_NVM_COMMAND_ERROR_UNKNOWN == commandStatus)
{
/* Erase Failed */
}
Writing Data to the NVM:
The following steps outline the sequence to be followed for writing data to the NVM Media:
1. The system should have completed necessary initialization and DRV_NVM_Tasks should either be running in a polled environment, or in an
interrupt environment.
Volume V: MPLAB Harmony Framework Driver Libraries Help NVM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 648
2. The driver should have been opened with the necessary intent.
3. The client should ensure that blocks of addresses to which write is being performed should be in the erased state.
4. Provide the data to be written, block start address and the number of blocks to be written and begin write using the DRV_NVM_Write.
5. The client can check the state of the write request by invoking the DRV_NVM_CommandStatus and passing the command handle returned by
the write request.
6. The client will be able to close itself by calling the DRV_NVM_Close.
Example:
// This code shows how to write data to NVM Media
DRV_HANDLE nvmHandle;
DRV_NVM_COMMAND_HANDLE nvmCommandHandle;
DRV_NVM_COMMAND_STATUS commandStatus;
uint8_t writeBuf[DRV_NVM_ROW_SIZE];
uint32_t blockAddress;
uint32_t nBlocks;
blockAddress = 0;
nBlocks = 1;
DRV_NVM_Write(nvmHandle, &nvmCommandHandle, (uint8_t *)writeBuf, blockAddress, nBlocks);
if(DRV_NVM_COMMAND_HANDLE_INVALID == nvmCommandHandle)
{
/* Failed to queue the write request. Handle the error. */
}
// Wait until the command completes. This should not
// be a while loop if a part of cooperative multi-tasking
// routine. In that case, it should be invoked in task
// state machine.
commandStatus = DRV_NVM_CommandStatus(nvmHandle, nvmCommandHandle);
if(DRV_NVM_COMMAND_COMPLETED == commandStatus)
{
/* Write completed */
}
else if (DRV_NVM_COMMAND_ERROR_UNKNOWN == commandStatus)
{
/* Write Failed */
}
Reading Data from the NVM:
The following steps outline the sequence to be followed for reading data from the NVM Media:
1. The system should have completed necessary initialization and DRV_NVM_Tasks should either be running in a polled environment, or in an
interrupt environment.
2. The driver should have been opened with the necessary intent.
3. Provide the target buffer, block start address and the number of blocks to be read and begin reading using the DRV_NVM_Read.
4. The client can check the state of the read request by invoking the DRV_NVM_CommandStatus and passing the command handle returned by
the read request.
5. The client will be able to close itself by calling the DRV_NVM_Close.
Example:
// This code shows how to read data from NVM Media
DRV_HANDLE nvmHandle;
DRV_NVM_COMMAND_HANDLE nvmCommandHandle;
DRV_NVM_COMMAND_STATUS commandStatus;
uint8_t readBuf[DRV_NVM_ROW_SIZE];
uint32_t blockAddress;
uint32_t nBlocks;
blockAddress = 0;
nBlocks = DRV_NVM_ROW_SIZE;
DRV_NVM_Read(nvmHandle, &nvmCommandHandle, (uint8_t *)readBuf, blockAddress, nBlocks);
Volume V: MPLAB Harmony Framework Driver Libraries Help NVM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 649
if(DRV_NVM_COMMAND_HANDLE_INVALID == nvmCommandHandle)
{
/* Failed to queue the read request. Handle the error. */
}
// Wait until the command completes. This should not
// be a while loop if a part of cooperative multi-tasking
// routine. In that case, it should be invoked in task
// state machine.
commandStatus = DRV_NVM_CommandStatus(nvmHandle, nvmCommandHandle);
if(DRV_NVM_COMMAND_COMPLETED == commandStatus)
{
/* Read completed */
}
else if (DRV_NVM_COMMAND_ERROR_UNKNOWN == commandStatus)
{
/* Read Failed */
}
Configuring the Library
Macros
Name Description
DRV_NVM_BUFFER_OBJECT_NUMBER Selects the maximum number of buffer objects
DRV_NVM_CLIENTS_NUMBER Selects the maximum number of clients
DRV_NVM_INSTANCES_NUMBER Selects the maximum number of Driver instances that can be supported by the
dynamic driver.
DRV_NVM_INTERRUPT_MODE Macro specifies operation of the driver to be in the interrupt mode or polled mode
DRV_NVM_ROW_SIZE Specifies the NVM Driver Program Row Size in bytes.
DRV_NVM_ERASE_WRITE_ENABLE Enables support for NVM Driver Erase Write Feature.
DRV_NVM_PAGE_SIZE Specifies the NVM Driver Program Page Size in bytes.
DRV_NVM_DISABLE_ERROR_CHECK Disables the error checks in the driver.
DRV_NVM_MEDIA_SIZE Specifies the NVM Media size.
DRV_NVM_MEDIA_START_ADDRESS Specifies the NVM Media start address.
DRV_NVM_SYS_FS_REGISTER Register to use with the File system
Description
The configuration of the NVM Driver is based on the file system_config.h.
This header file contains the configuration selection for the NVM Driver. Based on the selections made, the NVM Driver may support the selected
features. These configuration settings will apply to all instances of the NVM Driver.
This header can be placed anywhere; however, the path of this header needs to be present in the include search path for a successful build. Refer
to the Applications Help section for more details.
DRV_NVM_BUFFER_OBJECT_NUMBER Macro
Selects the maximum number of buffer objects
File
drv_nvm_config_template.h
C
#define DRV_NVM_BUFFER_OBJECT_NUMBER 5
Description
NVM Driver maximum number of buffer objects
This definition selects the maximum number of buffer objects. This indirectly also specifies the queue depth. The NVM Driver can queue up
DRV_NVM_BUFFER_OBJECT_NUMBER of read/write/erase requests before return a DRV_NVM_BUFFER_HANDLE_INVALID due to the
queue being full. Buffer objects are shared by all instances of the driver. Increasing this number increases the RAM requirement of the driver.
Remarks
This macro is mandatory when building the driver for dynamic operation.
Volume V: MPLAB Harmony Framework Driver Libraries Help NVM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 650
DRV_NVM_CLIENTS_NUMBER Macro
Selects the maximum number of clients
File
drv_nvm_config_template.h
C
#define DRV_NVM_CLIENTS_NUMBER 1
Description
NVM maximum number of clients
This definition selects the maximum number of clients that the NVM driver can supported at run time. This constant defines the total number of
NVM driver clients that will be available to all instances of the NVM driver.
Remarks
This macro is mandatory when building the driver for dynamic operation.
DRV_NVM_INSTANCES_NUMBER Macro
Selects the maximum number of Driver instances that can be supported by the dynamic driver.
File
drv_nvm_config_template.h
C
#define DRV_NVM_INSTANCES_NUMBER 1
Description
NVM Driver instance configuration
This definition selects the maximum number of Driver instances that can be supported by the dynamic driver. In case of this driver, multiple
instances of the driver could use the same hardware instance.
Remarks
This macro is mandatory when building the driver for dynamic operation.
DRV_NVM_INTERRUPT_MODE Macro
Macro specifies operation of the driver to be in the interrupt mode or polled mode
File
drv_nvm_config_template.h
C
#define DRV_NVM_INTERRUPT_MODE true
Description
NVM interrupt and polled mode operation control
This macro specifies operation of the driver to be in the interrupt mode or polled mode
• true - Select if interrupt mode of NVM operation is desired
• false - Select if polling mode of NVM operation is desired
Not defining this option to true or false will result in build error.
Remarks
This macro is mandatory when building the driver for dynamic operation.
DRV_NVM_ROW_SIZE Macro
Specifies the NVM Driver Program Row Size in bytes.
Volume V: MPLAB Harmony Framework Driver Libraries Help NVM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 651
File
drv_nvm.h
C
#define DRV_NVM_ROW_SIZE (NVM_ROW_SIZE)
Description
NVM Driver Program Row Size.
This definition specifies the NVM Driver Program Row Size in bytes. This parameter is device specific and is obtained from the device specific
processor header file. The Program Row Size is the minimum block size that can be programmed in one program operation.
Remarks
None
DRV_NVM_ERASE_WRITE_ENABLE Macro
Enables support for NVM Driver Erase Write Feature.
File
drv_nvm_config_template.h
C
#define DRV_NVM_ERASE_WRITE_ENABLE
Description
NVM Driver Erase Write Feature Enable
Specifying this macro enable row erase write feature. If this macro is specified, the drv_nvm_erasewrite.c file should be added in the project.
Support for DRV_NVM_EraseWrite() function then gets enabled.
Remarks
This macro is optional and should be specified only if the DRV_NVM_EraseWrite() function is required.
DRV_NVM_PAGE_SIZE Macro
Specifies the NVM Driver Program Page Size in bytes.
File
drv_nvm.h
C
#define DRV_NVM_PAGE_SIZE (NVM_PAGE_SIZE)
Description
NVM Driver Program Page Size.
This definition specifies the NVM Driver Program Page Size in bytes. This parameter is device specific and is obtained from the device specific
processor header file.
Remarks
None
DRV_NVM_DISABLE_ERROR_CHECK Macro
Disables the error checks in the driver.
File
drv_nvm_config_template.h
C
#define DRV_NVM_DISABLE_ERROR_CHECK
Volume V: MPLAB Harmony Framework Driver Libraries Help NVM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 652
Description
NVM Driver Disable Error Checks
Specifying this macro disables the error checks in the driver. Error checks like parameter validation, NULL checks etc, will be disabled in the driver
in order to optimize the code space.
Remarks
This macro is optional and should be specified only if code space is a constraint.
DRV_NVM_MEDIA_SIZE Macro
Specifies the NVM Media size.
File
drv_nvm_config_template.h
C
#define DRV_NVM_MEDIA_SIZE 32
Description
NVM Media Size
This definition specifies the NVM Media Size to be used. The size is specified in number of Kilo Bytes. The media size MUST never exceed
physical available NVM Memory size. Application code requirements should be kept in mind while defining this parameter.
Remarks
This macro is mandatory when building the driver for dynamic operation.
DRV_NVM_MEDIA_START_ADDRESS Macro
Specifies the NVM Media start address.
File
drv_nvm_config_template.h
C
#define DRV_NVM_MEDIA_START_ADDRESS 0x9D010000
Description
NVM Media Start Address
This definition specifies the NVM Media Start address parameter.
Remarks
This macro is mandatory when building the driver for dynamic operation.
DRV_NVM_SYS_FS_REGISTER Macro
Register to use with the File system
File
drv_nvm_config_template.h
C
#define DRV_NVM_SYS_FS_REGISTER
Description
NVM Driver Register with File System
Specifying this macro enables the NVM driver to register its services with the SYS FS.
Remarks
This macro is optional and should be specified only if the NVM driver is to be used with the File System.
Volume V: MPLAB Harmony Framework Driver Libraries Help NVM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 653
Building the Library
This section lists the files that are available in the NVM Driver Library.
Description
This section list the files that are available in the \src folder of the NVM Driver. It lists which files need to be included in the build based on either
a hardware feature present on the board or configuration option selected by the system.
The following three tables list and describe the header (.h) and source (.c) files that implement this library. The parent folder for these files is
/framework/driver/nvm.
Interface File(s)
This table lists and describes the header files that must be included (i.e., using #include) by any code that uses this library.
Source File Name Description
/drv_nvm.h Header file that exports the driver API.
Required File(s)
All of the required files listed in the following table are automatically added into the MPLAB X IDE project by the MHC
when the library is selected for use.
This table lists and describes the source and header files that must always be included in the MPLAB X IDE project to build this library.
Source File Name Description
/src/dynamic/drv_nvm.c
/src/dynamic/drv_nvm_erasewrite.c
Dynamic NVM Driver implementation file.
Dynamic NVM Driver Erase/Write implementation file.
/src/static/drv_nvm_static.c Static NVM Driver implementation file for single clients.
/src/static_multi/drv_nvm_static_multi.c Static NVM Driver implementation file for multiple clients.
Optional File(s)
This table lists and describes the source and header files that may optionally be included if required for the desired implementation.
Source File Name Description
N/A No optional files are available for this library.
Module Dependencies
The NVM Driver Library depends on the following modules:
• Interrupt System Service Library
• Ports System Service Library
Library Interface
a) System Functions
Name Description
DRV_NVM_Initialize Initializes the NVM instance for the specified driver index
Implementation: Static/Dynamic
DRV_NVM_Deinitialize Deinitializes the specified instance of the NVM driver module
Implementation: Static/Dynamic
DRV_NVM_Status Gets the current status of the NVM driver module.
Implementation: Static/Dynamic
b) Client Core Functions
Name Description
DRV_NVM_Open Opens the specified NVM driver instance and returns a handle to it
Implementation: Static/Dynamic
DRV_NVM_Close Closes an opened-instance of the NVM driver
Implementation: Static/Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help NVM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 654
DRV_NVM_Read Reads blocks of data from the specified address in memory.
Implementation: Static/Dynamic
DRV_NVM_Write Writes blocks of data starting from the specified address in flash memory.
Implementation: Static/Dynamic
DRV_NVM_Erase Erase the specified number of blocks of the Flash memory.
Implementation: Static/Dynamic
DRV_NVM_EraseWrite Erase and Write blocks of data starting from a specified address in flash memory.
Implementation: Static/Dynamic
DRV_NVM_EventHandlerSet Allows a client to identify an event handling function for the driver to call back when queued
operation has completed.
Implementation: Static/Dynamic
c) Client Block Data Functions
Name Description
DRV_NVM_Tasks Maintains the driver's erase and write state machine and implements its ISR.
Implementation: Static/Dynamic
d) Status Functions
Name Description
DRV_NVM_AddressGet Returns the NVM media start address
Implementation: Static/Dynamic
DRV_NVM_CommandStatus Gets the current status of the command.
Implementation: Static/Dynamic
DRV_NVM_GeometryGet Returns the geometry of the device.
Implementation: Static/Dynamic
e) Miscellaneous Functions
Name Description
DRV_NVM_IsAttached Returns the physical attach status of the NVM.
Implementation: Static/Dynamic
DRV_NVM_IsWriteProtected Returns the write protect status of the NVM.
Implementation: Static/Dynamic
f) Data Types and Constants
Name Description
DRV_NVM_INDEX_0 NVM driver index definitions
DRV_NVM_INIT Defines the data required to initialize or reinitialize the NVM driver
DRV_NVM_INDEX_1 This is macro DRV_NVM_INDEX_1.
DRV_NVM_EVENT Identifies the possible events that can result from a request.
DRV_NVM_EVENT_HANDLER Pointer to a NVM Driver Event handler function
DRV_NVM_COMMAND_HANDLE Handle identifying commands queued in the driver.
DRV_NVM_COMMAND_STATUS Specifies the status of the command for the read, write and erase operations.
DRV_NVM_COMMAND_HANDLE_INVALID This value defines the NVM Driver's Invalid Command Handle.
Description
This section describes the Application Programming Interface (API) functions of the NVM Driver Library.
Refer to each section for a detailed description.
a) System Functions
DRV_NVM_Initialize Function
Initializes the NVM instance for the specified driver index
Implementation: Static/Dynamic
File
drv_nvm.h
Volume V: MPLAB Harmony Framework Driver Libraries Help NVM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 655
C
SYS_MODULE_OBJ DRV_NVM_Initialize(const SYS_MODULE_INDEX index, const SYS_MODULE_INIT * const init);
Returns
If successful, returns a valid handle to a driver instance object. Otherwise it returns SYS_MODULE_OBJ_INVALID.
Description
This routine initializes the NVM driver instance for the specified driver index, making it ready for clients to open and use it.
Remarks
This routine must be called before any other NVM routine is called.
This routine should only be called once during system initialization unless DRV_NVM_Deinitialize is called to deinitialize the driver instance.
This routine will NEVER block for hardware access. If the operation requires time to allow the hardware to reinitialize, it will be reported by the
DRV_NVM_Status operation. The system must use DRV_NVM_Status to find out when the driver is in the ready state.
Build configuration options may be used to statically override options in the "init" structure and will take precedence over initialization data passed
using this routine.
Preconditions
None.
Example
// This code snippet shows an example
// of initializing the NVM Driver.
SYS_MODULE_OBJ objectHandle;
SYS_FS_MEDIA_REGION_GEOMETRY gNvmGeometryTable[3] =
{
{
// Read Region Geometry
.blockSize = 1,
.numBlocks = (DRV_NVM_MEDIA_SIZE * 1024),
},
{
// Write Region Geometry
.blockSize = DRV_NVM_ROW_SIZE,
.numBlocks = ((DRV_NVM_MEDIA_SIZE * 1024)/DRV_NVM_ROW_SIZE)
},
{
// Erase Region Geometry
.blockSize = DRV_NVM_PAGE_SIZE,
.numBlocks = ((DRV_NVM_MEDIA_SIZE * 1024)/DRV_NVM_PAGE_SIZE)
}
};
const SYS_FS_MEDIA_GEOMETRY gNvmGeometry =
{
.mediaProperty = SYS_FS_MEDIA_WRITE_IS_BLOCKING,
// Number of read, write and erase entries in the table
.numReadRegions = 1,
.numWriteRegions = 1,
.numEraseRegions = 1,
.geometryTable = &gNvmGeometryTable
};
// FLASH Driver Initialization Data
const DRV_NVM_INIT drvNvmInit =
{
.moduleInit.sys.powerState = SYS_MODULE_POWER_RUN_FULL,
.nvmID = NVM_ID_0,
.interruptSource = INT_SOURCE_FLASH_CONTROL,
.mediaStartAddress = NVM_BASE_ADDRESS,
.nvmMediaGeometry = &gNvmGeometry
};
Volume V: MPLAB Harmony Framework Driver Libraries Help NVM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 656
//usage of DRV_NVM_INDEX_0 indicates usage of Flash-related APIs
objectHandle = DRV_NVM_Initialize(DRV_NVM_INDEX_0, (SYS_MODULE_INIT*)&drvNVMInit);
if (SYS_MODULE_OBJ_INVALID == objectHandle)
{
// Handle error
}
Parameters
Parameters Description
index Identifier for the instance to be initialized also the type of memory used
init Pointer to a data structure containing any data necessary to initialize the driver.
Function
SYS_MODULE_OBJ DRV_NVM_Initialize
(
const SYS_MODULE_INDEX index,
const SYS_MODULE_INIT * const init
);
DRV_NVM_Deinitialize Function
Deinitializes the specified instance of the NVM driver module
Implementation: Static/Dynamic
File
drv_nvm.h
C
void DRV_NVM_Deinitialize(SYS_MODULE_OBJ object);
Returns
None.
Description
Deinitializes the specified instance of the NVM driver module, disabling its operation (and any hardware). Invalidates all the internal data.
Remarks
Once the Initialize operation has been called, the Deinitialize operation must be called before the Initialize operation can be called again.
Preconditions
Function DRV_NVM_Initialize should have been called before calling this function.
Parameter: object - Driver object handle, returned from the DRV_NVM_Initialize routine
Example
// This code snippet shows an example
// of deinitializing the driver.
SYS_MODULE_OBJ object; // Returned from DRV_NVM_Initialize
SYS_STATUS status;
DRV_NVM_Deinitialize(object);
status = DRV_NVM_Status(object);
if (SYS_MODULE_DEINITIALIZED != status)
{
// Check again later if you need to know
// when the driver is deinitialized.
}
Function
void DRV_NVM_Deinitialize
(
Volume V: MPLAB Harmony Framework Driver Libraries Help NVM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 657
SYS_MODULE_OBJ object
);
DRV_NVM_Status Function
Gets the current status of the NVM driver module.
Implementation: Static/Dynamic
File
drv_nvm.h
C
SYS_STATUS DRV_NVM_Status(SYS_MODULE_OBJ object);
Returns
SYS_STATUS_READY - Indicates that the driver is ready and accept requests for new operations.
SYS_STATUS_UNINITIALIZED - Indicates the driver is not initialized.
Description
This routine provides the current status of the NVM driver module.
Remarks
This routine will NEVER block waiting for hardware.
Preconditions
Function DRV_NVM_Initialize should have been called before calling this function.
Example
SYS_MODULE_OBJ object; // Returned from DRV_NVM_Initialize
SYS_STATUS NVMStatus;
NVMStatus = DRV_NVM_Status(object);
else if (SYS_STATUS_ERROR >= NVMStatus)
{
// Handle error
}
Parameters
Parameters Description
object Driver object handle, returned from the DRV_NVM_Initialize routine
Function
SYS_STATUS DRV_NVM_Status
(
SYS_MODULE_OBJ object
);
b) Client Core Functions
DRV_NVM_Open Function
Opens the specified NVM driver instance and returns a handle to it
Implementation: Static/Dynamic
File
drv_nvm.h
C
DRV_HANDLE DRV_NVM_Open(const SYS_MODULE_INDEX index, const DRV_IO_INTENT ioIntent);
Volume V: MPLAB Harmony Framework Driver Libraries Help NVM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 658
Returns
If successful, the routine returns a valid open-instance handle (a number identifying both the caller and the module instance).
If an error occurs, DRV_HANDLE_INVALID is returned. Errors can occur under the following circumstances:
• if the number of client objects allocated via DRV_NVM_CLIENTS_NUMBER is insufficient
• if the client is trying to open the driver but driver has been opened exclusively by another client
• if the client is trying to open the driver exclusively, but has already been opened in a non exclusive mode by another client.
• if the driver hardware instance being opened is not initialized or is invalid
Description
This routine opens the specified NVM driver instance and provides a handle. This handle must be provided to all other client-level operations to
identify the caller and the instance of the driver.
Remarks
The handle returned is valid until the DRV_NVM_Close routine is called. This routine will NEVER block waiting for hardware. If the driver has has
already been opened, it cannot be opened exclusively.
Preconditions
Function DRV_NVM_Initialize must have been called before calling this function.
Example
DRV_HANDLE handle;
handle = DRV_NVM_Open(DRV_NVM_INDEX_0, DRV_IO_INTENT_EXCLUSIVE);
if (DRV_HANDLE_INVALID == handle)
{
// Unable to open the driver
}
Parameters
Parameters Description
index Identifier for the object instance to be opened
intent Zero or more of the values from the enumeration DRV_IO_INTENT "ORed" together to
indicate the intended use of the driver
Function
DRV_HANDLE DRV_NVM_Open
(
const SYS_MODULE_INDEX index,
const DRV_IO_INTENT ioIntent
);
DRV_NVM_Close Function
Closes an opened-instance of the NVM driver
Implementation: Static/Dynamic
File
drv_nvm.h
C
void DRV_NVM_Close(const DRV_HANDLE handle);
Returns
None
Description
This routine closes an opened-instance of the NVM driver, invalidating the handle.
Remarks
After calling this routine, the handle passed in "handle" must not be used with any of the remaining driver routines. A new handle must be obtained
by calling DRV_NVM_Open before the caller may use the driver again. Usually there is no need for the driver client to verify that the Close
Volume V: MPLAB Harmony Framework Driver Libraries Help NVM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 659
operation has completed.
Preconditions
The DRV_NVM_Initialize routine must have been called for the specified NVM driver instance.
DRV_NVM_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE handle; // Returned from DRV_NVM_Open
DRV_NVM_Close(handle);
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
void DRV_NVM_Close
(
const DRV_HANDLE handle
);
DRV_NVM_Read Function
Reads blocks of data from the specified address in memory.
Implementation: Static/Dynamic
File
drv_nvm.h
C
void DRV_NVM_Read(const DRV_HANDLE handle, DRV_NVM_COMMAND_HANDLE * commandHandle, void * targetBuffer,
uint32_t blockStart, uint32_t nBlock);
Returns
The buffer handle is returned in the commandHandle argument. It will be DRV_NVM_COMMAND_HANDLE_INVALID if the request was not
successful.
Description
This routine reads blocks of data from the specified address in memory. This operation is blocking and returns with the required data in the target
buffer. If an event handler is registered with the driver the event handler would be invoked from within this function to indicate the status of the
operation. This function should not be used to read areas of memory which are queued to be programmed or erased. If required, the program or
erase operations should be allowed to complete. The function returns DRV_NVM_COMMAND_HANDLE_INVALID in the commandHandle
argument under the following circumstances:
• if the driver handle is invalid
• if the target buffer pointer is NULL
• if the number of blocks to be read is zero or more than the actual number of blocks available
• if a buffer object could not be allocated to the request
• if the client opened the driver in write only mode
Remarks
None.
Preconditions
The DRV_NVM_Initialize routine must have been called for the specified NVM driver instance.
DRV_NVM_Open must have been called with DRV_IO_INTENT_READ or DRV_IO_INTENT_READWRITE as the ioIntent to obtain a valid
opened device handle.
Example
uint8_t myBuffer[MY_BUFFER_SIZE];
// address should be block aligned.
uint32_t blockStart = NVM_BASE_ADDRESS_TO_READ_FROM;
Volume V: MPLAB Harmony Framework Driver Libraries Help NVM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 660
uint32_t nBlock = 2;
DRV_NVM_COMMAND_HANDLE commandHandle;
MY_APP_OBJ myAppObj;
// myNVMHandle is the handle returned
// by the DRV_NVM_Open function.
DRV_NVM_Read(myNVMHandle, &commandHandle, &myBuffer, blockStart, nBlock);
if(DRV_NVM_COMMAND_HANDLE_INVALID == commandHandle)
{
// Error handling here
}
else
{
// Read Successful
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
commandHandle Pointer to an argument that will contain the return buffer handle
targetBuffer Buffer into which the data read from the NVM Flash instance will be placed
blockStart Start block address in NVM memory from where the read should begin. It can be any address
of the flash.
nBlock Total number of blocks to be read. Each Read block is of 1 byte.
Function
void DRV_NVM_Read
(
const DRV_HANDLE handle,
DRV_NVM_COMMAND_HANDLE * commandHandle,
void * targetBuffer,
uint32_t blockStart,
uint32_t nBlock
);
DRV_NVM_Write Function
Writes blocks of data starting from the specified address in flash memory.
Implementation: Static/Dynamic
File
drv_nvm.h
C
void DRV_NVM_Write(const DRV_HANDLE handle, DRV_NVM_COMMAND_HANDLE * commandHandle, void * sourceBuffer,
uint32_t blockStart, uint32_t nBlock);
Returns
The buffer handle is returned in the commandHandle argument. It will be DRV_NVM_COMMAND_HANDLE_INVALID if the request was not
successful.
Description
This function schedules a non-blocking write operation for writing blocks of data into flash memory. The function returns with a valid buffer handle
in the commandHandle argument if the write request was scheduled successfully. The function adds the request to the hardware instance queue
and returns immediately. While the request is in the queue, the application buffer is owned by the driver and should not be modified. The function
returns DRV_NVM_COMMAND_HANDLE_INVALID in the commandHandle argument under the following circumstances:
• if a buffer object could not be allocated to the request
• if the source buffer pointer is NULL
• if the client opened the driver for read only
• if the number of blocks to be written is either zero or more than the number of blocks actually available
Volume V: MPLAB Harmony Framework Driver Libraries Help NVM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 661
• if the write queue size is full or queue depth is insufficient
• if the driver handle is invalid
If the requesting client registered an event callback with the driver, the driver will issue a DRV_NVM_EVENT_COMMAND_COMPLETE event if
the buffer was processed successfully or DRV_NVM_EVENT_COMMAND_ERROR event if the buffer was not processed successfully.
Remarks
Performing a flash programming operation while executing (fetching) instructions from program Flash memory, the CPU stalls (waits) until the
programming operation is finished. The CPU will not execute any instruction, or respond to interrupts, during this time. If any interrupts occur
during the programming cycle, they remain pending until the cycle completes. This makes the NVM write operation blocking in nature.
Preconditions
The DRV_NVM_Initialize() routine must have been called for the specified NVM driver instance.
DRV_NVM_Open() routine must have been called to obtain a valid opened device handle. DRV_IO_INTENT_WRITE or
DRV_IO_INTENT_READWRITE must have been specified as a parameter to this routine.
The flash address location which has to be written, must have be erased before using the DRV_NVM_Erase() routine.
Example
uint8_t myBuffer[MY_BUFFER_SIZE];
// address should be block aligned.
uint32_t blockStart = NVM_BASE_ADDRESS_TO_WRITE_TO;
uint32_t nBlock = 2;
DRV_NVM_COMMAND_HANDLE commandHandle;
MY_APP_OBJ myAppObj;
// myNVMHandle is the handle returned
// by the DRV_NVM_Open function.
// Client registers an event handler with driver
DRV_NVM_EventHandlerSet(myNVMHandle, APP_NVMEventHandler, (uintptr_t)&myAppObj);
DRV_NVM_Write(myNVMHandle, &commandHandle, &myBuffer, blockStart, nBlock);
if(DRV_NVM_COMMAND_HANDLE_INVALID == commandHandle)
{
// Error handling here
}
// Event is received when
// the buffer is processed.
void APP_NVMEventHandler(DRV_NVM_EVENT event,
DRV_NVM_COMMAND_HANDLE commandHandle, uintptr_t contextHandle)
{
// contextHandle points to myAppObj.
switch(event)
{
case DRV_NVM_EVENT_COMMAND_COMPLETE:
// This means the data was transferred.
break;
case DRV_NVM_EVENT_COMMAND_ERROR:
// Error handling here.
break;
default:
break;
}
}
Volume V: MPLAB Harmony Framework Driver Libraries Help NVM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 662
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
commandHandle Pointer to an argument that will contain the return buffer handle
sourceBuffer The source buffer containing data to be programmed into NVM Flash
blockStart Start block address of NVM Flash where the write should begin. This address should be
aligned on a block boundary.
nBlock Total number of blocks to be written.
Function
void DRV_NVM_Write
(
const DRV_HANDLE handle,
DRV_NVM_COMMAND_HANDLE * commandHandle,
void * sourceBuffer,
uint32_t blockStart,
uint32_t nBlock
);
DRV_NVM_Erase Function
Erase the specified number of blocks of the Flash memory.
Implementation: Static/Dynamic
File
drv_nvm.h
C
void DRV_NVM_Erase(const DRV_HANDLE handle, DRV_NVM_COMMAND_HANDLE * commandHandle, uint32_t blockStart,
uint32_t nBlock);
Returns
The buffer handle is returned in the commandHandle argument. It Will be DRV_NVM_COMMAND_HANDLE_INVALID if the request was not
queued.
Description
This function schedules a non-blocking erase operation of flash memory. The function returns with a valid erase handle in the commandHandle
argument if the erase request was scheduled successfully. The function adds the request to the hardware instance queue and returns
immediately. The function returns DRV_NVM_COMMAND_HANDLE_INVALID in the commandHandle argument under the following
circumstances:
• if a buffer object could not be allocated to the request
• if the client opened the driver for read only
• if the number of blocks to be erased is either zero or more than the number of blocks actually available
• if the erase queue size is full or queue depth is insufficient
• if the driver handle is invalid
If the requesting client registered an event callback with the driver, the driver will issue a DRV_NVM_EVENT_COMMAND_COMPLETE event if
the erase operation was successful or DRV_NVM_EVENT_COMMAND_ERROR event if the erase operation was not successful.
Remarks
Performing a flash erase operation while executing (fetching) instructions from program Flash memory, the CPU stalls (waits) until the erase
operation is finished. The CPU will not execute any instruction, or respond to interrupts, during this time. If any interrupts occur during the
programming cycle, they remain pending until the cycle completes. This make the NVM erase operation blocking in nature.
Preconditions
The DRV_NVM_Initialize() routine must have been called for the specified NVM driver instance.
The DRV_NVM_Open() routine must have been called with DRV_IO_INTENT_WRITE or DRV_IO_INTENT_READWRITE to obtain a valid
opened device handle.
Volume V: MPLAB Harmony Framework Driver Libraries Help NVM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 663
Example
// Destination address should be block aligned.
uint32_t blockStart;
uint32_t nBlock;
DRV_NVM_COMMAND_HANDLE commandHandle;
MY_APP_OBJ myAppObj;
// myNVMHandle is the handle returned
// by the DRV_NVM_Open function.
// Client registers an event handler with driver
DRV_NVM_EventHandlerSet(myNVMHandle, APP_NVMEventHandler, (uintptr_t)&myAppObj);
DRV_NVM_Erase( myNVMHandle, &commandHandle, blockStart, nBlock );
if(DRV_NVM_COMMAND_HANDLE_INVALID == commandHandle)
{
// Error handling here
}
// Event is received when
// the buffer queue is processed.
void APP_NVMEventHandler(DRV_NVM_EVENT event,
DRV_NVM_COMMAND_HANDLE commandHandle, uintptr_t contextHandle)
{
// contextHandle points to myAppObj.
switch(event)
{
case DRV_NVM_EVENT_COMMAND_COMPLETE:
// This means the data was transferred.
break;
case DRV_NVM_EVENT_COMMAND_ERROR:
// Error handling here.
break;
default:
break;
}
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
commandHandle Pointer to an argument that will contain the return buffer handle
blockStart Start block address in NVM memory from where the erase should begin. This should be
aligned on a DRV_NVM_PAGE_SIZE byte boundary.
nBlock Total number of blocks to be erased.
Function
void DRV_NVM_Erase
(
const DRV_HANDLE handle,
DRV_NVM_COMMAND_HANDLE * commandHandle,
uint32_t blockStart,
uint32_t nBlock
);
Volume V: MPLAB Harmony Framework Driver Libraries Help NVM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 664
DRV_NVM_EraseWrite Function
Erase and Write blocks of data starting from a specified address in flash memory.
Implementation: Static/Dynamic
File
drv_nvm.h
C
void DRV_NVM_EraseWrite(const DRV_HANDLE handle, DRV_NVM_COMMAND_HANDLE * commandHandle, void *
sourceBuffer, uint32_t writeBlockStart, uint32_t nWriteBlock);
Returns
The buffer handle is returned in the commandHandle argument. It Will be DRV_NVM_COMMAND_HANDLE_INVALID if the request was not
queued.
Description
This function combines the step of erasing a page and then writing the row. The application can use this function if it wants to avoid having to
explicitly delete a page in order to update the rows contained in the page.
This function schedules a non-blocking operation to erase and write blocks of data into flash memory. The function returns with a valid buffer
handle in the commandHandle argument if the write request was scheduled successfully. The function adds the request to the hardware instance
queue and returns immediately. While the request is in the queue, the application buffer is owned by the driver and should not be modified. The
function returns DRV_NVM_COMMAND_HANDLE_INVALID in the commandHandle argument under the following circumstances:
• if a buffer could not be allocated to the request
• if the input buffer pointer is NULL
• if the client opened the driver for read only
• if the buffer size is 0
• if the write queue size is full or queue depth is insufficient
• if the driver handle is invalid
If the requesting client registered an event callback with the driver, the driver will issue a DRV_NVM_EVENT_COMMAND_COMPLETE event if
the buffer was processed successfully or DRV_NVM_EVENT_COMMAND_ERROR event if the buffer was not processed successfully.
Remarks
In order to use this function, the DRV_NVM_ERASE_WRITE_ENABLE must be defined in system_config.h and the drv_nvm_erasewrite.c file
must be included in the project.
Preconditions
The DRV_NVM_Initialize() routine must have been called for the specified NVM driver instance.
The DRV_NVM_Open() must have been called with DRV_IO_INTENT_WRITE or DRV_IO_INTENT_READWRITE as a parameter to obtain a
valid opened device handle.
Example
uint8_t myBuffer[MY_BUFFER_SIZE];
// address should be block aligned.
uint32_t blockStart = NVM_BASE_ADDRESS_TO_WRITE_TO;
uint32_t nBlock = 2;
DRV_NVM_COMMAND_HANDLE commandHandle;
MY_APP_OBJ myAppObj;
// myNVMHandle is the handle returned
// by the DRV_NVM_Open function.
// Client registers an event handler with driver
DRV_NVM_EventHandlerSet(myNVMHandle, APP_NVMEventHandler, (uintptr_t)&myAppObj);
DRV_NVM_EraseWrite(myNVMHandle, &commandHandle, &myBuffer, blockStart, nBlock);
if(DRV_NVM_COMMAND_HANDLE_INVALID == commandHandle)
{
// Error handling here
}
Volume V: MPLAB Harmony Framework Driver Libraries Help NVM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 665
// Event is received when
// the buffer is processed.
void APP_NVMEventHandler(DRV_NVM_EVENT event,
DRV_NVM_COMMAND_HANDLE commandHandle, uintptr_t contextHandle)
{
// contextHandle points to myAppObj.
switch(event)
{
case DRV_NVM_EVENT_COMMAND_COMPLETE:
// This means the data was transferred.
break;
case DRV_NVM_EVENT_COMMAND_ERROR:
// Error handling here.
break;
default:
break;
}
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
commandHandle Pointer to an argument that will contain the return buffer handle. If NULL, then buffer handle is
not returned.
sourceBuffer The source buffer containing data to be programmed into NVM Flash
writeBlockStart Start block address of NVM Flash where the write should begin. This address should be
aligned on a DRV_NVM_ROW_SIZE byte boundary.
nWriteBlock Total number of blocks to be written.
Function
void DRV_NVM_EraseWrite
(
const DRV_HANDLE handle,
DRV_NVM_COMMAND_HANDLE * commandHandle,
void * sourceBuffer,
uint32_t writeBlockStart,
uint32_t nWriteBlock
);
DRV_NVM_EventHandlerSet Function
Allows a client to identify an event handling function for the driver to call back when queued operation has completed.
Implementation: Static/Dynamic
File
drv_nvm.h
C
void DRV_NVM_EventHandlerSet(const DRV_HANDLE handle, const void * eventHandler, const uintptr_t context);
Returns
None.
Description
This function allows a client to identify an event handling function for the driver to call back when queued operation has completed. When a client
calls a write or erase function, it is provided with a handle identifying the buffer that was added to the driver's buffer queue. The driver will pass this
Volume V: MPLAB Harmony Framework Driver Libraries Help NVM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 666
handle back to the client by calling "eventHandler" function when the queued operation has completed.
The event handler should be set before the client performs any write or erase operations that could generate events. The event handler once set,
persists until the client closes the driver or sets another event handler (which could be a "NULL" pointer to indicate no callback).
Remarks
If the client does not want to be notified when the queued operation has completed, it does not need to register a callback.
Preconditions
The DRV_NVM_Initialize() routine must have been called for the specified NVM driver instance.
The DRV_NVM_Open() routine must have been called to obtain a valid opened device handle.
Example
// myAppObj is an application specific state data object.
MY_APP_OBJ myAppObj;
uint8_t myBuffer[MY_BUFFER_SIZE];
uint32_t blockStart, nBlock;
DRV_NVM_COMMAND_HANDLE commandHandle;
// drvNVMHandle is the handle returned
// by the DRV_NVM_Open function.
// Client registers an event handler with driver. This is done once.
DRV_NVM_EventHandlerSet(drvNVMHandle, APP_NVMEventHandler, (uintptr_t)&myAppObj);
DRV_NVM_Read(drvNVMHandle, &commandHandle, &myBuffer, blockStart, nBlock);
if(DRV_NVM_COMMAND_HANDLE_INVALID == commandHandle)
{
// Error handling here
}
// Event Processing Technique. Event is received when operation is done.
void APP_NVMEventHandler(DRV_NVM_EVENT event,
DRV_NVM_COMMAND_HANDLE handle, uintptr_t context)
{
// The context handle was set to an application specific
// object. It is now retrievable easily in the event handler.
MY_APP_OBJ myAppObj = (MY_APP_OBJ *) context;
switch(event)
{
case DRV_NVM_EVENT_COMMAND_COMPLETE:
// This means the data was transferred.
break;
case DRV_NVM_EVENT_COMMAND_ERROR:
// Error handling here.
break;
default:
break;
}
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
eventHandler Pointer to the event handler function implemented by the user
Volume V: MPLAB Harmony Framework Driver Libraries Help NVM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 667
context The value of parameter will be passed back to the client unchanged, when the eventHandler
function is called. It can be used to identify any client specific data object that identifies the
instance of the client module (for example, it may be a pointer to the client module's state
structure).
Function
void DRV_NVM_EventHandlerSet
(
const DRV_HANDLE handle,
const void * eventHandler,
const uintptr_t context
);
c) Client Block Data Functions
DRV_NVM_Tasks Function
Maintains the driver's erase and write state machine and implements its ISR.
Implementation: Static/Dynamic
File
drv_nvm.h
C
void DRV_NVM_Tasks(SYS_MODULE_OBJ object);
Returns
None.
Description
This routine is used to maintain the driver's internal write and erase state machine and implement its ISR for interrupt-driven implementations.
Remarks
This routine is normally not called directly by an application. It is called by the system's Tasks routine (SYS_Tasks) or by the appropriate raw ISR.
This routine may execute in an ISR context and will never block or access any resources that may cause it to block.
Preconditions
The DRV_NVM_Initialize routine must have been called for the specified NVM driver instance.
Example
SYS_MODULE_OBJ object; // Returned from DRV_NVM_Initialize
while (true)
{
DRV_NVM_Tasks (object);
// Do other tasks
}
Parameters
Parameters Description
object Object handle for the specified driver instance (returned from DRV_NVM_Initialize)
Function
void DRV_NVM_Tasks
(
SYS_MODULE_OBJ object
);
Volume V: MPLAB Harmony Framework Driver Libraries Help NVM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 668
d) Status Functions
DRV_NVM_AddressGet Function
Returns the NVM media start address
Implementation: Static/Dynamic
File
drv_nvm.h
C
uintptr_t DRV_NVM_AddressGet(const DRV_HANDLE handle);
Returns
Start address of the NVM Media if the handle is valid otherwise NULL.
Description
This function returns the NVM Media start address.
Remarks
None.
Preconditions
The DRV_NVM_Initialize() routine must have been called for the specified NVM driver instance.
The DRV_NVM_Open() routine must have been called to obtain a valid opened device handle.
Example
uintptr_t startAddress;
startAddress = DRV_NVM_AddressGet(drvNVMHandle);
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
Function
uintptr_t DRV_NVM_AddressGet
(
const DRV_HANDLE handle
);
DRV_NVM_CommandStatus Function
Gets the current status of the command.
Implementation: Static/Dynamic
File
drv_nvm.h
C
DRV_NVM_COMMAND_STATUS DRV_NVM_CommandStatus(const DRV_HANDLE handle, const DRV_NVM_COMMAND_HANDLE
commandHandle);
Returns
A DRV_NVM_COMMAND_STATUS value describing the current status of the command. Returns DRV_NVM_COMMAND_HANDLE_INVALID if
the client handle or the command handle is not valid.
Description
This routine gets the current status of the command. The application must use this routine where the status of a scheduled command needs to
polled on. The function may return DRV_NVM_COMMAND_HANDLE_INVALID in a case where the command handle has expired. A command
Volume V: MPLAB Harmony Framework Driver Libraries Help NVM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 669
handle expires when the internal buffer object is re-assigned to another erase or write request. It is recommended that this function be called
regularly in order to track the command status correctly.
The application can alternatively register an event handler to receive write or erase operation completion events.
Remarks
This routine will not block for hardware access and will immediately return the current status.
Preconditions
The DRV_NVM_Initialize() routine must have been called.
The DRV_NVM_Open() must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE handle; // Returned from DRV_NVM_Open
DRV_NVM_COMMAND_HANDLE commandHandle;
DRV_NVM_COMMAND_STATUS status;
status = DRV_NVM_CommandStatus(handle, commandHandle);
if(status == DRV_NVM_COMMAND_COMPLETED)
{
// Operation Done
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
DRV_NVM_COMMAND_STATUS DRV_NVM_CommandStatus
(
const DRV_HANDLE handle,
const DRV_NVM_COMMAND_HANDLE commandHandle
);
DRV_NVM_GeometryGet Function
Returns the geometry of the device.
Implementation: Static/Dynamic
File
drv_nvm.h
C
SYS_FS_MEDIA_GEOMETRY * DRV_NVM_GeometryGet(const DRV_HANDLE handle);
Returns
SYS_FS_MEDIA_GEOMETRY - Pointer to structure which holds the media geometry information.
Description
This API gives the following geometrical details of the NVM Flash:
• Media Property
• Number of Read/Write/Erase regions in the flash device
• Number of Blocks and their size in each region of the device
Remarks
None.
Preconditions
The DRV_NVM_Initialize() routine must have been called for the specified NVM driver instance.
The DRV_NVM_Open() routine must have been called to obtain a valid opened device handle.
Volume V: MPLAB Harmony Framework Driver Libraries Help NVM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 670
Example
SYS_FS_MEDIA_GEOMETRY * nvmFlashGeometry;
uint32_t readBlockSize, writeBlockSize, eraseBlockSize;
uint32_t nReadBlocks, nReadRegions, totalFlashSize;
nvmFlashGeometry = DRV_NVM_GeometryGet(nvmOpenHandle1);
readBlockSize = nvmFlashGeometry->geometryTable->blockSize;
nReadBlocks = nvmFlashGeometry->geometryTable->numBlocks;
nReadRegions = nvmFlashGeometry->numReadRegions;
writeBlockSize = (nvmFlashGeometry->geometryTable +1)->blockSize;
eraseBlockSize = (nvmFlashGeometry->geometryTable +2)->blockSize;
totalFlashSize = readBlockSize * nReadBlocks * nReadRegions;
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
Function
SYS_FS_MEDIA_GEOMETRY * DRV_NVM_GeometryGet
(
const DRV_HANDLE handle
);
e) Miscellaneous Functions
DRV_NVM_IsAttached Function
Returns the physical attach status of the NVM.
Implementation: Static/Dynamic
File
drv_nvm.h
C
bool DRV_NVM_IsAttached(const DRV_HANDLE handle);
Returns
Returns false if the handle is invalid otherwise returns true.
Description
This function returns the physical attach status of the NVM.
Remarks
None.
Preconditions
The DRV_NVM_Initialize() routine must have been called for the specified NVM driver instance.
The DRV_NVM_Open() routine must have been called to obtain a valid opened device handle.
Example
// The NVM media is always attached and so the below
// always returns true.
bool isNVMAttached;
isNVMAttached = DRV_NVM_isAttached(drvNVMHandle);
Volume V: MPLAB Harmony Framework Driver Libraries Help NVM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 671
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
Function
bool DRV_NVM_IsAttached
(
const DRV_HANDLE handle
);
DRV_NVM_IsWriteProtected Function
Returns the write protect status of the NVM.
Implementation: Static/Dynamic
File
drv_nvm.h
C
bool DRV_NVM_IsWriteProtected(const DRV_HANDLE handle);
Returns
Always returns false.
Description
This function returns the physical attach status of the NVM. This function always returns false.
Remarks
None.
Preconditions
The DRV_NVM_Initialize() routine must have been called for the specified NVM driver instance.
The DRV_NVM_Open() routine must have been called to obtain a valid opened device handle.
Example
// The NVM media is treated as always writeable.
bool isWriteProtected;
isWriteProtected = DRV_NVM_IsWriteProtected(drvNVMHandle);
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
Function
bool DRV_NVM_IsWriteProtected
(
const DRV_HANDLE handle
);
f) Data Types and Constants
DRV_NVM_INDEX_0 Macro
NVM driver index definitions
File
drv_nvm.h
Volume V: MPLAB Harmony Framework Driver Libraries Help NVM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 672
C
#define DRV_NVM_INDEX_0 0
Description
Driver NVM Module Index reference
These constants provide NVM driver index definitions.
Remarks
These constants should be used in place of hard-coded numeric literals. These values should be passed into the DRV_NVM_Initialize and
DRV_NVM_Open routines to identify the driver instance in use.
DRV_NVM_INIT Structure
Defines the data required to initialize or reinitialize the NVM driver
File
drv_nvm.h
C
typedef struct {
SYS_MODULE_INIT moduleInit;
NVM_MODULE_ID nvmID;
INT_SOURCE interruptSource;
uint32_t mediaStartAddress;
const SYS_FS_MEDIA_GEOMETRY * nvmMediaGeometry;
} DRV_NVM_INIT;
Members
Members Description
SYS_MODULE_INIT moduleInit; System module initialization
NVM_MODULE_ID nvmID; Identifies NVM hardware module (PLIB-level) ID
INT_SOURCE interruptSource; Interrupt Source for Write Interrupt
uint32_t mediaStartAddress; NVM Media start address. The driver treats this address as
• block 0 address for read, write and erase operations.
const SYS_FS_MEDIA_GEOMETRY *
nvmMediaGeometry;
NVM Media geometry object.
Description
NVM Driver Initialization Data
This data type defines the data required to initialize or reinitialize the NVM driver.
Remarks
Not all initialization features are available for all devices. Please refer to the specific device data sheet to determine availability.
DRV_NVM_INDEX_1 Macro
File
drv_nvm.h
C
#define DRV_NVM_INDEX_1 1
Description
This is macro DRV_NVM_INDEX_1.
DRV_NVM_EVENT Enumeration
Identifies the possible events that can result from a request.
File
drv_nvm.h
Volume V: MPLAB Harmony Framework Driver Libraries Help NVM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 673
C
typedef enum {
DRV_NVM_EVENT_COMMAND_COMPLETE = SYS_FS_MEDIA_EVENT_BLOCK_COMMAND_COMPLETE,
DRV_NVM_EVENT_COMMAND_ERROR = SYS_FS_MEDIA_EVENT_BLOCK_COMMAND_ERROR
} DRV_NVM_EVENT;
Members
Members Description
DRV_NVM_EVENT_COMMAND_COMPLETE =
SYS_FS_MEDIA_EVENT_BLOCK_COMMAND_COMPLETE
Operation has been completed successfully.
DRV_NVM_EVENT_COMMAND_ERROR =
SYS_FS_MEDIA_EVENT_BLOCK_COMMAND_ERROR
There was an error during the operation
Description
NVM Driver Events
This enumeration identifies the possible events that can result from a Write or Erase request caused by the client.
Remarks
One of these values is passed in the "event" parameter of the event handling callback function that client registered with the driver by calling the
DRV_NVM_EventHandlerSet function when a request is completed.
DRV_NVM_EVENT_HANDLER Type
Pointer to a NVM Driver Event handler function
File
drv_nvm.h
C
typedef SYS_FS_MEDIA_EVENT_HANDLER DRV_NVM_EVENT_HANDLER;
Returns
None.
Description
NVM Driver Event Handler Function Pointer
This data type defines the required function signature for the NVM event handling callback function. A client must register a pointer to an event
handling function whose function signature (parameter and return value types) match the types specified by this function pointer in order to receive
event calls back from the driver.
The parameters and return values are described here and a partial example implementation is provided.
Remarks
If the event is DRV_NVM_EVENT_COMMAND_COMPLETE, it means that the write or a erase operation was completed successfully.
If the event is DRV_NVM_EVENT_COMMAND_ERROR, it means that the scheduled operation was not completed successfully.
The context parameter contains the handle to the client context, provided at the time the event handling function was registered using the
DRV_NVM_EventHandlerSet function. This context handle value is passed back to the client as the "context" parameter. It can be any value
necessary to identify the client context or instance (such as a pointer to the client's data) instance of the client that made the read/write/erase
request.
The event handler function executes in the driver peripheral's interrupt context when the driver is configured for interrupt mode operation. It is
recommended of the application to not perform process intensive or blocking operations within this function.
Example
void APP_MyNvmEventHandler
(
DRV_NVM_EVENT event,
DRV_NVM_COMMAND_HANDLE commandHandle,
uintptr_t context
)
{
MY_APP_DATA_STRUCT pAppData = (MY_APP_DATA_STRUCT) context;
switch(event)
Volume V: MPLAB Harmony Framework Driver Libraries Help NVM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 674
{
case DRV_NVM_EVENT_COMMAND_COMPLETE:
// Handle the completed buffer.
break;
case DRV_NVM_EVENT_COMMAND_ERROR:
default:
// Handle error.
break;
}
}
Parameters
Parameters Description
event Identifies the type of event
commandHandle Handle returned from the Read/Write/Erase requests
context Value identifying the context of the application that registered the event handling function
DRV_NVM_COMMAND_HANDLE Type
Handle identifying commands queued in the driver.
File
drv_nvm.h
C
typedef SYS_FS_MEDIA_BLOCK_COMMAND_HANDLE DRV_NVM_COMMAND_HANDLE;
Description
NVM Driver command handle.
A command handle is returned by a call to the Read, Write or Erase functions. This handle allows the application to track the completion of the
operation. This command handle is also returned to the client along with the event that has occurred with respect to the command. This allows the
application to connect the event to a specific command in case where multiple commands are queued.
The command handle associated with the command request expires when the client has been notified of the completion of the command (after
event handler function that notifies the client returns) or after the command has been retired by the driver if no event handler callback was set.
Remarks
None.
DRV_NVM_COMMAND_STATUS Enumeration
Specifies the status of the command for the read, write and erase operations.
File
drv_nvm.h
C
typedef enum {
DRV_NVM_COMMAND_COMPLETED = SYS_FS_MEDIA_COMMAND_COMPLETED,
DRV_NVM_COMMAND_QUEUED = SYS_FS_MEDIA_COMMAND_QUEUED,
DRV_NVM_COMMAND_IN_PROGRESS = SYS_FS_MEDIA_COMMAND_IN_PROGRESS,
DRV_NVM_COMMAND_ERROR_UNKNOWN = SYS_FS_MEDIA_COMMAND_UNKNOWN
} DRV_NVM_COMMAND_STATUS;
Members
Members Description
DRV_NVM_COMMAND_COMPLETED =
SYS_FS_MEDIA_COMMAND_COMPLETED
Done OK and ready
DRV_NVM_COMMAND_QUEUED =
SYS_FS_MEDIA_COMMAND_QUEUED
Scheduled but not started
Volume V: MPLAB Harmony Framework Driver Libraries Help NVM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 675
DRV_NVM_COMMAND_IN_PROGRESS =
SYS_FS_MEDIA_COMMAND_IN_PROGRESS
Currently being in transfer
DRV_NVM_COMMAND_ERROR_UNKNOWN =
SYS_FS_MEDIA_COMMAND_UNKNOWN
Unknown Command
Description
NVM Driver Command Status
NVM Driver command Status
This type specifies the status of the command for the read, write and erase operations.
Remarks
None.
DRV_NVM_COMMAND_HANDLE_INVALID Macro
This value defines the NVM Driver's Invalid Command Handle.
File
drv_nvm.h
C
#define DRV_NVM_COMMAND_HANDLE_INVALID SYS_FS_MEDIA_BLOCK_COMMAND_HANDLE_INVALID
Description
NVM Driver Invalid Command Handle.
This value defines the NVM Driver Invalid Command Handle. This value is returned by read/write/erase routines when the command request was
not accepted.
Remarks
None.
Files
Files
Name Description
drv_nvm.h NVM Driver Interface Definition
drv_nvm_config_template.h NVM driver configuration definitions.
Description
This section lists the source and header files used by the NVM Driver Library.
drv_nvm.h
NVM Driver Interface Definition
Enumerations
Name Description
DRV_NVM_COMMAND_STATUS Specifies the status of the command for the read, write and erase operations.
DRV_NVM_EVENT Identifies the possible events that can result from a request.
Functions
Name Description
DRV_NVM_AddressGet Returns the NVM media start address
Implementation: Static/Dynamic
DRV_NVM_Close Closes an opened-instance of the NVM driver
Implementation: Static/Dynamic
DRV_NVM_CommandStatus Gets the current status of the command.
Implementation: Static/Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help NVM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 676
DRV_NVM_Deinitialize Deinitializes the specified instance of the NVM driver module
Implementation: Static/Dynamic
DRV_NVM_Erase Erase the specified number of blocks of the Flash memory.
Implementation: Static/Dynamic
DRV_NVM_EraseWrite Erase and Write blocks of data starting from a specified address in flash memory.
Implementation: Static/Dynamic
DRV_NVM_EventHandlerSet Allows a client to identify an event handling function for the driver to call back when queued
operation has completed.
Implementation: Static/Dynamic
DRV_NVM_GeometryGet Returns the geometry of the device.
Implementation: Static/Dynamic
DRV_NVM_Initialize Initializes the NVM instance for the specified driver index
Implementation: Static/Dynamic
DRV_NVM_IsAttached Returns the physical attach status of the NVM.
Implementation: Static/Dynamic
DRV_NVM_IsWriteProtected Returns the write protect status of the NVM.
Implementation: Static/Dynamic
DRV_NVM_Open Opens the specified NVM driver instance and returns a handle to it
Implementation: Static/Dynamic
DRV_NVM_Read Reads blocks of data from the specified address in memory.
Implementation: Static/Dynamic
DRV_NVM_Status Gets the current status of the NVM driver module.
Implementation: Static/Dynamic
DRV_NVM_Tasks Maintains the driver's erase and write state machine and implements its ISR.
Implementation: Static/Dynamic
DRV_NVM_Write Writes blocks of data starting from the specified address in flash memory.
Implementation: Static/Dynamic
Macros
Name Description
DRV_NVM_COMMAND_HANDLE_INVALID This value defines the NVM Driver's Invalid Command Handle.
DRV_NVM_INDEX_0 NVM driver index definitions
DRV_NVM_INDEX_1 This is macro DRV_NVM_INDEX_1.
DRV_NVM_PAGE_SIZE Specifies the NVM Driver Program Page Size in bytes.
DRV_NVM_ROW_SIZE Specifies the NVM Driver Program Row Size in bytes.
Structures
Name Description
DRV_NVM_INIT Defines the data required to initialize or reinitialize the NVM driver
Types
Name Description
DRV_NVM_COMMAND_HANDLE Handle identifying commands queued in the driver.
DRV_NVM_EVENT_HANDLER Pointer to a NVM Driver Event handler function
Description
NVM Driver Interface Definition
The NVM driver provides a simple interface to manage the Non Volatile Flash Memory on Microchip microcontrollers. This file defines the interface
definition for the NVM driver.
File Name
drv_nvm.h
Company
Microchip Technology Inc.
Volume V: MPLAB Harmony Framework Driver Libraries Help NVM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 677
drv_nvm_config_template.h
NVM driver configuration definitions.
Macros
Name Description
DRV_NVM_BUFFER_OBJECT_NUMBER Selects the maximum number of buffer objects
DRV_NVM_CLIENTS_NUMBER Selects the maximum number of clients
DRV_NVM_DISABLE_ERROR_CHECK Disables the error checks in the driver.
DRV_NVM_ERASE_WRITE_ENABLE Enables support for NVM Driver Erase Write Feature.
DRV_NVM_INSTANCES_NUMBER Selects the maximum number of Driver instances that can be supported by the
dynamic driver.
DRV_NVM_INTERRUPT_MODE Macro specifies operation of the driver to be in the interrupt mode or polled mode
DRV_NVM_MEDIA_SIZE Specifies the NVM Media size.
DRV_NVM_MEDIA_START_ADDRESS Specifies the NVM Media start address.
DRV_NVM_SYS_FS_REGISTER Register to use with the File system
Description
NVM Driver Configuration Template Header file.
This template file describes all the mandatory and optional configuration macros that are needed for building the NVM driver. Do not include this
file in source code.
File Name
drv_nvm_config_template.h
Company
Microchip Technology Inc.
Output Compare Driver Library
This section describes the Output Compare Driver Library.
Introduction
The Output Compare Static Driver provides a high-level interface to manage the Output Compare module on the Microchip family of
microcontrollers.
Description
Through the MHC, this driver provides APIs for the following:
• Initializing the module
• Enabling/Disabling of the output compare
• Starting/Stopping of the output compare
• Fault checking
Library Interface
Functions
Name Description
DRV_OC_Disable Disables the Output Compare instance for the specified driver index.
Implementation: Static
DRV_OC_Enable Enables the Output Compare for the specified driver index.
Implementation: Static
DRV_OC_FaultHasOccurred Checks if a Fault has occurred for the specified driver index.
Implementation: Static
DRV_OC_Initialize Initializes the Comparator instance for the specified driver index.
Implementation: Static
Volume V: MPLAB Harmony Framework Driver Libraries Help Output Compare Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 678
DRV_OC_Start Starts the Comparator instance for the specified driver index.
Implementation: Static
DRV_OC_Stop Stops the Output Compare instance for the specified driver index.
Implementation: Static
Description
This section describes the Application Programming Interface (API) functions of the Output Compare Driver Library.
Functions
DRV_OC_Disable Function
Disables the Output Compare instance for the specified driver index.
Implementation: Static
File
help_drv_oc.h
C
void DRV_OC_Disable();
Returns
None.
Description
This routine disables the Output Compare for the specified driver instance, making it ready for clients to use it. The initialization routine is specified
by the MHC parameters.
Remarks
None.
Preconditions
DRV_OC_Initialize has been called.
Function
void DRV_OC_Disable( void )
DRV_OC_Enable Function
Enables the Output Compare for the specified driver index.
Implementation: Static
File
help_drv_oc.h
C
void DRV_OC_Enable();
Returns
None.
Description
This routine enables the Output Compare for the specified driver instance, making it ready for clients to use it. The initialization routine is specified
by the MHC parameters.
Remarks
None.
Preconditions
DRV_OC_Initialize has been called.
Volume V: MPLAB Harmony Framework Driver Libraries Help Output Compare Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 679
Function
void DRV_OC_Enable( void )
DRV_OC_FaultHasOccurred Function
Checks if a Fault has occurred for the specified driver index.
Implementation: Static
File
help_drv_oc.h
C
bool DRV_OC_FaultHasOccurred();
Returns
Boolean
• 1 - A Fault has occurred
• 0 - A Fault has not occurred
Description
This routine checks whether or not a Fault has occurred for the specified driver index. The initialization routine is specified by the MHC parameters.
Remarks
None.
Preconditions
DRV_OC_Initialize has been called.
Function
bool DRV_OC_FaultHasOccurred( void )
DRV_OC_Initialize Function
Initializes the Comparator instance for the specified driver index.
Implementation: Static
File
help_drv_oc.h
C
void DRV_OC_Initialize();
Returns
None.
Description
This routine initializes the Output Compare driver instance for the specified driver instance, making it ready for clients to use it. The initialization
routine is specified by the MHC parameters. The driver instance index is independent of the Output Compare module ID. For example, driver
instance 0 can be assigned to Output Compare 1.
Remarks
This routine must be called before any other Comparator routine is called. This routine should only be called once during system initialization.
Preconditions
None.
Function
void DRV_OC_Initialize( void )
Volume V: MPLAB Harmony Framework Driver Libraries Help Output Compare Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 680
DRV_OC_Start Function
Starts the Comparator instance for the specified driver index.
Implementation: Static
File
help_drv_oc.h
C
void DRV_OC_Start();
Returns
None.
Description
This routine starts the Output Compare for the specified driver instance.
Remarks
None.
Preconditions
DRV_OC_Initialize has been called.
Function
void DRV_OC_Start( void )
DRV_OC_Stop Function
Stops the Output Compare instance for the specified driver index.
Implementation: Static
File
help_drv_oc.h
C
void DRV_OC_Stop();
Returns
None.
Description
This routine stops the Output Compare for the specified driver instance.
Remarks
None.
Preconditions
DRV_OC_Initialize has been called.
Function
void DRV_OC_Stop( void )
Parallel Master Port (PMP) Driver Library
This section describes the Parallel Master Port Driver Library.
Introduction
This library provides an interface to manage the Parallel Master Port (PMP) module on Microchip family of microcontrollers in different modes of
operation.
Volume V: MPLAB Harmony Framework Driver Libraries Help Parallel Master Port (PMP) Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 681
Description
The Parallel Master Port (PMP) is a parallel 8-bit/16-bit I/O module specifically designed to communicate with a wide variety of parallel devices
such as communications peripherals, LCDs, external memory devices and microcontrollers. Because the interfaces to parallel peripherals vary
significantly, the PMP module is highly configurable.
The following figure shows a generic block diagram, which illustrates the ways the PMP module can be used:
The PMP module can be used in different modes. Master and Slave are the two modes that can have additional sub-modes, depending on the
different microcontroller families.
Master Mode: In Master mode, the PMP module can provide a 8-bit or 16-bit data bus, up to 16 bits of address, and all of the necessary control
signals to operate a variety of external parallel devices such as memory devices, peripherals and slave microcontrollers. The PMP master modes
provide a simple interface for reading and writing data, but not executing program instructions from external devices, such as SRAM or Flash
memories.
Slave Mode: Slave mode only supports 8-bit data and the module control pins are automatically dedicated when this mode is selected.
Using the Library
This topic describes the basic architecture of the PMP Driver Library and provides information and examples on its use.
Description
Interface Header File: drv_pmp.h
The interface to the PMP Driver library is defined in the drv_pmp.h header file. This file is included by the drv.h file. Any C language source (.c)
file that uses the PMP Driver Library should include drv.h.
Please refer to the What is MPLAB Harmony? section for how the driver interacts with the framework.
Abstraction Model
This library provides a low-level abstraction of the Parallel Master Port (PMP) module on Microchip's microcontrollers with a convenient C
language interface. This topic describes how that abstraction is modeled in software and introduces the library's interface.
Description
Hardware Abstraction Model Description
Depending on the device,the PMP module provides interface routines to interact with external peripherals such as LCD, EEPROM, Flash memory,
etc., as shown in the following diagram. The diagram shows the PMP module acting as a master. The PMP module can be easily configured to act
as a slave. The address and data lines can be multiplexed to suit the application. The address and data buffers are up to 2-byte (16-bit) buffers for
data transmitted or received by the parallel interface to the PMP bus over the data and address lines synchronized with control logic including the
read and write strobe.
The desired timing wait states to suit different peripheral timings can also be programmed using the PMP module.
Volume V: MPLAB Harmony Framework Driver Libraries Help Parallel Master Port (PMP) Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 682
PMP Hardware Abstraction Model Diagram
Library Overview
Refer to the Driver Library Overview section for information on how the driver operates in a system.
The library interface routines are divided into various sub-sections, which address one of the blocks or the overall operation of the PMP module.
Library Interface Section Description
System Functions Provides system module interfaces, device initialization, deinitialization, reinitialization, tasks, and status functions.
Client Interaction Functions Provides open, close, client status and client mode configuration functions.
Client Transfer Functions Provides interface for data transfer in master and slave mode.
Miscellaneous Provides driver miscellaneous functions, version identification functions, etc.
How the Library Works
This section describes how the PMP Driver Library operates.
Description
Before the driver is ready for use, its should be configured (compile time configuration). Refer to the Configuring the Library section for more
details on how to configure the driver.
There are few run-time configuration items that are done during initialization of the driver instance, and a few that are client-specific and are done
using dedicated functions.
To use the PMP Driver, initialization and client functions should be invoked in a specific sequence to ensure correct operation.
The following is the sequence in which various routines should be called:
1. Call DRV_PMP_Initialize to initialize the PMP Driver. Note that this may be performed by the MPLAB Harmony system module. The
DRV_PMP_Status function may be used to check the status of the initialization.
2. Once initialization for a particular driver instance is done, the client wanting to use the driver can open it using DRV_PMP_Open.
3. The DRV_PMP_ModeConfig function should now be called, which will configure the driver for the exact mode of operation required by that
client.
4. After configuring the mode, DRV_PMP_Write and/or DRV_PMP_Read can be called by the user application to Write/Read using the PMP
module. Calling these functions does not start the PMP transfer immediately in non-interrupt mode. Instead, all of these transfer tasks are
queued in an internal queue. Actual transfer starts only when the PMP Task function is called by the system/user. In interrupt mode, although
transfer tasks are queued, the actual transfer starts immediately.
5. PMP Write and Read functions return an ID of that particular transfer, which should be saved by user to get the status of that transfer later.
6. The system will either call DRV_PMP_Tasks from the System Task Service (in a polled environment), or it will be called from the ISR of the
PMP.
7. At any time status of the transfer can be obtained by using DRV_PMP_TransferStatus.
Note:
Not all modes are available on all devices. Please refer to the specific device data sheet to determine the supported modes.
System Initialization
This section describes initialization and reinitialization features.
Description
Initialization and Reinitialization
The system performs the initialization and the reinitialization of the device driver with settings that affect only the instance of the device that is
being initialized or reinitialized. During system initialization each instance of the PMP device will be initialized with the following configuration
settings:
Initialization Member Description
moduleInit System module initialization of the power state.
pmpId PMP hardware module ID (peripheral library-level ID).
stopInIdle Decide whether or not the module should be stopped in Idle mode.
muxMode To select one of the different multiplexing modes possible for PMP module.
inputBuffer Select the type of Input Buffer (TTL or Schmitt Trigger).
Volume V: MPLAB Harmony Framework Driver Libraries Help Parallel Master Port (PMP) Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 683
polarity Select polarity of different PMP pins.
ports Set the pins the user wants to use as port or PMP pins.
The DRV_PMP_Initialize function returns an object handle of the type SYS_MODULE_OBJ. After this, the object handle returned by the initialize
interface would be used by the other system interfaces, such as DRV_PMP_Reinitialize, DRV_PMP_Deinitialize, DRV_PMP_Status, and
DRV_PMP_Tasks.
Example for PMP Initialization Through the DRV_PMP_INIT Structure
DRV_PMP_INIT init;
SYS_MODULE_OBJ object;
SYS_STATUS pmpStatus;
// populate the PMP init configuration structure
init.inputBuffer = PMP_INPUT_BUFFER_TTL;
init.polarity.addressLatchPolarity = PMP_POLARITY_ACTIVE_HIGH;
init.polarity.rwStrobePolarity = PMP_POLARITY_ACTIVE_LOW;
init.polarity.writeEnableStrobePolarity = PMP_POLARITY_ACTIVE_LOW;
init.polarity.chipselect1Polarity = PMP_POLARITY_ACTIVE_HIGH;
init.polarity.chipselect2Polarity = PMP_POLARITY_ACTIVE_LOW;
init.ports.addressPortsMask = PMP_PMA0_PORT | PMP_PMA1_PORT | PMP_PMA2_TO_PMA13_PORTS | PMP_PMA14_PORT;
init.ports.readWriteStrobe = PORT_ENABLE;
init.ports.writeEnableStrobe = PORT_ENABLE;
init.moduleInit.value = SYS_MODULE_POWER_RUN_FULL;
init.pmpID = PMP_ID_0;
init.stopInIdle = false;
init.muxMode = PMP_MUX_NONE;
object = DRV_PMP_Initialize (DRV_PMP_INDEX_0, (SYS_MODULE_INIT *)&init);
pmpStatus = DRV_PMP_Status(object);
if ( SYS_STATUS_READY != pmpStatus)
{
// Handle error
}
Deinitialization
Once the initialize operation has been called, the deinitialize operation must be called before the initialize operation can be called again. This
routine may block if the driver is running in an OS environment that supports blocking operations and the driver requires system resources access.
However, the function will never block for hardware PMP access. If the operation requires time to allow the hardware to complete, which will be
reported by DRV_PMP_Status.
Status
PMP status is available to query the module state before, during and after initialization, deinitialization, and reinitialization.
Tasks Routine
The DRV_PMP_Tasks function will see the queue status and perform the task of transferring the data accordingly. In the Blocking mode when
interrupts are disabled, it will finish one of the tasks completely (that means emptying one space in queue), and then return back. Whereas in
Non-Blocking mode, it will return back just after starting one word (8-bit or 16-bit) of transfer (may not be emptying one space in the queue, as that
task may not be completely finished).
The DRV_PMP_Tasks function can be called in two ways:
• By the system task service in a polled environment
• By the ISR of the PMP in an interrupt-based system
Example: Polling
int main( void )
{
SYS_MODULE_OBJ object;
object = DRV_PMP_Initialize( DRV_PMP_INDEX_0, (SYS_MODULE_INIT *) &initConf );
if( SYS_STATUS_READY != DRV_PMP_Status( object ) )
return 0;
while (1)
{
DRV_PMP_Tasks (object);
Volume V: MPLAB Harmony Framework Driver Libraries Help Parallel Master Port (PMP) Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 684
}
}
Example: Interrupt
int main( void )
{
SYS_MODULE_OBJ object;
object = DRV_PMP_Initialize( DRV_PMP_INDEX_0, (SYS_MODULE_INIT *) &initConf );
if( SYS_STATUS_READY != DRV_PMP_Status( object ) )
return 0;
while (1);
}
/* Sample interrupt routine not specific to any device family */
void ISR PMPInterrupt(void)
{
//Call the PMP Tasks routine
DRV_PMP_Tasks(object);
}
Note:
A PMP transfer in Blocking mode in an interrupt environment is not supported.
Transfer Operation
This section describes transfer operation.
Description
Once the PMP Driver is open and configured for a client, it is set to start Reading/Writing through DRV_PMP_Read and DRV_PMP_Write.
However, these functions will not directly start reading or writing. These will just put the relevant information in a queue in non-interrupt mode and
return an ID that can be used later for checking the transfer status. In Interrupt mode, the Read/Write functions will trigger the transfer immediately
after storing the transfer information in the queue.
The user must use a buffer pointing to character for data values.
The repeatCount parameter allows the user to repeatedly write the same nBytes of data into the slave devices.
Example:
unsigned char myReadBuffer[300], myWriteBuffer[100]; // has to be 'char' arrays
uint32_t deviceAddress, nBytes, repeatCount, i;
uint32_t writeID, readID;
DRV_HANDLE handle;
//initialize, open and configure the driver/client
/* ... */
deviceAddress = 0x0206;
nBytes = 100;
repeatCount = 0x01;
for (i=0; i/framework/driver/pmp.
Volume V: MPLAB Harmony Framework Driver Libraries Help Parallel Master Port (PMP) Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 689
Interface File(s)
This table lists and describes the header files that must be included (i.e., using #include) by any code that uses this library.
Source File Name Description
/drv_pmp.h This file provides the interface definitions of the PMP driver
Required File(s)
All of the required files listed in the following table are automatically added into the MPLAB X IDE project by the MHC
when the library is selected for use.
This table lists and describes the source and header files that must always be included in the MPLAB X IDE project to build this library.
Source File Name Description
/src/dynamic/drv_pmp_dynamic.c This file contains the core implementation of the PMP driver.
Optional File(s)
This table lists and describes the source and header files that may optionally be included if required for the desired implementation.
Source File Name Description
N/A No optional files are available for this library
Module Dependencies
The PMP Driver Library depends on the following modules:
• PMP Peripheral Library
• Interrupt System Service Library
Library Interface
a) System Functions
Name Description
DRV_PMP_Deinitialize Deinitializes the specified instance of the PMP driver module.
Implementation: Dynamic
DRV_PMP_Initialize Initializes the PMP driver.
Implementation: Static/Dynamic
DRV_PMP_Reinitialize Reinitializes the driver and refreshes any associated hardware settings.
Implementation: Dynamic
DRV_PMP_Status Provides the current status of the PMP driver module.
Implementation: Dynamic
DRV_PMP_Tasks Maintains the driver's state machine and implements its ISR.
Implementation: Dynamic
DRV_PMP_TimingSet Sets PMP timing parameters.
Implementation: Static
b) Client Interaction Functions
Name Description
DRV_PMP_ClientStatus Gets the current client-specific status of the PMP driver.
Implementation: Dynamic
DRV_PMP_Close Closes an opened instance of the PMP driver.
Implementation: Dynamic
DRV_PMP_ModeConfig Configures the PMP modes.
Implementation: Static/Dynamic
DRV_PMP_Open Opens the specified PMP driver instance and returns a handle to it.
Implementation: Dynamic
DRV_PMP_Read Read the data from external device.
Implementation: Static/Dynamic
DRV_PMP_Write Transfers the data from the MCU to the external device.
Implementation: Static/Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help Parallel Master Port (PMP) Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 690
c) Client Transfer Functions
Name Description
DRV_PMP_TransferStatus Returns the transfer status.
Implementation: Dynamic
e) Data Types and Constants
Name Description
DRV_PMP_INDEX_COUNT Number of valid PMP driver indices.
DRV_PMP_CHIPX_STROBE_MODE PMP writeEnable/ReadWrite strobes.
DRV_PMP_CLIENT_STATUS PMP client status definitions.
DRV_PMP_ENDIAN_MODE PMP Endian modes.
DRV_PMP_INDEX PMP driver index definitions.
DRV_PMP_INIT Defines the PMP driver initialization data.
DRV_PMP_MODE_CONFIG PMP modes configuration.
DRV_PMP_POLARITY_OBJECT PMP polarity object.
DRV_PMP_PORT_CONTROL PMP port enable/disable definitions.
DRV_PMP_PORTS PMP port configuration.
DRV_PMP_QUEUE_ELEMENT_OBJ Defines the object for PMP queue element.
_DRV_PMP_QUEUE_ELEMENT_OBJ Defines the object for PMP queue element.
DRV_PMP_TRANSFER_STATUS Defines the PMP transfer status.
DRV_PMP_WAIT_STATES PMP wait states object.
MAX_NONBUFFERED_BYTE_COUNT After this number the PMP transfer should be polled to guarantee data transfer
DRV_PMP_TRANSFER_TYPE This is type DRV_PMP_TRANSFER_TYPE.
PMP_QUEUE_ELEMENT_OBJECT Defines the structure required for maintaining the queue element.
Description
This section describes the Application Programming Interface (API) functions of the PMP Driver.
Refer to each section for a detailed description.
a) System Functions
DRV_PMP_Deinitialize Function
Deinitializes the specified instance of the PMP driver module.
Implementation: Dynamic
File
drv_pmp.h
C
void DRV_PMP_Deinitialize(const SYS_MODULE_OBJ pmpDriverObject);
Returns
None.
Description
This function deinitializes the specified instance of the PMP driver module, disabling its operation (and any hardware). All internal data is
invalidated.
Remarks
Once the Initialize operation has been called, the Deinitialize operation must be called before the Initialize operation can be called again.
This function will NEVER block waiting for hardware. If the operation requires time to allow the hardware to complete, this will be reported by the
DRV_PMP_Status operation. The system has to use DRV_PMP_Status to find out when the module is in the ready state.
Preconditions
The DRV_PMP_Initialize function must have been called before calling this routine and a valid SYS_MODULE_OBJ must have been returned.
Volume V: MPLAB Harmony Framework Driver Libraries Help Parallel Master Port (PMP) Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 691
Example
SYS_MODULE_OBJ pmpDriverObject; // Returned from DRV_PMP_Initialize
SYS_STATUS status;
DRV_PMP_Deinitialize(pmpDriverObject);
status = DRV_PMP_Status(pmpDriverObject);
if (SYS_MODULE_DEINITIALIZED == status)
{
// Check again later if you need to know
// when the driver is deinitialized.
}
Parameters
Parameters Description
pmpDriverObject Driver object handle, returned from the DRV_PMP_Initialize
Function
void DRV_PMP_Deinitialize ( SYS_MODULE_OBJ pmpDriverObject )
DRV_PMP_Initialize Function
Initializes the PMP driver.
Implementation: Static/Dynamic
File
drv_pmp.h
C
SYS_MODULE_OBJ DRV_PMP_Initialize(const SYS_MODULE_INDEX drvIndex, const SYS_MODULE_INIT * const init);
Returns
If successful, it returns a valid handle to a driver object. Otherwise, it returns SYS_MODULE_OBJ_INVALID. The returned object must be passed
as argument to DRV_PMP_Reinitialize, DRV_PMP_Deinitialize, DRV_PMP_Tasks and DRV_PMP_Status routines.
Description
This function initializes the PMP driver, making it ready for clients to open and use it.
Remarks
This function must be called before any other PMP function is called.
This function should only be called once during system initialization unless DRV_PMP_Deinitialize is called to deinitialize the driver instance.
This function will NEVER block for hardware access. If the operation requires time to allow the hardware to reinitialize, it will be reported by the
DRV_PMP_Status operation. The system must use DRV_PMP_Status to find out when the driver is in the ready state.
Build configuration options may be used to statically override options in the "init" structure and will take precedence over initialization data passed
using this function.
Preconditions
None.
Example
DRV_PMP_INIT init;
SYS_MODULE_OBJ objectHandle;
// Populate the initialization structure
init.inputBuffer = PMP_INPUT_BUFFER_TTL;
init.polarity.addressLatchPolarity = PMP_POLARITY_ACTIVE_HIGH;
init.polarity.rwStrobePolarity = PMP_POLARITY_ACTIVE_LOW;
init.polarity.writeEnableStrobePolarity = PMP_POLARITY_ACTIVE_LOW;
init.polarity.chipselect1Polarity = PMP_POLARITY_ACTIVE_HIGH;
init.polarity.chipselect2Polarity = PMP_POLARITY_ACTIVE_LOW;
init.ports.addressPortsMask = PMP_PMA0_PORT | PMP_PMA1_PORT | PMP_PMA2_TO_PMA13_PORTS | PMP_PMA14_PORT;
init.ports.readWriteStrobe = PORT_ENABLE;
init.ports.writeEnableStrobe = PORT_ENABLE;
Volume V: MPLAB Harmony Framework Driver Libraries Help Parallel Master Port (PMP) Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 692
init.moduleInit.value = SYS_MODULE_POWER_RUN_FULL;
init.pmpID = PMP_ID_0;
init.stopInIdle = false;
init.muxMode = PMP_MUX_NONE;
// Do something
objectHandle = DRV_PMP_Initialize(DRV_PMP_INDEX_0, (SYS_MODULE_INIT*)&init);
if (SYS_MODULE_OBJ_INVALID == objectHandle)
{
// Handle error
}
Parameters
Parameters Description
drvIndex Index for the driver instance to be initialized
init Pointer to a data structure containing any data necessary to initialize the driver
Function
SYS_MODULE_OBJ DRV_PMP_Initialize( const SYS_MODULE_INDEX drvIndex,
const SYS_MODULE_INIT * const init )
DRV_PMP_Reinitialize Function
Reinitializes the driver and refreshes any associated hardware settings.
Implementation: Dynamic
File
drv_pmp.h
C
void DRV_PMP_Reinitialize(const SYS_MODULE_OBJ pmpDriverObject, const SYS_MODULE_INIT * const init);
Returns
None.
Description
This function reinitializes the driver and refreshes any associated hardware settings using the specified initialization data, but it will not interrupt
any ongoing operations.
Remarks
This function can be called multiple times to reinitialize the module.
This operation can be used to refresh any supported hardware registers as specified by the initialization data or to change the power state of the
module.
This function will NEVER block for hardware access. If the operation requires time to allow the hardware to re-initialize, it will be reported by the
DRV_PMP_Status operation. The system must use DRV_PMP_Status to find out when the driver is in the ready state.
Build configuration options may be used to statically override options in the "init" structure and will take precedence over initialization data passed
using this function.
Preconditions
The DRV_PMP_Initialize function must have been called before calling this function and a valid SYS_MODULE_OBJ must have been returned.
Example
DRV_PMP_INIT init;
SYS_MODULE_OBJ pmpDriverObject;
SYS_STATUS pmpStatus;
// Populate the initialization structure
init.inputBuffer = PMP_INPUT_BUFFER_TTL;
init.polarity.addressLatchPolarity = PMP_POLARITY_ACTIVE_HIGH;
init.polarity.rwStrobePolarity = PMP_POLARITY_ACTIVE_LOW;
init.polarity.writeEnableStrobePolarity = PMP_POLARITY_ACTIVE_LOW;
Volume V: MPLAB Harmony Framework Driver Libraries Help Parallel Master Port (PMP) Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 693
init.polarity.chipselect1Polarity = PMP_POLARITY_ACTIVE_HIGH;
init.polarity.chipselect2Polarity = PMP_POLARITY_ACTIVE_LOW;
init.ports.addressPortsMask = PMP_PMA0_PORT | PMP_PMA1_PORT | PMP_PMA2_TO_PMA13_PORTS | PMP_PMA14_PORT;
init.ports.readWriteStrobe = PORT_ENABLE;
init.ports.writeEnableStrobe = PORT_ENABLE;
init.moduleInit.value = SYS_MODULE_POWER_RUN_FULL;
init.pmpID = PMP_ID_0;
init.stopInIdle = false;
init.muxMode = PMP_MUX_NONE;
DRV_PMP_Reinitialize(pmpDriverObject, (SYS_MODULE_INIT*)&init);
pmpStatus = DRV_PMP_Status(pmpDriverObject);
if (SYS_STATUS_BUSY == pmpStatus)
{
// Check again later to ensure the driver is ready
}
else if (SYS_STATUS_ERROR >= pmpStatus)
{
// Handle error
}
Parameters
Parameters Description
pmpDriverObject Driver object handle, returned from the DRV_PMP_Initialize
Function
void DRV_PMP_Reinitialize ( SYS_MODULE_OBJ pmpDriverObject,
const SYS_MODULE_INIT * const init )
init - Pointer to the initialization data structure
DRV_PMP_Status Function
Provides the current status of the PMP driver module.
Implementation: Dynamic
File
drv_pmp.h
C
SYS_STATUS DRV_PMP_Status(const SYS_MODULE_OBJ pmpDriverObject);
Returns
SYS_STATUS_READY - Indicates that the driver is busy with a previous system level operation and cannot start another
Description
This function provides the current status of the PMP driver module.
Remarks
Any value greater than SYS_STATUS_READY is also a normal running state in which the driver is ready to accept new operations.
SYS_STATUS_BUSY - Indicates that the driver is busy with a previous system level operation and cannot start another
SYS_STATUS_ERROR - Indicates that the driver is in an error state
Any value less than SYS_STATUS_ERROR is also an error state.
SYS_MODULE_DEINITIALIZED - Indicates that the driver has been deinitialized
This value is less than SYS_STATUS_ERROR.
This operation can be used to determine when any of the driver's module level operations has completed.
If the status operation returns SYS_STATUS_BUSY, a previous operation has not yet completed. Once the status operation returns
SYS_STATUS_READY, any previous operations have completed.
The value of SYS_STATUS_ERROR is negative (-1). Any value less than that is also an error state.
This function will NEVER block waiting for hardware.
Volume V: MPLAB Harmony Framework Driver Libraries Help Parallel Master Port (PMP) Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 694
If the Status operation returns an error value, the error may be cleared by calling the reinitialize operation. If that fails, the deinitialize operation will
need to be called, followed by the initialize operation to return to normal operations.
Preconditions
The DRV_PMP_Initialize function must have been called before calling this function.
Example
SYS_MODULE_OBJ pmpDriverObject; // Returned from DRV_PMP_Initialize
SYS_STATUS status;
status = DRV_PMP_Status(pmpDriverObject);
else if (SYS_STATUS_ERROR >= status)
{
// Handle error
}
Parameters
Parameters Description
pmpDriverObject Driver object handle, returned from the DRV_PMP_Initialize routine
Function
SYS_STATUS DRV_PMP_Status ( SYS_MODULE_OBJ pmpDriverObject )
DRV_PMP_Tasks Function
Maintains the driver's state machine and implements its ISR.
Implementation: Dynamic
File
drv_pmp.h
C
void DRV_PMP_Tasks(SYS_MODULE_OBJ pmpDriverObject);
Returns
None.
Description
This function is used to maintain the queue and execute the tasks stored in the queue. It resides in the ISR of the PMP for interrupt-driven
implementations.
Remarks
This function is normally not called directly by an application. It is called by the system's Tasks routine (SYS_Tasks) or by the appropriate raw ISR.
This function may execute in an ISR context and will never block or access any resources that may cause it to block.
Preconditions
The DRV_PMP_Initialize function must have been called for the specified PMP driver instance.
Example
SYS_MODULE_OBJ pmpDriverObject; // Returned from DRV_PMP_Initialize
while (true)
{
DRV_PMP_Tasks (pmpDriverObject);
// Do other tasks
}
Parameters
Parameters Description
pmpDriverObject Object handle for the specified driver instance (returned from DRV_PMP_Initialize)
Volume V: MPLAB Harmony Framework Driver Libraries Help Parallel Master Port (PMP) Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 695
Function
void DRV_PMP_Tasks ( SYS_MODULE_OBJ pmpDriverObject );
DRV_PMP_TimingSet Function
Sets PMP timing parameters.
Implementation: Static
File
drv_pmp.h
C
void DRV_PMP_TimingSet(PMP_DATA_WAIT_STATES dataWait, PMP_STROBE_WAIT_STATES strobeWait,
PMP_DATA_HOLD_STATES dataHold);
Returns
None.
Description
This function sets the PMP timing parameters.
Remarks
None.
Preconditions
The DRV_PMP_Initialize function must have been called.
Example
DRV_PMP0_TimingSet(PMP_DATA_WAIT_THREE,PMP_STROBE_WAIT_6,PMP_DATA_HOLD_4);
Parameters
Parameters Description
dataWait Data setup to read/write strobe wait states
strobeWait Read/write strobe wait states
dataHold Data hold time after read/write strobe wait states
Function
void DRV_PMP_TimingSet(
PMP_DATA_WAIT_STATES dataWait,
PMP_STROBE_WAIT_STATES strobeWait,
PMP_DATA_HOLD_STATES dataHold
)
b) Client Interaction Functions
DRV_PMP_ClientStatus Function
Gets the current client-specific status of the PMP driver.
Implementation: Dynamic
File
drv_pmp.h
C
DRV_PMP_CLIENT_STATUS DRV_PMP_ClientStatus(DRV_HANDLE hClient);
Volume V: MPLAB Harmony Framework Driver Libraries Help Parallel Master Port (PMP) Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 696
Returns
A DRV_PMP_CLIENT_STATUS value describing the current status of the driver.
Description
This function gets the client-specific status of the PMP driver associated with the specified handle.
Remarks
This function will not block for hardware access and will immediately return the current status.
Preconditions
The DRV_PMP_Initialize routine must have been called.
DRV_PMP_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE hClient; // Returned from DRV_PMP_Open
DRV_PMP_CLIENT_STATUS pmpClientStatus;
pmpClientStatus = DRV_PMP_ClientStatus(hClient);
if(DRV_PMP_CLIENT_STATUS_ERROR >= pmpClientStatus)
{
// Handle the error
}
Parameters
Parameters Description
hClient A valid open-instance handle, returned from the driver's open routine
Function
DRV_PMP_CLIENT_STATUS DRV_PMP_ClientStatus ( DRV_HANDLE hClient )
DRV_PMP_Close Function
Closes an opened instance of the PMP driver.
Implementation: Dynamic
File
drv_pmp.h
C
void DRV_PMP_Close(const DRV_HANDLE hClient);
Returns
None
Description
This function closes an opened instance of the PMP driver, invalidating the handle.
Remarks
After calling this function, the handle passed in "handle" must not be used with any of the remaining driver routines. A new handle must be
obtained by calling DRV_PMP_Open before the caller may use the driver again.
If DRV_IO_INTENT_BLOCKING was requested and the driver was built appropriately to support blocking behavior call may block until the
operation is complete.
If DRV_IO_INTENT_NON_BLOCKING request the driver client can call the DRV_PMP_Status operation to find out when the module is in the
ready state (the handle is no longer valid).
Usually there is no need for the driver client to verify that the Close operation has completed.
Preconditions
The DRV_PMP_Initialize routine must have been called for the specified PMP driver instance.
DRV_PMP_Open must have been called to obtain a valid opened device handle.
Volume V: MPLAB Harmony Framework Driver Libraries Help Parallel Master Port (PMP) Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 697
Example
DRV_HANDLE hClient; // Returned from DRV_PMP_Open
DRV_PMP_Close(hClient);
Parameters
Parameters Description
hClient A valid open instance handle, returned from the driver's open routine
Function
void DRV_PMP_Close ( DRV_HANDLE hClient )
DRV_PMP_ModeConfig Function
Configures the PMP modes.
Implementation: Static/Dynamic
File
drv_pmp.h
C
void DRV_PMP_ModeConfig(DRV_HANDLE hClient, DRV_PMP_MODE_CONFIG config);
Returns
None.
Description
This function configures the modes for client in which it wants to operate. Different master-slave modes, 8/16 data bits selection, address
increment/decrement, interrupt mode, wait states, etc., can be configured through this function.
Remarks
This function will NEVER block waiting for hardware. If this API is called more than once for a particular client handle, previous config setting of
that client will be overwritten.
Preconditions
Function DRV_PMP_Initialize must have been called. DRV_PMP_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE hClient;
DRV_PMP_MODE_CONFIG config;
config.chipSelect = PMCS1_AND_PMCS2_AS_CHIP_SELECT;
config.endianMode = LITTLE_ENDIAN;
config.incrementMode = PMP_ADDRESS_AUTO_INCREMENT;
config.intMode = PMP_INTERRUPT_NONE;
config.pmpMode = PMP_MASTER_READ_WRITE_STROBES_INDEPENDENT;
config.portSize = PMP_DATA_SIZE_8_BITS;
config.waitStates.dataHoldWait = PMP_DATA_HOLD_2;
config.waitStates.dataWait = PMP_DATA_WAIT_THREE;
config.waitStates.strobeWait = PMP_STROBE_WAIT_5;
DRV_PMP_ModeConfig ( hClient, config );
Parameters
Parameters Description
hClient Client handle obtained from DRV_PMP_Open API
config Structure which will have all the required PMP modes configuration
Function
void DRV_PMP_ModeConfig ( DRV_HANDLE hClient,
DRV_PMP_MODE_CONFIG config )
Volume V: MPLAB Harmony Framework Driver Libraries Help Parallel Master Port (PMP) Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 698
DRV_PMP_Open Function
Opens the specified PMP driver instance and returns a handle to it.
Implementation: Dynamic
File
drv_pmp.h
C
DRV_HANDLE DRV_PMP_Open(const SYS_MODULE_INDEX index, const DRV_IO_INTENT intent);
Returns
If successful, the function returns a valid open-instance handle (a number identifying both the caller and the module instance).
If an error occurs, the return value is DRV_HANDLE_INVALID.
Description
This function opens the specified PMP driver instance and provides a handle that must be provided to all other client-level operations to identify
the caller and the instance of the driver.
Remarks
The handle returned is valid until the DRV_PMP_Close routine is called.
This function will NEVER block waiting for hardware.
If the DRV_IO_INTENT_BLOCKING is requested and the driver was built appropriately to support blocking behavior, other client-level operations
may block waiting on hardware until they are complete.
If DRV_IO_INTENT_NON_BLOCKING is requested the driver client can call the DRV_PMP_ClientStatus operation to find out when the module is
in the ready state.
If the requested intent flags are not supported, the routine will return DRV_HANDLE_INVALID.
Preconditions
The DRV_PMP_Initialize function must have been called before calling this function.
Example
DRV_HANDLE hClient;
hClient = DRV_PMP_Open(DRV_PMP_INDEX_0, DRV_IO_INTENT_EXCLUSIVE);
if (DRV_HANDLE_INVALID == hClient)
{
// Unable to open the driver
}
Parameters
Parameters Description
drvIndex Identifier for the object instance to be opened
intent Zero or more of the values from the enumeration DRV_IO_INTENT ORed together to indicate
the intended use of the driver
Function
DRV_HANDLE DRV_PMP_Open ( const SYS_MODULE_INDEX drvIndex,
const DRV_IO_INTENT intent )
DRV_PMP_Read Function
Read the data from external device.
Implementation: Static/Dynamic
File
drv_pmp.h
C
PMP_QUEUE_ELEMENT_OBJECT* DRV_PMP_Read(DRV_HANDLE hClient, uint32_t address, uint16_t* buffer, uint32_t
Volume V: MPLAB Harmony Framework Driver Libraries Help Parallel Master Port (PMP) Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 699
nBytes);
Returns
Returns the position number of the queue, where the data element was stored. Returns '0' when there is no place in the queue to store the data.
Description
This function reads the given number of data bytes from the given address of the external device to the MCU buffer through the selected PMP
instance. This function should be used for all the master and slave modes. Proper configuration should be done using DRV_PMP_ModeConfig
before calling this function.
Preconditions
The DRV_PMP_Initialize routine must have been called. DRV_PMP_Open must have been called to obtain a valid opened device handle.
DRV_PMP_ModeConfig must have been called to configure the desired mode
Example
DRV_HANDLE hClient; // Returned from DRV_PMP_Open
uint32_t deviceAddress;
uint32_t nBytes;
unsigned char myBuffer[nBytes];
uint32_t transferID;
transferID = DRV_PMP_Read ( hClient, deviceAddress, &myBuffer, nBytes);
Parameters
Parameters Description
hClient A valid open-instance handle, returned from the driver's open routine
address Starting address of the slave device from where data has to be read. It does not have any
significance for legacy slave mode and buffer mode. In PMP enhanced slave mode i.e.
addressable buffer slave mode, this parameter should be the buffer number to be used.
buffer Pointer to the buffer into which the data read through the PMP instance will be placed. Even if
only one word has to be transferred, pointer should be used.
nBytes Number of bytes that need to be read through the PMP instance
Function
uint32_t DRV_PMP_Read ( DRV_HANDLE hClient,
uint32_t address,
unsigned char* buffer,
uint32_t nBytes)
DRV_PMP_Write Function
Transfers the data from the MCU to the external device.
Implementation: Static/Dynamic
File
drv_pmp.h
C
PMP_QUEUE_ELEMENT_OBJECT* DRV_PMP_Write(DRV_HANDLE* hClient, bool address, uint32_t * buffer, uint32_t
nBytes, uint32_t repeatCount);
Returns
Returns a 32-bit ID with which status of the transfer can be checked later. Returns '0' when there is no place in the queue to store the data.
Description
This function transfer the given number of data bytes from the MCU buffer location to the defined address of the external device through the
selected PMP instance. It repeats the operation n (=repeatCount) number of times as well. This function should be used for all the master and
slave modes. Proper configuration should be done using DRV_PMP_ModeConfig before calling this function.
Preconditions
The DRV_PMP_Initialize routine must have been called. DRV_PMP_Open must have been called to obtain a valid opened device handle.
DRV_PMP_ModeConfig must have been called to configure the desired mode.
Volume V: MPLAB Harmony Framework Driver Libraries Help Parallel Master Port (PMP) Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 700
Example
DRV_HANDLE hClient; // Returned from DRV_PMP_Open
uint32_t deviceAddress;
uint32_t nBytes;
unsigned char myBuffer[nBytes];
uint32_t repeatCount;
uint32_t transferID;
transferID = DRV_PMP_MasterWrite ( hClient, deviceAddress, &myBuffer, nBytes, repeatCount);
Parameters
Parameters Description
hClient A valid open-instance handle, returned from the driver's open routine
address Starting address of the slave device where data has to be written. It does not have any
significance for legacy slave mode and buffer mode. In PMP enhanced slave mode (i.e.,
addressable buffer slave mode), this parameter should be the buffer number to be used.
buffer Pointer to MCU Buffer from which the data will be written through the PMP instance. even if
only one word has to be transferred, pointer should be used.
nBytes Total number of bytes that need to be written through the PMP instance
repeatCount Number of times the data set (nBytes of data) to be repeatedly written. This value should be 0
if user does not want any repetition. If repeatCount is greater than 0, then after writing every
nBytes of data, the buffer starts pointing to its first element. Ideally, PMP Address should be in
auto increment/decrement mode for repeatCount greater than 0.
Function
uint32_t DRV_PMP_Write ( DRV_HANDLE hClient,
uint32_t address,
unsigned char* buffer,
uint32_t nBytes,
uint32_t repeatCount)
c) Client Transfer Functions
DRV_PMP_TransferStatus Function
Returns the transfer status.
Implementation: Dynamic
File
drv_pmp.h
C
DRV_PMP_TRANSFER_STATUS DRV_PMP_TransferStatus(PMP_QUEUE_ELEMENT_OBJECT* queueObject);
Returns
A DRV_PMP_TRANSFER_STATUS value describing the current status of the transfer.
Description
This function returns the status of a particular transfer whose ID has been specified as input.
Example
uint32_8 seqID;
DRV_PMP_TRANSFER_STATUS transferStatus;
transferStatus = DRV_PMP_TransferStatus( DRV_PMP_INDEX_0, seqID);
Parameters
Parameters Description
drvIndex Identifier for the object instance to be opened
Volume V: MPLAB Harmony Framework Driver Libraries Help Parallel Master Port (PMP) Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 701
seqID A valid ID returned from read/write transfer functions
Function
DRV_PMP_TRANSFER_STATUS DRV_PMP_TransferStatus( DRV_HANDLE hClient )
d) Miscellaneous Functions
e) Data Types and Constants
DRV_PMP_INDEX_COUNT Macro
Number of valid PMP driver indices.
File
drv_pmp.h
C
#define DRV_PMP_INDEX_COUNT _PMP_EXISTS
Description
PMP Driver Module Index Count
This constant identifies the number of valid PMP driver indices.
Remarks
The value of "_PMP_EXISTS" is derived from device-specific header files defined as part of the peripheral libraries.
DRV_PMP_CHIPX_STROBE_MODE Enumeration
PMP writeEnable/ReadWrite strobes.
File
drv_pmp.h
C
typedef enum {
PMP_RW_STROBE_WITH_ENABLE_STROBE,
PMP_READ_AND_WRITE_STROBES
} DRV_PMP_CHIPX_STROBE_MODE;
Members
Members Description
PMP_RW_STROBE_WITH_ENABLE_STROBE One strobe for read/write and another for enable
PMP_READ_AND_WRITE_STROBES Separate strobes for read and write operations
Description
PMP writeEnable/ReadWrite strobes
This enumeration provides ReadWrite/WriteEnable Strobe definitions.
DRV_PMP_CLIENT_STATUS Enumeration
PMP client status definitions.
File
drv_pmp.h
C
typedef enum {
DRV_PMP_CLIENT_STATUS_INVALID,
PMP_CLIENT_STATUS_CLOSED,
Volume V: MPLAB Harmony Framework Driver Libraries Help Parallel Master Port (PMP) Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 702
DRV_PMP_CLIENT_STATUS_OPEN
} DRV_PMP_CLIENT_STATUS;
Description
PMP Client Status
This enumeration provides various client status possibilities.
DRV_PMP_ENDIAN_MODE Enumeration
PMP Endian modes.
File
drv_pmp.h
C
typedef enum {
LITTLE,
BIG
} DRV_PMP_ENDIAN_MODE;
Members
Members Description
LITTLE Little Endian
BIG Big Endian
Description
PMP Endian modes
This enumeration holds the Endian configuration options.
DRV_PMP_INDEX Enumeration
PMP driver index definitions.
File
drv_pmp.h
C
typedef enum {
DRV_PMP_INDEX_0,
DRV_PMP_INDEX_1
} DRV_PMP_INDEX;
Members
Members Description
DRV_PMP_INDEX_0 First PMP instance
DRV_PMP_INDEX_1 Second PMP instance (not available for now)
Description
PMP Driver Module Index Numbers
These constants provide PMP driver index definitions.
Remarks
These values should be passed into the DRV_PMP_Initialize and DRV_PMP_Open functions to identify the driver instance in use.
DRV_PMP_INIT Structure
Defines the PMP driver initialization data.
File
drv_pmp.h
Volume V: MPLAB Harmony Framework Driver Libraries Help Parallel Master Port (PMP) Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 703
C
typedef struct {
SYS_MODULE_INIT moduleInit;
PMP_MODULE_ID pmpID;
bool stopInIdle;
PMP_MUX_MODE muxMode;
PMP_INPUT_BUFFER_TYPE inputBuffer;
DRV_PMP_POLARITY_OBJECT polarity;
DRV_PMP_PORTS ports;
} DRV_PMP_INIT;
Members
Members Description
SYS_MODULE_INIT moduleInit; module power state info
PMP_MODULE_ID pmpID; module PLIB ID
bool stopInIdle; Stop in Idle enable
PMP_MUX_MODE muxMode; MUX mode
PMP_INPUT_BUFFER_TYPE inputBuffer; Input buffer type to be used
DRV_PMP_POLARITY_OBJECT polarity; Polarity settings
DRV_PMP_PORTS ports; PMP port settings
Description
PMP Driver Initialize Data
This data type defines data required to initialize or reinitialize the PMP driver.
Remarks
Not all the initialization features are available for all devices.
DRV_PMP_MODE_CONFIG Structure
PMP modes configuration.
File
drv_pmp.h
C
typedef struct {
PMP_OPERATION_MODE pmpMode;
PMP_INTERRUPT_MODE intMode;
PMP_INCREMENT_MODE incrementMode;
DRV_PMP_ENDIAN_MODE endianMode;
PMP_DATA_SIZE portSize;
DRV_PMP_WAIT_STATES waitStates;
PMP_CHIPSELECT_FUNCTION chipSelect;
} DRV_PMP_MODE_CONFIG;
Members
Members Description
PMP_OPERATION_MODE pmpMode; PMP Usage Mode Type
PMP_INTERRUPT_MODE intMode; Interrupt mode
PMP_INCREMENT_MODE incrementMode; should be appropriately selected based on read/write requirements and operation mode
setting */ address/buffer increment mode
DRV_PMP_ENDIAN_MODE endianMode; it does not have any significance in PMP slave mode or 8bit data mode */ Endian modes
PMP_DATA_SIZE portSize; Data Port Size
DRV_PMP_WAIT_STATES waitStates; Wait states
PMP_CHIPSELECT_FUNCTION chipSelect; use this when PLIB is fixed
Description
PMP modes configuration
This data type controls the configuration of PMP modes.
Volume V: MPLAB Harmony Framework Driver Libraries Help Parallel Master Port (PMP) Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 704
DRV_PMP_POLARITY_OBJECT Structure
PMP polarity object.
File
drv_pmp.h
C
typedef struct {
PMP_POLARITY_LEVEL addressLatchPolarity;
PMP_POLARITY_LEVEL byteEnablePolarity;
PMP_POLARITY_LEVEL rwStrobePolarity;
PMP_POLARITY_LEVEL writeEnableStrobePolarity;
PMP_POLARITY_LEVEL chipselect1Polarity;
PMP_POLARITY_LEVEL chipselect2Polarity;
} DRV_PMP_POLARITY_OBJECT;
Members
Members Description
PMP_POLARITY_LEVEL addressLatchPolarity; Address latch polarity
PMP_POLARITY_LEVEL byteEnablePolarity; ByteEnable port polarity
PMP_POLARITY_LEVEL rwStrobePolarity; Read/Write strobe polarity
PMP_POLARITY_LEVEL
writeEnableStrobePolarity;
Write/Enable strobe polarity
PMP_POLARITY_LEVEL chipselect1Polarity; ChipSelect-1 Polarity
PMP_POLARITY_LEVEL chipselect2Polarity; chipSelect-2 Polarity
Description
PMP polarity object
This structure holds the polarities of different entities to be configured.
DRV_PMP_PORT_CONTROL Enumeration
PMP port enable/disable definitions.
File
drv_pmp.h
C
typedef enum {
PORT_ENABLE,
PORT_DISABLE
} DRV_PMP_PORT_CONTROL;
Members
Members Description
PORT_ENABLE Enable the given port
PORT_DISABLE Disable the given port
Description
PMP port enable/disable.
This enumeration provides port enable/disable values.
DRV_PMP_PORTS Structure
PMP port configuration.
File
drv_pmp.h
Volume V: MPLAB Harmony Framework Driver Libraries Help Parallel Master Port (PMP) Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 705
C
typedef struct {
PMP_ADDRESS_PORT addressPortsMask;
PMP_PMBE_PORT byteEnablePort;
DRV_PMP_PORT_CONTROL readWriteStrobe;
DRV_PMP_PORT_CONTROL writeEnableStrobe;
} DRV_PMP_PORTS;
Members
Members Description
PMP_ADDRESS_PORT addressPortsMask; User needs to put the address lines which he wants to use in ORed fashion * Address ports
PMP_PMBE_PORT byteEnablePort; Byte enable ports
DRV_PMP_PORT_CONTROL readWriteStrobe; READ/WRITE Strobe PORT
DRV_PMP_PORT_CONTROL
writeEnableStrobe;
WRITE/ENABLE strobe port
Description
PMP Ports
This structure holds the ports (including the address ports) to be configured by the application to function as general purpose I/O (GPIO) or part of
the PMP.
DRV_PMP_QUEUE_ELEMENT_OBJ Structure
Defines the object for PMP queue element.
File
drv_pmp.h
C
typedef struct _DRV_PMP_QUEUE_ELEMENT_OBJ {
struct _DRV_PMP_CLIENT_OBJ * hClient;
uint32_t buffer;
uint16_t* addressBuffer;
uint32_t nTransfers;
int32_t nRepeats;
DRV_PMP_TRANSFER_TYPE type;
} DRV_PMP_QUEUE_ELEMENT_OBJ;
Members
Members Description
struct _DRV_PMP_CLIENT_OBJ * hClient; handle of the client object returned from open API
uint32_t buffer; pointer to the buffer holding the transmitted data
uint16_t* addressBuffer; pointer to the buffer holding the transmitted data
uint32_t nTransfers; number of bytes to be transferred
int32_t nRepeats; number of times the data set has to be transferred repeatedly
DRV_PMP_TRANSFER_TYPE type; PMP Read or Write
Description
PMP Driver Queue Element Object
This defines the object structure for each queue element of PMP. This object gets created for every Read/Write operations APIs.
Remarks
None
DRV_PMP_TRANSFER_STATUS Enumeration
Defines the PMP transfer status.
File
drv_pmp.h
Volume V: MPLAB Harmony Framework Driver Libraries Help Parallel Master Port (PMP) Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 706
C
typedef enum {
MASTER_8BIT_TRANSFER_IN_PROGRESS = PMP_DATA_SIZE_8_BITS,
MASTER_16BIT_TRANSFER_IN_PROGRESS = PMP_DATA_SIZE_16_BITS,
MASTER_8BIT_BUFFER_IN_PROGRESS,
MASTER_16BIT_BUFFER_IN_PROGRESS,
MASTER_8BIT_TRANSFER_CONTINUE,
MASTER_8BIT_BUFFER_CONTINUE,
QUEUED_BUT_PMP_TRANSFER_NOT_STARTED,
PMP_TRANSFER_FINISHED
} DRV_PMP_TRANSFER_STATUS;
Description
Queue Element Transfer Status
This enumeration defines the PMP transfer status.
DRV_PMP_WAIT_STATES Structure
PMP wait states object.
File
drv_pmp.h
C
typedef struct {
PMP_DATA_HOLD_STATES dataHoldWait;
PMP_STROBE_WAIT_STATES strobeWait;
PMP_DATA_WAIT_STATES dataWait;
} DRV_PMP_WAIT_STATES;
Members
Members Description
PMP_DATA_HOLD_STATES dataHoldWait; data hold wait states
PMP_STROBE_WAIT_STATES strobeWait; read/write strobe wait states
PMP_DATA_WAIT_STATES dataWait; data wait strobe wait sates
Description
PMP wait states object
This structure holds the different wait states to be configured. Refer to the PMP PLIB help document for the possible values and meaning of the
different wait states.
MAX_NONBUFFERED_BYTE_COUNT Macro
File
drv_pmp.h
C
#define MAX_NONBUFFERED_BYTE_COUNT 4 /**********************************************************************
After this number the PMP transfer should be polled to guarantee data
transfer
*********************************************************************
*/
Description
After this number the PMP transfer should be polled to guarantee data transfer
DRV_PMP_TRANSFER_TYPE Enumeration
File
drv_pmp.h
Volume V: MPLAB Harmony Framework Driver Libraries Help Parallel Master Port (PMP) Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 707
C
typedef enum {
ADDRESS,
READ,
WRITE,
BUFFERED_WRITE
} DRV_PMP_TRANSFER_TYPE;
Members
Members Description
ADDRESS PMP Address needs to be updated
READ PMP Read Transfer
WRITE PMP Write Transfer
BUFFERED_WRITE PMP Array Write Transfer
Description
This is type DRV_PMP_TRANSFER_TYPE.
PMP_QUEUE_ELEMENT_OBJECT Structure
Defines the structure required for maintaining the queue element.
File
drv_pmp.h
C
typedef struct {
DRV_PMP_QUEUE_ELEMENT_OBJ data;
DRV_PMP_TRANSFER_STATUS eTransferStatus;
uint32_t nTransfersDone;
} PMP_QUEUE_ELEMENT_OBJECT;
Members
Members Description
DRV_PMP_QUEUE_ELEMENT_OBJ data; The PMP Q Element
DRV_PMP_TRANSFER_STATUS
eTransferStatus;
Flag to indicate that the element is in use
uint32_t nTransfersDone; sequence id
Description
Queue Element Object
This defines the structure required for maintaining the queue element.
Remarks
None
Files
Files
Name Description
drv_pmp.h Parallel Master Port (PMP) device driver interface file.
drv_pmp_config.h PMP driver configuration definitions template
Description
This section lists the source and header files used by the PMP Driver Library.
drv_pmp.h
Parallel Master Port (PMP) device driver interface file.
Volume V: MPLAB Harmony Framework Driver Libraries Help Parallel Master Port (PMP) Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 708
Enumerations
Name Description
DRV_PMP_CHIPX_STROBE_MODE PMP writeEnable/ReadWrite strobes.
DRV_PMP_CLIENT_STATUS PMP client status definitions.
DRV_PMP_ENDIAN_MODE PMP Endian modes.
DRV_PMP_INDEX PMP driver index definitions.
DRV_PMP_PORT_CONTROL PMP port enable/disable definitions.
DRV_PMP_TRANSFER_STATUS Defines the PMP transfer status.
DRV_PMP_TRANSFER_TYPE This is type DRV_PMP_TRANSFER_TYPE.
Functions
Name Description
DRV_PMP_ClientStatus Gets the current client-specific status of the PMP driver.
Implementation: Dynamic
DRV_PMP_Close Closes an opened instance of the PMP driver.
Implementation: Dynamic
DRV_PMP_Deinitialize Deinitializes the specified instance of the PMP driver module.
Implementation: Dynamic
DRV_PMP_Initialize Initializes the PMP driver.
Implementation: Static/Dynamic
DRV_PMP_ModeConfig Configures the PMP modes.
Implementation: Static/Dynamic
DRV_PMP_Open Opens the specified PMP driver instance and returns a handle to it.
Implementation: Dynamic
DRV_PMP_Read Read the data from external device.
Implementation: Static/Dynamic
DRV_PMP_Reinitialize Reinitializes the driver and refreshes any associated hardware settings.
Implementation: Dynamic
DRV_PMP_Status Provides the current status of the PMP driver module.
Implementation: Dynamic
DRV_PMP_Tasks Maintains the driver's state machine and implements its ISR.
Implementation: Dynamic
DRV_PMP_TimingSet Sets PMP timing parameters.
Implementation: Static
DRV_PMP_TransferStatus Returns the transfer status.
Implementation: Dynamic
DRV_PMP_Write Transfers the data from the MCU to the external device.
Implementation: Static/Dynamic
Macros
Name Description
DRV_PMP_INDEX_COUNT Number of valid PMP driver indices.
MAX_NONBUFFERED_BYTE_COUNT After this number the PMP transfer should be polled to guarantee data transfer
Structures
Name Description
_DRV_PMP_QUEUE_ELEMENT_OBJ Defines the object for PMP queue element.
DRV_PMP_INIT Defines the PMP driver initialization data.
DRV_PMP_MODE_CONFIG PMP modes configuration.
DRV_PMP_POLARITY_OBJECT PMP polarity object.
DRV_PMP_PORTS PMP port configuration.
DRV_PMP_QUEUE_ELEMENT_OBJ Defines the object for PMP queue element.
DRV_PMP_WAIT_STATES PMP wait states object.
PMP_QUEUE_ELEMENT_OBJECT Defines the structure required for maintaining the queue element.
Volume V: MPLAB Harmony Framework Driver Libraries Help Parallel Master Port (PMP) Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 709
Description
PMP Device Driver Interface
The PMP device driver provides a simple interface to manage the Parallel Master and Slave ports. This file defines the interface definitions and
prototypes for the PMP driver.
File Name
drv_pmp.h
Company
Microchip Technology Inc.
drv_pmp_config.h
PMP driver configuration definitions template
Macros
Name Description
DRV_PMP_CLIENTS_NUMBER Selects the maximum number of clients.
DRV_PMP_INSTANCES_NUMBER Selects the maximum number of hardware instances that can be supported by the dynamic
driver.
DRV_PMP_QUEUE_SIZE PMP queue size for different instances.
Description
PMP Driver Configuration Definitions for the Template Version
These definitions statically define the driver's mode of operation.
File Name
drv_pmp_config_template.h
Company
Microchip Technology Inc.
RTCC Driver Library
This section describes the RTCC Driver Library.
Introduction
The Real-Time Clock Calendar (RTCC) Static Driver provides a high-level interface to manage the RTCC module on the Microchip family of
microcontrollers.
Description
Through the MHC, this driver provides APIs for the following:
• Initializing the module
• Starting/Stopping the RTCC
• Status functions to yield the date/time
• Status functions to yield the alarm date/time
• Clock output control
Library Interface
System Interaction Functions
Name Description
DRV_RTCC_AlarmDateGet Gets the Alarm Date of the RTCC.
Implementation: Static
DRV_RTCC_AlarmTimeGet Gets the Alarm Time of the RTCC.
Implementation: Static
Volume V: MPLAB Harmony Framework Driver Libraries Help RTCC Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 710
DRV_RTCC_ClockOutput Enables Clock Output for the RTCC.
Implementation: Static
DRV_RTCC_DateGet Gets the Date of the RTCC.
Implementation: Static
DRV_RTCC_Initialize Initializes the RTCC instance for the specified driver index.
Implementation: Static
DRV_RTCC_Start Starts the RTCC.
Implementation: Static
DRV_RTCC_Stop Stops the RTCC.
Implementation: Static
DRV_RTCC_TimeGet Gets the time of the RTCC.
Implementation: Static
Description
This section describes the Application Programming Interface (API) functions of the RTCC Driver Library.
System Interaction Functions
DRV_RTCC_AlarmDateGet Function
Gets the Alarm Date of the RTCC.
Implementation: Static
File
help_drv_rtcc.h
C
uint32_t DRV_RTCC_AlarmDateGet();
Returns
uint32_t alarm date value
Description
This routine gets the RTCC alarm date.
Remarks
None.
Preconditions
DRV_RTCC_Initialize has been called.
Function
uint32_t DRV_RTCC_AlarmDateGet( void )
DRV_RTCC_AlarmTimeGet Function
Gets the Alarm Time of the RTCC.
Implementation: Static
File
help_drv_rtcc.h
C
uint32_t DRV_RTCC_AlarmTimeGet();
Returns
uint32_t alarm time value
Volume V: MPLAB Harmony Framework Driver Libraries Help RTCC Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 711
Description
This routine gets the RTCC alarm time.
Remarks
None.
Preconditions
DRV_RTCC_Initialize has been called.
Function
uint32_t DRV_RTCC_AlarmTimeGet( void )
DRV_RTCC_ClockOutput Function
Enables Clock Output for the RTCC.
Implementation: Static
File
help_drv_rtcc.h
C
void DRV_RTCC_ClockOutput();
Returns
None.
Description
This routine enables the clock output for the RTCC
Remarks
None.
Preconditions
DRV_RTCC_Initialize has been called.
Function
void DRV_RTCC_ClockOutput( void )
DRV_RTCC_DateGet Function
Gets the Date of the RTCC.
Implementation: Static
File
help_drv_rtcc.h
C
uint32_t DRV_RTCC_DateGet();
Returns
uint32_t date value
Description
This routine gets the RTCC date.
Remarks
None.
Preconditions
DRV_RTCC_Initialize has been called.
Volume V: MPLAB Harmony Framework Driver Libraries Help RTCC Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 712
Function
uint32_t DRV_RTCC_DateGet( void )
DRV_RTCC_Initialize Function
Initializes the RTCC instance for the specified driver index.
Implementation: Static
File
help_drv_rtcc.h
C
void DRV_RTCC_Initialize();
Returns
None.
Description
This routine initializes the RTCC driver instance for the specified driver instance, making it ready for clients to use it. The initialization routine is
specified by the MHC parameters.
Remarks
This routine must be called before any other RTCC routine is called. This routine should only be called once during system initialization.
Preconditions
None.
Function
void DRV_RTCC_Initialize( void )
DRV_RTCC_Start Function
Starts the RTCC.
Implementation: Static
File
help_drv_rtcc.h
C
void DRV_RTCC_Start();
Returns
None.
Description
This routine starts the RTCC, making it ready for clients to use it.
Remarks
None.
Preconditions
DRV_RTCC_Initialize has been called.
Function
void DRV_RTCC_Start( void )
DRV_RTCC_Stop Function
Stops the RTCC.
Implementation: Static
Volume V: MPLAB Harmony Framework Driver Libraries Help RTCC Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 713
File
help_drv_rtcc.h
C
void DRV_RTCC_Stop();
Returns
None.
Description
This routine stops the RTCC.
Remarks
None.
Preconditions
DRV_RTCC_Initialize has been called.
Function
void DRV_RTCC_Stop( void )
DRV_RTCC_TimeGet Function
Gets the time of the RTCC.
Implementation: Static
File
help_drv_rtcc.h
C
uint32_t DRV_RTCC_TimeGet();
Returns
uint32_t time value
Description
This routine gets the RTCC time.
Remarks
None.
Preconditions
DRV_RTCC_Initialize has been called.
Function
uint32_t DRV_RTCC_TimeGet( void )
Secure Digital (SD) Card Driver Library
This section describes the Secure Digital (SD) Card Driver Library.
Introduction
The SD Card driver provides the necessary interfaces to interact with an SD card. It provides the necessary abstraction for the higher_layer.
Description
A SD Card is a non-volatile memory (Flash memory) card designed to provide high-capacity memory in a small size. Its applications include digital
video camcorders, digital cameras, handheld computers, audio players, and mobile phones.
Volume V: MPLAB Harmony Framework Driver Libraries Help Secure Digital (SD) Card Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 714
Using the Library
This topic describes the basic architecture of the SD Card Driver Library and provides information and examples on its use.
Description
Interface Header File: drv_sdcard.h
The interface to the SD Card Driver library is defined in the drv_sdcard.h header file. This file is included by the drv.h file. Any C language
source (.c) file that uses the SD Card Driver library should include drv.h.
Please refer to the What is MPLAB Harmony? section for how the Driver interacts with the framework.
Abstraction Model
This library provides a low-level abstraction of the SD Card Driver Library on the Microchip family microcontrollers with a convenient C language
interface. This topic describes how that abstraction is modeled in software and introduces the library's interface.
Description
The SD Card driver comes in the_layer below the Partition Manager in the MPLAB Harmony file system architecture and it uses the SPI Driver to
interact with the SD card.
SD Card Driver Software Abstraction Block Diagram
Volume V: MPLAB Harmony Framework Driver Libraries Help Secure Digital (SD) Card Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 715
Library Overview
Refer to the Driver Library Overview section for information on how the driver operates in a system.
The library interface routines are divided into various sub-sections, which address one of the blocks or the overall operation of the SD Card
module.
Library Interface Section Description
System Level Functions Includes functions for initialize the module.
Client Level Functions Functions to open and close a client.
Operation Functions Functions for read and write operations
Module Information Functions Functions for information about the module.
Version Information Functions Functions to get the software version.
How the Library Works
This section describes how the SD Card Driver Library operates.
Description
Note:
Not all modes are available on all devices. Please refer to the specific device data sheet to determine the supported modes.
The library provides interfaces that support:
• Driver Initialization Functionality
• Client Block Data Functionality
• Client Access Functionality
Volume V: MPLAB Harmony Framework Driver Libraries Help Secure Digital (SD) Card Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 716
SD Card Driver Initialization
This section provides information for system initialization and reinitialization.
Description
The system performs the initialization and the reinitialization of the device driver with settings that affect only the instance of the device that is
being initialized or reinitialized. During system initialization each instance of the SD Card module would be initialized with the following
configuration settings (either passed dynamically at run time using DRV_SDCARD_INIT or by using initialization overrides) that are supported by
the specific SD Card device hardware:
• SPI Peripheral ID: Identifies the SPI Peripheral ID to be used for the SD Card Driver
• SPI Index: SPI Driver Index
• SD Card frequency: SD Card communication speed
• SPI Clock source: Peripheral clock used by the SPI
• Write-Protect Port: Port used to check if the SD Card is write protected
• Write-Protect Pin: Pin used to check if the SD Card is write protected
• Chip Select Port: Port used for the SPI Chip Select
• Chip Select Pin: Pin used for the SPI Chip Select
The DRV_SDCARD_Initialize function returns an object handle of the type SYS_MODULE_OBJ. After this, the object handle returned by the
initialize interface would be used by the other system interfaces, such as DRV_SDCARD_Deinitialize, DRV_SDCARD_Status, and
DRV_SDCARD_Tasks.
Note:
The system initialization and the reinitialization settings, only affect the instance of the peripheral that is being initialized or
reinitialized.
Example:
const DRV_SDCARD_INIT drvSDCardInit =
{
.spiId = SPI_ID_2,
.spiIndex = 0,
.sdcardSpeedHz = 20000000,
.spiClk = CLK_BUS_PERIPHERAL_2,
.writeProtectPort = PORT_CHANNEL_F,
.writeProtectBitPosition = PORTS_BIT_POS_1,
.chipSelectPort = PORT_CHANNEL_B,
.chipSelectBitPosition = PORTS_BIT_POS_14,
};
void SYS_Initialize (void *data)
{
.
.
sysObj.drvSDCard = DRV_SDCARD_Initialize(DRV_SDCARD_INDEX_0,(SYS_MODULE_INIT *)&drvSDCardInit);
.
.
}
Tasks Routine
The system will call DRV_SDCARD_Tasks, from system task service to maintain the driver's state machine.
Client Access Operation
This section provides information for general client operation.
Description
General Client Operation
For the application to start using an instance of the module, it must call the DRV_SDCARD_Open function. This provides the configuration
required to open the SD Card instance for operation. If the driver is deinitialized using the function DRV_SDCARD_Deinitialize, the application
must call the DRV_SDCARD_Open function again to set up the instance of the SDCARD.
For the various options available for I/O INTENT please refer to Data Types and Constants in the Library Interface section.
Example:
DRV_HANDLE handle;
handle = DRV_SDCARD_Open(DRV_SDCARD_INDEX_0, DRV_IO_INTENT_EXCLUSIVE);
Volume V: MPLAB Harmony Framework Driver Libraries Help Secure Digital (SD) Card Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 717
if (DRV_HANDLE_INVALID == handle)
{
// Unable to open the driver
}
Client Block Data Operation
This topic provides information on client block data operation.
Description
The SDCARD Driver provides a block interface to access the SD Card. The interface provides functionality to read from and write to the SD Card.
Reading Data from the SD Card:
The following steps outline the sequence to be followed for reading data from the SD Card:
1. The system should have completed necessary initialization and DRV_SDCARD_Tasks should either be running in a polled environment, or in
an interrupt environment.
2. The driver should have been opened with the necessary intent.
3. Invoke the DRV_SDCARD_Read function and pass the pointer where the data is to be stored, block start address and the number of blocks of
data to be read.
4. The client should validate the command handle returned by the DRV_SDCARD_Read function.
DRV_SDCARD_COMMAND_HANDLE_INVALID value indicates that an error has occurred which the client needs to handle.
5. If the request was successful then the client can check the status of the request by invoking the DRV_SDCARD_CommandStatus and passing
the command handle returned by the read request. Alternately the client could use the event handler for notifications from the driver.
6. The client will be able to close itself by calling the DRV_SDCARD_Close.
Example:
// This code shows how to read data from the SD Card
DRV_HANDLE sdcardHandle;
DRV_SDCARD_COMMAND_HANDLE sdcardCommandHandle;
DRV_SDCARD_COMMAND_STATUS commandStatus;
uint8_t readBuf[512];
uint32_t blockAddress;
uint32_t nBlocks;
/* Initialize the block start address and the number of blocks to be read */
blockAddress = 0;
nBlocks = 1;
DRV_SDCARD_Read(sdcardHandle, &sdcardCommandHandle, (uint8_t *)readBuf, blockAddress, nBlocks);
if(DRV_SDCARD_COMMAND_HANDLE_INVALID == sdcardCommandHandle)
{
/* Failed to queue the read request. Handle the error. */
}
// Wait until the command completes. This should not
// be a while loop if part of cooperative multi-tasking
// routine. In that case, it should be invoked in task
// state machine.
commandStatus = DRV_SDCARD_CommandStatus(sdcardHandle, sdcardCommandHandle);
if(DRV_SDCARD_COMMAND_COMPLETED == commandStatus)
{
/* Read completed */
}
else if (DRV_SDCARD_COMMAND_ERROR_UNKNOWN == commandStatus)
{
/* Read Failed */
}
Writing Data to the SD Card:
The following steps outline the sequence to be followed for writing data to the SD Card:
1. The system should have completed necessary initialization and DRV_SDCARD_Tasks should either be running in a polled environment, or in
an interrupt environment.
2. The driver should have been opened with the necessary intent.
3. Invoke the DRV_SDCARD_Write function and pass the pointer to the data to be written, block start address and the number of blocks of data to
be written.
4. The client should validate the command handle returned by the DRV_SDCARD_Write function.
DRV_SDCARD_COMMAND_HANDLE_INVALID value indicates that an error has occurred which the client needs to handle.
5. If the request was successful then the client can check the status of the request by invoking the DRV_SDCARD_CommandStatus and passing
the command handle returned by the write request. Alternately, the client could use the event handler for notifications from the driver.
Volume V: MPLAB Harmony Framework Driver Libraries Help Secure Digital (SD) Card Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 718
6. The client will be able to close itself by calling the DRV_SDCARD_Close.
Example:
// This code shows how to write data to the SD Card
DRV_HANDLE sdcardHandle;
DRV_SDCARD_COMMAND_HANDLE sdcardCommandHandle;
DRV_SDCARD_COMMAND_STATUS commandStatus;
uint8_t writeBuf[512];
uint32_t blockAddress;
uint32_t nBlocks;
/* Initialize the block start address and the number of blocks to be written */
blockAddress = 0;
nBlocks = 1;
/* Populate writeBuf with the data to be written */
DRV_SDCARD_Write(sdcardHandle, &sdcardCommandHandle, (uint8_t *)writeBuf, blockAddress, nBlocks);
if(DRV_SDCARD_COMMAND_HANDLE_INVALID == sdcardCommandHandle)
{
/* Failed to queue the write request. Handle the error. */
}
// Wait until the command completes. This should not
// be a while loop if part of cooperative multi-tasking
// routine. In that case, it should be invoked in task
// state machine.
commandStatus = DRV_SDCARD_CommandStatus(sdcardHandle, sdcardCommandHandle);
if(DRV_SDCARD_COMMAND_COMPLETED == commandStatus)
{
/* Write completed */
}
else if (DRV_SDCARD_COMMAND_ERROR_UNKNOWN == commandStatus)
{
/* Write Failed */
}
Configuring the Library
Macros
Name Description
DRV_SDCARD_CLIENTS_NUMBER Selects the miximum number of clients
DRV_SDCARD_INDEX_MAX SD Card Static Index selection
DRV_SDCARD_INSTANCES_NUMBER Selects the maximum number of hardware instances that can be
supported by the dynamic driver
DRV_SDCARD_POWER_STATE Defines an override of the power state of the SD Card driver.
DRV_SDCARD_SYS_FS_REGISTER Register to use with the File system
DRV_SDCARD_ENABLE_WRITE_PROTECT_CHECK Enable SD Card write protect check.
Description
The configuration of the SD Card Driver is based on the file system_config.h.
This header file contains the configuration selection for the SD Card Driver. Based on the selections made, the SD Card Driver may support the
selected features. These configuration settings will apply to all instances of the SD Card.
This header can be placed anywhere; however, the path of this header needs to be present in the include search path for a successful build. Refer
to the Applications Help section for more details.
DRV_SDCARD_CLIENTS_NUMBER Macro
Selects the miximum number of clients
File
drv_sdcard_config_template.h
C
#define DRV_SDCARD_CLIENTS_NUMBER 1
Volume V: MPLAB Harmony Framework Driver Libraries Help Secure Digital (SD) Card Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 719
Description
SD Card Maximum Number of Clients
This definition select the maximum number of clients that the SD Card driver can support at run time. Not defining it means using a single client.
Remarks
None.
DRV_SDCARD_INDEX_MAX Macro
SD Card Static Index selection
File
drv_sdcard_config_template.h
C
#define DRV_SDCARD_INDEX_MAX 1
Description
SD Card Static Index Selection
SD Card Static Index selection for the driver object reference
Remarks
This index is required to make a reference to the driver object
DRV_SDCARD_INSTANCES_NUMBER Macro
Selects the maximum number of hardware instances that can be supported by the dynamic driver
File
drv_sdcard_config_template.h
C
#define DRV_SDCARD_INSTANCES_NUMBER 1
Description
SD Card hardware instance configuration
This definition selects the maximum number of hardware instances that can be supported by the dynamic driver. Not defining it means using a
static driver.
Remarks
None
DRV_SDCARD_POWER_STATE Macro
Defines an override of the power state of the SD Card driver.
File
drv_sdcard_config_template.h
C
#define DRV_SDCARD_POWER_STATE SYS_MODULE_POWER_IDLE_STOP
Description
SD Card power state configuration
Defines an override of the power state of the SD Card driver.
Remarks
This feature may not be available in the device or the SD Card module selected.
Volume V: MPLAB Harmony Framework Driver Libraries Help Secure Digital (SD) Card Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 720
DRV_SDCARD_SYS_FS_REGISTER Macro
Register to use with the File system
File
drv_sdcard_config_template.h
C
#define DRV_SDCARD_SYS_FS_REGISTER
Description
SDCARD Driver Register with File System
Specifying this macro enables the SDCARD driver to register its services with the SYS FS.
Remarks
This macro is optional and should be specified only if the SDCARD driver is to be used with the File System.
DRV_SDCARD_ENABLE_WRITE_PROTECT_CHECK Macro
Enable SD Card write protect check.
File
drv_sdcard_config_template.h
C
#define DRV_SDCARD_ENABLE_WRITE_PROTECT_CHECK
Description
SDCARD Driver Enable Write Protect Check
Specifying this macro enables the SDCARD driver to check whether the SD card is write protected.
Remarks
None
Building the Library
This section lists the files that are available in the SD Card Driver Library.
Description
The following three tables list and describe the header (.h) and source (.c) files that implement this library. The parent folder for these files is
/framework/driver/sdcard.
Interface File(s)
This table lists and describes the header files that must be included (i.e., using #include) by any code that uses this library.
Source File Name Description
/drv_sdcard.h This file provides the interface definitions of the SD Card driver
Required File(s)
All of the required files listed in the following table are automatically added into the MPLAB X IDE project by the MHC
when the library is selected for use.
This table lists and describes the source and header files that must always be included in the MPLAB X IDE project to build this library.
Source File Name Description
/src/dynamic/drv_sdcard.c This file contains the core implementation of the SD Card driver.
Optional File(s)
This table lists and describes the source and header files that may optionally be included if required for the desired implementation.
Volume V: MPLAB Harmony Framework Driver Libraries Help Secure Digital (SD) Card Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 721
Source File Name Description
N/A No optional files are available for this library
Module Dependencies
The SD Card Driver Library depends on the following modules:
• SPI Driver Library
• Clock System Service Library
• Interrupt System Service Library
• Ports System Service Library
• Timer System Service Library
• Timer Driver Library
Library Interface
a) System Level Functions
Name Description
DRV_SDCARD_Initialize Initializes the SD Card driver.
Implementation: Dynamic
DRV_SDCARD_Deinitialize Deinitializes the specified instance of the SD Card driver module.
Implementation: Dynamic
DRV_SDCARD_Reinitialize Reinitializes the driver and refreshes any associated hardware settings.
Implementation: Dynamic
DRV_SDCARD_Status Provides the current status of the SD Card driver module.
Implementation: Dynamic
DRV_SDCARD_Tasks Maintains the driver's state machine.
Implementation: Dynamic
b) Client Level Functions
Name Description
DRV_SDCARD_Close Closes an opened-instance of the SD Card driver.
Implementation: Dynamic
DRV_SDCARD_Open Opens the specified SD Card driver instance and returns a handle to it.
Implementation: Dynamic
DRV_SDCARD_Read Reads blocks of data from the specified block address of the SD Card.
DRV_SDCARD_Write Writes blocks of data starting at the specified address of the SD Card.
DRV_SDCARD_EventHandlerSet Allows a client to identify an event handling function for the driver to call back when queued
operation has completed.
c) Status Functions
Name Description
DRV_SDCARD_IsAttached Returns the physical attach status of the SD Card.
DRV_SDCARD_IsWriteProtected Returns the write protect status of the SDCARD.
DRV_SDCARD_CommandStatus Gets the current status of the command.
DRV_SDCARD_GeometryGet Returns the geometry of the device.
d) Data Types and Constants
Name Description
DRV_SDCARD_INDEX_0 SD Card driver index definitions
DRV_SDCARD_INDEX_COUNT Number of valid SD Card driver indices
DRV_SDCARD_INIT Contains all the data necessary to initialize the SD Card device
_DRV_SDCARD_INIT Contains all the data necessary to initialize the SD Card device
SDCARD_DETECTION_LOGIC Defines the different system events
SDCARD_MAX_LIMIT Maximum allowed SD card instances
DRV_SDCARD_INDEX_1 This is macro DRV_SDCARD_INDEX_1.
DRV_SDCARD_INDEX_2 This is macro DRV_SDCARD_INDEX_2.
DRV_SDCARD_INDEX_3 This is macro DRV_SDCARD_INDEX_3.
Volume V: MPLAB Harmony Framework Driver Libraries Help Secure Digital (SD) Card Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 722
DRV_SDCARD_COMMAND_HANDLE_INVALID SDCARD Driver's Invalid Command Handle.
DRV_SDCARD_COMMAND_HANDLE Handle identifying commands queued in the driver.
DRV_SDCARD_COMMAND_STATUS Identifies the possible events that can result from a request.
DRV_SDCARD_EVENT Identifies the possible events that can result from a request.
DRV_SDCARD_EVENT_HANDLER Pointer to a SDCARDDriver Event handler function
Description
This section describes the Application Programming Interface (API) functions of the SD Card Driver.
Refer to each section for a detailed description.
a) System Level Functions
DRV_SDCARD_Initialize Function
Initializes the SD Card driver.
Implementation: Dynamic
File
drv_sdcard.h
C
SYS_MODULE_OBJ DRV_SDCARD_Initialize(const SYS_MODULE_INDEX index, const SYS_MODULE_INIT *const init);
Returns
If successful, returns a valid handle to a driver object. Otherwise, it returns SYS_MODULE_OBJ_INVALID.
Description
This routine initializes the SD Card driver, making it ready for clients to open and use the driver.
Remarks
This routine must be called before any other SD Card routine is called.
This routine should only be called once during system initialization unless DRV_SDCARD_Deinitialize is called to deinitialize the driver instance.
This routine will NEVER block for hardware access. If the operation requires time to allow the hardware to reinitialize, it will be reported by the
DRV_SDCARD_Status operation. The system must use DRV_SDCARD_Status to find out when the driver is in the ready state.
Preconditions
None.
Example
DRV_SDCARD_INIT init;
SYS_MODULE_OBJ objectHandle;
// Populate the SD Card initialization structure
objectHandle = DRV_SDCARD_Initialize(DRV_SDCARD_INDEX_0, (SYS_MODULE_INIT*)&init);
if (SYS_MODULE_OBJ_INVALID == objectHandle)
{
// Handle error
}
Parameters
Parameters Description
drvIndex Index for the driver instance to be initialized
init Pointer to a data structure containing any data necessary to initialize the driver.
Function
SYS_MODULE_OBJ DRV_SDCARD_Initialize
(
const SYS_MODULE_INDEX index,
Volume V: MPLAB Harmony Framework Driver Libraries Help Secure Digital (SD) Card Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 723
const SYS_MODULE_INIT * const init
);
DRV_SDCARD_Deinitialize Function
Deinitializes the specified instance of the SD Card driver module.
Implementation: Dynamic
File
drv_sdcard.h
C
void DRV_SDCARD_Deinitialize(SYS_MODULE_OBJ object);
Returns
None.
Description
Deinitializes the specified instance of the SD Card driver module, disabling its operation (and any hardware). Invalidates all the internal data.
Remarks
Once the Initialize operation has been called, the Deinitialize operation must be called before the Initialize operation can be called again.
This routine will NEVER block waiting for hardware. If the operation requires time to allow the hardware to complete, this will be reported by the
DRV_SDCARD_Status operation. The system has to use DRV_SDCARD_Status to check if the de-initialization is complete.
Preconditions
Function DRV_SDCARD_Initialize must have been called before calling this routine and a valid SYS_MODULE_OBJ must have been returned.
Example
SYS_MODULE_OBJ objectHandle; // Returned from DRV_SDCARD_Initialize
SYS_STATUS status;
DRV_SDCARD_Deinitialize(objectHandle);
status = DRV_SDCARD_Status(objectHandle);
if (SYS_MODULE_UNINITIALIZED == status)
{
// Check again later if you need to know
// when the driver is deinitialized.
}
Parameters
Parameters Description
object Driver object handle, returned from the DRV_SDCARD_Initialize routine.
Function
void DRV_SDCARD_Deinitialize
(
SYS_MODULE_OBJ object
);
DRV_SDCARD_Reinitialize Function
Reinitializes the driver and refreshes any associated hardware settings.
Implementation: Dynamic
File
drv_sdcard.h
C
void DRV_SDCARD_Reinitialize(SYS_MODULE_OBJ object, const SYS_MODULE_INIT * const init);
Volume V: MPLAB Harmony Framework Driver Libraries Help Secure Digital (SD) Card Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 724
Returns
None
Description
This routine reinitializes the driver and refreshes any associated hardware settings using the given initialization data, but it will not interrupt any
ongoing operations.
Remarks
This function can be called multiple times to reinitialize the module.
This operation can be used to refresh any supported hardware registers as specified by the initialization data or to change the power state of the
module.
This routine will NEVER block for hardware access. If the operation requires time to allow the hardware to reinitialize, it will be reported by the
DRV_SDCARD_Status operation. The system must use DRV_SDCARD_Status to find out when the driver is in the ready state.
Preconditions
Function DRV_SDCARD_Initialize must have been called before calling this routine and a valid SYS_MODULE_OBJ must have been returned.
Example
DRV_SDCARD_INIT init;
SYS_MODULE_OBJ objectHandle; // Returned from DRV_SDCARD_Initialize
// Update the required fields of the SD Card initialization structure
DRV_SDCARD_Reinitialize (objectHandle, (SYS_MODULE_INIT*)&init);
Parameters
Parameters Description
object Driver object handle, returned from the DRV_SDCARD_Initialize routine
init Pointer to the initialization data structure
Function
void DRV_SDCARD_Reinitialize
(
SYS_MODULE_OBJ object,
const SYS_MODULE_INIT * const init
);
DRV_SDCARD_Status Function
Provides the current status of the SD Card driver module.
Implementation: Dynamic
File
drv_sdcard.h
C
SYS_STATUS DRV_SDCARD_Status(SYS_MODULE_OBJ object);
Returns
SYS_STATUS_READY - Indicates that the driver is busy with a previous system level operation and cannot start another
Note Any value greater than SYS_STATUS_READY is also a normal running state in which the driver is ready to accept new operations.
SYS_STATUS_BUSY - Indicates that the driver is busy with a previous system level operation and cannot start another
SYS_STATUS_ERROR - Indicates that the driver is in an error state
Description
This routine provides the current status of the SD Card driver module.
Remarks
Any value less than SYS_STATUS_ERROR is also an error state.
SYS_MODULE_DEINITIALIZED - Indicates that the driver has been deinitialized
Volume V: MPLAB Harmony Framework Driver Libraries Help Secure Digital (SD) Card Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 725
This value is less than SYS_STATUS_ERROR
This operation can be used to determine when any of the driver's module level operations has completed.
If the status operation returns SYS_STATUS_BUSY, then a previous operation has not yet completed. If the status operation returns
SYS_STATUS_READY, then it indicates that all previous operations have completed.
The value of SYS_STATUS_ERROR is negative (-1). Any value less than that is also an error state.
This routine will NEVER block waiting for hardware.
If the Status operation returns an error value, the error may be cleared by calling the reinitialize operation. If that fails, the deinitialize operation will
need to be called, followed by the initialize operation to return to normal operations.
Preconditions
Function DRV_SDCARD_Initialize must have been called before calling this
Example
SYS_MODULE_OBJ object; // Returned from DRV_SDCARD_Initialize
SYS_STATUS status;
status = DRV_SDCARD_Status(object);
if (SYS_MODULE_UNINITIALIZED == status)
{
// Check again later if you need to know
// when the driver is deinitialized.
}
else if (SYS_STATUS_ERROR >= status)
{
// Handle error
}
Parameters
Parameters Description
object Driver object handle, returned from the DRV_SDCARD_Initialize routine
Function
SYS_STATUS DRV_SDCARD_Status
(
SYS_MODULE_OBJ object
);
DRV_SDCARD_Tasks Function
Maintains the driver's state machine.
Implementation: Dynamic
File
drv_sdcard.h
C
void DRV_SDCARD_Tasks(SYS_MODULE_OBJ object);
Returns
None
Description
This routine is used to maintain the driver's internal state machine.
Remarks
This routine is normally not called directly by an application. It is called by the system's Tasks routine (SYS_Tasks) or by the appropriate raw ISR.
This routine may execute in an ISR context and will never block or access any resources that may cause it to block.
Preconditions
The DRV_SDCARD_Initialize routine must have been called for the specified SDCARD driver instance.
Volume V: MPLAB Harmony Framework Driver Libraries Help Secure Digital (SD) Card Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 726
Example
SYS_MODULE_OBJ object; // Returned from DRV_SDCARD_Initialize
while (true)
{
DRV_SDCARD_Tasks (object);
// Do other tasks
}
Parameters
Parameters Description
object Object handle for the specified driver instance (returned from DRV_SDCARD_Initialize)
Function
void DRV_SDCARD_Tasks
(
SYS_MODULE_OBJ object
);
b) Client Level Functions
DRV_SDCARD_Close Function
Closes an opened-instance of the SD Card driver.
Implementation: Dynamic
File
drv_sdcard.h
C
void DRV_SDCARD_Close(DRV_HANDLE handle);
Returns
None
Description
This routine closes an opened-instance of the SD Card driver, invalidating the handle.
Remarks
After calling this routine, the handle passed in "handle" must not be used with any of the remaining driver routines. A new handle must be obtained
by calling DRV_SDCARD_Open before the caller may use the driver again.
If DRV_IO_INTENT_BLOCKING was requested and the driver was built appropriately to support blocking behavior call may block until the
operation is complete.
If DRV_IO_INTENT_NON_BLOCKING request the driver client can call the DRV_SDCARD_Status operation to find out when the module is in the
ready state (the handle is no longer valid).
Usually there is no need for the driver client to verify that the Close operation has completed.
Preconditions
The DRV_SDCARD_Initialize routine must have been called for the specified SD Card driver instance.
DRV_SDCARD_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE handle; // Returned from DRV_SDCARD_Open
DRV_SDCARD_Close (handle);
Volume V: MPLAB Harmony Framework Driver Libraries Help Secure Digital (SD) Card Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 727
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
void DRV_SDCARD_Close
(
DRV_HANDLE handle
);
DRV_SDCARD_Open Function
Opens the specified SD Card driver instance and returns a handle to it.
Implementation: Dynamic
File
drv_sdcard.h
C
DRV_HANDLE DRV_SDCARD_Open(const SYS_MODULE_INDEX drvIndex, const DRV_IO_INTENT intent);
Returns
If successful, the routine returns a valid open-instance handle (a number identifying both the caller and the module instance).
If an error occurs, the return value is DRV_HANDLE_INVALID.
Description
This routine opens the specified SD Card driver instance and provides a handle that must be provided to all other client-level operations to identify
the caller and the instance of the driver.
Remarks
The handle returned is valid until the DRV_SDCARD_Close routine is called.
This routine will NEVER block waiting for hardware.
If the DRV_IO_INTENT_BLOCKING is requested and the driver was built appropriately to support blocking behavior, then other client-level
operations may block waiting on hardware until they are complete.
If the requested intent flags are not supported, the routine will return DRV_HANDLE_INVALID.
Preconditions
Function DRV_SDCARD_Initialize must have been called before calling this function.
Example
DRV_HANDLE handle;
handle = DRV_SDCARD_Open (DRV_SDCARD_INDEX_0, DRV_IO_INTENT_EXCLUSIVE);
if (DRV_HANDLE_INVALID == handle)
{
// Unable to open the driver
}
Parameters
Parameters Description
drvIndex Identifier for the object instance to be opened
intent Zero or more of the values from the enumeration DRV_IO_INTENT "ORed" together to
indicate the intended use of the driver
Function
DRV_HANDLE DRV_SDCARD_Open
(
const SYS_MODULE_INDEX drvIndex,
const DRV_IO_INTENT intent
Volume V: MPLAB Harmony Framework Driver Libraries Help Secure Digital (SD) Card Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 728
);
DRV_SDCARD_Read Function
Reads blocks of data from the specified block address of the SD Card.
File
drv_sdcard.h
C
void DRV_SDCARD_Read(DRV_HANDLE handle, DRV_SDCARD_COMMAND_HANDLE * commandHandle, void * targetBuffer,
uint32_t blockStart, uint32_t nBlock);
Returns
The buffer handle is returned in the commandHandle argument. It will be DRV_SDCARD_COMMAND_HANDLE_INVALID if the request was not
successful.
Description
This function schedules a non-blocking read operation for reading blocks of data from the SD Card. The function returns with a valid buffer handle
in the commandHandle argument if the read request was scheduled successfully. The function adds the request to the hardware instance queue
and returns immediately. While the request is in the queue, the application buffer is owned by the driver and should not be modified. The function
returns DRV_SDCARD_COMMAND_HANDLE_INVALID in the commandHandle argument under the following circumstances:
• if the driver handle is invalid
• if the target buffer pointer is NULL
• if the number of blocks to be read is zero or more than the actual number of blocks available
• if a buffer object could not be allocated to the request
• if the client opened the driver in write only mode
If the requesting client registered an event callback with the driver, the driver will issue a DRV_SDCARD_EVENT_COMMAND_COMPLETE event
if the buffer was processed successfully or DRV_SDCARD_EVENT_COMMAND_ERROR event if the buffer was not processed successfully.
Remarks
None.
Preconditions
The DRV_SDCARD_Initialize routine must have been called for the specified SDCARD driver instance.
DRV_SDCARD_Open must have been called with DRV_IO_INTENT_READ or DRV_IO_INTENT_READWRITE as the ioIntent to obtain a valid
opened device handle.
Example
uint8_t myBuffer[MY_BUFFER_SIZE];
// address should be block aligned.
uint32_t blockStart = 0x00;
uint32_t nBlock = 2;
DRV_SDCARD_COMMAND_HANDLE commandHandle;
MY_APP_OBJ myAppObj;
// mySDCARDHandle is the handle returned
// by the DRV_SDCARD_Open function.
DRV_SDCARD_Read(mySDCARDHandle, &commandHandle, &myBuffer, blockStart, nBlock);
if(DRV_SDCARD_COMMAND_HANDLE_INVALID == commandHandle)
{
// Error handling here
}
else
{
// Read Successful
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
Volume V: MPLAB Harmony Framework Driver Libraries Help Secure Digital (SD) Card Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 729
commandHandle Pointer to an argument that will contain the return buffer handle
targetBuffer Buffer into which the data read from the SD Card will be placed
blockStart Start block address of the SD Card from where the read should begin.
nBlock Total number of blocks to be read.
Function
void DRV_SDCARD_Read
(
const DRV_HANDLE handle,
DRV_SDCARD_COMMAND_HANDLE * commandHandle,
void * targetBuffer,
uint32_t blockStart,
uint32_t nBlock
);
DRV_SDCARD_Write Function
Writes blocks of data starting at the specified address of the SD Card.
File
drv_sdcard.h
C
void DRV_SDCARD_Write(DRV_HANDLE handle, DRV_SDCARD_COMMAND_HANDLE * commandHandle, void * sourceBuffer,
uint32_t blockStart, uint32_t nBlock);
Returns
The buffer handle is returned in the commandHandle argument. It will be DRV_SDCARD_COMMAND_HANDLE_INVALID if the request was not
successful.
Description
This function schedules a non-blocking write operation for writing blocks of data to the SD Card. The function returns with a valid buffer handle in
the commandHandle argument if the write request was scheduled successfully. The function adds the request to the hardware instance queue and
returns immediately. While the request is in the queue, the application buffer is owned by the driver and should not be modified. The function
returns DRV_SDCARD_COMMAND_HANDLE_INVALID in the commandHandle argument under the following circumstances:
• if a buffer object could not be allocated to the request
• if the source buffer pointer is NULL
• if the client opened the driver for read only
• if the number of blocks to be written is either zero or more than the number of blocks actually available
• if the write queue size is full or queue depth is insufficient
• if the driver handle is invalid
If the requesting client registered an event callback with the driver, the driver will issue a DRV_SDCARD_EVENT_COMMAND_COMPLETE event
if the buffer was processed successfully or DRV_SDCARD_EVENT_COMMAND_ERROR event if the buffer was not processed successfully.
Remarks
None.
Preconditions
The DRV_SDCARD_Initialize() routine must have been called for the specified SDCARD driver instance.
DRV_SDCARD_Open() routine must have been called to obtain a valid opened device handle. DRV_IO_INTENT_WRITE or
DRV_IO_INTENT_READWRITE must have been specified as a parameter to this routine.
Example
uint8_t myBuffer[MY_BUFFER_SIZE];
// address should be block aligned.
uint32_t blockStart = 0x00;
uint32_t nBlock = 2;
DRV_SDCARD_COMMAND_HANDLE commandHandle;
MY_APP_OBJ myAppObj;
Volume V: MPLAB Harmony Framework Driver Libraries Help Secure Digital (SD) Card Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 730
// mySDCARDHandle is the handle returned
// by the DRV_SDCARD_Open function.
// Client registers an event handler with driver
DRV_SDCARD_EventHandlerSet(mySDCARDHandle, APP_SDCARDEventHandler, (uintptr_t)&myAppObj);
DRV_SDCARD_Write(mySDCARDHandle, &commandHandle, &myBuffer, blockStart, nBlock);
if(DRV_SDCARD_COMMAND_HANDLE_INVALID == commandHandle)
{
// Error handling here
}
// Event is received when
// the buffer is processed.
void APP_SDCARDEventHandler(DRV_SDCARD_EVENT event,
DRV_SDCARD_COMMAND_HANDLE commandHandle, uintptr_t contextHandle)
{
// contextHandle points to myAppObj.
switch(event)
{
case DRV_SDCARD_EVENT_COMMAND_COMPLETE:
// This means the data was transferred.
break;
case DRV_SDCARD_EVENT_COMMAND_ERROR:
// Error handling here.
break;
default:
break;
}
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
commandHandle Pointer to an argument that will contain the return buffer handle
sourceBuffer The source buffer containing data to be programmed to the SD Card.
blockStart Start block address of SD Card where the writes should begin.
nBlock Total number of blocks to be written.
Function
void DRV_SDCARD_Write
(
const DRV_HANDLE handle,
DRV_SDCARD_COMMAND_HANDLE * commandHandle,
void * sourceBuffer,
uint32_t blockStart,
uint32_t nBlock
);
DRV_SDCARD_EventHandlerSet Function
Allows a client to identify an event handling function for the driver to call back when queued operation has completed.
File
drv_sdcard.h
Volume V: MPLAB Harmony Framework Driver Libraries Help Secure Digital (SD) Card Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 731
C
void DRV_SDCARD_EventHandlerSet(const DRV_HANDLE handle, const void * eventHandler, const uintptr_t
context);
Returns
None.
Description
This function allows a client to identify an event handling function for the driver to call back when queued operation has completed. When a client
queues a request for a read or a write operation, it is provided with a handle identifying the buffer that was added to the driver's buffer queue. The
driver will pass this handle back to the client by calling "eventHandler" function when the queued operation has completed.
The event handler should be set before the client performs any read or write operations that could generate events. The event handler once set,
persists until the client closes the driver or sets another event handler (which could be a "NULL" pointer to indicate no callback).
Remarks
If the client does not want to be notified when the queued operation has completed, it does not need to register a callback.
Preconditions
The DRV_SDCARD_Initialize() routine must have been called for the specified SDCARD driver instance.
The DRV_SDCARD_Open() routine must have been called to obtain a valid opened device handle.
Example
// myAppObj is an application specific state data object.
MY_APP_OBJ myAppObj;
uint8_t myBuffer[MY_BUFFER_SIZE];
uint32_t blockStart, nBlock;
DRV_SDCARD_COMMAND_HANDLE commandHandle;
// drvSDCARDHandle is the handle returned
// by the DRV_SDCARD_Open function.
// Client registers an event handler with driver. This is done once.
DRV_SDCARD_EventHandlerSet(drvSDCARDHandle, APP_SDCARDEventHandler, (uintptr_t)&myAppObj);
DRV_SDCARD_Read(drvSDCARDHandle, &commandHandle, &myBuffer, blockStart, nBlock);
if(DRV_SDCARD_COMMAND_HANDLE_INVALID == commandHandle)
{
// Error handling here
}
// Event Processing Technique. Event is received when operation is done.
void APP_SDCARDEventHandler(DRV_SDCARD_EVENT event,
DRV_SDCARD_COMMAND_HANDLE handle, uintptr_t context)
{
// The context handle was set to an application specific
// object. It is now retrievable easily in the event handler.
MY_APP_OBJ myAppObj = (MY_APP_OBJ *) context;
switch(event)
{
case DRV_SDCARD_EVENT_COMMAND_COMPLETE:
// This means the data was transferred.
break;
case DRV_SDCARD_EVENT_COMMAND_ERROR:
// Error handling here.
break;
default:
Volume V: MPLAB Harmony Framework Driver Libraries Help Secure Digital (SD) Card Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 732
break;
}
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
eventHandler Pointer to the event handler function implemented by the user
context The value of parameter will be passed back to the client unchanged, when the eventHandler
function is called. It can be used to identify any client specific data object that identifies the
instance of the client module (for example, it may be a pointer to the client module's state
structure).
Function
void DRV_SDCARD_EventHandlerSet
(
const DRV_HANDLE handle,
const void * eventHandler,
const uintptr_t context
);
c) Status Functions
DRV_SDCARD_IsAttached Function
Returns the physical attach status of the SD Card.
File
drv_sdcard.h
C
bool DRV_SDCARD_IsAttached(const DRV_HANDLE handle);
Returns
Returns false if the handle is invalid otherwise returns the attach status of the SD Card. Returns true if the SD Card is attached and initialized by
the SDCARD driver otherwise returns false.
Description
This function returns the physical attach status of the SD Card.
Remarks
None.
Preconditions
The DRV_SDCARD_Initialize() routine must have been called for the specified SDCARD driver instance.
The DRV_SDCARD_Open() routine must have been called to obtain a valid opened device handle.
Example
bool isSDCARDAttached;
isSDCARDAttached = DRV_SDCARD_isAttached(drvSDCARDHandle);
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
Function
bool DRV_SDCARD_IsAttached
(
const DRV_HANDLE handle
Volume V: MPLAB Harmony Framework Driver Libraries Help Secure Digital (SD) Card Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 733
);
DRV_SDCARD_IsWriteProtected Function
Returns the write protect status of the SDCARD.
File
drv_sdcard.h
C
bool DRV_SDCARD_IsWriteProtected(const DRV_HANDLE handle);
Returns
Returns true if the attached SD Card is write protected. Returns false if the handle is not valid, or if the SD Card is not write protected.
Description
This function returns true if the SD Card is write protected otherwise it returns false.
Remarks
None.
Preconditions
The DRV_SDCARD_Initialize() routine must have been called for the specified SDCARD driver instance.
The DRV_SDCARD_Open() routine must have been called to obtain a valid opened device handle.
Example
bool isWriteProtected;
isWriteProtected = DRV_SDCARD_IsWriteProtected(drvSDCARDHandle);
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
Function
bool DRV_SDCARD_IsWriteProtected
(
const DRV_HANDLE handle
);
DRV_SDCARD_CommandStatus Function
Gets the current status of the command.
File
drv_sdcard.h
C
DRV_SDCARD_COMMAND_STATUS DRV_SDCARD_CommandStatus(const DRV_HANDLE handle, const DRV_SDCARD_COMMAND_HANDLE
commandHandle);
Returns
A DRV_SDCARD_COMMAND_STATUS value describing the current status of the command. Returns
DRV_SDCARD_COMMAND_HANDLE_INVALID if the client handle or the command handle is not valid.
Description
This routine gets the current status of the command. The application must use this routine where the status of a scheduled command needs to be
polled on. The function may return DRV_SDCARD_COMMAND_HANDLE_INVALID in a case where the command handle has expired. A
command handle expires when the internal buffer object is re-assigned to another read or write request. It is recommended that this function be
called regularly in order to track the command status correctly.
The application can alternatively register an event handler to receive read or write operation completion events.
Volume V: MPLAB Harmony Framework Driver Libraries Help Secure Digital (SD) Card Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 734
Remarks
This routine will not block for hardware access and will immediately return the current status.
Preconditions
The DRV_SDCARD_Initialize() routine must have been called.
The DRV_SDCARD_Open() must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE handle; // Returned from DRV_SDCARD_Open
DRV_SDCARD_COMMAND_HANDLE commandHandle;
DRV_SDCARD_COMMAND_STATUS status;
status = DRV_SDCARD_CommandStatus(handle, commandHandle);
if(status == DRV_SDCARD_COMMAND_COMPLETED)
{
// Operation Done
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
DRV_SDCARD_COMMAND_STATUS DRV_SDCARD_CommandStatus
(
const DRV_HANDLE handle,
const DRV_SDCARD_COMMAND_HANDLE commandHandle
);
DRV_SDCARD_GeometryGet Function
Returns the geometry of the device.
File
drv_sdcard.h
C
SYS_FS_MEDIA_GEOMETRY * DRV_SDCARD_GeometryGet(const DRV_HANDLE handle);
Returns
SYS_FS_MEDIA_GEOMETRY - Pointer to structure which holds the media geometry information.
Description
This API gives the following geometrical details of the SD Card.
• Media Property
• Number of Read/Write/Erase regions in the SD Card
• Number of Blocks and their size in each region of the device
Remarks
None.
Preconditions
The DRV_SDCARD_Initialize() routine must have been called for the specified SDCARD driver instance.
The DRV_SDCARD_Open() routine must have been called to obtain a valid opened device handle.
Example
SYS_FS_MEDIA_GEOMETRY * SDCARDGeometry;
uint32_t readBlockSize, writeBlockSize, eraseBlockSize;
uint32_t nReadBlocks, nReadRegions, totalSize;
SDCARDGeometry = DRV_SDCARD_GeometryGet(SDCARDOpenHandle1);
Volume V: MPLAB Harmony Framework Driver Libraries Help Secure Digital (SD) Card Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 735
readBlockSize = SDCARDGeometry->geometryTable->blockSize;
nReadBlocks = SDCARDGeometry->geometryTable->numBlocks;
nReadRegions = SDCARDGeometry->numReadRegions;
writeBlockSize = (SDCARDGeometry->geometryTable +1)->blockSize;
eraseBlockSize = (SDCARDGeometry->geometryTable +2)->blockSize;
totalSize = readBlockSize * nReadBlocks * nReadRegions;
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
Function
SYS_FS_MEDIA_GEOMETRY * DRV_SDCARD_GeometryGet
(
const DRV_HANDLE handle
);
d) Data Types and Constants
DRV_SDCARD_INDEX_0 Macro
SD Card driver index definitions
File
drv_sdcard.h
C
#define DRV_SDCARD_INDEX_0 0
Description
SD Card Driver Module Index Numbers
These constants provide SD Card driver index definitions.
Remarks
These constants should be used in place of hard-coded numeric literals.
These values should be passed into the DRV_SDCARD_Initialize and DRV_SDCARD_Open routines to identify the driver instance in use.
DRV_SDCARD_INDEX_COUNT Macro
Number of valid SD Card driver indices
File
drv_sdcard.h
C
#define DRV_SDCARD_INDEX_COUNT DRV_SDCARD_INDEX_MAX
Description
SD Card Driver Module Index Count
This constant identifies number of valid SD Card driver indices.
Remarks
This constant should be used in place of hard-coded numeric literals.
This value is derived from part-specific header files defined as part of the peripheral libraries.
Volume V: MPLAB Harmony Framework Driver Libraries Help Secure Digital (SD) Card Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 736
DRV_SDCARD_INIT Structure
Contains all the data necessary to initialize the SD Card device
File
drv_sdcard.h
C
typedef struct _DRV_SDCARD_INIT {
SYS_MODULE_INIT moduleInit;
SYS_MODULE_INDEX spiIndex;
SPI_MODULE_ID spiId;
CLK_BUSES_PERIPHERAL spiClk;
uint32_t sdcardSpeedHz;
SDCARD_DETECTION_LOGIC sdCardPinActiveLogic;
PORTS_CHANNEL cardDetectPort;
PORTS_BIT_POS cardDetectBitPosition;
PORTS_CHANNEL writeProtectPort;
PORTS_BIT_POS writeProtectBitPosition;
PORTS_CHANNEL chipSelectPort;
PORTS_BIT_POS chipSelectBitPosition;
} DRV_SDCARD_INIT;
Members
Members Description
SYS_MODULE_INIT moduleInit; System module initialization
SYS_MODULE_INDEX spiIndex; SPI driver index
SPI_MODULE_ID spiId; Identifies peripheral (PLIB-level) ID
CLK_BUSES_PERIPHERAL spiClk; Peripheral clock used by the SPI
uint32_t sdcardSpeedHz; SD card communication speed
SDCARD_DETECTION_LOGIC
sdCardPinActiveLogic;
SD Card Pin Detection Logic
PORTS_CHANNEL cardDetectPort; Card detect port
PORTS_BIT_POS cardDetectBitPosition; Card detect pin
PORTS_CHANNEL writeProtectPort; Write protect port
PORTS_BIT_POS writeProtectBitPosition; Write protect pin
PORTS_CHANNEL chipSelectPort; Chip select port
PORTS_BIT_POS chipSelectBitPosition; Chip select pin
Description
SD Card Device Driver Initialization Data
This structure contains all the data necessary to initialize the SD Card device.
Remarks
A pointer to a structure of this format containing the desired initialization data must be passed into the DRV_SDCARD_Initialize routine.
SDCARD_DETECTION_LOGIC Enumeration
Defines the different system events
File
drv_sdcard.h
C
typedef enum {
SDCARD_DETECTION_LOGIC_ACTIVE_LOW,
SDCARD_DETECTION_LOGIC_ACTIVE_HIGH
} SDCARD_DETECTION_LOGIC;
Members
Members Description
SDCARD_DETECTION_LOGIC_ACTIVE_LOW The media event is SD Card attach
Volume V: MPLAB Harmony Framework Driver Libraries Help Secure Digital (SD) Card Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 737
SDCARD_DETECTION_LOGIC_ACTIVE_HIGH The media event is SD Card detach
Description
System events
This enum defines different system events.
Remarks
None.
SDCARD_MAX_LIMIT Macro
Maximum allowed SD card instances
File
drv_sdcard.h
C
#define SDCARD_MAX_LIMIT 2
Description
SD Card Driver Maximum allowed limit
This constant identifies number of valid SD Card driver indices.
Remarks
This constant should be used in place of hard-coded numeric literals.
This value is derived from part-specific header files defined as part of the peripheral libraries.
DRV_SDCARD_INDEX_1 Macro
File
drv_sdcard.h
C
#define DRV_SDCARD_INDEX_1 1
Description
This is macro DRV_SDCARD_INDEX_1.
DRV_SDCARD_INDEX_2 Macro
File
drv_sdcard.h
C
#define DRV_SDCARD_INDEX_2 2
Description
This is macro DRV_SDCARD_INDEX_2.
DRV_SDCARD_INDEX_3 Macro
File
drv_sdcard.h
C
#define DRV_SDCARD_INDEX_3 3
Description
This is macro DRV_SDCARD_INDEX_3.
Volume V: MPLAB Harmony Framework Driver Libraries Help Secure Digital (SD) Card Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 738
DRV_SDCARD_COMMAND_HANDLE_INVALID Macro
SDCARD Driver's Invalid Command Handle.
File
drv_sdcard.h
C
#define DRV_SDCARD_COMMAND_HANDLE_INVALID SYS_FS_MEDIA_BLOCK_COMMAND_HANDLE_INVALID
Description
SDCARD Driver Invalid Command Handle.
This value defines the SDCARD Driver Invalid Command Handle. This value is returned by read or write routines when the command request was
not accepted.
Remarks
None.
DRV_SDCARD_COMMAND_HANDLE Type
Handle identifying commands queued in the driver.
File
drv_sdcard.h
C
typedef SYS_FS_MEDIA_BLOCK_COMMAND_HANDLE DRV_SDCARD_COMMAND_HANDLE;
Description
SDCARD Driver command handle.
A command handle is returned by a call to the Read or Write functions. This handle allows the application to track the completion of the operation.
This command handle is also returned to the client along with the event that has occurred with respect to the command. This allows the application
to connect the event to a specific command in case where multiple commands are queued.
The command handle associated with the command request expires when the client has been notified of the completion of the command (after
event handler function that notifies the client returns) or after the command has been retired by the driver if no event handler callback was set.
Remarks
None.
DRV_SDCARD_COMMAND_STATUS Enumeration
Identifies the possible events that can result from a request.
File
drv_sdcard.h
C
typedef enum {
DRV_SDCARD_COMMAND_COMPLETED = SYS_FS_MEDIA_COMMAND_COMPLETED,
DRV_SDCARD_COMMAND_QUEUED = SYS_FS_MEDIA_COMMAND_QUEUED,
DRV_SDCARD_COMMAND_IN_PROGRESS = SYS_FS_MEDIA_COMMAND_IN_PROGRESS,
DRV_SDCARD_COMMAND_ERROR_UNKNOWN = SYS_FS_MEDIA_COMMAND_UNKNOWN
} DRV_SDCARD_COMMAND_STATUS;
Members
Members Description
DRV_SDCARD_COMMAND_COMPLETED =
SYS_FS_MEDIA_COMMAND_COMPLETED
Done OK and ready
DRV_SDCARD_COMMAND_QUEUED =
SYS_FS_MEDIA_COMMAND_QUEUED
Scheduled but not started
Volume V: MPLAB Harmony Framework Driver Libraries Help Secure Digital (SD) Card Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 739
DRV_SDCARD_COMMAND_IN_PROGRESS =
SYS_FS_MEDIA_COMMAND_IN_PROGRESS
Currently being in transfer
DRV_SDCARD_COMMAND_ERROR_UNKNOWN
= SYS_FS_MEDIA_COMMAND_UNKNOWN
Unknown Command
Description
SDCARD Driver Events
This enumeration identifies the possible events that can result from a read or a write request made by the client.
Remarks
One of these values is passed in the "event" parameter of the event handling callback function that client registered with the driver by calling the
DRV_SDCARD_EventHandlerSet function when a request is completed.
DRV_SDCARD_EVENT Enumeration
Identifies the possible events that can result from a request.
File
drv_sdcard.h
C
typedef enum {
DRV_SDCARD_EVENT_COMMAND_COMPLETE = SYS_FS_MEDIA_EVENT_BLOCK_COMMAND_COMPLETE,
DRV_SDCARD_EVENT_COMMAND_ERROR = SYS_FS_MEDIA_EVENT_BLOCK_COMMAND_ERROR
} DRV_SDCARD_EVENT;
Members
Members Description
DRV_SDCARD_EVENT_COMMAND_COMPLETE =
SYS_FS_MEDIA_EVENT_BLOCK_COMMAND_COMPLETE
Operation has been completed successfully.
DRV_SDCARD_EVENT_COMMAND_ERROR =
SYS_FS_MEDIA_EVENT_BLOCK_COMMAND_ERROR
There was an error during the operation
Description
SDCARD Driver Events
This enumeration identifies the possible events that can result from a read or a write request issued by the client.
Remarks
One of these values is passed in the "event" parameter of the event handling callback function that client registered with the driver by calling the
DRV_SDCARD_EventHandlerSet function when a request is completed.
DRV_SDCARD_EVENT_HANDLER Type
Pointer to a SDCARDDriver Event handler function
File
drv_sdcard.h
C
typedef SYS_FS_MEDIA_EVENT_HANDLER DRV_SDCARD_EVENT_HANDLER;
Returns
None.
Description
SDCARD Driver Event Handler Function Pointer
This data type defines the required function signature for the SDCARD event handling callback function. A client must register a pointer to an
event handling function whose function signature (parameter and return value types) match the types specified by this function pointer in order to
receive event calls back from the driver.
The parameters and return values are described here and a partial example implementation is provided.
Volume V: MPLAB Harmony Framework Driver Libraries Help Secure Digital (SD) Card Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 740
Remarks
If the event is DRV_SDCARD_EVENT_COMMAND_COMPLETE, it means that the write or a erase operation was completed successfully.
If the event is DRV_SDCARD_EVENT_COMMAND_ERROR, it means that the scheduled operation was not completed successfully.
The context parameter contains the handle to the client context, provided at the time the event handling function was registered using the
DRV_SDCARD_EventHandlerSet function. This context handle value is passed back to the client as the "context" parameter. It can be any value
necessary to identify the client context or instance (such as a pointer to the client's data) instance of the client that made the read/write/erase
request.
Example
void APP_MySDCARDEventHandler
(
DRV_SDCARD_EVENT event,
DRV_SDCARD_COMMAND_HANDLE commandHandle,
uintptr_t context
)
{
MY_APP_DATA_STRUCT pAppData = (MY_APP_DATA_STRUCT) context;
switch(event)
{
case DRV_SDCARD_EVENT_COMMAND_COMPLETE:
// Handle the completed buffer.
break;
case DRV_SDCARD_EVENT_COMMAND_ERROR:
default:
// Handle error.
break;
}
}
Parameters
Parameters Description
event Identifies the type of event
commandHandle Handle returned from the Read/Write requests
context Value identifying the context of the application that registered the event handling function
Files
Files
Name Description
drv_sdcard.h SD Card Device Driver Interface File
drv_sdcard_config_template.h SD Card driver configuration definitions template
Description
This section lists the source and header files used by the SD Card Driver Library.
drv_sdcard.h
SD Card Device Driver Interface File
Enumerations
Name Description
DRV_SDCARD_COMMAND_STATUS Identifies the possible events that can result from a request.
DRV_SDCARD_EVENT Identifies the possible events that can result from a request.
SDCARD_DETECTION_LOGIC Defines the different system events
Volume V: MPLAB Harmony Framework Driver Libraries Help Secure Digital (SD) Card Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 741
Functions
Name Description
DRV_SDCARD_Close Closes an opened-instance of the SD Card driver.
Implementation: Dynamic
DRV_SDCARD_CommandStatus Gets the current status of the command.
DRV_SDCARD_Deinitialize Deinitializes the specified instance of the SD Card driver module.
Implementation: Dynamic
DRV_SDCARD_EventHandlerSet Allows a client to identify an event handling function for the driver to call back when queued
operation has completed.
DRV_SDCARD_GeometryGet Returns the geometry of the device.
DRV_SDCARD_Initialize Initializes the SD Card driver.
Implementation: Dynamic
DRV_SDCARD_IsAttached Returns the physical attach status of the SD Card.
DRV_SDCARD_IsWriteProtected Returns the write protect status of the SDCARD.
DRV_SDCARD_Open Opens the specified SD Card driver instance and returns a handle to it.
Implementation: Dynamic
DRV_SDCARD_Read Reads blocks of data from the specified block address of the SD Card.
DRV_SDCARD_Reinitialize Reinitializes the driver and refreshes any associated hardware settings.
Implementation: Dynamic
DRV_SDCARD_Status Provides the current status of the SD Card driver module.
Implementation: Dynamic
DRV_SDCARD_Tasks Maintains the driver's state machine.
Implementation: Dynamic
DRV_SDCARD_Write Writes blocks of data starting at the specified address of the SD Card.
Macros
Name Description
DRV_SDCARD_COMMAND_HANDLE_INVALID SDCARD Driver's Invalid Command Handle.
DRV_SDCARD_INDEX_0 SD Card driver index definitions
DRV_SDCARD_INDEX_1 This is macro DRV_SDCARD_INDEX_1.
DRV_SDCARD_INDEX_2 This is macro DRV_SDCARD_INDEX_2.
DRV_SDCARD_INDEX_3 This is macro DRV_SDCARD_INDEX_3.
DRV_SDCARD_INDEX_COUNT Number of valid SD Card driver indices
SDCARD_MAX_LIMIT Maximum allowed SD card instances
Structures
Name Description
_DRV_SDCARD_INIT Contains all the data necessary to initialize the SD Card device
DRV_SDCARD_INIT Contains all the data necessary to initialize the SD Card device
Types
Name Description
DRV_SDCARD_COMMAND_HANDLE Handle identifying commands queued in the driver.
DRV_SDCARD_EVENT_HANDLER Pointer to a SDCARDDriver Event handler function
Description
SD Card Device Driver Interface
The SD Card device driver provides a simple interface to manage the "SD Card" peripheral. This file defines the interface definitions and
prototypes for the SD Card driver.
File Name
drv_sdcard.h
Company
Microchip Technology Inc.
Volume V: MPLAB Harmony Framework Driver Libraries Help Secure Digital (SD) Card Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 742
drv_sdcard_config_template.h
SD Card driver configuration definitions template
Macros
Name Description
DRV_SDCARD_CLIENTS_NUMBER Selects the miximum number of clients
DRV_SDCARD_ENABLE_WRITE_PROTECT_CHECK Enable SD Card write protect check.
DRV_SDCARD_INDEX_MAX SD Card Static Index selection
DRV_SDCARD_INSTANCES_NUMBER Selects the maximum number of hardware instances that can be
supported by the dynamic driver
DRV_SDCARD_POWER_STATE Defines an override of the power state of the SD Card driver.
DRV_SDCARD_SYS_FS_REGISTER Register to use with the File system
Description
SD Card Driver Configuration Definitions for the template version
These definitions statically define the driver's mode of operation.
File Name
drv_sdcard_config_template.h
Company
Microchip Technology Inc.
SPI Driver Library
This section describes the Serial Peripheral Interface (SPI) Driver Library.
Introduction
This library provides an interface to manage the Serial Peripheral Interface (SPI) module on the Microchip family of microcontrollers in different
modes of operation.
Description
The SPI module is a full duplex synchronous serial interface useful for communicating with other peripherals or microcontrollers in master/slave
relationship and it can transfer data over short distances at high speeds. The peripheral devices may be serial EEPROMs, shift registers, display
drivers, analog-to-digital converters, etc. The SPI module is compatible with Motorola’s SPI and SIOP interfaces.
During data transfer devices can work either in master or in Slave mode. The source of synchronization is the system clock, which is generated by
the master. The SPI module allows one or more slave devices to be connected to a single master device via the same bus.
The SPI serial interface consists of four pins, which are further sub-divided into data and control lines:
Data Lines:
• MOSI – Master Data Output, Slave Data Input
• MISO – Master Data Input, Slave Data Output
Control Lines:
• SCLK – Serial Clock
• /SS – Slave Select (no addressing)
SPI Master-Slave Relationship
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 743
The SPI module can be configured to operate using two, three, or four pins. In the 3-pin mode, the Slave Select line is not used. In the 2-pin mode,
both the MOSI and /SS lines are not used.
Note:
Third-party trademarks are property of their respective owners. Refer to the MPLAB Harmony Software License Agreement for
complete licensing information. A copy of this agreement is available in the /doc folder of your MPLAB Harmony
installation.
Using the Library
This topic describes the basic architecture of the SPI Driver Library and provides information and examples on its use.
Description
Interface Header File: drv_spi.h
The interface to the SPI Driver library is defined in the drv_spi.h header file. Any C language source (.c) file that uses the SPI Driver library
should include this header.
Please refer to the What is MPLAB Harmony? section for how the Driver interacts with the framework.
Abstraction Model
This library provides a low-level abstraction of the SPI Driver Library on the Microchip family microcontrollers with a convenient C language
interface. This topic describes how that abstraction is modeled in software and introduces the library's interface.
Description
Different types of SPIs are available on Microchip microcontrollers. Some have an internal buffer mechanism and some do not. The buffer depth
varies across part families. The SPI driver abstracts out these differences and provides a unified model for data transfer across different types of
SPIs available.
Both transmitter and receiver provides a buffer in the driver which transmits and receives data to/from the hardware. The SPI driver provides a set
of interfaces to perform the read and the write.
The following diagrams illustrate the model used by the SPI driver for transmitter and receiver.
Receiver Abstraction Model
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 744
Transmitter Abstraction Model
Library Overview
Refer to the Driver Library Overview section for information on how the driver operates in a system.
The library interface routines are divided into various sub-sections, which address one of the blocks or the overall operation of the SPI module.
Library Interface Section Description
System Interaction Functions Provides system module interfaces, device initialization, deinitialization,
reinitialization, tasks and status functions.
Client Setup Functions Provides open, close, status and other setup functions.
Data Transfer Functions Provides data transfer functions available in the configuration.
Miscellaneous Provides driver miscellaneous functions, data transfer status function, version
identification functions etc.
How the Library Works
The library provides interfaces to support:
• System Functionality
• Client Functionality
Note:
Not all modes are available on all devices, please refer to the specific device data sheet to determine the modes that are
supported for your device.
System Access
System Initialization and Reinitialization
The system performs the initialization and the reinitialization of the device driver with settings that affect only the instance of the device that is
being initialized or reinitialized. During system initialization each instance of the SPI module would be initialized with the following configuration
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 745
settings (either passed dynamically at run time using DRV_SPI_INIT or by using Initialization Overrides) that are supported by the specific SPI
device hardware:
• Device requested power state: one of the System Module Power States. For specific details please refer to Data Types and Constants in the
Library Interface section
• The actual peripheral ID enumerated as the PLIB level module ID (e.g., SPI_ID_2)
• Defining the respective interrupt sources for TX, RX, and Error Interrupt
The DRV_SPI_Initialize API returns an object handle of the type SYS_MODULE_OBJ. After this, the object handle returned by the Initialize
interface would be used by the other system interfaces like DRV_SPI_Deinitialize, DRV_SPI_Status, and DRV_SPI_Tasks.
Note:
The system initialization and the reinitialization settings, only affect the instance of the peripheral that is being initialized or
reinitialized.
Example:
DRV_SPI_INIT spiInitData;
SYS_MODULE_OBJ objectHandle;
spiInitData.moduleInit.value = SYS_MODULE_POWER_RUN_FULL;
spiInitData.spiId = SPI_ID_1;
spiInitData.taskMode = DRV_SPI_TASK_MODE_POLLED;
spiInitData.spiMode = DRV_SPI_MODE_MASTER;
spiInitData.spiProtocolType = DRV_SPI_PROTOCOL_TYPE_STANDARD;
spiInitData.commWidth = SPI_COMMUNICATION_WIDTH_8BITS;
spiInitData.baudRate = 5000;
spiInitData.bufferType = DRV_SPI_BUFFER_TYPE_STANDARD;
// It is highly recommended to set this to
// DRV_SPI_BUFFER_TYPE_ENHANCED for hardware
// that supports it
spiInitData.inputSamplePhase = SPI_INPUT_SAMPLING_PHASE_IN_MIDDLE;
spiInitData.clockMode = DRV_SPI_CLOCK_MODE_IDLE_LOW_EDGE_RISE;
spiInitData.txInterruptSource = INT_SOURCE_SPI_1_TRANSMIT;
spiInitData.rxInterruptSource = INT_SOURCE_SPI_1_RECEIVE;
spiInitData.errInterruptSource = INT_SOURCE_SPI_1_ERROR;
spiInitData.queueSize = 10;
spiInitData.jobQueueReserveSize = 1;
objectHandle = DRV_SPI_Initialize(DRV_SPI_INDEX_1, (SYS_MODULE_INIT*)&spiInitData);
if (SYS_MODULE_OBJ_INVALID == objectHandle)
{
// Handle error
}
Tasks Routine
The system will either call DRV_SPI_Tasks, from System Task Service (in a polled environment) or DRV_SPI_Tasks will be called from the ISR of
the SPI.
Client Access
General Client Operation
For the application to start using an instance of the module, it must call the DRV_SPI_Open function. This provides the configuration required to
open the SPI instance for operation. If the driver is deinitialized using the function DRV_SPI_Deinitialize, the application must call the
DRV_SPI_Open function again to set up the instance of the SPI.
For the various options available for IO_INTENT, please refer to Data Types and Constants in the Library Interface section.
After a client instance is opened, DRV_SPI_ClientConfigure can be called to set a client-specific bps, OperationStarting and OperationEnded
callbacks. The OperationStarting callback will be called before the first bit is put onto the SPI bus, allowing for the slave select line to be toggled to
active. The OperationEnded callback will be called after the last bit is received, allowing for the slave select line to be toggled to inactive. These
two callbacks will be called from the ISR, if the SPI driver is operating in ISR mode, care should be taken that they do the minimum needed. For
example, OSAL calls make cause exceptions in ISR context.
Example:
DRV_HANDLE handle;
// Configure the instance DRV_SPI_INDEX_1 with the configuration
handle = DRV_SPI_Open(DRV_SPI_INDEX_1, DRV_IO_INTENT_READWRITE);
if(handle == DRV_HANDLE_INVALID)
{
// Client cannot open the instance.
}
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 746
Client Transfer - Core
Client basic functionality provides a extremely basic interface for the driver operation.
The following diagram illustrates the byte/word model used for the data transfer.
Note:
It is not necessary to close and reopen the client between multiple transfers.
Client Data Transfer Functionality
Applications using the SPI byte/word functionality, need to perform the following:
1. The system should have completed necessary initialization and the DRV_SPI_Tasks should either be running in polled environment, or in an
interrupt environment.
2. Open_the driver using DRV_SPI_Open with the necessary intent.
3. Optionally configure the client with DRV_SPI_ClientConfigure to set up OperationStarting and OperationEnded callbacks to handle selecting
and deselecting the slave select pin.
4. Add a buffer using the DRV_SPI_BufferAddRead/DRV_SPI_BufferAddWrite/DRV_SPI_BufferAddWriteRead functions. An optional callback
can be provided that will be called when the buffer/job is complete.
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 747
5. Check for the current transfer status using DRV_SPI_BufferStatus until the transfer progress is DRV_SPI_BUFFER_EVENT_COMPLETE, or
wait for the callback to be called. If the SPI driver is configured in Polled more, ensure that DRV_SPI_Tasks is called regularly to handle the
buffer/job.
6. The client will be able to close the driver using DRV_SPI_Close when required.
Example:
SYS_MODULE_OBJ spiObject;
int main( void )
{
while ( 1 )
{
appTask ();
DRV_SPI_Tasks(spiObject);
}
}
void appTask ()
{
#define MY_BUFFER_SIZE 5
DRV_HANDLE handle; // Returned from DRV_SPI_Open
char myBuffer[MY_BUFFER_SIZE] = { 11, 22, 33, 44, 55};
unsigned int numBytes;
DRV_SPI_BUFFER_HANDLE bufHandle;
// Preinitialize myBuffer with MY_BUFFER_SIZE bytes of valid data.
while( 1 )
{
switch( state )
{
case APP_STATE_INIT:
/* Initialize the SPI Driver */
spiObject = DRV_SPI_Initialize( DRV_SPI_INDEX_1,
( SYS_MODULE_INIT * )
&initConf_1 );
/* Check for the System Status */
if( SYS_STATUS_READY != DRV_SPI_Status( spiObject ) )
return 0;
/* Open the Driver */
handle = DRV_SPI_Open( DRV_SPI_INDEX_1,
DRV_IO_INTENT_EXCLUSIVE );
/* Enable/Activate the CS */
/* Update the state to transfer data */
state = APP_STATE_DATA_PUT;
break;
case APP_STATE_DATA_PUT:
bufHandle = DRV_SPI_BufferAddWrite ( handle, myBuffer,
5, NULL, NULL );
/* Update the state to status check */
state = APP_STATE_DATA_CHECK;
break;
case APP_STATE_DATA_CHECK:
/* Check for the successful data transfer */
if( DRV_SPI_BUFFER_EVENT_COMPLETE &
DRV_SPI_BufferStatus( bufhandle ) )
{
/* Do this repeatedly */
state = APP_STATE_DATA_PUT;
}
break;
default:
break;
}
}
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 748
Configuring the Library
Miscellaneous Configuration
Name Description
DRV_SPI_INSTANCES_NUMBER Selects the maximum number of hardware instances that can be supported by the dynamic
driver .
DRV_SPI_CLIENTS_NUMBER Selects the maximum number of clients.
System Configuration
Name Description
DRV_SPI_16BIT Controls the compilation of 16 Bit mode
DRV_SPI_32BIT Controls the compilation of 32 Bit mode
DRV_SPI_8BIT Controls the compilation of 8 Bit mode
DRV_SPI_DMA Controls the compilation of DMA support
DRV_SPI_DMA_DUMMY_BUFFER_SIZE Controls the size of DMA dummy buffer
DRV_SPI_DMA_TXFER_SIZE Controls the size of DMA transfers
DRV_SPI_EBM Controls the compilation of Enhanced Buffer Mode mode
DRV_SPI_ELEMENTS_PER_QUEUE Controls the number of elements that are allocated.
DRV_SPI_ISR Controls the compilation of ISR mode
DRV_SPI_MASTER Controls the compilation of master mode
DRV_SPI_POLLED Controls the compilation of Polled mode
DRV_SPI_RM Controls the compilation of Standard Buffer mode
DRV_SPI_SLAVE Controls the compilation of slave mode
Description
The configuration of the SPI driver is based on the file system_config.h.
This header file contains the configuration selection for the SPI driver. Based on the selections made, the SPI driver may support the selected
features. These configuration settings will apply to all instances of the SPI driver.
This header can be placed anywhere, the path of this header needs to be present in the include search path for a successful build. Refer to the
Applications Help section for more details.
System Configuration
DRV_SPI_16BIT Macro
Controls the compilation of 16 Bit mode
File
drv_spi_config_template.h
C
#define DRV_SPI_16BIT 1
Description
SPI 16 Bit Mode Enable
This definition controls whether or not 16 Bit mode functionality is built as part of the driver. With it set to 1 then 16 Bit mode will be compiled and
commWidth = SPI_COMMUNICATION_WIDTH_16BITS will be accepted by SPI_DRV_Initialize(). With it set to 0 SPI_DRV_Initialize() will cause
an assert. With this set the BufferAdd functions will only accept buffer sizes of multiples of 2 (16 bit words)
Remarks
Optional definition
DRV_SPI_32BIT Macro
Controls the compilation of 32 Bit mode
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 749
File
drv_spi_config_template.h
C
#define DRV_SPI_32BIT 1
Description
SPI 32 Bit Mode Enable
This definition controls whether or not 32 Bit mode functionality is built as part of the driver. With it set to 1 then 32 Bit mode will be compiled and
commWidth = SPI_COMMUNICATION_WIDTH_32BITS will be accepted by SPI_DRV_Initialize(). With it set to 0 SPI_DRV_Initialize() will cause
an assert. With this set the BufferAdd functions will only accept buffer sizes of multiples of 4 (32 bit words)
Remarks
Optional definition
DRV_SPI_8BIT Macro
Controls the compilation of 8 Bit mode
File
drv_spi_config_template.h
C
#define DRV_SPI_8BIT 1
Description
SPI 8 Bit Mode Enable
This definition controls whether or not 8 Bit mode functionality is built as part of the driver. With it set to 1 then 8 Bit mode will be compiled and
commWidth = SPI_COMMUNICATION_WIDTH_8BITS will be accepted by SPI_DRV_Initialize(). With it set to 0 SPI_DRV_Initialize() will cause an
assert.
Remarks
Optional definition
DRV_SPI_DMA Macro
Controls the compilation of DMA support
File
drv_spi_config_template.h
C
#define DRV_SPI_DMA 1
Description
SPI DMA Enable
This definition controls whether or not DMA functionality is built as part of the driver. With it set to 1 then DMA will be compiled.
Remarks
Optional definition
DRV_SPI_DMA_DUMMY_BUFFER_SIZE Macro
Controls the size of DMA dummy buffer
File
drv_spi_config_template.h
C
#define DRV_SPI_DMA_DUMMY_BUFFER_SIZE 256
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 750
Description
SPI DMA Dummy Buffer Size
This controls the size of the buffer the SPI driver uses to give to the DMA service when it is to send and receive invalid data on the bus. This
occurs when the number of bytes to be read are different than the number of bytes transmitted.
Remarks
Optional definition
DRV_SPI_DMA_TXFER_SIZE Macro
Controls the size of DMA transfers
File
drv_spi_config_template.h
C
#define DRV_SPI_DMA_TXFER_SIZE 256
Description
SPI DMA Transfer Size
This definition controls the maximum number of bytes to transfer per DMA transfer.
Remarks
Optional definition
DRV_SPI_EBM Macro
Controls the compilation of Enhanced Buffer Mode mode
File
drv_spi_config_template.h
C
#define DRV_SPI_EBM 1
Description
SPI Enhanced Buffer Mode Enable (Hardware FIFO)
This definition controls whether or not Enhanced Buffer mode functionality is built as part of the driver. With it set to 1 then enhanced buffer mode
will be compiled and bufferType = DRV_SPI_BUFFER_TYPE_ENHANCED will be accepted by SPI_DRV_Initialize(). With it set to 0
SPI_DRV_Initialize() will cause an assert. This mode is not available on all PIC32s. Trying to use this mode on PICMX3XX/4XX will cause compile
time warnings and errors.
Remarks
Optional definition
DRV_SPI_ELEMENTS_PER_QUEUE Macro
Controls the number of elements that are allocated.
File
drv_spi_config_template.h
C
#define DRV_SPI_ELEMENTS_PER_QUEUE 10
Description
SPI Buffer Queue Depth
This definition along with DRV_SPI_INSTANCES_NUMBER and DRV_SPI_CLIENT_NUMBER controls how many buffer queue elements are
created.
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 751
Remarks
Optional definition
DRV_SPI_ISR Macro
Controls the compilation of ISR mode
File
drv_spi_config_template.h
C
#define DRV_SPI_ISR 1
Description
SPI ISR Mode Enable
This definition controls whether or not ISR mode functionality is built as part of the driver. With it set to 1 then ISR mode will be compiled and
taskMode = DRV_SPI_TASK_MODE_ISR will be accepted by SPI_DRV_Initialize(). With it set to 0 SPI_DRV_Initialize() will cause an assert
Remarks
Optional definition
DRV_SPI_MASTER Macro
Controls the compilation of master mode
File
drv_spi_config_template.h
C
#define DRV_SPI_MASTER 1
Description
SPI Master Mode Enable
This definition controls whether or not master mode functionality is built as part of the driver. With it set to 1 then master mode will be compiled and
spiMode = DRV_SPI_MODE_MASTER will be accepted by SPI_DRV_Initialize(). With it set to 0 SPI_DRV_Initialize() will cause an assert
Remarks
Optional definition
DRV_SPI_POLLED Macro
Controls the compilation of Polled mode
File
drv_spi_config_template.h
C
#define DRV_SPI_POLLED 1
Description
SPI Polled Mode Enable
This definition controls whether or not polled mode functionality is built as part of the driver. With it set to 1 then polled mode will be compiled and
taskMode = DRV_SPI_TASK_MODE_POLLED will be accepted by SPI_DRV_Initialize(). With it set to 0 SPI_DRV_Initialize() will cause an assert
Remarks
Optional definition
DRV_SPI_RM Macro
Controls the compilation of Standard Buffer mode
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 752
File
drv_spi_config_template.h
C
#define DRV_SPI_RM 1
Description
SPI Standard Buffer Mode Enable
This definition controls whether or not Standard Buffer mode functionality is built as part of the driver. With it set to 1 then standard buffer mode will
be compiled and bufferType = DRV_SPI_BUFFER_TYPE_STANDARD will be accepted by SPI_DRV_Initialize(). With it set to 0
SPI_DRV_Initialize() will cause an assert. This mode is available on all PIC32s
Remarks
Optional definition
DRV_SPI_SLAVE Macro
Controls the compilation of slave mode
File
drv_spi_config_template.h
C
#define DRV_SPI_SLAVE 1
Description
SPI Slave Mode Enable
This definition controls whether or not slave mode functionality is built as part of the driver. With it set to 1 then slave mode will be compiled and
spiMode = DRV_SPI_MODE_SLAVE will be accepted by SPI_DRV_Initialize(). With it set to 0 SPI_DRV_Initialize() will cause an assert
Remarks
Optional definition
Miscellaneous Configuration
DRV_SPI_INSTANCES_NUMBER Macro
Selects the maximum number of hardware instances that can be supported by the dynamic driver .
File
drv_spi_config_template.h
C
#define DRV_SPI_INSTANCES_NUMBER 1
Description
SPI hardware instance configuration
This definition selects the maximum number of hardware instances that can be supported by the dynamic driver.
Remarks
Mandatory definition
DRV_SPI_CLIENTS_NUMBER Macro
Selects the maximum number of clients.
File
drv_spi_config_template.h
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 753
C
#define DRV_SPI_CLIENTS_NUMBER 1
Description
SPI maximum number of clients
This definition selects the maximum number of clients that the SPI driver can support at run time.
Remarks
Mandatory definition
Building the Library
This section lists the files that are available in the SPI Driver Library.
Description
This section list the files that are available in the \src folder of the SPI Driver. It lists which files need to be included in the build based on either a
hardware feature present on the board or configuration option selected by the system.
The following three tables list and describe the header (.h) and source (.c) files that implement this library. The parent folder for these files is
/framework/driver/spi.
Interface File(s)
This table lists and describes the header files that must be included (i.e., using #include) by any code that uses this library.
Source File Name Description
/drv_spi.h Header file that exports the driver API.
Required File(s)
All of the required files listed in the following table are automatically added into the MPLAB X IDE project by the MHC
when the library is selected for use.
This table lists and describes the source and header files that must always be included in the MPLAB X IDE project to build this library.
Source File Name Description
/src/dynamic/drv_spi.c Basic SPI Driver implementation file.
/src/dynamic/drv_spi_api.c Functions used by the driver API.
/src/drv_spi_sys_queue_fifo.c Queue implementation used by the SPI Driver.
Optional File(s)
This table lists and describes the source and header files that may optionally be included if required for the desired implementation.
Source File Name Description
N/A No optional files are available for this library
Module Dependencies
The SPI Driver Library depends on the following modules:
• Clock System Service Library
Optional Dependencies
• DMA System Service Library (used when operating in DMA mode)
• Interrupt System Service Library (used when task is running in Interrupt mode)
Library Interface
a) System Interaction Functions
Name Description
DRV_SPI_Initialize Initializes the SPI instance for the specified driver index.
Implementation: Static/Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 754
DRV_SPI_Deinitialize Deinitializes the specified instance of the SPI driver module.
Implementation: Static/Dynamic
DRV_SPI_Status Provides the current status of the SPI driver module.
Implementation: Static/Dynamic
DRV_SPI_Tasks Maintains the driver's state machine and implements its ISR.
Implementation: Static/Dynamic
b) Client Setup Functions
Name Description
DRV_SPI_Close Closes an opened instance of the SPI driver.
Implementation: Static/Dynamic
DRV_SPI_Open Opens the specified SPI driver instance and returns a handle to it.
Implementation: Static/Dynamic
DRV_SPI_ClientConfigure Configures a SPI client with specific data.
Implementation: Static/Dynamic
c) Data Transfer Functions
Name Description
DRV_SPI_BufferStatus Returns the transmitter and receiver transfer status.
Implementation: Static/Dynamic
DRV_SPI_BufferAddRead Registers a buffer for a read operation. Actual transfer will happen in the Task function.
Implementation: Static/Dynamic
DRV_SPI_BufferAddWrite Registers a buffer for a write operation. Actual transfer will happen in the Task function.
Implementation: Static/Dynamic
DRV_SPI_BufferAddWriteRead Registers a buffer for a read and write operation. Actual transfer will happen in the Task
function.
Implementation: Static/Dynamic
DRV_SPI_BufferAddRead2 Registers a buffer for a read operation. Actual transfer will happen in the Task function.
Implementation: Static/Dynamic
DRV_SPI_BufferAddWrite2 Registers a buffer for a write operation. Actual transfer will happen in the Task function.
Implementation: Static/Dynamic
DRV_SPI_BufferAddWriteRead2 Registers a buffer for a read and write operation. Actual transfer will happen in the Task
function.
Implementation: Static/Dynamic
DRV_SPIn_ReceiverBufferIsFull Returns the receive buffer status. 'n' represents the instance of the SPI driver used.
Implementation: Static
DRV_SPIn_TransmitterBufferIsFull Returns the transmit buffer status. 'n' represents the instance of the SPI driver used.
Implementation: Static
Description
This section describes the API functions of the SPI Driver library.
Refer to each section for a detailed description.
a) System Interaction Functions
DRV_SPI_Initialize Function
Initializes the SPI instance for the specified driver index.
Implementation: Static/Dynamic
File
drv_spi.h
C
SYS_MODULE_OBJ DRV_SPI_Initialize(const SYS_MODULE_INDEX index, const SYS_MODULE_INIT * const init);
Returns
• If successful - returns a valid handle to a driver instance object
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 755
• If unsuccessful - returns SYS_MODULE_OBJ_INVALID
Description
This routine initializes the SPI driver instance for the specified driver index, making it ready for clients to open and use it. The initialization data is
specified by the 'init' parameter. The initialization may fail if the number of driver objects allocated are insufficient or if the specified driver instance
is already initialized. The driver instance index is independent of the SPI module ID. For example, driver instance 0 can be assigned to SPI2. If the
driver is built statically, then some of the initialization parameters are overridden by configuration macros. Refer to the description of the
DRV_SPI_INIT data structure for more details on which members on this data structure are overridden.
Remarks
This routine must be called before any other SPI routine is called.
This routine should only be called once during system initialization unless DRV_SPI_Deinitialize is called to deinitialize the driver instance. This
routine will NEVER block for hardware access.
Preconditions
None.
Example
DRV_SPI_INIT init;
SYS_MODULE_OBJ objectHandle;
// Populate the SPI initialization structure
init.spiId = SPI_ID_1,
init.taskMode = DRV_SPI_TASK_MODE_ISR,
init.spiMode = DRV_SPI_MODE_MASTER,
init.allowIdleRun = false,
init.spiProtocolType = DRV_SPI_PROTOCOL_TYPE_STANDARD,
init.commWidth = SPI_COMMUNICATION_WIDTH_8BITS,
init.baudClockSource = SPI_BAUD_RATE_PBCLK_CLOCK;
init.spiClk = CLK_BUS_PERIPHERAL_2,
init.baudRate = 10000000,
init.bufferType = DRV_SPI_BUFFER_TYPE_ENHANCED,
init.clockMode = DRV_SPI_CLOCK_MODE_IDLE_LOW_EDGE_FALL,
init.inputSamplePhase = SPI_INPUT_SAMPLING_PHASE_IN_MIDDLE,
init.txInterruptSource = INT_SOURCE_SPI_1_TRANSMIT,
init.rxInterruptSource = INT_SOURCE_SPI_1_RECEIVE,
init.errInterruptSource = INT_SOURCE_SPI_1_ERROR,
init.dummyByteValue = 0xFF,
init.queueSize = 10,
init.jobQueueReserveSize = 1,
objectHandle = DRV_SPI_Initialize(DRV_SPI_INDEX_1, (SYS_MODULE_INIT*)usartInitData);
if (SYS_MODULE_OBJ_INVALID == objectHandle)
{
// Handle error
}
Parameters
Parameters Description
index Identifier for the instance to be initialized. Please note this is not the SPI id. The hardware SPI
id is set in the initialization structure. This is the index of the driver index to use.
init Pointer to a data structure containing any data necessary to initialize the driver. If this pointer
is NULL, the driver uses the static initialization override macros for each member of the
initialization data structure.
Function
SYS_MODULE_OBJ DRV_SPI_Initialize( const SYS_MODULE_INDEX index,
const SYS_MODULE_INIT * const init )
DRV_SPI_Deinitialize Function
Deinitializes the specified instance of the SPI driver module.
Implementation: Static/Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 756
File
drv_spi.h
C
void DRV_SPI_Deinitialize(SYS_MODULE_OBJ object);
Returns
None.
Description
Deinitializes the specified instance of the SPI driver module, disabling its operation (and any hardware) and invalidates all of the internal data.
Remarks
Once the Initialize operation has been called, the De-initialize operation must be called before the Initialize operation can be called again.
This function will NEVER block waiting for hardware. If the operation requires time to allow the hardware to complete, this will be reported by the
DRV_SPI_Status operation. The system has to use DRV_SPI_Status to find out when the module is in the ready state.
Preconditions
Function DRV_SPI_Initialize must have been called before calling this routine and a valid SYS_MODULE_OBJ must have been returned.
Example
SYS_MODULE_OBJ object; // Returned from DRV_SPI_Initialize
SYS_STATUS status;
DRV_SPI_Deinitialize ( object );
status = DRV_SPI_Status( object );
if( SYS_MODULE_UNINITIALIZED == status )
{
// Check again later if you need to know
// when the driver is deinitialized.
}
Parameters
Parameters Description
object Driver object handle, returned from DRV_SPI_Initialize
Function
void DRV_SPI_Deinitialize ( SYS_MODULE_OBJ object )
DRV_SPI_Status Function
Provides the current status of the SPI driver module.
Implementation: Static/Dynamic
File
drv_spi.h
C
SYS_STATUS DRV_SPI_Status(SYS_MODULE_OBJ object);
Returns
• SYS_STATUS_READY - Indicates that the driver is busy with a previous
system level operation and cannot start another
Description
This function provides the current status of the SPI driver module.
Remarks
Any value greater than SYS_STATUS_READY is also a normal running state in which the driver is ready to accept new operations.
SYS_MODULE_UNINITIALIZED - Indicates that the driver has been deinitialized
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 757
This value is less than SYS_STATUS_ERROR.
This function can be used to determine when any of the driver's module level operations has completed.
If the status operation returns SYS_STATUS_BUSY, the previous operation has not yet completed. Once the status operation returns
SYS_STATUS_READY, any previous operations have completed.
The value of SYS_STATUS_ERROR is negative (-1). Any value less than that is also an error state.
This function will NEVER block waiting for hardware.
If the Status operation returns an error value, the error may be cleared by calling the reinitialize operation. If that fails, the deinitialize operation will
need to be called, followed by the initialize operation to return to normal operations.
Preconditions
The DRV_SPI_Initialize function must have been called before calling this function.
Example
SYS_MODULE_OBJ object; // Returned from DRV_SPI_Initialize
SYS_STATUS status;
status = DRV_SPI_Status( object );
if( SYS_STATUS_READY != status )
{
// Handle error
}
Parameters
Parameters Description
object Driver object handle, returned from DRV_SPI_Initialize
Function
SYS_STATUS DRV_SPI_Status ( SYS_MODULE_OBJ object )
DRV_SPI_Tasks Function
Maintains the driver's state machine and implements its ISR.
Implementation: Static/Dynamic
File
drv_spi.h
C
void DRV_SPI_Tasks(SYS_MODULE_OBJ object);
Returns
None.
Description
This routine is used to maintain the driver's internal state machine and implement its transmit ISR for interrupt-driven implementations. In polling
mode, this function should be called from the SYS_Tasks() function. In interrupt mode, this function should be called in the transmit interrupt
service routine of the USART that is associated with this USART driver hardware instance.
Remarks
This function is normally not called directly by an application. It is called by the system's Tasks routine (SYS_Tasks) or by the appropriate raw ISR.
This function may execute in an ISR context and will never block or access any resources that may cause it to block.
Preconditions
The DRV_SPI_Initialize routine must have been called for the specified SPI driver instance.
Example
SYS_MODULE_OBJ object; // Returned from DRV_SPI_Initialize
while( true )
{
DRV_SPI_Tasks ( object );
// Do other tasks
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 758
}
Parameters
Parameters Description
object Object handle for the specified driver instance (returned from DRV_SPI_Initialize)
Function
void DRV_SPI_Tasks ( SYS_MODULE_OBJ object );
b) Client Setup Functions
DRV_SPI_Close Function
Closes an opened instance of the SPI driver.
Implementation: Static/Dynamic
File
drv_spi.h
C
void DRV_SPI_Close(DRV_HANDLE handle);
Returns
None.
Description
This function closes an opened instance of the SPI driver, invalidating the handle.
Remarks
After calling this routine, the handle passed in "handle" must not be used with any of the remaining driver routines. A new handle must be obtained
by calling DRV_SPI_Open before the caller may use the driver again. This function is thread safe in a RTOS application.
Usually there is no need for the driver client to verify that the Close operation has completed.
Preconditions
The DRV_SPI_Initialize routine must have been called for the specified SPI driver instance.
DRV_SPI_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE handle; // Returned from DRV_SPI_Open
DRV_SPI_Close ( handle );
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
void DRV_SPI_Close ( DRV_HANDLE handle )
DRV_SPI_Open Function
Opens the specified SPI driver instance and returns a handle to it.
Implementation: Static/Dynamic
File
drv_spi.h
C
DRV_HANDLE DRV_SPI_Open(const SYS_MODULE_INDEX drvIndex, const DRV_IO_INTENT ioIntent);
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 759
Returns
If successful, the routine returns a valid open-instance handle (a number identifying both the caller and the module instance).
If an error occurs, the return value is DRV_HANDLE_INVALID. An error can occur when the following is true:
• if the number of client objects allocated via DRV_SPI_INSTANCES_NUMBER is insufficient
• if the client is trying to open the driver but driver has been opened exclusively by another client
• if the driver hardware instance being opened is not initialized or is invalid
Description
This routine opens the specified SPI driver instance and provides a handle that must be provided to all other client-level operations to identify the
caller and the instance of the driver. The ioIntent parameter defines how the client interacts with this driver instance.
If ioIntent is DRV_IO_INTENT_READ, the client will only be read from the driver. If ioIntent is DRV_IO_INTENT_WRITE, the client will only be able
to write to the driver. If the ioIntent in DRV_IO_INTENT_READWRITE, the client will be able to do both, read and write.
Specifying a DRV_IO_INTENT_EXCLUSIVE will cause the driver to provide exclusive access to this client. The driver cannot be opened by any
other client.
Remarks
The handle returned is valid until the DRV_SPI_Close routine is called. This routine will NEVER block waiting for hardware. If the requested intent
flags are not supported, the routine will return DRV_HANDLE_INVALID. This function is thread safe in a RTOS application. It should not be called
in an ISR.
Preconditions
The DRV_SPI_Initialize function must have been called before calling this function.
Example
DRV_HANDLE handle;
handle = DRV_SPI_Open( DRV_SPI_INDEX_0, DRV_IO_INTENT_EXCLUSIVE );
if( DRV_HANDLE_INVALID == handle )
{
// Unable to open the driver
}
Parameters
Parameters Description
drvIndex Index of the driver initialized with DRV_SPI_Initialize(). Please note this is not the SPI ID.
ioIntent Zero or more of the values from the enumeration DRV_IO_INTENT ORed together to indicate
the intended use of the driver
Function
DRV_HANDLE DRV_SPI_Open ( const SYS_MODULE_INDEX drvIndex,
const DRV_IO_INTENT ioIntent )
DRV_SPI_ClientConfigure Function
Configures a SPI client with specific data.
Implementation: Static/Dynamic
File
drv_spi.h
C
int32_t DRV_SPI_ClientConfigure(DRV_HANDLE handle, const DRV_SPI_CLIENT_DATA * cfgData);
Returns
• If successful - the routing will return greater than or equal to zero
• If an error occurs - the return value is negative
Description
This routine takes a DRV_SPI_CLIENT_DATA structure and sets client specific options. Whenever a new SPI job is started these values will be
used. Passing in NULL will reset the client back to configuration parameters passed to driver initialization. A zero in any of the structure elements
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 760
will reset that specific configuration back to the driver default.
Preconditions
The DRV_SPI_Open function must have been called before calling this function.
Parameters
Parameters Description
handle handle of the client returned by DRV_SPI_Open.
cfgData Client-specific configuration data.
Function
int32_t DRV_SPI_ClientConfigure ( DRV_HANDLE handle,
const DRV_SPI_CLIENT_DATA * cfgData )
c) Data Transfer Functions
DRV_SPI_BufferStatus Function
Returns the transmitter and receiver transfer status.
Implementation: Static/Dynamic
File
drv_spi.h
C
DRV_SPI_BUFFER_EVENT DRV_SPI_BufferStatus(DRV_SPI_BUFFER_HANDLE bufferHandle);
Returns
A DRV_SPI_BUFFER_STATUS value describing the current status of the transfer.
Description
This returns the transmitter and receiver transfer status.
Remarks
The returned status may contain a value with more than one of the bits specified in the DRV_SPI_BUFFER_STATUS enumeration set. The caller
should perform an AND with the bit of interest and verify if the result is non-zero (as shown in the example) to verify the desired status bit.
Preconditions
The DRV_SPI_Initialize routine must have been called for the specified SPI driver instance.
DRV_SPI_Open must have been called to obtain a valid opened device handle.
DRV_SPI_BufferAddmust have been called to obtain the buffer handle associated with that transfer.
Example
// Buffer handle returned from the data transfer function
DRV_SPI_BUFFER_HANDLE bufferHandle;
if(DRV_SPI_BufferStatus(bufferHandle) == DRV_SPI_BUFFER_EVENT_COMPLETE)
{
// All transmitter data has been sent.
}
Parameters
Parameters Description
bufferHandle A valid buffer handle, returned from the driver's data transfer routine
Function
DRV_SPI_BUFFER_EVENT DRV_SPI_BufferStatus ( DRV_SPI_BUFFER_HANDLE bufferHandle )
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 761
DRV_SPI_BufferAddRead Function
Registers a buffer for a read operation. Actual transfer will happen in the Task function.
Implementation: Static/Dynamic
File
drv_spi.h
C
DRV_SPI_BUFFER_HANDLE DRV_SPI_BufferAddRead(DRV_HANDLE handle, void * rxBuffer, size_t size,
DRV_SPI_BUFFER_EVENT_HANDLER completeCB, void * context);
Returns
If the buffer add request is successful, a valid buffer handle is returned. If request is not queued up, DRV_SPI_BUFFER_HANDLE_INVALID is
returned.
Description
Registers a buffer for a read operation. Actual transfer will happen in the Task function. The status of this operation can be monitored using
DRV_SPI_BufferStatus function. A optional callback can also be provided that will be called when the operation is complete.
Remarks
This API will be deprecated soon, so avoid using it. Use "DRV_SPI_BufferAddRead2" instead of it.
Preconditions
The DRV_SPI_Initialize routine must have been called for the specified SPI driver instance.
DRV_SPI_Open must have been called to obtain a valid opened device handle.
DRV_IO_INTENT_READ or DRV_IO_INTENT_READWRITE must have been specified in the DRV_SPI_Open call.
Example
DRV_HANDLE handle; // Returned from DRV_SPI_Open
char myBuffer[MY_BUFFER_SIZE], state = 0;
DRV_SPI_BUFFER_HANDLE bufferHandle;
switch ( state )
{
case 0:
bufferHandle = DRV_SPI_BufferAddRead( handle, myBuffer, 10, NULL, NULL );
if(bufferHandle != DRV_SPI_BUFFER_HANDLE_INVALID )
{
state++;
}
break;
case 1:
if(DRV_SPI_BufferStatus(bufferHandle) == DRV_SPI_BUFFER_EVENT_COMPLETE)
{
state++;
// All transmitter data has been sent successfully.
}
break;
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
rxBuffer The buffer to which the data should be written to.
size Number of bytes to be read from the SPI bus.
completeCB Pointer to a function to be called when this queued operation is complete.
context unused by the driver but this is passed to the callback when it is called.
Function
DRV_SPI_BUFFER_HANDLE DRV_SPI_BufferAddRead ( DRV_HANDLE handle, void *rxBuffer,
size_t size, DRV_SPI_BUFFER_EVENT_HANDLER completeCB,
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 762
void * context )
DRV_SPI_BufferAddWrite Function
Registers a buffer for a write operation. Actual transfer will happen in the Task function.
Implementation: Static/Dynamic
File
drv_spi.h
C
DRV_SPI_BUFFER_HANDLE DRV_SPI_BufferAddWrite(DRV_HANDLE handle, void * txBuffer, size_t size,
DRV_SPI_BUFFER_EVENT_HANDLER completeCB, void * context);
Returns
If the buffer add request is successful, a valid buffer handle is returned. If request is not queued up, DRV_SPI_BUFFER_HANDLE_INVALID is
returned.
Description
Registers a buffer for a write operation. Actual transfer will happen in the Task function. The status of this operation can be monitored using
DRV_SPI_BufferStatus function. A optional callback can also be provided that will be called when the operation is complete.
Remarks
This API will be deprecated soon, so avoid using it. Use "DRV_SPI_BufferAddWrite2" instead of it.
Preconditions
The DRV_SPI_Initialize routine must have been called for the specified SPI driver instance.
DRV_SPI_Open must have been called to obtain a valid opened device handle.
DRV_IO_INTENT_WRITE or DRV_IO_INTENT_READWRITE must have been specified in the DRV_SPI_Open call.
Example
DRV_HANDLE handle; // Returned from DRV_SPI_Open
char myBuffer[MY_BUFFER_SIZE], state = 0;
DRV_SPI_BUFFER_HANDLE bufferHandle;
switch ( state )
{
case 0:
bufferHandle = DRV_SPI_BufferAddWrite( handle, myBuffer, 10, NULL, NULL );
if(bufferHandle != DRV_SPI_BUFFER_HANDLE_INVALID )
{
state++;
}
break;
case 1:
if(DRV_SPI_BufferStatus(bufferHandle) == DRV_SPI_BUFFER_EVENT_COMPLETE)
{
state++;
// All transmitter data has been sent successfully.
}
break;
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
txBuffer The buffer which hold the data.
size Number of bytes to be written to the SPI bus.
completeCB Pointer to a function to be called when this queued operation is complete
context unused by the driver but this is passed to the callback when it is called
Function
DRV_SPI_BUFFER_HANDLE DRV_SPI_BufferAddWrite ( DRV_HANDLE handle, void *txBuffer,
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 763
size_t size, DRV_SPI_BUFFER_EVENT_HANDLER completeCB,
void * context )
DRV_SPI_BufferAddWriteRead Function
Registers a buffer for a read and write operation. Actual transfer will happen in the Task function.
Implementation: Static/Dynamic
File
drv_spi.h
C
DRV_SPI_BUFFER_HANDLE DRV_SPI_BufferAddWriteRead(DRV_HANDLE handle, void * txBuffer, size_t txSize, void *
rxBuffer, size_t rxSize, DRV_SPI_BUFFER_EVENT_HANDLER completeCB, void * context);
Returns
If the buffer add request is successful, a valid buffer handle is returned. If request is not queued up, DRV_SPI_BUFFER_HANDLE_INVALID is
returned.
Description
Registers a buffer for a read and write operation. Actual transfer will happen in the Task function. The status of this operation can be monitored
using DRV_SPI_BufferStatus function. A optional callback can also be provided that will be called when the operation is complete.
Remarks
This API will be deprecated soon, so avoid using it. Use "DRV_SPI_BufferAddWriteRead2" instead of it.
Preconditions
The DRV_SPI_Initialize routine must have been called for the specified SPI driver instance.
DRV_SPI_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE handle; // Returned from DRV_SPI_Open
char myReadBuffer[MY_BUFFER_SIZE], myWriteBuffer[MY_BUFFER_SIZE], state = 0;
DRV_SPI_BUFFER_HANDLE bufferHandle;
switch ( state )
{
case 0:
bufferHandle = DRV_SPI_BufferAddWriteRead( handle, myWriteBuffer, 10, myReadBuffer, 10, NULL, NULL
);
if(bufferHandle != DRV_SPI_BUFFER_HANDLE_INVALID )
{
state++;
}
break;
case 1:
if(DRV_SPI_BufferStatus(bufferHandle) == DRV_SPI_BUFFER_EVENT_COMPLETE)
{
state++;
// All transmitter data has been sent successfully.
}
break;
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
txBuffer The buffer which hold the data.
txSize Number of bytes to be written to the SPI bus.
rxBuffer The buffer to which the data should be written to.
rxSize Number of bytes to be read from the SPI bus
completeCB Pointer to a function to be called when this queued operation is complete
context unused by the driver but this is passed to the callback when it is called
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 764
Function
DRV_SPI_BUFFER_HANDLE DRV_SPI_BufferAddWriteRead( DRV_HANDLE handle,
void *txBuffer, void *rxBuffer, size_t size, )
DRV_SPI_BufferAddRead2 Function
Registers a buffer for a read operation. Actual transfer will happen in the Task function.
Implementation: Static/Dynamic
File
drv_spi.h
C
DRV_SPI_BUFFER_HANDLE DRV_SPI_BufferAddRead2(DRV_HANDLE handle, void * rxBuffer, size_t size,
DRV_SPI_BUFFER_EVENT_HANDLER completeCB, void * context, DRV_SPI_BUFFER_HANDLE * jobHandle);
Returns
If the buffer add request is successful, a valid buffer handle is returned. If request is not queued up, DRV_SPI_BUFFER_HANDLE_INVALID is
returned.
Description
Registers a buffer for a read operation. Actual transfer will happen in the Task function. The status of this operation can be monitored using
DRV_SPI_BufferStatus function. A optional callback can also be provided that will be called when the operation is complete.
Remarks
None.
Preconditions
The DRV_SPI_Initialize routine must have been called for the specified SPI driver instance.
DRV_SPI_Open must have been called to obtain a valid opened device handle.
DRV_IO_INTENT_READ or DRV_IO_INTENT_READWRITE must have been specified in the DRV_SPI_Open call.
Example
DRV_HANDLE handle; // Returned from DRV_SPI_Open
char myBuffer[MY_BUFFER_SIZE], state = 0;
DRV_SPI_BUFFER_HANDLE bufferHandle, bufferHandle2;
switch ( state )
{
case 0:
bufferHandle = DRV_SPI_BufferAddRead2( handle, myBuffer, 10, NULL, NULL, &bufferHandle2 );
if(bufferHandle2 != DRV_SPI_BUFFER_HANDLE_INVALID )
{
state++;
}
break;
case 1:
if(DRV_SPI_BufferStatus(bufferHandle2) == DRV_SPI_BUFFER_EVENT_COMPLETE)
{
state++;
// All transmitter data has been sent successfully.
}
break;
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
rxBuffer The buffer to which the data should be written to.
size Number of bytes to be read from the SPI bus.
completeCB Pointer to a function to be called when this queued operation is complete
context unused by the driver but this is passed to the callback when it is called
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 765
jobHandle pointer to the buffer handle, this will be set before the function returns and can be used in the
ISR callback.
Function
DRV_SPI_BUFFER_HANDLE DRV_SPI_BufferAddRead2 ( DRV_HANDLE handle, void *rxBuffer,
size_t size, DRV_SPI_BUFFER_EVENT_HANDLER completeCB,
void * context, DRV_SPI_BUFFER_HANDLE * jobHandle )
DRV_SPI_BufferAddWrite2 Function
Registers a buffer for a write operation. Actual transfer will happen in the Task function.
Implementation: Static/Dynamic
File
drv_spi.h
C
DRV_SPI_BUFFER_HANDLE DRV_SPI_BufferAddWrite2(DRV_HANDLE handle, void * txBuffer, size_t size,
DRV_SPI_BUFFER_EVENT_HANDLER completeCB, void * context, DRV_SPI_BUFFER_HANDLE * jobHandle);
Returns
If the buffer add request is successful, a valid buffer handle is returned. If request is not queued up, DRV_SPI_BUFFER_HANDLE_INVALID is
returned.
Description
Registers a buffer for a write operation. Actual transfer will happen in the Task function. The status of this operation can be monitored using
DRV_SPI_BufferStatus function. A optional callback can also be provided that will be called when the operation is complete.
Remarks
None.
Preconditions
The DRV_SPI_Initialize routine must have been called for the specified SPI driver instance.
DRV_SPI_Open must have been called to obtain a valid opened device handle.
DRV_IO_INTENT_WRITE or DRV_IO_INTENT_READWRITE must have been specified in the DRV_SPI_Open call.
Example
DRV_HANDLE handle; // Returned from DRV_SPI_Open
char myBuffer[MY_BUFFER_SIZE], state = 0;
DRV_SPI_BUFFER_HANDLE bufferHandle, bufferHandle2;
switch ( state )
{
case 0:
bufferHandle = DRV_SPI_BufferAddWrite2( handle, myBuffer, 10, NULL, NULL, &bufferHandle2 );
if(bufferHandle2 != DRV_SPI_BUFFER_HANDLE_INVALID )
{
state++;
}
break;
case 1:
if(DRV_SPI_BufferStatus(bufferHandle2) == DRV_SPI_BUFFER_EVENT_COMPLETE)
{
state++;
// All transmitter data has been sent successfully.
}
break;
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
txBuffer The buffer which hold the data.
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 766
size Number of bytes to be written to the SPI bus.
completeCB Pointer to a function to be called when this queued operation is complete
context unused by the driver but this is passed to the callback when it is called
jobHandle pointer to the buffer handle, this will be set before the function returns and can be used in the
ISR callback.
Function
DRV_SPI_BUFFER_HANDLE DRV_SPI_BufferAddWrite2 ( DRV_HANDLE handle, void *txBuffer,
size_t size, DRV_SPI_BUFFER_EVENT_HANDLER completeCB,
void * context, DRV_SPI_BUFFER_HANDLE * jobHandle )
DRV_SPI_BufferAddWriteRead2 Function
Registers a buffer for a read and write operation. Actual transfer will happen in the Task function.
Implementation: Static/Dynamic
File
drv_spi.h
C
DRV_SPI_BUFFER_HANDLE DRV_SPI_BufferAddWriteRead2(DRV_HANDLE handle, void * txBuffer, size_t txSize, void *
rxBuffer, size_t rxSize, DRV_SPI_BUFFER_EVENT_HANDLER completeCB, void * context, DRV_SPI_BUFFER_HANDLE *
jobHandle);
Returns
If the buffer add request is successful, a valid buffer handle is returned. If request is not queued up, DRV_SPI_BUFFER_HANDLE_INVALID is
returned.
Description
Registers a buffer for a read and write operation. Actual transfer will happen in the Task function. The status of this operation can be monitored
using DRV_SPI_BufferStatus function. A optional callback can also be provided that will be called when the operation is complete.
Remarks
None.
Preconditions
The DRV_SPI_Initialize routine must have been called for the specified SPI driver instance.
DRV_SPI_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE handle; // Returned from DRV_SPI_Open
char myReadBuffer[MY_BUFFER_SIZE], myWriteBuffer[MY_BUFFER_SIZE], state = 0;
DRV_SPI_BUFFER_HANDLE bufferHandle, bufferHandle2;
switch ( state )
{
case 0:
bufferHandle = DRV_SPI_BufferAddWriteRead2( handle, myWriteBuffer, 10, myReadBuffer, 10, NULL,
NULL, &bufferHandle2 );
if(bufferHandle2 != DRV_SPI_BUFFER_HANDLE_INVALID )
{
state++;
}
break;
case 1:
if(DRV_SPI_BufferStatus(bufferHandle2) == DRV_SPI_BUFFER_EVENT_COMPLETE)
{
state++;
// All transmitter data has been sent successfully.
}
break;
}
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 767
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
txBuffer The buffer which hold the data.
txSize Number of bytes to be written to the SPI bus.
rxBuffer The buffer to which the data should be written to.
rxSize Number of bytes to be read from the SPI bus
completeCB Pointer to a function to be called when this queued operation is complete
context unused by the driver but this is passed to the callback when it is called
jobHandle pointer to the buffer handle, this will be set before the function returns and can be used in the
ISR callback.
Function
DRV_SPI_BUFFER_HANDLE DRV_SPI_BufferAddWriteRead2( DRV_HANDLE handle,
void *txBuffer, void *rxBuffer, size_t size,
DRV_SPI_BUFFER_EVENT_HANDLER completeCB,
void * context, DRV_SPI_BUFFER_HANDLE * jobHandle )
DRV_SPIn_ReceiverBufferIsFull Function
Returns the receive buffer status. 'n' represents the instance of the SPI driver used.
Implementation: Static
File
drv_spi.h
C
bool DRV_SPIn_ReceiverBufferIsFull();
Returns
Receive Buffer Status
• 1 - Full
• 0 - Empty
Description
This function returns the receive buffer status (full/empty).
Remarks
None.
Preconditions
None.
Example
bool rxBufStat;
// Using instance 1 of SPI driver, that is n = 1
rxBufStat = DRV_SPI1_ReceiverBufferIsFull();
if (rxBufStat)
{
...
}
Function
bool DRV_SPIn_ReceiverBufferIsFull(void)
DRV_SPIn_TransmitterBufferIsFull Function
Returns the transmit buffer status. 'n' represents the instance of the SPI driver used.
Implementation: Static
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 768
File
drv_spi.h
C
bool DRV_SPIn_TransmitterBufferIsFull();
Returns
Transmit Buffer Status
• 1 - Full
• 0 - Empty
Description
This function returns the transmit buffer status (full/empty).
Remarks
None.
Preconditions
None.
Example
bool txBufStat;
// Using instance 1 of SPI driver, that is n = 1
txBufStat = DRV_SPI1_TransmitterBufferIsFull();
if (txBufStat)
{
...
}
Function
bool DRV_SPIn_TransmitterBufferIsFull(void)
d) Miscellaneous Functions
e) Data Types and Constants
Files
Files
Name Description
drv_spi.h SPI device driver interface file.
drv_spi_config_template.h SPI Driver configuration definitions template.
Description
This section lists the source and header files used by the SPI Driver Library.
drv_spi.h
SPI device driver interface file.
Functions
Name Description
DRV_SPI_BufferAddRead Registers a buffer for a read operation. Actual transfer will happen in the Task function.
Implementation: Static/Dynamic
DRV_SPI_BufferAddRead2 Registers a buffer for a read operation. Actual transfer will happen in the Task function.
Implementation: Static/Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 769
DRV_SPI_BufferAddWrite Registers a buffer for a write operation. Actual transfer will happen in the Task function.
Implementation: Static/Dynamic
DRV_SPI_BufferAddWrite2 Registers a buffer for a write operation. Actual transfer will happen in the Task function.
Implementation: Static/Dynamic
DRV_SPI_BufferAddWriteRead Registers a buffer for a read and write operation. Actual transfer will happen in the Task
function.
Implementation: Static/Dynamic
DRV_SPI_BufferAddWriteRead2 Registers a buffer for a read and write operation. Actual transfer will happen in the Task
function.
Implementation: Static/Dynamic
DRV_SPI_BufferStatus Returns the transmitter and receiver transfer status.
Implementation: Static/Dynamic
DRV_SPI_ClientConfigure Configures a SPI client with specific data.
Implementation: Static/Dynamic
DRV_SPI_Close Closes an opened instance of the SPI driver.
Implementation: Static/Dynamic
DRV_SPI_Deinitialize Deinitializes the specified instance of the SPI driver module.
Implementation: Static/Dynamic
DRV_SPI_Initialize Initializes the SPI instance for the specified driver index.
Implementation: Static/Dynamic
DRV_SPI_Open Opens the specified SPI driver instance and returns a handle to it.
Implementation: Static/Dynamic
DRV_SPI_Status Provides the current status of the SPI driver module.
Implementation: Static/Dynamic
DRV_SPI_Tasks Maintains the driver's state machine and implements its ISR.
Implementation: Static/Dynamic
DRV_SPIn_ReceiverBufferIsFull Returns the receive buffer status. 'n' represents the instance of the SPI driver used.
Implementation: Static
DRV_SPIn_TransmitterBufferIsFull Returns the transmit buffer status. 'n' represents the instance of the SPI driver used.
Implementation: Static
Description
SPI Driver Interface
The SPI driver provides a simple interface to manage the SPI module. This file defines the interface definitions and prototypes for the SPI driver.
File Name
drv_spi.h
Company
Microchip Technology Inc.
drv_spi_config_template.h
SPI Driver configuration definitions template.
Macros
Name Description
DRV_SPI_16BIT Controls the compilation of 16 Bit mode
DRV_SPI_32BIT Controls the compilation of 32 Bit mode
DRV_SPI_8BIT Controls the compilation of 8 Bit mode
DRV_SPI_CLIENTS_NUMBER Selects the maximum number of clients.
DRV_SPI_DMA Controls the compilation of DMA support
DRV_SPI_DMA_DUMMY_BUFFER_SIZE Controls the size of DMA dummy buffer
DRV_SPI_DMA_TXFER_SIZE Controls the size of DMA transfers
DRV_SPI_EBM Controls the compilation of Enhanced Buffer Mode mode
DRV_SPI_ELEMENTS_PER_QUEUE Controls the number of elements that are allocated.
DRV_SPI_INSTANCES_NUMBER Selects the maximum number of hardware instances that can be supported by the
dynamic driver .
DRV_SPI_ISR Controls the compilation of ISR mode
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 770
DRV_SPI_MASTER Controls the compilation of master mode
DRV_SPI_POLLED Controls the compilation of Polled mode
DRV_SPI_RM Controls the compilation of Standard Buffer mode
DRV_SPI_SLAVE Controls the compilation of slave mode
Description
SPI Driver Configuration Definitions for the Template Version
These definitions statically define the driver's mode of operation.
File Name
drv_spi_config_template.h
Company
Microchip Technology Inc.
SPI Flash Driver Library
This section describes the Serial Peripheral Interface (SPI) Flash Driver Library.
Introduction
This library provides an interface to manage the SST SPI Flash modules (SST25VF020B, SST25VF016B, and SST25VF064C) in different modes
of operation.
Description
The SPI Flash Driver uses SPI interface to establish the communication between SST Flash and Microchip microcontrollers. The SPI module of
the controller works as a Master device and the Flash module works as a Slave. The following diagram shows the pin connections that are
required to make the driver operational:
The SPI Flash Driver is dynamic in nature, so single instance of it can support multiple clients that want to use the same Flash. Multiple instances
of the driver can be used when multiple Flash devices are required to be part of the system. The SPI Driver, which is used by the SPI Flash Driver,
can be configured for use in either Polled or Interrupt mode.
Using the Library
This topic describes the basic architecture of the SPI Flash Driver Library and provides information and examples on its use.
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 771
Description
Interface Header Files: drv_sst25vf016b.h, drv_sst25vf020b.h, or drv_sst25vf064c.h
The interface to the SPI Flash Driver Library is defined in the header file. Any C language source (.c) file that uses the SPI Flash Driver library
should include this header.
Please refer to the What is MPLAB Harmony? section for how the driver interacts with the framework.
Abstraction Model
This library provides a low-level abstraction of the SPI Flash Driver Library with a convenient C language interface. This topic describes how that
abstraction is modeled in software.
Description
The SST SPI Flash needs a specific set of commands to be given on its SPI interface along with the required address and data to do different
operations. This driver abstracts these requirements and provide simple APIs that can be used to perform Erase, Write, and Read operations. The
SPI Driver is used for this purpose. The following layered diagram depicts the communication between different modules.
Library Overview
Refer to the Driver Library Overview section for information on how the driver operates in a system.
The library interface routines are divided into various sub-sections, which address one of the blocks or the overall operation of the SPI Flash
module.
Library Interface Section Description
System Functions These functions are accessed by the MPLAB Harmony System module and allow the
driver to be initialized, deinitialized, and maintained.
Core Client Functions These functions allow the application client to open and close the driver.
Block Operation Functions These functions enable the Flash module to be erased, written, and read (to/from).
Media Interface Functions These functions provide media status and the Flash geometry.
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 772
How the Library Works
The library provides interfaces to support:
• System Initialization/Deinitialization
• Opening the Driver
• Block Operations
System Initialization and Deinitialization
Provides information on initializing the system.
Description
System Initialization and Deinitialization
The system performs the initialization of the device driver with settings that affect only the instance of the device that is being initialized. During
system initialization each instance of the SST Flash module would be initialized with the following configuration settings (either passed dynamically
at run-time using DRV_SST25VF020B_INIT, DRV_SST25VF016B_INIT, or DRV_SST25VF064C_INIT, or by using Initialization Overrides) that
are supported or used by the specific SST Flash device hardware:
• Device requested power state: one of the System Module Power States. For specific details please refer to Data Types and Constants in the
Library Interface section
• The SPI Driver Module Index which is intended to be used to communicate with SST Flash (e.g., DRV_SPI_INDEX_0)
• Port Pins of the microcontroller to be used for Chip Select, Write Protection, and Hold operations on the SST Flash device
• Maximum Buffer Queue Size for that instance of the SST Flash Driver
Using the SST25VF020B as an example, the DRV_SST25VF020B_Initialize function returns an object handle of the type SYS_MODULE_OBJ.
After this, the object handle returned by the Initialize interface would be used by the other system interfaces like DRV_SST25VF020B_Deinitialize,
DRV_SST25VF020B_Status, and DRV_SST25VF020B_Tasks.
Note:
The system initialization and the deinitialization settings, only affect the instance of the peripheral that is being initialized or
deinitialized.
Example:
// This code example shows the initialization of the SST25VF020B SPI Flash
// Driver. SPI driver index 0 is used for the purpose. Pin numbers 1, 2,
// and 3 of PORTB are configured for the Hold pin, Write Protection pin, and
// the Chip Select pin, respectively. The maximum buffer queue size is set to 5.
DRV_SST25VF020B_INIT SST25VF020BInitData;
SYS_MODULE_OBJ objectHandle;
SST25VF020BInitData.moduleInit.value = SYS_MODULE_POWER_RUN_FULL;
SST25VF020BInitData.spiDriverModuleIndex = DRV_SPI_INDEX_0;
SST25VF020BInitData.holdPortChannel = PORT_CHANNEL_B;
SST25VF020BInitData.holdBitPosition = PORTS_BIT_POS_1;
SST25VF020BInitData.writeProtectPortChannel = PORT_CHANNEL_B;
SST25VF020BInitData.writeProtectBitPosition = PORTS_BIT_POS_2;
SST25VF020BInitData.chipSelectPortChannel = PORT_CHANNEL_F;
SST25VF020BInitData.chipSelectBitPosition = PORTS_BIT_POS_2;
SST25VF020BInitData.queueSize = 5;
objectHandle = DRV_SST25VF020B_Initialize(DRV_SST25VF020B_INDEX_0,
(SYS_MODULE_INIT*)SST25VF020BInitData);
if (SYS_MODULE_OBJ_INVALID == objectHandle)
{
// Handle error
}
Tasks Routine
The system will either call DRV_SST25VF020B_Tasks, from SYS_Tasks (in a polled environment) or DRV_SST25VF020B_Tasks will be called
from the ISR of the SPI module in use.
Opening the Driver
Provides information on opening the driver.
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 773
Description
To use the SST Flash driver, the application must open the driver. Using the SST25VF020B as an example, this is done by calling the
DRV_SST25VF020B_Open function. Calling this function with DRV_IO_INTENT_NONBLOCKING will cause the driver to be opened in non
blocking mode. Then DRV_SST25VF020B_BlockErase, DRV_SST25VF020B_BlockWrite and DRV_SST25VF020B_BlockRead functions when
called by this client will be non-blocking.
The client can also open the driver in Read-only mode (DRV_IO_INTENT_READ), Write-only mode (DRV_IO_INTENT_WRITE), and Exclusive
mode (DRV_IO_INTENT_EXCLUSIVE). If the driver has been opened exclusively by a client, it cannot be opened again by another client.
If successful, the DRV_SST25VF020B_Open function will return a handle to the driver. This handle records the association between the client and
the driver instance that was opened. The DRV_SST25VF020B_Open function may return DRV_HANDLE_INVALID in the situation where the
driver is not ready to be opened. When this occurs, the application can try opening the driver again. Note that the open function may return an
invalid handle in other (error) cases as well.
The following code shows an example of the driver being opened in different modes.
DRV_HANDLE sstHandle1, sstHandle2;
/* Client 1 opens the SST driver in non blocking mode */
sstHandle1 = DRV_SST25VF020B_Open(DRV_SST25VF020B_INDEX_0, DRV_IO_INTENT_NONBLOCKING);
/* Check if the handle is valid */
if(DRV_HANDLE_INVALID == sstHandle1)
{
/* The driver was not opened successfully. The client
* can try opening it again */
}
/* Client 2 opens the SST driver in Exclusive Write only mode */
sstHandle2 = DRV_SST25VF020B_Open(DRV_SST25VF020B_INDEX_0, DRV_IO_INTENT_WRITE | DRV_IO_INTENT_EXCLUSIVE);
/* Check if the handle is valid */
if(DRV_HANDLE_INVALID == sstHandle2)
{
/* The driver was not opened successfully. The client
* can try opening it again */
}
Block Operations
Provides information on block operations.
Description
This driver provides simple client interfaces to Erase, Write, and Read the SST flash in blocks. A block is the unit to represent minimum amount of
data that can be erased, written, or read. Block size may differ for Erase, Write, and Read operations. Using the SST25VF020B as an example,
the DRV_SST25VF020B_GeometryGet function can be used to determine the different block sizes for the driver.
The DRV_SST25VF020B_BlockErase, DRV_SST25VF020B_BlockWrite, and DRV_SST25VF020B_BlockRead functions are used to erase, write,
and read the data to/from SST SPI Flash. These functions are always non-blocking. All of these functions follow a standard queue model to read,
write, and erase. When any of these functions are called (i.e., a block request is made), the request is queued. The size of the queue is
determined by the queueSize member of the DRV_SST25VF020B_INIT data structure. All of the requests in the queue are executed by the
DRV_SST25VF020B_Tasks function one-by-one.
When the driver adds a request to the queue, it returns a buffer handle. This handle allows the client to track the request as it progresses through
the queue. The buffer handle expires when the event associated with the buffer completes. The driver provides driver events
(DRV_SST25VF020B_BLOCK_EVENT) that indicate termination of the buffer requests.
The following steps can be performed for a simple Block Data Operation:
1. The system should have completed necessary initialization of the SPI Driver and the SST Flash Driver, and the DRV_SST25VF020B_Tasks
function should be running in a polled environment.
2. The DRV_SPI_Tasks function should be running in either a polled environment or an interrupt environment.
3. Open the driver using DRV_SST25VF020B_Open with the necessary intent.
4. Set an event handler callback using the function DRV_SST25VF020B_BlockEventHandlerSet.
5. Request for block operations using the functions, DRV_SST25VF020B_BlockErase, DRV_SST25VF020B_BlockWrite, and
DRV_SST25VF020B_BlockRead, with the appropriate parameters.
6. Wait for event handler callback to occur and check the status of the block operation using the callback function parameter of type
DRV_SST25VF020B_BLOCK_EVENT.
7. The client will be able to close the driver using the function, DRV_SST25VF020B_Close, when required.
Example:
/* This code example shows usage of the block operations
* on the SPI Flash SST25VF020B device */
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 774
DRV_HANDLE sstHandle1;
uint8_t myData1[10], myData2[10];
DRV_SST25VF020B_BLOCK_COMMAND_HANDLE blockHandle1, blockHandle2, blockHandle3;
/* The driver is opened for read-write in Exclusive mode */
sstHandle1 = DRV_SST25VF020B_Open(DRV_SST25VF020B_INDEX_0,
DRV_IO_INTENT_READWRITE | DRV_IO_INTENT_EXCLUSIVE);
/* Check if the driver was opened successfully */
if(DRV_HANDLE_INVALID == sstHandle1)
{
/* The driver could not be opened successfully */
}
/* Register a Buffer Event Handler with SST25VF020B driver.
* This event handler function will be called whenever
* there is a buffer event. An application defined
* context can also be specified. This is returned when
* the event handler is called.
* */
DRV_SST25VF020B_BlockEventHandlerSet(sstHandle1,
APP_SSTBufferEventHandler, NULL);
/* Request for all the three block operations one by one */
/* first block API to erase 1 block of the flash starting from address 0x0, each block is of 4kbyte */
DRV_SST25VF020B_BlockErase(sstHandle1, &blockHandle1, 0x0, 1);
/* 2nd block API to write myData1 in the first 10 locations of the flash */
DRV_SST25VF020B_BlockWrite(sstHandle1, &blockHandle2, &myData1[0], 0x0, 10);
/* 3rd block API to read the first 10 locations of the flash into myData2 */
DRV_SST25VF020B_BlockRead(sstHandle1, &blockHandle3, &myData2[0], 0x0, 10);
/* This is the Driver Event Handler */
void APP_SSTBufferEventHandler(DRV_SST25VF020B_BLOCK_EVENT event,
DRV_SST25VF020B_BLOCK_COMMAND_HANDLE blockHandle, uintptr_t contextHandle)
{
switch(event)
{
case DRV_SST25VF020B_EVENT_BLOCK_COMMAND_COMPLETE:
if ( blockHandle == blockHandle3)
{
/* This means the data was read */
/* Do data verification/processing */
}
break;
case DRV_SST25VF020B_EVENT_BLOCK_COMMAND_ERROR:
/* Error handling here. */
break;
default:
break;
}
}
Configuring the Library
SST25VF016B Configuration
Name Description
DRV_SST25VF016B_CLIENTS_NUMBER Sets up the maximum number of clients that can be
connected to any hardware instance.
DRV_SST25VF016B_HARDWARE_HOLD_ENABLE Specifies if the hardware hold feature is enabled or not.
DRV_SST25VF016B_HARDWARE_WRITE_PROTECTION_ENABLE Specifies if the hardware write protect feature is enabled or
not.
DRV_SST25VF016B_INSTANCES_NUMBER Sets up the maximum number of hardware instances that
can be supported
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 775
DRV_SST25VF016B_MODE Determines whether the driver is implemented as static or
dynamic
DRV_SST25VF016B_QUEUE_DEPTH_COMBINED Number of entries of queues in all instances of the driver.
SST25VF020B Configuration
Name Description
DRV_SST25VF020B_CLIENTS_NUMBER Sets up the maximum number of clients that can be
connected to any hardware instance.
DRV_SST25VF020B_HARDWARE_HOLD_ENABLE Specifies if the hardware hold feature is enabled or not.
DRV_SST25VF020B_HARDWARE_WRITE_PROTECTION_ENABLE Specifies if the hardware write protect feature is enabled or
not.
DRV_SST25VF020B_INSTANCES_NUMBER Sets up the maximum number of hardware instances that
can be supported.
DRV_SST25VF020B_MODE Determines whether the driver is implemented as static or
dynamic.
DRV_SST25VF020B_QUEUE_DEPTH_COMBINED Number of entries of queues in all instances of the driver.
SST25VF064C Configuration
Name Description
DRV_SST25VF064C_CLIENTS_NUMBER Sets up the maximum number of clients that can be
connected to any hardware instance.
DRV_SST25VF064C_HARDWARE_HOLD_ENABLE Specifies whether or not the hardware hold feature is
enabled.
DRV_SST25VF064C_HARDWARE_WRITE_PROTECTION_ENABLE Specifies whether or not the hardware write protect feature
is enabled.
DRV_SST25VF064C_INSTANCES_NUMBER Sets up the maximum number of hardware instances that
can be supported.
DRV_SST25VF064C_MODE Determines whether the driver is implemented as static or
dynamic.
DRV_SST25VF064C_QUEUE_DEPTH_COMBINED Number of entries of queues in all instances of the driver.
Description
The SST Flash Driver requires the specification of compile-time configuration macros. These macros define resource usage, feature availability,
and dynamic behavior of the driver. These configuration macros should be defined in the system_config.h file.
This header can be placed anywhere, the path of this header needs to be present in the include search path for a successful build. Refer to the
Applications Help section for more details.
SST25VF016B Configuration
DRV_SST25VF016B_CLIENTS_NUMBER Macro
Sets up the maximum number of clients that can be connected to any hardware instance.
File
drv_sst25vf016b_config_template.h
C
#define DRV_SST25VF016B_CLIENTS_NUMBER 4
Description
SST25VF016B Client Count Configuration
Sets up the maximum number of clients that can be connected to any hardware instance. This value represents the total number of clients to be
supported across all hardware instances. So if SST25VF016B-1 will be accessed by 2 clients and SST25VF016B-2 will accessed by 3 clients, then
this number should be 5. It is recommended that this be set exactly equal to the number of expected clients. Client support consumes RAM
memory space. If this macro is not defined and the DRV_SST25VF016B_INSTANCES_NUMBER macro is not defined, then the driver will be built
for static - single client operation. If this macro is defined and the DRV_SST25VF016B_INSTANCES_NUMBER macro is not defined, then the
driver will be built for static - multi client operation.
Remarks
None.
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 776
DRV_SST25VF016B_HARDWARE_HOLD_ENABLE Macro
Specifies if the hardware hold feature is enabled or not.
File
drv_sst25vf016b_config_template.h
C
#define DRV_SST25VF016B_HARDWARE_HOLD_ENABLE false
Description
SST25VF016B Hardware HOLD Support
This macro defines if the hardware hold feature is enabled or not. If hardware hold is enabled, then user must provide a port pin corresponding to
HOLD pin on the flash
Remarks
None
DRV_SST25VF016B_HARDWARE_WRITE_PROTECTION_ENABLE Macro
Specifies if the hardware write protect feature is enabled or not.
File
drv_sst25vf016b_config_template.h
C
#define DRV_SST25VF016B_HARDWARE_WRITE_PROTECTION_ENABLE false
Description
SST25VF016B Hardware Write Protect Support
This macro defines if the hardware Write Protect feature is enabled or not. If hardware write protection is enabled, then user must provide a port
pin corresponding to WP pin on the flash
Remarks
None.
DRV_SST25VF016B_INSTANCES_NUMBER Macro
Sets up the maximum number of hardware instances that can be supported
File
drv_sst25vf016b_config_template.h
C
#define DRV_SST25VF016B_INSTANCES_NUMBER 2
Description
SST25VF016B driver objects configuration
Sets up the maximum number of hardware instances that can be supported. It is recommended that this number be set exactly equal to the
number of SST25VF016B modules that are needed by the application. Hardware Instance support consumes RAM memory space. If this macro is
not defined, then the driver will be built statically.
Remarks
None.
DRV_SST25VF016B_MODE Macro
Determines whether the driver is implemented as static or dynamic
File
drv_sst25vf016b_config_template.h
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 777
C
#define DRV_SST25VF016B_MODE DYNAMIC
Description
SST25VF016B mode
Determines whether the driver is implemented as static or dynamic. Static drivers control the peripheral directly with peripheral library routines.
Remarks
None.
DRV_SST25VF016B_QUEUE_DEPTH_COMBINED Macro
Number of entries of queues in all instances of the driver.
File
drv_sst25vf016b_config_template.h
C
#define DRV_SST25VF016B_QUEUE_DEPTH_COMBINED 7
Description
SST25VF016B Driver Instance combined queue depth.
This macro defines the number of entries of all queues in all instances of the driver.
Each hardware instance supports a buffer queue for all the read/write/erase operations. The size of queue is specified either in driver initialization
(for dynamic build) or by macros (for static build).
A buffer queue will contain buffer queue entries, each related to a BufferAdd request. This configuration macro defines total number of buffer
entries that will be available for use between all SST25VF016B driver hardware instances. The buffer queue entries are allocated to individual
hardware instances as requested by hardware instances. Once the request is processed, the buffer queue entry is free for use by other hardware
instances.
The total number of buffer entries in the system determines the ability of the driver to service non blocking erase/write/read requests. If a free
buffer entry is not available, the driver will not add the request and will return an invalid buffer handle. More the number of buffer entries, greater
the ability of the driver to service and add requests to its queue. A hardware instance additionally can queue up as many buffer entries as specified
by its buffer queue size.
SST25VF020B Configuration
DRV_SST25VF020B_CLIENTS_NUMBER Macro
Sets up the maximum number of clients that can be connected to any hardware instance.
File
drv_sst25vf020b_config_template.h
C
#define DRV_SST25VF020B_CLIENTS_NUMBER 4
Description
SST25VF020B Client Count Configuration
Sets up the maximum number of clients that can be connected to any hardware instance. This value represents the total number of clients to be
supported across all hardware instances. So if SST25VF020B-1 will be accessed by 2 clients and SST25VF020B-2 will accessed by 3 clients, then
this number should be 5. It is recommended that this be set exactly equal to the number of expected clients. Client support consumes RAM
memory space. If this macro is not defined and the DRV_SST25VF020B_INSTANCES_NUMBER macro is not defined, then the driver will be built
for static - single client operation. If this macro is defined and the DRV_SST25VF020B_INSTANCES_NUMBER macro is not defined, then the
driver will be built for static - multi client operation.
Remarks
None.
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 778
DRV_SST25VF020B_HARDWARE_HOLD_ENABLE Macro
Specifies if the hardware hold feature is enabled or not.
File
drv_sst25vf020b_config_template.h
C
#define DRV_SST25VF020B_HARDWARE_HOLD_ENABLE false
Description
SST25VF020B Hardware HOLD Support
This macro defines if the hardware hold feature is enabled or not. If hardware hold is enabled, then user must provide a port pin corresponding to
HOLD pin on the flash
Remarks
None.
DRV_SST25VF020B_HARDWARE_WRITE_PROTECTION_ENABLE Macro
Specifies if the hardware write protect feature is enabled or not.
File
drv_sst25vf020b_config_template.h
C
#define DRV_SST25VF020B_HARDWARE_WRITE_PROTECTION_ENABLE false
Description
SST25VF020B Hardware Write Protect Support
This macro defines if the hardware Write Protect feature is enabled or not. If hardware write protection is enabled, then user must provide a port
pin corresponding to WP pin on the flash
Remarks
None.
DRV_SST25VF020B_INSTANCES_NUMBER Macro
Sets up the maximum number of hardware instances that can be supported.
File
drv_sst25vf020b_config_template.h
C
#define DRV_SST25VF020B_INSTANCES_NUMBER 2
Description
SST25VF020B driver objects configuration
Sets up the maximum number of hardware instances that can be supported. It is recommended that this number be set exactly equal to the
number of SST25VF020B modules that are needed by the application. Hardware Instance support consumes RAM memory space. If this macro is
not defined, then the driver will be built statically.
Remarks
None.
DRV_SST25VF020B_MODE Macro
Determines whether the driver is implemented as static or dynamic.
File
drv_sst25vf020b_config_template.h
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 779
C
#define DRV_SST25VF020B_MODE DYNAMIC
Description
SST25VF020B mode
Determines whether the driver is implemented as static or dynamic. Static drivers control the peripheral directly with peripheral library routines.
Remarks
None.
DRV_SST25VF020B_QUEUE_DEPTH_COMBINED Macro
Number of entries of queues in all instances of the driver.
File
drv_sst25vf020b_config_template.h
C
#define DRV_SST25VF020B_QUEUE_DEPTH_COMBINED 7
Description
SST25VF020B Driver Instance combined queue depth.
This macro defines the number of entries of all queues in all instances of the driver.
Each hardware instance supports a buffer queue for all the read/write/erase operations. The size of queue is specified either in driver initialization
(for dynamic build) or by macros (for static build).
A buffer queue will contain buffer queue entries, each related to a BufferAdd request. This configuration macro defines total number of buffer
entries that will be available for use between all SST25VF020B driver hardware instances. The buffer queue entries are allocated to individual
hardware instances as requested by hardware instances. Once the request is processed, the buffer queue entry is free for use by other hardware
instances.
The total number of buffer entries in the system determines the ability of the driver to service non blocking erase/write/read requests. If a free
buffer entry is not available, the driver will not add the request and will return an invalid buffer handle. More the number of buffer entries, greater
the ability of the driver to service and add requests to its queue. A hardware instance additionally can queue up as many buffer entries as specified
by its buffer queue size.
SST25VF064C Configuration
DRV_SST25VF064C_CLIENTS_NUMBER Macro
Sets up the maximum number of clients that can be connected to any hardware instance.
File
drv_sst25vf064c_config_template.h
C
#define DRV_SST25VF064C_CLIENTS_NUMBER 4
Description
SST25VF064C Client Count Configuration
Sets up the maximum number of clients that can be connected to any hardware instance. This value represents the total number of clients to be
supported across all hardware instances. So if SST25VF064C-1 will be accessed by 2 clients and SST25VF064C-2 will accessed by 3 clients,
then this number should be 5. It is recommended that this be set exactly equal to the number of expected clients. Client support consumes RAM
memory space. If this macro is not defined and the DRV_SST25VF064C_INSTANCES_NUMBER macro is not defined, then the driver will be built
for static - single client operation. If this macro is defined and the DRV_SST25VF064C_INSTANCES_NUMBER macro is not defined, then the
driver will be built for static - multi client operation.
Remarks
None.
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 780
DRV_SST25VF064C_HARDWARE_HOLD_ENABLE Macro
Specifies whether or not the hardware hold feature is enabled.
File
drv_sst25vf064c_config_template.h
C
#define DRV_SST25VF064C_HARDWARE_HOLD_ENABLE false
Description
SST25VF064C Hardware HOLD Support
This macro defines whether or not the hardware hold feature is enabled. If hardware hold is enabled, the user must provide a port pin
corresponding to the HOLD pin on the Flash device.
Remarks
None.
DRV_SST25VF064C_HARDWARE_WRITE_PROTECTION_ENABLE Macro
Specifies whether or not the hardware write protect feature is enabled.
File
drv_sst25vf064c_config_template.h
C
#define DRV_SST25VF064C_HARDWARE_WRITE_PROTECTION_ENABLE false
Description
SST25VF064C Hardware Write Protect Support
This macro defines whether or not the hardware Write Protect feature is enabled. If hardware write protection is enabled, the user must provide a
port pin corresponding to the WP pin on the Flash device.
Remarks
None.
DRV_SST25VF064C_INSTANCES_NUMBER Macro
Sets up the maximum number of hardware instances that can be supported.
File
drv_sst25vf064c_config_template.h
C
#define DRV_SST25VF064C_INSTANCES_NUMBER 2
Description
SST25VF064C driver objects configuration
Sets up the maximum number of hardware instances that can be supported. It is recommended that this number be set exactly equal to the
number of SST25VF064C modules that are needed by the application. Hardware Instance support consumes RAM memory space. If this macro is
not defined, then the driver will be built statically.
Remarks
None.
DRV_SST25VF064C_MODE Macro
Determines whether the driver is implemented as static or dynamic.
File
drv_sst25vf064c_config_template.h
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 781
C
#define DRV_SST25VF064C_MODE DYNAMIC
Description
SST25VF064C mode
Determines whether the driver is implemented as static or dynamic. Static drivers control the peripheral directly with peripheral library routines.
Remarks
None.
DRV_SST25VF064C_QUEUE_DEPTH_COMBINED Macro
Number of entries of queues in all instances of the driver.
File
drv_sst25vf064c_config_template.h
C
#define DRV_SST25VF064C_QUEUE_DEPTH_COMBINED 7
Description
SST25VF064C Driver Instance combined queue depth.
This macro defines the number of entries of all queues in all instances of the driver.
Each hardware instance supports a buffer queue for all the read/write/erase operations. The size of queue is specified either in driver initialization
(for dynamic build) or by macros (for static build).
A buffer queue will contain buffer queue entries, each related to a BufferAdd request. This configuration macro defines total number of buffer
entries that will be available for use between all SST25VF064C driver hardware instances. The buffer queue entries are allocated to individual
hardware instances as requested by hardware instances. Once the request is processed, the buffer queue entry is free for use by other hardware
instances.
The total number of buffer entries in the system determines the ability of the driver to service non blocking erase/write/read requests. If a free
buffer entry is not available, the driver will not add the request and will return an invalid buffer handle. More the number of buffer entries, greater
the ability of the driver to service and add requests to its queue. A hardware instance additionally can queue up as many buffer entries as specified
by its buffer queue size.
Building the Library
This section lists the files that are available in the SPI Flash Driver Library.
Description
This section list the files that are available in the /src folder of the SPI Flash Driver. It lists which files need to be included in the build based on
either a hardware feature present on the board or configuration option selected by the system.
The following three tables list and describe the header (.h) and source (.c) files that implement this library. The parent folder for these files is
/framework/driver/spi_flash.
Interface File(s)
This table lists and describes the header files that must be included (i.e., using #include) by any code that uses this library.
Source File Name Description
sst25vf016b/drv_sst25vf016b.h Header file that exports the SST25VF016B driver API.
sst25vf020b/drv_sst25vf020b.h Header file that exports the SST25VF020B driver API.
sst25vf064c/drv_sst25vf064c.h Header file that exports the SST25VF064C driver API.
Required File(s)
All of the required files listed in the following table are automatically added into the MPLAB X IDE project by the MHC
when the library is selected for use.
This table lists and describes the source and header files that must always be included in the MPLAB X IDE project to build this library.
Source File Name Description
sst25vf016b/src/dynamic/drv_sst25vf016b.c Basic SPI Flash Driver SST25VF016B implementation file.
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 782
sst25vf020b/src/dynamic/drv_sst25vf020b.c Basic SPI Flash Driver SST25VF020B implementation file.
sst25vf064c/src/dynamic/drv_sst25vf064c.c Basic SPI Flash Driver SST25VF064C implementation file.
Optional File(s)
This table lists and describes the source and header files that may optionally be included if required for the desired implementation.
Source File Name Description
sst25vf020b/src/dynamic/drv_sst25vf020b_erasewrite.c This file implements an optional BlockEraseWrite feature for the
SST25VF020B driver.
Module Dependencies
The SPI Flash Driver Library depends on the following modules:
• SPI Driver Library
• Ports System Service Library
Library Interface
This section describes the API functions of the SPI Flash Driver Library.
Refer to each section for a detailed description.
SST25FV016B API
a) System Functions
Name Description
DRV_SST25VF016B_Initialize Initializes the SST25VF016B SPI Flash Driver instance for the specified driver index.
Implementation: Dynamic
DRV_SST25VF016B_Deinitialize Deinitializes the specified instance of the SPI Flash driver module.
Implementation: Dynamic
DRV_SST25VF016B_Status Gets the current status of the SPI Flash Driver module.
Implementation: Dynamic
DRV_SST25VF016B_Tasks Maintains the driver's read, erase, and write state machine and implements its ISR.
Implementation: Dynamic
b) Core Client Functions
Name Description
DRV_SST25VF016B_Close Closes an opened-instance of the SPI Flash driver.
Implementation: Dynamic
DRV_SST25VF016B_Open Opens the specified SPI Flash driver instance and returns a handle to it.
Implementation: Dynamic
DRV_SST25VF016B_ClientStatus Gets current client-specific status of the SPI Flash driver.
Implementation: Dynamic
c) Block Operation Functions
Name Description
DRV_SST25VF016B_BlockErase Erase the specified number of blocks in Flash memory.
Implementation: Dynamic
DRV_SST25VF016B_BlockEventHandlerSet Allows a client to identify an event handling function for the driver to call back when
queued operation has completed.
Implementation: Dynamic
DRV_SST25VF016B_BlockRead Reads blocks of data starting from the specified address in Flash memory.
Implementation: Dynamic
DRV_SST25VF016B_BlockWrite Write blocks of data starting from a specified address in Flash memory.
Implementation: Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 783
d) Media Interface Functions
Name Description
DRV_SST25VF016B_GeometryGet Returns the geometry of the device.
Implementation: Dynamic
DRV_SST25VF016B_MediaIsAttached Returns the status of the media.
Implementation: Dynamic
e) Data Types and Constants
Name Description
DRV_SST25VF016B_BLOCK_COMMAND_HANDLE Handle identifying block commands of the driver.
DRV_SST25VF016B_BLOCK_EVENT Identifies the possible events that can result from a request.
DRV_SST25VF016B_CLIENT_STATUS Defines the client status.
Implementation: Dynamic
DRV_SST25VF016B_EVENT_HANDLER Pointer to a SST25VF016B SPI Flash Driver Event handler
function.
Implementation: Dynamic
DRV_SST25VF016B_INIT Contains all the data necessary to initialize the SPI Flash device.
Implementation: Dynamic
DRV_SST25VF016B_BLOCK_COMMAND_HANDLE_INVALID This value defines the SPI Flash Driver Block Command Invalid
handle.
DRV_SST25VF016B_INDEX_0 SPI Flash driver index definitions
DRV_SST25VF016B_INDEX_1 This is macro DRV_SST25VF016B_INDEX_1.
Description
This section contains the SST25V016B Flash device API.
a) System Functions
DRV_SST25VF016B_Initialize Function
Initializes the SST25VF016B SPI Flash Driver instance for the specified driver index.
Implementation: Dynamic
File
drv_sst25vf016b.h
C
SYS_MODULE_OBJ DRV_SST25VF016B_Initialize(const SYS_MODULE_INDEX index, const SYS_MODULE_INIT * const init);
Returns
If successful, returns a valid handle to a driver instance object. Otherwise, it returns SYS_MODULE_OBJ_INVALID.
Description
This function initializes the SPI Flash driver instance for the specified driver index, making it ready for clients to open and use it.
Remarks
This function must be called before any other SPI Flash function is called.
This function should only be called once during system initialization unless DRV_SST25VF016B_Deinitialize is called to deinitialize the driver
instance.
Build configuration options may be used to statically override options in the "init" structure and will take precedence over initialization data passed
using this function.
Preconditions
None.
Example
// This code snippet shows an example of initializing the SST25VF016B SPI
// Flash Driver. SPI driver index 0 is used for the purpose. Pin numbers 1, 2
// and 3 of port channel B are configured for hold pin, write protection pin
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 784
// and chip select pin respectively. Maximum buffer queue size is set 5.
DRV_SST25VF016B_INIT SST25VF016BInitData;
SYS_MODULE_OBJ objectHandle;
SST25VF016BInitData.moduleInit.value = SYS_MODULE_POWER_RUN_FULL;
SST25VF016BInitData.spiDriverModuleIndex = DRV_SPI_INDEX_0;
SST25VF016BInitData.holdPortChannel = PORT_CHANNEL_B;
SST25VF016BInitData.holdBitPosition = PORTS_BIT_POS_1;
SST25VF016BInitData.writeProtectPortChannel = PORT_CHANNEL_B;
SST25VF016BInitData.writeProtectBitPosition = PORTS_BIT_POS_2;
SST25VF016BInitData.chipSelectPortChannel = PORT_CHANNEL_F;
SST25VF016BInitData.chipSelectBitPosition = PORTS_BIT_POS_2;
SST25VF016BInitData.queueSize = 5;
objectHandle = DRV_SST25VF016B_Initialize(DRV_SST25VF016B_INDEX_0,
(SYS_MODULE_INIT*)SST25VF016BInitData);
if (SYS_MODULE_OBJ_INVALID == objectHandle)
{
// Handle error
}
Parameters
Parameters Description
index Identifier for the instance to be initialized
init Pointer to a data structure containing data necessary to initialize the driver.
Function
SYS_MODULE_OBJ DRV_SST25VF016B_Initialize
(
const SYS_MODULE_INDEX index,
const SYS_MODULE_INIT * const init
);
DRV_SST25VF016B_Deinitialize Function
Deinitializes the specified instance of the SPI Flash driver module.
Implementation: Dynamic
File
drv_sst25vf016b.h
C
void DRV_SST25VF016B_Deinitialize(SYS_MODULE_OBJ object);
Returns
None.
Description
Deinitializes the specified instance of the SPI Flash Driver module, disabling its operation (and any hardware) and invalidates all of the internal
data.
Remarks
Once the Initialize operation has been called, the Deinitialize operation must be called before the Initialize operation can be called again. This
function will NEVER block waiting for hardware.
Preconditions
Function DRV_SST25VF016B_Initialize should have been called before calling this function.
Example
// This code snippet shows an example of deinitializing the driver.
SYS_MODULE_OBJ object; // Returned from DRV_SST25VF016B_Initialize
SYS_STATUS status;
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 785
DRV_SST25VF016B_Deinitialize(object);
status = DRV_SST25VF016B_Status(object);
if (SYS_MODULE_DEINITIALIZED != status)
{
// Check again later if you need to know
// when the driver is deinitialized.
}
Parameters
Parameters Description
object Driver object handle, returned from the DRV_SST25VF016B_Initialize
Function
void DRV_SST25VF016B_Deinitialize( SYS_MODULE_OBJ object )
DRV_SST25VF016B_Status Function
Gets the current status of the SPI Flash Driver module.
Implementation: Dynamic
File
drv_sst25vf016b.h
C
SYS_STATUS DRV_SST25VF016B_Status(SYS_MODULE_OBJ object);
Returns
SYS_STATUS_READY - Indicates that the driver is ready and accept requests for new operations
SYS_STATUS_UNINITIALIZED - Indicates that the driver is not initialized
Description
This function provides the current status of the SPI Flash Driver module.
Remarks
A driver can only be opened when its status is SYS_STATUS_READY.
Preconditions
Function DRV_SST25VF016B_Initialize should have been called before calling this function.
Example
SYS_MODULE_OBJ object; // Returned from DRV_SST25VF016B_Initialize
SYS_STATUS SST25VF016BStatus;
SST25VF016BStatus = DRV_SST25VF016B_Status(object);
else if (SYS_STATUS_ERROR >= SST25VF016BStatus)
{
// Handle error
}
Parameters
Parameters Description
object Driver object handle, returned from the DRV_SST25VF016B_Initialize
Function
SYS_STATUS DRV_SST25VF016B_Status( SYS_MODULE_OBJ object )
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 786
DRV_SST25VF016B_Tasks Function
Maintains the driver's read, erase, and write state machine and implements its ISR.
Implementation: Dynamic
File
drv_sst25vf016b.h
C
void DRV_SST25VF016B_Tasks(SYS_MODULE_OBJ object);
Returns
None.
Description
This function is used to maintain the driver's internal state machine and should be called from the system's Tasks function.
Remarks
This function is normally not called directly by an application. It is called by the system's Tasks function (SYS_Tasks).
Preconditions
The DRV_SST25VF016B_Initialize function must have been called for the specified SPI Flash driver instance.
Example
SYS_MODULE_OBJ object; // Returned from DRV_SST25VF016B_Initialize
while (true)
{
DRV_SST25VF016B_Tasks (object);
// Do other tasks
}
Parameters
Parameters Description
object Object handle for the specified driver instance (returned from DRV_SST25VF016B_Initialize)
Function
void DRV_SST25VF016B_Tasks ( SYS_MODULE_OBJ object );
b) Core Client Functions
DRV_SST25VF016B_Close Function
Closes an opened-instance of the SPI Flash driver.
Implementation: Dynamic
File
drv_sst25vf016b.h
C
void DRV_SST25VF016B_Close(const DRV_HANDLE handle);
Returns
None.
Description
This function closes an opened-instance of the SPI Flash driver, invalidating the handle.
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 787
Remarks
After calling this function, the handle passed in "handle" must not be used with any of the remaining driver routines. A new handle must be
obtained by calling DRV_SST25VF016B_Open before the caller may use the driver again.
Usually, there is no need for the driver client to verify that the Close operation has completed.
Preconditions
The DRV_SST25VF016B_Initialize function must have been called for the specified SPI Flash driver instance.
DRV_SST25VF016B_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE handle; // Returned from DRV_SST25VF016B_Open
DRV_SST25VF016B_Close(handle);
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
Function
void DRV_SST25VF016B_Close( DRV_Handle handle );
DRV_SST25VF016B_Open Function
Opens the specified SPI Flash driver instance and returns a handle to it.
Implementation: Dynamic
File
drv_sst25vf016b.h
C
DRV_HANDLE DRV_SST25VF016B_Open(const SYS_MODULE_INDEX drvIndex, const DRV_IO_INTENT ioIntent);
Returns
If successful, the function returns a valid open-instance handle (a number identifying both the caller and the module instance).
If an error occurs, the return value is DRV_HANDLE_INVALID. Errors can occur under the following circumstances:
• if the number of client objects allocated via DRV_SST25VF016B_CLIENTS_NUMBER is insufficient
• if the client is trying to open the driver but driver has been opened exclusively by another client
• if the driver hardware instance being opened is not initialized or is invalid
• if the client is trying to open the driver exclusively, but has already been opened in a non exclusive mode by another client.
• if the driver status is not ready.
The driver status becomes ready inside "DRV_SST25VF016B_Tasks" function. To make the SST Driver status ready and hence successfully
"Open" the driver, "Task" routine need to be called periodically.
Description
This function opens the specified SPI Flash driver instance and provides a handle that must be provided to all other client-level operations to
identify the caller and the instance of the driver.
Remarks
The driver will always work in Non-Blocking mode even if IO-intent is selected as blocking.
The handle returned is valid until the DRV_SST25VF016B_Close function is called.
This function will NEVER block waiting for hardware.
Preconditions
Function DRV_SST25VF016B_Initialize must have been called before calling this function.
Example
DRV_HANDLE handle;
handle = DRV_SST25VF016B_Open(DRV_SST25VF016B_INDEX_0,
DRV_IO_INTENT_EXCLUSIVE);
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 788
if (DRV_HANDLE_INVALID == handle)
{
// Unable to open the driver
}
Parameters
Parameters Description
drvIndex Identifier for the object instance to be opened
ioIntent Zero or more of the values from the enumeration DRV_IO_INTENT "ORed" together to
indicate the intended use of the driver
Function
DRV_HANDLE DRV_SST25VF016B_Open
(
const SYS_MODULE_INDEX drvIndex,
const DRV_IO_INTENT ioIntent
);
DRV_SST25VF016B_ClientStatus Function
Gets current client-specific status of the SPI Flash driver.
Implementation: Dynamic
File
drv_sst25vf016b.h
C
DRV_SST25VF016B_CLIENT_STATUS DRV_SST25VF016B_ClientStatus(const DRV_HANDLE handle);
Returns
A DRV_SST25VF016B_CLIENT_STATUS value describing the current status of the driver.
Description
This function gets the client-specific status of the SPI Flash driver associated with the given handle.
Remarks
This function will not block for hardware access and will immediately return the current status.
Preconditions
The DRV_SST25VF016B_Initialize function must have been called.
DRV_SST25VF016B_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE handle; // Returned from DRV_SST25VF016B_Open
DRV_SST25VF016B_CLIENT_STATUS clientStatus;
clientStatus = DRV_SST25VF016B_ClientStatus(handle);
if(DRV_SST25VF016B_CLIENT_STATUS_READY == clientStatus)
{
// do the tasks
}
Parameters
Parameters Description
handle A valid open instance handle, returned from the driver's open
Function
DRV_SST25VF016B_CLIENT_STATUS DRV_SST25VF016B_ClientStatus(DRV_HANDLE handle);
c) Block Operation Functions
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 789
DRV_SST25VF016B_BlockErase Function
Erase the specified number of blocks in Flash memory.
Implementation: Dynamic
File
drv_sst25vf016b.h
C
void DRV_SST25VF016B_BlockErase(const DRV_HANDLE handle, DRV_SST25VF016B_BLOCK_COMMAND_HANDLE *
commandHandle, uint32_t blockStart, uint32_t nBlock);
Returns
The buffer handle is returned in the commandHandle argument. It Will be DRV_BUFFER_HANDLE_INVALID if the request was not queued.
Description
This function schedules a non-blocking erase operation in flash memory. The function returns with a valid erase handle in the commandHandle
argument if the erase request was scheduled successfully. The function adds the request to the hardware instance queue and returns
immediately. The function returns DRV_SST25VF016B_BLOCK_COMMAND_HANDLE_INVALID in the commandHandle argument under the
following circumstances:
• if the client opened the driver for read only
• if nBlock is 0
• if the queue size is full or queue depth is insufficient
• if the driver handle is invalid
If the requesting client registered an event callback with the driver, the driver will issue a DRV_SST25VF016B_EVENT_ERASE_COMPLETE
event if the erase operation was successful or DRV_SST25VF016B_EVENT_ERASE_ERROR event if the erase operation was not successful.
Remarks
Write Protection will be disabled for the complete flash memory region in the beginning by default.
Preconditions
The DRV_SST25VF016B_Initialize function must have been called for the specified SPI Flash driver instance.
DRV_SST25VF016B_Open must have been called to obtain a valid opened device handle.
DRV_IO_INTENT_WRITE or DRV_IO_INTENT_READWRITE must have been specified in the DRV_SST25VF016B_Open call.
Example
// Destination address should be block aligned.
uint32_t blockStart;
uint32_t nBlock;
DRV_SST25VF016B_BLOCK_COMMAND_HANDLE commandHandle;
MY_APP_OBJ myAppObj;
// mySST25VF016BHandle is the handle returned
// by the DRV_SST25VF016B_Open function.
// Client registers an event handler with driver
DRV_SST25VF016B_BlockEventHandlerSet(mySST25VF016BHandle,
APP_SST25VF016BEventHandler, (uintptr_t)&myAppObj);
DRV_SST25VF016B_BlockErase( mySST25VF016BHandle, commandHandle,
blockStart, nBlock );
if(DRV_SST25VF016B_BLOCK_COMMAND_HANDLE_INVALID == commandHandle)
{
// Error handling here
}
// Event is received when
// the buffer queue is processed.
void APP_SST25VF016BEventHandler(DRV_SST25VF016B_BLOCK_EVENT event,
DRV_SST25VF016B_BLOCK_COMMAND_HANDLE commandHandle, uintptr_t contextHandle)
{
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 790
// contextHandle points to myAppObj.
switch(event)
{
case DRV_SST25VF016B_EVENT_ERASE_COMPLETE:
// This means the data was transferred.
break;
case DRV_SST25VF016B_EVENT_ERASE_ERROR:
// Error handling here.
break;
default:
break;
}
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
commandHandle Pointer to an argument that will contain the return buffer handle
blockStart Start block address in SST25VF016B memory from where the erase should begin. LSBs
(A0-A11) of block start address will be ignored to align it with Erase block size boundary.
nBlock Total number of blocks to be erased. Each Erase block is of size 4 KByte.
Function
void DRV_SST25VF016B_BlockErase
(
const DRV_HANDLE handle,
DRV_SST25VF016B_BLOCK_COMMAND_HANDLE * commandHandle,
uint32_t blockStart,
uint32_t nBlock
);
DRV_SST25VF016B_BlockEventHandlerSet Function
Allows a client to identify an event handling function for the driver to call back when queued operation has completed.
Implementation: Dynamic
File
drv_sst25vf016b.h
C
void DRV_SST25VF016B_BlockEventHandlerSet(const DRV_HANDLE handle, const DRV_SST25VF016B_EVENT_HANDLER
eventHandler, const uintptr_t context);
Returns
None.
Description
This function allows a client to identify an event handling function for the driver to call back when queued operation has completed. When a client
calls any read, write or erase function, it is provided with a handle identifying the buffer that was added to the driver's buffer queue. The driver will
pass this handle back to the client by calling "eventHandler" function when the queued operation has completed.
The event handler should be set before the client performs any read/write/erase operations that could generate events. The event handler once
set, persists until the client closes the driver or sets another event handler (which could be a "NULL" pointer to indicate no callback).
Remarks
If the client does not want to be notified when the queued operation has completed, it does not need to register a callback.
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 791
Preconditions
The DRV_SST25VF016B_Initialize function must have been called for the specified SPI FLash driver instance.
DRV_SST25VF016B_Open must have been called to obtain a valid opened device handle.
Example
// myAppObj is an application specific state data object.
MY_APP_OBJ myAppObj;
uint8_t myBuffer[MY_BUFFER_SIZE];
uint32_t blockStart, nBlock;
DRV_SST25VF016B_BLOCK_COMMAND_HANDLE commandHandle;
// mySST25VF016BHandle is the handle returned
// by the DRV_SST25VF016B_Open function.
// Client registers an event handler with driver. This is done once.
DRV_SST25VF016B_BlockEventHandlerSet( mySST25VF016BHandle,
APP_SST25VF016BEventHandler, (uintptr_t)&myAppObj );
DRV_SST25VF016B_BlockRead( mySST25VF016BHandle, commandHandle,
&myBuffer, blockStart, nBlock );
if(DRV_SST25VF016B_BLOCK_COMMAND_HANDLE_INVALID == commandHandle)
{
// Error handling here
}
// Event Processing Technique. Event is received when operation is done.
void APP_SST25VF016BEventHandler(DRV_SST25VF016B_BLOCK_EVENT event,
DRV_SST25VF016B_BLOCK_COMMAND_HANDLE handle, uintptr_t context)
{
// The context handle was set to an application specific
// object. It is now retrievable easily in the event handler.
MY_APP_OBJ myAppObj = (MY_APP_OBJ *) context;
switch(event)
{
case DRV_SST25VF016B_EVENT_BLOCK_COMMAND_COMPLETE:
// This means the data was transferred.
break;
case DRV_SST25VF016B_EVENT_BLOCK_COMMAND_ERROR:
// Error handling here.
break;
default:
break;
}
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
eventHandler Pointer to the event handler function implemented by the user
context The value of parameter will be passed back to the client unchanged, when the eventHandler
function is called. It can be used to identify any client specific data object that identifies the
instance of the client module (for example, it may be a pointer to the client module's state
structure).
Function
void DRV_SST25VF016B_BlockEventHandlerSet
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 792
(
const DRV_HANDLE handle,
const DRV_SST25VF016B_EVENT_HANDLER eventHandler,
const uintptr_t context
);
DRV_SST25VF016B_BlockRead Function
Reads blocks of data starting from the specified address in Flash memory.
Implementation: Dynamic
File
drv_sst25vf016b.h
C
void DRV_SST25VF016B_BlockRead(const DRV_HANDLE handle, DRV_SST25VF016B_BLOCK_COMMAND_HANDLE *
commandHandle, uint8_t * targetBuffer, uint32_t blockStart, uint32_t nBlock);
Returns
The buffer handle is returned in the commandHandle argument. It will be DRV_BUFFER_HANDLE_INVALID if the request was not successful.
Description
This function schedules a non-blocking read operation for reading blocks of data from flash memory. The function returns with a valid handle in the
commandHandle argument if the read request was scheduled successfully. The function adds the request to the hardware instance queue and
returns immediately. While the request is in the queue, the application buffer is owned by the driver and should not be modified. The function
returns DRV_SST25VF016B_BLOCK_COMMAND_HANDLE_INVALID in the commandHandle argument under the following circumstances:
• if a buffer could not be allocated to the request
• if the target buffer pointer is NULL
• if the client opened the driver for write only
• if the buffer size is 0
• if the read queue size is full or queue depth is insufficient
• if the driver handle is invalid
If the requesting client registered an event callback with the driver, the driver will issue a
DRV_SST25VF016B_EVENT_BLOCK_COMMAND_COMPLETE event if the buffer was processed successfully of
DRV_SST25VF016B_EVENT_BLOCK_COMMAND_ERROR event if the buffer was not processed successfully.
Remarks
The maximum read speed is 33 MHz.
Preconditions
The DRV_SST25VF016B_Initialize function must have been called for the specified SPI Flash driver instance.
DRV_SST25VF016B_Open must have been called to obtain a valid opened device handle.
DRV_IO_INTENT_READ or DRV_IO_INTENT_READWRITE must have been specified in the DRV_SST25VF016B_Open call.
Example
uint8_t myBuffer[MY_BUFFER_SIZE];
// address should be block aligned.
uint32_t blockStart = SST25VF016B_BASE_ADDRESS_TO_READ_FROM;
uint32_t nBlock = 2;
DRV_SST25VF016B_BLOCK_COMMAND_HANDLE commandHandle;
MY_APP_OBJ myAppObj;
// mySST25VF016BHandle is the handle returned
// by the DRV_SST25VF016B_Open function.
// Client registers an event handler with driver
DRV_SST25VF016B_BlockEventHandlerSet(mySST25VF016BHandle,
APP_SST25VF016BEventHandler, (uintptr_t)&myAppObj);
DRV_SST25VF016B_BlockRead( mySST25VF016BHandle, commandHandle,
&myBuffer, blockStart, nBlock );
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 793
if(DRV_SST25VF016B_BLOCK_COMMAND_HANDLE_INVALID == commandHandle)
{
// Error handling here
}
// Event is received when the buffer is processed.
void APP_SST25VF016BEventHandler(DRV_SST25VF016B_BLOCK_EVENT event,
DRV_SST25VF016B_BLOCK_COMMAND_HANDLE commandHandle, uintptr_t contextHandle)
{
// contextHandle points to myAppObj.
switch(event)
{
case DRV_SST25VF016B_EVENT_BLOCK_COMMAND_COMPLETE:
// This means the data was transferred.
break;
case DRV_SST25VF016B_EVENT_BLOCK_COMMAND_ERROR:
// Error handling here.
break;
default:
break;
}
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
commandHandle Pointer to an argument that will contain the return buffer handle
*targetBuffer Buffer into which the data read from the SPI Flash instance will be placed
blockStart Start block address in SST25VF016B memory from where the read should begin. It can be
any address of the flash.
nBlock Total number of blocks to be read. Each Read block is of 1 byte.
Function
void DRV_SST25VF016B_BlockRead
(
const DRV_HANDLE handle,
DRV_SST25VF016B_BLOCK_COMMAND_HANDLE * commandHandle,
uint8_t *targetBuffer,
uint32_t blockStart,
uint32_t nBlock
);
DRV_SST25VF016B_BlockWrite Function
Write blocks of data starting from a specified address in Flash memory.
Implementation: Dynamic
File
drv_sst25vf016b.h
C
void DRV_SST25VF016B_BlockWrite(DRV_HANDLE handle, DRV_SST25VF016B_BLOCK_COMMAND_HANDLE * commandHandle,
uint8_t * sourceBuffer, uint32_t blockStart, uint32_t nBlock);
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 794
Returns
The buffer handle is returned in the commandHandle argument. It will be DRV_BUFFER_HANDLE_INVALID if the request was not successful.
Description
This function schedules a non-blocking write operation for writing blocks of data into flash memory. The function returns with a valid buffer handle
in the commandHandle argument if the write request was scheduled successfully. The function adds the request to the hardware instance queue
and returns immediately. While the request is in the queue, the application buffer is owned by the driver and should not be modified. The function
returns DRV_SST25VF016B_BLOCK_COMMAND_HANDLE_INVALID in the commandHandle argument under the following circumstances:
• if a buffer could not be allocated to the request
• if the input buffer pointer is NULL
• if the client opened the driver for read only
• if the buffer size is 0
• if the write queue size is full or queue depth is insufficient
• if the driver handle is invalid
If the requesting client registered an event callback with the driver, the driver will issue a
DRV_SST25VF016B_EVENT_BLOCK_COMMAND_COMPLETE event if the buffer was processed successfully or
DRV_SST25VF016B_EVENT_BLOCK_COMMAND_ERROR event if the buffer was not processed successfully.
Remarks
In the case of multi bytes write operation, byte by byte writing will happen instead of Address auto Increment writing.
Write Protection will be disabled for the complete flash memory region in the beginning by default.
Preconditions
The DRV_SST25VF016B_Initialize function must have been called for the specified SPI Flash driver instance.
DRV_SST25VF016B_Open must have been called to obtain a valid opened device handle.
DRV_IO_INTENT_WRITE or DRV_IO_INTENT_READWRITE must have been specified in the DRV_SST25VF016B_Open call.
The flash address location which has to be written, must be erased before using the API DRV_SST25VF016B_BlockErase().
Example
uint8_t myBuffer[MY_BUFFER_SIZE];
// address should be block aligned.
uint32_t blockStart = SST25VF016B_BASE_ADDRESS_TO_WRITE_TO;
uint32_t nBlock = 2;
DRV_SST25VF016B_BLOCK_COMMAND_HANDLE commandHandle;
MY_APP_OBJ myAppObj;
// mySST25VF016BHandle is the handle returned
// by the DRV_SST25VF016B_Open function.
// Client registers an event handler with driver
DRV_SST25VF016B_BlockEventHandlerSet(mySST25VF016BHandle,
APP_SST25VF016BEventHandler, (uintptr_t)&myAppObj);
DRV_SST25VF016B_BlockWrite( mySST25VF016BHandle, commandHandle,
&myBuffer, blockStart, nBlock );
if(DRV_SST25VF016B_BLOCK_COMMAND_HANDLE_INVALID == commandHandle)
{
// Error handling here
}
// Event is received when
// the buffer is processed.
void APP_SST25VF016BEventHandler(DRV_SST25VF016B_BLOCK_EVENT event,
DRV_SST25VF016B_BLOCK_COMMAND_HANDLE commandHandle, uintptr_t contextHandle)
{
// contextHandle points to myAppObj.
switch(event)
{
case DRV_SST25VF016B_EVENT_BLOCK_COMMAND_COMPLETE:
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 795
// This means the data was transferred.
break;
case DRV_SST25VF016B_EVENT_BLOCK_COMMAND_ERROR:
// Error handling here.
break;
default:
break;
}
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
commandHandle -Pointer to an argument that will contain the return buffer handle
sourceBuffer The source buffer containing data to be programmed into SPI Flash
blockStart Start block address of SST25VF016B Flash where the write should begin. It can be any
address of the flash.
nBlock Total number of blocks to be written. Each write block is of 1 byte.
Function
void DRV_SST25VF016B_BlockWrite
(
DRV_HANDLE handle,
DRV_SST25VF016B_BLOCK_COMMAND_HANDLE * commandHandle,
uint8_t *sourceBuffer,
uint32_t blockStart,
uint32_t nBlock
);
d) Media Interface Functions
DRV_SST25VF016B_GeometryGet Function
Returns the geometry of the device.
Implementation: Dynamic
File
drv_sst25vf016b.h
C
SYS_FS_MEDIA_GEOMETRY * DRV_SST25VF016B_GeometryGet(DRV_HANDLE handle);
Returns
SYS_FS_MEDIA_GEOMETRY - Structure which holds the media geometry information.
Description
This API gives the following geometrical details of the SST25VF016B Flash:
• Media Property
• Number of Read/Write/Erase regions in the flash device
• Number of Blocks and their size in each region of the device
Remarks
This function is typically used by File System Media Manager.
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 796
Preconditions
None.
Example
SYS_FS_MEDIA_GEOMETRY * sstFlashGeometry;
uint32_t readBlockSize, writeBlockSize, eraseBlockSize;
uint32_t nReadBlocks, nReadRegions, totalFlashSize;
sstFlashGeometry = DRV_SST25VF016B_GeometryGet(sstOpenHandle1);
// read block size should be 1 byte
readBlockSize = sstFlashGeometry->geometryTable->blockSize;
nReadBlocks = sstFlashGeometry->geometryTable->numBlocks;
nReadRegions = sstFlashGeometry->numReadRegions;
// write block size should be 1 byte
writeBlockSize = (sstFlashGeometry->geometryTable +1)->blockSize;
// erase block size should be 4k byte
eraseBlockSize = (sstFlashGeometry->geometryTable +2)->blockSize;
// total flash size should be 256k byte
totalFlashSize = readBlockSize * nReadBlocks * nReadRegions;
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
Function
SYS_FS_MEDIA_GEOMETRY DRV_SST25VF016B_GeometryGet( DRV_HANDLE handle );
DRV_SST25VF016B_MediaIsAttached Function
Returns the status of the media.
Implementation: Dynamic
File
drv_sst25vf016b.h
C
bool DRV_SST25VF016B_MediaIsAttached(DRV_HANDLE handle);
Returns
• True - Media is attached
• False - Media is not attached
Description
This API tells if the media is attached or not.
Remarks
This function is typically used by File System Media Manager.
Preconditions
None.
Example
if (DRV_SST25VF016B_MediaIsAttached(handle))
{
// Do Something
}
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 797
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
Function
bool DRV_SST25VF016B_MediaIsAttached( DRV_HANDLE handle);
e) Data Types and Constants
DRV_SST25VF016B_BLOCK_COMMAND_HANDLE Type
Handle identifying block commands of the driver.
File
drv_sst25vf016b.h
C
typedef SYS_FS_MEDIA_BLOCK_COMMAND_HANDLE DRV_SST25VF016B_BLOCK_COMMAND_HANDLE;
Description
SPI Flash Driver Block Command Handle
A block command handle is returned by a call to the Read, Write, or Erase functions. This handle allows the application to track the completion of
the operation. The handle is returned back to the client by the "event handler callback" function registered with the driver.
The handle assigned to a client request expires when the client has been notified of the completion of the operation (after event handler function
that notifies the client returns) or after the buffer has been retired by the driver if no event handler callback was set.
Remarks
None.
DRV_SST25VF016B_BLOCK_EVENT Enumeration
Identifies the possible events that can result from a request.
File
drv_sst25vf016b.h
C
typedef enum {
DRV_SST25VF016B_EVENT_BLOCK_COMMAND_COMPLETE,
DRV_SST25VF016B_EVENT_BLOCK_COMMAND_ERROR
} DRV_SST25VF016B_BLOCK_EVENT;
Members
Members Description
DRV_SST25VF016B_EVENT_BLOCK_COMMAND_COMPLETE Block operation has been completed successfully. Read/Write/Erase Complete
DRV_SST25VF016B_EVENT_BLOCK_COMMAND_ERROR There was an error during the block operation Read/Write/Erase Error
Description
SST25VF016B SPI Flash Driver Events
This enumeration identifies the possible events that can result from a Read, Write, or Erase request caused by the client.
Remarks
One of these values is passed in the "event" parameter of the event handling callback function that client registered with the driver by calling the
DRV_SST25VF016B_BlockEventHandlerSet function when a block request is completed.
DRV_SST25VF016B_CLIENT_STATUS Enumeration
Defines the client status.
Implementation: Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 798
File
drv_sst25vf016b.h
C
typedef enum {
DRV_SST25VF016B_CLIENT_STATUS_READY = DRV_CLIENT_STATUS_READY+0,
DRV_SST25VF016B_CLIENT_STATUS_BUSY = DRV_CLIENT_STATUS_BUSY,
DRV_SST25VF016B_CLIENT_STATUS_CLOSED = DRV_CLIENT_STATUS_CLOSED,
DRV_SST25VF016B_CLIENT_STATUS_ERROR = DRV_CLIENT_STATUS_ERROR
} DRV_SST25VF016B_CLIENT_STATUS;
Members
Members Description
DRV_SST25VF016B_CLIENT_STATUS_READY
= DRV_CLIENT_STATUS_READY+0
Up and running, ready to start new operations
DRV_SST25VF016B_CLIENT_STATUS_BUSY =
DRV_CLIENT_STATUS_BUSY
Operation in progress, unable to start a new one
DRV_SST25VF016B_CLIENT_STATUS_CLOSED
= DRV_CLIENT_STATUS_CLOSED
Client is closed
DRV_SST25VF016B_CLIENT_STATUS_ERROR
= DRV_CLIENT_STATUS_ERROR
Client Error
Description
SPI Flash Client Status
Defines the various client status codes.
Remarks
None.
DRV_SST25VF016B_EVENT_HANDLER Type
Pointer to a SST25VF016B SPI Flash Driver Event handler function.
Implementation: Dynamic
File
drv_sst25vf016b.h
C
typedef void (* DRV_SST25VF016B_EVENT_HANDLER)(DRV_SST25VF016B_BLOCK_EVENT event,
DRV_SST25VF016B_BLOCK_COMMAND_HANDLE commandHandle, uintptr_t context);
Returns
None.
Description
SST25VF016B SPI Flash Driver Event Handler Function Pointer
This data type defines the required function signature for the SST25VF016B SPI Flash driver event handling callback function. A client must
register a pointer to an event handling function whose function signature (parameter and return value types) match the types specified by this
function pointer in order to receive event calls back from the driver.
The parameters and return values and return value are described here and a partial example implementation is provided.
Remarks
If the event is DRV_SST25VF016B_EVENT_BLOCK_COMMAND_COMPLETE, it means that the data was transferred successfully.
If the event is DRV_SST25VF016B_EVENT_BLOCK_COMMAND_ERROR, it means that the data was not transferred successfully.
The context parameter contains the a handle to the client context, provided at the time the event handling function was registered using the
DRV_SST25VF016B_BlockEventHandlerSet function. This context handle value is passed back to the client as the "context" parameter. It can be
any value necessary to identify the client context or instance (such as a pointer to the client's data) instance of the client that made the
read/write/erase request.
The event handler function executes in the driver peripheral's interrupt context when the driver is configured for interrupt mode operation. It is
recommended of the application to not perform process intensive or blocking operations with in this function.
The Read, Write, and Erase functions can be called in the event handler to add a buffer to the driver queue. These functions can only be called to
add buffers to the driver whose event handler is running.
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 799
Example
void APP_MyBufferEventHandler
(
DRV_SST25VF016B_BLOCK_EVENT event,
DRV_SST25VF016B_BLOCK_COMMAND_HANDLE commandHandle,
uintptr_t context
)
{
MY_APP_DATA_STRUCT pAppData = (MY_APP_DATA_STRUCT) context;
switch(event)
{
case DRV_SST25VF016B_EVENT_BLOCK_COMMAND_COMPLETE:
// Handle the completed buffer.
break;
case DRV_SST25VF016B_EVENT_BLOCK_COMMAND_ERROR:
default:
// Handle error.
break;
}
}
Parameters
Parameters Description
event Identifies the type of event
commandHandle Handle returned from the Read/Write/Erase requests
context Value identifying the context of the application that registered the event handling function
DRV_SST25VF016B_INIT Structure
Contains all the data necessary to initialize the SPI Flash device.
Implementation: Dynamic
File
drv_sst25vf016b.h
C
typedef struct {
SYS_MODULE_INIT moduleInit;
SYS_MODULE_INDEX spiDriverModuleIndex;
PORTS_CHANNEL holdPortChannel;
PORTS_BIT_POS holdBitPosition;
PORTS_CHANNEL writeProtectPortChannel;
PORTS_BIT_POS writeProtectBitPosition;
PORTS_CHANNEL chipSelectPortChannel;
PORTS_BIT_POS chipSelectBitPosition;
uint32_t queueSize;
} DRV_SST25VF016B_INIT;
Members
Members Description
SYS_MODULE_INIT moduleInit; System module initialization
SYS_MODULE_INDEX spiDriverModuleIndex; Identifies the SPI driver to be used
PORTS_CHANNEL holdPortChannel; HOLD pin port channel
PORTS_BIT_POS holdBitPosition; HOLD pin port position
PORTS_CHANNEL writeProtectPortChannel; Write protect pin port channel
PORTS_BIT_POS writeProtectBitPosition; Write Protect Bit pin position
PORTS_CHANNEL chipSelectPortChannel; Chip select pin port channel
PORTS_BIT_POS chipSelectBitPosition; Chip Select Bit pin position
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 800
uint32_t queueSize; This is the buffer queue size. This is the maximum number of requests that this instance of
the driver will queue. For a static build of the driver, this is overridden by the
DRV_SST25VF016B_QUEUE_SIZE macro in system_config.h
Description
SST SPI Flash Driver Initialization Data
This structure contains all of the data necessary to initialize the SPI Flash device.
Remarks
A pointer to a structure of this format containing the desired initialization data must be passed into the DRV_SST25VF016B_Initialize function.
DRV_SST25VF016B_BLOCK_COMMAND_HANDLE_INVALID Macro
This value defines the SPI Flash Driver Block Command Invalid handle.
File
drv_sst25vf016b.h
C
#define DRV_SST25VF016B_BLOCK_COMMAND_HANDLE_INVALID
Description
SPI Flash Driver Block Event Invalid Handle
This value defines the SPI Flash Driver Block Command Invalid handle. It is returned by read/write/erase routines when the request could not be
taken.
Remarks
None.
DRV_SST25VF016B_INDEX_0 Macro
SPI Flash driver index definitions
File
drv_sst25vf016b.h
C
#define DRV_SST25VF016B_INDEX_0 0
Description
Driver SPI Flash Module Index reference
These constants provide SST25VF016B SPI Flash driver index definitions.
Remarks
These constants should be used in place of hard-coded numeric literals.
These values should be passed into the DRV_SST25VF016B_Initialize and DRV_SST25VF016B_Open routines to identify the driver instance in
use.
DRV_SST25VF016B_INDEX_1 Macro
File
drv_sst25vf016b.h
C
#define DRV_SST25VF016B_INDEX_1 1
Description
This is macro DRV_SST25VF016B_INDEX_1.
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 801
SST25VF020B API
a) System Functions
Name Description
DRV_SST25VF020B_Initialize Initializes the SST25VF020B SPI Flash Driver instance for the specified driver index.
Implementation: Dynamic
DRV_SST25VF020B_Deinitialize Deinitializes the specified instance of the SPI Flash driver module.
Implementation: Dynamic
DRV_SST25VF020B_Status Gets the current status of the SPI Flash Driver module.
Implementation: Dynamic
DRV_SST25VF020B_Tasks Maintains the driver's read, erase, and write state machine and implements its ISR.
Implementation: Dynamic
b) Core Client Functions
Name Description
DRV_SST25VF020B_ClientStatus Gets current client-specific status of the SPI Flash driver.
Implementation: Dynamic
DRV_SST25VF020B_CommandStatus Gets the current status of the command.
DRV_SST25VF020B_Close Closes an opened-instance of the SPI Flash driver.
Implementation: Dynamic
DRV_SST25VF020B_Open Opens the specified SPI Flash driver instance and returns a handle to it.
Implementation: Dynamic
c) Block Operation Functions
Name Description
DRV_SST25VF020B_BlockErase Erase the specified number of blocks in Flash memory.
Implementation: Dynamic
DRV_SST25VF020B_BlockEventHandlerSet Allows a client to identify an event handling function for the driver to call back when
queued operation has completed.
Implementation: Dynamic
DRV_SST25VF020B_BlockRead Reads blocks of data starting from the specified address in Flash memory.
Implementation: Dynamic
DRV_SST25VF020B_BlockWrite Write blocks of data starting from a specified address in Flash memory.
Implementation: Dynamic
DRV_SST25VF020B_BlockEraseWrite Erase and Write blocks of data starting from a specified address in SST flash
memory.
d) Media Interface Functions
Name Description
DRV_SST25VF020B_GeometryGet Returns the geometry of the device.
Implementation: Dynamic
DRV_SST25VF020B_MediaIsAttached Returns the status of the media.
Implementation: Dynamic
e) Data Types and Constants
Name Description
DRV_SST25VF020B_BLOCK_COMMAND_HANDLE Handle identifying block commands of the driver.
DRV_SST25VF020B_BLOCK_EVENT Identifies the possible events that can result from a request.
DRV_SST25VF020B_CLIENT_STATUS Defines the client status.
DRV_SST25VF020B_EVENT_HANDLER Pointer to a SST25VF020B SPI Flash Driver Event handler
function.
DRV_SST25VF020B_INIT Contains all the data necessary to initialize the SPI Flash device.
DRV_SST25VF020B_COMMAND_STATUS Specifies the status of the command for the read, write and erase
operations.
DRV_SST25VF020B_BLOCK_COMMAND_HANDLE_INVALID This value defines the SPI Flash Driver Block Command Invalid
handle.
DRV_SST25VF020B_INDEX_0 SPI Flash driver index definitions.
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 802
DRV_SST25VF020B_INDEX_1 This is macro DRV_SST25VF020B_INDEX_1.
Description
This section contains the SST25V020B Flash device API.
a) System Functions
DRV_SST25VF020B_Initialize Function
Initializes the SST25VF020B SPI Flash Driver instance for the specified driver index.
Implementation: Dynamic
File
drv_sst25vf020b.h
C
SYS_MODULE_OBJ DRV_SST25VF020B_Initialize(const SYS_MODULE_INDEX index, const SYS_MODULE_INIT * const init);
Returns
If successful, returns a valid handle to a driver instance object. Otherwise, it returns SYS_MODULE_OBJ_INVALID.
Description
This function initializes the SPI Flash driver instance for the specified driver index, making it ready for clients to open and use it.
Remarks
This function must be called before any other SPI Flash function is called.
This function should only be called once during system initialization unless DRV_SST25VF020B_Deinitialize is called to deinitialize the driver
instance.
Build configuration options may be used to statically override options in the "init" structure and will take precedence over initialization data passed
using this function.
Preconditions
None.
Example
// This code snippet shows an example of initializing the SST25VF020B SPI
// Flash Driver. SPI driver index 0 is used for the purpose. Pin numbers 1, 2
// and 3 of port channel B are configured for hold pin, write protection pin
// and chip select pin respectively. Maximum buffer queue size is set 5.
DRV_SST25VF020B_INIT SST25VF020BInitData;
SYS_MODULE_OBJ objectHandle;
SST25VF020BInitData.moduleInit.value = SYS_MODULE_POWER_RUN_FULL;
SST25VF020BInitData.spiDriverModuleIndex = DRV_SPI_INDEX_0;
SST25VF020BInitData.holdPortChannel = PORT_CHANNEL_B;
SST25VF020BInitData.holdBitPosition = PORTS_BIT_POS_1;
SST25VF020BInitData.writeProtectPortChannel = PORT_CHANNEL_B;
SST25VF020BInitData.writeProtectBitPosition = PORTS_BIT_POS_2;
SST25VF020BInitData.chipSelectPortChannel = PORT_CHANNEL_F;
SST25VF020BInitData.chipSelectBitPosition = PORTS_BIT_POS_2;
SST25VF020BInitData.queueSize = 5;
objectHandle = DRV_SST25VF020B_Initialize(DRV_SST25VF020B_INDEX_0,
(SYS_MODULE_INIT*)SST25VF020BInitData);
if (SYS_MODULE_OBJ_INVALID == objectHandle)
{
// Handle error
}
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 803
Parameters
Parameters Description
index Identifier for the instance to be initialized
init Pointer to a data structure containing data necessary to initialize the driver.
Function
SYS_MODULE_OBJ DRV_SST25VF020B_Initialize
(
const SYS_MODULE_INDEX index,
const SYS_MODULE_INIT * const init
);
DRV_SST25VF020B_Deinitialize Function
Deinitializes the specified instance of the SPI Flash driver module.
Implementation: Dynamic
File
drv_sst25vf020b.h
C
void DRV_SST25VF020B_Deinitialize(SYS_MODULE_OBJ object);
Returns
None.
Description
Deinitializes the specified instance of the SPI Flash Driver module, disabling its operation (and any hardware) and invalidates all of the internal
data.
Remarks
Once the Initialize operation has been called, the Deinitialize operation must be called before the Initialize operation can be called again. This
function will NEVER block waiting for hardware.
Preconditions
Function DRV_SST25VF020B_Initialize should have been called before calling this function.
Example
// This code snippet shows an example of deinitializing the driver.
SYS_MODULE_OBJ object; // Returned from DRV_SST25VF020B_Initialize
SYS_STATUS status;
DRV_SST25VF020B_Deinitialize(object);
status = DRV_SST25VF020B_Status(object);
if (SYS_MODULE_DEINITIALIZED != status)
{
// Check again later if you need to know
// when the driver is deinitialized.
}
Parameters
Parameters Description
object Driver object handle, returned from the DRV_SST25VF020B_Initialize
Function
void DRV_SST25VF020B_Deinitialize( SYS_MODULE_OBJ object )
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 804
DRV_SST25VF020B_Status Function
Gets the current status of the SPI Flash Driver module.
Implementation: Dynamic
File
drv_sst25vf020b.h
C
SYS_STATUS DRV_SST25VF020B_Status(SYS_MODULE_OBJ object);
Returns
SYS_STATUS_READY - Indicates that the driver is ready and accept requests for new operations
SYS_STATUS_UNINITIALIZED - Indicates that the driver is not initialized
Description
This function provides the current status of the SPI Flash Driver module.
Remarks
A driver can only be opened when its status is SYS_STATUS_READY.
Preconditions
Function DRV_SST25VF020B_Initialize should have been called before calling this function.
Example
SYS_MODULE_OBJ object; // Returned from DRV_SST25VF020B_Initialize
SYS_STATUS SST25VF020BStatus;
SST25VF020BStatus = DRV_SST25VF020B_Status(object);
else if (SYS_STATUS_ERROR >= SST25VF020BStatus)
{
// Handle error
}
Parameters
Parameters Description
object Driver object handle, returned from the DRV_SST25VF020B_Initialize
Function
SYS_STATUS DRV_SST25VF020B_Status( SYS_MODULE_OBJ object )
DRV_SST25VF020B_Tasks Function
Maintains the driver's read, erase, and write state machine and implements its ISR.
Implementation: Dynamic
File
drv_sst25vf020b.h
C
void DRV_SST25VF020B_Tasks(SYS_MODULE_OBJ object);
Returns
None.
Description
This function is used to maintain the driver's internal state machine and should be called from the system's Tasks function.
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 805
Remarks
This function is normally not called directly by an application. It is called by the system's Tasks function (SYS_Tasks).
Preconditions
The DRV_SST25VF020B_Initialize function must have been called for the specified SPI Flash driver instance.
Example
SYS_MODULE_OBJ object; // Returned from DRV_SST25VF020B_Initialize
while (true)
{
DRV_SST25VF020B_Tasks (object);
// Do other tasks
}
Parameters
Parameters Description
object Object handle for the specified driver instance (returned from DRV_SST25VF020B_Initialize)
Function
void DRV_SST25VF020B_Tasks ( SYS_MODULE_OBJ object );
b) Core Client Functions
DRV_SST25VF020B_ClientStatus Function
Gets current client-specific status of the SPI Flash driver.
Implementation: Dynamic
File
drv_sst25vf020b.h
C
DRV_SST25VF020B_CLIENT_STATUS DRV_SST25VF020B_ClientStatus(const DRV_HANDLE handle);
Returns
A DRV_SST25VF020B_CLIENT_STATUS value describing the current status of the driver.
Description
This function gets the client-specific status of the SPI Flash driver associated with the given handle.
Remarks
This function will not block for hardware access and will immediately return the current status.
Preconditions
The DRV_SST25VF020B_Initialize function must have been called.
DRV_SST25VF020B_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE handle; // Returned from DRV_SST25VF020B_Open
DRV_SST25VF020B_CLIENT_STATUS clientStatus;
clientStatus = DRV_SST25VF020B_ClientStatus(handle);
if(DRV_SST25VF020B_CLIENT_STATUS_READY == clientStatus)
{
// do the tasks
}
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 806
Parameters
Parameters Description
handle A valid open instance handle, returned from the driver's open
Function
DRV_SST25VF020B_CLIENT_STATUS DRV_SST25VF020B_ClientStatus(DRV_HANDLE handle);
DRV_SST25VF020B_CommandStatus Function
Gets the current status of the command.
File
drv_sst25vf020b.h
C
DRV_SST25VF020B_COMMAND_STATUS DRV_SST25VF020B_CommandStatus(const DRV_HANDLE handle, const
DRV_SST25VF020B_BLOCK_COMMAND_HANDLE commandHandle);
Returns
A DRV_SST25VF020B_COMMAND_STATUS value describing the current status of the buffer. Returns
DRV_SST25VF020B_BLOCK_COMMAND_HANDLE_INVALID if the client handle or the command handle is not valid.
Description
This routine gets the current status of the buffer. The application must use this routine where the status of a scheduled buffer needs to polled on.
The function may return DRV_SST25VF020B_BLOCK_COMMAND_HANDLE_INVALID in a case where the buffer handle has expired. A buffer
handle expires when the internal buffer object is re-assigned to another erase, read or write request. It is recommended that this function be called
regularly in order to track the buffer status correctly.
The application can alternatively register an event handler to receive write, read or erase operation completion events.
Remarks
This function will not block for hardware access and will immediately return the current status.
Preconditions
Block command request must have been made using Erase, Read or Write APIs to get a valid command handle.
Example
DRV_HANDLE sstOpenHandle; // Returned from DRV_SST25VF020B_Open
DRV_SST25VF020B_BLOCK_COMMAND_HANDLE commandHandle;
DRV_SST25VF020B_BlockErase
(
sstOpenHandle,
&commandHandle,
0,
1
);
if(DRV_SST25VF020B_CommandStatus(sstOpenHandle, commandHandle) == DRV_SST25VF020B_COMMAND_COMPLETED );
{
// do something
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
commandHandle A valid command handle, returned from Read/Write/Erase APIs.
Function
DRV_SST25VF020B_COMMAND_STATUS DRV_SST25VF020B_CommandStatus
(
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 807
const DRV_HANDLE handle,
const DRV_SST25VF020B_BLOCK_COMMAND_HANDLE commandHandle
);
DRV_SST25VF020B_Close Function
Closes an opened-instance of the SPI Flash driver.
Implementation: Dynamic
File
drv_sst25vf020b.h
C
void DRV_SST25VF020B_Close(const DRV_HANDLE handle);
Returns
None.
Description
This function closes an opened-instance of the SPI Flash driver, invalidating the handle.
Remarks
After calling this function, the handle passed in "handle" must not be used with any of the remaining driver routines. A new handle must be
obtained by calling DRV_SST25VF020B_Open before the caller may use the driver again.
Usually, there is no need for the driver client to verify that the Close operation has completed.
Preconditions
The DRV_SST25VF020B_Initialize function must have been called for the specified SPI Flash driver instance.
DRV_SST25VF020B_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE handle; // Returned from DRV_SST25VF020B_Open
DRV_SST25VF020B_Close(handle);
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
Function
void DRV_SST25VF020B_Close( DRV_Handle handle );
DRV_SST25VF020B_Open Function
Opens the specified SPI Flash driver instance and returns a handle to it.
Implementation: Dynamic
File
drv_sst25vf020b.h
C
DRV_HANDLE DRV_SST25VF020B_Open(const SYS_MODULE_INDEX drvIndex, const DRV_IO_INTENT ioIntent);
Returns
If successful, the function returns a valid open-instance handle (a number identifying both the caller and the module instance).
If an error occurs, the return value is DRV_HANDLE_INVALID. Errors can occur under the following circumstances:
• if the number of client objects allocated via DRV_SST25VF020B_CLIENTS_NUMBER is insufficient
• if the client is trying to open the driver but driver has been opened exclusively by another client
• if the driver hardware instance being opened is not initialized or is invalid
• if the client is trying to open the driver exclusively, but has already been opened in a non exclusive mode by another client.
• if the driver status is not ready.
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 808
The driver status becomes ready inside "DRV_SST25VF020B_Tasks" function. To make the SST Driver status ready and hence successfully
"Open" the driver, "Task" routine need to be called periodically.
Description
This function opens the specified SPI Flash driver instance and provides a handle that must be provided to all other client-level operations to
identify the caller and the instance of the driver.
Remarks
The driver will always work in Non-Blocking mode even if IO-intent is selected as blocking.
The handle returned is valid until the DRV_SST25VF020B_Close function is called.
This function will NEVER block waiting for hardware.
Preconditions
Function DRV_SST25VF020B_Initialize must have been called before calling this function.
Example
DRV_HANDLE handle;
handle = DRV_SST25VF020B_Open(DRV_SST25VF020B_INDEX_0,
DRV_IO_INTENT_EXCLUSIVE);
if (DRV_HANDLE_INVALID == handle)
{
// Unable to open the driver
}
Parameters
Parameters Description
drvIndex Identifier for the object instance to be opened
ioIntent Zero or more of the values from the enumeration DRV_IO_INTENT "ORed" together to
indicate the intended use of the driver
Function
DRV_HANDLE DRV_SST25VF020B_Open
(
const SYS_MODULE_INDEX drvIndex,
const DRV_IO_INTENT ioIntent
);
c) Block Operation Functions
DRV_SST25VF020B_BlockErase Function
Erase the specified number of blocks in Flash memory.
Implementation: Dynamic
File
drv_sst25vf020b.h
C
void DRV_SST25VF020B_BlockErase(const DRV_HANDLE handle, DRV_SST25VF020B_BLOCK_COMMAND_HANDLE *
commandHandle, uint32_t blockStart, uint32_t nBlock);
Returns
The buffer handle is returned in the commandHandle argument. It Will be DRV_BUFFER_HANDLE_INVALID if the request was not queued.
Description
This function schedules a non-blocking erase operation in flash memory. The function returns with a valid erase handle in the commandHandle
argument if the erase request was scheduled successfully. The function adds the request to the hardware instance queue and returns
immediately. The function returns DRV_SST25VF020B_BLOCK_COMMAND_HANDLE_INVALID in the commandHandle argument under the
following circumstances:
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 809
• if the client opened the driver for read only
• if nBlock is 0
• if the queue size is full or queue depth is insufficient
• if the driver handle is invalid
If the requesting client registered an event callback with the driver, the driver will issue a DRV_SST25VF020B_EVENT_ERASE_COMPLETE
event if the erase operation was successful or DRV_SST25VF020B_EVENT_ERASE_ERROR event if the erase operation was not successful.
Remarks
Write Protection will be disabled for the complete flash memory region in the beginning by default.
Preconditions
The DRV_SST25VF020B_Initialize function must have been called for the specified SPI Flash driver instance.
DRV_SST25VF020B_Open must have been called to obtain a valid opened device handle.
DRV_IO_INTENT_WRITE or DRV_IO_INTENT_READWRITE must have been specified in the DRV_SST25VF020B_Open call.
Example
// Destination address should be block aligned.
uint32_t blockStart;
uint32_t nBlock;
DRV_SST25VF020B_BLOCK_COMMAND_HANDLE commandHandle;
MY_APP_OBJ myAppObj;
// mySST25VF020BHandle is the handle returned
// by the DRV_SST25VF020B_Open function.
// Client registers an event handler with driver
DRV_SST25VF020B_BlockEventHandlerSet(mySST25VF020BHandle,
APP_SST25VF020BEventHandler, (uintptr_t)&myAppObj);
DRV_SST25VF020B_BlockErase( mySST25VF020BHandle, commandHandle,
blockStart, nBlock );
if(DRV_SST25VF020B_BLOCK_COMMAND_HANDLE_INVALID == commandHandle)
{
// Error handling here
}
// Event is received when
// the buffer queue is processed.
void APP_SST25VF020BEventHandler(DRV_SST25VF020B_BLOCK_EVENT event,
DRV_SST25VF020B_BLOCK_COMMAND_HANDLE commandHandle, uintptr_t contextHandle)
{
// contextHandle points to myAppObj.
switch(event)
{
case DRV_SST25VF020B_EVENT_ERASE_COMPLETE:
// This means the data was transferred.
break;
case DRV_SST25VF020B_EVENT_ERASE_ERROR:
// Error handling here.
break;
default:
break;
}
}
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 810
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
commandHandle Pointer to an argument that will contain the return buffer handle
blockStart Start block address in SST25VF020B memory from where the erase should begin. LSBs
(A0-A11) of block start address will be ignored to align it with Erase block size boundary.
nBlock Total number of blocks to be erased. Each Erase block is of size 4 KByte.
Function
void DRV_SST25VF020B_BlockErase
(
const DRV_HANDLE handle,
DRV_SST25VF020B_BLOCK_COMMAND_HANDLE * commandHandle,
uint32_t blockStart,
uint32_t nBlock
);
DRV_SST25VF020B_BlockEventHandlerSet Function
Allows a client to identify an event handling function for the driver to call back when queued operation has completed.
Implementation: Dynamic
File
drv_sst25vf020b.h
C
void DRV_SST25VF020B_BlockEventHandlerSet(const DRV_HANDLE handle, const DRV_SST25VF020B_EVENT_HANDLER
eventHandler, const uintptr_t context);
Returns
None.
Description
This function allows a client to identify an event handling function for the driver to call back when queued operation has completed. When a client
calls any read, write or erase function, it is provided with a handle identifying the buffer that was added to the driver's buffer queue. The driver will
pass this handle back to the client by calling "eventHandler" function when the queued operation has completed.
The event handler should be set before the client performs any read/write/erase operations that could generate events. The event handler once
set, persists until the client closes the driver or sets another event handler (which could be a "NULL" pointer to indicate no callback).
Remarks
If the client does not want to be notified when the queued operation has completed, it does not need to register a callback.
Preconditions
The DRV_SST25VF020B_Initialize function must have been called for the specified SPI FLash driver instance.
DRV_SST25VF020B_Open must have been called to obtain a valid opened device handle.
Example
// myAppObj is an application specific state data object.
MY_APP_OBJ myAppObj;
uint8_t myBuffer[MY_BUFFER_SIZE];
uint32_t blockStart, nBlock;
DRV_SST25VF020B_BLOCK_COMMAND_HANDLE commandHandle;
// mySST25VF020BHandle is the handle returned
// by the DRV_SST25VF020B_Open function.
// Client registers an event handler with driver. This is done once.
DRV_SST25VF020B_BlockEventHandlerSet( mySST25VF020BHandle,
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 811
APP_SST25VF020BEventHandler, (uintptr_t)&myAppObj );
DRV_SST25VF020B_BlockRead( mySST25VF020BHandle, commandHandle,
&myBuffer, blockStart, nBlock );
if(DRV_SST25VF020B_BLOCK_COMMAND_HANDLE_INVALID == commandHandle)
{
// Error handling here
}
// Event Processing Technique. Event is received when operation is done.
void APP_SST25VF020BEventHandler(DRV_SST25VF020B_BLOCK_EVENT event,
DRV_SST25VF020B_BLOCK_COMMAND_HANDLE handle, uintptr_t context)
{
// The context handle was set to an application specific
// object. It is now retrievable easily in the event handler.
MY_APP_OBJ myAppObj = (MY_APP_OBJ *) context;
switch(event)
{
case DRV_SST25VF020B_EVENT_BLOCK_COMMAND_COMPLETE:
// This means the data was transferred.
break;
case DRV_SST25VF020B_EVENT_BLOCK_COMMAND_ERROR:
// Error handling here.
break;
default:
break;
}
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
eventHandler Pointer to the event handler function implemented by the user
context The value of parameter will be passed back to the client unchanged, when the eventHandler
function is called. It can be used to identify any client specific data object that identifies the
instance of the client module (for example, it may be a pointer to the client module's state
structure).
Function
void DRV_SST25VF020B_BlockEventHandlerSet
(
const DRV_HANDLE handle,
const DRV_SST25VF020B_EVENT_HANDLER eventHandler,
const uintptr_t context
);
DRV_SST25VF020B_BlockRead Function
Reads blocks of data starting from the specified address in Flash memory.
Implementation: Dynamic
File
drv_sst25vf020b.h
C
void DRV_SST25VF020B_BlockRead(const DRV_HANDLE handle, DRV_SST25VF020B_BLOCK_COMMAND_HANDLE *
commandHandle, uint8_t * targetBuffer, uint32_t blockStart, uint32_t nBlock);
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 812
Returns
The buffer handle is returned in the commandHandle argument. It will be DRV_BUFFER_HANDLE_INVALID if the request was not successful.
Description
This function schedules a non-blocking read operation for reading blocks of data from flash memory. The function returns with a valid handle in the
commandHandle argument if the read request was scheduled successfully. The function adds the request to the hardware instance queue and
returns immediately. While the request is in the queue, the application buffer is owned by the driver and should not be modified. The function
returns DRV_SST25VF020B_BLOCK_COMMAND_HANDLE_INVALID in the commandHandle argument under the following circumstances:
• if a buffer could not be allocated to the request
• if the target buffer pointer is NULL
• if the client opened the driver for write only
• if the buffer size is 0
• if the read queue size is full or queue depth is insufficient
• if the driver handle is invalid
If the requesting client registered an event callback with the driver, the driver will issue a
DRV_SST25VF020B_EVENT_BLOCK_COMMAND_COMPLETE event if the buffer was processed successfully of
DRV_SST25VF020B_EVENT_BLOCK_COMMAND_ERROR event if the buffer was not processed successfully.
Remarks
The maximum read speed is 33 MHz.
Preconditions
The DRV_SST25VF020B_Initialize function must have been called for the specified SPI Flash driver instance.
DRV_SST25VF020B_Open must have been called to obtain a valid opened device handle.
DRV_IO_INTENT_READ or DRV_IO_INTENT_READWRITE must have been specified in the DRV_SST25VF020B_Open call.
Example
uint8_t myBuffer[MY_BUFFER_SIZE];
// address should be block aligned.
uint32_t blockStart = SST25VF020B_BASE_ADDRESS_TO_READ_FROM;
uint32_t nBlock = 2;
DRV_SST25VF020B_BLOCK_COMMAND_HANDLE commandHandle;
MY_APP_OBJ myAppObj;
// mySST25VF020BHandle is the handle returned
// by the DRV_SST25VF020B_Open function.
// Client registers an event handler with driver
DRV_SST25VF020B_BlockEventHandlerSet(mySST25VF020BHandle,
APP_SST25VF020BEventHandler, (uintptr_t)&myAppObj);
DRV_SST25VF020B_BlockRead( mySST25VF020BHandle, commandHandle,
&myBuffer, blockStart, nBlock );
if(DRV_SST25VF020B_BLOCK_COMMAND_HANDLE_INVALID == commandHandle)
{
// Error handling here
}
// Event is received when the buffer is processed.
void APP_SST25VF020BEventHandler(DRV_SST25VF020B_BLOCK_EVENT event,
DRV_SST25VF020B_BLOCK_COMMAND_HANDLE commandHandle, uintptr_t contextHandle)
{
// contextHandle points to myAppObj.
switch(event)
{
case DRV_SST25VF020B_EVENT_BLOCK_COMMAND_COMPLETE:
// This means the data was transferred.
break;
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 813
case DRV_SST25VF020B_EVENT_BLOCK_COMMAND_ERROR:
// Error handling here.
break;
default:
break;
}
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
commandHandle Pointer to an argument that will contain the return buffer handle
*targetBuffer Buffer into which the data read from the SPI Flash instance will be placed
blockStart Start block address in SST25VF020B memory from where the read should begin. It can be
any address of the flash.
nBlock Total number of blocks to be read. Each Read block is of 1 byte.
Function
void DRV_SST25VF020B_BlockRead
(
const DRV_HANDLE handle,
DRV_SST25VF020B_BLOCK_COMMAND_HANDLE * commandHandle,
uint8_t *targetBuffer,
uint32_t blockStart,
uint32_t nBlock
);
DRV_SST25VF020B_BlockWrite Function
Write blocks of data starting from a specified address in Flash memory.
Implementation: Dynamic
File
drv_sst25vf020b.h
C
void DRV_SST25VF020B_BlockWrite(DRV_HANDLE handle, DRV_SST25VF020B_BLOCK_COMMAND_HANDLE * commandHandle,
uint8_t * sourceBuffer, uint32_t blockStart, uint32_t nBlock);
Returns
The buffer handle is returned in the commandHandle argument. It will be DRV_BUFFER_HANDLE_INVALID if the request was not successful.
Description
This function schedules a non-blocking write operation for writing blocks of data into flash memory. The function returns with a valid buffer handle
in the commandHandle argument if the write request was scheduled successfully. The function adds the request to the hardware instance queue
and returns immediately. While the request is in the queue, the application buffer is owned by the driver and should not be modified. The function
returns DRV_SST25VF020B_BLOCK_COMMAND_HANDLE_INVALID in the commandHandle argument under the following circumstances:
• if a buffer could not be allocated to the request
• if the input buffer pointer is NULL
• if the client opened the driver for read only
• if the buffer size is 0
• if the write queue size is full or queue depth is insufficient
• if the driver handle is invalid
If the requesting client registered an event callback with the driver, the driver will issue a
DRV_SST25VF020B_EVENT_BLOCK_COMMAND_COMPLETE event if the buffer was processed successfully or
DRV_SST25VF020B_EVENT_BLOCK_COMMAND_ERROR event if the buffer was not processed successfully.
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 814
Remarks
In the case of multi bytes write operation, byte by byte writing will happen instead of Address auto Increment writing.
Write Protection will be disabled for the complete flash memory region in the beginning by default.
Preconditions
The DRV_SST25VF020B_Initialize function must have been called for the specified SPI Flash driver instance.
DRV_SST25VF020B_Open must have been called to obtain a valid opened device handle.
DRV_IO_INTENT_WRITE or DRV_IO_INTENT_READWRITE must have been specified in the DRV_SST25VF020B_Open call.
The flash address location which has to be written, must be erased before using the API DRV_SST25VF020B_BlockErase().
Example
uint8_t myBuffer[MY_BUFFER_SIZE];
// address should be block aligned.
uint32_t blockStart = SST25VF020B_BASE_ADDRESS_TO_WRITE_TO;
uint32_t nBlock = 2;
DRV_SST25VF020B_BLOCK_COMMAND_HANDLE commandHandle;
MY_APP_OBJ myAppObj;
// mySST25VF020BHandle is the handle returned
// by the DRV_SST25VF020B_Open function.
// Client registers an event handler with driver
DRV_SST25VF020B_BlockEventHandlerSet(mySST25VF020BHandle,
APP_SST25VF020BEventHandler, (uintptr_t)&myAppObj);
DRV_SST25VF020B_BlockWrite( mySST25VF020BHandle, commandHandle,
&myBuffer, blockStart, nBlock );
if(DRV_SST25VF020B_BLOCK_COMMAND_HANDLE_INVALID == commandHandle)
{
// Error handling here
}
// Event is received when
// the buffer is processed.
void APP_SST25VF020BEventHandler(DRV_SST25VF020B_BLOCK_EVENT event,
DRV_SST25VF020B_BLOCK_COMMAND_HANDLE commandHandle, uintptr_t contextHandle)
{
// contextHandle points to myAppObj.
switch(event)
{
case DRV_SST25VF020B_EVENT_BLOCK_COMMAND_COMPLETE:
// This means the data was transferred.
break;
case DRV_SST25VF020B_EVENT_BLOCK_COMMAND_ERROR:
// Error handling here.
break;
default:
break;
}
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
commandHandle -Pointer to an argument that will contain the return buffer handle
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 815
sourceBuffer The source buffer containing data to be programmed into SPI Flash
blockStart Start block address of SST25VF020B Flash where the write should begin. It can be any
address of the flash.
nBlock Total number of blocks to be written. Each write block is of 1 byte.
Function
void DRV_SST25VF020B_BlockWrite
(
DRV_HANDLE handle,
DRV_SST25VF020B_BLOCK_COMMAND_HANDLE * commandHandle,
uint8_t *sourceBuffer,
uint32_t blockStart,
uint32_t nBlock
);
DRV_SST25VF020B_BlockEraseWrite Function
Erase and Write blocks of data starting from a specified address in SST flash memory.
File
drv_sst25vf020b.h
C
void DRV_SST25VF020B_BlockEraseWrite(DRV_HANDLE hClient, DRV_SST25VF020B_BLOCK_COMMAND_HANDLE *
commandHandle, uint8_t * sourceBuffer, uint32_t blockStart, uint32_t nBlock);
Description
This function combines the step of erasing blocks of SST Flash and then writing the data. The application can use this function if it wants to avoid
having to explicitly delete a block in order to update the bytes contained in the block.
This function schedules a non-blocking operation to erase and write blocks of data into SST flash. The function returns with a valid buffer handle in
the commandHandle argument if the write request was scheduled successfully. The function adds the request to the hardware instance queue and
returns immediately. While the request is in the queue, the application buffer is owned by the driver and should not be modified. The function
returns DRV_SST25VF020B_BLOCK_COMMAND_HANDLE_INVALID in the commandHandle argument under the following circumstances:
• if a buffer could not be allocated to the request
• if the input buffer pointer is NULL
• if the client opened the driver for read only
• if the buffer size is 0
• if the queue size is full or queue depth is insufficient
• if the driver handle is invalid
If the requesting client registered an event callback with the driver, the driver will issue a
DRV_SST25VF020B_EVENT_BLOCK_COMMAND_COMPLETE event if the buffer was processed successfully or
DRV_SST25VF020B_EVENT_ERASE_ERROR event if the buffer was not processed successfully.
Remarks
Refer to drv_sst25vf020b.h for usage information.
Function
void DRV_SST25VF020B_BlockEraseWrite
(
const DRV_HANDLE handle,
DRV_SST25VF020B_BLOCK_COMMAND_HANDLE * commandHandle,
void * sourceBuffer,
uint32_t writeBlockStart,
uint32_t nWriteBlock
)
d) Media Interface Functions
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 816
DRV_SST25VF020B_GeometryGet Function
Returns the geometry of the device.
Implementation: Dynamic
File
drv_sst25vf020b.h
C
SYS_FS_MEDIA_GEOMETRY * DRV_SST25VF020B_GeometryGet(DRV_HANDLE handle);
Returns
SYS_FS_MEDIA_GEOMETRY - Structure which holds the media geometry information.
Description
This API gives the following geometrical details of the SST25VF020B Flash:
• Media Property
• Number of Read/Write/Erase regions in the flash device
• Number of Blocks and their size in each region of the device
Remarks
This function is typically used by File System Media Manager.
Preconditions
None.
Example
SYS_FS_MEDIA_GEOMETRY * sstFlashGeometry;
uint32_t readBlockSize, writeBlockSize, eraseBlockSize;
uint32_t nReadBlocks, nReadRegions, totalFlashSize;
sstFlashGeometry = DRV_SST25VF020B_GeometryGet(sstOpenHandle1);
// read block size should be 1 byte
readBlockSize = sstFlashGeometry->geometryTable->blockSize;
nReadBlocks = sstFlashGeometry->geometryTable->numBlocks;
nReadRegions = sstFlashGeometry->numReadRegions;
// write block size should be 1 byte
writeBlockSize = (sstFlashGeometry->geometryTable +1)->blockSize;
// erase block size should be 4k byte
eraseBlockSize = (sstFlashGeometry->geometryTable +2)->blockSize;
// total flash size should be 256k byte
totalFlashSize = readBlockSize * nReadBlocks * nReadRegions;
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
Function
SYS_FS_MEDIA_GEOMETRY DRV_SST25VF020B_GeometryGet( DRV_HANDLE handle );
DRV_SST25VF020B_MediaIsAttached Function
Returns the status of the media.
Implementation: Dynamic
File
drv_sst25vf020b.h
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 817
C
bool DRV_SST25VF020B_MediaIsAttached(DRV_HANDLE handle);
Returns
• True - Media is attached
• False - Media is not attached
Description
This function determines whether or not the media is attached.
Remarks
This function is typically used by File System Media Manager.
Preconditions
None.
Example
if (DRV_SST25VF020B_MediaIsAttached(handle))
{
// Do Something
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
Function
bool DRV_SST25VF020B_MediaIsAttached( DRV_HANDLE handle);
e) Data Types and Constants
DRV_SST25VF020B_BLOCK_COMMAND_HANDLE Type
Handle identifying block commands of the driver.
File
drv_sst25vf020b.h
C
typedef SYS_FS_MEDIA_BLOCK_COMMAND_HANDLE DRV_SST25VF020B_BLOCK_COMMAND_HANDLE;
Description
SPI Flash Driver Block Command Handle
A block command handle is returned by a call to the Read, Write, or Erase functions. This handle allows the application to track the completion of
the operation. The handle is returned back to the client by the "event handler callback" function registered with the driver.
The handle assigned to a client request expires when the client has been notified of the completion of the operation (after event handler function
that notifies the client returns) or after the buffer has been retired by the driver if no event handler callback was set.
Remarks
None.
DRV_SST25VF020B_BLOCK_EVENT Enumeration
Identifies the possible events that can result from a request.
File
drv_sst25vf020b.h
C
typedef enum {
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 818
DRV_SST25VF020B_EVENT_BLOCK_COMMAND_COMPLETE,
DRV_SST25VF020B_EVENT_BLOCK_COMMAND_ERROR
} DRV_SST25VF020B_BLOCK_EVENT;
Members
Members Description
DRV_SST25VF020B_EVENT_BLOCK_COMMAND_COMPLETE Block operation has been completed successfully. Read/Write/Erase Complete
DRV_SST25VF020B_EVENT_BLOCK_COMMAND_ERROR There was an error during the block operation Read/Write/Erase Error
Description
SST25VF020B SPI Flash Driver Events
This enumeration identifies the possible events that can result from a Read, Write, or Erase request caused by the client.
Remarks
One of these values is passed in the "event" parameter of the event handling callback function that client registered with the driver by calling the
DRV_SST25VF020B_BlockEventHandlerSet function when a block request is completed.
DRV_SST25VF020B_CLIENT_STATUS Enumeration
Defines the client status.
File
drv_sst25vf020b.h
C
typedef enum {
DRV_SST25VF020B_CLIENT_STATUS_READY = DRV_CLIENT_STATUS_READY+0,
DRV_SST25VF020B_CLIENT_STATUS_BUSY = DRV_CLIENT_STATUS_BUSY,
DRV_SST25VF020B_CLIENT_STATUS_CLOSED = DRV_CLIENT_STATUS_CLOSED,
DRV_SST25VF020B_CLIENT_STATUS_ERROR = DRV_CLIENT_STATUS_ERROR
} DRV_SST25VF020B_CLIENT_STATUS;
Members
Members Description
DRV_SST25VF020B_CLIENT_STATUS_READY
= DRV_CLIENT_STATUS_READY+0
Up and running, ready to start new operations
DRV_SST25VF020B_CLIENT_STATUS_BUSY =
DRV_CLIENT_STATUS_BUSY
Operation in progress, unable to start a new one
DRV_SST25VF020B_CLIENT_STATUS_CLOSED
= DRV_CLIENT_STATUS_CLOSED
Client is closed
DRV_SST25VF020B_CLIENT_STATUS_ERROR
= DRV_CLIENT_STATUS_ERROR
Client Error
Description
SPI Flash Client Status
Defines the various client status codes.
Remarks
None.
DRV_SST25VF020B_EVENT_HANDLER Type
Pointer to a SST25VF020B SPI Flash Driver Event handler function.
File
drv_sst25vf020b.h
C
typedef void (* DRV_SST25VF020B_EVENT_HANDLER)(DRV_SST25VF020B_BLOCK_EVENT event,
DRV_SST25VF020B_BLOCK_COMMAND_HANDLE commandHandle, uintptr_t context);
Returns
None.
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 819
Description
SST25VF020B SPI Flash Driver Event Handler Function Pointer
This data type defines the required function signature for the SST25VF020B SPI Flash driver event handling callback function. A client must
register a pointer to an event handling function whose function signature (parameter and return value types) match the types specified by this
function pointer in order to receive event calls back from the driver.
The parameters and return values and return value are described here and a partial example implementation is provided.
Remarks
If the event is DRV_SST25VF020B_EVENT_BLOCK_COMMAND_COMPLETE, it means that the data was transferred successfully.
If the event is DRV_SST25VF020B_EVENT_BLOCK_COMMAND_ERROR, it means that the data was not transferred successfully.
The context parameter contains the a handle to the client context, provided at the time the event handling function was registered using the
DRV_SST25VF020B_BlockEventHandlerSet function. This context handle value is passed back to the client as the "context" parameter. It can be
any value necessary to identify the client context or instance (such as a pointer to the client's data) instance of the client that made the
read/write/erase request.
The event handler function executes in the driver peripheral's interrupt context when the driver is configured for interrupt mode operation. It is
recommended of the application to not perform process intensive or blocking operations with in this function.
The Read, Write, and Erase functions can be called in the event handler to add a buffer to the driver queue. These functions can only be called to
add buffers to the driver whose event handler is running.
Example
void APP_MyBufferEventHandler
(
DRV_SST25VF020B_BLOCK_EVENT event,
DRV_SST25VF020B_BLOCK_COMMAND_HANDLE commandHandle,
uintptr_t context
)
{
MY_APP_DATA_STRUCT pAppData = (MY_APP_DATA_STRUCT) context;
switch(event)
{
case DRV_SST25VF020B_EVENT_BLOCK_COMMAND_COMPLETE:
// Handle the completed buffer.
break;
case DRV_SST25VF020B_EVENT_BLOCK_COMMAND_ERROR:
default:
// Handle error.
break;
}
}
Parameters
Parameters Description
event Identifies the type of event
commandHandle Handle returned from the Read/Write/Erase requests
context Value identifying the context of the application that registered the event handling function
DRV_SST25VF020B_INIT Structure
Contains all the data necessary to initialize the SPI Flash device.
File
drv_sst25vf020b.h
C
typedef struct {
SYS_MODULE_INIT moduleInit;
SYS_MODULE_INDEX spiDriverModuleIndex;
PORTS_CHANNEL holdPortChannel;
PORTS_BIT_POS holdBitPosition;
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 820
PORTS_CHANNEL writeProtectPortChannel;
PORTS_BIT_POS writeProtectBitPosition;
PORTS_CHANNEL chipSelectPortChannel;
PORTS_BIT_POS chipSelectBitPosition;
uint32_t queueSize;
} DRV_SST25VF020B_INIT;
Members
Members Description
SYS_MODULE_INIT moduleInit; System module initialization
SYS_MODULE_INDEX spiDriverModuleIndex; Identifies the SPI driver to be used
PORTS_CHANNEL holdPortChannel; HOLD pin port channel
PORTS_BIT_POS holdBitPosition; HOLD pin port position
PORTS_CHANNEL writeProtectPortChannel; Write protect pin port channel
PORTS_BIT_POS writeProtectBitPosition; Write Protect Bit pin position
PORTS_CHANNEL chipSelectPortChannel; Chip select pin port channel
PORTS_BIT_POS chipSelectBitPosition; Chip Select Bit pin position
uint32_t queueSize; This is the buffer queue size. This is the maximum number of requests that this instance of
the driver will queue. For a static build of the driver, this is overridden by the
DRV_SST25VF020B_QUEUE_SIZE macro in system_config.h
Description
SST SPI Flash Driver Initialization Data
This structure contains all of the data necessary to initialize the SPI Flash device.
Remarks
A pointer to a structure of this format containing the desired initialization data must be passed into the DRV_SST25VF020B_Initialize function.
DRV_SST25VF020B_COMMAND_STATUS Enumeration
Specifies the status of the command for the read, write and erase operations.
File
drv_sst25vf020b.h
C
typedef enum {
DRV_SST25VF020B_COMMAND_COMPLETED,
DRV_SST25VF020B_COMMAND_QUEUED,
DRV_SST25VF020B_COMMAND_IN_PROGRESS,
DRV_SST25VF020B_COMMAND_ERROR_UNKNOWN
} DRV_SST25VF020B_COMMAND_STATUS;
Members
Members Description
DRV_SST25VF020B_COMMAND_COMPLETED Requested operation is completed
DRV_SST25VF020B_COMMAND_QUEUED Scheduled but not started
DRV_SST25VF020B_COMMAND_IN_PROGRESS Currently being in transfer
DRV_SST25VF020B_COMMAND_ERROR_UNKNOWN Unknown Command
Description
SST Flash Driver Command Status
SST Flash Driver command Status
This type specifies the status of the command for the read, write and erase operations.
Remarks
None.
DRV_SST25VF020B_BLOCK_COMMAND_HANDLE_INVALID Macro
This value defines the SPI Flash Driver Block Command Invalid handle.
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 821
File
drv_sst25vf020b.h
C
#define DRV_SST25VF020B_BLOCK_COMMAND_HANDLE_INVALID
Description
SPI Flash Driver Block Event Invalid Handle
This value defines the SPI Flash Driver Block Command Invalid handle. It is returned by read/write/erase routines when the request could not be
taken.
Remarks
None.
DRV_SST25VF020B_INDEX_0 Macro
SPI Flash driver index definitions.
File
drv_sst25vf020b.h
C
#define DRV_SST25VF020B_INDEX_0 0
Description
Driver SPI Flash Module Index reference
These constants provide SST25VF020B SPI Flash driver index definitions.
Remarks
These constants should be used in place of hard-coded numeric literals.
These values should be passed into the DRV_SST25VF020B_Initialize and DRV_SST25VF020B_Open routines to identify the driver instance in
use.
DRV_SST25VF020B_INDEX_1 Macro
File
drv_sst25vf020b.h
C
#define DRV_SST25VF020B_INDEX_1 1
Description
This is macro DRV_SST25VF020B_INDEX_1.
SST25VF064C API
a) System Functions
Name Description
DRV_SST25VF064C_Initialize Initializes the SST25VF064C SPI Flash Driver instance for the specified driver index.
DRV_SST25VF064C_Deinitialize Deinitializes the specified instance of the SPI Flash driver module.
DRV_SST25VF064C_Status Gets the current status of the SPI Flash Driver module.
DRV_SST25VF064C_Tasks Maintains the driver's read, erase, and write state machine and implements its ISR.
b) Core Client Functions
Name Description
DRV_SST25VF064C_ClientStatus Gets current client-specific status of the SPI Flash driver.
DRV_SST25VF064C_Close Closes an opened-instance of the SPI Flash driver.
DRV_SST25VF064C_CommandStatus Gets the current status of the command.
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 822
DRV_SST25VF064C_Open Opens the specified SPI Flash driver instance and returns a handle to it.
c) Block Operation Functions
Name Description
DRV_SST25VF064C_BlockErase Erase the specified number of blocks in Flash memory.
DRV_SST25VF064C_BlockEventHandlerSet Allows a client to identify an event handling function for the driver to call back when
queued operation has completed.
DRV_SST25VF064C_BlockRead Reads blocks of data starting from the specified address in Flash memory.
DRV_SST25VF064C_BlockWrite Write blocks of data starting from a specified address in Flash memory.
d) Media Interface Functions
Name Description
DRV_SST25VF064C_GeometryGet Returns the geometry of the device.
DRV_SST25VF064C_MediaIsAttached Returns the status of the media.
e) Data Types and Constants
Name Description
DRV_SST25VF064C_BLOCK_COMMAND_HANDLE Handle identifying block commands of the driver.
DRV_SST25VF064C_BLOCK_EVENT Identifies the possible events that can result from a request.
DRV_SST25VF064C_CLIENT_STATUS Defines the client status.
DRV_SST25VF064C_COMMAND_STATUS Specifies the status of the command for the read, write and erase
operations.
DRV_SST25VF064C_EVENT_HANDLER Pointer to a SST25VF064C SPI Flash Driver Event handler
function.
DRV_SST25VF064C_INIT Contains all the data necessary to initialize the SPI Flash device.
DRV_SST25VF064C_BLOCK_COMMAND_HANDLE_INVALID This value defines the SPI Flash Driver Block Command Invalid
handle.
DRV_SST25VF064C_INDEX_0 SPI Flash driver index definitions.
DRV_SST25VF064C_INDEX_1 This is macro DRV_SST25VF064C_INDEX_1.
Description
a) System Functions
DRV_SST25VF064C_Initialize Function
Initializes the SST25VF064C SPI Flash Driver instance for the specified driver index.
File
drv_sst25vf064c.h
C
SYS_MODULE_OBJ DRV_SST25VF064C_Initialize(const SYS_MODULE_INDEX index, const SYS_MODULE_INIT * const init);
Returns
If successful, returns a valid handle to a driver instance object. Otherwise, it returns SYS_MODULE_OBJ_INVALID.
Description
This function initializes the SPI Flash driver instance for the specified driver index, making it ready for clients to open and use it.
Remarks
This function must be called before any other SPI Flash function is called.
This function should only be called once during system initialization unless DRV_SST25VF064C_Deinitialize is called to deinitialize the driver
instance.
Build configuration options may be used to statically override options in the "init" structure and will take precedence over initialization data passed
using this function.
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 823
Preconditions
None.
Example
// This code snippet shows an example of initializing the SST25VF064C SPI
// Flash Driver. SPI driver index 0 is used for the purpose. Pin numbers 1, 2
// and 3 of port channel B are configured for hold pin, write protection pin
// and chip select pin respectively. Maximum buffer queue size is set 5.
DRV_SST25VF064C_INIT SST25VF064CInitData;
SYS_MODULE_OBJ objectHandle;
SST25VF064CInitData.moduleInit.value = SYS_MODULE_POWER_RUN_FULL;
SST25VF064CInitData.spiDriverModuleIndex = DRV_SPI_INDEX_0;
SST25VF064CInitData.holdPortChannel = PORT_CHANNEL_B;
SST25VF064CInitData.holdBitPosition = PORTS_BIT_POS_1;
SST25VF064CInitData.writeProtectPortChannel = PORT_CHANNEL_B;
SST25VF064CInitData.writeProtectBitPosition = PORTS_BIT_POS_2;
SST25VF064CInitData.chipSelectPortChannel = PORT_CHANNEL_F;
SST25VF064CInitData.chipSelectBitPosition = PORTS_BIT_POS_2;
SST25VF064CInitData.queueSize = 5;
objectHandle = DRV_SST25VF064C_Initialize(DRV_SST25VF064C_INDEX_0,
(SYS_MODULE_INIT*)SST25VF064CInitData);
if (SYS_MODULE_OBJ_INVALID == objectHandle)
{
// Handle error
}
Parameters
Parameters Description
index Identifier for the instance to be initialized
init Pointer to a data structure containing data necessary to initialize the driver.
Function
SYS_MODULE_OBJ DRV_SST25VF064C_Initialize
(
const SYS_MODULE_INDEX index,
const SYS_MODULE_INIT * const init
);
DRV_SST25VF064C_Deinitialize Function
Deinitializes the specified instance of the SPI Flash driver module.
File
drv_sst25vf064c.h
C
void DRV_SST25VF064C_Deinitialize(SYS_MODULE_OBJ object);
Returns
None.
Description
Deinitializes the specified instance of the SPI Flash Driver module, disabling its operation (and any hardware) and invalidates all of the internal
data.
Remarks
Once the Initialize operation has been called, the Deinitialize operation must be called before the Initialize operation can be called again. This
function will NEVER block waiting for hardware.
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 824
Preconditions
Function DRV_SST25VF064C_Initialize should have been called before calling this function.
Example
// This code snippet shows an example of deinitializing the driver.
SYS_MODULE_OBJ object; // Returned from DRV_SST25VF064C_Initialize
SYS_STATUS status;
DRV_SST25VF064C_Deinitialize(object);
status = DRV_SST25VF064C_Status(object);
if (SYS_MODULE_DEINITIALIZED != status)
{
// Check again later if you need to know
// when the driver is deinitialized.
}
Parameters
Parameters Description
object Driver object handle, returned from the DRV_SST25VF064C_Initialize
Function
void DRV_SST25VF064C_Deinitialize( SYS_MODULE_OBJ object )
DRV_SST25VF064C_Status Function
Gets the current status of the SPI Flash Driver module.
File
drv_sst25vf064c.h
C
SYS_STATUS DRV_SST25VF064C_Status(SYS_MODULE_OBJ object);
Returns
SYS_STATUS_READY - Indicates that the driver is ready and accept requests for new operations
SYS_STATUS_UNINITIALIZED - Indicates that the driver is not initialized
Description
This function provides the current status of the SPI Flash Driver module.
Remarks
A driver can only be opened when its status is SYS_STATUS_READY.
Preconditions
Function DRV_SST25VF064C_Initialize should have been called before calling this function.
Example
SYS_MODULE_OBJ object; // Returned from DRV_SST25VF064C_Initialize
SYS_STATUS SST25VF064CStatus;
SST25VF064CStatus = DRV_SST25VF064C_Status(object);
else if (SYS_STATUS_ERROR >= SST25VF064CStatus)
{
// Handle error
}
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 825
Parameters
Parameters Description
object Driver object handle, returned from the DRV_SST25VF064C_Initialize
Function
SYS_STATUS DRV_SST25VF064C_Status( SYS_MODULE_OBJ object )
DRV_SST25VF064C_Tasks Function
Maintains the driver's read, erase, and write state machine and implements its ISR.
File
drv_sst25vf064c.h
C
void DRV_SST25VF064C_Tasks(SYS_MODULE_OBJ object);
Returns
None.
Description
This function is used to maintain the driver's internal state machine and should be called from the system's Tasks function.
Remarks
This function is normally not called directly by an application. It is called by the system's Tasks function (SYS_Tasks).
Preconditions
The DRV_SST25VF064C_Initialize function must have been called for the specified SPI Flash driver instance.
Example
SYS_MODULE_OBJ object; // Returned from DRV_SST25VF064C_Initialize
while (true)
{
DRV_SST25VF064C_Tasks (object);
// Do other tasks
}
Parameters
Parameters Description
object Object handle for the specified driver instance (returned from DRV_SST25VF064C_Initialize)
Function
void DRV_SST25VF064C_Tasks ( SYS_MODULE_OBJ object );
b) Core Client Functions
DRV_SST25VF064C_ClientStatus Function
Gets current client-specific status of the SPI Flash driver.
File
drv_sst25vf064c.h
C
DRV_SST25VF064C_CLIENT_STATUS DRV_SST25VF064C_ClientStatus(const DRV_HANDLE handle);
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 826
Returns
A DRV_SST25VF064C_CLIENT_STATUS value describing the current status of the driver.
Description
This function gets the client-specific status of the SPI Flash driver associated with the given handle.
Remarks
This function will not block for hardware access and will immediately return the current status.
Preconditions
The DRV_SST25VF064C_Initialize function must have been called.
DRV_SST25VF064C_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE handle; // Returned from DRV_SST25VF064C_Open
DRV_SST25VF064C_CLIENT_STATUS clientStatus;
clientStatus = DRV_SST25VF064C_ClientStatus(handle);
if(DRV_SST25VF064C_CLIENT_STATUS_READY == clientStatus)
{
// do the tasks
}
Parameters
Parameters Description
handle A valid open instance handle, returned from the driver's open
Function
DRV_SST25VF064C_CLIENT_STATUS DRV_SST25VF064C_ClientStatus(DRV_HANDLE handle);
DRV_SST25VF064C_Close Function
Closes an opened-instance of the SPI Flash driver.
File
drv_sst25vf064c.h
C
void DRV_SST25VF064C_Close(const DRV_HANDLE handle);
Returns
None.
Description
This function closes an opened-instance of the SPI Flash driver, invalidating the handle.
Remarks
After calling this function, the handle passed in "handle" must not be used with any of the remaining driver routines. A new handle must be
obtained by calling DRV_SST25VF064C_Open before the caller may use the driver again.
Usually, there is no need for the driver client to verify that the Close operation has completed.
Preconditions
The DRV_SST25VF064C_Initialize function must have been called for the specified SPI Flash driver instance.
DRV_SST25VF064C_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE handle; // Returned from DRV_SST25VF064C_Open
DRV_SST25VF064C_Close(handle);
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 827
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
Function
void DRV_SST25VF064C_Close( DRV_Handle handle );
DRV_SST25VF064C_CommandStatus Function
Gets the current status of the command.
File
drv_sst25vf064c.h
C
DRV_SST25VF064C_COMMAND_STATUS DRV_SST25VF064C_CommandStatus(const DRV_HANDLE handle, const
DRV_SST25VF064C_BLOCK_COMMAND_HANDLE commandHandle);
Returns
A DRV_SST25VF064C_COMMAND_STATUS value describing the current status of the buffer. Returns
DRV_SST25VF064C_BLOCK_COMMAND_HANDLE_INVALID if the client handle or the command handle is not valid.
Description
This routine gets the current status of the buffer. The application must use this routine where the status of a scheduled buffer needs to polled on.
The function may return DRV_SST25VF064C_BLOCK_COMMAND_HANDLE_INVALID in a case where the buffer handle has expired. A buffer
handle expires when the internal buffer object is re-assigned to another erase, read or write request. It is recommended that this function be called
regularly in order to track the buffer status correctly.
The application can alternatively register an event handler to receive write, read or erase operation completion events.
Remarks
This function will not block for hardware access and will immediately return the current status.
Preconditions
Block command request must have been made using Erase, Read or Write APIs to get a valid command handle.
Example
DRV_HANDLE sstOpenHandle; // Returned from DRV_SST25VF064C_Open
DRV_SST25VF064C_BLOCK_COMMAND_HANDLE commandHandle;
DRV_SST25VF064C_BlockErase
(
sstOpenHandle,
&commandHandle,
0,
1
);
if(DRV_SST25VF064C_CommandStatus(sstOpenHandle, commandHandle) == DRV_SST25VF064C_COMMAND_COMPLETED );
{
// do something
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
commandHandle A valid command handle, returned from Read/Write/Erase APIs.
Function
DRV_SST25VF064C_COMMAND_STATUS DRV_SST25VF064C_CommandStatus
(
const DRV_HANDLE handle,
const DRV_SST25VF064C_BLOCK_COMMAND_HANDLE commandHandle
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 828
);
DRV_SST25VF064C_Open Function
Opens the specified SPI Flash driver instance and returns a handle to it.
File
drv_sst25vf064c.h
C
DRV_HANDLE DRV_SST25VF064C_Open(const SYS_MODULE_INDEX drvIndex, const DRV_IO_INTENT ioIntent);
Returns
If successful, the function returns a valid open-instance handle (a number identifying both the caller and the module instance).
If an error occurs, the return value is DRV_HANDLE_INVALID. Errors can occur under the following circumstances:
• if the number of client objects allocated via DRV_SST25VF064C_CLIENTS_NUMBER is insufficient
• if the client is trying to open the driver but driver has been opened exclusively by another client
• if the driver hardware instance being opened is not initialized or is invalid
• if the client is trying to open the driver exclusively, but has already been opened in a non exclusive mode by another client.
Description
This function opens the specified SPI Flash driver instance and provides a handle that must be provided to all other client-level operations to
identify the caller and the instance of the driver.
Remarks
The driver will always work in Non-Blocking mode even if IO-intent is selected as blocking.
The handle returned is valid until the DRV_SST25VF064C_Close function is called.
This function will NEVER block waiting for hardware.
Preconditions
Function DRV_SST25VF064C_Initialize must have been called before calling this function.
Example
DRV_HANDLE handle;
handle = DRV_SST25VF064C_Open(DRV_SST25VF064C_INDEX_0,
DRV_IO_INTENT_EXCLUSIVE);
if (DRV_HANDLE_INVALID == handle)
{
// Unable to open the driver
}
Parameters
Parameters Description
drvIndex Identifier for the object instance to be opened
ioIntent Zero or more of the values from the enumeration DRV_IO_INTENT "ORed" together to
indicate the intended use of the driver
Function
DRV_HANDLE DRV_SST25VF064C_Open
(
const SYS_MODULE_INDEX drvIndex,
const DRV_IO_INTENT ioIntent
);
c) Block Operation Functions
DRV_SST25VF064C_BlockErase Function
Erase the specified number of blocks in Flash memory.
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 829
File
drv_sst25vf064c.h
C
void DRV_SST25VF064C_BlockErase(const DRV_HANDLE handle, DRV_SST25VF064C_BLOCK_COMMAND_HANDLE *
commandHandle, uint32_t blockStart, uint32_t nBlock);
Returns
The buffer handle is returned in the commandHandle argument. It Will be DRV_BUFFER_HANDLE_INVALID if the request was not queued.
Description
This function schedules a non-blocking erase operation in Flash memory. The function returns with a valid erase handle in the commandHandle
argument if the erase request was scheduled successfully. The function adds the request to the hardware instance queue and returns
immediately. The function returns DRV_SST25VF064C_BLOCK_COMMAND_HANDLE_INVALID in the commandHandle argument under the
following circumstances:
• if the client opened the driver for read only
• if nBlock is 0
• if the queue size is full or queue depth is insufficient
• if the driver handle is invalid
If the requesting client registered an event callback with the driver, the driver will issue a DRV_SST25VF064C_EVENT_ERASE_COMPLETE
event if the erase operation was successful or DRV_SST25VF064C_EVENT_ERASE_ERROR event if the erase operation was not successful.
Remarks
Write Protection will be disabled for the complete Flash memory region in the beginning by default.
Preconditions
The DRV_SST25VF064C_Initialize function must have been called for the specified SPI Flash driver instance.
DRV_SST25VF064C_Open must have been called to obtain a valid opened device handle.
DRV_IO_INTENT_WRITE or DRV_IO_INTENT_READWRITE must have been specified in the DRV_SST25VF064C_Open call.
Example
// Destination address should be block aligned.
uint32_t blockStart;
uint32_t nBlock;
DRV_SST25VF064C_BLOCK_COMMAND_HANDLE commandHandle;
MY_APP_OBJ myAppObj;
// mySST25VF064CHandle is the handle returned
// by the DRV_SST25VF064C_Open function.
// Client registers an event handler with driver
DRV_SST25VF064C_BlockEventHandlerSet(mySST25VF064CHandle,
APP_SST25VF064CEventHandler, (uintptr_t)&myAppObj);
DRV_SST25VF064C_BlockErase( mySST25VF064CHandle, commandHandle,
blockStart, nBlock );
if(DRV_SST25VF064C_BLOCK_COMMAND_HANDLE_INVALID == commandHandle)
{
// Error handling here
}
// Event is received when
// the buffer queue is processed.
void APP_SST25VF064CEventHandler(DRV_SST25VF064C_BLOCK_EVENT event,
DRV_SST25VF064C_BLOCK_COMMAND_HANDLE commandHandle, uintptr_t contextHandle)
{
// contextHandle points to myAppObj.
switch(event)
{
case DRV_SST25VF064C_EVENT_ERASE_COMPLETE:
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 830
// This means the data was transferred.
break;
case DRV_SST25VF064C_EVENT_ERASE_ERROR:
// Error handling here.
break;
default:
break;
}
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
commandHandle Pointer to an argument that will contain the return buffer handle
blockStart Start block address in SST25VF064C memory from where the erase should begin. LSBs
(A0-A11) of block start address will be ignored to align it with Erase block size boundary.
nBlock Total number of blocks to be erased. Each Erase block is of size 4 KByte.
Function
void DRV_SST25VF064C_BlockErase
(
const DRV_HANDLE handle,
DRV_SST25VF064C_BLOCK_COMMAND_HANDLE * commandHandle,
uint32_t blockStart,
uint32_t nBlock
);
DRV_SST25VF064C_BlockEventHandlerSet Function
Allows a client to identify an event handling function for the driver to call back when queued operation has completed.
File
drv_sst25vf064c.h
C
void DRV_SST25VF064C_BlockEventHandlerSet(const DRV_HANDLE handle, const DRV_SST25VF064C_EVENT_HANDLER
eventHandler, const uintptr_t context);
Returns
None.
Description
This function allows a client to identify an event handling function for the driver to call back when queued operation has completed. When a client
calls any read, write or erase function, it is provided with a handle identifying the buffer that was added to the driver's buffer queue. The driver will
pass this handle back to the client by calling "eventHandler" function when the queued operation has completed.
The event handler should be set before the client performs any read/write/erase operations that could generate events. The event handler once
set, persists until the client closes the driver or sets another event handler (which could be a "NULL" pointer to indicate no callback).
Remarks
If the client does not want to be notified when the queued operation has completed, it does not need to register a callback.
Preconditions
The DRV_SST25VF064C_Initialize function must have been called for the specified SPI FLash driver instance.
DRV_SST25VF064C_Open must have been called to obtain a valid opened device handle.
Example
// myAppObj is an application specific state data object.
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 831
MY_APP_OBJ myAppObj;
uint8_t myBuffer[MY_BUFFER_SIZE];
uint32_t blockStart, nBlock;
DRV_SST25VF064C_BLOCK_COMMAND_HANDLE commandHandle;
// mySST25VF064CHandle is the handle returned
// by the DRV_SST25VF064C_Open function.
// Client registers an event handler with driver. This is done once.
DRV_SST25VF064C_BlockEventHandlerSet( mySST25VF064CHandle,
APP_SST25VF064CEventHandler, (uintptr_t)&myAppObj );
DRV_SST25VF064C_BlockRead( mySST25VF064CHandle, commandHandle,
&myBuffer, blockStart, nBlock );
if(DRV_SST25VF064C_BLOCK_COMMAND_HANDLE_INVALID == commandHandle)
{
// Error handling here
}
// Event Processing Technique. Event is received when operation is done.
void APP_SST25VF064CEventHandler(DRV_SST25VF064C_BLOCK_EVENT event,
DRV_SST25VF064C_BLOCK_COMMAND_HANDLE handle, uintptr_t context)
{
// The context handle was set to an application specific
// object. It is now retrievable easily in the event handler.
MY_APP_OBJ myAppObj = (MY_APP_OBJ *) context;
switch(event)
{
case DRV_SST25VF064C_EVENT_BLOCK_COMMAND_COMPLETE:
// This means the data was transferred.
break;
case DRV_SST25VF064C_EVENT_BLOCK_COMMAND_ERROR:
// Error handling here.
break;
default:
break;
}
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
eventHandler Pointer to the event handler function implemented by the user
context The value of parameter will be passed back to the client unchanged, when the eventHandler
function is called. It can be used to identify any client specific data object that identifies the
instance of the client module (for example, it may be a pointer to the client module's state
structure).
Function
void DRV_SST25VF064C_BlockEventHandlerSet
(
const DRV_HANDLE handle,
const DRV_SST25VF064C_EVENT_HANDLER eventHandler,
const uintptr_t context
);
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 832
DRV_SST25VF064C_BlockRead Function
Reads blocks of data starting from the specified address in Flash memory.
File
drv_sst25vf064c.h
C
void DRV_SST25VF064C_BlockRead(const DRV_HANDLE handle, DRV_SST25VF064C_BLOCK_COMMAND_HANDLE *
commandHandle, uint8_t * targetBuffer, uint32_t blockStart, uint32_t nBlock);
Returns
The buffer handle is returned in the commandHandle argument. It will be DRV_BUFFER_HANDLE_INVALID if the request was not successful.
Description
This function schedules a non-blocking read operation for reading blocks of data from Flash memory. The function returns with a valid handle in
the commandHandle argument if the read request was scheduled successfully. The function adds the request to the hardware instance queue and
returns immediately. While the request is in the queue, the application buffer is owned by the driver and should not be modified. The function
returns DRV_SST25VF064C_BLOCK_COMMAND_HANDLE_INVALID in the commandHandle argument under the following circumstances:
• if a buffer could not be allocated to the request
• if the target buffer pointer is NULL
• if the client opened the driver for write only
• if the buffer size is 0
• if the read queue size is full or queue depth is insufficient
• if the driver handle is invalid
If the requesting client registered an event callback with the driver, the driver will issue a
DRV_SST25VF064C_EVENT_BLOCK_COMMAND_COMPLETE event if the buffer was processed successfully of
DRV_SST25VF064C_EVENT_BLOCK_COMMAND_ERROR event if the buffer was not processed successfully.
Remarks
The maximum read speed is 33 MHz.
Preconditions
The DRV_SST25VF064C_Initialize function must have been called for the specified SPI Flash driver instance.
DRV_SST25VF064C_Open must have been called to obtain a valid opened device handle.
DRV_IO_INTENT_READ or DRV_IO_INTENT_READWRITE must have been specified in the DRV_SST25VF064C_Open call.
Example
uint8_t myBuffer[MY_BUFFER_SIZE];
// address should be block aligned.
uint32_t blockStart = SST25VF064C_BASE_ADDRESS_TO_READ_FROM;
uint32_t nBlock = 2;
DRV_SST25VF064C_BLOCK_COMMAND_HANDLE commandHandle;
MY_APP_OBJ myAppObj;
// mySST25VF064CHandle is the handle returned
// by the DRV_SST25VF064C_Open function.
// Client registers an event handler with driver
DRV_SST25VF064C_BlockEventHandlerSet(mySST25VF064CHandle,
APP_SST25VF064CEventHandler, (uintptr_t)&myAppObj);
DRV_SST25VF064C_BlockRead( mySST25VF064CHandle, commandHandle,
&myBuffer, blockStart, nBlock );
if(DRV_SST25VF064C_BLOCK_COMMAND_HANDLE_INVALID == commandHandle)
{
// Error handling here
}
// Event is received when the buffer is processed.
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 833
void APP_SST25VF064CEventHandler(DRV_SST25VF064C_BLOCK_EVENT event,
DRV_SST25VF064C_BLOCK_COMMAND_HANDLE commandHandle, uintptr_t contextHandle)
{
// contextHandle points to myAppObj.
switch(event)
{
case DRV_SST25VF064C_EVENT_BLOCK_COMMAND_COMPLETE:
// This means the data was transferred.
break;
case DRV_SST25VF064C_EVENT_BLOCK_COMMAND_ERROR:
// Error handling here.
break;
default:
break;
}
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
commandHandle Pointer to an argument that will contain the return buffer handle
*targetBuffer Buffer into which the data read from the SPI Flash instance will be placed
blockStart Start block address in SST25VF064C memory from where the read should begin. It can be
any address of the Flash.
nBlock Total number of blocks to be read. Each Read block is of 1 byte.
Function
void DRV_SST25VF064C_BlockRead
(
const DRV_HANDLE handle,
DRV_SST25VF064C_BLOCK_COMMAND_HANDLE * commandHandle,
uint8_t *targetBuffer,
uint32_t blockStart,
uint32_t nBlock
);
DRV_SST25VF064C_BlockWrite Function
Write blocks of data starting from a specified address in Flash memory.
File
drv_sst25vf064c.h
C
void DRV_SST25VF064C_BlockWrite(DRV_HANDLE handle, DRV_SST25VF064C_BLOCK_COMMAND_HANDLE * commandHandle,
uint8_t * sourceBuffer, uint32_t blockStart, uint32_t nBlock);
Returns
The buffer handle is returned in the commandHandle argument. It will be DRV_BUFFER_HANDLE_INVALID if the request was not successful.
Description
This function schedules a non-blocking write operation for writing blocks of data into Flash memory. The function returns with a valid buffer handle
in the commandHandle argument if the write request was scheduled successfully. The function adds the request to the hardware instance queue
and returns immediately. While the request is in the queue, the application buffer is owned by the driver and should not be modified. The function
returns DRV_SST25VF064C_BLOCK_COMMAND_HANDLE_INVALID in the commandHandle argument under the following circumstances:
• if a buffer could not be allocated to the request
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 834
• if the input buffer pointer is NULL
• if the client opened the driver for read only
• if the buffer size is 0
• if the write queue size is full or queue depth is insufficient
• if the driver handle is invalid
If the requesting client registered an event callback with the driver, the driver will issue a
DRV_SST25VF064C_EVENT_BLOCK_COMMAND_COMPLETE event if the buffer was processed successfully or
DRV_SST25VF064C_EVENT_BLOCK_COMMAND_ERROR event if the buffer was not processed successfully.
Remarks
In the case of multi bytes write operation, byte by byte writing will happen instead of Address auto Increment writing.
Write Protection will be disabled for the complete Flash memory region in the beginning by default.
Preconditions
The DRV_SST25VF064C_Initialize function must have been called for the specified SPI Flash driver instance.
DRV_SST25VF064C_Open must have been called to obtain a valid opened device handle.
DRV_IO_INTENT_WRITE or DRV_IO_INTENT_READWRITE must have been specified in the DRV_SST25VF064C_Open call.
The Flash address location which has to be written, must be erased before using the API DRV_SST25VF064C_BlockErase().
Example
uint8_t myBuffer[MY_BUFFER_SIZE];
// address should be block aligned.
uint32_t blockStart = SST25VF064C_BASE_ADDRESS_TO_WRITE_TO;
uint32_t nBlock = 2;
DRV_SST25VF064C_BLOCK_COMMAND_HANDLE commandHandle;
MY_APP_OBJ myAppObj;
// mySST25VF064CHandle is the handle returned
// by the DRV_SST25VF064C_Open function.
// Client registers an event handler with driver
DRV_SST25VF064C_BlockEventHandlerSet(mySST25VF064CHandle,
APP_SST25VF064CEventHandler, (uintptr_t)&myAppObj);
DRV_SST25VF064C_BlockWrite( mySST25VF064CHandle, commandHandle,
&myBuffer, blockStart, nBlock );
if(DRV_SST25VF064C_BLOCK_COMMAND_HANDLE_INVALID == commandHandle)
{
// Error handling here
}
// Event is received when
// the buffer is processed.
void APP_SST25VF064CEventHandler(DRV_SST25VF064C_BLOCK_EVENT event,
DRV_SST25VF064C_BLOCK_COMMAND_HANDLE commandHandle, uintptr_t contextHandle)
{
// contextHandle points to myAppObj.
switch(event)
{
case DRV_SST25VF064C_EVENT_BLOCK_COMMAND_COMPLETE:
// This means the data was transferred.
break;
case DRV_SST25VF064C_EVENT_BLOCK_COMMAND_ERROR:
// Error handling here.
break;
default:
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 835
break;
}
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
commandHandle -Pointer to an argument that will contain the return buffer handle
sourceBuffer The source buffer containing data to be programmed into SPI Flash
blockStart Start block address of SST25VF064C Flash where the write should begin. It can be any
address of the Flash.
nBlock Total number of blocks to be written. Each write block is of 1 byte.
Function
void DRV_SST25VF064C_BlockWrite
(
DRV_HANDLE handle,
DRV_SST25VF064C_BLOCK_COMMAND_HANDLE * commandHandle,
uint8_t *sourceBuffer,
uint32_t blockStart,
uint32_t nBlock
);
d) Media Interface Functions
DRV_SST25VF064C_GeometryGet Function
Returns the geometry of the device.
File
drv_sst25vf064c.h
C
SYS_FS_MEDIA_GEOMETRY * DRV_SST25VF064C_GeometryGet(DRV_HANDLE handle);
Returns
SYS_FS_MEDIA_GEOMETRY - Structure which holds the media geometry information.
Description
This API gives the following geometrical details of the SST25VF064C Flash:
• Media Property
• Number of Read/Write/Erase regions in the Flash device
• Number of Blocks and their size in each region of the device
Remarks
This function is typically used by File System Media Manager.
Preconditions
None.
Example
SYS_FS_MEDIA_GEOMETRY * sstFlashGeometry;
uint32_t readBlockSize, writeBlockSize, eraseBlockSize;
uint32_t nReadBlocks, nReadRegions, totalFlashSize;
sstFlashGeometry = DRV_SST25VF064C_GeometryGet(sstOpenHandle1);
// read block size should be 1 byte
readBlockSize = sstFlashGeometry->geometryTable->blockSize;
nReadBlocks = sstFlashGeometry->geometryTable->numBlocks;
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 836
nReadRegions = sstFlashGeometry->numReadRegions;
// write block size should be 1 byte
writeBlockSize = (sstFlashGeometry->geometryTable +1)->blockSize;
// erase block size should be 4k byte
eraseBlockSize = (sstFlashGeometry->geometryTable +2)->blockSize;
// total Flash size should be 8 MB
totalFlashSize = readBlockSize * nReadBlocks * nReadRegions;
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
Function
SYS_FS_MEDIA_GEOMETRY DRV_SST25VF064C_GeometryGet( DRV_HANDLE handle );
DRV_SST25VF064C_MediaIsAttached Function
Returns the status of the media.
File
drv_sst25vf064c.h
C
bool DRV_SST25VF064C_MediaIsAttached(DRV_HANDLE handle);
Returns
• True - Media is attached
• False - Media is not attached
Description
This function determines whether or not the media is attached.
Remarks
This function is typically used by File System Media Manager.
Preconditions
None.
Example
if (DRV_SST25VF064C_MediaIsAttached(handle))
{
// Do Something
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
Function
bool DRV_SST25VF064C_MediaIsAttached( DRV_HANDLE handle);
e) Data Types and Constants
DRV_SST25VF064C_BLOCK_COMMAND_HANDLE Type
Handle identifying block commands of the driver.
File
drv_sst25vf064c.h
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 837
C
typedef SYS_FS_MEDIA_BLOCK_COMMAND_HANDLE DRV_SST25VF064C_BLOCK_COMMAND_HANDLE;
Description
SPI Flash Driver Block Command Handle
A block command handle is returned by a call to the Read, Write, or Erase functions. This handle allows the application to track the completion of
the operation. The handle is returned back to the client by the "event handler callback" function registered with the driver.
The handle assigned to a client request expires when the client has been notified of the completion of the operation (after event handler function
that notifies the client returns) or after the buffer has been retired by the driver if no event handler callback was set.
Remarks
None.
DRV_SST25VF064C_BLOCK_EVENT Enumeration
Identifies the possible events that can result from a request.
File
drv_sst25vf064c.h
C
typedef enum {
DRV_SST25VF064C_EVENT_BLOCK_COMMAND_COMPLETE,
DRV_SST25VF064C_EVENT_BLOCK_COMMAND_ERROR
} DRV_SST25VF064C_BLOCK_EVENT;
Members
Members Description
DRV_SST25VF064C_EVENT_BLOCK_COMMAND_COMPLETE Block operation has been completed successfully. Read/Write/Erase Complete
DRV_SST25VF064C_EVENT_BLOCK_COMMAND_ERROR There was an error during the block operation Read/Write/Erase Error
Description
SST25VF064C SPI Flash Driver Events
This enumeration identifies the possible events that can result from a Read, Write, or Erase request caused by the client.
Remarks
One of these values is passed in the "event" parameter of the event handling callback function that client registered with the driver by calling the
DRV_SST25VF064C_BlockEventHandlerSet function when a block request is completed.
DRV_SST25VF064C_CLIENT_STATUS Enumeration
Defines the client status.
File
drv_sst25vf064c.h
C
typedef enum {
DRV_SST25VF064C_CLIENT_STATUS_READY = DRV_CLIENT_STATUS_READY+0,
DRV_SST25VF064C_CLIENT_STATUS_BUSY = DRV_CLIENT_STATUS_BUSY,
DRV_SST25VF064C_CLIENT_STATUS_CLOSED = DRV_CLIENT_STATUS_CLOSED,
DRV_SST25VF064C_CLIENT_STATUS_ERROR = DRV_CLIENT_STATUS_ERROR
} DRV_SST25VF064C_CLIENT_STATUS;
Members
Members Description
DRV_SST25VF064C_CLIENT_STATUS_READY
= DRV_CLIENT_STATUS_READY+0
Up and running, ready to start new operations
DRV_SST25VF064C_CLIENT_STATUS_BUSY =
DRV_CLIENT_STATUS_BUSY
Operation in progress, unable to start a new one
DRV_SST25VF064C_CLIENT_STATUS_CLOSED
= DRV_CLIENT_STATUS_CLOSED
Client is closed
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 838
DRV_SST25VF064C_CLIENT_STATUS_ERROR
= DRV_CLIENT_STATUS_ERROR
Client Error
Description
SPI Flash Client Status
Defines the various client status codes.
Remarks
None.
DRV_SST25VF064C_COMMAND_STATUS Enumeration
Specifies the status of the command for the read, write and erase operations.
File
drv_sst25vf064c.h
C
typedef enum {
DRV_SST25VF064C_COMMAND_COMPLETED,
DRV_SST25VF064C_COMMAND_QUEUED,
DRV_SST25VF064C_COMMAND_IN_PROGRESS,
DRV_SST25VF064C_COMMAND_ERROR_UNKNOWN
} DRV_SST25VF064C_COMMAND_STATUS;
Members
Members Description
DRV_SST25VF064C_COMMAND_COMPLETED Requested operation is completed
DRV_SST25VF064C_COMMAND_QUEUED Scheduled but not started
DRV_SST25VF064C_COMMAND_IN_PROGRESS Currently being in transfer
DRV_SST25VF064C_COMMAND_ERROR_UNKNOWN Unknown Command
Description
SST Flash Driver Command Status
SST Flash Driver command Status. This type specifies the status of the command for the read, write and erase operations.
Remarks
None.
DRV_SST25VF064C_EVENT_HANDLER Type
Pointer to a SST25VF064C SPI Flash Driver Event handler function.
File
drv_sst25vf064c.h
C
typedef void (* DRV_SST25VF064C_EVENT_HANDLER)(DRV_SST25VF064C_BLOCK_EVENT event,
DRV_SST25VF064C_BLOCK_COMMAND_HANDLE commandHandle, uintptr_t context);
Returns
None.
Description
SST25VF064C SPI Flash Driver Event Handler Function Pointer
This data type defines the required function signature for the SST25VF064C SPI Flash driver event handling callback function. A client must
register a pointer to an event handling function whose function signature (parameter and return value types) match the types specified by this
function pointer in order to receive event calls back from the driver.
The parameters and return values and return value are described here and a partial example implementation is provided.
Remarks
If the event is DRV_SST25VF064C_EVENT_BLOCK_COMMAND_COMPLETE, it means that the data was transferred successfully.
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 839
If the event is DRV_SST25VF064C_EVENT_BLOCK_COMMAND_ERROR, it means that the data was not transferred successfully.
The context parameter contains the a handle to the client context, provided at the time the event handling function was registered using the
DRV_SST25VF064C_BlockEventHandlerSet function. This context handle value is passed back to the client as the "context" parameter. It can be
any value necessary to identify the client context or instance (such as a pointer to the client's data) instance of the client that made the
read/write/erase request.
The event handler function executes in the driver peripheral's interrupt context when the driver is configured for interrupt mode operation. It is
recommended of the application to not perform process intensive or blocking operations with in this function.
The Read, Write, and Erase functions can be called in the event handler to add a buffer to the driver queue. These functions can only be called to
add buffers to the driver whose event handler is running.
Example
void APP_MyBufferEventHandler
(
DRV_SST25VF064C_BLOCK_EVENT event,
DRV_SST25VF064C_BLOCK_COMMAND_HANDLE commandHandle,
uintptr_t context
)
{
MY_APP_DATA_STRUCT pAppData = (MY_APP_DATA_STRUCT) context;
switch(event)
{
case DRV_SST25VF064C_EVENT_BLOCK_COMMAND_COMPLETE:
// Handle the completed buffer.
break;
case DRV_SST25VF064C_EVENT_BLOCK_COMMAND_ERROR:
default:
// Handle error.
break;
}
}
Parameters
Parameters Description
event Identifies the type of event
commandHandle Handle returned from the Read/Write/Erase requests
context Value identifying the context of the application that registered the event handling function
DRV_SST25VF064C_INIT Structure
Contains all the data necessary to initialize the SPI Flash device.
File
drv_sst25vf064c.h
C
typedef struct {
SYS_MODULE_INIT moduleInit;
SYS_MODULE_INDEX spiDriverModuleIndex;
PORTS_CHANNEL holdPortChannel;
PORTS_BIT_POS holdBitPosition;
PORTS_CHANNEL writeProtectPortChannel;
PORTS_BIT_POS writeProtectBitPosition;
PORTS_CHANNEL chipSelectPortChannel;
PORTS_BIT_POS chipSelectBitPosition;
uint32_t queueSize;
} DRV_SST25VF064C_INIT;
Members
Members Description
SYS_MODULE_INIT moduleInit; System module initialization
SYS_MODULE_INDEX spiDriverModuleIndex; Identifies the SPI driver to be used
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 840
PORTS_CHANNEL holdPortChannel; HOLD pin port channel
PORTS_BIT_POS holdBitPosition; HOLD pin port position
PORTS_CHANNEL writeProtectPortChannel; Write protect pin port channel
PORTS_BIT_POS writeProtectBitPosition; Write Protect Bit pin position
PORTS_CHANNEL chipSelectPortChannel; Chip select pin port channel
PORTS_BIT_POS chipSelectBitPosition; Chip Select Bit pin position
uint32_t queueSize; This is the buffer queue size. This is the maximum number of requests that this instance of
the driver will queue. For a static build of the driver, this is overridden by the
DRV_SST25VF064C_QUEUE_SIZE macro in system_config.h
Description
SST SPI Flash Driver Initialization Data
This structure contains all of the data necessary to initialize the SPI Flash device.
Remarks
A pointer to a structure of this format containing the desired initialization data must be passed into the DRV_SST25VF064C_Initialize function.
DRV_SST25VF064C_BLOCK_COMMAND_HANDLE_INVALID Macro
This value defines the SPI Flash Driver Block Command Invalid handle.
File
drv_sst25vf064c.h
C
#define DRV_SST25VF064C_BLOCK_COMMAND_HANDLE_INVALID
Description
SPI Flash Driver Block Event Invalid Handle
This value defines the SPI Flash Driver Block Command Invalid handle. It is returned by read/write/erase routines when the request could not be
taken.
Remarks
None.
DRV_SST25VF064C_INDEX_0 Macro
SPI Flash driver index definitions.
File
drv_sst25vf064c.h
C
#define DRV_SST25VF064C_INDEX_0 0
Description
Driver SPI Flash Module Index reference
These constants provide SST25VF064C SPI Flash driver index definitions.
Remarks
These constants should be used in place of hard-coded numeric literals.
These values should be passed into the DRV_SST25VF064C_Initialize and DRV_SST25VF064C_Open routines to identify the driver instance in
use.
DRV_SST25VF064C_INDEX_1 Macro
File
drv_sst25vf064c.h
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 841
C
#define DRV_SST25VF064C_INDEX_1 1
Description
This is macro DRV_SST25VF064C_INDEX_1.
Files
Files
Name Description
drv_sst25vf016b.h SPI Flash Driver Interface Definition
drv_sst25vf016b_config_template.h SST25VF016B Driver Configuration Template.
drv_sst25vf020b.h SPI Flash Driver Interface Definition
drv_sst25vf020b_config_template.h SST25VF020B Driver Configuration Template.
drv_sst25vf064c.h SPI Flash Driver Interface Definition
drv_sst25vf064c_config_template.h SST25VF064C Driver Configuration Template.
Description
This section lists the source and header files used by the SPI Flash Driver Library.
drv_sst25vf016b.h
SPI Flash Driver Interface Definition
Enumerations
Name Description
DRV_SST25VF016B_BLOCK_EVENT Identifies the possible events that can result from a request.
DRV_SST25VF016B_CLIENT_STATUS Defines the client status.
Implementation: Dynamic
Functions
Name Description
DRV_SST25VF016B_BlockErase Erase the specified number of blocks in Flash memory.
Implementation: Dynamic
DRV_SST25VF016B_BlockEventHandlerSet Allows a client to identify an event handling function for the driver to call back when
queued operation has completed.
Implementation: Dynamic
DRV_SST25VF016B_BlockRead Reads blocks of data starting from the specified address in Flash memory.
Implementation: Dynamic
DRV_SST25VF016B_BlockWrite Write blocks of data starting from a specified address in Flash memory.
Implementation: Dynamic
DRV_SST25VF016B_ClientStatus Gets current client-specific status of the SPI Flash driver.
Implementation: Dynamic
DRV_SST25VF016B_Close Closes an opened-instance of the SPI Flash driver.
Implementation: Dynamic
DRV_SST25VF016B_Deinitialize Deinitializes the specified instance of the SPI Flash driver module.
Implementation: Dynamic
DRV_SST25VF016B_GeometryGet Returns the geometry of the device.
Implementation: Dynamic
DRV_SST25VF016B_Initialize Initializes the SST25VF016B SPI Flash Driver instance for the specified driver index.
Implementation: Dynamic
DRV_SST25VF016B_MediaIsAttached Returns the status of the media.
Implementation: Dynamic
DRV_SST25VF016B_Open Opens the specified SPI Flash driver instance and returns a handle to it.
Implementation: Dynamic
DRV_SST25VF016B_Status Gets the current status of the SPI Flash Driver module.
Implementation: Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 842
DRV_SST25VF016B_Tasks Maintains the driver's read, erase, and write state machine and implements its ISR.
Implementation: Dynamic
Macros
Name Description
DRV_SST25VF016B_BLOCK_COMMAND_HANDLE_INVALID This value defines the SPI Flash Driver Block Command Invalid
handle.
DRV_SST25VF016B_INDEX_0 SPI Flash driver index definitions
DRV_SST25VF016B_INDEX_1 This is macro DRV_SST25VF016B_INDEX_1.
Structures
Name Description
DRV_SST25VF016B_INIT Contains all the data necessary to initialize the SPI Flash device.
Implementation: Dynamic
Types
Name Description
DRV_SST25VF016B_BLOCK_COMMAND_HANDLE Handle identifying block commands of the driver.
DRV_SST25VF016B_EVENT_HANDLER Pointer to a SST25VF016B SPI Flash Driver Event handler function.
Implementation: Dynamic
Description
SPI Flash Driver Interface Definition
The SPI Flash device driver provides a simple interface to manage the SPI Flash modules which are external to Microchip Controllers. This file
defines the interface definition for the SPI Flash Driver.
File Name
drv_sst25vf016b.h
Company
Microchip Technology Inc.
drv_sst25vf016b_config_template.h
SST25VF016B Driver Configuration Template.
Macros
Name Description
DRV_SST25VF016B_CLIENTS_NUMBER Sets up the maximum number of clients that can be
connected to any hardware instance.
DRV_SST25VF016B_HARDWARE_HOLD_ENABLE Specifies if the hardware hold feature is enabled or not.
DRV_SST25VF016B_HARDWARE_WRITE_PROTECTION_ENABLE Specifies if the hardware write protect feature is enabled or
not.
DRV_SST25VF016B_INSTANCES_NUMBER Sets up the maximum number of hardware instances that
can be supported
DRV_SST25VF016B_MODE Determines whether the driver is implemented as static or
dynamic
DRV_SST25VF016B_QUEUE_DEPTH_COMBINED Number of entries of queues in all instances of the driver.
Description
SST25VF016B Driver Configuration Template
These file provides the list of all the configurations that can be used with the driver. This file should not be included in the driver.
File Name
drv_sst25vf016b_config_template.h
Company
Microchip Technology Inc.
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 843
drv_sst25vf020b.h
SPI Flash Driver Interface Definition
Enumerations
Name Description
DRV_SST25VF020B_BLOCK_EVENT Identifies the possible events that can result from a request.
DRV_SST25VF020B_CLIENT_STATUS Defines the client status.
DRV_SST25VF020B_COMMAND_STATUS Specifies the status of the command for the read, write and erase operations.
Functions
Name Description
DRV_SST25VF020B_BlockErase Erase the specified number of blocks in Flash memory.
Implementation: Dynamic
DRV_SST25VF020B_BlockEraseWrite Erase and Write blocks of data starting from a specified address in SST flash
memory.
DRV_SST25VF020B_BlockEventHandlerSet Allows a client to identify an event handling function for the driver to call back when
queued operation has completed.
Implementation: Dynamic
DRV_SST25VF020B_BlockRead Reads blocks of data starting from the specified address in Flash memory.
Implementation: Dynamic
DRV_SST25VF020B_BlockWrite Write blocks of data starting from a specified address in Flash memory.
Implementation: Dynamic
DRV_SST25VF020B_ClientStatus Gets current client-specific status of the SPI Flash driver.
Implementation: Dynamic
DRV_SST25VF020B_Close Closes an opened-instance of the SPI Flash driver.
Implementation: Dynamic
DRV_SST25VF020B_CommandStatus Gets the current status of the command.
DRV_SST25VF020B_Deinitialize Deinitializes the specified instance of the SPI Flash driver module.
Implementation: Dynamic
DRV_SST25VF020B_GeometryGet Returns the geometry of the device.
Implementation: Dynamic
DRV_SST25VF020B_Initialize Initializes the SST25VF020B SPI Flash Driver instance for the specified driver index.
Implementation: Dynamic
DRV_SST25VF020B_MediaIsAttached Returns the status of the media.
Implementation: Dynamic
DRV_SST25VF020B_Open Opens the specified SPI Flash driver instance and returns a handle to it.
Implementation: Dynamic
DRV_SST25VF020B_Status Gets the current status of the SPI Flash Driver module.
Implementation: Dynamic
DRV_SST25VF020B_Tasks Maintains the driver's read, erase, and write state machine and implements its ISR.
Implementation: Dynamic
Macros
Name Description
DRV_SST25VF020B_BLOCK_COMMAND_HANDLE_INVALID This value defines the SPI Flash Driver Block Command Invalid
handle.
DRV_SST25VF020B_INDEX_0 SPI Flash driver index definitions.
DRV_SST25VF020B_INDEX_1 This is macro DRV_SST25VF020B_INDEX_1.
Structures
Name Description
DRV_SST25VF020B_INIT Contains all the data necessary to initialize the SPI Flash device.
Types
Name Description
DRV_SST25VF020B_BLOCK_COMMAND_HANDLE Handle identifying block commands of the driver.
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 844
DRV_SST25VF020B_EVENT_HANDLER Pointer to a SST25VF020B SPI Flash Driver Event handler function.
Description
SPI Flash Driver Interface Definition
The SPI Flash device driver provides a simple interface to manage the SPI Flash modules which are external to Microchip Controllers. This file
defines the interface definition for the SPI Flash Driver.
File Name
drv_sst25vf020b.h
Company
Microchip Technology Inc.
drv_sst25vf020b_config_template.h
SST25VF020B Driver Configuration Template.
Macros
Name Description
DRV_SST25VF020B_CLIENTS_NUMBER Sets up the maximum number of clients that can be
connected to any hardware instance.
DRV_SST25VF020B_HARDWARE_HOLD_ENABLE Specifies if the hardware hold feature is enabled or not.
DRV_SST25VF020B_HARDWARE_WRITE_PROTECTION_ENABLE Specifies if the hardware write protect feature is enabled or
not.
DRV_SST25VF020B_INSTANCES_NUMBER Sets up the maximum number of hardware instances that
can be supported.
DRV_SST25VF020B_MODE Determines whether the driver is implemented as static or
dynamic.
DRV_SST25VF020B_QUEUE_DEPTH_COMBINED Number of entries of queues in all instances of the driver.
Description
SST25VF020B Driver Configuration Template
These file provides the list of all the configurations that can be used with the driver. This file should not be included in the driver.
File Name
drv_sst25vf020b_config_template.h
Company
Microchip Technology Inc.
drv_sst25vf064c.h
SPI Flash Driver Interface Definition
Enumerations
Name Description
DRV_SST25VF064C_BLOCK_EVENT Identifies the possible events that can result from a request.
DRV_SST25VF064C_CLIENT_STATUS Defines the client status.
DRV_SST25VF064C_COMMAND_STATUS Specifies the status of the command for the read, write and erase operations.
Functions
Name Description
DRV_SST25VF064C_BlockErase Erase the specified number of blocks in Flash memory.
DRV_SST25VF064C_BlockEventHandlerSet Allows a client to identify an event handling function for the driver to call back when
queued operation has completed.
DRV_SST25VF064C_BlockRead Reads blocks of data starting from the specified address in Flash memory.
DRV_SST25VF064C_BlockWrite Write blocks of data starting from a specified address in Flash memory.
DRV_SST25VF064C_ClientStatus Gets current client-specific status of the SPI Flash driver.
DRV_SST25VF064C_Close Closes an opened-instance of the SPI Flash driver.
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 845
DRV_SST25VF064C_CommandStatus Gets the current status of the command.
DRV_SST25VF064C_Deinitialize Deinitializes the specified instance of the SPI Flash driver module.
DRV_SST25VF064C_GeometryGet Returns the geometry of the device.
DRV_SST25VF064C_Initialize Initializes the SST25VF064C SPI Flash Driver instance for the specified driver index.
DRV_SST25VF064C_MediaIsAttached Returns the status of the media.
DRV_SST25VF064C_Open Opens the specified SPI Flash driver instance and returns a handle to it.
DRV_SST25VF064C_Status Gets the current status of the SPI Flash Driver module.
DRV_SST25VF064C_Tasks Maintains the driver's read, erase, and write state machine and implements its ISR.
Macros
Name Description
DRV_SST25VF064C_BLOCK_COMMAND_HANDLE_INVALID This value defines the SPI Flash Driver Block Command Invalid
handle.
DRV_SST25VF064C_INDEX_0 SPI Flash driver index definitions.
DRV_SST25VF064C_INDEX_1 This is macro DRV_SST25VF064C_INDEX_1.
Structures
Name Description
DRV_SST25VF064C_INIT Contains all the data necessary to initialize the SPI Flash device.
Types
Name Description
DRV_SST25VF064C_BLOCK_COMMAND_HANDLE Handle identifying block commands of the driver.
DRV_SST25VF064C_EVENT_HANDLER Pointer to a SST25VF064C SPI Flash Driver Event handler function.
Description
SPI Flash Driver Interface Definition
The SPI Flash device driver provides a simple interface to manage the SPI Flash modules which are external to Microchip Controllers. This file
defines the interface definition for the SPI Flash Driver.
File Name
drv_sst25vf064c.h
Company
Microchip Technology Inc.
drv_sst25vf064c_config_template.h
SST25VF064C Driver Configuration Template.
Macros
Name Description
DRV_SST25VF064C_CLIENTS_NUMBER Sets up the maximum number of clients that can be
connected to any hardware instance.
DRV_SST25VF064C_HARDWARE_HOLD_ENABLE Specifies whether or not the hardware hold feature is
enabled.
DRV_SST25VF064C_HARDWARE_WRITE_PROTECTION_ENABLE Specifies whether or not the hardware write protect feature
is enabled.
DRV_SST25VF064C_INSTANCES_NUMBER Sets up the maximum number of hardware instances that
can be supported.
DRV_SST25VF064C_MODE Determines whether the driver is implemented as static or
dynamic.
DRV_SST25VF064C_QUEUE_DEPTH_COMBINED Number of entries of queues in all instances of the driver.
Description
SST25VF064C Driver Configuration Template
These file provides the list of all the configurations that can be used with the driver. This file should not be included in the driver.
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 846
File Name
drv_sst25vf064c_config_template.h
Company
Microchip Technology Inc.
SPI PIC32WK IPF Flash Driver Library
This section describes the Serial Peripheral Interface (SPI) Flash driver library for the PIC32WK IPF (in-package flash) module.
Introduction
This library provides an interface to manage the PIC32WK IPF module in different modes of operation.
Description
PIC32WK consists of an in-package flash (IPF) that is interfaced to the core using SPI, specifically the SPI0 instance. For more information, refer
to the PIC32WK Silicon Data Sheet. The SPI module of the controller operates as a master device and the IPF module operates as a slave.
The PIC32WK IPF driver is dynamic in nature, therefore a single instance of it can support multiple clients that want to use the same flash. Multiple
instances of the driver can be used when multiple flash devices are required to be part of the system. The SPI driver, which is used by the
PIC32WK IPF driver, can be configured for use in either Polled or Interrupt mode.
Using the Library
This topic describes the basic architecture of the SPI PIC32WK IPF Flash Driver Library and provides information and examples about how to use
it.
Description
Interface Header File: drv_ipf.h
The interface to the SPI PIC32WK IPF Flash Driver Library is defined in the drv_ipf.h header file. Any C language source (.c) file that uses the
SPI PIC32WK IPF Flash Driver Library should include this header file.
Refer to the What is MPLAB Harmony? section for how the driver interacts with the framework.
Library Source Files
The SPI PIC32WK IPF Flash Driver Library source files are provided in the
/framework/driver/spi_flash/pic32wk_ipf/src folder. This folder may contain optional files and alternate
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI PIC32WK IPF Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 847
implementations. Refer to Configuring the Library for instructions about how to select optional features, and Building the Library for instructions
about how to build the library.
Abstraction Model
This section provides a low-level abstraction of the SPI PIC32WK IPF Flash Driver Library with a convenient C language interface. This topic
describes how that abstraction is modeled in software.
Description
To perform a particular operation, the SPI PIC32WK IPF Flash Driver Library needs a specific set of commands to be given on its SPI interface
along with the required address and data. The driver abstracts these requirements and provides simple APIs that can be used to perform Erase,
Write, Read and memory protect operations. The SPI Driver is used for this purpose. The following layered diagram depicts the communication
between different modules.
SPI PIC32WK IPF Flash Driver Library Abstraction Model
Library Overview
Refer to the Driver Library Overview section for information on how the driver operates in a system.
Description
The library interface routines are divided into various sub-sections, which address one of the blocks or the overall operation of the SPI PIC32WK
IPF Flash Driver Library.
Library Interface Section Description
System Functions Accessed by the MPLAB Harmony system module and allow the driver to be
initialized, de-initialized, and maintained.
Core Client Functions Allow the application client to open and close the driver.
Block Operation Functions Enable the Flash module to be erased, written, and read (to/from).
Media Interface Functions Provide media status and the Flash geometry.
Memory Protection Functions Functions protect or unprotect the required block of memory.
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI PIC32WK IPF Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 848
Pin Control Functions Functions provide a means of controlling WP and Hold Pins.
How the Library Works
This topic describes the basic architecture of the SPI PIC32WK IPF Flash Driver Library and provides information and examples about its use.
Description
The library provides interfaces to support:
• System Initialization/Deinitialization
• Opening the Driver
• Block Operations
System Initialization/Deinitialization
This section provides information about initializing the system.
Description
The system performs the initialization of the device driver with settings that affect only the instance of the device that is being initialized. During
system initialization, the SPI PIC32WK IPF Flash Driver is initialized with the following configuration settings (either passed dynamically at runtime
by using DRV_IPF_INIT or by using Initialization Overrides) that are supported or used by the IPF:
• Device-requested power state: one of the System Module Power States. For specific details please refer to "Data Types and Constants" in the
Library Interface section.
• The SPI Driver Module Index, which is intended to be used to communicate with the IPF (for example, DRV_SPI_INDEX_0)
• Port Pins of the microcontroller to be used for Chip Select, Write Protection, and Hold operations on the IPF.
• Maximum Buffer Queue Size for that instance of the IPF.
The DRV_IPF_Initialize function returns an object handle of the type SYS_MODULE_OBJ. After this, the object handle returned by the Initialize
interface is used by the other system interfaces such as DRV_IPF_Deinitialize, DRV_ IPF _Status, and DRV_ IPF _Tasks.
Notes:
1. The system initialization and deinitialization settings affect only the instance of the peripheral that is being initialized or
deinitialized.
2. As Hold, WP, and Chip select pins are internally routed, these are not configurable. Refer to the PIC32WK Silicon Data Sheet
for more information.
Example:
// This code example shows the initialization of the In-Package Flash
// Driver. SPI driver index 0 is used for the purpose. Pin numbers 1, 2,
// and 3 of PORTB are configured for the Hold pin, Write Protection pin, and
// the Chip Select pin, respectively. The maximum buffer queue size is set to 5.
DRV_IPF_INIT IPFInitData;
SYS_MODULE_OBJ objectHandle;
IPFInitData.moduleInit.value = SYS_MODULE_POWER_RUN_FULL;
IPFInitData.spiDriverModuleIndex = DRV_SPI_INDEX_0;
IPFInitData.holdPortChannel = PORT_CHANNEL_K;
IPFInitData.holdBitPosition = PORTS_BIT_POS_14;
IPFInitData.writeProtectPortChannel = PORT_CHANNEL_K;
IPFInitData.writeProtectBitPosition = PORTS_BIT_POS_13;
IPFInitData.chipSelectPortChannel = PORT_CHANNEL_K;
IPFInitData.chipSelectBitPosition = PORTS_BIT_POS_15;
IPFInitData.queueSize = 5;
objectHandle = DRV_IPF_Initialize(DRV_IPF_INDEX_0,(SYS_MODULE_INIT*)IPFInitData);
if (SYS_MODULE_OBJ_INVALID == objectHandle)
{
// Handle error
}
Tasks Routine
The system will call DRV_IPF_Tasks, from SYS_Tasks. .
Opening the Driver
This section provides information about opening the driver.
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI PIC32WK IPF Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 849
Description
To use the SST Flash driver, the application must open the driver. Using the SST25VF020B as an example, this is done by calling the
DRV_IPF_Open function. Calling this function with DRV_IO_INTENT_NONBLOCKING will cause the driver to be opened in non blocking mode.
Then DRV_IPF_BlockErase, DRV_IPF_BlockWrite and DRV_IPF_BlockRead functions when called by this client will be non-blocking.
The client can also open the driver in Read-only mode (DRV_IO_INTENT_READ), Write-only mode (DRV_IO_INTENT_WRITE), and Exclusive
mode (DRV_IO_INTENT_EXCLUSIVE). If the driver has been opened exclusively by a client, it cannot be opened again by another client. If
successful, the DRV_IPF_Open function will return a handle to the driver. This handle records the association between the client and the driver
instance that was opened. The DRV_IPF_Open function may return DRV_HANDLE_INVALID in the situation where the driver is not ready to be
opened. When this occurs, the application can try opening the driver again. Note that the open function may return and invalid handle in other
(error) cases as well.
The following code shows an example of the driver being opened in different modes.
DRV_HANDLE ipfHandle1, ipfHandle2;
/* Client 1 opens the IPF driver in non blocking mode */
ipfHandle1 = DRV_IPF_Open(DRV_IPF_INDEX_0, DRV_IO_INTENT_NONBLOCKING);
/* Check if the handle is valid */
if(DRV_HANDLE_INVALID == ipfHandle1)
{
/* The driver was not opened successfully. The client
* can try opening it again */
}
/* Client 2 opens the IPF driver in Exclusive Write only mode */
ipfHandle2 = DRV_IPF_Open(DRV_IPF_INDEX_0, DRV_IO_INTENT_WRITE | DRV_IO_INTENT_EXCLUSIVE);
/* Check if the handle is valid */
if(DRV_HANDLE_INVALID == ipfHandle2)
{
/* The driver was not opened successfully. The client
* can try opening it again */
}
Block Operations
This section provides information about block operations.
Description
This driver provides simple client interfaces to Erase, Write, and Read the IPF in blocks. A block is the unit to represent minimum amount of data
that can be erased, written, or read. Block size may differ for Erase, Write, and Read operations. The DRV_IPF_GeometryGet function can be
used to determine the different block sizes for the driver.
The DRV_IPF_BlockErase, DRV_IPF_BlockWrite, and DRV_IPF_BlockRead functions are used to erase, write, and read the data to/from IPF.
These functions are always non-blocking. All of these functions follow a standard queue model to read, write, and erase. When any of these
functions are called (i.e., a block request is made), the request is queued. The size of the queue is determined by the queueSize member of the
DRV_IPF_INIT data structure. All of the requests in the queue are executed by the DRV_IPF_Tasks function one-by-one.
When the driver adds a request to the queue, it returns a buffer handle. This handle allows the client to track the request as it progresses through
the queue. The buffer handle expires when the event associated with the buffer completes. The driver provides driver events
(DRV_IPF_BLOCK_EVENT) that indicate termination of the buffer requests.
For a simple Block Data Operation, perform the following steps :
1. The system should have completed necessary initialization of the SPI Driver and the IPF Driver, and the DRV_IPF_Tasks function should be
running in a polled environment.
2. The DRV_SPI_Tasks function should be running in either a polled environment or an interrupt environment.
3. Open the driver using DRV_IPF_Open with the necessary intent.
4. Set an event handler callback using the function DRV_IPF_BlockEventHandlerSet.
5. Request for block operations using the functions, DRV_IPF_BlockErase, DRV_IPF_BlockWrite, and DRV_IPF_BlockRead, with the appropriate
parameters.
6. Wait for event handler callback to occur and check the status of the block operation using the callback function parameter of type
DRV_IPF_BLOCK_EVENT.
7. The client will be able to close the driver using the function, DRV_IPF_Close, when required.
Example:
/* This code example shows usage of the block operations
* on the PIC32WK IPF */
DRV_HANDLE ipfHandle1;
uint8_t myData1[10], myData2[10];
DRV_IPF_BLOCK_COMMAND_HANDLE blockHandle1, blockHandle2, blockHandle3;
/* The driver is opened for read-write in Exclusive mode */
ipfHandle1 = DRV_IPF_Open(DRV_IPF_INDEX_0,
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI PIC32WK IPF Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 850
DRV_IO_INTENT_READWRITE | DRV_IO_INTENT_EXCLUSIVE);
/* Check if the driver was opened successfully */
if(DRV_HANDLE_INVALID == ipfHandle1)
{
/* The driver could not be opened successfully */
}
/* Register a Buffer Event Handler with IPF driver.
* This event handler function will be called whenever
* there is a buffer event. An application defined
* context can also be specified. This is returned when
* the event handler is called.
* */
DRV_IPF_BlockEventHandlerSet(sstHandle1,APP_IPFBufferEventHandler, NULL);
/* Request for all the three block operations one by one */
/* first block API to erase 1 block of the flash starting from address 0x0, each block is of 4kbyte */
DRV_IPF_BlockErase(ipfHandle1, &blockHandle1, 0x0, 1);
/* 2nd block API to write myData1 in the first 10 locations of the flash */
DRV_SST25VF020B_BlockWrite(ipfHandle1, &blockHandle2, &myData1[0], 0x0, 10);
/* 3rd block API to read the first 10 locations of the flash into myData2 */
DRV_SST25VF020B_BlockRead(ipfHandle1, &blockHandle3, &myData2[0], 0x0, 10);
/* This is the Driver Event Handler */
void APP_IPFBufferEventHandler(DRV_SST25VF020B_BLOCK_EVENT event, DRV_SST25VF020B_BLOCK_COMMAND_HANDLE
blockHandle, uintptr_t contextHandle)
{
switch(event)
{
case DRV_IPF_EVENT_BLOCK_COMMAND_COMPLETE:
if ( blockHandle == blockHandle3)
{
/* This means the data was read */
/* Do data verification/processing */
}
break;
case DRV_IPF_EVENT_BLOCK_COMMAND_ERROR:
/* Error handling here. */
break;
default:
break;
}
Configuring the Library
Use this section for the drivers and system services and middleware. This section will contain any related configuration macros imported into the
project from the companion _config_template.h file into this topic, if applicable.
Description
The SPI PIC32WK IPF Flash Driver Library requires the specification of compile-time configuration macros. These macros define resource usage,
feature availability, and dynamic behavior of the driver. These configuration macros should be defined in the system_config.h file.
This header can be placed anywhere, the path of this header needs to be present in the include search path for a successful build. For more
details, refer to Applications Help.
Building the Library
This section lists the files that are available in the SPI PIC32WK IPF Flash Driver Library.
Description
This section list the files that are available in the \src folder of the SPI PIC32WK IPF Flash Driver. It lists which files need to be included in the
build based on either a hardware feature present on the board or configuration option selected by the system.
The following three tables list and describe the header (.h) and source (.c) files that implement this library. The parent folder for these files is
/framework/driver/spi_flash/pic32wk_ipf.
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI PIC32WK IPF Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 851
Interface File(s)
This table lists and describes the header files that must be included (i.e., using #include) by any code that uses this library.
Source File Name Description
/drv_ipf.h Header file that exports the driver API.
Required File(s)
All of the required files listed in the following table are automatically added into the MPLAB X IDE project by the MHC
when the library is selected for use.
This table lists and describes the source and header files that must always be included in the MPLAB X IDE project to build this library.
Source File Name Description
/src/dynamic/drv_ipf.c Basic SPI PIC32WK IPF Flash Driver implementation file.
/src/dynamic/drv_ipf_fs.c File system functions used by the driver API.
/src/drv_ipf_prot.c Protocol implementation used by the driver.
Optional File(s)
This table lists and describes the source and header files that may optionally be included if required for the desired implementation.
Source File Name Description
N/A No optional files are available for this library
Module Dependencies
The SPI PIC32WK IPF Flash Driver Library depends on the following modules:
• Clock System Service Library
Optional Dependencies
• DMA System Service Library (used when operating in DMA mode)
• Interrupt System Service Library (used when task is running in Interrupt mode)
Library Interface
a) System Initialization Functions
Name Description
DRV_IPF_Deinitialize Deinitializes the specified instance of the SPI Flash driver module.
Implementation: Dynamic
DRV_IPF_Initialize Initializes the IPF SPI Flash Driver instance for the specified driver index.
Implementation: Dynamic
DRV_IPF_Status Gets the current status of the SPI Flash Driver module.
Implementation: Dynamic
DRV_IPF_Tasks Maintains the driver's read, erase, and write state machine and implements its ISR.
Implementation: Dynamic
b) Client Setup Functions
Name Description
DRV_IPF_ClientStatus Gets current client-specific status of the SPI Flash driver.
Implementation: Dynamic
DRV_IPF_Close Closes an opened-instance of the SPI Flash driver.
Implementation: Dynamic
DRV_IPF_Open Opens the specified SPI Flash driver instance and returns a handle to it.
Implementation: Dynamic
c) Other Functions
Name Description
DRV_IPF_BlockErase Erase the specified number of blocks in Flash memory.
Implementation: Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI PIC32WK IPF Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 852
DRV_IPF_BlockEventHandlerSet Allows a client to identify an event handling function for the driver to call back when queued
operation has completed.
Implementation: Dynamic
DRV_IPF_BlockRead Reads blocks of data starting from the specified address in Flash memory.
Implementation: Dynamic
DRV_IPF_BlockWrite Write blocks of data starting from a specified address in Flash memory.
Implementation: Dynamic
DRV_IPF_GeometryGet Returns the geometry of the device.
Implementation: Dynamic
DRV_IPF_HoldAssert Asserts the Hold pin for flash.
Implementation: Dynamic
DRV_IPF_HoldDeAssert Deasserts the Hold pin for flash.
Implementation: Dynamic
DRV_IPF_MediaIsAttached Returns the status of the media.
Implementation: Dynamic
DRV_IPF_ProtectMemoryVolatile Protects the memory block to which the given memory address belongs
Implementation: Dynamic
DRV_IPF_ReadBlockProtectionStatus Reads the content of Block Protection Register which belongs to In-Package flash.
Implementation: Dynamic
DRV_IPF_UnProtectMemoryVolatile Un-protects the memory block to which the given memory address belongs
Implementation: Dynamic
DRV_IPF_WPAssert Asserts the WP pin for flash.
Implementation: Dynamic
DRV_IPF_WPDeAssert Deasserts the WP pin for flash.
Implementation: Dynamic
d) Data Types and Constants
Name Description
DRV_IPF_BLOCK_COMMAND_HANDLE Handle identifying block commands of the driver.
DRV_IPF_BLOCK_EVENT Identifies the possible events that can result from a request.
DRV_IPF_BLOCK_OPERATION Lists the different operations that IPF driver can do.
DRV_IPF_CLIENT_STATUS Defines the client status.
Implementation: Dynamic
DRV_IPF_COMMAND_STATUS Specifies the status of the command for the read, write and erase operations.
DRV_IPF_EVENT_HANDLER Pointer to a IPF SPI Flash Driver Event handler function.
Implementation: Dynamic
DRV_IPF_INIT Contains all the data necessary to initialize the SPI Flash device.
Implementation: Dynamic
DRV_IPF_PROT_MODE Lists the different memory protection modes.
_DRV_IPF_H This is macro _DRV_IPF_H.
DRV_IPF_BLOCK_COMMAND_HANDLE_INVALID This value defines the SPI Flash Driver Block Command Invalid handle.
DRV_IPF_INDEX_0 SPI Flash driver index definitions
_DRV_IPF_CONFIG_TEMPLATE_H This is macro _DRV_IPF_CONFIG_TEMPLATE_H.
DRV_IPF_CLIENTS_NUMBER Sets up the maximum number of clients that can be connected to the
hardware instance.
DRV_IPF_INSTANCES_NUMBER Sets up the maximum number of hardware instances that can be supported
DRV_IPF_MODE Determines whether the driver is implemented as static or dynamic
Description
This section describes the API functions of the SPI PIC32WK IPF Flash Driver library.
Refer to each section for a detailed description.
a) System Initialization Functions
DRV_IPF_Deinitialize Function
Deinitializes the specified instance of the SPI Flash driver module.
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI PIC32WK IPF Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 853
Implementation: Dynamic
File
drv_ipf.h
C
void DRV_IPF_Deinitialize(SYS_MODULE_OBJ object);
Returns
None.
Description
Deinitializes the specified instance of the SPI Flash Driver module, disabling its operation (and any hardware) and invalidates all of the internal
data.
Remarks
Once the Initialize operation has been called, the Deinitialize operation must be called before the Initialize operation can be called again. This
function will NEVER block waiting for hardware.
Preconditions
Function DRV_IPF_Initialize should have been called before calling this function.
Example
// This code snippet shows an example of deinitializing the driver.
SYS_MODULE_OBJ object; // Returned from DRV_IPF_Initialize
SYS_STATUS status;
DRV_IPF_Deinitialize(object);
status = DRV_IPF_Status(object);
if (SYS_MODULE_DEINITIALIZED != status)
{
// Check again later if you need to know
// when the driver is deinitialized.
}
Parameters
Parameters Description
object Driver object handle, returned from the DRV_IPF_Initialize
Function
void DRV_IPF_Deinitialize( SYS_MODULE_OBJ object )
DRV_IPF_Initialize Function
Initializes the IPF SPI Flash Driver instance for the specified driver index.
Implementation: Dynamic
File
drv_ipf.h
C
SYS_MODULE_OBJ DRV_IPF_Initialize(const SYS_MODULE_INDEX index, const SYS_MODULE_INIT * const init);
Returns
If successful, returns a valid handle to a driver instance object. Otherwise, it returns SYS_MODULE_OBJ_INVALID.
Description
This function initializes the SPI Flash driver instance for the specified driver index, making it ready for clients to open and use it.
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI PIC32WK IPF Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 854
Remarks
This function must be called before any other SPI Flash function is called.
This function should only be called once during system initialization unless DRV_IPF_Deinitialize is called to deinitialize the driver instance.
Build configuration options may be used to statically override options in the "init" structure and will take precedence over initialization data passed
using this function.
Preconditions
None.
Example
// This code snippet shows an example of initializing the IPF SPI
// Flash Driver. SPI driver index 0 is used for the purpose. Pin numbers 1, 2
// and 3 of port channel B are configured for hold pin, write protection pin
// and chip select pin respectively. Maximum buffer queue size is set 5.
DRV_IPF_INIT IPFInitData;
SYS_MODULE_OBJ objectHandle;
IPFInitData.moduleInit.value = SYS_MODULE_POWER_RUN_FULL;
IPFInitData.spiDriverModuleIndex = DRV_SPI_INDEX_0;
IPFInitData.holdPortChannel = PORT_CHANNEL_B;
IPFInitData.holdBitPosition = PORTS_BIT_POS_1;
IPFInitData.writeProtectPortChannel = PORT_CHANNEL_B;
IPFInitData.writeProtectBitPosition = PORTS_BIT_POS_2;
IPFInitData.chipSelectPortChannel = PORT_CHANNEL_F;
IPFInitData.chipSelectBitPosition = PORTS_BIT_POS_2;
IPFInitData.queueSize = 5;
objectHandle = DRV_IPF_Initialize(DRV_IPF_INDEX_0,
(SYS_MODULE_INIT*)IPFInitData);
if (SYS_MODULE_OBJ_INVALID == objectHandle)
{
// Handle error
}
Parameters
Parameters Description
index Identifier for the instance to be initialized
init Pointer to a data structure containing data necessary to initialize the driver.
Function
SYS_MODULE_OBJ DRV_IPF_Initialize
(
const SYS_MODULE_INDEX index,
const SYS_MODULE_INIT * const init
);
DRV_IPF_Status Function
Gets the current status of the SPI Flash Driver module.
Implementation: Dynamic
File
drv_ipf.h
C
SYS_STATUS DRV_IPF_Status(SYS_MODULE_OBJ object);
Returns
SYS_STATUS_READY - Indicates that the driver is ready and accept requests for new operations
SYS_STATUS_UNINITIALIZED - Indicates that the driver is not initialized
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI PIC32WK IPF Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 855
Description
This function provides the current status of the SPI Flash Driver module.
Remarks
A driver can only be opened when its status is SYS_STATUS_READY.
Preconditions
Function DRV_IPF_Initialize should have been called before calling this function.
Example
SYS_MODULE_OBJ object; // Returned from DRV_IPF_Initialize
SYS_STATUS IPFStatus;
IPFStatus = DRV_IPF_Status(object);
else if (SYS_STATUS_ERROR >= IPFStatus)
{
// Handle error
}
Parameters
Parameters Description
object Driver object handle, returned from the DRV_IPF_Initialize
Function
SYS_STATUS DRV_IPF_Status( SYS_MODULE_OBJ object )
DRV_IPF_Tasks Function
Maintains the driver's read, erase, and write state machine and implements its ISR.
Implementation: Dynamic
File
drv_ipf.h
C
void DRV_IPF_Tasks(SYS_MODULE_OBJ object);
Returns
None.
Description
This function is used to maintain the driver's internal state machine and should be called from the system's Tasks function.
Remarks
This function is normally not called directly by an application. It is called by the system's Tasks function (SYS_Tasks).
Preconditions
The DRV_IPF_Initialize function must have been called for the specified SPI Flash driver instance.
Example
SYS_MODULE_OBJ object; // Returned from DRV_IPF_Initialize
while (true)
{
DRV_IPF_Tasks (object);
// Do other tasks
}
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI PIC32WK IPF Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 856
Parameters
Parameters Description
object Object handle for the specified driver instance (returned from DRV_IPF_Initialize)
Function
void DRV_IPF_Tasks ( SYS_MODULE_OBJ object );
b) Client Setup Functions
DRV_IPF_ClientStatus Function
Gets current client-specific status of the SPI Flash driver.
Implementation: Dynamic
File
drv_ipf.h
C
DRV_IPF_CLIENT_STATUS DRV_IPF_ClientStatus(const DRV_HANDLE handle);
Returns
A DRV_IPF_CLIENT_STATUS value describing the current status of the driver.
Description
This function gets the client-specific status of the SPI Flash driver associated with the given handle.
Remarks
This function will not block for hardware access and will immediately return the current status.
Preconditions
The DRV_IPF_Initialize function must have been called.
DRV_IPF_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE handle; // Returned from DRV_IPF_Open
DRV_IPF_CLIENT_STATUS clientStatus;
clientStatus = DRV_IPF_ClientStatus(handle);
if(DRV_IPF_CLIENT_STATUS_READY == clientStatus)
{
// do the tasks
}
Parameters
Parameters Description
handle A valid open instance handle, returned from the driver's open
Function
DRV_IPF_CLIENT_STATUS DRV_IPF_ClientStatus(DRV_HANDLE handle);
DRV_IPF_Close Function
Closes an opened-instance of the SPI Flash driver.
Implementation: Dynamic
File
drv_ipf.h
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI PIC32WK IPF Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 857
C
void DRV_IPF_Close(const DRV_HANDLE handle);
Returns
None.
Description
This function closes an opened-instance of the SPI Flash driver, invalidating the handle.
Remarks
After calling this function, the handle passed in "handle" must not be used with any of the remaining driver routines. A new handle must be
obtained by calling DRV_IPF_Open before the caller may use the driver again.
Usually, there is no need for the driver client to verify that the Close operation has completed.
Preconditions
The DRV_IPF_Initialize function must have been called for the specified SPI Flash driver instance.
DRV_IPF_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE handle; // Returned from DRV_IPF_Open
DRV_IPF_Close(handle);
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
Function
void DRV_IPF_Close( DRV_Handle handle );
DRV_IPF_Open Function
Opens the specified SPI Flash driver instance and returns a handle to it.
Implementation: Dynamic
File
drv_ipf.h
C
DRV_HANDLE DRV_IPF_Open(const SYS_MODULE_INDEX drvIndex, const DRV_IO_INTENT ioIntent);
Returns
If successful, the function returns a valid open-instance handle (a number identifying both the caller and the module instance).
If an error occurs, the return value is DRV_HANDLE_INVALID. Errors can occur under the following circumstances:
• if the number of client objects allocated via DRV_IPF_CLIENTS_NUMBER is insufficient
• if the client is trying to open the driver but driver has been opened exclusively by another client
• if the driver hardware instance being opened is not initialized or is invalid
• if the client is trying to open the driver exclusively, but has already been opened in a non exclusive mode by another client.
• if the driver status is not ready.
The driver status becomes ready inside "DRV_IPF_Tasks" function. To make the SST Driver status ready and hence successfully "Open" the
driver, "Task" routine need to be called periodically.
Description
This function opens the specified SPI Flash driver instance and provides a handle that must be provided to all other client-level operations to
identify the caller and the instance of the driver.
Remarks
The driver will always work in Non-Blocking mode even if IO-intent is selected as blocking.
The handle returned is valid until the DRV_IPF_Close function is called.
This function will NEVER block waiting for hardware.
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI PIC32WK IPF Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 858
Preconditions
Function DRV_IPF_Initialize must have been called before calling this function.
Example
DRV_HANDLE handle;
handle = DRV_IPF_Open(DRV_IPF_INDEX_0,
DRV_IO_INTENT_EXCLUSIVE);
if (DRV_HANDLE_INVALID == handle)
{
// Unable to open the driver
}
Parameters
Parameters Description
drvIndex Identifier for the object instance to be opened
ioIntent Zero or more of the values from the enumeration DRV_IO_INTENT "ORed" together to
indicate the intended use of the driver
Function
DRV_HANDLE DRV_IPF_Open
(
const SYS_MODULE_INDEX drvIndex,
const DRV_IO_INTENT ioIntent
);
c) Other Functions
DRV_IPF_BlockErase Function
Erase the specified number of blocks in Flash memory.
Implementation: Dynamic
File
drv_ipf.h
C
void DRV_IPF_BlockErase(const DRV_HANDLE handle, DRV_IPF_BLOCK_COMMAND_HANDLE * commandHandle, uint32_t
blockStart, uint32_t nBlock);
Returns
The buffer handle is returned in the commandHandle argument. It Will be DRV_BUFFER_HANDLE_INVALID if the request was not queued.
Description
This function schedules a non-blocking erase operation in flash memory. The function returns with a valid erase handle in the commandHandle
argument if the erase request was scheduled successfully. The function adds the request to the hardware instance queue and returns
immediately. The function returns DRV_IPF_BLOCK_COMMAND_HANDLE_INVALID in the commandHandle argument under the following
circumstances:
• if the client opened the driver for read only
• if nBlock is 0
• if the queue size is full or queue depth is insufficient
• if the driver handle is invalid
If the requesting client registered an event callback with the driver, the driver will issue a DRV_IPF_EVENT_ERASE_COMPLETE event if the
erase operation was successful or DRV_IPF_EVENT_ERASE_ERROR event if the erase operation was not successful.
Remarks
Write Protection will be disabled for the complete flash memory region in the beginning by default.
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI PIC32WK IPF Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 859
Preconditions
The DRV_IPF_Initialize function must have been called for the specified SPI Flash driver instance.
DRV_IPF_Open must have been called to obtain a valid opened device handle.
DRV_IO_INTENT_WRITE or DRV_IO_INTENT_READWRITE must have been specified in the DRV_IPF_Open call.
Example
// Destination address should be block aligned.
uint32_t blockStart;
uint32_t nBlock;
DRV_IPF_BLOCK_COMMAND_HANDLE commandHandle;
MY_APP_OBJ myAppObj;
// myIPFHandle is the handle returned
// by the DRV_IPF_Open function.
// Client registers an event handler with driver
DRV_IPF_BlockEventHandlerSet(myIPFHandle,
APP_IPFEventHandler, (uintptr_t)&myAppObj);
DRV_IPF_BlockErase( myIPFHandle, commandHandle,
blockStart, nBlock );
if(DRV_IPF_BLOCK_COMMAND_HANDLE_INVALID == commandHandle)
{
// Error handling here
}
// Event is received when
// the buffer queue is processed.
void APP_IPFEventHandler(DRV_IPF_BLOCK_EVENT event,
DRV_IPF_BLOCK_COMMAND_HANDLE commandHandle, uintptr_t contextHandle)
{
// contextHandle points to myAppObj.
switch(event)
{
case DRV_IPF_EVENT_ERASE_COMPLETE:
// This means the data was transferred.
break;
case DRV_IPF_EVENT_ERASE_ERROR:
// Error handling here.
break;
default:
break;
}
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
commandHandle Pointer to an argument that will contain the return buffer handle
blockStart Start block address in IPF memory from where the erase should begin. LSBs (A0-A11) of
block start address will be ignored to align it with Erase block size boundary.
nBlock Total number of blocks to be erased. Each Erase block is of size 4 KByte.
Function
void DRV_IPF_BlockErase
(
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI PIC32WK IPF Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 860
const DRV_HANDLE handle,
DRV_IPF_BLOCK_COMMAND_HANDLE * commandHandle,
uint32_t blockStart,
uint32_t nBlock
);
DRV_IPF_BlockEventHandlerSet Function
Allows a client to identify an event handling function for the driver to call back when queued operation has completed.
Implementation: Dynamic
File
drv_ipf.h
C
void DRV_IPF_BlockEventHandlerSet(const DRV_HANDLE handle, const DRV_IPF_EVENT_HANDLER eventHandler, const
uintptr_t context);
Returns
None.
Description
This function allows a client to identify an event handling function for the driver to call back when queued operation has completed. When a client
calls any read, write or erase function, it is provided with a handle identifying the buffer that was added to the driver's buffer queue. The driver will
pass this handle back to the client by calling "eventHandler" function when the queued operation has completed.
The event handler should be set before the client performs any read/write/erase operations that could generate events. The event handler once
set, persists until the client closes the driver or sets another event handler (which could be a "NULL" pointer to indicate no callback).
Remarks
If the client does not want to be notified when the queued operation has completed, it does not need to register a callback.
Preconditions
The DRV_IPF_Initialize function must have been called for the specified SPI FLash driver instance.
DRV_IPF_Open must have been called to obtain a valid opened device handle.
Example
// myAppObj is an application specific state data object.
MY_APP_OBJ myAppObj;
uint8_t myBuffer[MY_BUFFER_SIZE];
uint32_t blockStart, nBlock;
DRV_IPF_BLOCK_COMMAND_HANDLE commandHandle;
// myIPFHandle is the handle returned
// by the DRV_IPF_Open function.
// Client registers an event handler with driver. This is done once.
DRV_IPF_BlockEventHandlerSet( myIPFHandle,
APP_IPFEventHandler, (uintptr_t)&myAppObj );
DRV_IPF_BlockRead( myIPFHandle, commandHandle,
&myBuffer, blockStart, nBlock );
if(DRV_IPF_BLOCK_COMMAND_HANDLE_INVALID == commandHandle)
{
// Error handling here
}
// Event Processing Technique. Event is received when operation is done.
void APP_IPFEventHandler(DRV_IPF_BLOCK_EVENT event,
DRV_IPF_BLOCK_COMMAND_HANDLE handle, uintptr_t context)
{
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI PIC32WK IPF Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 861
// The context handle was set to an application specific
// object. It is now retrievable easily in the event handler.
MY_APP_OBJ myAppObj = (MY_APP_OBJ *) context;
switch(event)
{
case DRV_IPF_EVENT_BLOCK_COMMAND_COMPLETE:
// This means the data was transferred.
break;
case DRV_IPF_EVENT_BLOCK_COMMAND_ERROR:
// Error handling here.
break;
default:
break;
}
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
eventHandler Pointer to the event handler function implemented by the user
context The value of parameter will be passed back to the client unchanged, when the eventHandler
function is called. It can be used to identify any client specific data object that identifies the
instance of the client module (for example, it may be a pointer to the client module's state
structure).
Function
void DRV_IPF_BlockEventHandlerSet
(
const DRV_HANDLE handle,
const DRV_IPF_EVENT_HANDLER eventHandler,
const uintptr_t context
);
DRV_IPF_BlockRead Function
Reads blocks of data starting from the specified address in Flash memory.
Implementation: Dynamic
File
drv_ipf.h
C
void DRV_IPF_BlockRead(const DRV_HANDLE handle, DRV_IPF_BLOCK_COMMAND_HANDLE * commandHandle, uint8_t *
targetBuffer, uint32_t blockStart, uint32_t nBlock);
Returns
The buffer handle is returned in the commandHandle argument. It will be DRV_BUFFER_HANDLE_INVALID if the request was not successful.
Description
This function schedules a non-blocking read operation for reading blocks of data from flash memory. The function returns with a valid handle in the
commandHandle argument if the read request was scheduled successfully. The function adds the request to the hardware instance queue and
returns immediately. While the request is in the queue, the application buffer is owned by the driver and should not be modified. The function
returns DRV_IPF_BLOCK_COMMAND_HANDLE_INVALID in the commandHandle argument under the following circumstances:
• if a buffer could not be allocated to the request
• if the target buffer pointer is NULL
• if the client opened the driver for write only
• if the buffer size is 0
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI PIC32WK IPF Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 862
• if the read queue size is full or queue depth is insufficient
• if the driver handle is invalid
If the requesting client registered an event callback with the driver, the driver will issue a DRV_IPF_EVENT_BLOCK_COMMAND_COMPLETE
event if the buffer was processed successfully of DRV_IPF_EVENT_BLOCK_COMMAND_ERROR event if the buffer was not processed
successfully.
Remarks
The maximum read speed is 33 MHz.
Preconditions
The DRV_IPF_Initialize function must have been called for the specified SPI Flash driver instance.
DRV_IPF_Open must have been called to obtain a valid opened device handle.
DRV_IO_INTENT_READ or DRV_IO_INTENT_READWRITE must have been specified in the DRV_IPF_Open call.
Example
uint8_t myBuffer[MY_BUFFER_SIZE];
// address should be block aligned.
uint32_t blockStart = IPF_BASE_ADDRESS_TO_READ_FROM;
uint32_t nBlock = 2;
DRV_IPF_BLOCK_COMMAND_HANDLE commandHandle;
MY_APP_OBJ myAppObj;
// myIPFHandle is the handle returned
// by the DRV_IPF_Open function.
// Client registers an event handler with driver
DRV_IPF_BlockEventHandlerSet(myIPFHandle,
APP_IPFEventHandler, (uintptr_t)&myAppObj);
DRV_IPF_BlockRead( myIPFHandle, commandHandle,
&myBuffer, blockStart, nBlock );
if(DRV_IPF_BLOCK_COMMAND_HANDLE_INVALID == commandHandle)
{
// Error handling here
}
// Event is received when the buffer is processed.
void APP_IPFEventHandler(DRV_IPF_BLOCK_EVENT event,
DRV_IPF_BLOCK_COMMAND_HANDLE commandHandle, uintptr_t contextHandle)
{
// contextHandle points to myAppObj.
switch(event)
{
case DRV_IPF_EVENT_BLOCK_COMMAND_COMPLETE:
// This means the data was transferred.
break;
case DRV_IPF_EVENT_BLOCK_COMMAND_ERROR:
// Error handling here.
break;
default:
break;
}
}
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI PIC32WK IPF Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 863
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
commandHandle Pointer to an argument that will contain the return buffer handle
*targetBuffer Buffer into which the data read from the SPI Flash instance will be placed
blockStart Start block address in IPF memory from where the read should begin. It can be any address
of the flash.
nBlock Total number of blocks to be read. Each Read block is of 1 byte.
Function
void DRV_IPF_BlockRead
(
const DRV_HANDLE handle,
DRV_IPF_BLOCK_COMMAND_HANDLE * commandHandle,
uint8_t *targetBuffer,
uint32_t blockStart,
uint32_t nBlock
);
DRV_IPF_BlockWrite Function
Write blocks of data starting from a specified address in Flash memory.
Implementation: Dynamic
File
drv_ipf.h
C
void DRV_IPF_BlockWrite(DRV_HANDLE handle, DRV_IPF_BLOCK_COMMAND_HANDLE * commandHandle, uint8_t *
sourceBuffer, uint32_t blockStart, uint32_t nBlock);
Returns
The buffer handle is returned in the commandHandle argument. It will be DRV_BUFFER_HANDLE_INVALID if the request was not successful.
Description
This function schedules a non-blocking write operation for writing blocks of data into flash memory. The function returns with a valid buffer handle
in the commandHandle argument if the write request was scheduled successfully. The function adds the request to the hardware instance queue
and returns immediately. While the request is in the queue, the application buffer is owned by the driver and should not be modified. The function
returns DRV_IPF_BLOCK_COMMAND_HANDLE_INVALID in the commandHandle argument under the following circumstances:
• if a buffer could not be allocated to the request
• if the input buffer pointer is NULL
• if the client opened the driver for read only
• if the buffer size is 0
• if the write queue size is full or queue depth is insufficient
• if the driver handle is invalid
If the requesting client registered an event callback with the driver, the driver will issue a DRV_IPF_EVENT_BLOCK_COMMAND_COMPLETE
event if the buffer was processed successfully or DRV_IPF_EVENT_BLOCK_COMMAND_ERROR event if the buffer was not processed
successfully.
Remarks
In the case of multi bytes write operation, byte by byte writing will happen instead of Address auto Increment writing.
Write Protection will be disabled for the complete flash memory region in the beginning by default.
Preconditions
The DRV_IPF_Initialize function must have been called for the specified SPI Flash driver instance.
DRV_IPF_Open must have been called to obtain a valid opened device handle.
DRV_IO_INTENT_WRITE or DRV_IO_INTENT_READWRITE must have been specified in the DRV_IPF_Open call.
The flash address location which has to be written, must be erased before using the API DRV_IPF_BlockErase().
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI PIC32WK IPF Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 864
Example
uint8_t myBuffer[MY_BUFFER_SIZE];
// address should be block aligned.
uint32_t blockStart = IPF_BASE_ADDRESS_TO_WRITE_TO;
uint32_t nBlock = 2;
DRV_IPF_BLOCK_COMMAND_HANDLE commandHandle;
MY_APP_OBJ myAppObj;
// myIPFHandle is the handle returned
// by the DRV_IPF_Open function.
// Client registers an event handler with driver
DRV_IPF_BlockEventHandlerSet(myIPFHandle,
APP_IPFEventHandler, (uintptr_t)&myAppObj);
DRV_IPF_BlockWrite( myIPFHandle, commandHandle,
&myBuffer, blockStart, nBlock );
if(DRV_IPF_BLOCK_COMMAND_HANDLE_INVALID == commandHandle)
{
// Error handling here
}
// Event is received when
// the buffer is processed.
void APP_IPFEventHandler(DRV_IPF_BLOCK_EVENT event,
DRV_IPF_BLOCK_COMMAND_HANDLE commandHandle, uintptr_t contextHandle)
{
// contextHandle points to myAppObj.
switch(event)
{
case DRV_IPF_EVENT_BLOCK_COMMAND_COMPLETE:
// This means the data was transferred.
break;
case DRV_IPF_EVENT_BLOCK_COMMAND_ERROR:
// Error handling here.
break;
default:
break;
}
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
commandHandle -Pointer to an argument that will contain the return buffer handle
sourceBuffer The source buffer containing data to be programmed into SPI Flash
blockStart Start block address of IPF Flash where the write should begin. It can be any address of the
flash.
nBlock Total number of blocks to be written. Each write block is of 1 byte.
Function
void DRV_IPF_BlockWrite
(
DRV_HANDLE handle,
DRV_IPF_BLOCK_COMMAND_HANDLE * commandHandle,
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI PIC32WK IPF Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 865
uint8_t *sourceBuffer,
uint32_t blockStart,
uint32_t nBlock
);
DRV_IPF_GeometryGet Function
Returns the geometry of the device.
Implementation: Dynamic
File
drv_ipf.h
C
SYS_FS_MEDIA_GEOMETRY * DRV_IPF_GeometryGet(DRV_HANDLE handle);
Returns
SYS_FS_MEDIA_GEOMETRY - Structure which holds the media geometry information.
Description
This API gives the following geometrical details of the IPF Flash:
• Media Property
• Number of Read/Write/Erase regions in the flash device
• Number of Blocks and their size in each region of the device
Remarks
This function is typically used by File System Media Manager.
Preconditions
None.
Example
SYS_FS_MEDIA_GEOMETRY * sstFlashGeometry;
uint32_t readBlockSize, writeBlockSize, eraseBlockSize;
uint32_t nReadBlocks, nReadRegions, totalFlashSize;
sstFlashGeometry = DRV_IPF_GeometryGet(sstOpenHandle1);
// read block size should be 1 byte
readBlockSize = sstFlashGeometry->geometryTable->blockSize;
nReadBlocks = sstFlashGeometry->geometryTable->numBlocks;
nReadRegions = sstFlashGeometry->numReadRegions;
// write block size should be 1 byte
writeBlockSize = (sstFlashGeometry->geometryTable +1)->blockSize;
// erase block size should be 4k byte
eraseBlockSize = (sstFlashGeometry->geometryTable +2)->blockSize;
// total flash size should be 256k byte
totalFlashSize = readBlockSize * nReadBlocks * nReadRegions;
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
Function
SYS_FS_MEDIA_GEOMETRY DRV_IPF_GeometryGet( DRV_HANDLE handle );
DRV_IPF_HoldAssert Function
Asserts the Hold pin for flash.
Implementation: Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI PIC32WK IPF Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 866
File
drv_ipf.h
C
void DRV_IPF_HoldAssert();
Returns
None.
Description
This API is used to assert the Hold pin of the in-package flash.
Remarks
The Hold GPIO is fixed in case of PIC32WK devices.
Preconditions
None.
Example
DRV_IPF_HoldAssert();
Function
void DRV_IPF_HoldAssert();
DRV_IPF_HoldDeAssert Function
Deasserts the Hold pin for flash.
Implementation: Dynamic
File
drv_ipf.h
C
void DRV_IPF_HoldDeAssert();
Returns
None.
Description
This API is used to deassert the Hold pin of the in-package flash.
Remarks
The Hold GPIO is fixed in case of PIC32WK devices.
Preconditions
None.
Example
DRV_IPF_HoldDeAssert();
Function
void DRV_IPF_HoldDeAssert();
DRV_IPF_MediaIsAttached Function
Returns the status of the media.
Implementation: Dynamic
File
drv_ipf.h
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI PIC32WK IPF Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 867
C
bool DRV_IPF_MediaIsAttached(DRV_HANDLE handle);
Returns
• True - Media is attached
• False - Media is not attached
Description
This API tells if the media is attached or not.
Remarks
This function is typically used by File System Media Manager.
Preconditions
None.
Example
if (DRV_IPF_MediaIsAttached(handle))
{
// Do Something
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
Function
bool DRV_IPF_MediaIsAttached( DRV_HANDLE handle);
DRV_IPF_ProtectMemoryVolatile Function
Protects the memory block to which the given memory address belongs
Implementation: Dynamic
File
drv_ipf.h
C
void DRV_IPF_ProtectMemoryVolatile(DRV_HANDLE clientHandle, DRV_IPF_BLOCK_COMMAND_HANDLE * commandHandle,
uintptr_t memAddress, DRV_IPF_PROT_MODE protMode);
Returns
None.
Description
This API is used to protect the memory block to which a given memory address belongs. Both read and write protection mode is supported. The
memory will be protected until the next power cycle.
Remarks
Only the selected blocks can be read protected, which is as per the in-package flash specification.
Preconditions
In-package flash driver open function must be called and a valid client handle must be available.
Example
uintptr_t memAddr = IPF_ADDRESS_PROTECT;
DRV_IPF_PROT_MODE protMode = DRV_IPF_WRITE_PROTECT;
DRV_IPF_BLOCK_COMMAND_HANDLE commandHandle;
MY_APP_OBJ myAppObj;
// myIPFHandle is the handle returned
// by the DRV_IPF_Open function.
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI PIC32WK IPF Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 868
// Client registers an event handler with driver
DRV_IPF_BlockEventHandlerSet(myIPFHandle,
APP_IPFEventHandler, (uintptr_t)&myAppObj);
DRV_IPF_ProtectMemoryVolatile( myIPFHandle, commandHandle,
memAddr, protMode );
if(DRV_IPF_BLOCK_COMMAND_HANDLE_INVALID == commandHandle)
{
// Error handling here
}
// Event is received when
// the buffer is processed.
void APP_IPFEventHandler(DRV_IPF_BLOCK_EVENT event,
DRV_IPF_BLOCK_COMMAND_HANDLE commandHandle, uintptr_t contextHandle)
{
// contextHandle points to myAppObj.
switch(event)
{
case DRV_IPF_EVENT_BLOCK_COMMAND_COMPLETE:
// This means the memory protection is complete.
break;
case DRV_IPF_EVENT_BLOCK_COMMAND_ERROR:
// Error handling here.
break;
default:
break;
}
}
Parameters
Parameters Description
clientHandle A valid open-instance handle, returned from the driver's open function
commandHandle Pointer to an argument that will contain the return buffer handle
memAddress Memory address which belongs to the memory block which needs to be protected
protMode Read or write protect mode. If a block needs to be protected for both read and write, then both
enum values can be ORed and passed to the function.
Function
void DRV_IPF_ProtectMemoryVolatile
(
DRV_HANDLE clientHandle,
DRV_IPF_BLOCK_COMMAND_HANDLE * commandHandle,
uintptr_t memAddress,
DRV_IPF_PROT_MODE protMode
);
DRV_IPF_ReadBlockProtectionStatus Function
Reads the content of Block Protection Register which belongs to In-Package flash.
Implementation: Dynamic
File
drv_ipf.h
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI PIC32WK IPF Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 869
C
void DRV_IPF_ReadBlockProtectionStatus(DRV_HANDLE clientHandle, DRV_IPF_BLOCK_COMMAND_HANDLE *
commandHandle, uint8_t * buffer);
Returns
None.
Description
This API is read the current contents of the block protection register in in-package flash and fills the buffer passed by the client.
Remarks
The block protection word is 6-bytes wide.
Preconditions
In-package flash driver open function must be called and a valid client handle must be available.
Example
uint8_t buf[6] = {0,};
DRV_IPF_BLOCK_COMMAND_HANDLE commandHandle;
MY_APP_OBJ myAppObj;
// myIPFHandle is the handle returned
// by the DRV_IPF_Open function.
// Client registers an event handler with driver
DRV_IPF_BlockEventHandlerSet(myIPFHandle,
APP_IPFEventHandler, (uintptr_t)&myAppObj);
DRV_IPF_ReadBlockProtectionStatus( myIPFHandle, commandHandle,
buf );
if(DRV_IPF_BLOCK_COMMAND_HANDLE_INVALID == commandHandle)
{
// Error handling here
}
// Event is received when
// the buffer is processed.
void APP_IPFEventHandler(DRV_IPF_BLOCK_EVENT event,
DRV_IPF_BLOCK_COMMAND_HANDLE commandHandle, uintptr_t contextHandle)
{
// contextHandle points to myAppObj.
switch(event)
{
case DRV_IPF_EVENT_BLOCK_COMMAND_COMPLETE:
// This means the BPR read is complete.
break;
case DRV_IPF_EVENT_BLOCK_COMMAND_ERROR:
// Error handling here.
break;
default:
break;
}
}
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI PIC32WK IPF Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 870
Parameters
Parameters Description
clientHandle A valid open-instance handle, returned from the driver's open function
commandHandle Pointer to an argument that will contain the return buffer handle
buffer pointer to a buffer to which the block protection status has to be updated
Function
void DRV_IPF_ReadBlockProtectionStatus
(
DRV_HANDLE clientHandle,
DRV_IPF_BLOCK_COMMAND_HANDLE * commandHandle,
uint8_t * buffer
);
DRV_IPF_UnProtectMemoryVolatile Function
Un-protects the memory block to which the given memory address belongs
Implementation: Dynamic
File
drv_ipf.h
C
void DRV_IPF_UnProtectMemoryVolatile(DRV_HANDLE clientHandle, DRV_IPF_BLOCK_COMMAND_HANDLE * commandHandle,
uintptr_t memAddress, DRV_IPF_PROT_MODE protMode);
Returns
None.
Description
This API is used to un-protect the memory block to which a given memory address belongs. Both read and write protection mode is supported.
The memory will be protected until the next power cycle.
Remarks
If the memory block a client is trying to unprotect, is protected by some other client, then memory unprotection will not executed. The function will
return without unprotecting.
Preconditions
In-package flash driver open function must be called and a valid client handle must be available.
Example
uintptr_t memAddr = IPF_ADDRESS_UNPROTECT;
DRV_IPF_PROT_MODE protMode = DRV_IPF_WRITE_PROTECT;
DRV_IPF_BLOCK_COMMAND_HANDLE commandHandle;
MY_APP_OBJ myAppObj;
// myIPFHandle is the handle returned
// by the DRV_IPF_Open function.
// Client registers an event handler with driver
DRV_IPF_BlockEventHandlerSet(myIPFHandle,
APP_IPFEventHandler, (uintptr_t)&myAppObj);
DRV_IPF_UnProtectMemoryVolatile( myIPFHandle, commandHandle,
memAddr, protMode );
if(DRV_IPF_BLOCK_COMMAND_HANDLE_INVALID == commandHandle)
{
// Error handling here
}
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI PIC32WK IPF Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 871
// Event is received when
// the buffer is processed.
void APP_IPFEventHandler(DRV_IPF_BLOCK_EVENT event,
DRV_IPF_BLOCK_COMMAND_HANDLE commandHandle, uintptr_t contextHandle)
{
// contextHandle points to myAppObj.
switch(event)
{
case DRV_IPF_EVENT_BLOCK_COMMAND_COMPLETE:
// This means the memory unprotection is complete.
break;
case DRV_IPF_EVENT_BLOCK_COMMAND_ERROR:
// Error handling here.
break;
default:
break;
}
}
Parameters
Parameters Description
clientHandle A valid open-instance handle, returned from the driver's open function
commandHandle Pointer to an argument that will contain the return buffer handle
memAddress Memory address which belongs to the memory block which needs to be un-protected
protMode Read or write protect mode. If a block needs to be un-protected for both read and write, then
both enum values can be ORed and passed to the function.
Function
void DRV_IPF_UnProtectMemoryVolatile
(
DRV_HANDLE clientHandle,
DRV_IPF_BLOCK_COMMAND_HANDLE * commandHandle,
uintptr_t memAddress,
DRV_IPF_PROT_MODE protMode
);
DRV_IPF_WPAssert Function
Asserts the WP pin for flash.
Implementation: Dynamic
File
drv_ipf.h
C
void DRV_IPF_WPAssert();
Returns
None.
Description
This API is used to assert the Write Protect (WP) pin of the in-package flash.
Remarks
The Write Protection GPIO is fixed in case of PIC32WK devices.
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI PIC32WK IPF Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 872
Preconditions
None.
Example
DRV_IPF_WPAssert();
Function
void DRV_IPF_WPAssert();
DRV_IPF_WPDeAssert Function
Deasserts the WP pin for flash.
Implementation: Dynamic
File
drv_ipf.h
C
void DRV_IPF_WPDeAssert();
Returns
None.
Description
This API is used to deassert the Write Protect (WP) pin of the in-package flash.
Remarks
The Write Protection GPIO is fixed in case of PIC32WK devices.
Preconditions
None.
Example
DRV_IPF_WPDeAssert();
Function
void DRV_IPF_WPAssert();
d) Data Types and Constants
DRV_IPF_BLOCK_COMMAND_HANDLE Type
Handle identifying block commands of the driver.
File
drv_ipf.h
C
typedef SYS_FS_MEDIA_BLOCK_COMMAND_HANDLE DRV_IPF_BLOCK_COMMAND_HANDLE;
Description
SPI Flash Driver Block Command Handle
A block command handle is returned by a call to the Read, Write, or Erase functions. This handle allows the application to track the completion of
the operation. The handle is returned back to the client by the "event handler callback" function registered with the driver.
The handle assigned to a client request expires when the client has been notified of the completion of the operation (after event handler function
that notifies the client returns) or after the buffer has been retired by the driver if no event handler callback was set.
Remarks
None.
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI PIC32WK IPF Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 873
DRV_IPF_BLOCK_EVENT Enumeration
Identifies the possible events that can result from a request.
File
drv_ipf.h
C
typedef enum {
DRV_IPF_EVENT_BLOCK_COMMAND_COMPLETE,
DRV_IPF_EVENT_BLOCK_COMMAND_ERROR
} DRV_IPF_BLOCK_EVENT;
Members
Members Description
DRV_IPF_EVENT_BLOCK_COMMAND_COMPLETE Block operation has been completed successfully. Read/Write/Erase Complete
DRV_IPF_EVENT_BLOCK_COMMAND_ERROR There was an error during the block operation Read/Write/Erase Error
Description
IPF SPI Flash Driver Events
This enumeration identifies the possible events that can result from a Read, Write, or Erase request caused by the client.
Remarks
One of these values is passed in the "event" parameter of the event handling callback function that client registered with the driver by calling the
DRV_IPF_BlockEventHandlerSet function when a block request is completed.
DRV_IPF_BLOCK_OPERATION Enumeration
Lists the different operations that IPF driver can do.
File
drv_ipf.h
C
typedef enum {
DRV_IPF_BLOCK_READ,
DRV_IPF_BLOCK_WRITE,
DRV_IPF_BLOCK_ERASE,
DRV_IPF_HW_BLOCK_PROT,
DRV_IPF_HW_BLOCK_UNPROT,
DRV_IPF_READ_HW_BLOCK_PROT
} DRV_IPF_BLOCK_OPERATION;
Members
Members Description
DRV_IPF_BLOCK_READ Block Read
DRV_IPF_BLOCK_WRITE Block Write
DRV_IPF_BLOCK_ERASE Block Erase
DRV_IPF_HW_BLOCK_PROT Hardware Block Protection
DRV_IPF_HW_BLOCK_UNPROT Hardware Block Un-Protection
DRV_IPF_READ_HW_BLOCK_PROT Read HW Block Protection Status
Description
IPF Driver Operations
This enumeration lists the different operations that IPF driver can do.
Remarks
None.
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI PIC32WK IPF Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 874
DRV_IPF_CLIENT_STATUS Enumeration
Defines the client status.
Implementation: Dynamic
File
drv_ipf.h
C
typedef enum {
DRV_IPF_CLIENT_STATUS_READY = DRV_CLIENT_STATUS_READY+0,
DRV_IPF_CLIENT_STATUS_BUSY = DRV_CLIENT_STATUS_BUSY,
DRV_IPF_CLIENT_STATUS_CLOSED = DRV_CLIENT_STATUS_CLOSED,
DRV_IPF_CLIENT_STATUS_ERROR = DRV_CLIENT_STATUS_ERROR
} DRV_IPF_CLIENT_STATUS;
Members
Members Description
DRV_IPF_CLIENT_STATUS_READY =
DRV_CLIENT_STATUS_READY+0
Up and running, ready to start new operations
DRV_IPF_CLIENT_STATUS_BUSY =
DRV_CLIENT_STATUS_BUSY
Operation in progress, unable to start a new one
DRV_IPF_CLIENT_STATUS_CLOSED =
DRV_CLIENT_STATUS_CLOSED
Client is closed
DRV_IPF_CLIENT_STATUS_ERROR =
DRV_CLIENT_STATUS_ERROR
Client Error
Description
SPI Flash Client Status
Defines the various client status codes.
Remarks
None.
DRV_IPF_COMMAND_STATUS Enumeration
Specifies the status of the command for the read, write and erase operations.
File
drv_ipf.h
C
typedef enum {
DRV_IPF_COMMAND_COMPLETED = SYS_FS_MEDIA_COMMAND_COMPLETED,
DRV_IPF_COMMAND_QUEUED = SYS_FS_MEDIA_COMMAND_QUEUED,
DRV_IPF_COMMAND_IN_PROGRESS = SYS_FS_MEDIA_COMMAND_IN_PROGRESS,
DRV_IPF_COMMAND_ERROR_UNKNOWN = SYS_FS_MEDIA_COMMAND_UNKNOWN
} DRV_IPF_COMMAND_STATUS;
Members
Members Description
DRV_IPF_COMMAND_COMPLETED =
SYS_FS_MEDIA_COMMAND_COMPLETED
Done OK and ready
DRV_IPF_COMMAND_QUEUED =
SYS_FS_MEDIA_COMMAND_QUEUED
Scheduled but not started
DRV_IPF_COMMAND_IN_PROGRESS =
SYS_FS_MEDIA_COMMAND_IN_PROGRESS
Currently being in transfer
DRV_IPF_COMMAND_ERROR_UNKNOWN =
SYS_FS_MEDIA_COMMAND_UNKNOWN
Unknown Command
Description
IPF Driver Command Status
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI PIC32WK IPF Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 875
IPF Driver command Status
This type specifies the status of the command for the read, write and erase operations.
Remarks
None.
DRV_IPF_EVENT_HANDLER Type
Pointer to a IPF SPI Flash Driver Event handler function.
Implementation: Dynamic
File
drv_ipf.h
C
typedef void (* DRV_IPF_EVENT_HANDLER)(DRV_IPF_BLOCK_EVENT event, DRV_IPF_BLOCK_COMMAND_HANDLE
commandHandle, uintptr_t context);
Returns
None.
Description
IPF SPI Flash Driver Event Handler Function Pointer
This data type defines the required function signature for the IPF SPI Flash driver event handling callback function. A client must register a pointer
to an event handling function whose function signature (parameter and return value types) match the types specified by this function pointer in
order to receive event calls back from the driver.
The parameters and return values and return value are described here and a partial example implementation is provided.
Remarks
If the event is DRV_IPF_EVENT_BLOCK_COMMAND_COMPLETE, it means that the data was transferred successfully.
If the event is DRV_IPF_EVENT_BLOCK_COMMAND_ERROR, it means that the data was not transferred successfully.
The context parameter contains the a handle to the client context, provided at the time the event handling function was registered using the
DRV_IPF_BlockEventHandlerSet function. This context handle value is passed back to the client as the "context" parameter. It can be any value
necessary to identify the client context or instance (such as a pointer to the client's data) instance of the client that made the read/write/erase
request.
The event handler function executes in the driver peripheral's interrupt context when the driver is configured for interrupt mode operation. It is
recommended of the application to not perform process intensive or blocking operations with in this function.
The Read, Write, and Erase functions can be called in the event handler to add a buffer to the driver queue. These functions can only be called to
add buffers to the driver whose event handler is running.
Example
void APP_MyBufferEventHandler
(
DRV_IPF_BLOCK_EVENT event,
DRV_IPF_BLOCK_COMMAND_HANDLE commandHandle,
uintptr_t context
)
{
MY_APP_DATA_STRUCT pAppData = (MY_APP_DATA_STRUCT) context;
switch(event)
{
case DRV_IPF_EVENT_BLOCK_COMMAND_COMPLETE:
// Handle the completed buffer.
break;
case DRV_IPF_EVENT_BLOCK_COMMAND_ERROR:
default:
// Handle error.
break;
}
}
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI PIC32WK IPF Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 876
Parameters
Parameters Description
event Identifies the type of event
commandHandle Handle returned from the Read/Write/Erase requests
context Value identifying the context of the application that registered the event handling function
DRV_IPF_INIT Structure
Contains all the data necessary to initialize the SPI Flash device.
Implementation: Dynamic
File
drv_ipf.h
C
typedef struct {
SYS_MODULE_INIT moduleInit;
SYS_MODULE_INDEX spiDriverModuleIndex;
PORTS_CHANNEL holdPortChannel;
PORTS_BIT_POS holdBitPosition;
PORTS_CHANNEL writeProtectPortChannel;
PORTS_BIT_POS writeProtectBitPosition;
PORTS_CHANNEL chipSelectPortChannel;
PORTS_BIT_POS chipSelectBitPosition;
uint32_t queueSize;
} DRV_IPF_INIT;
Members
Members Description
SYS_MODULE_INIT moduleInit; System module initialization
SYS_MODULE_INDEX spiDriverModuleIndex; Identifies the SPI driver to be used
PORTS_CHANNEL holdPortChannel; HOLD pin port channel
PORTS_BIT_POS holdBitPosition; HOLD pin port position
PORTS_CHANNEL writeProtectPortChannel; Write protect pin port channel
PORTS_BIT_POS writeProtectBitPosition; Write Protect Bit pin position
PORTS_CHANNEL chipSelectPortChannel; Chip select pin port channel
PORTS_BIT_POS chipSelectBitPosition; Chip Select Bit pin position
uint32_t queueSize; This is the buffer queue size. This is the maximum number of requests that this instance of
the driver will queue. For a static build of the driver, this is overridden by the
DRV_IPF_QUEUE_SIZE macro in system_config.h
Description
SST SPI Flash Driver Initialization Data
This structure contains all of the data necessary to initialize the SPI Flash device.
Remarks
A pointer to a structure of this format containing the desired initialization data must be passed into the DRV_IPF_Initialize function.
DRV_IPF_PROT_MODE Enumeration
Lists the different memory protection modes.
File
drv_ipf.h
C
typedef enum {
DRV_IPF_WRITE_PROTECT = 1,
DRV_IPF_READ_PROTECT
} DRV_IPF_PROT_MODE;
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI PIC32WK IPF Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 877
Members
Members Description
DRV_IPF_WRITE_PROTECT = 1 Write Protect
DRV_IPF_READ_PROTECT Read Protect
Description
IPF Driver memory protection modes
This enumeration lists the different memory protection modes.
Remarks
None.
_DRV_IPF_H Macro
File
drv_ipf.h
C
#define _DRV_IPF_H
Description
This is macro _DRV_IPF_H.
DRV_IPF_BLOCK_COMMAND_HANDLE_INVALID Macro
This value defines the SPI Flash Driver Block Command Invalid handle.
File
drv_ipf.h
C
#define DRV_IPF_BLOCK_COMMAND_HANDLE_INVALID
Description
SPI Flash Driver Block Event Invalid Handle
This value defines the SPI Flash Driver Block Command Invalid handle. It is returned by read/write/erase routines when the request could not be
taken.
Remarks
None.
DRV_IPF_INDEX_0 Macro
SPI Flash driver index definitions
File
drv_ipf.h
C
#define DRV_IPF_INDEX_0 0
Description
Driver SPI Flash Module Index reference
These constants provide IPF SPI Flash driver index definitions.
Remarks
These constants should be used in place of hard-coded numeric literals.
These values should be passed into the DRV_IPF_Initialize and DRV_IPF_Open routines to identify the driver instance in use.
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI PIC32WK IPF Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 878
_DRV_IPF_CONFIG_TEMPLATE_H Macro
File
drv_ipf_config_template.h
C
#define _DRV_IPF_CONFIG_TEMPLATE_H
Description
This is macro _DRV_IPF_CONFIG_TEMPLATE_H.
DRV_IPF_CLIENTS_NUMBER Macro
Sets up the maximum number of clients that can be connected to the hardware instance.
File
drv_ipf_config_template.h
C
#define DRV_IPF_CLIENTS_NUMBER 4
Description
IPF Client Count Configuration
Sets up the maximum number of clients that can be connected to the hardware instance. So if IPF will be accessed by 2 clients then this number
should be 2. It is recommended that this be set exactly equal to the number of expected clients. Client support consumes RAM memory space.
Remarks
None.
DRV_IPF_INSTANCES_NUMBER Macro
Sets up the maximum number of hardware instances that can be supported
File
drv_ipf_config_template.h
C
#define DRV_IPF_INSTANCES_NUMBER 1
Description
IPF driver objects configuration
Sets up the maximum number of hardware instances that can be supported. It is recommended that this number be set exactly equal to the
number of IPF modules that are needed by the application. Hardware Instance support consumes RAM memory space.
Remarks
As PIC32WK has only 1 instance of IPF, this macro is always set to 1.
DRV_IPF_MODE Macro
Determines whether the driver is implemented as static or dynamic
File
drv_ipf_config_template.h
C
#define DRV_IPF_MODE DYNAMIC
Description
IPF mode
Determines whether the driver is implemented as static or dynamic. Static drivers control the peripheral directly with peripheral library routines.
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI PIC32WK IPF Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 879
Remarks
None.
Files
Files
Name Description
drv_ipf.h SPI Flash Driver Interface Definition
drv_ipf_config_template.h IPF Driver Configuration Template.
Description
This section lists the source and header files used by the SPI PIC32WK IPF Flash Driver Library.
drv_ipf.h
SPI Flash Driver Interface Definition
Enumerations
Name Description
DRV_IPF_BLOCK_EVENT Identifies the possible events that can result from a request.
DRV_IPF_BLOCK_OPERATION Lists the different operations that IPF driver can do.
DRV_IPF_CLIENT_STATUS Defines the client status.
Implementation: Dynamic
DRV_IPF_COMMAND_STATUS Specifies the status of the command for the read, write and erase operations.
DRV_IPF_PROT_MODE Lists the different memory protection modes.
Functions
Name Description
DRV_IPF_BlockErase Erase the specified number of blocks in Flash memory.
Implementation: Dynamic
DRV_IPF_BlockEventHandlerSet Allows a client to identify an event handling function for the driver to call back when queued
operation has completed.
Implementation: Dynamic
DRV_IPF_BlockRead Reads blocks of data starting from the specified address in Flash memory.
Implementation: Dynamic
DRV_IPF_BlockWrite Write blocks of data starting from a specified address in Flash memory.
Implementation: Dynamic
DRV_IPF_ClientStatus Gets current client-specific status of the SPI Flash driver.
Implementation: Dynamic
DRV_IPF_Close Closes an opened-instance of the SPI Flash driver.
Implementation: Dynamic
DRV_IPF_Deinitialize Deinitializes the specified instance of the SPI Flash driver module.
Implementation: Dynamic
DRV_IPF_GeometryGet Returns the geometry of the device.
Implementation: Dynamic
DRV_IPF_HoldAssert Asserts the Hold pin for flash.
Implementation: Dynamic
DRV_IPF_HoldDeAssert Deasserts the Hold pin for flash.
Implementation: Dynamic
DRV_IPF_Initialize Initializes the IPF SPI Flash Driver instance for the specified driver index.
Implementation: Dynamic
DRV_IPF_MediaIsAttached Returns the status of the media.
Implementation: Dynamic
DRV_IPF_Open Opens the specified SPI Flash driver instance and returns a handle to it.
Implementation: Dynamic
DRV_IPF_ProtectMemoryVolatile Protects the memory block to which the given memory address belongs
Implementation: Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI PIC32WK IPF Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 880
DRV_IPF_ReadBlockProtectionStatus Reads the content of Block Protection Register which belongs to In-Package flash.
Implementation: Dynamic
DRV_IPF_Status Gets the current status of the SPI Flash Driver module.
Implementation: Dynamic
DRV_IPF_Tasks Maintains the driver's read, erase, and write state machine and implements its ISR.
Implementation: Dynamic
DRV_IPF_UnProtectMemoryVolatile Un-protects the memory block to which the given memory address belongs
Implementation: Dynamic
DRV_IPF_WPAssert Asserts the WP pin for flash.
Implementation: Dynamic
DRV_IPF_WPDeAssert Deasserts the WP pin for flash.
Implementation: Dynamic
Macros
Name Description
_DRV_IPF_H This is macro _DRV_IPF_H.
DRV_IPF_BLOCK_COMMAND_HANDLE_INVALID This value defines the SPI Flash Driver Block Command Invalid handle.
DRV_IPF_INDEX_0 SPI Flash driver index definitions
Structures
Name Description
DRV_IPF_INIT Contains all the data necessary to initialize the SPI Flash device.
Implementation: Dynamic
Types
Name Description
DRV_IPF_BLOCK_COMMAND_HANDLE Handle identifying block commands of the driver.
DRV_IPF_EVENT_HANDLER Pointer to a IPF SPI Flash Driver Event handler function.
Implementation: Dynamic
Description
SPI Flash Driver Interface Definition
The SPI Flash device driver provides a simple interface to manage the SPI Flash modules which are external to Microchip Controllers. This file
defines the interface definition for the SPI Flash Driver.
File Name
drv_IPF.h
Company
Microchip Technology Inc.
drv_ipf_config_template.h
IPF Driver Configuration Template.
Macros
Name Description
_DRV_IPF_CONFIG_TEMPLATE_H This is macro _DRV_IPF_CONFIG_TEMPLATE_H.
DRV_IPF_CLIENTS_NUMBER Sets up the maximum number of clients that can be connected to the hardware instance.
DRV_IPF_INSTANCES_NUMBER Sets up the maximum number of hardware instances that can be supported
DRV_IPF_MODE Determines whether the driver is implemented as static or dynamic
Description
IPF Driver Configuration Template
These file provides the list of all the configurations that can be used with the driver. This file should not be included in the driver.
File Name
drv_ipf_config_template.h
Volume V: MPLAB Harmony Framework Driver Libraries Help SPI PIC32WK IPF Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 881
Company
Microchip Technology Inc.
SQI Driver Library
Introduction
This library provides an interface to manage the Serial Quad Interface (SQI) module on the Microchip family of microcontrollers in different modes
of operation.
Description
The MPLAB Harmony Serial Quad Interface (SQI) Driver provides a high-level interface to the SQI peripherals on Microchip's PIC32
microcontrollers. The SQI Driver includes the following features:
• Provides application ready routines to read and write data to an SQI peripheral
• Supports Single, Dual, and Quad Lane modes
• Supports Single Data Rate (SDR)
• Supports Interrupt mode operation only
• Supports multi-client operation
• Provides data transfer events
• Supports non-blocking mode operation only
• Features thread-safe functions for use in RTOS applications
• Uses the SQI module’s internal DMA Controller for transfers
Using the Library
This topic describes the basic architecture of the SQI Driver Library and provides information and examples on its use.
Description
Interface Header File: drv_sqi.h
The interface to the SQI Driver Library is defined in the drv_sqi.h header file. Any C language source (.c) file that uses the SQI Driver library
should include this header.
Please refer to the What is MPLAB Harmony? section for how the Driver interacts with the framework.
Abstraction Model
This library provides a low-level abstraction of the SQI Driver Library on the Microchip family microcontrollers with a convenient C language
interface. This topic describes how that abstraction is modeled in software and introduces the library's interface.
Description
The SQI Driver Library supports up to two Chip Select lines. The following diagram shows the high SQI Driver and the SQI Flash sub-system
SQI Abstraction Model
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 882
Library Overview
Refer to the Driver Library Overview section for information on how the driver operates in a system.
The library interface routines are divided into various sub-sections, which address one of the blocks or the overall operation of the SQI module.
Library Interface Section Description
System Interaction Functions Provides system module interfaces, device initialization, deinitialization,
reinitialization, tasks and status functions.
Client Setup Functions Provides open, close, status and other setup functions.
Data Transfer Functions Provides data transfer functions available in the configuration.
How the Library Works
The library provides interfaces to support:
• System Functionality
• Client Functionality
Note:
Not all modes are available on all devices, please refer to the specific device data sheet to determine the modes that are
supported for your device.
System Functions
Provides information on the system functions provided in the SQI Driver Library.
Description
SQI Driver Initialization
The system performs the initialization of the device driver with settings that affect only the instance of the device that is being initialized. During
system initialization, each instance of the SQI would be initialized with the following configuration settings (either passed dynamically at run time
using DRV_SQI_INIT or by using initialization overrides) that are supported by the specific SQI Controller hardware:
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 883
• SQI Peripheral ID - Identifies the SQI Peripheral ID to be used
• Interrupt Source - The interrupt source associated with the SQI Controller
• Enabled Devices - Number of devices to enable
• Device Configuration - This configuration is per enabled device. A maximum of two devices are supported. The following configurations are
allowed per device:
• Clock Divider Value - Clock divider value to be used
• SPI Mode of Operation - SPI mode of operation to be used for this device
• LSB First - Send or receive least significant bit of a byte first
The DRV_SQI_Initialize function configures and initializes the SQI controller using the configuration information provided. It returns an object
handle of the type SYS_MODULE_OBJ. This object handle would be used by other system interfaces such as DRV_SQI_Status, DRV_SQI_Tasks
and DRV_SQI_Deinitialize.
Example:
/* SQI Driver Initialization Data */
const DRV_SQI_INIT drvSqiInit =
{
.sqiId = SQI_ID_0,
.interruptSource = INT_SOURCE_SQI1,
.enabledDevices = DRV_SQI_ENABLE_DEVICE_1,
.clockDivider = DRV_SQI_CLK_DIV_1,
.devCfg[0].spiMode = DRV_SQI_SPI_MODE_0,
.devCfg[0].lsbFirst = false,
};
/* Initialize the SQI Driver */
sysObj.drvSqi = DRV_SQI_Initialize(DRV_SQI_INDEX_0, (SYS_MODULE_INIT *)&drvSqiInit);
SQI Driver Task Routine
The SQI driver data transfers are interrupt driven. The data transfer request from the client results in the SQI driver kick starting the transfer if there
is no transfer in progress otherwise the request is added to the driver queue. The SQI interrupt handler is responsible for invoking the
DRV_SQI_Tasks, which maintains the driver state machine. The task routine checks if the current request is complete and if there is another data
transfer request queued, then it kick starts the processing of the request.
SQI Driver Status
DRV_SQI_Status returns the current status of the SQI driver module and is called by the Harmony System. The application may not find the need
to call this function directly.
Example:
SYS_MODULE_OBJ object;
// Returned from DRV_SQI_Initialize
SYS_STATUS sqiStatus;
sqiStatus = DRV_SQI_Status(object);
if (SYS_STATUS_ERROR >= sqiStatus)
{
// Handle error
}
Client Core Functions
Provides information on the client core functions provided in the SQI Driver Library
Description
Opening the Driver
For the application to start using an instance of the module, it must call the DRV_SQI_Open function repeatedly until a valid handle is returned by
the driver. This provides the configuration required to open the SQI instance for operation.
For the various options available for I/O INTENT please refer to "Data Types and Constants" in the Library Interface section.
Example:
sqiHandle = DRV_SQI_Open (0, DRV_IO_INTENT_READWRITE);
if (sqiHandle != DRV_HANDLE_INVALID)
{
/* Do further processing. */
}
else
{
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 884
/* Call until the function returns a valid handle. */
}
Closing the Driver
Closes an opened-instance of the SQI driver
Example:
DRV_HANDLE handle; // Returned from DRV_SQI_Open
DRV_SQI_Close(handle);
Client Data Transfer Functions
Provides information on the client data transfer functions provided in the SQI Driver Library.
Description
Client data transfer functionality provides API interfaces for the data transfer operation. The following diagram illustrates the data transfer model.
Applications need to perform the following steps to transfer data using the SQI Driver:
1. The system should have completed necessary initialization and the DRV_SQI_Tasks should be running in an interrupt environment.
2. Open_the driver using DRV_SQI_Open with the necessary intent. The application should wait call the DRV_SQI_Open until the function
returns a valid open handle.
3. Register callback function using the DRV_SQI_EventHandlerSet.
4. Add a transfer request using the buffer using the DRV_SQI_TransferData function. The reads or writes of blocks of data generally involves
sending down the read or a write command, the address on the device from/to which data is to be read/written. The client also has to specify
the source or destination buffer and the number of bytes to be read or written. The client builds an array of transfer elements containing this
information and passes the array and the number of elements of the array as part of this transfer request.
5. Check for the current transfer status using DRV_SQI_CommandStatus until the transfer progress is DRV_SQI_COMMAND_COMPLETED, or
wait for the callback to be called.
6. When the client has no more data to be transferred, the client can close the driver using DRV_SQI_Close.
Example:
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 885
#define READ_BUF_SIZE 512
uint8_t readBuffer[READ_BUF_SIZE] __attribute__((coherent, aligned(16)));
uint8_t command [5] __attribute__((coherent, aligned(16)) = {0x0B, 0x00, 0x00, 0x00, 0x0FF};
uint8_t numElements = 0;
DRV_SQI_COMMAND_HANDLE commandHandle;
MY_APP_OBJ myAppObj;
DRV_SQI_TRANSFER_ELEMENT xferData[2];
// mySQIHandle is the handle returned by the DRV_SQI_Open function.
// Setup the transfer elements.
xferData[0].data = &command[0];
xferData[0].length = sizeof(command);
xferData[0].flag = (DRV_SQI_FLAG_MODE_SINGLE_LANE);
xferData[1].data = readBuffer;
xferData[1].length = READ_BUF_SIZE;
xferData[1].flag = (DRV_SQI_FLAG_MODE_QUAD_LANE | DRV_SQI_FLAG_DIR_READ | DRV_SQI_FLAG_DEASSERT_CS);
DRV_SQI_TransferData(mySQIHandle, &commandHandle, 0, xferData, 2);
if(DRV_SQI_COMMAND_HANDLE_INVALID == commandHandle)
{
// Error handling here
}
else
{
// Transfer operation queued successfully. Wait for the
// completion event.
}
// Transfer completion can be tracked either by polling on the commandHandle or waiting
// for the event using the event callback function.
status = DRV_SQI_CommandStatus(mySQIHandle, commandHandle);
if(status == DRV_SQI_COMMAND_COMPLETED)
{
// Operation Done
}
// Event handler.
void APP_SQIEventHandler
(
DRV_SQI_EVENT event,
DRV_SQI_COMMAND_HANDLE handle,
uintptr_t context
)
{
// The context handle was set to an application specific
// object. It is now retrievable easily in the event
// handler.
MY_APP_OBJ myAppObj = (MY_APP_OBJ *) context;
switch(event)
{
case DRV_SQI_EVENT_COMMAND_COMPLETE:
// This means the operation was completed
// successfully.
break;
case DRV_SQI_EVENT_COMMAND_ERROR:
// Operation failed. Handle the error.
break;
default:
break;
}
}
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 886
Configuring the Library
Macros
Name Description
DRV_SQI_BUFFER_OBJECT_NUMBER Selects the maximum number of buffer objects
DRV_SQI_CLIENTS_NUMBER Selects the maximum number of clients
DRV_SQI_DMA_BUFFER_DESCRIPTORS_NUMBER Selects the maximum number of DMA Buffer descriptors to be used by the
driver.
DRV_SQI_INSTANCES_NUMBER Selects the maximum number of Driver instances that can be supported
by the dynamic driver.
DRV_SQI_INTERRUPT_MODE Macro specifies operation of the driver to be in the interrupt mode or polled
mode
Description
The configuration of the SQI driver is based on the file system_config.h.
This header file contains the configuration selection for the SQI driver. Based on the selections made, the SQI driver may support the selected
features. These configuration settings will apply to all instances of the SQI driver.
This header can be placed anywhere, the path of this header needs to be present in the include search path for a successful build. Refer to the
Applications Help section for more details.
DRV_SQI_BUFFER_OBJECT_NUMBER Macro
Selects the maximum number of buffer objects
File
drv_sqi_config_template.h
C
#define DRV_SQI_BUFFER_OBJECT_NUMBER 5
Description
SQI Driver maximum number of buffer objects
This definition selects the maximum number of buffer objects. This indirectly also specifies the queue depth. The SQI Driver can queue up
DRV_SQI_BUFFER_OBJECT_NUMBER of read/write/erase requests before return a DRV_SQI_BUFFER_HANDLE_INVALID due to the queue
being full. Buffer objects are shared by all instances of the driver. Increasing this number increases the RAM requirement of the driver.
Remarks
This macro is mandatory when building the driver for dynamic operation.
DRV_SQI_CLIENTS_NUMBER Macro
Selects the maximum number of clients
File
drv_sqi_config_template.h
C
#define DRV_SQI_CLIENTS_NUMBER 1
Description
SQI maximum number of clients
This definition selects the maximum number of clients that the SQI driver can supported at run time. This constant defines the total number of SQI
driver clients that will be available to all instances of the SQI driver.
Remarks
This macro is mandatory when building the driver for dynamic operation.
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 887
DRV_SQI_DMA_BUFFER_DESCRIPTORS_NUMBER Macro
Selects the maximum number of DMA Buffer descriptors to be used by the driver.
File
drv_sqi_config_template.h
C
#define DRV_SQI_DMA_BUFFER_DESCRIPTORS_NUMBER 4
Description
SQI Driver maximum number DMA Buffer Descriptors
This definition selects the maximum number of DMA buffer descriptor objects. The SQI Driver can queue up to
DRV_SQI_DMA_BUFFER_DESCRIPTORS_NUMBER of transactions to be processed by the hardware. DMA buffer desired are shared by all
instances of the driver. Increasing this number increases the RAM requirement of the driver.
Remarks
This macro is mandatory when building the driver for dynamic operation.
DRV_SQI_INSTANCES_NUMBER Macro
Selects the maximum number of Driver instances that can be supported by the dynamic driver.
File
drv_sqi_config_template.h
C
#define DRV_SQI_INSTANCES_NUMBER 1
Description
SQI Driver instance configuration
This definition selects the maximum number of Driver instances that can be supported by the dynamic driver. In case of this driver, multiple
instances of the driver could use the same hardware instance.
Remarks
This macro is mandatory when building the driver for dynamic operation.
DRV_SQI_INTERRUPT_MODE Macro
Macro specifies operation of the driver to be in the interrupt mode or polled mode
File
drv_sqi_config_template.h
C
#define DRV_SQI_INTERRUPT_MODE true
Description
SQI interrupt and polled mode operation control
This macro specifies operation of the driver to be in the interrupt mode or polled mode
• true - Select if interrupt mode of SQI operation is desired
• false - Select if polling mode of SQI operation is desired
Not defining this option to true or false will result in build error.
Remarks
This macro is mandatory when building the driver for dynamic operation.
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 888
Building the Library
This section lists the files that are available in the SQI Driver Library.
Description
This section list the files that are available in the \src folder of the SQI Driver. It lists which files need to be included in the build based on either a
hardware feature present on the board or configuration option selected by the system.
The following three tables list and describe the header (.h) and source (.c) files that implement this library. The parent folder for these files is
/framework/driver/sqi.
Interface File(s)
This table lists and describes the header files that must be included (i.e., using #include) by any code that uses this library.
Source File Name Description
/drv_sqi.h Header file that exports the driver API.
Required File(s)
All of the required files listed in the following table are automatically added into the MPLAB X IDE project by the MHC
when the library is selected for use.
This table lists and describes the source and header files that must always be included in the MPLAB X IDE project to build this library.
Source File Name Description
/src/dynamic/drv_sqi.c This file contains the source code for the dynamic implementation of the SQI driver.
Optional File(s)
This table lists and describes the source and header files that may optionally be included if required for the desired implementation.
Source File Name Description
N/A No optional files are available for this library
Module Dependencies
The SQI Driver Library depends on the following modules:
• Clock System Service Library
Optional Dependencies
• Interrupt System Service Library (used when task is running in Interrupt mode)
Library Interface
a) System Interaction Functions
Name Description
DRV_SQI_Initialize Initializes the SQI instance for the specified driver index
DRV_SQI_Deinitialize Deinitializes the specified instance of the SQI driver module
DRV_SQI_Status Gets the current status of the SQI driver module.
DRV_SQI_Tasks Maintains the driver's task state machine.
b) Client Setup Functions
Name Description
DRV_SQI_Open Opens the specified SQI driver instance and returns a handle to it.
DRV_SQI_Close Closes an opened-instance of the SQI driver
DRV_SQI_CommandStatus Gets the current status of the transfer request.
DRV_SQI_EventHandlerSet Allows a client to register an event handling function, which the driver can invoke when the
queued transfer request has completed.
c) Data Transfer Functions
Name Description
DRV_SQI_TransferData Queue a data transfer operation on the specified SQI device.
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 889
DRV_SQI_TransferFrames Queue a transfer request operation on the SQI device.
d) Data Types and Constants
Name Description
DRV_SQI_COMMAND_HANDLE Handle to identify the transfer request queued at the SQI driver.
DRV_SQI_COMMAND_STATUS Specifies the status of the transfer request.
DRV_SQI_EVENT Identifies the possible events that can result from a transfer request.
DRV_SQI_EVENT_HANDLER Pointer to a SQI Driver Event handler function
DRV_SQI_SPI_OPERATION_MODE Enumeration of the SPI mode of operation supported by the SQI Controller.
DRV_SQI_TRANSFER_FLAGS Enumeration of the configuration options associated with a single transfer
element.
DRV_SQI_TransferElement Defines the data transfer element of the SQI driver.
DRV_SQI_COMMAND_HANDLE_INVALID Identifies an invalid command handle.
DRV_SQI_INDEX_0 SQI driver index definitions.
DRV_SQI_FLAG_32_BIT_ADDR_ENABLE This is macro DRV_SQI_FLAG_32_BIT_ADDR_ENABLE.
DRV_SQI_FLAG_32_BIT_ADDR_ENABLE_MASK This is macro DRV_SQI_FLAG_32_BIT_ADDR_ENABLE_MASK.
DRV_SQI_FLAG_32_BIT_ADDR_ENABLE_POS Enables 32-bit addressing instead of 24-bit addressing.
DRV_SQI_FLAG_ADDR_ENABLE This is macro DRV_SQI_FLAG_ADDR_ENABLE.
DRV_SQI_FLAG_ADDR_ENABLE_MASK This is macro DRV_SQI_FLAG_ADDR_ENABLE_MASK.
DRV_SQI_FLAG_ADDR_ENABLE_POS Address Enable Macro.
DRV_SQI_FLAG_CRM_ENABLE This is macro DRV_SQI_FLAG_CRM_ENABLE.
DRV_SQI_FLAG_CRM_ENABLE_MASK This is macro DRV_SQI_FLAG_CRM_ENABLE_MASK.
DRV_SQI_FLAG_CRM_ENABLE_POS Continuous Read Mode Enable Macro.
DRV_SQI_FLAG_DATA_DIRECTION_MASK This is macro DRV_SQI_FLAG_DATA_DIRECTION_MASK.
DRV_SQI_FLAG_DATA_DIRECTION_POS Macros to select the direction of the transfers.
DRV_SQI_FLAG_DATA_DIRECTION_READ This is macro DRV_SQI_FLAG_DATA_DIRECTION_READ.
DRV_SQI_FLAG_DATA_DIRECTION_WRITE This is macro DRV_SQI_FLAG_DATA_DIRECTION_WRITE.
DRV_SQI_FLAG_DATA_ENABLE This is macro DRV_SQI_FLAG_DATA_ENABLE.
DRV_SQI_FLAG_DATA_ENABLE_MASK This is macro DRV_SQI_FLAG_DATA_ENABLE_MASK.
DRV_SQI_FLAG_DATA_ENABLE_POS Data Enable Macro.
DRV_SQI_FLAG_DATA_TARGET_MASK This is macro DRV_SQI_FLAG_DATA_TARGET_MASK.
DRV_SQI_FLAG_DATA_TARGET_MEMORY This is macro DRV_SQI_FLAG_DATA_TARGET_MEMORY.
DRV_SQI_FLAG_DATA_TARGET_POS Macros to select the source and destination of a transfer.
DRV_SQI_FLAG_DATA_TARGET_REGISTER This is macro DRV_SQI_FLAG_DATA_TARGET_REGISTER.
DRV_SQI_FLAG_DDR_ENABLE This is macro DRV_SQI_FLAG_DDR_ENABLE.
DRV_SQI_FLAG_DDR_ENABLE_MASK This is macro DRV_SQI_FLAG_DDR_ENABLE_MASK.
DRV_SQI_FLAG_DDR_ENABLE_POS DDR Enable Macro.
DRV_SQI_FLAG_INSTR_ENABLE This is macro DRV_SQI_FLAG_INSTR_ENABLE.
DRV_SQI_FLAG_INSTR_ENABLE_MASK This is macro DRV_SQI_FLAG_INSTR_ENABLE_MASK.
DRV_SQI_FLAG_INSTR_ENABLE_POS Macros listing the bitmap values for the flags member of the
DRV_SQI_TransferFrame structure. Instruction Enable Macro.
DRV_SQI_FLAG_OPT_ENABLE This is macro DRV_SQI_FLAG_OPT_ENABLE.
DRV_SQI_FLAG_OPT_ENABLE_MASK This is macro DRV_SQI_FLAG_OPT_ENABLE_MASK.
DRV_SQI_FLAG_OPT_ENABLE_POS Option Enable Macro.
DRV_SQI_FLAG_OPT_LENGTH This is macro DRV_SQI_FLAG_OPT_LENGTH.
DRV_SQI_FLAG_OPT_LENGTH_1BIT This is macro DRV_SQI_FLAG_OPT_LENGTH_1BIT.
DRV_SQI_FLAG_OPT_LENGTH_2BIT This is macro DRV_SQI_FLAG_OPT_LENGTH_2BIT.
DRV_SQI_FLAG_OPT_LENGTH_4BIT This is macro DRV_SQI_FLAG_OPT_LENGTH_4BIT.
DRV_SQI_FLAG_OPT_LENGTH_8BIT This is macro DRV_SQI_FLAG_OPT_LENGTH_8BIT.
DRV_SQI_FLAG_OPT_LENGTH_MASK This is macro DRV_SQI_FLAG_OPT_LENGTH_MASK.
DRV_SQI_FLAG_OPT_LENGTH_POS Macros to enable and specify the option length.
DRV_SQI_FLAG_SQI_CS_NUMBER This is macro DRV_SQI_FLAG_SQI_CS_NUMBER.
DRV_SQI_FLAG_SQI_CS_NUMBER_0 This is macro DRV_SQI_FLAG_SQI_CS_NUMBER_0.
DRV_SQI_FLAG_SQI_CS_NUMBER_1 This is macro DRV_SQI_FLAG_SQI_CS_NUMBER_1.
DRV_SQI_FLAG_SQI_CS_NUMBER_2 This is macro DRV_SQI_FLAG_SQI_CS_NUMBER_2.
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 890
DRV_SQI_FLAG_SQI_CS_NUMBER_3 This is macro DRV_SQI_FLAG_SQI_CS_NUMBER_3.
DRV_SQI_FLAG_SQI_CS_NUMBER_MASK This is macro DRV_SQI_FLAG_SQI_CS_NUMBER_MASK.
DRV_SQI_FLAG_SQI_CS_NUMBER_POS Macros to select the SQI CS Line Number to be used for the current transfer
• frame.
DRV_SQI_LANE_CONFIG Defines the SQI lane configuration options.
DRV_SQI_TransferFrame Defines the transfer frame of the SQI driver.
Description
This section describes the API functions of the SQI Driver Library.
Refer to each section for a detailed description.
a) System Interaction Functions
DRV_SQI_Initialize Function
Initializes the SQI instance for the specified driver index
File
drv_sqi.h
C
SYS_MODULE_OBJ DRV_SQI_Initialize(const SYS_MODULE_INDEX drvIndex, const SYS_MODULE_INIT *const init);
Returns
Returns a valid handle to a driver instance object on success. Otherwise returns SYS_MODULE_OBJ_INVALID.
Description
This routine initializes the SQI driver instance for the specified driver index, making it ready for clients to open and use it.
Remarks
This routine must be called before any other SQI routines are called.
This routine should only be called once during system initialization unless DRV_SQI_Deinitialize is called to deinitialize the driver instance.
This routine will NEVER block for hardware access. If the operation requires time to allow the hardware to initialize, it will be reported by the
DRV_SQI_Status operation. The system must use DRV_SQI_Status to find out when the driver is in the ready state.
Preconditions
None.
Example
// This code snippet shows an example of initializing the SQI Driver.
SYS_MODULE_OBJ objectHandle;
TODO:Replace with appropriate init snippet.
// SQI Driver Initialization Data
const DRV_SQI_INIT drvSqiInit =
{
.sqiId = SQI_ID_0,
.interruptSource = INT_SOURCE_SQI1,
.enabledDevices = DRV_SQI_ENABLE_BOTH_DEVICES,
.clockDivider = DRV_SQI_CLK_DIV_1,
.devCfg[0].spiMode = DRV_SQI_SPI_MODE_0,
.devCfg[0].lsbFirst = true,
.devCfg[1].spiMode = DRV_SQI_SPI_MODE_3,
.devCfg[1].lsbFirst = false,
};
objectHandle = DRV_SQI_Initialize(DRV_SQI_INDEX_0, (SYS_MODULE_INIT*)&drvSqiInit);
if (SYS_MODULE_OBJ_INVALID == objectHandle)
{
// Handle error
}
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 891
Parameters
Parameters Description
index Identifier for the instance to be initialized.
init Pointer to a data structure containing any data necessary to initialize the driver.
Function
SYS_MODULE_OBJ DRV_SQI_Initialize
(
const SYS_MODULE_INDEX index,
const SYS_MODULE_INIT * const init
);
DRV_SQI_Deinitialize Function
Deinitializes the specified instance of the SQI driver module
File
drv_sqi.h
C
void DRV_SQI_Deinitialize(SYS_MODULE_OBJ object);
Returns
None.
Description
Deinitializes the specified instance of the SQI driver module, disabling its operation (and any hardware). Invalidates all the internal data.
Remarks
Once the Initialize operation has been called, the Deinitialize operation must be called before the Initialize operation can be called again.
Preconditions
Function DRV_SQI_Initialize should have been called before calling this function.
Parameter: object - Driver object handle, returned from the DRV_SQI_Initialize routine
Example
// This code snippet shows an example of deinitializing the driver.
SYS_MODULE_OBJ object; // Returned from DRV_SQI_Initialize
SYS_STATUS status;
DRV_SQI_Deinitialize(object);
status = DRV_SQI_Status(object);
if (SYS_MODULE_DEINITIALIZED != status)
{
// Check again later to know if the driver is deinitialized.
}
Function
void DRV_SQI_Deinitialize
(
SYS_MODULE_OBJ object
);
DRV_SQI_Status Function
Gets the current status of the SQI driver module.
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 892
File
drv_sqi.h
C
SYS_STATUS DRV_SQI_Status(SYS_MODULE_OBJ object);
Returns
SYS_STATUS_READY - Indicates that the driver is ready and can accept transfer requests.
SYS_STATUS_UNINITIALIZED - Indicates the driver is not initialized.
Description
This routine provides the current status of the SQI driver module.
Remarks
This routine will NEVER block waiting for hardware.
Preconditions
Function DRV_SQI_Initialize should have been called before calling this function.
Example
SYS_MODULE_OBJ object; // Returned from DRV_SQI_Initialize
SYS_STATUS sqiStatus;
sqiStatus = DRV_SQI_Status(object);
else if (SYS_STATUS_ERROR >= sqiStatus)
{
// Handle error
}
Parameters
Parameters Description
object Driver object handle, returned from the DRV_SQI_Initialize routine
Function
SYS_STATUS DRV_SQI_Status
(
SYS_MODULE_OBJ object
);
DRV_SQI_Tasks Function
Maintains the driver's task state machine.
File
drv_sqi.h
C
void DRV_SQI_Tasks(SYS_MODULE_OBJ object);
Returns
None.
Description
This routine is used to maintain the driver's internal task state machine.
Remarks
This routine may either be called by the system's task routine(SYS_Tasks) or the from the interrupt service routine of the peripheral.
Preconditions
The DRV_SQI_Initialize routine must have been called for the specified SQI driver instance.
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 893
Example
SYS_MODULE_OBJ object; // Returned from DRV_SQI_Initialize
while (true)
{
DRV_SQI_Tasks (object);
// Do other tasks
}
Parameters
Parameters Description
object Object handle for the specified driver instance (returned from DRV_SQI_Initialize)
Function
void DRV_SQI_Tasks
(
SYS_MODULE_OBJ object
);
b) Client Setup Functions
DRV_SQI_Open Function
Opens the specified SQI driver instance and returns a handle to it.
File
drv_sqi.h
C
DRV_HANDLE DRV_SQI_Open(const SYS_MODULE_INDEX index, const DRV_IO_INTENT ioIntent);
Returns
If successful, the routine returns a valid open-instance handle (a number identifying both the caller and the module instance).
If an error occurs, DRV_HANDLE_INVALID is returned. Errors can occur under the following circumstances:
• if the number of client objects allocated via DRV_SQI_CLIENTS_NUMBER is insufficient
• if the client is trying to open the driver but driver has been opened exclusively by another client
• if the client is trying to open the driver exclusively, but has already been opened in a non exclusive mode by another client.
• if the driver hardware instance being opened is not initialized or is invalid
Description
This routine opens the specified SQI driver instance and provides a handle identifying the SQI driver instance. This handle must be provided to all
other client-level operations to identify the caller and the instance of the driver.
Remarks
The handle returned is valid until the DRV_SQI_Close routine is called. This routine will NEVER block waiting for hardware. If the driver has has
already been opened, it cannot be opened exclusively.
Preconditions
Function DRV_SQI_Initialize must have been called before calling this function.
Example
DRV_HANDLE handle;
handle = DRV_SQI_Open(DRV_SQI_INDEX_0, DRV_IO_INTENT_EXCLUSIVE);
if (DRV_HANDLE_INVALID == handle)
{
// Unable to open the driver
}
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 894
Parameters
Parameters Description
index Identifier for the object instance to be opened.
intent Zero or more of the values from the enumeration DRV_IO_INTENT "ORed" together to
indicate the intended use of the driver.
Function
DRV_HANDLE DRV_SQI_Open
(
const SYS_MODULE_INDEX index,
const DRV_IO_INTENT ioIntent
);
DRV_SQI_Close Function
Closes an opened-instance of the SQI driver
File
drv_sqi.h
C
void DRV_SQI_Close(const DRV_HANDLE handle);
Returns
None
Description
This routine closes an opened-instance of the SQI driver, invalidating the handle.
Remarks
After calling this routine, the handle passed in "handle" must not be used with any of the remaining driver routines. A new handle must be obtained
by calling DRV_SQI_Open before the caller may use the driver again. Usually there is no need for the driver client to verify that the Close
operation has completed.
Preconditions
The DRV_SQI_Initialize routine must have been called for the specified SQI driver instance.
DRV_SQI_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE handle; // Returned from DRV_SQI_Open
DRV_SQI_Close(handle);
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
void DRV_SQI_Close
(
const DRV_HANDLE handle
);
DRV_SQI_CommandStatus Function
Gets the current status of the transfer request.
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 895
File
drv_sqi.h
C
DRV_SQI_COMMAND_STATUS DRV_SQI_CommandStatus(const DRV_HANDLE handle, const DRV_SQI_COMMAND_HANDLE
commandHandle);
Returns
A DRV_SQI_COMMAND_STATUS value describing the current status of the transfer request. Returns
DRV_SQI_COMMAND_ERROR_UNKNOWN if the client handle or the handle is not valid.
Description
This routine gets the current status of the tranfer request. The application must use this routine where the status of a scheduled transfer request
needs to polled on. The function may return DRV_SQI_COMMAND_COMPLETED in a case where the handle has expired. A handle expires
when the internal buffer object is re-assigned to another transfer request. It is recommended that this function be called regularly in order to track
the status of the transfer request correctly.
The application can alternatively register an event handler to receive the transfer completion events.
Remarks
This routine will not block for hardware access and will immediately return the current status of the transfer request.
Preconditions
The DRV_SQI_Initialize() routine must have been called.
The DRV_SQI_Open() must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE handle; // Returned from DRV_SQI_Open
DRV_SQI_COMMAND_HANDLE commandHandle;
DRV_SQI_COMMAND_STATUS status;
status = DRV_SQI_CommandStatus(handle, commandHandle);
if(status == DRV_SQI_COMMAND_COMPLETED)
{
// Operation Done
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
DRV_SQI_COMMAND_STATUS DRV_SQI_CommandStatus
(
const DRV_HANDLE handle,
const DRV_SQI_COMMAND_HANDLE commandHandle
);
DRV_SQI_EventHandlerSet Function
Allows a client to register an event handling function, which the driver can invoke when the queued transfer request has completed.
File
drv_sqi.h
C
void DRV_SQI_EventHandlerSet(const DRV_HANDLE handle, const void * eventHandler, const uintptr_t context);
Returns
None.
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 896
Description
This function allows a client to identify an event handling function for the driver to call back when queued operation has completed. When a client
queues a transfer request with the driver, it is provided with a handle identifying the transfer request that was added to the driver's buffer queue.
The driver will pass this handle back to the client by calling "eventHandler" function when the queued operation has completed.
The event handler should be set before the client performs any transfer operations that could generate events. The event handler once set,
persists until the client closes the driver or sets another event handler (which could be a "NULL" pointer to indicate no callback).
Remarks
If the client does not want to be notified when the queued operation has completed, it does not need to register a callback.
Preconditions
The DRV_SQI_Initialize() routine must have been called for the specified SQI driver instance.
The DRV_SQI_Open() routine must have been called to obtain a valid opened device handle.
Example
// myAppObj is an application specific state data object.
MY_APP_OBJ myAppObj;
DRV_SQI_TransferFrame xferFrame;
DRV_SQI_COMMAND_HANDLE commandHandle;
// drvSQIHandle is the handle returned by the DRV_SQI_Open function.
// Client registers an event handler with driver. This is done once.
DRV_SQI_EventHandlerSet(drvSQIHandle, APP_SQIEventHandler, (uintptr_t)&myAppObj);
DRV_SQI_Read(drvSQIHandle, &commandHandle, &xferFrame, 1);
if(DRV_SQI_COMMAND_HANDLE_INVALID == commandHandle)
{
// Error handling here
}
// Event handler.
void APP_SQIEventHandler
(
DRV_SQI_EVENT event,
DRV_SQI_COMMAND_HANDLE handle,
uintptr_t context
)
{
// The context handle was set to an application specific object. It is
// now retrievable easily in the event handler.
MY_APP_OBJ myAppObj = (MY_APP_OBJ *) context;
switch(event)
{
case DRV_SQI_EVENT_COMMAND_COMPLETE:
// This means the operation was completed successfully.
break;
case DRV_SQI_EVENT_COMMAND_ERROR:
// Operation failed. Handle the error.
break;
default:
break;
}
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
eventHandler Pointer to the event handler function implemented by the user
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 897
context The value of parameter will be passed back to the client unchanged, when the eventHandler
function is called. It can be used to identify any client specific data object that identifies the
instance of the client module (for example, it may be a pointer to the client module's state
structure).
Function
void DRV_SQI_EventHandlerSet
(
const DRV_HANDLE handle,
const void *eventHandler,
const uintptr_t context
);
c) Data Transfer Functions
DRV_SQI_TransferData Function
Queue a data transfer operation on the specified SQI device.
File
drv_sqi.h
C
void DRV_SQI_TransferData(DRV_HANDLE handle, DRV_SQI_COMMAND_HANDLE * commandHandle, uint8_t sqiDevice,
DRV_SQI_TransferElement * xferData, uint8_t numElements);
Returns
The handle to the command request is returned in the commandHandle argument. It will be DRV_SQI_COMMAND_HANDLE_INVALID if the
request was not successful.
Description
This routine queues a data transfer operation on the specified SQI device. The reads or writes of blocks of data generally involves sending down
the read or a write command, the address on the device from/to which data is to be read/written. The client also has to specify the source or
destination buffer and the number of bytes to be read or written. The client builds an array of transfer elements containing these information and
passes the array and the number of elements of the array as part of this transfer operation. If an event handler is registered with the driver the
event handler would be invoked with the status of the operation once the operation has been completed. The function returns
DRV_SQI_COMMAND_HANDLE_INVALID in the commandHandle argument under the following circumstances:
• if the driver handle is invalid
• if the transfer element is NULL or number of transfer elements is zero
• if a buffer object could not be allocated to the request
Remarks
None.
Preconditions
The DRV_SQI_Initialize routine must have been called for the specified SQI driver instance.
DRV_SQI_Open must have been called with DRV_IO_INTENT_READ or DRV_IO_INTENT_READWRITE as the ioIntent to obtain a valid opened
device handle.
Example
#define READ_BUF_SIZE 512
uint8_t readBuffer[READ_BUF_SIZE] __attribute__((coherent, aligned(16)));
uint8_t command [5] __attribute__((coherent, aligned(16)) = {0x0B, 0x00, 0x00, 0x00, 0x0FF};
uint8_t numElements = 0;
DRV_SQI_COMMAND_HANDLE commandHandle;
MY_APP_OBJ myAppObj;
DRV_SQI_TransferElement xferData[2];
// mySQIHandle is the handle returned by the DRV_SQI_Open function.
// Setup the transfer elements.
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 898
xferData[0].data = &command[0];
xferData[0].length = sizeof(command);
xferData[0].flag = (DRV_SQI_FLAG_MODE_SINGLE_LANE);
xferData[1].data = readBuffer;
xferData[1].length = READ_BUF_SIZE;
xferData[1].flag = (DRV_SQI_FLAG_MODE_QUAD_LANE | DRV_SQI_FLAG_DIR_READ | DRV_SQI_FLAG_DEASSERT_CS);
DRV_SQI_TransferData(mySQIHandle, &commandHandle, 0, xferData, 2);
if(DRV_SQI_COMMAND_HANDLE_INVALID == commandHandle)
{
// Error handling here
}
else
{
// Transfer operation queued successfully. Wait for the completion event.
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
commandHandle Pointer to an argument that will contain the return buffer handle
sqiDevice The SQI device index on which the operation is to be performed.
xferData Pointer to the transfer elements array.
numElements Number of elements in the transfer elements array.
Function
void DRV_SQI_TransferData
(
DRV_HANDLE handle,
DRV_SQI_COMMAND_HANDLE *commandHandle,
uint8_t sqiDevice,
DRV_SQI_TransferElement *xferData,
uint8_t numElements
);
DRV_SQI_TransferFrames Function
Queue a transfer request operation on the SQI device.
File
drv_sqi.h
C
void DRV_SQI_TransferFrames(DRV_HANDLE handle, DRV_SQI_COMMAND_HANDLE * commandHandle,
DRV_SQI_TransferFrame * frame, uint8_t numFrames);
Returns
The handle to the transfer request is returned in the commandHandle argument. It will be DRV_SQI_COMMAND_HANDLE_INVALID if the
request was not successful.
Description
This routine queues a transfer request operation on the SQI device. In order to perform any operation on the sqi flash device, a one byte
instruction specifying the operation to be performed needs to be sent out. This is followed by optional address from/to which data is to be
read/written, option, dummy and data bytes.
If an event handler is registered with the driver the event handler would be invoked with the status of the operation once the operation has been
completed. The function returns DRV_SQI_COMMAND_HANDLE_INVALID in the commandHandle argument under the following circumstances:
• if the driver handle is invalid
• if the transfer element is NULL or number of transfer elements is zero
• if a buffer object could not be allocated to the request
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 899
Remarks
None.
Preconditions
The DRV_SQI_Initialize routine must have been called for the specified SQI driver instance.
DRV_SQI_Open must have been called with DRV_IO_INTENT_READ or DRV_IO_INTENT_READWRITE as the ioIntent to obtain a valid opened
device handle.
Example
#define READ_BUF_SIZE 512
uint8_t readBuffer[READ_BUF_SIZE];
uint8_t numElements = 0;
DRV_SQI_COMMAND_HANDLE cmdHandle;
DRV_SQI_TransferFrame xferFrame;
DRV_SQI_TransferFrame *frame = &xferFrame;
frame->instruction = 0x6B;
frame->address = 0x00;
frame->data = readBuffer;
frame->length = READ_BUF_SIZE;
frame->laneCfg = DRV_SQI_LANE_QUAD_DATA;
frame->numDummyBytes = 8;
frame->flags = (DRV_SQI_FLAG_INSTR_ENABLE_MASK | DRV_SQI_FLAG_DATA_ENABLE_MASK |
DRV_SQI_FLAG_ADDR_ENABLE_MASK | DRV_SQI_FLAG_DATA_TARGET_MEMORY |
DRV_SQI_FLAG_DATA_DIRECTION_READ);
DRV_SQI_TransferFrames (sqiHandle, &cmdHandle, frame, 1);
if (cmdHandle == DRV_SQI_COMMAND_HANDLE_INVALID)
{
// handle the failure.
}
else
{
// continue with the rest of the operation.
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
commandHandle Pointer to an argument that will contain the handle to the track the status of the transfer
request.
frame Pointer to the transfer frame array.
numFrames Number of elements in the transfer frame array.
Function
void DRV_SQI_TransferFrames
(
DRV_HANDLE handle,
DRV_SQI_COMMAND_HANDLE *commandHandle,
DRV_SQI_TransferFrame *frame,
uint8_t numFrames
);
d) Data Types and Constants
DRV_SQI_COMMAND_HANDLE Type
Handle to identify the transfer request queued at the SQI driver.
File
drv_sqi.h
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 900
C
typedef uintptr_t DRV_SQI_COMMAND_HANDLE;
Description
SQI Driver Command Handle
A command handle is returned by a call to the DRV_SQI_TransferFrames () function. This handle allows the application to track the completion of
the request. This command handle is also returned to the client along with the event that has occurred with respect to the request. This allows the
application to connect the event to a specific transfer request in case where multiple requests are queued.
The command handle associated with the transfer request expires when the client has been notified of the completion of the request (after event
handler function that notifies the client returns) or after the request has been retired by the driver if no event handler callback was set.
Remarks
None.
DRV_SQI_COMMAND_STATUS Enumeration
Specifies the status of the transfer request.
File
drv_sqi.h
C
typedef enum {
DRV_SQI_COMMAND_COMPLETED,
DRV_SQI_COMMAND_QUEUED,
DRV_SQI_COMMAND_IN_PROGRESS,
DRV_SQI_COMMAND_ERROR_UNKNOWN
} DRV_SQI_COMMAND_STATUS;
Members
Members Description
DRV_SQI_COMMAND_COMPLETED Command completed.
DRV_SQI_COMMAND_QUEUED Command is pending.
DRV_SQI_COMMAND_IN_PROGRESS Command is being processed
DRV_SQI_COMMAND_ERROR_UNKNOWN There was an error while processing the command.
Description
SQI Driver Command Status
This enumeration identifies the possible status values associated with a transfer request. The client can retrieve the status by calling the
DRV_SQI_CommandStatus () function and passing the command handle associated with the request.
Remarks
None.
DRV_SQI_EVENT Enumeration
Identifies the possible events that can result from a transfer request.
File
drv_sqi.h
C
typedef enum {
DRV_SQI_EVENT_COMMAND_COMPLETE = 0,
DRV_SQI_EVENT_COMMAND_ERROR
} DRV_SQI_EVENT;
Members
Members Description
DRV_SQI_EVENT_COMMAND_COMPLETE = 0 Operation has been completed successfully.
DRV_SQI_EVENT_COMMAND_ERROR There was an error during the operation
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 901
Description
SQI Driver Events
This enumeration identifies the possible events that can result from a transfer request issued by the client.
Remarks
One of these values is passed in the "event" parameter of the event handling callback function that client registered with the driver by calling the
DRV_SQI_EventHandlerSet function when a request is completed.
DRV_SQI_EVENT_HANDLER Type
Pointer to a SQI Driver Event handler function
File
drv_sqi.h
C
typedef void (* DRV_SQI_EVENT_HANDLER)(DRV_SQI_EVENT event, DRV_SQI_COMMAND_HANDLE commandHandle, void
*context);
Returns
None.
Description
SQI Driver Event Handler Function Pointer data type.
This data type defines the required function signature for the SQI driver event handling callback function. A client must register a pointer to a event
handling function the signature(parameter and return value types) of which should match the types specified by this function pointer in order to
receive transfer request related event call backs from the driver.
The parameters and return values are described here and a partial example implementation is provided.
Remarks
If the event is DRV_SQI_EVENT_COMMAND_COMPLETE, that the operation associated with the transfer request was completed successfully. If
the event is DRV_SQI_EVENT_COMMAND_ERROR, there was an error while executing the transfer request.
The context parameter contains context details provided by the client as part of registering the event handler function. This context value is passed
back to the client as the "context" parameter. It can be any value necessary to identify the client context or instance (such as a pointer to the
client's data) of the client that made the request.
Example
void MyAppCommandEventHandler
(
DRV_SQI_EVENT event,
DRV_SQI_COMMAND_HANDLE commandHandle,
uintptr_t context
)
{
MY_APP_DATA_STRUCT pAppData = (MY_APP_DATA_STRUCT)context;
switch(event)
{
case DRV_SQI_EVENT_COMMAND_COMPLETE:
// Handle the completed transfer request.
break;
case DRV_SQI_EVENT_COMMAND_ERROR:
default:
// Handle the failed transfer request.
break;
}
}
Parameters
Parameters Description
event Identifies the type of event
commandHandle Handle identifying the transfer request to which this event relates
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 902
context Value identifying the context of the application that registered the event handling function.
DRV_SQI_SPI_OPERATION_MODE Enumeration
Enumeration of the SPI mode of operation supported by the SQI Controller.
File
drv_sqi.h
C
typedef enum {
DRV_SQI_SPI_MODE_0 = 0,
DRV_SQI_SPI_MODE_3 = 3
} DRV_SQI_SPI_OPERATION_MODE;
Members
Members Description
DRV_SQI_SPI_MODE_0 = 0 CPOL = 0 and CPHA = 0. SCK Idle state = LOW
DRV_SQI_SPI_MODE_3 = 3 CPOL = 1 and CPHA = 1. SCK Idle state = HIGH
Description
SQI SPI Mode of operation
This enumeration lists the SPI mode of operation supported by the SQI controller. In MODE 0 of operation: CPOL = 0 and CPHA = 0. SCK Idle
state = LOW
In MODE 3 of operation: CPOL = 1 and CPHA = 1. SCK Idle state = HIGH
In both MODE 0 and MODE 3 of operation the: SQI Data Input is sampled on the rising edge of the SQI Clock SQI Data is Output on the falling
edge of the SQI Clock
Remarks
None
DRV_SQI_TRANSFER_FLAGS Enumeration
Enumeration of the configuration options associated with a single transfer element.
File
drv_sqi.h
C
typedef enum {
DRV_SQI_FLAG_MODE_SINGLE_LANE = 0x00,
DRV_SQI_FLAG_MODE_DUAL_LANE = 0x01,
DRV_SQI_FLAG_MODE_QUAD_LANE = 0x02,
DRV_SQI_FLAG_DDR_MODE = 0x04,
DRV_SQI_FLAG_DEASSERT_CS = 0x08,
DRV_SQI_FLAG_DIR_READ = 0x80
} DRV_SQI_TRANSFER_FLAGS;
Members
Members Description
DRV_SQI_FLAG_MODE_SINGLE_LANE = 0x00 Bits 0-1: Indicates the Lane configuration to be used.
DRV_SQI_FLAG_DDR_MODE = 0x04 Bit 2: This bit indicates if DDR or SDR mode of operation is to be used.
DRV_SQI_FLAG_DEASSERT_CS = 0x08 Bit 3: This bit indicates if CS is to be de-asserted at the end of this
• transaction.
DRV_SQI_FLAG_DIR_READ = 0x80 Bit 7: This bit indicates if the operation is a read or a write.
Description
Flags associated with the SQI Driver Transfer element.
This enumeration lists the various configuration options associated with a single transfer element(Refer to the data structure
DRV_SQI_TransferElement). The client can specify one or more of these as configuration parameters of a single transfer element.
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 903
Remarks
None
DRV_SQI_TransferElement Structure
Defines the data transfer element of the SQI driver.
File
drv_sqi.h
C
typedef struct {
uint8_t * data;
uint32_t length;
uint8_t flag;
} DRV_SQI_TransferElement;
Members
Members Description
uint8_t * data; Pointer to the source or destination buffer
uint32_t length; Length of the buffer in bytes.
uint8_t flag; This is a bitmap used to indicate the configuration options to be used
• for this transfer element. One or more values of the enumeration
• DRV_SQI_TRANSFER_FLAGS can be passed as part of this flag.
Description
SQI Driver data transfer element.
This data type defines the composition of a single transfer element. A single element will consist of the pointer to the source of destination buffer,
length of the data to be transferred or received and the various configuration options to be used for the element. The configuration options also
indicate if data is transferred to/from the device. A client builds an array of such transfer elements and passes the array and the number of
elements of the array as part of the read or write operation.
Remarks
None.
DRV_SQI_COMMAND_HANDLE_INVALID Macro
Identifies an invalid command handle.
File
drv_sqi.h
C
#define DRV_SQI_COMMAND_HANDLE_INVALID ((DRV_SQI_COMMAND_HANDLE)(-1))
Description
SQI Driver Invalid Command Handle
This is the definition of an invalid command handle. An invalid command handle is returned by DRV_SQI_TransferFrames() function if the transfer
request was not queued.
Remarks
None.
DRV_SQI_INDEX_0 Macro
SQI driver index definitions.
File
drv_sqi.h
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 904
C
#define DRV_SQI_INDEX_0 0
Description
SQI Driver Module Index Numbers
This constant provides the SQI driver index definition.
Remarks
This constant should be used in place of hard-coded numeric literal.
This value should be passed into the DRV_SQI_Initialize and DRV_SQI_Open functions to identify the driver instance in use.
DRV_SQI_FLAG_32_BIT_ADDR_ENABLE Macro
File
drv_sqi.h
C
#define DRV_SQI_FLAG_32_BIT_ADDR_ENABLE(value) (DRV_SQI_FLAG_32_BIT_ADDR_ENABLE_MASK & ((value) <<
DRV_SQI_FLAG_32_BIT_ADDR_ENABLE_POS))
Description
This is macro DRV_SQI_FLAG_32_BIT_ADDR_ENABLE.
DRV_SQI_FLAG_32_BIT_ADDR_ENABLE_MASK Macro
File
drv_sqi.h
C
#define DRV_SQI_FLAG_32_BIT_ADDR_ENABLE_MASK (0x1U << DRV_SQI_FLAG_32_BIT_ADDR_ENABLE_POS)
Description
This is macro DRV_SQI_FLAG_32_BIT_ADDR_ENABLE_MASK.
DRV_SQI_FLAG_32_BIT_ADDR_ENABLE_POS Macro
File
drv_sqi.h
C
#define DRV_SQI_FLAG_32_BIT_ADDR_ENABLE_POS (6)
Description
Enables 32-bit addressing instead of 24-bit addressing.
DRV_SQI_FLAG_ADDR_ENABLE Macro
File
drv_sqi.h
C
#define DRV_SQI_FLAG_ADDR_ENABLE(value) (DRV_SQI_FLAG_ADDR_ENABLE_MASK & ((value) <<
DRV_SQI_FLAG_ADDR_ENABLE_POS))
Description
This is macro DRV_SQI_FLAG_ADDR_ENABLE.
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 905
DRV_SQI_FLAG_ADDR_ENABLE_MASK Macro
File
drv_sqi.h
C
#define DRV_SQI_FLAG_ADDR_ENABLE_MASK (0x1U << DRV_SQI_FLAG_ADDR_ENABLE_POS)
Description
This is macro DRV_SQI_FLAG_ADDR_ENABLE_MASK.
DRV_SQI_FLAG_ADDR_ENABLE_POS Macro
File
drv_sqi.h
C
#define DRV_SQI_FLAG_ADDR_ENABLE_POS (1)
Description
Address Enable Macro.
DRV_SQI_FLAG_CRM_ENABLE Macro
File
drv_sqi.h
C
#define DRV_SQI_FLAG_CRM_ENABLE(value) (DRV_SQI_FLAG_CRM_ENABLE_MASK & ((value) <<
DRV_SQI_FLAG_CRM_ENABLE_POS))
Description
This is macro DRV_SQI_FLAG_CRM_ENABLE.
DRV_SQI_FLAG_CRM_ENABLE_MASK Macro
File
drv_sqi.h
C
#define DRV_SQI_FLAG_CRM_ENABLE_MASK (0x1U << DRV_SQI_FLAG_CRM_ENABLE_POS)
Description
This is macro DRV_SQI_FLAG_CRM_ENABLE_MASK.
DRV_SQI_FLAG_CRM_ENABLE_POS Macro
File
drv_sqi.h
C
#define DRV_SQI_FLAG_CRM_ENABLE_POS (5)
Description
Continuous Read Mode Enable Macro.
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 906
DRV_SQI_FLAG_DATA_DIRECTION_MASK Macro
File
drv_sqi.h
C
#define DRV_SQI_FLAG_DATA_DIRECTION_MASK (0x1U << DRV_SQI_FLAG_DATA_DIRECTION_POS)
Description
This is macro DRV_SQI_FLAG_DATA_DIRECTION_MASK.
DRV_SQI_FLAG_DATA_DIRECTION_POS Macro
File
drv_sqi.h
C
#define DRV_SQI_FLAG_DATA_DIRECTION_POS (11)
Description
Macros to select the direction of the transfers.
DRV_SQI_FLAG_DATA_DIRECTION_READ Macro
File
drv_sqi.h
C
#define DRV_SQI_FLAG_DATA_DIRECTION_READ (DRV_SQI_FLAG_DATA_DIRECTION_MASK & ((0x1U) <<
DRV_SQI_FLAG_DATA_DIRECTION_POS))
Description
This is macro DRV_SQI_FLAG_DATA_DIRECTION_READ.
DRV_SQI_FLAG_DATA_DIRECTION_WRITE Macro
File
drv_sqi.h
C
#define DRV_SQI_FLAG_DATA_DIRECTION_WRITE (DRV_SQI_FLAG_DATA_DIRECTION_MASK & ((0x0U) <<
DRV_SQI_FLAG_DATA_DIRECTION_POS))
Description
This is macro DRV_SQI_FLAG_DATA_DIRECTION_WRITE.
DRV_SQI_FLAG_DATA_ENABLE Macro
File
drv_sqi.h
C
#define DRV_SQI_FLAG_DATA_ENABLE(value) (DRV_SQI_FLAG_DATA_ENABLE_MASK & ((value) <<
DRV_SQI_FLAG_DATA_ENABLE_POS))
Description
This is macro DRV_SQI_FLAG_DATA_ENABLE.
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 907
DRV_SQI_FLAG_DATA_ENABLE_MASK Macro
File
drv_sqi.h
C
#define DRV_SQI_FLAG_DATA_ENABLE_MASK (0x1U << DRV_SQI_FLAG_DATA_ENABLE_POS)
Description
This is macro DRV_SQI_FLAG_DATA_ENABLE_MASK.
DRV_SQI_FLAG_DATA_ENABLE_POS Macro
File
drv_sqi.h
C
#define DRV_SQI_FLAG_DATA_ENABLE_POS (3)
Description
Data Enable Macro.
DRV_SQI_FLAG_DATA_TARGET_MASK Macro
File
drv_sqi.h
C
#define DRV_SQI_FLAG_DATA_TARGET_MASK (0x1U << DRV_SQI_FLAG_DATA_TARGET_POS)
Description
This is macro DRV_SQI_FLAG_DATA_TARGET_MASK.
DRV_SQI_FLAG_DATA_TARGET_MEMORY Macro
File
drv_sqi.h
C
#define DRV_SQI_FLAG_DATA_TARGET_MEMORY (DRV_SQI_FLAG_DATA_TARGET_MASK & ((0x1U) <<
DRV_SQI_FLAG_DATA_TARGET_POS))
Description
This is macro DRV_SQI_FLAG_DATA_TARGET_MEMORY.
DRV_SQI_FLAG_DATA_TARGET_POS Macro
File
drv_sqi.h
C
#define DRV_SQI_FLAG_DATA_TARGET_POS (10)
Description
Macros to select the source and destination of a transfer.
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 908
DRV_SQI_FLAG_DATA_TARGET_REGISTER Macro
File
drv_sqi.h
C
#define DRV_SQI_FLAG_DATA_TARGET_REGISTER (DRV_SQI_FLAG_DATA_TARGET_MASK & ((0x0U) <<
DRV_SQI_FLAG_DATA_TARGET_POS))
Description
This is macro DRV_SQI_FLAG_DATA_TARGET_REGISTER.
DRV_SQI_FLAG_DDR_ENABLE Macro
File
drv_sqi.h
C
#define DRV_SQI_FLAG_DDR_ENABLE(value) (DRV_SQI_FLAG_DDR_ENABLE_MASK & ((value) <<
DRV_SQI_FLAG_DDR_ENABLE_POS))
Description
This is macro DRV_SQI_FLAG_DDR_ENABLE.
DRV_SQI_FLAG_DDR_ENABLE_MASK Macro
File
drv_sqi.h
C
#define DRV_SQI_FLAG_DDR_ENABLE_MASK (0x1U << DRV_SQI_FLAG_DDR_ENABLE_POS)
Description
This is macro DRV_SQI_FLAG_DDR_ENABLE_MASK.
DRV_SQI_FLAG_DDR_ENABLE_POS Macro
File
drv_sqi.h
C
#define DRV_SQI_FLAG_DDR_ENABLE_POS (4)
Description
DDR Enable Macro.
DRV_SQI_FLAG_INSTR_ENABLE Macro
File
drv_sqi.h
C
#define DRV_SQI_FLAG_INSTR_ENABLE(value) (DRV_SQI_FLAG_INSTR_ENABLE_MASK & ((value) <<
DRV_SQI_FLAG_INSTR_ENABLE_POS))
Description
This is macro DRV_SQI_FLAG_INSTR_ENABLE.
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 909
DRV_SQI_FLAG_INSTR_ENABLE_MASK Macro
File
drv_sqi.h
C
#define DRV_SQI_FLAG_INSTR_ENABLE_MASK (0x1U << DRV_SQI_FLAG_INSTR_ENABLE_POS)
Description
This is macro DRV_SQI_FLAG_INSTR_ENABLE_MASK.
DRV_SQI_FLAG_INSTR_ENABLE_POS Macro
File
drv_sqi.h
C
#define DRV_SQI_FLAG_INSTR_ENABLE_POS (0)
Description
Macros listing the bitmap values for the flags member of the DRV_SQI_TransferFrame structure. Instruction Enable Macro.
DRV_SQI_FLAG_OPT_ENABLE Macro
File
drv_sqi.h
C
#define DRV_SQI_FLAG_OPT_ENABLE(value) (DRV_SQI_FLAG_OPT_ENABLE_MASK & ((value) <<
DRV_SQI_FLAG_OPT_ENABLE_POS))
Description
This is macro DRV_SQI_FLAG_OPT_ENABLE.
DRV_SQI_FLAG_OPT_ENABLE_MASK Macro
File
drv_sqi.h
C
#define DRV_SQI_FLAG_OPT_ENABLE_MASK (0x1U << DRV_SQI_FLAG_OPT_ENABLE_POS)
Description
This is macro DRV_SQI_FLAG_OPT_ENABLE_MASK.
DRV_SQI_FLAG_OPT_ENABLE_POS Macro
File
drv_sqi.h
C
#define DRV_SQI_FLAG_OPT_ENABLE_POS (2)
Description
Option Enable Macro.
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 910
DRV_SQI_FLAG_OPT_LENGTH Macro
File
drv_sqi.h
C
#define DRV_SQI_FLAG_OPT_LENGTH(value) (DRV_SQI_FLAG_OPT_LENGTH_MASK & ((value) <<
DRV_SQI_FLAG_OPT_LENGTH_POS))
Description
This is macro DRV_SQI_FLAG_OPT_LENGTH.
DRV_SQI_FLAG_OPT_LENGTH_1BIT Macro
File
drv_sqi.h
C
#define DRV_SQI_FLAG_OPT_LENGTH_1BIT (0x0U)
Description
This is macro DRV_SQI_FLAG_OPT_LENGTH_1BIT.
DRV_SQI_FLAG_OPT_LENGTH_2BIT Macro
File
drv_sqi.h
C
#define DRV_SQI_FLAG_OPT_LENGTH_2BIT (0x1U)
Description
This is macro DRV_SQI_FLAG_OPT_LENGTH_2BIT.
DRV_SQI_FLAG_OPT_LENGTH_4BIT Macro
File
drv_sqi.h
C
#define DRV_SQI_FLAG_OPT_LENGTH_4BIT (0x2U)
Description
This is macro DRV_SQI_FLAG_OPT_LENGTH_4BIT.
DRV_SQI_FLAG_OPT_LENGTH_8BIT Macro
File
drv_sqi.h
C
#define DRV_SQI_FLAG_OPT_LENGTH_8BIT (0x3U)
Description
This is macro DRV_SQI_FLAG_OPT_LENGTH_8BIT.
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 911
DRV_SQI_FLAG_OPT_LENGTH_MASK Macro
File
drv_sqi.h
C
#define DRV_SQI_FLAG_OPT_LENGTH_MASK (0x3U << DRV_SQI_FLAG_OPT_LENGTH_POS)
Description
This is macro DRV_SQI_FLAG_OPT_LENGTH_MASK.
DRV_SQI_FLAG_OPT_LENGTH_POS Macro
File
drv_sqi.h
C
#define DRV_SQI_FLAG_OPT_LENGTH_POS (8)
Description
Macros to enable and specify the option length.
DRV_SQI_FLAG_SQI_CS_NUMBER Macro
File
drv_sqi.h
C
#define DRV_SQI_FLAG_SQI_CS_NUMBER(value) (DRV_SQI_FLAG_SQI_CS_NUMBER_MASK & ((value) <<
DRV_SQI_FLAG_SQI_CS_NUMBER_POS))
Description
This is macro DRV_SQI_FLAG_SQI_CS_NUMBER.
DRV_SQI_FLAG_SQI_CS_NUMBER_0 Macro
File
drv_sqi.h
C
#define DRV_SQI_FLAG_SQI_CS_NUMBER_0 (0x0U)
Description
This is macro DRV_SQI_FLAG_SQI_CS_NUMBER_0.
DRV_SQI_FLAG_SQI_CS_NUMBER_1 Macro
File
drv_sqi.h
C
#define DRV_SQI_FLAG_SQI_CS_NUMBER_1 (0x1U)
Description
This is macro DRV_SQI_FLAG_SQI_CS_NUMBER_1.
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 912
DRV_SQI_FLAG_SQI_CS_NUMBER_2 Macro
File
drv_sqi.h
C
#define DRV_SQI_FLAG_SQI_CS_NUMBER_2 (0x2U)
Description
This is macro DRV_SQI_FLAG_SQI_CS_NUMBER_2.
DRV_SQI_FLAG_SQI_CS_NUMBER_3 Macro
File
drv_sqi.h
C
#define DRV_SQI_FLAG_SQI_CS_NUMBER_3 (0x3U)
Description
This is macro DRV_SQI_FLAG_SQI_CS_NUMBER_3.
DRV_SQI_FLAG_SQI_CS_NUMBER_MASK Macro
File
drv_sqi.h
C
#define DRV_SQI_FLAG_SQI_CS_NUMBER_MASK (0x3U << DRV_SQI_FLAG_SQI_CS_NUMBER_POS)
Description
This is macro DRV_SQI_FLAG_SQI_CS_NUMBER_MASK.
DRV_SQI_FLAG_SQI_CS_NUMBER_POS Macro
File
drv_sqi.h
C
#define DRV_SQI_FLAG_SQI_CS_NUMBER_POS (16)
Description
Macros to select the SQI CS Line Number to be used for the current transfer
• frame.
DRV_SQI_LANE_CONFIG Enumeration
Defines the SQI lane configuration options.
File
drv_sqi.h
C
typedef enum {
DRV_SQI_LANE_SINGLE = 0,
DRV_SQI_LANE_DUAL_DATA,
DRV_SQI_LANE_QUAD_DATA,
DRV_SQI_LANE_DUAL_ADDR_DATA,
DRV_SQI_LANE_QUAD_ADDR_DATA,
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 913
DRV_SQI_LANE_DUAL_ALL,
DRV_SQI_LANE_QUAD_ALL
} DRV_SQI_LANE_CONFIG;
Members
Members Description
DRV_SQI_LANE_SINGLE = 0 Instruction opcode, Address and Data are all sent in single lane
DRV_SQI_LANE_DUAL_DATA Instruction opcode and Address are sent in single lane, while data is
• sent using dual lane.
DRV_SQI_LANE_QUAD_DATA Instruction opcode and Address are sent in single lane, while data is
• sent using quad lane.
DRV_SQI_LANE_DUAL_ADDR_DATA Instruction opcode is sent in single lane, Address and Data are sent
• using dual lane.
DRV_SQI_LANE_QUAD_ADDR_DATA Instruction opcode is sent in single lane, Address and Data are sent
• using quad lane.
DRV_SQI_LANE_DUAL_ALL Instruction opcode, Address and Data are sent using dual lanes.
DRV_SQI_LANE_QUAD_ALL Instruction opcode, Address and Data are sent using quad lanes.
Description
SQI lane configuration options.
This enumeration lists the various lane configuration options provided by the driver.
Remarks
None.
DRV_SQI_TransferFrame Structure
Defines the transfer frame of the SQI driver.
File
drv_sqi.h
C
typedef struct {
uint8_t instruction;
uint32_t address;
uint8_t * data;
uint32_t length;
DRV_SQI_LANE_CONFIG laneCfg;
uint8_t option;
uint8_t numDummyBytes;
uint32_t flags;
} DRV_SQI_TransferFrame;
Members
Members Description
uint8_t instruction; 8-bit instruction opcode.
uint32_t address; 24/32-bit address.
uint8_t * data; Pointer to the source or destination buffer
uint32_t length; Length of the buffer in bytes.
DRV_SQI_LANE_CONFIG laneCfg; Lane Configuration.
uint8_t option; Option code associated with the current command.
uint8_t numDummyBytes; Optional number of dummy bytes associated with the current command.
uint32_t flags; This is bit-map field providing various configuration options for the
• current frame.
Description
SQI Driver transfer frame.
This data type defines the composition of a single transfer frame. In order to perform any operation on the SQI flash device, a one byte instruction
specifying the operation to be performed needs to be sent out. This is followed by optional address from/to which data is to be read/written, option,
dummy and data bytes.
The configuration options also indicate if data is transferred to/from the device.
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 914
Remarks
None.
Files
Files
Name Description
drv_sqi.h SQI Driver Interface Definition
drv_sqi_config_template.h SQI driver configuration definitions.
Description
This section lists the source and header files used by the SQI Driver Library.
drv_sqi.h
SQI Driver Interface Definition
Enumerations
Name Description
DRV_SQI_COMMAND_STATUS Specifies the status of the transfer request.
DRV_SQI_EVENT Identifies the possible events that can result from a transfer request.
DRV_SQI_LANE_CONFIG Defines the SQI lane configuration options.
DRV_SQI_SPI_OPERATION_MODE Enumeration of the SPI mode of operation supported by the SQI Controller.
DRV_SQI_TRANSFER_FLAGS Enumeration of the configuration options associated with a single transfer element.
Functions
Name Description
DRV_SQI_Close Closes an opened-instance of the SQI driver
DRV_SQI_CommandStatus Gets the current status of the transfer request.
DRV_SQI_Deinitialize Deinitializes the specified instance of the SQI driver module
DRV_SQI_EventHandlerSet Allows a client to register an event handling function, which the driver can invoke when the
queued transfer request has completed.
DRV_SQI_Initialize Initializes the SQI instance for the specified driver index
DRV_SQI_Open Opens the specified SQI driver instance and returns a handle to it.
DRV_SQI_Status Gets the current status of the SQI driver module.
DRV_SQI_Tasks Maintains the driver's task state machine.
DRV_SQI_TransferData Queue a data transfer operation on the specified SQI device.
DRV_SQI_TransferFrames Queue a transfer request operation on the SQI device.
Macros
Name Description
DRV_SQI_COMMAND_HANDLE_INVALID Identifies an invalid command handle.
DRV_SQI_FLAG_32_BIT_ADDR_ENABLE This is macro DRV_SQI_FLAG_32_BIT_ADDR_ENABLE.
DRV_SQI_FLAG_32_BIT_ADDR_ENABLE_MASK This is macro DRV_SQI_FLAG_32_BIT_ADDR_ENABLE_MASK.
DRV_SQI_FLAG_32_BIT_ADDR_ENABLE_POS Enables 32-bit addressing instead of 24-bit addressing.
DRV_SQI_FLAG_ADDR_ENABLE This is macro DRV_SQI_FLAG_ADDR_ENABLE.
DRV_SQI_FLAG_ADDR_ENABLE_MASK This is macro DRV_SQI_FLAG_ADDR_ENABLE_MASK.
DRV_SQI_FLAG_ADDR_ENABLE_POS Address Enable Macro.
DRV_SQI_FLAG_CRM_ENABLE This is macro DRV_SQI_FLAG_CRM_ENABLE.
DRV_SQI_FLAG_CRM_ENABLE_MASK This is macro DRV_SQI_FLAG_CRM_ENABLE_MASK.
DRV_SQI_FLAG_CRM_ENABLE_POS Continuous Read Mode Enable Macro.
DRV_SQI_FLAG_DATA_DIRECTION_MASK This is macro DRV_SQI_FLAG_DATA_DIRECTION_MASK.
DRV_SQI_FLAG_DATA_DIRECTION_POS Macros to select the direction of the transfers.
DRV_SQI_FLAG_DATA_DIRECTION_READ This is macro DRV_SQI_FLAG_DATA_DIRECTION_READ.
DRV_SQI_FLAG_DATA_DIRECTION_WRITE This is macro DRV_SQI_FLAG_DATA_DIRECTION_WRITE.
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 915
DRV_SQI_FLAG_DATA_ENABLE This is macro DRV_SQI_FLAG_DATA_ENABLE.
DRV_SQI_FLAG_DATA_ENABLE_MASK This is macro DRV_SQI_FLAG_DATA_ENABLE_MASK.
DRV_SQI_FLAG_DATA_ENABLE_POS Data Enable Macro.
DRV_SQI_FLAG_DATA_TARGET_MASK This is macro DRV_SQI_FLAG_DATA_TARGET_MASK.
DRV_SQI_FLAG_DATA_TARGET_MEMORY This is macro DRV_SQI_FLAG_DATA_TARGET_MEMORY.
DRV_SQI_FLAG_DATA_TARGET_POS Macros to select the source and destination of a transfer.
DRV_SQI_FLAG_DATA_TARGET_REGISTER This is macro DRV_SQI_FLAG_DATA_TARGET_REGISTER.
DRV_SQI_FLAG_DDR_ENABLE This is macro DRV_SQI_FLAG_DDR_ENABLE.
DRV_SQI_FLAG_DDR_ENABLE_MASK This is macro DRV_SQI_FLAG_DDR_ENABLE_MASK.
DRV_SQI_FLAG_DDR_ENABLE_POS DDR Enable Macro.
DRV_SQI_FLAG_INSTR_ENABLE This is macro DRV_SQI_FLAG_INSTR_ENABLE.
DRV_SQI_FLAG_INSTR_ENABLE_MASK This is macro DRV_SQI_FLAG_INSTR_ENABLE_MASK.
DRV_SQI_FLAG_INSTR_ENABLE_POS Macros listing the bitmap values for the flags member of the
DRV_SQI_TransferFrame structure. Instruction Enable Macro.
DRV_SQI_FLAG_OPT_ENABLE This is macro DRV_SQI_FLAG_OPT_ENABLE.
DRV_SQI_FLAG_OPT_ENABLE_MASK This is macro DRV_SQI_FLAG_OPT_ENABLE_MASK.
DRV_SQI_FLAG_OPT_ENABLE_POS Option Enable Macro.
DRV_SQI_FLAG_OPT_LENGTH This is macro DRV_SQI_FLAG_OPT_LENGTH.
DRV_SQI_FLAG_OPT_LENGTH_1BIT This is macro DRV_SQI_FLAG_OPT_LENGTH_1BIT.
DRV_SQI_FLAG_OPT_LENGTH_2BIT This is macro DRV_SQI_FLAG_OPT_LENGTH_2BIT.
DRV_SQI_FLAG_OPT_LENGTH_4BIT This is macro DRV_SQI_FLAG_OPT_LENGTH_4BIT.
DRV_SQI_FLAG_OPT_LENGTH_8BIT This is macro DRV_SQI_FLAG_OPT_LENGTH_8BIT.
DRV_SQI_FLAG_OPT_LENGTH_MASK This is macro DRV_SQI_FLAG_OPT_LENGTH_MASK.
DRV_SQI_FLAG_OPT_LENGTH_POS Macros to enable and specify the option length.
DRV_SQI_FLAG_SQI_CS_NUMBER This is macro DRV_SQI_FLAG_SQI_CS_NUMBER.
DRV_SQI_FLAG_SQI_CS_NUMBER_0 This is macro DRV_SQI_FLAG_SQI_CS_NUMBER_0.
DRV_SQI_FLAG_SQI_CS_NUMBER_1 This is macro DRV_SQI_FLAG_SQI_CS_NUMBER_1.
DRV_SQI_FLAG_SQI_CS_NUMBER_2 This is macro DRV_SQI_FLAG_SQI_CS_NUMBER_2.
DRV_SQI_FLAG_SQI_CS_NUMBER_3 This is macro DRV_SQI_FLAG_SQI_CS_NUMBER_3.
DRV_SQI_FLAG_SQI_CS_NUMBER_MASK This is macro DRV_SQI_FLAG_SQI_CS_NUMBER_MASK.
DRV_SQI_FLAG_SQI_CS_NUMBER_POS Macros to select the SQI CS Line Number to be used for the current transfer
• frame.
DRV_SQI_INDEX_0 SQI driver index definitions.
Structures
Name Description
DRV_SQI_TransferElement Defines the data transfer element of the SQI driver.
DRV_SQI_TransferFrame Defines the transfer frame of the SQI driver.
Types
Name Description
DRV_SQI_COMMAND_HANDLE Handle to identify the transfer request queued at the SQI driver.
DRV_SQI_EVENT_HANDLER Pointer to a SQI Driver Event handler function
Description
SQI Driver Interface Definition
The SQI driver provides data structures and interfaces to manage the SQI controller. This file contains the data structures and interface definitions
of the SQI driver.
File Name
drv_sqi.h
Company
Microchip Technology Inc.
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 916
drv_sqi_config_template.h
SQI driver configuration definitions.
Macros
Name Description
DRV_SQI_BUFFER_OBJECT_NUMBER Selects the maximum number of buffer objects
DRV_SQI_CLIENTS_NUMBER Selects the maximum number of clients
DRV_SQI_DMA_BUFFER_DESCRIPTORS_NUMBER Selects the maximum number of DMA Buffer descriptors to be used by the
driver.
DRV_SQI_INSTANCES_NUMBER Selects the maximum number of Driver instances that can be supported
by the dynamic driver.
DRV_SQI_INTERRUPT_MODE Macro specifies operation of the driver to be in the interrupt mode or polled
mode
Description
SQI Driver Configuration Template Header file.
This template file describes all the mandatory and optional configuration macros that are needed for building the SQI driver. Do not include this file
in source code.
File Name
drv_sqi_config_template.h
Company
Microchip Technology Inc.
SQI Flash Driver Library
This section describes the Serial Quad Interface (SQI) Flash Driver Library.
Introduction
This library provides an interface to manage the SST26VF family of SQI Flash devices in different modes of operation.
Description
The MPLAB Harmony SST26 SQI Flash Driver provides a high-level interface to manage the SST26VF family of Flash devices over the SQI
interface. The driver includes the following features:
• Provides application ready routines to perform block operations on the SQI Flash devices
• Supports Single, Dual, and Quad Lane modes
• Supports multi-client operation
• Provides data transfer events
• Supports non-blocking mode of operation only
• Thread-safe functions for use in RTOS applications
The SST26 Flash Driver uses the SQI module to establish the communication between SST26 Flash devices and Microchip microcontrollers. The
following diagram shows the pin connections that are required to make the driver operational:
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 917
The SST26 Flash driver supports multi-client operation. This feature allows multiple application clients to access the same Flash device. Multiple
instances of the driver can be used when multiple Flash devices are required to be part of the system.
Using the Library
This topic describes the basic architecture of the SQI Flash Driver Library and provides information and examples on its use.
Description
Interface Header Files: drv_sst26.h
The interface to the SQI Flash Driver Library is defined in the header file. Any C language source (.c) file that uses the SQI Flash Driver library
should include this header.
Please refer to the What is MPLAB Harmony? section for how the driver interacts with the framework.
Abstraction Model
This library provides a low-level abstraction of the SQI Flash Driver Library with a convenient C language interface. This topic describes how that
abstraction is modeled in software.
Description
The SST26 SQI Flash needs a specific set of commands to be given on its SQI interface along with the required address and data to do different
operations. This driver abstracts these requirements and provide simple APIs that can be used to perform Erase, Write, and Read operations. The
SQI Driver is used for this purpose. The following layered diagram depicts the communication between different modules.
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 918
Library Overview
Refer to the Driver Library Overview section for information on how the driver operates in a system.
The library interface routines are divided into various sub-sections, which address one of the blocks or the overall operation of the SQI Flash Driver
module.
Library Interface Section Description
System Functions These functions are accessed by the MPLAB Harmony System module and allow the
driver to be initialized, deinitialized, and maintained.
Core Client Functions These functions allow the application client to open and close the driver.
Block Operation Functions These functions enable the Flash module to be erased, written, and read (to/from).
Media Interface Functions These functions provide media status and the Flash geometry.
How the Library Works
This topic provides information on how the SQI Flash Driver Library works.
Description
System Functions
SST26 Driver Initialization
The system performs the initialization of the device driver with settings that affect only the instance of the device that is being initialized. During
system initialization each instance of the SST26 Flash driver would be initialized with the following configuration settings passed dynamically at run
time using DRV_SST26_INIT, that are supported by the specific SST26 Flash driver:
• sqiDevice: The SQI controller supports a maximum of two slave devices. This identifies the SQI device index on which the flash device is
located.
The DRV_SST26_Initialize function configures and initializes the SST26 Flash driver using the configuration information provided. It returns an
object handle of the type SYS_MODULE_OBJ. This object handle would be used by other system interfaces such as DRV_SST26_Status,
DRV_SST26_Tasks and DRV_SST26_Deinitialize.
Example:
/*** SST26 FLASH Driver Initialization Data ***/
const DRV_SST26_INIT drvSst26InitData0 =
{
.sqiDevice = 1,
};
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 919
/* Initialize the SST26 Driver */
sysObj.drvSst26Obj0 = DRV_SST26_Initialize(DRV_SST26_INDEX_0,
(SYS_MODULE_INIT *)&drvSst26InitData0);
SST26 Flash Driver Task Routine
The SST26 Driver task routine DRV_SST26_Tasks, will be called from the system task routine, SYS_Tasks. The driver task routine is responsible
maintaining the driver state machine. The block operation requests from the application or from other modules are added to the driver queue. The
task routine processes these queued requests by invoking the SQI driver routines for handling the transfer to the flash media.
SST26 Flash Driver Status
DRV_SST26_Status returns the current status of the SST26 Flash driver and is called by MPLAB Harmony. The application may not find the need
to call this function directly.
Example:
SYS_MODULE_OBJ object;
// Returned from DRV_SST26_Initialize
SYS_STATUS sst26Status;
sst26Status = DRV_SST26_Status(object);
if (SYS_STATUS_ERROR >= sst26Status)
{
// Handle error
}
Client Core Functions
Opening the Driver
For the application to start using an instance of the module, it must call the DRV_SST26_Open function repeatedly until a valid handle is returned
by the driver. The application client uses this driver handle to access the driver functions.
For the various options available for I/O INTENT please refer to Data Types and Constants in the Library Interface section.
Example:
handle = DRV_SST26_Open(DRV_SST26_INDEX_0,
DRV_IO_INTENT_EXCLUSIVE);
if (DRV_HANDLE_INVALID == handle)
{
/* Call until the function returns a valid handle. */
}
else
{
/* Do further processing. */
}
Closing the Driver
DRV_SST26_Close closes an opened-instance of the SST26 Flash driver, which also invalidates the driver handle. The application must open the
driver again to obtain a valid handle.
Example:
DRV_HANDLE handle; // Returned from DRV_SST26_Open
DRV_SST26_Close(handle);
Client Block Operation Functions
The driver provides client interfaces to perform operations in terms of blocks. A block is a unit that represents the minimum amount of data that
can be erased, written, or read. The block sizes may differ for Erase, Write, and Read operations. The DRV_SST26_GeometryGet function can be
used to read out the geometry of the flash device. The geometry indicates the number of read, write and erase regions, blocks per region and the
size of each block.
The DRV_SST26_Erase, DRV_SST26_Write, and DRV_SST26_Read functions are used to erase, write, and read the data to/from SST26 Flash
devices. In addition to these functions, the driver also provides the DRV_SST26_EraseWrite function that combines the step of erasing a sector
and then writing a page. The application can use this function if it wants to avoid having to explicitly delete a sector in order to update the pages
contained in the sector.
These functions are non-blocking in nature and queue the operation request into the driver queue. All of the requests in the queue are executed by
the DRV_SST26_Tasks function one-by-one. A command handle associated with the operation request is returned to the application client when
the operation request is queued at the driver. This handle allows the application client to track the request as it progresses through the queue. The
handle expires when the request processing is complete. The driver provides events (DRV_SST26_EVENT) that indicate the completion of the
requests.
The following steps can be used for a simple Block Data Operation:
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 920
1. The system should have completed necessary initialization of the SQI Driver and the SST26 Flash Driver, and the DRV_SST26_Tasks function
should be running in a polled environment.
2. Open the driver using DRV_SST26_Open with the necessary intent.
3. Set an event handler callback using the function DRV_SST26_EventHandlerSet.
4. Request for block operations using the functions, DRV_SST26_Erase, DRV_SST26_Write, DRV_SST26_Read and DRV_SST26_EraseWrite
with the appropriate parameters.
5. Wait for event handler callback to occur and check the status of the block operation using the callback function parameter of type
DRV_SST26_ EVENT.
6. After performing the required block operations, the client can close the driver using the function , DRV_SST25VF020B_Close .
Example:
// myAppObj is an application specific state data object.
MY_APP_OBJ myAppObj;
uint8_t myBuffer[MY_BUFFER_SIZE];
uint32_t blockStart, nBlock;
DRV_SST26_COMMAND_HANDLE commandHandle;
// drvSST26Handle is the handle returned by the DRV_SST26_Open
// function. Client registers an event handler with driver. This is done once.
DRV_SST26_EventHandlerSet(drvSST26Handle, APP_SST26EventHandler, (uintptr_t)&myAppObj);
DRV_SST26_Read(drvSST26Handle, &commandHandle, &myBuffer, blockStart, nBlock);
if(DRV_SST26_COMMAND_HANDLE_INVALID == commandHandle)
{
// Error handling here
}
// Event Processing Technique. Event is received when operation is done.
void APP_SST26EventHandler
(
DRV_SST26_EVENT event,
DRV_SST26_COMMAND_HANDLE commandHandle,
uintptr_t contextHandle
)
{
// The context handle was set to an application specific
// object. It is now retrievable easily in the event
// handler.
MY_APP_OBJ myAppObj = (MY_APP_OBJ *) context;
switch(event)
{
case DRV_SST26_EVENT_COMMAND_COMPLETE:
// Operation completed successfully.
break;
case DRV_SST26_EVENT_COMMAND_ERROR:
// Error handling here.
break;
default:
break;
}
}
Media Interface Functions
Reading the Device Geometry
The application can call the DRV_SST26_GeometryGet function to obtain the geometry of the flash device. The geometry indicates the number of
read, write and erase regions, number of blocks per region and the size of each block.
Example:
SYS_FS_MEDIA_GEOMETRY * sst26FlashGeometry;
uint32_t readBlockSize, writeBlockSize, eraseBlockSize;
uint32_t nReadBlocks, nReadRegions, totalFlashSize;
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 921
sst26FlashGeometry = DRV_SST26_GeometryGet(sst26OpenHandle1);
readBlockSize = sst26FlashGeometry->geometryTable->blockSize;
nReadBlocks = sst26FlashGeometry->geometryTable->numBlocks;
nReadRegions = sst26FlashGeometry->numReadRegions;
writeBlockSize = (sst26FlashGeometry->geometryTable +1)->blockSize;
eraseBlockSize = (sst26FlashGeometry->geometryTable +2)->blockSize;
//The below expression provides the flash memory size.
totalFlashSize = readBlockSize * nReadBlocks * nReadRegions;
Configuring the Library
Macros
Name Description
DRV_SST26_BUFFER_OBJECT_NUMBER Selects the maximum number of buffer objects
DRV_SST26_CLIENTS_NUMBER Selects the maximum number of clients
DRV_SST26_INSTANCES_NUMBER Selects the maximum number of Driver instances that can be supported by the
dynamic driver.
DRV_SST26_SYS_FS_REGISTER Register to use with the File system
Description
The SQI Flash Driver requires the specification of compile-time configuration macros. These macros define resource usage, feature availability,
and dynamic behavior of the driver. These configuration macros should be defined in the system_config.h file.
This header can be placed anywhere, the path of this header needs to be present in the include search path for a successful build. Refer to the
Applications Help section for more details.
DRV_SST26_BUFFER_OBJECT_NUMBER Macro
Selects the maximum number of buffer objects
File
drv_sst26_config_template.h
C
#define DRV_SST26_BUFFER_OBJECT_NUMBER 5
Description
SST26 Driver maximum number of buffer objects
This definition selects the maximum number of buffer objects. This indirectly also specifies the queue depth. The SST26 Driver can queue up
DRV_SST26_BUFFER_OBJECT_NUMBER of read/write/erase requests before return a DRV_SST26_BUFFER_HANDLE_INVALID due to the
queue being full. Buffer objects are shared by all instances of the driver. Increasing this number increases the RAM requirement of the driver.
Remarks
This macro is mandatory when building the driver for dynamic operation.
DRV_SST26_CLIENTS_NUMBER Macro
Selects the maximum number of clients
File
drv_sst26_config_template.h
C
#define DRV_SST26_CLIENTS_NUMBER 1
Description
SST26 maximum number of clients
This definition selects the maximum number of clients that the SST26 driver can supported at run time. This constant defines the total number of
SST26 driver clients that will be available to all instances of the SST26 driver.
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 922
Remarks
This macro is mandatory when building the driver for dynamic operation.
DRV_SST26_INSTANCES_NUMBER Macro
Selects the maximum number of Driver instances that can be supported by the dynamic driver.
File
drv_sst26_config_template.h
C
#define DRV_SST26_INSTANCES_NUMBER 1
Description
SST26 Driver instance configuration
This definition selects the maximum number of Driver instances that can be supported by the dynamic driver. In case of this driver, multiple
instances of the driver could use the same hardware instance.
Remarks
This macro is mandatory when building the driver for dynamic operation.
DRV_SST26_SYS_FS_REGISTER Macro
Register to use with the File system
File
drv_sst26_config_template.h
C
#define DRV_SST26_SYS_FS_REGISTER
Description
SST26 Driver Register with File System
Specifying this macro enables the SST26 driver to register its services with the SYS FS.
Remarks
This macro is optional and should be specified only if the SST26 driver is to be used with the File System.
Building the Library
This section lists the files that are available in the SQI Flash Driver Library.
Description
This section list the files that are available in the /src folder of the SQI Flash Driver. It lists which files need to be included in the build based on
either a hardware feature present on the board or configuration option selected by the system.
The following three tables list and describe the header (.h) and source (.c) files that implement this library. The parent folder for these files is
/framework/driver/sqi_flash.
Interface File(s)
This table lists and describes the header files that must be included (i.e., using #include) by any code that uses this library.
Source File Name Description
sst26/drv_sst26.h Header file that exports the SST26VF driver API.
Required File(s)
All of the required files listed in the following table are automatically added into the MPLAB X IDE project by the MHC
when the library is selected for use.
This table lists and describes the source and header files that must always be included in the MPLAB X IDE project to build this library.
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 923
Source File Name Description
sst26/src/dynamic/drv_sst26.c Basic SQI Flash Driver SST26VF implementation file.
Optional File(s)
This table lists and describes the source and header files that may optionally be included if required for the desired implementation.
Source File Name Description
N/A No optional files are available for this library
Module Dependencies
The SQI Flash Driver Library depends on the following modules:
• SQI Driver Library
• Ports System Service Library
Library Interface
a) System Functions
Name Description
DRV_SST26_Initialize Initializes the SST26 instance for the specified driver index
DRV_SST26_Deinitialize Deinitializes the specified instance of the SST26 driver module
DRV_SST26_Status Gets the current status of the SST26 driver module.
DRV_SST26_Tasks Maintains the SST26 driver's internal state machine.
b) Core Client Functions
Name Description
DRV_SST26_Open Opens the specified SST26 driver instance and returns a handle to it
DRV_SST26_Close Closes an opened-instance of the SST26 driver
c) Block Operation Functions
Name Description
DRV_SST26_Erase Erase the specified number of flash blocks from the specified block start address.
DRV_SST26_EraseWrite Erase and Write blocks of data starting from a specified block start address.
DRV_SST26_Read Reads blocks of data from the specified block start address.
DRV_SST26_Write Writes blocks of data starting at the specified block start address.
DRV_SST26_CommandStatus Gets the current status of the command.
DRV_SST26_EventHandlerSet Allows a client to identify an event handling function for the driver to call back when queued
operation has completed.
d) Media Interface Functions
Name Description
DRV_SST26_AddressGet Returns the SST26 media start address
DRV_SST26_GeometryGet Returns the geometry of the device.
DRV_SST26_IsAttached Returns the physical attach status of the SST26.
DRV_SST26_IsWriteProtected Returns the write protect status of the SST26.
e) Data Types and Constants
Name Description
DRV_SST26_COMMAND_HANDLE Handle identifying commands queued in the driver.
DRV_SST26_COMMAND_STATUS SST26 Driver command Status
DRV_SST26_EVENT Identifies the possible events that can result from a request.
DRV_SST26_EVENT_HANDLER Pointer to a SST26 Driver Event handler function
DRV_SST26_INIT Defines the data required to initialize or reinitialize the SST26 driver
DRV_SST26_COMMAND_HANDLE_INVALID This value defines the SST26 Driver's Invalid Command Handle.
DRV_SST26_INDEX_0 SST26 driver index definitions
DRV_SST26_INDEX_1 This is macro DRV_SST26_INDEX_1.
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 924
Description
This section describes the API functions of the SQI Flash Driver Library.
Refer to each section for a detailed description.
a) System Functions
DRV_SST26_Initialize Function
Initializes the SST26 instance for the specified driver index
File
drv_sst26.h
C
SYS_MODULE_OBJ DRV_SST26_Initialize(const SYS_MODULE_INDEX index, const SYS_MODULE_INIT * const init);
Returns
If successful, returns a valid handle to a driver instance object. Otherwise it returns SYS_MODULE_OBJ_INVALID.
Description
This routine initializes the SST26 driver instance for the specified driver index, making it ready for clients to open and use it.
Remarks
This routine must be called before any other SST26 routine is called.
This routine should only be called once during system initialization unless DRV_SST26_Deinitialize is called to deinitialize the driver instance.
This routine will NEVER block for hardware access. If the operation requires time to allow the hardware to initialize, it will be reported by the
DRV_SST26_Status operation. The system must use DRV_SST26_Status to find out when the driver is in the ready state.
Preconditions
None.
Example
// This code snippet shows an example of initializing the SST26 Driver.
SYS_MODULE_OBJ objectHandle;
const DRV_SST26_INIT drvSst26InitData0 =
{
.sqiDevice = 1,
};
//usage of DRV_SST26_INDEX_0 indicates usage of Flash-related APIs
objectHandle = DRV_SST26_Initialize(DRV_SST26_INDEX_0, (SYS_MODULE_INIT*)&drvSst26InitData0);
if (SYS_MODULE_OBJ_INVALID == objectHandle)
{
// Handle error
}
Parameters
Parameters Description
index Identifier for the instance to be initialized
init Pointer to a data structure containing any data necessary to initialize the driver.
Function
SYS_MODULE_OBJ DRV_SST26_Initialize
(
const SYS_MODULE_INDEX index,
const SYS_MODULE_INIT * const init
);
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 925
DRV_SST26_Deinitialize Function
Deinitializes the specified instance of the SST26 driver module
File
drv_sst26.h
C
void DRV_SST26_Deinitialize(SYS_MODULE_OBJ object);
Returns
None.
Description
Deinitializes the specified instance of the SST26 driver module, disabling its operation (and any hardware). Invalidates all the internal data.
Remarks
Once the Initialize operation has been called, the Deinitialize operation must be called before the Initialize operation can be called again.
Preconditions
Function DRV_SST26_Initialize should have been called before calling this function.
Parameter: object - Driver object handle, returned from the DRV_SST26_Initialize routine
Example
// This code snippet shows an example of deinitializing the driver.
SYS_MODULE_OBJ object; // Returned from DRV_SST26_Initialize
SYS_STATUS status;
DRV_SST26_Deinitialize(object);
status = DRV_SST26_Status(object);
if (SYS_MODULE_DEINITIALIZED != status)
{
// Check again later if you need to know when the driver is
// deinitialized.
}
Function
void DRV_SST26_Deinitialize
(
SYS_MODULE_OBJ object
);
DRV_SST26_Status Function
Gets the current status of the SST26 driver module.
File
drv_sst26.h
C
SYS_STATUS DRV_SST26_Status(SYS_MODULE_OBJ object);
Returns
SYS_STATUS_READY - Indicates that the driver is ready and accept requests for new operations.
SYS_STATUS_UNINITIALIZED - Indicates the driver is not initialized.
Description
This routine provides the current status of the SST26 driver module.
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 926
Remarks
This routine will NEVER block waiting for hardware.
Preconditions
Function DRV_SST26_Initialize should have been called before calling this function.
Example
SYS_MODULE_OBJ object; // Returned from DRV_SST26_Initialize
SYS_STATUS SST26Status;
SST26Status = DRV_SST26_Status(object);
else if (SYS_STATUS_ERROR >= SST26Status)
{
// Handle error
}
Parameters
Parameters Description
object Driver object handle, returned from the DRV_SST26_Initialize routine
Function
SYS_STATUS DRV_SST26_Status
(
SYS_MODULE_OBJ object
);
DRV_SST26_Tasks Function
Maintains the SST26 driver's internal state machine.
File
drv_sst26.h
C
void DRV_SST26_Tasks(SYS_MODULE_OBJ object);
Returns
None.
Description
This routine maintains the driver's internal state machine. Part of the driver initialization is done in this routine. This routine is responsible for
processing the read, write, erase or erasewrite requests queued for the SST26 driver.
Remarks
This routine is normally not called directly by an application. It is called by the system's Tasks routine (SYS_Tasks).
This routine may execute in an ISR context and will never block or access any resources that may cause it to block.
Preconditions
The DRV_SST26_Initialize routine must have been called for the specified SST26 driver instance.
Example
SYS_MODULE_OBJ object; // Returned from DRV_SST26_Initialize
while (true)
{
DRV_SST26_Tasks (object);
// Do other tasks
}
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 927
Parameters
Parameters Description
object Object handle for the specified driver instance (returned from DRV_SST26_Initialize)
Function
void DRV_SST26_Tasks
(
SYS_MODULE_OBJ object
);
b) Core Client Functions
DRV_SST26_Open Function
Opens the specified SST26 driver instance and returns a handle to it
File
drv_sst26.h
C
DRV_HANDLE DRV_SST26_Open(const SYS_MODULE_INDEX index, const DRV_IO_INTENT ioIntent);
Returns
If successful, the routine returns a valid open-instance handle (a number identifying both the caller and the module instance).
If an error occurs, DRV_HANDLE_INVALID is returned. Errors can occur under the following circumstances:
• if the number of client objects allocated via DRV_SST26_CLIENTS_NUMBER is insufficient
• if the client is trying to open the driver but driver has been opened exclusively by another client
• if the client is trying to open the driver exclusively, but has already been opened in a non exclusive mode by another client.
• if the driver hardware instance being opened is not initialized or is invalid
Description
This routine opens the specified SST26 driver instance and provides a handle. This handle must be provided to all other client-level operations to
identify the caller and the instance of the driver.
Remarks
The handle returned is valid until the DRV_SST26_Close routine is called. This routine will NEVER block waiting for hardware. If the driver has has
already been opened, it cannot be opened exclusively.
Preconditions
Function DRV_SST26_Initialize must have been called before calling this function.
Example
DRV_HANDLE handle;
handle = DRV_SST26_Open(DRV_SST26_INDEX_0, DRV_IO_INTENT_EXCLUSIVE);
if (DRV_HANDLE_INVALID == handle)
{
// Unable to open the driver
}
Parameters
Parameters Description
index Identifier for the object instance to be opened
intent Zero or more of the values from the enumeration DRV_IO_INTENT "ORed" together to
indicate the intended use of the driver
Function
DRV_HANDLE DRV_SST26_Open
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 928
(
const SYS_MODULE_INDEX index,
const DRV_IO_INTENT ioIntent
);
DRV_SST26_Close Function
Closes an opened-instance of the SST26 driver
File
drv_sst26.h
C
void DRV_SST26_Close(const DRV_HANDLE handle);
Returns
None
Description
This routine closes an opened-instance of the SST26 driver, invalidating the handle.
Remarks
After calling this routine, the handle passed in "handle" must not be used with any of the remaining driver routines. A new handle must be obtained
by calling DRV_SST26_Open before the caller may use the driver again. Usually there is no need for the driver client to verify that the Close
operation has completed.
Preconditions
The DRV_SST26_Initialize routine must have been called for the specified SST26 driver instance.
DRV_SST26_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE handle; // Returned from DRV_SST26_Open
DRV_SST26_Close(handle);
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
void DRV_SST26_Close
(
const DRV_HANDLE handle
);
c) Block Operation Functions
DRV_SST26_Erase Function
Erase the specified number of flash blocks from the specified block start address.
File
drv_sst26.h
C
void DRV_SST26_Erase(const DRV_HANDLE handle, DRV_SST26_COMMAND_HANDLE * commandHandle, uint32_t
blockStart, uint32_t nBlock);
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 929
Returns
The command handle is returned in the commandHandle argument. It Will be DRV_SST26_COMMAND_HANDLE_INVALID if the request was not
queued.
Description
This function schedules a non-blocking erase operation of flash memory. The function returns with a valid erase handle in the commandHandle
argument if the erase request was scheduled successfully. The function adds the request to the hardware instance queue and returns
immediately. The function returns DRV_SST26_COMMAND_HANDLE_INVALID in the commandHandle argument under the following
circumstances:
• if a buffer object could not be allocated to the request
• if the client opened the driver for read only
• if the number of blocks to be erased is either zero or more than the number of blocks actually available
• if the driver handle is invalid
If the requesting client registered an event callback with the driver, the driver will issue a DRV_SST26_EVENT_COMMAND_COMPLETE event if
the erase operation was successful or DRV_SST26_EVENT_COMMAND_ERROR event if the erase operation was not successful.
Remarks
None.
Preconditions
The DRV_SST26_Initialize() routine must have been called for the specified SST26 driver instance.
The DRV_SST26_Open() routine must have been called with DRV_IO_INTENT_WRITE or DRV_IO_INTENT_READWRITE to obtain a valid
opened device handle.
Example
// Use DRV_SST26_GeometryGet () to find the read region geometry.
// Find the erase block start address from where the number of blocks
// should be erased.
uint32_t blockStart = 0;
uint32_t nBlock = 4;
DRV_SST26_COMMAND_HANDLE commandHandle;
MY_APP_OBJ myAppObj;
// mySST26Handle is the handle returned by the DRV_SST26_Open function.
// Client registers an event handler with driver
DRV_SST26_EventHandlerSet(mySST26Handle, APP_SST26EventHandler, (uintptr_t)&myAppObj);
DRV_SST26_Erase( mySST26Handle, &commandHandle, blockStart, nBlock );
if(DRV_SST26_COMMAND_HANDLE_INVALID == commandHandle)
{
// Error handling here
}
// Event is received when the buffer queue is processed.
void APP_SST26EventHandler
(
DRV_SST26_EVENT event,
DRV_SST26_COMMAND_HANDLE commandHandle,
uintptr_t contextHandle
)
{
// contextHandle points to myAppObj.
switch(event)
{
case DRV_SST26_EVENT_COMMAND_COMPLETE:
// Erase operation completled successfully.
break;
case DRV_SST26_EVENT_COMMAND_ERROR:
// Error handling here.
break;
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 930
default:
break;
}
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
commandHandle Pointer to an argument that will contain the return buffer handle
blockStart Erase block start address from where the blocks should be erased.
nBlock Total number of blocks to be erased.
Function
void DRV_SST26_Erase
(
const DRV_HANDLE handle,
DRV_SST26_COMMAND_HANDLE * commandHandle,
uint32_t blockStart,
uint32_t nBlock
);
DRV_SST26_EraseWrite Function
Erase and Write blocks of data starting from a specified block start address.
File
drv_sst26.h
C
void DRV_SST26_EraseWrite(const DRV_HANDLE handle, DRV_SST26_COMMAND_HANDLE * commandHandle, void *
sourceBuffer, uint32_t writeBlockStart, uint32_t nWriteBlock);
Returns
The command handle is returned in the commandHandle argument. It Will be DRV_SST26_COMMAND_HANDLE_INVALID if the request was not
queued.
Description
This function combines the step of erasing a sector and then writing the page. The application can use this function if it wants to avoid having to
explicitly delete a sector in order to update the pages contained in the sector.
This function schedules a non-blocking operation to erase and write blocks of data into flash memory. The function returns with a valid command
handle in the commandHandle argument if the write request was scheduled successfully. The function adds the request to the hardware instance
queue and returns immediately. While the request is in the queue, the application buffer is owned by the driver and should not be modified. The
function returns DRV_SST26_COMMAND_HANDLE_INVALID in the commandHandle argument under the following circumstances:
• if a buffer could not be allocated to the request
• if the input buffer pointer is NULL
• if the client opened the driver for read only
• if the number of blocks to be written is either zero or more than the number of blocks actually available
• if the driver handle is invalid
If the requesting client registered an event callback with the driver, the driver will issue a DRV_SST26_EVENT_COMMAND_COMPLETE event if
the buffer was processed successfully or DRV_SST26_EVENT_COMMAND_ERROR event if the buffer was not processed successfully.
Remarks
None.
Preconditions
The DRV_SST26_Initialize() routine must have been called for the specified SST26 driver instance.
The DRV_SST26_Open() must have been called with DRV_IO_INTENT_WRITE or DRV_IO_INTENT_READWRITE as a parameter to obtain a
valid opened device handle.
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 931
Example
uint8_t myBuffer[MY_BUFFER_SIZE];
// Use DRV_SST26_GeometryGet () to find the write region geometry.
// Find the block address to which data is to be written.
uint32_t blockStart = SST26_BLOCK_ADDRESS_TO_WRITE_TO;
uint32_t nBlock = 2;
DRV_SST26_COMMAND_HANDLE commandHandle;
MY_APP_OBJ myAppObj;
// mySST26Handle is the handle returned by the DRV_SST26_Open function.
// Client registers an event handler with driver
DRV_SST26_EventHandlerSet(mySST26Handle, APP_SST26EventHandler, (uintptr_t)&myAppObj);
DRV_SST26_EraseWrite(mySST26Handle, &commandHandle, &myBuffer, blockStart, nBlock);
if(DRV_SST26_COMMAND_HANDLE_INVALID == commandHandle)
{
// Error handling here
}
// Event is received when the buffer is processed.
void APP_SST26EventHandler
(
DRV_SST26_EVENT event,
DRV_SST26_COMMAND_HANDLE commandHandle,
uintptr_t contextHandle
)
{
// contextHandle points to myAppObj.
switch(event)
{
case DRV_SST26_EVENT_COMMAND_COMPLETE:
// Operation completled successfully.
break;
case DRV_SST26_EVENT_COMMAND_ERROR:
// Error handling here.
break;
default:
break;
}
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
commandHandle Pointer to an argument that will contain the return command handle. If NULL, then command
handle is not returned.
sourceBuffer The source buffer containing data to be programmed into SST26 Flash
writeBlockStart Write block start address where the write should begin.
nWriteBlock Total number of blocks to be written.
Function
void DRV_SST26_EraseWrite
(
const DRV_HANDLE handle,
DRV_SST26_COMMAND_HANDLE * commandHandle,
void * sourceBuffer,
uint32_t writeBlockStart,
uint32_t nWriteBlock
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 932
);
DRV_SST26_Read Function
Reads blocks of data from the specified block start address.
File
drv_sst26.h
C
void DRV_SST26_Read(const DRV_HANDLE handle, DRV_SST26_COMMAND_HANDLE * commandHandle, void * targetBuffer,
uint32_t blockStart, uint32_t nBlock);
Returns
The command handle is returned in the commandHandle argument. It will be DRV_SST26_COMMAND_HANDLE_INVALID if the request was not
successful.
Description
This function schedules a non-blocking read operation for reading blocks of data from the flash memory. The function returns with a valid
command handle in the commandHandle argument if the request was scheduled successfully. The function adds the request to the hardware
instance queue and returns immediately. While the request is in the queue, the application buffer is owned by the driver and should not be
modified. The function returns DRV_SST26_COMMAND_HANDLE_INVALID in the commandHandle argument under the following circumstances:
• if a buffer object could not be allocated to the request
• if the target buffer pointer is NULL
• if the client opened the driver for write only
• if the number of blocks to be read is either zero or more than the number of blocks actually available
• if the driver handle is invalid
Remarks
None.
Preconditions
The DRV_SST26_Initialize routine must have been called for the specified SST26 driver instance.
DRV_SST26_Open must have been called with DRV_IO_INTENT_READ or DRV_IO_INTENT_READWRITE as the ioIntent to obtain a valid
opened device handle.
Example
uint8_t myBuffer[MY_BUFFER_SIZE];
// Use DRV_SST26_GeometryGet () to find the read region geometry.
// Find the block address from which to read data.
uint32_t blockStart = SST26_BLOCK_ADDRESS_TO_READ_FROM;
uint32_t nBlock = 2;
DRV_SST26_COMMAND_HANDLE commandHandle;
MY_APP_OBJ myAppObj;
// mySST26Handle is the handle returned by the DRV_SST26_Open function.
// Client registers an event handler with driver
DRV_SST26_EventHandlerSet(mySST26Handle, APP_SST26EventHandler, (uintptr_t)&myAppObj);
DRV_SST26_Read(mySST26Handle, &commandHandle, &myBuffer, blockStart, nBlock);
if(DRV_SST26_COMMAND_HANDLE_INVALID == commandHandle)
{
// Error handling here
}
else
{
// Read queued successfully.
}
// Event is received when the command request is processed.
void APP_SST26EventHandler
(
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 933
DRV_SST26_EVENT event,
DRV_SST26_COMMAND_HANDLE commandHandle,
uintptr_t contextHandle
)
{
// contextHandle points to myAppObj.
switch(event)
{
case DRV_SST26_EVENT_COMMAND_COMPLETE:
// This means the data was transferred.
break;
case DRV_SST26_EVENT_COMMAND_ERROR:
// Error handling here.
break;
default:
break;
}
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
commandHandle Pointer to an argument that will contain the command handle
targetBuffer Buffer into which the data read from the SST26 Flash memory will be placed
blockStart Read block start address from where the data should be read.
nBlock Total number of blocks to be read.
Function
void DRV_SST26_Read
(
const DRV_HANDLE handle,
DRV_SST26_COMMAND_HANDLE * commandHandle,
void * targetBuffer,
uint32_t blockStart,
uint32_t nBlock
);
DRV_SST26_Write Function
Writes blocks of data starting at the specified block start address.
File
drv_sst26.h
C
void DRV_SST26_Write(const DRV_HANDLE handle, DRV_SST26_COMMAND_HANDLE * commandHandle, void *
sourceBuffer, uint32_t blockStart, uint32_t nBlock);
Returns
The command handle is returned in the commandHandle argument. It will be DRV_SST26_COMMAND_HANDLE_INVALID if the request was not
successful.
Description
This function schedules a non-blocking write operation for writing blocks of data into flash memory. The function returns with a valid command
handle in the commandHandle argument if the write request was scheduled successfully. The function adds the request to the hardware instance
queue and returns immediately. While the request is in the queue, the application buffer is owned by the driver and should not be modified. The
function returns DRV_SST26_COMMAND_HANDLE_INVALID in the commandHandle argument under the following circumstances:
• if a buffer object could not be allocated to the request
• if the source buffer pointer is NULL
• if the client opened the driver for read only
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 934
• if the number of blocks to be written is either zero or more than the number of blocks actually available
• if the driver handle is invalid
If the requesting client registered an event callback with the driver, the driver will issue a DRV_SST26_EVENT_COMMAND_COMPLETE event if
the buffer was processed successfully or DRV_SST26_EVENT_COMMAND_ERROR event if the buffer was not processed successfully.
Remarks
None.
Preconditions
The DRV_SST26_Initialize() routine must have been called for the specified SST26 driver instance.
DRV_SST26_Open() routine must have been called to obtain a valid opened device handle. DRV_IO_INTENT_WRITE or
DRV_IO_INTENT_READWRITE must have been specified as a parameter to this routine.
The flash address location which has to be written, must have be erased before using the DRV_SST26_Erase() routine.
Example
uint8_t myBuffer[MY_BUFFER_SIZE];
// Use DRV_SST26_GeometryGet () to find the write region geometry.
// Find the block address to which data is to be written.
uint32_t blockStart = SST26_BLOCK_ADDRESS_TO_WRITE_TO;
uint32_t nBlock = 2;
DRV_SST26_COMMAND_HANDLE commandHandle;
MY_APP_OBJ myAppObj;
// mySST26Handle is the handle returned by the DRV_SST26_Open function.
// Client registers an event handler with driver
DRV_SST26_EventHandlerSet(mySST26Handle, APP_SST26EventHandler, (uintptr_t)&myAppObj);
DRV_SST26_Write(mySST26Handle, &commandHandle, &myBuffer, blockStart, nBlock);
if(DRV_SST26_COMMAND_HANDLE_INVALID == commandHandle)
{
// Error handling here
}
// Event is received when the buffer is processed.
void APP_SST26EventHandler
(
DRV_SST26_EVENT event,
DRV_SST26_COMMAND_HANDLE commandHandle,
uintptr_t contextHandle
)
{
// contextHandle points to myAppObj.
switch(event)
{
case DRV_SST26_EVENT_COMMAND_COMPLETE:
// This means the data was transferred.
break;
case DRV_SST26_EVENT_COMMAND_ERROR:
// Error handling here.
break;
default:
break;
}
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
commandHandle Pointer to an argument that will contain the return buffer handle
sourceBuffer The source buffer containing data to be programmed into SST26 Flash
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 935
blockStart Write block start address from where the data should be written to.
nBlock Total number of blocks to be written.
Function
void DRV_SST26_Write
(
const DRV_HANDLE handle,
DRV_SST26_COMMAND_HANDLE * commandHandle,
void * sourceBuffer,
uint32_t blockStart,
uint32_t nBlock
);
DRV_SST26_CommandStatus Function
Gets the current status of the command.
File
drv_sst26.h
C
DRV_SST26_COMMAND_STATUS DRV_SST26_CommandStatus(const DRV_HANDLE handle, const DRV_SST26_COMMAND_HANDLE
commandHandle);
Returns
A DRV_SST26_COMMAND_STATUS value describing the current status of the command. Returns
DRV_SST26_COMMAND_HANDLE_INVALID if the client handle or the command handle is not valid.
Description
This routine gets the current status of the command. The application must use this routine where the status of a scheduled command needs to be
polled on. The function may return DRV_SST26_COMMAND_COMPLETED in a case where the command handle has expired. A command
handle expires when the internal buffer object is re-assigned to another request. It is recommended that this function be called regularly in order to
track the command status correctly.
The application can alternatively register an event handler to receive the command completion events.
Remarks
This routine will not block for hardware access and will immediately return the current status.
Preconditions
The DRV_SST26_Initialize() routine must have been called.
The DRV_SST26_Open() must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE handle; // Returned from DRV_SST26_Open
DRV_SST26_COMMAND_HANDLE commandHandle;
DRV_SST26_COMMAND_STATUS status;
status = DRV_SST26_CommandStatus(handle, commandHandle);
if(status == DRV_SST26_COMMAND_COMPLETED)
{
// Operation Done
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
DRV_SST26_COMMAND_STATUS DRV_SST26_CommandStatus
(
const DRV_HANDLE handle,
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 936
const DRV_SST26_COMMAND_HANDLE commandHandle
);
DRV_SST26_EventHandlerSet Function
Allows a client to identify an event handling function for the driver to call back when queued operation has completed.
File
drv_sst26.h
C
void DRV_SST26_EventHandlerSet(const DRV_HANDLE handle, const void * eventHandler, const uintptr_t context);
Returns
None.
Description
This function allows a client to identify an event handling function for the driver to call back when queued operation has completed. When a client
calls a read, write, erase or a erasewrite function, it is provided with a handle identifying the command that was added to the driver's buffer queue.
The driver will pass this handle back to the client by calling "eventHandler" function when the queued operation has completed.
The event handler should be set before the client performs any operations that could generate events. The event handler once set, persists until
the client closes the driver or sets another event handler (which could be a "NULL" pointer to indicate no callback).
Remarks
If the client does not want to be notified when the queued operation has completed, it does not need to register a callback.
Preconditions
The DRV_SST26_Initialize() routine must have been called for the specified SST26 driver instance.
The DRV_SST26_Open() routine must have been called to obtain a valid opened device handle.
Example
// myAppObj is an application specific state data object.
MY_APP_OBJ myAppObj;
uint8_t myBuffer[MY_BUFFER_SIZE];
uint32_t blockStart, nBlock;
DRV_SST26_COMMAND_HANDLE commandHandle;
// drvSST26Handle is the handle returned by the DRV_SST26_Open function.
// Client registers an event handler with driver. This is done once.
DRV_SST26_EventHandlerSet(drvSST26Handle, APP_SST26EventHandler, (uintptr_t)&myAppObj);
DRV_SST26_Read(drvSST26Handle, &commandHandle, &myBuffer, blockStart, nBlock);
if(DRV_SST26_COMMAND_HANDLE_INVALID == commandHandle)
{
// Error handling here
}
// Event Processing Technique. Event is received when operation is done.
void APP_SST26EventHandler
(
DRV_SST26_EVENT event,
DRV_SST26_COMMAND_HANDLE commandHandle,
uintptr_t contextHandle
)
{
// The context handle was set to an application specific
// object. It is now retrievable easily in the event handler.
MY_APP_OBJ myAppObj = (MY_APP_OBJ *) context;
switch(event)
{
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 937
case DRV_SST26_EVENT_COMMAND_COMPLETE:
// Operation completled successfully.
break;
case DRV_SST26_EVENT_COMMAND_ERROR:
// Error handling here.
break;
default:
break;
}
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
eventHandler Pointer to the event handler function implemented by the user
context The value of parameter will be passed back to the client unchanged, when the eventHandler
function is called. It can be used to identify any client specific data object that identifies the
instance of the client module (for example, it may be a pointer to the client module's state
structure).
Function
void DRV_SST26_EventHandlerSet
(
const DRV_HANDLE handle,
const void * eventHandler,
const uintptr_t context
);
d) Media Interface Functions
DRV_SST26_AddressGet Function
Returns the SST26 media start address
File
drv_sst26.h
C
uintptr_t DRV_SST26_AddressGet(const DRV_HANDLE handle);
Returns
Start address of the SST26 Media if the handle is valid otherwise NULL.
Description
This function returns the SST26 Media start address.
Remarks
None.
Preconditions
The DRV_SST26_Initialize() routine must have been called for the specified SST26 driver instance.
The DRV_SST26_Open() routine must have been called to obtain a valid opened device handle.
Example
uintptr_t startAddress;
startAddress = DRV_SST26_AddressGet(drvSST26Handle);
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 938
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
Function
uintptr_t DRV_SST26_AddressGet
(
const DRV_HANDLE handle
);
DRV_SST26_GeometryGet Function
Returns the geometry of the device.
File
drv_sst26.h
C
SYS_FS_MEDIA_GEOMETRY * DRV_SST26_GeometryGet(const DRV_HANDLE handle);
Returns
SYS_FS_MEDIA_GEOMETRY - Pointer to structure which holds the media geometry information.
Description
This API gives the following geometrical details of the SST26 Flash:
• Media Property
• Number of Read/Write/Erase regions in the flash device
• Number of Blocks and their size in each region of the device
Remarks
None.
Preconditions
The DRV_SST26_Initialize() routine must have been called for the specified SST26 driver instance.
The DRV_SST26_Open() routine must have been called to obtain a valid opened device handle.
Example
SYS_FS_MEDIA_GEOMETRY * sst26FlashGeometry;
uint32_t readBlockSize, writeBlockSize, eraseBlockSize;
uint32_t nReadBlocks, nReadRegions, totalFlashSize;
sst26FlashGeometry = DRV_SST26_GeometryGet(sst26OpenHandle1);
readBlockSize = sst26FlashGeometry->geometryTable->blockSize;
nReadBlocks = sst26FlashGeometry->geometryTable->numBlocks;
nReadRegions = sst26FlashGeometry->numReadRegions;
writeBlockSize = (sst26FlashGeometry->geometryTable +1)->blockSize;
eraseBlockSize = (sst26FlashGeometry->geometryTable +2)->blockSize;
totalFlashSize = readBlockSize * nReadBlocks * nReadRegions;
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
Function
SYS_FS_MEDIA_GEOMETRY * DRV_SST26_GeometryGet
(
const DRV_HANDLE handle
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 939
);
DRV_SST26_IsAttached Function
Returns the physical attach status of the SST26.
File
drv_sst26.h
C
bool DRV_SST26_IsAttached(const DRV_HANDLE handle);
Returns
Returns false if the handle is invalid otherwise returns true.
Description
This function returns the physical attach status of the SST26.
Remarks
None.
Preconditions
The DRV_SST26_Initialize() routine must have been called for the specified SST26 driver instance.
The DRV_SST26_Open() routine must have been called to obtain a valid opened device handle.
Example
bool isSST26Attached;
isSST26Attached = DRV_SST26_isAttached(drvSST26Handle);
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
Function
bool DRV_SST26_IsAttached
(
const DRV_HANDLE handle
);
DRV_SST26_IsWriteProtected Function
Returns the write protect status of the SST26.
File
drv_sst26.h
C
bool DRV_SST26_IsWriteProtected(const DRV_HANDLE handle);
Returns
True - If the flash is write protected. False - If the flash is not write protected.
Description
This function returns the write protect status of the SST26.
Remarks
None.
Preconditions
The DRV_SST26_Initialize() routine must have been called for the specified SST26 driver instance.
The DRV_SST26_Open() routine must have been called to obtain a valid opened device handle.
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 940
Example
bool isWriteProtected;
isWriteProtected = DRV_SST26_IsWriteProtected(drvSST26Handle);
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
Function
bool DRV_SST26_IsWriteProtected
(
const DRV_HANDLE handle
);
e) Data Types and Constants
DRV_SST26_COMMAND_HANDLE Type
Handle identifying commands queued in the driver.
File
drv_sst26.h
C
typedef SYS_FS_MEDIA_BLOCK_COMMAND_HANDLE DRV_SST26_COMMAND_HANDLE;
Description
SST26 Driver command handle.
A command handle is returned by a call to the Read, Write, Erase or EraseWrite functions. This handle allows the application to track the
completion of the operation. This command handle is also returned to the client along with the event that has occurred with respect to the
command. This allows the application to connect the event to a specific command in case where multiple commands are queued.
The command handle associated with the command request expires when the client has been notified of the completion of the command (after
event handler function that notifies the client returns) or after the command has been retired by the driver if no event handler callback was set.
Remarks
None.
DRV_SST26_COMMAND_STATUS Enumeration
SST26 Driver command Status
File
drv_sst26.h
C
typedef enum {
DRV_SST26_COMMAND_COMPLETED = SYS_FS_MEDIA_COMMAND_COMPLETED,
DRV_SST26_COMMAND_QUEUED = SYS_FS_MEDIA_COMMAND_QUEUED,
DRV_SST26_COMMAND_IN_PROGRESS = SYS_FS_MEDIA_COMMAND_IN_PROGRESS,
DRV_SST26_COMMAND_ERROR_UNKNOWN = SYS_FS_MEDIA_COMMAND_UNKNOWN
} DRV_SST26_COMMAND_STATUS;
Members
Members Description
DRV_SST26_COMMAND_COMPLETED =
SYS_FS_MEDIA_COMMAND_COMPLETED
Done OK and ready
DRV_SST26_COMMAND_QUEUED =
SYS_FS_MEDIA_COMMAND_QUEUED
Scheduled but not started
DRV_SST26_COMMAND_IN_PROGRESS =
SYS_FS_MEDIA_COMMAND_IN_PROGRESS
Currently being in transfer
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 941
DRV_SST26_COMMAND_ERROR_UNKNOWN
= SYS_FS_MEDIA_COMMAND_UNKNOWN
Unknown Command
Description
SST26 Driver Command Status
Specifies the status of the command for the read, write, erase and erasewrite operations.
Remarks
None.
DRV_SST26_EVENT Enumeration
Identifies the possible events that can result from a request.
File
drv_sst26.h
C
typedef enum {
DRV_SST26_EVENT_COMMAND_COMPLETE = SYS_FS_MEDIA_EVENT_BLOCK_COMMAND_COMPLETE,
DRV_SST26_EVENT_COMMAND_ERROR = SYS_FS_MEDIA_EVENT_BLOCK_COMMAND_ERROR
} DRV_SST26_EVENT;
Members
Members Description
DRV_SST26_EVENT_COMMAND_COMPLETE =
SYS_FS_MEDIA_EVENT_BLOCK_COMMAND_COMPLETE
Operation has been completed successfully.
DRV_SST26_EVENT_COMMAND_ERROR =
SYS_FS_MEDIA_EVENT_BLOCK_COMMAND_ERROR
There was an error during the operation
Description
SST26 Driver Events
This enumeration identifies the possible events that can result from a read, write, erase or erasewrite request caused by the client.
Remarks
One of these values is passed in the "event" parameter of the event handling callback function that client registered with the driver by calling the
DRV_SST26_EventHandlerSet function when a request is completed.
DRV_SST26_EVENT_HANDLER Type
Pointer to a SST26 Driver Event handler function
File
drv_sst26.h
C
typedef SYS_FS_MEDIA_EVENT_HANDLER DRV_SST26_EVENT_HANDLER;
Returns
None.
Description
SST26 Driver Event Handler Function Pointer
This data type defines the required function signature for the SST26 event handling callback function. A client must register a pointer to an event
handling function whose function signature (parameter and return value types) match the types specified by this function pointer in order to receive
event calls back from the driver.
The parameters and return values are described here and a partial example implementation is provided.
Remarks
If the event is DRV_SST26_EVENT_COMMAND_COMPLETE, it means that the requested operation was completed successfully.
If the event is DRV_SST26_EVENT_COMMAND_ERROR, it means that the scheduled operation was not completed successfully.
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 942
The context parameter contains the handle to the client context, provided at the time the event handling function was registered using the
DRV_SST26_EventHandlerSet function. This context handle value is passed back to the client as the "context" parameter. It can be any value
necessary to identify the client context or instance (such as a pointer to the client's data) instance of the client that made the read/write/erase
request.
The event handler function executes in the driver peripheral's interrupt context when the driver is configured for interrupt mode operation. It is
recommended of the application to not perform process intensive or blocking operations within this function.
Example
void APP_MySst26EventHandler
(
DRV_SST26_EVENT event,
DRV_SST26_COMMAND_HANDLE commandHandle,
uintptr_t context
)
{
MY_APP_DATA_STRUCT pAppData = (MY_APP_DATA_STRUCT) context;
switch(event)
{
case DRV_SST26_EVENT_COMMAND_COMPLETE:
// Handle the completed buffer.
break;
case DRV_SST26_EVENT_COMMAND_ERROR:
default:
// Handle error.
break;
}
}
Parameters
Parameters Description
event Identifies the type of event
commandHandle Handle returned from the Read/Write/Erase/EraseWrite requests
context Value identifying the context of the application that registered the event handling function
DRV_SST26_INIT Structure
Defines the data required to initialize or reinitialize the SST26 driver
File
drv_sst26.h
C
typedef struct {
uint8_t sqiDevice;
} DRV_SST26_INIT;
Members
Members Description
uint8_t sqiDevice; SQI Device Index.
Description
SST26 Driver Initialization Data
This data type defines the data required to initialize or reinitialize the SST26 driver.
Remarks
Not all initialization features are available for all devices. Please refer to the specific device data sheet to determine availability.
DRV_SST26_COMMAND_HANDLE_INVALID Macro
This value defines the SST26 Driver's Invalid Command Handle.
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 943
File
drv_sst26.h
C
#define DRV_SST26_COMMAND_HANDLE_INVALID SYS_FS_MEDIA_BLOCK_COMMAND_HANDLE_INVALID
Description
SST26 Driver Invalid Command Handle.
This value defines the SST26 Driver's Invalid Command Handle. This value is returned by read/write/erase/erasewrite routines when the command
request was not accepted.
Remarks
None.
DRV_SST26_INDEX_0 Macro
SST26 driver index definitions
File
drv_sst26.h
C
#define DRV_SST26_INDEX_0 0
Description
Driver SST26 Module Index reference
These constants provide SST26 driver index definitions.
Remarks
These constants should be used in place of hard-coded numeric literals. These values should be passed into the DRV_SST26_Initialize and
DRV_SST26_Open routines to identify the driver instance in use.
DRV_SST26_INDEX_1 Macro
File
drv_sst26.h
C
#define DRV_SST26_INDEX_1 1
Description
This is macro DRV_SST26_INDEX_1.
Files
Files
Name Description
drv_sst26.h SST26 Driver Interface Definition
drv_sst26_config_template.h SST26 driver configuration definitions.
Description
This section lists the source and header files used by the SQI Flash Driver Library.
drv_sst26.h
SST26 Driver Interface Definition
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 944
Enumerations
Name Description
DRV_SST26_COMMAND_STATUS SST26 Driver command Status
DRV_SST26_EVENT Identifies the possible events that can result from a request.
Functions
Name Description
DRV_SST26_AddressGet Returns the SST26 media start address
DRV_SST26_Close Closes an opened-instance of the SST26 driver
DRV_SST26_CommandStatus Gets the current status of the command.
DRV_SST26_Deinitialize Deinitializes the specified instance of the SST26 driver module
DRV_SST26_Erase Erase the specified number of flash blocks from the specified block start address.
DRV_SST26_EraseWrite Erase and Write blocks of data starting from a specified block start address.
DRV_SST26_EventHandlerSet Allows a client to identify an event handling function for the driver to call back when queued
operation has completed.
DRV_SST26_GeometryGet Returns the geometry of the device.
DRV_SST26_Initialize Initializes the SST26 instance for the specified driver index
DRV_SST26_IsAttached Returns the physical attach status of the SST26.
DRV_SST26_IsWriteProtected Returns the write protect status of the SST26.
DRV_SST26_Open Opens the specified SST26 driver instance and returns a handle to it
DRV_SST26_Read Reads blocks of data from the specified block start address.
DRV_SST26_Status Gets the current status of the SST26 driver module.
DRV_SST26_Tasks Maintains the SST26 driver's internal state machine.
DRV_SST26_Write Writes blocks of data starting at the specified block start address.
Macros
Name Description
DRV_SST26_COMMAND_HANDLE_INVALID This value defines the SST26 Driver's Invalid Command Handle.
DRV_SST26_INDEX_0 SST26 driver index definitions
DRV_SST26_INDEX_1 This is macro DRV_SST26_INDEX_1.
Structures
Name Description
DRV_SST26_INIT Defines the data required to initialize or reinitialize the SST26 driver
Types
Name Description
DRV_SST26_COMMAND_HANDLE Handle identifying commands queued in the driver.
DRV_SST26_EVENT_HANDLER Pointer to a SST26 Driver Event handler function
Description
SST26 Driver Interface Definition
The SST26 driver provides a simple interface to manage the SST26VF series of SQI Flash Memory connected to Microchip microcontrollers. This
file defines the interface definition for the SST26 driver.
File Name
drv_sst26.h
Company
Microchip Technology Inc.
drv_sst26_config_template.h
SST26 driver configuration definitions.
Volume V: MPLAB Harmony Framework Driver Libraries Help SQI Flash Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 945
Macros
Name Description
DRV_SST26_BUFFER_OBJECT_NUMBER Selects the maximum number of buffer objects
DRV_SST26_CLIENTS_NUMBER Selects the maximum number of clients
DRV_SST26_INSTANCES_NUMBER Selects the maximum number of Driver instances that can be supported by the
dynamic driver.
DRV_SST26_SYS_FS_REGISTER Register to use with the File system
Description
SST26 Driver Configuration Template Header file.
This template file describes all the mandatory and optional configuration macros that are needed for building the SST26 driver. Do not include this
file in source code.
File Name
drv_sst26_config_template.h
Company
Microchip Technology Inc.
SRAM Driver Library
This section describes the Static Random Access (SRAM) driver library.
Introduction
The SRAM Media Driver library provides a high-level interface to manage the onboard SRAM as a media
Description
The SRAM Media driver features the following:
• Provides application ready routines to perform block operations on the SRAM media
• Supports multi-client operation
• Provides data transfer events
• Supports blocking mode of operation only
Using the Library
This topic describes the basic architecture of the SRAM Media Driver Library and provides information and examples about how to use it.
Description
Interface Header Files: drv_sram.h
Please refer to the What is MPLAB Harmony? section for how the driver interacts with the framework.
Topics
Name Description
Abstraction Model This library provides a low-level abstraction of the SRAM media with a convenient C language interface. This
topic describes how that abstraction is modeled in software.
Library Overview This library provides information about how the driver operates in a system. The library interface routines are
divided into various sub-sections, which address one of the blocks or the overall operation of the SRAM
Media driver module.
How the Library Works This section describes how the SRAM Media Driver Library operates
Abstraction Model
This library provides a low-level abstraction of the SRAM media with a convenient C language interface. This section describes how that
abstraction is modeled in software.
Volume V: MPLAB Harmony Framework Driver Libraries Help SRAM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 946
Description
The SRAM Media driver facilitates the block access to the SRAM media by providing APIs that can be used to perform read/write operations. The
end applications can either access the media directly through the driver or through MPLAB Harmony. The following diagram shows the
communication between different modules.
SRAM Media Driver Abstraction Model
Library Overview
Refer to the Driver Library Overview section for information about how the SRAM driver operates within a system.
Description
The library interface routines are divided into various sub-sections, which address one of the blocks or the overall operation of the SRAM module.
Library Interface Section Description
System Functions Provides system module interfaces, device initialization, de-initialization and status
functions.
Data Types and Constants Provides data types and macros.
How the Library Works
The library provides interfaces to support:
• System Functionality
• Client Functionality
• Media Functionality
System Initialization/Status Functions
The SRAM driver provides the following system functions:
• SRAM driver initialization
• SRAM driver status.
Volume V: MPLAB Harmony Framework Driver Libraries Help SRAM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 947
Description
SRAM driver initialization
The system performs the initialization of the device driver with settings that affect only the instance of the device that is being initialized. During
system initialization each instance of the SRAM Media driver would be initialized with the following configuration settings passed dynamically at
run time using DRV_SRAM_INIT:
• registerWithFs: This controls the registration of the driver with the Harmony File System.
• mediaStartAddress: This indicates the start address of the SRAM media on which driver is to operate.
• sramMediaGeometry: This provides the SRAM media geometry information that the driver will use while performing the read/write operations
on the media.
The DRV_SRAM_Initialize function configures and initializes the SRAM Media driver by using the configuration information provided. The
function returns an object handle of the type SYS_MODULE_OBJ. This object handle is used by other system interfaces such as
DRV_SRAM_Status and DRV_SRAM_Deinitialize.
Example:
/*** SRAM Driver Initialization Data ***/
SYS_FS_MEDIA_REGION_GEOMETRY sramMedia0GeometryTable[3] =
{
{
.blockSize = 1,
.numBlocks = (32 * (1024/1)),
},
{
.blockSize = 1,
.numBlocks = (32 * (1024/1)),
},
{
.blockSize = 1,
.numBlocks = (32 * (1024/1)),
}
};
const SYS_FS_MEDIA_GEOMETRY sramMedia0Geometry =
{
.mediaProperty = SYS_FS_MEDIA_WRITE_IS_BLOCKING | SYS_FS_MEDIA_READ_IS_BLOCKING,
.numReadRegions = 1,
.numWriteRegions = 1,
.numEraseRegions = 1,
.geometryTable = (SYS_FS_MEDIA_REGION_GEOMETRY *)&sramMedia0GeometryTable
};
extern uint8_t SRAM_MEDIA_0_DATA[];
const DRV_SRAM_INIT drvSram0Init =
{
.registerWithFs = true,
.mediaStartAddress = (uint8_t *)SRAM_MEDIA_0_DATA,
.sramMediaGeometry = (SYS_FS_MEDIA_GEOMETRY
*)&sramMedia0Geometry
};
/* Initialize the SRAM Driver Instance 0 */
sysObj.drvSramObj0 = DRV_SRAM_Initialize(DRV_SRAM_INDEX_0, (SYS_MODULE_INIT *)&drvSram0Init);
SRAM driver status
DRV_SRAM_Status() returns the current status of the SRAM Media driver and is called by the Harmony System. The application may not find the
need to call this function directly.
Example:
SYS_MODULE_OBJ object;
// Returned from DRV_SRAM_Initialize
Volume V: MPLAB Harmony Framework Driver Libraries Help SRAM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 948
SYS_STATUS sramStatus;
sramStatus = DRV_SRAM_Status(object);
if (SYS_STATUS_ERROR >= sramStatus)
{
// Handle error
}
Client Core Functions
The SRAM driver provides the following client core functions:
• Opening the driver
• Closing the driver
Description
Opening the driver
For the application to start using an instance of the module, it must call the function DRV_SRAM_Open and obtain a valid driver handle. The
application client uses this driver handle to access the driver functions.
For the various options available for I/O INTENT, please refer to Data Types and Constants in the Library Interface section.
Example:
handle = DRV_SRAM_Open(DRV_SRAM_INDEX_0, DRV_IO_INTENT_EXCLUSIVE);
if (DRV_HANDLE_INVALID == handle)
{
/* Call until the function returns a valid handle. */
}
else
{
/* Do further processing. */
}
Closing the driver
This function closes an opened-instance of the SRAM Media driver. This invalidates the driver handle. The application must open the driver again
to obtain a valid handle.
Example:
DRV_HANDLE handle; // Returned from DRV_SRAM_Open
DRV_SRAM_Close(handle);
Client Block Operation Functions
The SRAM driver provides client interfaces to perform operations in terms of blocks.
Description
A block is a unit that represents the minimum amount of data that can be written or read. The block sizes may differ for write and read operations.
The DRV_SRAM_GeometryGet function can be used to read out the geometry of the SRAM Media. The geometry indicates the number of read,
write, and erase regions; blocks per region; and the size of each block.
The DRV_SRAM_Write and DRV_SRAM_Read functions are used to write and read the data to/from SRAM media. These functions block
operations until the requested amount of data is transferred. If an event handler has been registered to receive the driver events, then the event
handler will be invoked from within these functions. The driver provides events (DRV_SRAM_EVENT) that indicate the completion of the requests.
The following steps can be performed for a simple block data transfer operation:
1. Make sure the system has completed the necessary initialization of the SRAM driver.
2. Open the driver using DRV_SRAM_Open with the necessary intent.
3. Register an event handler callback by using the function DRV_SRAM_EventHandlerSet.
4. Request for block operation by using the functions DRV_SRAM_Write and DRV_SRAM_Read with the appropriate parameters.
5. Wait for the event handler callback to occur and check the status of the block operation by using the callback function parameter of type
DRV_SRAM_ EVENT.
6. After performing the required block operations, the client can close the driver by using the function DRV_SRAM_Close.
Example:
uint8_t myBuffer[MY_BUFFER_SIZE];
uint32_t blockStart = 0;
uint32_t nBlock = 2;
Volume V: MPLAB Harmony Framework Driver Libraries Help SRAM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 949
DRV_SRAM_COMMAND_HANDLE commandHandle;
MY_APP_OBJ myAppObj;
// mySRAMHandle is the handle returned by the DRV_SRAM_Open
// function.
DRV_SRAM_EventHandlerSet(
mySRAMHandle,
APP_SRAMEventHandler,
(uintptr_t)&myAppObj);
DRV_SRAM_Read(
mySRAMHandle,
&commandHandle,
&myBuffer,
blockStart,
nBlock);
if(DRV_SRAM_COMMAND_HANDLE_INVALID == commandHandle)
{
// Error handling here
}
else
{
// Read operation completed successfully.
}
// Event is invoked from within the DRV_SRAM_Read function when
// the read operation processing is complete.
void APP_SRAMEventHandler
(
DRV_SRAM_EVENT event,
DRV_SRAM_COMMAND_HANDLE commandHandle,
uintptr_t contextHandle
)
{
// contextHandle points to myAppObj.
switch(event)
{
case DRV_SRAM_EVENT_COMMAND_COMPLETE:
// This means the data was transferred.
break;
case DRV_SRAM_EVENT_COMMAND_ERROR:
// Error handling here.
break;
default:
break;
}
}
Media Interface Functions
The SRAM driver provides the following media interface function:
• Reading the device geometry
Volume V: MPLAB Harmony Framework Driver Libraries Help SRAM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 950
Description
The application can call the DRV_SRAM_GeometryGet function to obtain the geometry of the media device.
Reading the device geometry
The geometry indicates the number of read, write, and erase regions; the number of blocks per region; and the size of each block.
Example:
SYS_FS_MEDIA_GEOMETRY * sramGeometry;
uint32_t readBlockSize, writeBlockSize, eraseBlockSize;
uint32_t nReadBlocks, nReadRegions, totalSize;
sramGeometry = DRV_SRAM_GeometryGet(sramOpenHandle1);
readBlockSize = sramGeometry->geometryTable->blockSize;
nReadBlocks = sramGeometry->geometryTable->numBlocks;
nReadRegions = sramGeometry->numReadRegions;
writeBlockSize = (sramGeometry->geometryTable +1)->blockSize;
eraseBlockSize = (sramGeometry->geometryTable +2)->blockSize;
totalSize = readBlockSize * nReadBlocks * nReadRegions;
Configuring the Library
This section contains related configuration macros.
Description
The configuration of the SRAM driver is based on the file system_config.h.
This header file contains the configuration selection for the SRAM driver. Based on the selections made, the SRAM driver may support the
selected features. These configuration settings apply to all instances of the SRAM driver.
This header can be placed anywhere; however, the path of this header needs to be present in the include search path for a successful build. Refer
to the Applications Help section for more details.
Building the Library
This section lists the files that are available in the SRAM library.
Description
The following three tables list and describe the header (.h) and source (.c) files that implement this library. The parent folder for these files is
/framework/driver/sram/.
Interface File(s)
This table lists and describes the header files that must be included (i.e., using #include) by any code that uses this library.
Source File Name Description
/drv_sram.h This is the SRAM library's interface header file.
Required File(s)
All of the required files listed in the following table are automatically added into the MPLAB X IDE project by the MHC
when the library is selected for use.
This table lists and describes the source and header files that must always be included in the MPLAB X IDE project to build this library.
Source File Name Description
/src/dynamic/drv_sram.c This file contains the source code for the dynamic implementation of the SRAM driver.
/config/drv_sram_config_template.h This file contains configuration macros for the SRAM driver.
Optional File(s)
This table lists and describes the source and header files that may optionally be included if required for the desired implementation.
Volume V: MPLAB Harmony Framework Driver Libraries Help SRAM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 951
Source File Name Description
N/A No optional files are available for this library.
Library Interface
This section describes the Application Programming Interface (API) functions of the SRAM driver library.
Refer to each section for a detailed description.
a) System Functions
Name Description
DRV_SRAM_AddressGet Returns the SRAM media start address
DRV_SRAM_Close Closes an opened-instance of the SRAM driver
DRV_SRAM_CommandStatus Gets the current status of the command.
DRV_SRAM_Deinitialize Deinitializes the specified instance of the SRAM driver module
DRV_SRAM_EventHandlerSet Allows a client to identify an event handling function for the driver to call back when an
operation has completed.
DRV_SRAM_GeometryGet Returns the geometry of the device.
DRV_SRAM_Initialize Initializes the SRAM instance for the specified driver index.
DRV_SRAM_IsAttached Returns the physical attach status of the SRAM.
DRV_SRAM_IsWriteProtected Returns the write protect status of the SRAM.
DRV_SRAM_Open Opens the specified SRAM driver instance and returns a handle to it
DRV_SRAM_Read Reads blocks of data from the specified block start address.
DRV_SRAM_Status Gets the current status of the SRAM driver module.
DRV_SRAM_Write Writes blocks of data starting from the specified block start address of the SRAM media.
c) Data Types and Constants
Name Description
DRV_SRAM_COMMAND_HANDLE Handle identifying commands queued in the driver.
DRV_SRAM_COMMAND_STATUS Specifies the status of the command for the read and write operations.
DRV_SRAM_EVENT Identifies the possible events that can result from a request.
DRV_SRAM_EVENT_HANDLER Pointer to a SRAM Driver Event handler function
DRV_SRAM_INIT Defines the data required to initialize the SRAM driver
_DRV_SRAM_H This is macro _DRV_SRAM_H.
DRV_SRAM_COMMAND_HANDLE_INVALID This value defines the SRAM Driver's Invalid Command Handle.
DRV_SRAM_INDEX_0 SRAM driver index definitions
DRV_SRAM_INDEX_1 This is macro DRV_SRAM_INDEX_1.
a) System Functions
DRV_SRAM_AddressGet Function
Returns the SRAM media start address
File
drv_sram.h
C
uintptr_t DRV_SRAM_AddressGet(const DRV_HANDLE handle);
Returns
Start address of the SRAM Media if the handle is valid otherwise NULL.
Description
This function returns the SRAM Media start address.
Volume V: MPLAB Harmony Framework Driver Libraries Help SRAM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 952
Remarks
None.
Preconditions
The DRV_SRAM_Initialize() routine must have been called for the specified SRAM driver instance.
The DRV_SRAM_Open() routine must have been called to obtain a valid opened device handle.
Example
uintptr_t startAddress;
startAddress = DRV_SRAM_AddressGet(drvSRAMHandle);
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open
Function
uintptr_t DRV_SRAM_AddressGet
(
const DRV_HANDLE handle
);
DRV_SRAM_Close Function
Closes an opened-instance of the SRAM driver
File
drv_sram.h
C
void DRV_SRAM_Close(const DRV_HANDLE handle);
Returns
None
Description
This routine closes an opened-instance of the SRAM driver, invalidating the handle.
Remarks
After calling this routine, the handle passed in "handle" must not be used with any of the remaining driver routines. A new handle must be obtained
by calling DRV_SRAM_Open before the caller may use the driver again. Usually there is no need for the driver client to verify that the Close
operation has completed.
Preconditions
The DRV_SRAM_Initialize routine must have been called for the specified SRAM driver instance.
DRV_SRAM_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE handle; // Returned from DRV_SRAM_Open
DRV_SRAM_Close(handle);
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
void DRV_SRAM_Close
(
const DRV_HANDLE handle
);
Volume V: MPLAB Harmony Framework Driver Libraries Help SRAM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 953
DRV_SRAM_CommandStatus Function
Gets the current status of the command.
File
drv_sram.h
C
DRV_SRAM_COMMAND_STATUS DRV_SRAM_CommandStatus(const DRV_HANDLE handle, const DRV_SRAM_COMMAND_HANDLE
commandHandle);
Returns
A DRV_SRAM_COMMAND_STATUS value describing the current status of the command. Returns DRV_SRAM_COMMAND_COMPLETED if the
client handle or the command handle is not valid.
Description
This routine gets the current status of the command. The application must use this routine where the status of a scheduled command needs to be
polled on. The function may return DRV_SRAM_COMMAND_COMPLETED in a case where the command handle has expired. A command
handle expires when the internal buffer object is re-assigned to another read or write request. It is recommended that this function be called
regularly in order to track the command status correctly.
The application can alternatively register an event handler to receive read or write operation completion events.
Remarks
This routine will not block for hardware access and will immediately return the current status.
Preconditions
The DRV_SRAM_Initialize() routine must have been called.
The DRV_SRAM_Open() must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE handle; // Returned from DRV_SRAM_Open
DRV_SRAM_COMMAND_HANDLE commandHandle;
DRV_SRAM_COMMAND_STATUS status;
status = DRV_SRAM_CommandStatus(handle, commandHandle);
if(status == DRV_SRAM_COMMAND_COMPLETED)
{
// Operation Done
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
DRV_SRAM_COMMAND_STATUS DRV_SRAM_CommandStatus
(
const DRV_HANDLE handle,
const DRV_SRAM_COMMAND_HANDLE commandHandle
);
DRV_SRAM_Deinitialize Function
Deinitializes the specified instance of the SRAM driver module
File
drv_sram.h
C
void DRV_SRAM_Deinitialize(SYS_MODULE_OBJ object);
Volume V: MPLAB Harmony Framework Driver Libraries Help SRAM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 954
Returns
None.
Description
Deinitializes the specified instance of the SRAM driver module, disabling its operation. Invalidates all the internal data.
Remarks
Once the Initialize operation has been called, the Deinitialize operation must be called before the Initialize operation can be called again.
Preconditions
Function DRV_SRAM_Initialize should have been called before calling this function.
Parameter: object - Driver object handle, returned from the DRV_SRAM_Initialize routine
Example
// This code snippet shows an example of deinitializing the driver.
SYS_MODULE_OBJ object; // Returned from DRV_SRAM_Initialize
SYS_STATUS status;
DRV_SRAM_Deinitialize(object);
status = DRV_SRAM_Status(object);
if (SYS_MODULE_DEINITIALIZED != status)
{
// Check again later if you need to know when the driver is
// deinitialized.
}
Function
void DRV_SRAM_Deinitialize
(
SYS_MODULE_OBJ object
);
DRV_SRAM_EventHandlerSet Function
Allows a client to identify an event handling function for the driver to call back when an operation has completed.
File
drv_sram.h
C
void DRV_SRAM_EventHandlerSet(const DRV_HANDLE handle, const void * eventHandler, const uintptr_t context);
Returns
None.
Description
This function allows a client to identify an event handling function for the driver to call back when an operation has completed. When a client calls a
read or a write function, it is provided with a handle identifying the read/write request. The driver will pass this handle back to the client by calling
"eventHandler" function when the operation has completed.
The event handler should be set before the client performs any read or write operations that could generate events. The event handler once set,
persists until the client closes the driver or sets another event handler (which could be a "NULL" pointer to indicate no callback).
Remarks
If the client does not want to be notified when the queued operation has completed, it does not need to register a callback.
Preconditions
The DRV_SRAM_Initialize() routine must have been called for the specified SRAM driver instance.
The DRV_SRAM_Open() routine must have been called to obtain a valid opened device handle.
Volume V: MPLAB Harmony Framework Driver Libraries Help SRAM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 955
Example
// myAppObj is an application specific state data object.
MY_APP_OBJ myAppObj;
uint8_t myBuffer[MY_BUFFER_SIZE];
uint32_t blockStart, nBlock;
DRV_SRAM_COMMAND_HANDLE commandHandle;
// drvSRAMHandle is the handle returned by the DRV_SRAM_Open function.
// Client registers an event handler with driver. This is done once.
DRV_SRAM_EventHandlerSet(drvSRAMHandle, APP_SRAMEventHandler, (uintptr_t)&myAppObj);
DRV_SRAM_Read(drvSRAMHandle, &commandHandle, &myBuffer, blockStart, nBlock);
if(DRV_SRAM_COMMAND_HANDLE_INVALID == commandHandle)
{
// Error handling here
}
// Event Processing Technique. Event is received when operation is done.
void APP_SRAMEventHandler
(
DRV_SRAM_EVENT event,
DRV_SRAM_COMMAND_HANDLE handle,
uintptr_t context
)
{
// The context handle was set to an application specific object. It is
// now retrievable easily in the event handler.
MY_APP_OBJ myAppObj = (MY_APP_OBJ *) context;
switch(event)
{
case DRV_SRAM_EVENT_COMMAND_COMPLETE:
// This means the data was transferred.
break;
case DRV_SRAM_EVENT_COMMAND_ERROR:
// Error handling here.
break;
default:
break;
}
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
eventHandler Pointer to the event handler function implemented by the user
context The value of parameter will be passed back to the client unchanged, when the eventHandler
function is called. It can be used to identify any client specific data object that identifies the
instance of the client module (for example, it may be a pointer to the client module's state
structure).
Function
void DRV_SRAM_EventHandlerSet
(
const DRV_HANDLE handle,
const void * eventHandler,
const uintptr_t context
);
Volume V: MPLAB Harmony Framework Driver Libraries Help SRAM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 956
DRV_SRAM_GeometryGet Function
Returns the geometry of the device.
File
drv_sram.h
C
SYS_FS_MEDIA_GEOMETRY * DRV_SRAM_GeometryGet(const DRV_HANDLE handle);
Returns
SYS_FS_MEDIA_GEOMETRY - Pointer to structure which holds the media geometry information.
Description
This API gives the following geometrical details of the SRAM memory:
• Media Property
• Number of Read/Write/Erase regions
• Number of Blocks and their size in each region of the device
Remarks
None.
Preconditions
The DRV_SRAM_Initialize() routine must have been called for the specified SRAM driver instance.
The DRV_SRAM_Open() routine must have been called to obtain a valid opened device handle.
Example
SYS_FS_MEDIA_GEOMETRY * sramGeometry;
uint32_t readBlockSize, writeBlockSize, eraseBlockSize;
uint32_t nReadBlocks, nReadRegions, totalSize;
sramGeometry = DRV_SRAM_GeometryGet(sramOpenHandle1);
readBlockSize = sramGeometry->geometryTable->blockSize;
nReadBlocks = sramGeometry->geometryTable->numBlocks;
nReadRegions = sramGeometry->numReadRegions;
writeBlockSize = (sramGeometry->geometryTable +1)->blockSize;
eraseBlockSize = (sramGeometry->geometryTable +2)->blockSize;
totalSize = readBlockSize * nReadBlocks * nReadRegions;
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
Function
SYS_FS_MEDIA_GEOMETRY * DRV_SRAM_GeometryGet
(
const DRV_HANDLE handle
);
DRV_SRAM_Initialize Function
Initializes the SRAM instance for the specified driver index.
File
drv_sram.h
C
SYS_MODULE_OBJ DRV_SRAM_Initialize(const SYS_MODULE_INDEX index, const SYS_MODULE_INIT * const init);
Volume V: MPLAB Harmony Framework Driver Libraries Help SRAM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 957
Returns
If successful, returns a valid handle to a driver instance object. Otherwise it returns SYS_MODULE_OBJ_INVALID.
Description
This routine initializes the SRAM driver instance for the specified driver index, making it ready for clients to open and use it.
Remarks
This routine must be called before any other SRAM routine is called.
This routine should only be called once during system initialization unless DRV_SRAM_Deinitialize is called to deinitialize the driver instance.
This routine will NEVER block for hardware access. The system must use DRV_SRAM_Status to find out when the driver is in the ready state.
Preconditions
None.
Example
// This code snippet shows an example of initializing the SRAM Driver.
SYS_MODULE_OBJ objectHandle;
SYS_FS_MEDIA_REGION_GEOMETRY gSramGeometryTable[3] =
{
{
// Read Region Geometry
.blockSize = 512,
.numBlocks = (DRV_SRAM_MEDIA_SIZE * (1024/512)),
},
{
// Write Region Geometry
.blockSize = 512,
.numBlocks = ((DRV_SRAM_MEDIA_SIZE * (1024/512))
},
{
// Erase Region Geometry
.blockSize = 512,
.numBlocks = ((DRV_SRAM_MEDIA_SIZE * (1024/512))
}
};
const SYS_FS_MEDIA_GEOMETRY gSramGeometry =
{
.mediaProperty = SYS_FS_MEDIA_WRITE_IS_BLOCKING,
// Number of read, write and erase entries in the table
.numReadRegions = 1,
.numWriteRegions = 1,
.numEraseRegions = 1,
.geometryTable = &gSramGeometryTable
};
// SRAM Driver Initialization Data
const DRV_SRAM_INIT drvSramInit =
{
.mediaStartAddress = DRV_SRAM_MEDIA_START_ADDRESS,
.sramMediaGeometry = &gSramGeometry
};
objectHandle = DRV_SRAM_Initialize(DRV_SRAM_INDEX_0, (SYS_MODULE_INIT*)&drvSRAMInit);
if (SYS_MODULE_OBJ_INVALID == objectHandle)
{
// Handle error
}
Parameters
Parameters Description
index Identifier for the instance to be initialized.
Volume V: MPLAB Harmony Framework Driver Libraries Help SRAM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 958
init Pointer to a data structure containing any data necessary to initialize the driver.
Function
SYS_MODULE_OBJ DRV_SRAM_Initialize
(
const SYS_MODULE_INDEX index,
const SYS_MODULE_INIT * const init
);
DRV_SRAM_IsAttached Function
Returns the physical attach status of the SRAM.
File
drv_sram.h
C
bool DRV_SRAM_IsAttached(const DRV_HANDLE handle);
Returns
Returns false if the handle is invalid otherwise returns true.
Description
This function returns the physical attach status of the SRAM.
Remarks
None.
Preconditions
The DRV_SRAM_Initialize() routine must have been called for the specified SRAM driver instance.
The DRV_SRAM_Open() routine must have been called to obtain a valid opened device handle.
Example
// The SRAM media is always attached and so the below always returns true.
bool isSRAMAttached;
isSRAMAttached = DRV_SRAM_isAttached(drvSRAMHandle);
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open
Function
bool DRV_SRAM_IsAttached
(
const DRV_HANDLE handle
);
DRV_SRAM_IsWriteProtected Function
Returns the write protect status of the SRAM.
File
drv_sram.h
C
bool DRV_SRAM_IsWriteProtected(const DRV_HANDLE handle);
Returns
Always returns false.
Volume V: MPLAB Harmony Framework Driver Libraries Help SRAM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 959
Description
This function returns the physical attach status of the SRAM. This function always returns false.
Remarks
None.
Preconditions
The DRV_SRAM_Initialize() routine must have been called for the specified SRAM driver instance.
The DRV_SRAM_Open() routine must have been called to obtain a valid opened device handle.
Example
// The SRAM media is treated as always writeable.
bool isWriteProtected;
isWriteProtected = DRV_SRAM_IsWriteProtected(drvSRAMHandle);
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
Function
bool DRV_SRAM_IsWriteProtected
(
const DRV_HANDLE handle
);
DRV_SRAM_Open Function
Opens the specified SRAM driver instance and returns a handle to it
File
drv_sram.h
C
DRV_HANDLE DRV_SRAM_Open(const SYS_MODULE_INDEX index, const DRV_IO_INTENT ioIntent);
Returns
If successful, the routine returns a valid open-instance handle (a number identifying both the caller and the module instance).
If an error occurs, DRV_HANDLE_INVALID is returned. Errors can occur under the following circumstances:
• if the number of client objects allocated via DRV_SRAM_CLIENTS_NUMBER
is insufficient
• if the client is trying to open the driver but driver has been opened
exclusively by another client
• if the client is trying to open the driver exclusively, but has
already been opened in a non exclusive mode by another client.
• if the driver hardware instance being opened is invalid
Description
This routine opens the specified SRAM driver instance and provides a handle. This handle must be provided to all other client-level operations to
identify the caller and the instance of the driver.
Remarks
The handle returned is valid until the DRV_SRAM_Close routine is called. This routine will NEVER block waiting for hardware. If the driver has has
already been opened, it cannot be opened exclusively.
Preconditions
DRV_SRAM_Initialize must have been called before calling this function.
Example
DRV_HANDLE handle;
Volume V: MPLAB Harmony Framework Driver Libraries Help SRAM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 960
handle = DRV_SRAM_Open(DRV_SRAM_INDEX_0, DRV_IO_INTENT_EXCLUSIVE);
if (DRV_HANDLE_INVALID == handle)
{
// Unable to open the driver
}
Parameters
Parameters Description
index Identifier for the object instance to be opened
intent Zero or more of the values from the enumeration DRV_IO_INTENT "ORed" together to
indicate the intended use of the driver
Function
DRV_HANDLE DRV_SRAM_Open
(
const SYS_MODULE_INDEX index,
const DRV_IO_INTENT ioIntent
);
DRV_SRAM_Read Function
Reads blocks of data from the specified block start address.
File
drv_sram.h
C
void DRV_SRAM_Read(const DRV_HANDLE handle, DRV_SRAM_COMMAND_HANDLE * commandHandle, void * targetBuffer,
uint32_t blockStart, uint32_t nBlock);
Returns
The buffer handle is returned in the commandHandle argument. It will be DRV_SRAM_COMMAND_HANDLE_INVALID if the request was not
successful.
Description
This routine reads blocks of data from the specified block start address. This operation is blocking and returns with the required data in the target
buffer. If a event handler has been registered to receive the driver events then the event handler will be called from within this function. The
function returns DRV_SRAM_COMMAND_HANDLE_INVALID in the commandHandle argument under the following circumstances:
• if the driver handle is invalid
• if the driver state is not ready
• if the target buffer pointer is NULL
• if the number of blocks to be read is zero or more than the actual number
of blocks available
• if the client opened the driver in write only mode
Remarks
None.
Preconditions
The DRV_SRAM_Initialize routine must have been called for the specified SRAM driver instance.
DRV_SRAM_Open must have been called with DRV_IO_INTENT_READ or DRV_IO_INTENT_READWRITE as the ioIntent to obtain a valid
opened device handle.
Example
uint8_t myBuffer[MY_BUFFER_SIZE];
uint32_t blockStart = 0;
uint32_t nBlock = 2;
DRV_SRAM_COMMAND_HANDLE commandHandle;
MY_APP_OBJ myAppObj;
// mySRAMHandle is the handle returned by the DRV_SRAM_Open function.
Volume V: MPLAB Harmony Framework Driver Libraries Help SRAM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 961
DRV_SRAM_EventHandlerSet(mySRAMHandle, APP_SRAMEventHandler, (uintptr_t)&myAppObj);
DRV_SRAM_Read(mySRAMHandle, &commandHandle, &myBuffer, blockStart, nBlock);
if(DRV_SRAM_COMMAND_HANDLE_INVALID == commandHandle)
{
// Error handling here
}
else
{
// Read operation completed successfully.
}
// Event is invoked from within the DRV_SRAM_Read function when the read
// operation processing is complete.
void APP_SRAMEventHandler
(
DRV_SRAM_EVENT event,
DRV_SRAM_COMMAND_HANDLE commandHandle,
uintptr_t contextHandle
)
{
// contextHandle points to myAppObj.
switch(event)
{
case DRV_SRAM_EVENT_COMMAND_COMPLETE:
// This means the data was transferred.
break;
case DRV_SRAM_EVENT_COMMAND_ERROR:
// Error handling here.
break;
default:
break;
}
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
commandHandle Pointer to an argument that will contain the return buffer handle
targetBuffer Buffer into which the data read from the SRAM memory will be placed
blockStart SRAM media's start block address from where the read should begin.
nBlock Total number of blocks to be read.
Function
void DRV_SRAM_Read
(
const DRV_HANDLE handle,
DRV_SRAM_COMMAND_HANDLE * commandHandle,
void * targetBuffer,
uint32_t blockStart,
uint32_t nBlock
);
DRV_SRAM_Status Function
Gets the current status of the SRAM driver module.
File
drv_sram.h
Volume V: MPLAB Harmony Framework Driver Libraries Help SRAM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 962
C
SYS_STATUS DRV_SRAM_Status(SYS_MODULE_OBJ object);
Returns
SYS_STATUS_READY - Indicates that the driver is ready and accept requests for new operations.
SYS_STATUS_UNINITIALIZED - Indicates the driver is not initialized.
Description
This routine provides the current status of the SRAM driver module.
Remarks
None.
Preconditions
Function DRV_SRAM_Initialize should have been called before calling this function.
Example
SYS_MODULE_OBJ object; // Returned from DRV_SRAM_Initialize
SYS_STATUS SRAMStatus;
SRAMStatus = DRV_SRAM_Status(object);
if (SRAMStatus == SYS_STATUS_READY)
{
// Driver is ready to process read/write operations.
}
else
{
// Driver is not ready.
}
Parameters
Parameters Description
object Driver object handle, returned from the DRV_SRAM_Initialize routine
Function
SYS_STATUS DRV_SRAM_Status
(
SYS_MODULE_OBJ object
);
DRV_SRAM_Write Function
Writes blocks of data starting from the specified block start address of the SRAM media.
File
drv_sram.h
C
void DRV_SRAM_Write(const DRV_HANDLE handle, DRV_SRAM_COMMAND_HANDLE * commandHandle, void * sourceBuffer,
uint32_t blockStart, uint32_t nBlock);
Returns
The buffer handle is returned in the commandHandle argument. It will be DRV_SRAM_COMMAND_HANDLE_INVALID if the request was not
successful.
Description
This routine writes blocks of data starting at the specified block start address. This operation is blocking and returns after having written the data. If
a event handler has been registered to receive the driver events then the event handler will be called from within this function. The function returns
DRV_SRAM_COMMAND_HANDLE_INVALID in the commandHandle argument under the following circumstances:
• if the driver handle is invalid
Volume V: MPLAB Harmony Framework Driver Libraries Help SRAM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 963
• if the driver state is not ready
• if the source buffer pointer is NULL
• if the number of blocks to be written is zero or more than the actual
number of blocks available
• if the client opened the driver in read only mode
Remarks
None
Preconditions
The DRV_SRAM_Initialize() routine must have been called for the specified SRAM driver instance.
DRV_SRAM_Open() routine must have been called to obtain a valid opened device handle. DRV_IO_INTENT_WRITE or
DRV_IO_INTENT_READWRITE must have been specified as a parameter to this routine.
Example
uint8_t myBuffer[MY_BUFFER_SIZE];
uint32_t blockStart = 2;
uint32_t nBlock = 2;
DRV_SRAM_COMMAND_HANDLE commandHandle;
MY_APP_OBJ myAppObj;
// mySRAMHandle is the handle returned by the DRV_SRAM_Open function.
// Client registers an event handler with driver
DRV_SRAM_EventHandlerSet(mySRAMHandle, APP_SRAMEventHandler, (uintptr_t)&myAppObj);
DRV_SRAM_Write(mySRAMHandle, &commandHandle, &myBuffer, blockStart, nBlock);
if(DRV_SRAM_COMMAND_HANDLE_INVALID == commandHandle)
{
// Error handling here
}
else
{
// Write completed successfully.
}
// Event is received from within the DRV_SRAM_Write function when the
// buffer is processed.
void APP_SRAMEventHandler
(
DRV_SRAM_EVENT event,
DRV_SRAM_COMMAND_HANDLE commandHandle,
uintptr_t contextHandle
)
{
// contextHandle points to myAppObj.
switch(event)
{
case DRV_SRAM_EVENT_COMMAND_COMPLETE:
// This means the data was transferred.
break;
case DRV_SRAM_EVENT_COMMAND_ERROR:
// Error handling here.
break;
default:
break;
}
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open function
commandHandle Pointer to an argument that will contain the return buffer handle
Volume V: MPLAB Harmony Framework Driver Libraries Help SRAM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 964
sourceBuffer The source buffer containing data to be programmed into SRAM memory
blockStart Start block address of SRAM media from where the write should begin.
nBlock Total number of blocks to be written.
Function
void DRV_SRAM_Write
(
const DRV_HANDLE handle,
DRV_SRAM_COMMAND_HANDLE * commandHandle,
void * sourceBuffer,
uint32_t blockStart,
uint32_t nBlock
);
c) Data Types and Constants
DRV_SRAM_COMMAND_HANDLE Type
Handle identifying commands queued in the driver.
File
drv_sram.h
C
typedef SYS_FS_MEDIA_BLOCK_COMMAND_HANDLE DRV_SRAM_COMMAND_HANDLE;
Description
SRAM Driver command handle.
A command handle is returned by a call to the Read or Write functions. This handle allows the application to track the completion of the operation.
This command handle is also returned to the client along with the event that has occurred with respect to the command. This allows the application
to connect the event to a specific command in case where multiple commands are queued.
The command handle associated with the command request expires when the client has been notified of the completion of the command (after
event handler function that notifies the client returns) or after the command has been retired by the driver if no event handler callback was set.
Remarks
None.
DRV_SRAM_COMMAND_STATUS Enumeration
Specifies the status of the command for the read and write operations.
File
drv_sram.h
C
typedef enum {
DRV_SRAM_COMMAND_COMPLETED = SYS_FS_MEDIA_COMMAND_COMPLETED,
DRV_SRAM_COMMAND_QUEUED = SYS_FS_MEDIA_COMMAND_QUEUED,
DRV_SRAM_COMMAND_IN_PROGRESS = SYS_FS_MEDIA_COMMAND_IN_PROGRESS,
DRV_SRAM_COMMAND_ERROR_UNKNOWN = SYS_FS_MEDIA_COMMAND_UNKNOWN
} DRV_SRAM_COMMAND_STATUS;
Members
Members Description
DRV_SRAM_COMMAND_COMPLETED =
SYS_FS_MEDIA_COMMAND_COMPLETED
Done OK and ready
DRV_SRAM_COMMAND_QUEUED =
SYS_FS_MEDIA_COMMAND_QUEUED
Scheduled but not started
DRV_SRAM_COMMAND_IN_PROGRESS =
SYS_FS_MEDIA_COMMAND_IN_PROGRESS
Currently being in transfer
Volume V: MPLAB Harmony Framework Driver Libraries Help SRAM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 965
DRV_SRAM_COMMAND_ERROR_UNKNOWN
= SYS_FS_MEDIA_COMMAND_UNKNOWN
Unknown Command
Description
SRAM Driver Command Status
SRAM Driver command Status
This type specifies the status of the command for the read and write operations.
Remarks
None.
DRV_SRAM_EVENT Enumeration
Identifies the possible events that can result from a request.
File
drv_sram.h
C
typedef enum {
DRV_SRAM_EVENT_COMMAND_COMPLETE = SYS_FS_MEDIA_EVENT_BLOCK_COMMAND_COMPLETE,
DRV_SRAM_EVENT_COMMAND_ERROR = SYS_FS_MEDIA_EVENT_BLOCK_COMMAND_ERROR
} DRV_SRAM_EVENT;
Members
Members Description
DRV_SRAM_EVENT_COMMAND_COMPLETE =
SYS_FS_MEDIA_EVENT_BLOCK_COMMAND_COMPLETE
Operation has been completed successfully.
DRV_SRAM_EVENT_COMMAND_ERROR =
SYS_FS_MEDIA_EVENT_BLOCK_COMMAND_ERROR
There was an error during the operation
Description
SRAM Driver Events
This enumeration identifies the possible events that can result from a read or a write request caused by the client.
Remarks
One of these values is passed in the "event" parameter of the event handling callback function that client registered with the driver by calling the
DRV_SRAM_EventHandlerSet function when a request is completed.
DRV_SRAM_EVENT_HANDLER Type
Pointer to a SRAM Driver Event handler function
File
drv_sram.h
C
typedef SYS_FS_MEDIA_EVENT_HANDLER DRV_SRAM_EVENT_HANDLER;
Returns
None.
Description
SRAM Driver Event Handler Function Pointer
This data type defines the required function signature for the SRAM event handling callback function. A client must register a pointer to an event
handling function whose function signature (parameter and return value types) match the types specified by this function pointer in order to receive
event callbacks from the driver.
The parameters and return values are described here and a partial example implementation is provided.
Remarks
If the event is DRV_SRAM_EVENT_COMMAND_COMPLETE, it means that the read or write operation was completed successfully.
Volume V: MPLAB Harmony Framework Driver Libraries Help SRAM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 966
If the event is DRV_SRAM_EVENT_COMMAND_ERROR, it means that the scheduled operation was not completed successfully.
The context parameter contains the handle to the client context, provided at the time the event handling function was registered using the
DRV_SRAM_EventHandlerSet function. This context handle value is passed back to the client as the "context" parameter. It can be any value
necessary to identify the client context or instance (such as a pointer to the client's data) instance of the client that made the read/write request.
The event handler function executes in the driver's context. It is recommended of the application to not perform process intensive or blocking
operations within this function.
Example
void APP_MySramEventHandler
(
DRV_SRAM_EVENT event,
DRV_SRAM_COMMAND_HANDLE commandHandle,
uintptr_t context
)
{
MY_APP_DATA_STRUCT pAppData = (MY_APP_DATA_STRUCT) context;
switch(event)
{
case DRV_SRAM_EVENT_COMMAND_COMPLETE:
// Handle the completed buffer.
break;
case DRV_SRAM_EVENT_COMMAND_ERROR:
default:
// Handle error.
break;
}
}
Parameters
Parameters Description
event Identifies the type of event
commandHandle Handle returned from the Read/Write requests
context Value identifying the context of the application that registered the event handling function
DRV_SRAM_INIT Structure
Defines the data required to initialize the SRAM driver
File
drv_sram.h
C
typedef struct {
bool registerWithFs;
uint8_t* mediaStartAddress;
const SYS_FS_MEDIA_GEOMETRY * sramMediaGeometry;
} DRV_SRAM_INIT;
Members
Members Description
bool registerWithFs; Flag to indicate if the driver is to be registered with the file system.
uint8_t* mediaStartAddress; SRAM Media start address. The driver treats this address as block 0
• address for read and write operations.
const SYS_FS_MEDIA_GEOMETRY *
sramMediaGeometry;
SRAM Media geometry object.
Description
SRAM Driver Initialization Data
This data type defines the data required to initialize the SRAM driver.
Volume V: MPLAB Harmony Framework Driver Libraries Help SRAM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 967
Remarks
None.
_DRV_SRAM_H Macro
File
drv_sram.h
C
#define _DRV_SRAM_H
Description
This is macro _DRV_SRAM_H.
DRV_SRAM_COMMAND_HANDLE_INVALID Macro
This value defines the SRAM Driver's Invalid Command Handle.
File
drv_sram.h
C
#define DRV_SRAM_COMMAND_HANDLE_INVALID SYS_FS_MEDIA_BLOCK_COMMAND_HANDLE_INVALID
Description
SRAM Driver Invalid Command Handle.
This value defines the SRAM Driver Invalid Command Handle. This value is returned by read/write routines when the command request is not
accepted.
Remarks
None.
DRV_SRAM_INDEX_0 Macro
SRAM driver index definitions
File
drv_sram.h
C
#define DRV_SRAM_INDEX_0 0
Description
Driver SRAM Module Index reference
These constants provide SRAM driver index definitions.
Remarks
These constants should be used in place of hard-coded numeric literals. These values should be passed into the DRV_SRAM_Initialize and
DRV_SRAM_Open routines to identify the driver instance in use.
DRV_SRAM_INDEX_1 Macro
File
drv_sram.h
C
#define DRV_SRAM_INDEX_1 1
Description
This is macro DRV_SRAM_INDEX_1.
Volume V: MPLAB Harmony Framework Driver Libraries Help SRAM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 968
Files
Files
Name Description
drv_sram.h SRAM Driver Interface Definition
Description
This section will list only the library's interface header file(s).
drv_sram.h
SRAM Driver Interface Definition
Enumerations
Name Description
DRV_SRAM_COMMAND_STATUS Specifies the status of the command for the read and write operations.
DRV_SRAM_EVENT Identifies the possible events that can result from a request.
Functions
Name Description
DRV_SRAM_AddressGet Returns the SRAM media start address
DRV_SRAM_Close Closes an opened-instance of the SRAM driver
DRV_SRAM_CommandStatus Gets the current status of the command.
DRV_SRAM_Deinitialize Deinitializes the specified instance of the SRAM driver module
DRV_SRAM_EventHandlerSet Allows a client to identify an event handling function for the driver to call back when an
operation has completed.
DRV_SRAM_GeometryGet Returns the geometry of the device.
DRV_SRAM_Initialize Initializes the SRAM instance for the specified driver index.
DRV_SRAM_IsAttached Returns the physical attach status of the SRAM.
DRV_SRAM_IsWriteProtected Returns the write protect status of the SRAM.
DRV_SRAM_Open Opens the specified SRAM driver instance and returns a handle to it
DRV_SRAM_Read Reads blocks of data from the specified block start address.
DRV_SRAM_Status Gets the current status of the SRAM driver module.
DRV_SRAM_Write Writes blocks of data starting from the specified block start address of the SRAM media.
Macros
Name Description
_DRV_SRAM_H This is macro _DRV_SRAM_H.
DRV_SRAM_COMMAND_HANDLE_INVALID This value defines the SRAM Driver's Invalid Command Handle.
DRV_SRAM_INDEX_0 SRAM driver index definitions
DRV_SRAM_INDEX_1 This is macro DRV_SRAM_INDEX_1.
Structures
Name Description
DRV_SRAM_INIT Defines the data required to initialize the SRAM driver
Types
Name Description
DRV_SRAM_COMMAND_HANDLE Handle identifying commands queued in the driver.
DRV_SRAM_EVENT_HANDLER Pointer to a SRAM Driver Event handler function
Description
SRAM Driver Interface Definition
The SRAM driver provides a simple interface to manage the SRAM Memory on Microchip microcontrollers. This file defines the interface definition
for the SRAM driver.
Volume V: MPLAB Harmony Framework Driver Libraries Help SRAM Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 969
File Name
drv_sram.h
Company
Microchip Technology Inc.
Timer Driver Library
This section describes the Timer Driver Library.
Introduction
This library provides an interface to manage the Timer module on the Microchip family of microcontrollers during different modes of operation.
Description
Timers are useful for generating accurate time based periodic interrupts for software application or real time operating systems. Other uses include
counting external pulses or accurate timing measurement of external events using the timer's gate functions and accurate hardware delays.
Note:
Not all features are available on all devices. Please refer to the specific device data sheet to determine availability.
Using the Library
This topic describes the basic architecture of the Timer Driver Library and provides information and examples on its use.
Description
Interface Header File: drv_tmr.h
The interface to the Timer Driver Library is defined in the drv_tmr.h header file.
Please refer to the What is MPLAB Harmony? section for how the driver interacts with the framework.
Abstraction Model
The Timer Driver abstracts the hardware by providing the capability to register callback functions to the application.
Description
Abstraction Model
The abstraction model of the Timer Driver is explained in the following diagram:
The core functionality of the Timer allows access to both the counter and the period values.
Library Overview
Refer to the Driver Library Overview section for information on how the driver operates in a system.
The library interface routines are divided into various sub-sections, which address one of the blocks or the overall operation of the Timer Driver
Library.
Volume V: MPLAB Harmony Framework Driver Libraries Help Timer Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 970
Library Interface
Section
Description
Configuration Provides macros for configuring the system. It is required that the system configures the driver to build correctly by
choosing appropriate configuration options as listed in this section. These macros enable different features or modes of
the timer peripheral.
System Interaction
Functions
Provides interfaces to system_layer to initialize, deinitialize and reinitialize the module. This section also describes
functions to query the status of the module.
Core Functions Provides interfaces for core functionality of the driver.
Alarm Functions Provides interfaces to handle alarm features, if alarm functionality is enabled.
Period Functions Provides interfaces to control the periodicity of the timers.
Counter Control
Functions
Provides interfaces to update the counter values.
Miscellaneous
Functions
Provides interfaces to get the version information, timer tick and operating frequencies.
How the Library Works
The library provides interfaces to support:
• System Interaction
• Sync Mode Setup
• Period Modification
• Counter Modification
• Client Core Functionality
• Client Alarm Functionality (optional function, enabled using configuration options)
• Other Optional Functionality (enabled using configuration options)
Note:
Any code segment pertaining to the driver interfaces will work for both the static or dynamic configurations. It is not necessary to
modify the code to move from one configuration to the other (i.e., from static or dynamic or static-multi).
System Interaction
This section describes Timer initialization and reinitialization.
Description
Initialization and Reinitialization
The system performs the initialization of the device driver with settings that affect only the instance of the device that is being initialized.
The DRV_TMR_Initialize function returns an object handle of the type SYS_MODULE_OBJ. After this, the object handle returned by the Initialize
interface would be used by the other system interfaces such as DRV_TMR_Deinitialize and DRV_TMR_Status, DRV_TMR_Tasks.
Example: Timer Initialization
DRV_TMR_INIT init;
SYS_MODULE_OBJ object;
SYS_STATUS tmrStatus;
// populate the TMR init configuration structure
init.moduleInit.value = SYS_MODULE_POWER_RUN_FULL;
init.tmrId = TMR_ID_2;
init.clockSource = TMR_CLOCK_SOURCE_PERIPHERAL_CLOCK;
init.prescale = TMR_PRESCALE_VALUE_256;
init.interruptSource = INT_SOURCE_TIMER_2;
init.mode = DRV_TMR_OPERATION_MODE_16_BIT;
init.asyncWriteEnable = false;
object = DRV_TMR_Initialize (DRV_TMR_INDEX_0, (SYS_MODULE_INIT *)&init);
if (object == SYS_MODULE_OBJ_INVALID)
{
// Handle error
}
Volume V: MPLAB Harmony Framework Driver Libraries Help Timer Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 971
Deinitialization
Once the Initialize operation has been called, the Deinitialize operation must be called before the Initialize operation can be called again. This
routine may block if the driver is running in an OS environment that supports blocking operations and the driver requires system resources access.
However, the routine will never block for hardware Timer access.
Status
Timer status is available to query the module state after initialization and reinitialization.
Tasks Routine
The interface DRV_TMR_Tasks needs to be called by the system task service in a polled environment and in an interrupt-based system.
Example: Polling
int main( void )
{
SYS_MODULE_OBJ object;
object = DRV_TMR_Initialize( DRV_TMR_INDEX_0, (SYS_MODULE_INIT *) &initConf );
if( SYS_STATUS_READY != DRV_TMR_Status( object ) )
return 0;
while (1)
{
DRV_TMR_Tasks (object);
}
}
Example: Interrupt
int main( void )
{
SYS_MODULE_OBJ object;
object = DRV_TMR_Initialize( DRV_TMR_INDEX_0, (SYS_MODULE_INIT *) &initConf );
if( SYS_STATUS_READY != DRV_TMR_Status( object ) )
return 0;
while (1);
}
/* Sample interrupt routine not specific to any device family */
void ISR T1Interrupt(void)
{
//Call the Timer Tasks routine
DRV_TMR_Tasks(object);
}
Client Interaction
This section describes general client operation.
Description
General Client Operation
For the application to begin using an instance of the Timer module, it must call the DRV_TMR_Open function. This provides the configuration
required to open the Timer instance for operation.
The Timer Driver supports only the 'DRV_IO_INTENT_EXCLUSIVE' IO_INTENT.
Example:
DRV_HANDLE handle;
// Configure the instance DRV_TMR_INDEX_1 with the configuration
handle = DRV_TMR_Open(DRV_TMR_INDEX_1, DRV_IO_INTENT_EXCLUSIVE);
if( handle == DRV_HANDLE_INVALID )
{
// Client cannot open the instance.
}
The function DRV_TMR_Close closes an already opened instance of the Timer Driver, invalidating the handle. DRV_TMR_Open must have been
Volume V: MPLAB Harmony Framework Driver Libraries Help Timer Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 972
called to obtain a valid opened device handle.
Example:
DRV_HANDLE handle;
// Configure the instance DRV_TMR_INDEX_1 with the configuration
handle = DRV_TMR_Open(DRV_TMR_INDEX_1, DRV_IO_INTENT_EXCLUSIVE);
/*...*/
DRV_TMR_Close( handle );
The client has the option to check the status through the interface DRV_TMR_ClientStatus.
Example:
DRV_HANDLE handle;
// Configure the instance DRV_TMR_INDEX_1 with the configuration
handle = DRV_TMR_Open(DRV_TMR_INDEX_1, DRV_IO_INTENT_EXCLUSIVE);
if ( DRV_TMR_CLIENT_STATUS_READY != DRV_TMR_ClientStatus( handle ) )
return 0;
Modification
This section describes Period modification for the different types of Timers (i.e., 16-/32-bit).
Description
These set of functions help modify the Timer periodicity at the client level.
Period Modification
Periodicity of Timer (16/32-bit) can be modified using DRV_TMR_AlarmPeriodSet and the current period can be obtained using
DRV_TMR_AlarmPeriodGet.
Example:
DRV_HANDLE handle;
/* Open the client */
handle = DRV_TMR_Open( DRV_TMR_INDEX_0, DRV_IO_INTENT_EXCLUSIVE );
/* ... */
/* Update the new period */
DRV_TMR_AlarmPeriodSet( handle, 0xC350);
Counter Modification
This section describes counter modification for the different types of Timers (i.e., 8-/16-/32-bit).
Description
These set of functions help modify the initial value of the Timer counters to help adjust any errors in the periodicity.
Counter Modification
The Timer initial value can be modified using DRV_TMR_CounterValueSet and the current counter value can be obtained using
DRV_TMR_CounterValueGet.
Example:
DRV_HANDLE handle;
/* Open the client */
handle = DRV_TMR_Open( DRV_TMR_INDEX_0, DRV_IO_INTENT_EXCLUSIVE );
/* ... */
/* Update the counter value */
/* Following code updates the initial value from 0x0000 to 0x0010
to cover up any error in the previously set periodicity */
DRV_TMR_CounterValueSet( handle, 0x0010);
Volume V: MPLAB Harmony Framework Driver Libraries Help Timer Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 973
Core Functionality
This section describes core functionality of the Timer Driver.
Description
Core functionality provides an extremely basic interface for the driver operation.
Applications using the Timer core functionality need to perform the following:
1. The system should have completed the necessary initialization and DRV_TMR_Tasks should be called in a polled/interrupt environment.
2. Open_the driver using DRV_TMR_Open. The Timer Driver only supports exclusive access.
3. The Timer can be updated using DRV_TMR_AlarmPeriodSet. The previously set value can be retrieved using DRV_TMR_AlarmPeriodGet.
4. Start the driver using DRV_TMR_Start.
5. Poll for the elapsed alarm status using DRV_TMR_AlarmHasElapsed.
6. The client will be able to stop the started Timer instance using DRV_TMR_Stop at any time and will be able to close it using DRV_TMR_Close
when it is no longer required.
Example:
/* Open the client */
handle = DRV_TMR_Open( DRV_TMR_INDEX_0, DRV_IO_INTENT_EXCLUSIVE );
DRV_TMR_Start (handle);
unsigned int alarmCount = 0;
while (1)
{
if (true == DRV_TMR_AlarmHasElapsed (handle))
{
alarmCount++;
// Do something
}
}
Notes:
1. The user needs to stop the Timer before any updates on the counter or period and restart it later.
2. The Timer alarm count gets reset after any call to DRV_TMR_AlarmHasElapsed.
3. The Timer alarm status remains unchanged if the user stops the timer and restarts later.
Alarm Functionality
This section describes the Timer Driver alarm functionality.
Description
The Timer Driver provides alarm functionality.
Applications using the Timer alarm functionality, need to perform the following:
1. The system should have completed the necessary initialization and DRV_TMR_Tasks should be running in either a polled environment or in an
interrupt environment.
2. Open_the driver using DRV_TMR_Open. The Timer Driver supports exclusive access only.
3. Configure the alarm using DRV_TMR_AlarmRegister.
4. Start the driver using DRV_TMR_Start.
5. If a callback is supplied, the Timer Driver will call the callback function when the alarm expires.
6. The client will be able to stop the started Timer module instance using DRV_TMR_Stop at any time and will be able to close it using
DRV_TMR_Close when it is no longer required.
7. The client can deregister the callback by using DRV_TMR_AlarmDeregister.
Example:
DRV_HANDLE handle;
/* Open the client */
handle = DRV_TMR_Open (DRV_TMR_INDEX_0, DRV_IO_INTENT_EXCLUSIVE);
/* Configure the timer alarm feature */
uint32_t myFreq = 1000; // 1KHz
uint32_t clkFreq = DRV_TMR_CounterFrequencyGet(tmrHandle); // timer running frequency
// calculate the divider needed
uint32_t divider = clkFreq / myFreq;
// Start the alarm
if(!DRV_TMR_AlarmRegister ( tmrHandle, divider, true, 0, CallBackFreq ))
Volume V: MPLAB Harmony Framework Driver Libraries Help Timer Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 974
{
// divider value could not be obtain;
// handle the error
//
return;
}
DRV_TMR_Start (handle);
// The driver tasks function calls the client registered callback after the alarm expires.
void CallBackFreq (uintptr_t context, uint32_t alarmCount)
{
// Do something specific on an alarm event trigger
}
Optional Interfaces
This section describes additional/optional client interfaces.
Description
Additional/Optional client interfaces include the following:
Get Operating Frequency
The function DRV_TMR_CounterFrequencyGet provides the client with the information on the Timer operating frequency.
Example:
DRV_HANDLE handle;
uint32_t freq;
/* Open the client */
handle = DRV_TMR_Open (DRV_TMR_INDEX_0, DRV_IO_INTENT_EXCLUSIVE);
freq = DRV_TMR_OperatingFrequencyGet (handle);
Example Usage of the Timer Driver
This section describes typical usage of the Timer Driver for various Timer modules in polling/interrupt advanced/core modes.
Description
The user can pass NULL to the driver initialize interface. However, the respective configuration parameters need to be configured in the correct
manner.
Example:
//Polled mode under 32-bit count mode for a PIC32 device using the alarm feature
SYS_MODULE_OBJ object;
// main
DRV_TMR_INIT init;
DRV_HANDLE handle;
init.moduleInit.value = SYS_MODULE_POWER_RUN_FULL;
init.tmrId = TMR_ID_2;
init.clockSource = TMR_CLKSOURCE_INTERNAL;
init.prescale = TMR_PRESCALE_TX_VALUE_256;
init.interruptSource = INT_SOURCE_TIMER_3;
init.mode = DRV_TMR_OPERATION_MODE_16_BIT;init.asyncWriteEnable = false;
object = DRV_TMR_Initialize (DRV_TMR_INDEX_0, (SYS_MODULE_INIT *)&init);
if ( SYS_STATUS_READY != DRV_TMR_Status(object))
return 0;
handle = DRV_TMR_Open (DRV_TMR_INDEX_0, DRV_IO_INTENT_EXCLUSIVE);
if ( DRV_TMR_CLIENT_STATUS_READY != DRV_TMR_ClientStatus(handle))
return 0;
if(!DRV_TMR_AlarmRegister ( tmrHandle, divider, true, 0, AlarmCallback ))
{
// divider value could not be obtain;
Volume V: MPLAB Harmony Framework Driver Libraries Help Timer Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 975
// handle the error
}
DRV_TMR_Start (handle);
while (1)
{
DRV_TMR_Tasks (object);
}
DRV_TMR_Stop (handle);
DRV_TMR_Close (handle);
if ( DRV_TMR_CLIENT_STATUS_INVALID != DRV_TMR_ClientStatus(handle))
return 0;
DRV_TMR_Deinitialize (object);
// end main
void AlarmCallback (uintptr_t context, uint32_t alarmCount)
{
// Do something specific on an alarm event trigger
}
Configuring the Library
Macros
Name Description
DRV_TMR_INSTANCES_NUMBER Sets up the maximum number of hardware instances that can be supported by the
dynamic driver.
DRV_TMR_INTERRUPT_MODE Controls operation of the driver in the interrupt or polled mode.
DRV_TMR_CLOCK_PRESCALER Sets the default timer driver clock prescaler.
DRV_TMR_MODE Sets the default timer driver clock operating mode.
DRV_TMR_MODULE_ID Sets the default timer module ID to be used by the timer driver.
DRV_TMR_MODULE_INIT Sets the default module init value for the timer driver.
DRV_TMR_INTERRUPT_SOURCE Sets the default timer driver clock interrupt source
DRV_TMR_ASYNC_WRITE_ENABLE Controls Asynchronous Write mode of the Timer.
DRV_TMR_CLOCK_SOURCE Sets the default timer driver clock source.
DRV_TMR_CLIENTS_NUMBER Sets up the maximum number of clients that can be supported by an instance of the
dynamic driver.
Description
The configuration of the Timer Driver Library is based on the file system_config.h.
This header file contains the configuration selection for the Timer Driver Library build. Based on the selections made here and the system setup,
the Timer Driver may support the selected features. These configuration settings will apply to all instances of the driver.
This header can be placed anywhere in the application-specific folders and the path of this header needs to be presented to the include search for
a successful build. Refer to the Applications Help section for more details.
DRV_TMR_INSTANCES_NUMBER Macro
Sets up the maximum number of hardware instances that can be supported by the dynamic driver.
File
drv_tmr_config_template.h
C
#define DRV_TMR_INSTANCES_NUMBER 5
Description
Hardware instances support
This definition sets up the maximum number of hardware instances that can be supported by the dynamic driver.
Volume V: MPLAB Harmony Framework Driver Libraries Help Timer Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 976
Remarks
None
DRV_TMR_INTERRUPT_MODE Macro
Controls operation of the driver in the interrupt or polled mode.
File
drv_tmr_config_template.h
C
#define DRV_TMR_INTERRUPT_MODE true
Description
TMR Interrupt And Polled Mode Operation Control
This macro controls the operation of the driver in the interrupt mode of operation. The possible values of this macro are:
• true - Select if interrupt mode of timer operation is desired
• false - Select if polling mode of timer operation is desired
Not defining this option to true or false will result in a build error.
Remarks
None.
DRV_TMR_CLOCK_PRESCALER Macro
Sets the default timer driver clock prescaler.
File
drv_tmr_config_template.h
C
#define DRV_TMR_CLOCK_PRESCALER (TMR_PRESCALE_VALUE_256)
Description
Default timer driver clock prescaler
This macro sets the default timer driver clock prescaler.
Remarks
This value can be overridden by a run time initialization value.
DRV_TMR_MODE Macro
Sets the default timer driver clock operating mode.
File
drv_tmr_config_template.h
C
#define DRV_TMR_MODE (DRV_TMR_OPERATION_MODE_16_BIT)
Description
Default timer driver clock operating mode
This macro sets the default timer driver clock operating mode.
Remarks
This value can be overridden by a run time initialization value.
Volume V: MPLAB Harmony Framework Driver Libraries Help Timer Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 977
DRV_TMR_MODULE_ID Macro
Sets the default timer module ID to be used by the timer driver.
File
drv_tmr_config_template.h
C
#define DRV_TMR_MODULE_ID (TMR_ID_2)
Description
Default timer driver index
This macro sets the default timer module ID to be used by the timer driver.
Remarks
This value can be overridden by a run time initialization value.
DRV_TMR_MODULE_INIT Macro
Sets the default module init value for the timer driver.
File
drv_tmr_config_template.h
C
#define DRV_TMR_MODULE_INIT (SYS_MODULE_POWER_RUN_FULL)
Description
Default module init object configuration
This macro sets the default module init value for the timer driver.
Remarks
This value can be overridden by a run time initialization value.
DRV_TMR_INTERRUPT_SOURCE Macro
Sets the default timer driver clock interrupt source
File
drv_tmr_config_template.h
C
#define DRV_TMR_INTERRUPT_SOURCE (INT_SOURCE_TIMER_2)
Description
Default timer driver clock interrupt source
This macro sets the default timer driver clock interrupt source
Remarks
This value can be overridden by a run time initialization value.
DRV_TMR_ASYNC_WRITE_ENABLE Macro
Controls Asynchronous Write mode of the Timer.
File
drv_tmr_config_template.h
C
#define DRV_TMR_ASYNC_WRITE_ENABLE false
Volume V: MPLAB Harmony Framework Driver Libraries Help Timer Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 978
Description
TMR Asynchronous write mode configuration
This macro controls the Asynchronous Write mode of the Timer. This macro accepts the following values:
• true - Configures the Timer to enable asynchronous write control
• false - Configures the Timer to disable asynchronous write control
• DRV_CONFIG_NOT_SUPPORTED - When the feature is not supported on the instance.
Remarks
This feature is not available in all modules/devices. Refer to the specific device data sheet for more information.
DRV_TMR_CLOCK_SOURCE Macro
Sets the default timer driver clock source.
File
drv_tmr_config_template.h
C
#define DRV_TMR_CLOCK_SOURCE (DRV_TMR_CLKSOURCE_INTERNAL)
Description
Default timer driver clock source
This macro sets the default timer driver clock source.
Remarks
This value can be overridden by a run time initialization value.
DRV_TMR_CLIENTS_NUMBER Macro
Sets up the maximum number of clients that can be supported by an instance of the dynamic driver.
File
drv_tmr_config_template.h
C
#define DRV_TMR_CLIENTS_NUMBER 1
Description
Client instances support
This definition sets up the maximum number of clients that can be supported by an instance of the dynamic driver.
Remarks
Currently each client is required to get exclusive access to the timer module. Therfore the DRV_TMR_CLIENTS_NUMBER should always be set
to 1.
Building the Library
This section lists the files that are available in the Timer Driver Library.
Description
This section list the files that are available in the \src folder of the Timer Driver. It lists which files need to be included in the build based on either
a hardware feature present on the board or configuration option selected by the system.
The following three tables list and describe the header (.h) and source (.c) files that implement this library. The parent folder for these files is
/framework/driver/tmr.
Interface File(s)
This table lists and describes the header files that must be included (i.e., using #include) by any code that uses this library.
Volume V: MPLAB Harmony Framework Driver Libraries Help Timer Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 979
Source File Name Description
/drv_tmr.h Header file that exports the driver API.
Required File(s)
All of the required files listed in the following table are automatically added into the MPLAB X IDE project by the MHC
when the library is selected for use.
This table lists and describes the source and header files that must always be included in the MPLAB X IDE project to build this library.
Source File Name Description
/src/dynamic/drv_tmr_dynamic.c Basic Timer driver implementation file.
Optional File(s)
This table lists and describes the source and header files that may optionally be included if required for the desired implementation.
Source File Name Description
N/A No optional files are available for this library
Module Dependencies
The Timer Driver Library depends on the following modules:
• Clock System Service Library
• Interrupt System Service Library
• Interrupt Peripheral Library
• Device Control System Service Library
Library Interface
a) System Interaction Functions
Name Description
DRV_TMR_Deinitialize Deinitializes the specified instance of the Timer driver.
Implementation: Dynamic
DRV_TMR_Initialize Initializes the Timer driver.
Implementation: Static/Dynamic
DRV_TMR_Status Provides the current status of the Timer driver.
Implementation: Dynamic
DRV_TMR_Tasks Maintains the driver's state machine.
Implementation: Dynamic
DRV_TMR_ClockSet Sets the timers clock by selecting the source and prescaler.
Implementation: Dynamic
DRV_TMR_GateModeSet Enables the Gate mode.
Implementation: Dynamic
b) Core Functions
Name Description
DRV_TMR_ClientStatus Gets the status of the client operation.
Implementation: Dynamic
DRV_TMR_Close Closes an opened instance of the Timer driver.
Implementation: Dynamic
DRV_TMR_Open Opens the specified Timer driver instance and returns a handle to it.
Implementation: Dynamic
DRV_TMR_Start Starts the Timer counting.
Implementation: Static/Dynamic
DRV_TMR_Stop Stops the Timer from counting.
Implementation: Static/Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help Timer Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 980
c) Alarm Functions
Name Description
DRV_TMR_AlarmHasElapsed Provides the status of Timer's period elapse.
Implementation: Dynamic
DRV_TMR_AlarmDisable Disables an alarm signal.
Implementation: Dynamic
DRV_TMR_AlarmEnable Re-enables an alarm signal.
Implementation: Dynamic
DRV_TMR_AlarmDeregister Removes a previously set alarm.
Implementation: Dynamic
DRV_TMR_AlarmPeriodGet Provides the Timer's period.
Implementation: Dynamic
DRV_TMR_AlarmPeriodSet Updates the Timer's period.
Implementation: Dynamic
DRV_TMR_AlarmRegister Sets up an alarm.
Implementation: Dynamic
d) Counter Control Functions
Name Description
DRV_TMR_CounterFrequencyGet Provides the Timer input frequency.
Implementation: Dynamic
DRV_TMR_CounterClear Clears the Timer's counter register.
Implementation: Static/Dynamic
DRV_TMR_CounterValueGet Reads the Timer's counter register.
Implementation: Static/Dynamic
DRV_TMR_CounterValueSet Updates the Timer's counter register.
Implementation: Static/Dynamic
e) Miscellaneous Functions
Name Description
DRV_TMR_GateModeClear Enables the Gate mode.
Implementation: Dynamic
DRV_TMR_PrescalerGet This function gets the currently selected prescaler.
Implementation: Dynamic
DRV_TMR_OperationModeGet This function gets the currently selected operation mode.
Implementation: Dynamic
DRV_TMR_DividerRangeGet Returns the Timer divider values.
Implementation: Dynamic
f) Data Types and Constants
Name Description
DRV_TMR_CALLBACK Pointer to a Timer driver callback function data type.
DRV_TMR_INIT Defines the Timer driver initialization data.
DRV_TMR_CLIENT_STATUS Identifies the client-specific status of the Timer driver
DRV_TMR_DIVIDER_RANGE This data structure specifies the divider values that can be obtained by the timer module.
DRV_TMR_OPERATION_MODE Lists the operation modes available for timer driver.
DRV_TMR_INDEX_COUNT Number of valid Timer driver indices.
DRV_TMR_INDEX_0 Timer driver index definitions
DRV_TMR_INDEX_1 This is macro DRV_TMR_INDEX_1.
DRV_TMR_INDEX_2 This is macro DRV_TMR_INDEX_2.
DRV_TMR_INDEX_3 This is macro DRV_TMR_INDEX_3.
DRV_TMR_INDEX_4 This is macro DRV_TMR_INDEX_4.
DRV_TMR_INDEX_5 This is macro DRV_TMR_INDEX_5.
DRV_TMR_INDEX_6 This is macro DRV_TMR_INDEX_6.
DRV_TMR_INDEX_7 This is macro DRV_TMR_INDEX_7.
DRV_TMR_INDEX_8 This is macro DRV_TMR_INDEX_8.
Volume V: MPLAB Harmony Framework Driver Libraries Help Timer Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 981
DRV_TMR_INDEX_9 This is macro DRV_TMR_INDEX_9.
DRV_TMR_INDEX_10 This is macro DRV_TMR_INDEX_10.
DRV_TMR_INDEX_11 This is macro DRV_TMR_INDEX_11.
Description
This section describes the functions of the Timer Driver Library.
Refer to each section for a detailed description.
a) System Interaction Functions
DRV_TMR_Deinitialize Function
Deinitializes the specified instance of the Timer driver.
Implementation: Dynamic
File
drv_tmr.h
C
void DRV_TMR_Deinitialize(SYS_MODULE_OBJ object);
Returns
None.
Description
Deinitializes the specified instance of the Timer driver, disabling its operation (and any hardware). All internal data is invalidated.
Remarks
Once the Initialize operation has been called, the Deinitialize operation must be called before the Initialize operation can be called again.
This function will NEVER block waiting for hardware. If the operation requires time to allow the hardware to complete, this will be reported by the
DRV_TMR_Status operation. The system has to use DRV_TMR_Status to find out when the module is in the ready state.
Preconditions
The DRV_TMR_Initialize function must have been called before calling this function and a valid SYS_MODULE_OBJ must have been returned.
Example
SYS_MODULE_OBJ tmrObject; // Returned from DRV_TMR_Initialize
SYS_STATUS tmrStatus;
DRV_TMR_Deinitialize ( tmrObject );
tmrStatus = DRV_TMR_Status ( tmrObject );
if ( SYS_MODULE_UNINITIALIZED == tmrStatus )
{
// Check again later if you need to know
// when the driver is deinitialized.
}
Parameters
Parameters Description
object Driver object handle, returned from DRV_TMR_Initialize
Function
void DRV_TMR_Deinitialize ( SYS_MODULE_OBJ object )
DRV_TMR_Initialize Function
Initializes the Timer driver.
Implementation: Static/Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help Timer Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 982
File
drv_tmr.h
C
SYS_MODULE_OBJ DRV_TMR_Initialize(const SYS_MODULE_INDEX drvIndex, const SYS_MODULE_INIT * const init);
Returns
If successful, returns a valid handle to a driver object. Otherwise, it returns SYS_MODULE_OBJ_INVALID. The returned object must be passed as
argument to DRV_TMR_Deinitialize, DRV_TMR_Tasks and DRV_TMR_Status functions.
Description
This function initializes the Timer driver, making it ready for clients to open and use it.
Remarks
This function must be called before any other Timer driver function is called.
This function should only be called once during system initialization unless DRV_TMR_Deinitialize is called to deinitialize the driver instance.
This function will NEVER block for hardware access. The system must use DRV_TMR_Status to find out when the driver is in the ready state.
Build configuration options may be used to statically override options in the "init" structure and will take precedence over initialization data passed
using this function.
Preconditions
None.
Example
DRV_TMR_INIT init;
SYS_MODULE_OBJ objectHandle;
// Populate the timer initialization structure
init.moduleInit.value = SYS_MODULE_POWER_RUN_FULL;
init.tmrId = TMR_ID_2;
init.clockSource = DRV_TMR_CLKSOURCE_INTERNAL;
init.prescale = TMR_PRESCALE_VALUE_256;
init.interruptSource = INT_SOURCE_TIMER_2;
init.mode = DRV_TMR_OPERATION_MODE_16_BIT;
init.asyncWriteEnable = false;
// Do something
objectHandle = DRV_TMR_Initialize ( DRV_TMR_INDEX_0, (SYS_MODULE_INIT*)&init );
if ( SYS_MODULE_OBJ_INVALID == objectHandle )
{
// Handle error
}
Parameters
Parameters Description
drvIndex Index for the driver instance to be initialized
init Pointer to a data structure containing any data necessary to initialize the driver.
Function
SYS_MODULE_OBJ DRV_TMR_Initialize
(
const SYS_MODULE_INDEX drvIndex,
const SYS_MODULE_INIT * const init
)
DRV_TMR_Status Function
Provides the current status of the Timer driver.
Implementation: Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help Timer Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 983
File
drv_tmr.h
C
SYS_STATUS DRV_TMR_Status(SYS_MODULE_OBJ object);
Returns
SYS_STATUS_READY - Indicates that the driver is initialized and ready for operation
Description
This function provides the current status of the Timer driver.
Remarks
Any value greater than SYS_STATUS_READY is also a normal running state in which the driver is ready to accept new operations.
SYS_STATUS_ERROR - Indicates that the driver is in an error state
Any value less than SYS_STATUS_ERROR is also an error state.
SYS_MODULE_UNINITIALIZED - Indicates that the driver has been deinitialized
This value is less than SYS_STATUS_ERROR.
The this operation can be used to determine when any of the driver's module level operations has completed.
Once the status operation returns SYS_STATUS_READY, the driver is ready for operation.
The value of SYS_STATUS_ERROR is negative (-1). Any value less than that is also an error state.
This function will NEVER block waiting for hardware.
Preconditions
The DRV_TMR_Initialize function must have been called before calling this function.
Example
SYS_MODULE_OBJ object; // Returned from DRV_TMR_Initialize
SYS_STATUS tmrStatus;
tmrStatus = DRV_TMR_Status ( object );
else if ( SYS_STATUS_ERROR >= tmrStatus )
{
// Handle error
}
Parameters
Parameters Description
object Driver object handle, returned from DRV_TMR_Initialize
Function
SYS_STATUS DRV_TMR_Status ( SYS_MODULE_OBJ object )
DRV_TMR_Tasks Function
Maintains the driver's state machine.
Implementation: Dynamic
File
drv_tmr.h
C
void DRV_TMR_Tasks(SYS_MODULE_OBJ object);
Returns
None
Description
This function is used to maintain the driver's internal state machine and processes the timer events..
Volume V: MPLAB Harmony Framework Driver Libraries Help Timer Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 984
Remarks
This function is normally not called directly by an application. It is called by the system's Tasks routine (SYS_Tasks)
Preconditions
The DRV_TMR_Initialize function must have been called for the specified Timer driver instance.
Example
SYS_MODULE_OBJ object; // Returned from DRV_TMR_Initialize
while (true)
{
DRV_TMR_Tasks ( object );
// Do other tasks
}
Parameters
Parameters Description
object Object handle for the specified driver instance (returned from DRV_TMR_Initialize)
Function
void DRV_TMR_Tasks ( SYS_MODULE_OBJ object )
DRV_TMR_ClockSet Function
Sets the timers clock by selecting the source and prescaler.
Implementation: Dynamic
File
drv_tmr.h
C
bool DRV_TMR_ClockSet(DRV_HANDLE handle, DRV_TMR_CLK_SOURCES clockSource, TMR_PRESCALE preScale);
Returns
• true - if the operation is successful
• false - either the handle is invalid or the clockSource and/or prescaler are not supported
Description
This function sets the timer clock by selecting the source and prescaler. The clock sources are device specific, refer device datasheet for
supported clock sources. If unsupported clock source is passed then the behaviour of this function is unpredictable.
Remarks
None.
Preconditions
The DRV_TMR_Initialize function must have been called. Must have selected 32-Bit timer mode if mode selection is applicable.
DRV_TMR_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE tmrHandle; // Returned from DRV_TMR_Open
DRV_TMR_ClockSet ( tmrHandle, DRV_TMR_CLKSOURCE_INTERNAL, TMR_PRESCALE_VALUE_256 );
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
clockSource Clock source of the timer
preScale Timer's Prescaler divisor
Volume V: MPLAB Harmony Framework Driver Libraries Help Timer Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 985
Function
bool DRV_TMR_ClockSet
(
DRV_HANDLE handle,
DRV_TMR_CLK_SOURCES clockSource,
TMR_PRESCALE preScale
)
DRV_TMR_GateModeSet Function
Enables the Gate mode.
Implementation: Dynamic
File
drv_tmr.h
C
bool DRV_TMR_GateModeSet(DRV_HANDLE handle);
Returns
• true - if the operation is successful
• false - either the handle is invalid or the gate mode is not supported
Description
This function enables the Gated mode of Timer. User can measure the duration of an external signal in this mode. Once the Gate mode is
enabled, Timer will start on the raising edge of the external signal. It will keep counting until the next falling edge.
Remarks
None.
Preconditions
The DRV_TMR_Initialize function must have been called.
DRV_TMR_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE tmrHandle; // Returned from DRV_TMR_Open
DRV_TMR_GateModeSet ( tmrHandle );
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
bool DRV_TMR_GateModeSet ( DRV_HANDLE handle )
b) Core Functions
DRV_TMR_ClientStatus Function
Gets the status of the client operation.
Implementation: Dynamic
File
drv_tmr.h
C
DRV_TMR_CLIENT_STATUS DRV_TMR_ClientStatus(DRV_HANDLE handle);
Volume V: MPLAB Harmony Framework Driver Libraries Help Timer Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 986
Returns
None
Description
This function gets the status of the recently completed client level operation.
Remarks
None.
Preconditions
The DRV_TMR_Initialize function must have been called for the specified Timer driver instance.
DRV_TMR_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE tmrHandle; // Returned from DRV_TMR_Open
DRV_TMR_CLIENT_STATUS tmrDrvStatus;
tmrDrvStatus = DRV_TMR_ClientStatus ( tmrHandle );
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
DRV_TMR_CLIENT_STATUS DRV_TMR_ClientStatus ( DRV_HANDLE handle )
DRV_TMR_Close Function
Closes an opened instance of the Timer driver.
Implementation: Dynamic
File
drv_tmr.h
C
void DRV_TMR_Close(DRV_HANDLE handle);
Returns
None
Description
This function closes an opened instance of the Timer driver, invalidating the handle.
Remarks
After calling this function, the handle passed in "handle" must not be used with any of the remaining driver functions. A new handle must be
obtained by calling DRV_TMR_Open before the caller may use the driver again.
Usually there is no need for the driver client to verify that the Close operation has completed.
Preconditions
The DRV_TMR_Initialize function must have been called for the specified Timer driver instance.
DRV_TMR_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE handle; // Returned from DRV_TMR_Open
DRV_TMR_Close ( handle );
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Volume V: MPLAB Harmony Framework Driver Libraries Help Timer Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 987
Function
void DRV_TMR_Close ( DRV_HANDLE handle )
DRV_TMR_Open Function
Opens the specified Timer driver instance and returns a handle to it.
Implementation: Dynamic
File
drv_tmr.h
C
DRV_HANDLE DRV_TMR_Open(const SYS_MODULE_INDEX index, const DRV_IO_INTENT intent);
Returns
If successful, the function returns a valid open instance handle (a number identifying both the caller and the module instance).
If an error occurs, the return value is DRV_HANDLE_INVALID.
Description
This function opens the specified Timer driver instance and provides a handle that must be provided to all other client-level operations to identify
the caller and the instance of the driver. Timer driver does not support multiple clients. If two tasks want to use the timer, one should wait until the
other one gets closed.
Remarks
The handle returned is valid until the DRV_TMR_Close function is called.
This function will NEVER block waiting for hardware.
If the requested intent flags are not supported, the function will return DRV_HANDLE_INVALID.
The Timer driver does not support DRV_IO_INTENT_SHARED. Only exclusive access is supported for now.
Preconditions
The DRV_TMR_Initialize function must have been called before calling this function.
Example
DRV_HANDLE handle;
handle = DRV_TMR_Open ( DRV_TMR_INDEX_0, DRV_IO_INTENT_EXCLUSIVE );
if ( DRV_HANDLE_INVALID == handle )
{
// Unable to open the driver
}
Parameters
Parameters Description
index Identifier for the object instance to be opened
intent Zero or more of the values from the enumeration DRV_IO_INTENT ORed together to indicate
the intended use of the driver
Function
DRV_HANDLE DRV_TMR_Open
(
const SYS_MODULE_INDEX index,
const DRV_IO_INTENT intent
)
DRV_TMR_Start Function
Starts the Timer counting.
Implementation: Static/Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help Timer Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 988
File
drv_tmr.h
C
bool DRV_TMR_Start(DRV_HANDLE handle);
Returns
• true - if the operation succeeded
• false - the supplied handle is invalid or the client doesn't have the needed parameters to run (alarm callback and period )
Description
This function starts the Timer counting.
Remarks
None.
Preconditions
The DRV_TMR_Initialize function must have been called.
DRV_TMR_Open must have been called to obtain a valid opened device handle.
Timer parameters must have been set by a call to DRV_TMR_AlarmRegister.
Example
DRV_HANDLE tmrHandle; // Returned from DRV_TMR_Open
DRV_TMR_AlarmRegister(tmrHandle, 0x100, true, 0, myTmrCallback);
DRV_TMR_Start ( tmrHandle );
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
bool DRV_TMR_Start ( DRV_HANDLE handle )
DRV_TMR_Stop Function
Stops the Timer from counting.
Implementation: Static/Dynamic
File
drv_tmr.h
C
void DRV_TMR_Stop(DRV_HANDLE handle);
Returns
None.
Description
This function stops the running Timer from counting.
Remarks
None.
Preconditions
The DRV_TMR_Initialize function must have been called.
DRV_TMR_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE handle; // Returned from DRV_TMR_Open
Volume V: MPLAB Harmony Framework Driver Libraries Help Timer Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 989
DRV_TMR_Stop ( handle );
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
void DRV_TMR_Stop ( DRV_HANDLE handle )
c) Alarm Functions
DRV_TMR_AlarmHasElapsed Function
Provides the status of Timer's period elapse.
Implementation: Dynamic
File
drv_tmr.h
C
uint32_t DRV_TMR_AlarmHasElapsed(DRV_HANDLE handle);
Returns
Number of times timer has elapsed since the last call.
Description
This function returns the number of times Timer's period has elapsed since last call to this API has made. On calling this API, the internally
maintained counter will be cleared and count will be started again from next elapse.
Remarks
None.
Preconditions
The DRV_TMR_Initialize function must have been called.
DRV_TMR_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE tmrHandle; // Returned from DRV_TMR_Open
bool elapseStatus;
SYS_MODULE_OBJ tmrObject // Returned by DRV_TMR_Initialize
unsigned int appInternalTime = 0;
Sys_Tasks()
{
//Timer task will be called from ISR
APP_TimeUpdate_Task();
//Other Tasks
}
void APP_TimeUpdate_Task ( void )
{
//We will not miss a count even though we are late
appInternalTime += DRV_TMR_AlarmHasElapsed ( tmrHandle );
}
Parameters
Parameters Description
handle A valid handle, returned from the DRV_TMR_Open
Volume V: MPLAB Harmony Framework Driver Libraries Help Timer Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 990
Function
unsigned int DRV_TMR_AlarmHasElapsed ( DRV_HANDLE handle )
DRV_TMR_AlarmDisable Function
Disables an alarm signal.
Implementation: Dynamic
File
drv_tmr.h
C
bool DRV_TMR_AlarmDisable(DRV_HANDLE handle);
Returns
The current status of the alarm:
• true if the alarm was currently enabled
• false if the alarm was currently disabled
Description
This function allows the client to disable an alarm generation. Use DRV_TMR_AlarmEnable to re-enable.
Remarks
When the driver operates in interrupts this call resolves to a device interrupt disable.
Do NOT disable the timer except for very short periods of time. If the time that the interrupt is disabled is longer than a wrap around period and the
interrupt is missed, the hardware has no means of recovering and the resulting timing will be inaccurate.
Preconditions
The DRV_TMR_Initialize function must have been called.
DRV_TMR_Open must have been called to obtain a valid opened device handle.
A client alarm must be active.
Example
Parameters
Parameters Description
handle A valid handle, returned from DRV_TMR_Open
Function
bool DRV_TMR_AlarmDisable ( DRV_HANDLE handle);
DRV_TMR_AlarmEnable Function
Re-enables an alarm signal.
Implementation: Dynamic
File
drv_tmr.h
C
void DRV_TMR_AlarmEnable(DRV_HANDLE handle, bool enable);
Returns
None
Description
This function allows the client to re-enable an alarm after it has been disabled by a DRV_TMR_AlarmDisable call.
Remarks
When the driver operates in interrupts this call resolves to a device interrupt re-enable.
Volume V: MPLAB Harmony Framework Driver Libraries Help Timer Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 991
Preconditions
The DRV_TMR_Initialize function must have been called. DRV_TMR_Open must have been called to obtain a valid opened device handle.
Example
Parameters
Parameters Description
handle A valid handle, returned from DRV_TMR_Open
enable boolean to enable the current callback
Function
void DRV_TMR_AlarmEnable ( DRV_HANDLE handle, bool enable );
DRV_TMR_AlarmDeregister Function
Removes a previously set alarm.
Implementation: Dynamic
File
drv_tmr.h
C
void DRV_TMR_AlarmDeregister(DRV_HANDLE handle);
Returns
None.
Description
This function removes a previously set alarm.
Remarks
None.
Preconditions
The DRV_TMR_Initialize function must have been called.
DRV_TMR_Open must have been called to obtain a valid opened device handle.
DRV_TMR_AlarmRegister function must have been called before.
Example
// Example of a key debounce check
static unsigned int lastReadKey, readKey, keyCount, globalKeyState;
DRV_HANDLE tmrHandle; // Returned from DRV_TMR_Open
void keyPressDetect ()
{
// Calculate the count to be passed on from the clock input
DRV_TMR_AlarmRegister ( tmrHandle, 0xFF00, true, DebounceCheck );
}
void DebounceCheck ( uintptr_t context )
{
readKey = AppReadKey();
if ( readKey != lastReadKey )
{
lastReadKey = readKey;
keyCount = 0;
}
else
{
if ( keyCount > 20 )
{
Volume V: MPLAB Harmony Framework Driver Libraries Help Timer Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 992
globalKeyState = readKey;
DRV_TMR_AlarmDeregister ( tmrHandle );
}
keyCount++;
}
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
void DRV_TMR_AlarmDeregister ( DRV_HANDLE handle )
DRV_TMR_AlarmPeriodGet Function
Provides the Timer's period.
Implementation: Dynamic
File
drv_tmr.h
C
uint32_t DRV_TMR_AlarmPeriodGet(DRV_HANDLE handle);
Returns
Timer period value:
• a 16 bit value if the timer is configured in 16 bit mode
• a 32 bit value if the timer is configured in 32 bit mode
Description
This function gets the Timer's period.
Remarks
None.
Preconditions
The DRV_TMR_Initialize function must have been called.
DRV_TMR_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE tmrHandle; // Returned from DRV_TMR_Open
uint32_t period;
period = DRV_TMR_AlarmPeriodGet ( tmrHandle );
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
uint32_t DRV_TMR_AlarmPeriodGet ( DRV_HANDLE handle )
DRV_TMR_AlarmPeriodSet Function
Updates the Timer's period.
Implementation: Dynamic
File
drv_tmr.h
Volume V: MPLAB Harmony Framework Driver Libraries Help Timer Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 993
C
void DRV_TMR_AlarmPeriodSet(DRV_HANDLE handle, uint32_t value);
Returns
None.
Description
This function updates the Timer's period.
Remarks
• The period value will be truncated to a 16 bit value if the timer is
configured in 16 bit mode.
Preconditions
The DRV_TMR_Initialize function must have been called.
DRV_TMR_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE handle; // Returned from DRV_TMR_Open
DRV_TMR_AlarmPeriodSet ( handle, 0x1000 );
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
value Period value
• a 16 bit value if the timer is configured in 16 bit mode
• a 32 bit value if the timer is configured in 32 bit mode
Function
void DRV_TMR_AlarmPeriodSet ( DRV_HANDLE handle, uint32_t value )
DRV_TMR_AlarmRegister Function
Sets up an alarm.
Implementation: Dynamic
File
drv_tmr.h
C
bool DRV_TMR_AlarmRegister(DRV_HANDLE handle, uint32_t divider, bool isPeriodic, uintptr_t context,
DRV_TMR_CALLBACK callBack);
Returns
• true - if the call succeeded
• false - the obtained divider could not be obtained or the passed handle was invalid
Description
This function sets up an alarm, allowing the client to receive a callback from the driver when the timer counter reaches zero. Alarms can be
one-shot or periodic. A periodic alarm will reload the timer and generate alarm until stopped. The alarm frequency is:
DRV_TMR_CounterFrequencyGet() / divider;
Remarks
The divider value will be truncated to a 16 bit value if the timer is configured in 16 bit mode. The timer should be started using DRV_TMR_Start
API to get a callback.
Preconditions
The DRV_TMR_Initialize function must have been called.
DRV_TMR_Open must have been called to obtain a valid opened device handle.
divider value has to be within the timer divider range (see DRV_TMR_DividerSpecGet).
Volume V: MPLAB Harmony Framework Driver Libraries Help Timer Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 994
Example
//Do the initialization with 'mode' set to DRV_TMR_OPERATION_MODE_16_BIT
void setupTask ()
{
DRV_HANDLE tmrHandle; // Returned from DRV_TMR_Open
uint32_t myFreq = 1000; // 1KHz
uint32_t clkFreq = DRV_TMR_CounterFrequencyGet(tmrHandle); // timer running frequency
// calculate the divider needed
uint32_t divider = clkFreq / myFreq;
// Start the alarm
if(!DRV_TMR_AlarmRegister ( tmrHandle, divider, true, 0, CallBackFreq ))
{
// divider value could not be obtain;
// handle the error
//
}
}
Parameters
Parameters Description
handle A valid handle, returned from DRV_TMR_Open
divider The value to divide the timer clock source to obtain the required alarm frequency.
• a 16 bit value if the timer is configured in 16 bit mode
• a 32 bit value if the timer is configured in 32 bit mode
isPeriodic Flag indicating whether the alarm should be one-shot or periodic.
context A reference, call back function will be called with the same reference.
callBack A call back function which will be called on time out.
Function
bool DRV_TMR_AlarmRegister
(
DRV_HANDLE handle,
uint32_t divider,
bool isPeriodic,
uintptr_t context,
DRV_TMR_CALLBACK callBack
)
d) Counter Control Functions
DRV_TMR_CounterFrequencyGet Function
Provides the Timer input frequency.
Implementation: Dynamic
File
drv_tmr.h
C
uint32_t DRV_TMR_CounterFrequencyGet(DRV_HANDLE handle);
Returns
32-bit value corresponding to the running frequency. If Timer clock source is external, then this function returns 0.
Volume V: MPLAB Harmony Framework Driver Libraries Help Timer Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 995
Description
This function provides the Timer input frequency. Input frequency is the clock to the Timer register and it is considering the prescaler divisor.
Remarks
On most processors, the Timer's base frequency is the same as the peripheral bus clock.
Preconditions
The DRV_TMR_Initialize function must have been called.
DRV_TMR_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE tmrHandle; // Returned from DRV_TMR_Open
uint32_t clkFreqHz;
clkFreqHz = DRV_TMR_CounterFrequencyGet ( tmrHandle );
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
uint32_t DRV_TMR_CounterFrequencyGet ( DRV_HANDLE handle )
DRV_TMR_CounterClear Function
Clears the Timer's counter register.
Implementation: Static/Dynamic
File
drv_tmr.h
C
void DRV_TMR_CounterClear(DRV_HANDLE handle);
Returns
None.
Description
This function clears the Timer's value in the counter register.
Remarks
None.
Preconditions
The DRV_TMR_Initialize function must have been called.
DRV_TMR_Open must have been called to obtain a valid opened device handle.
Example
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
void DRV_TMR_CounterClear ( DRV_HANDLE handle )
DRV_TMR_CounterValueGet Function
Reads the Timer's counter register.
Implementation: Static/Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help Timer Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 996
File
drv_tmr.h
C
uint32_t DRV_TMR_CounterValueGet(DRV_HANDLE handle);
Returns
Timer current period:
• a 16 bit value if the timer is configured in 16 bit mode
• a 32 bit value if the timer is configured in 32 bit mode
Description
This function returns the Timer's value in the counter register.
Remarks
None.
Preconditions
The DRV_TMR_Initialize function must have been called.
DRV_TMR_Open must have been called to obtain a valid opened device handle.
Example
//Example to use timer for precision time measurement
//without configuring an alarm (interrupt based)
char appState = 0;
DRV_HANDLE tmrHandle; // Returned from DRV_TMR_Open
switch ( appState )
{
case 0:
//Calculate and set the counter period
DRV_TMR_CounterValueSet ( tmrHandle, ( 0xFFFF - 0x1000 ) );
//counter starts
DRV_TMR_Start ( tmrHandle );
//Trigger an application operation
app_trigger_operation();
//Check for time-out in the next state
appState++;
case 1:
//Overflows and stops at 0 if no alarm is set
if ( DRV_TMR_CounterValueGet ( tmrHandle ) == 0 )
{
//Time-out
return false;
}
else if ( app_operation_isComplete( ) )
{
//Operation is complete before time-out
return true;
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
uint32_t DRV_TMR_CounterValueGet ( DRV_HANDLE handle )
Volume V: MPLAB Harmony Framework Driver Libraries Help Timer Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 997
DRV_TMR_CounterValueSet Function
Updates the Timer's counter register.
Implementation: Static/Dynamic
File
drv_tmr.h
C
void DRV_TMR_CounterValueSet(DRV_HANDLE handle, uint32_t counterPeriod);
Returns
None.
Description
This function updates the Timer's value in the counter register.
Remarks
None.
Preconditions
The DRV_TMR_Initialize function must have been called.
DRV_TMR_Open must have been called to obtain a valid opened device handle.
Example
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
counterPeriod counter period value
• a 16 bit value if the timer is configured in 16 bit mode
• a 32 bit value if the timer is configured in 32 bit mode
Function
void DRV_TMR_CounterValueSet ( DRV_HANDLE handle, uint32_t counterPeriod )
e) Miscellaneous Functions
DRV_TMR_GateModeClear Function
Enables the Gate mode.
Implementation: Dynamic
File
drv_tmr.h
C
bool DRV_TMR_GateModeClear(DRV_HANDLE handle);
Returns
• true - if the operation is successful
• false - either the handle is invalid or the gate mode is not supported
Description
This function enables the Gated mode of Timer. User can measure the duration of an external signal in this mode. Once the Gate mode is
enabled, Timer will start on the raising edge of the external signal. It will keep counting until the next falling edge.
Remarks
None.
Volume V: MPLAB Harmony Framework Driver Libraries Help Timer Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 998
Preconditions
The DRV_TMR_Initialize function must have been called.
DRV_TMR_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE tmrHandle; // Returned from DRV_TMR_Open
DRV_TMR_GateModeClear ( tmrHandle );
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
bool DRV_TMR_GateModeClear ( DRV_HANDLE handle )
DRV_TMR_PrescalerGet Function
This function gets the currently selected prescaler.
Implementation: Dynamic
File
drv_tmr.h
C
TMR_PRESCALE DRV_TMR_PrescalerGet(DRV_HANDLE handle);
Returns
Timer prescaler.
Description
This function gets the currently selected prescaler.
Remarks
None.
Preconditions
The DRV_TMR_Initialize function must have been called.
DRV_TMR_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE tmrHandle; // Returned from DRV_TMR_Open
TMR_PRESCALE preScale;
preScale = DRV_TMR_PrescalerGet ( tmrHandle );
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
TMR_PRESCALE DRV_TMR_PrescalerGet ( DRV_HANDLE handle )
DRV_TMR_OperationModeGet Function
This function gets the currently selected operation mode.
Implementation: Dynamic
File
drv_tmr.h
Volume V: MPLAB Harmony Framework Driver Libraries Help Timer Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 999
C
DRV_TMR_OPERATION_MODE DRV_TMR_OperationModeGet(DRV_HANDLE handle);
Returns
A DRV_TMR_OPERATION_MODE value showing how the timer is currently configured. DRV_TMR_OPERATION_MODE_NONE is returned for
an invalid client handle.
Description
This function gets the currently selected 16/32 bit operation mode.
Remarks
None.
Preconditions
The DRV_TMR_Initialize function must have been called.
DRV_TMR_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE tmrHandle; // Returned from DRV_TMR_Open
DRV_TMR_OPERATION_MODE operMode;
operMode = DRV_TMR_OperationModeGet ( tmrHandle );
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
DRV_TMR_OPERATION_MODE DRV_TMR_OperationModeGet(DRV_HANDLE handle)
DRV_TMR_DividerRangeGet Function
Returns the Timer divider values.
Implementation: Dynamic
File
drv_tmr.h
C
DRV_TMR_OPERATION_MODE DRV_TMR_DividerRangeGet(DRV_HANDLE handle, DRV_TMR_DIVIDER_RANGE* pDivRange);
Returns
• A DRV_TMR_OPERATION_MODE value showing how the timer is currently configured. The pDivRange is updated with the supported range
values.
• DRV_TMR_OPERATION_MODE_NONE for invalid client handle
Description
This function provides the Timer operating mode and divider range.
Remarks
None.
Preconditions
The DRV_TMR_Initialize function must have been called.
DRV_TMR_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE tmrHandle; // Returned from DRV_TMR_Open
DRV_TMR_OPERATION_MODE timerMode;
DRV_TMR_DIVIDER_RANGE timerRange;
Volume V: MPLAB Harmony Framework Driver Libraries Help Timer Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1000
DRV_TMR_DividerRangeGet(handle, &timerRange);
uint32_t clkFreqHz = DRV_TMR_CounterFrequencyGet ( tmrHandle );
uint32_t maxFreqHz = clkFreqHz / timerRange.dividerMin;
uint32_t minFreqHz = clkFreqHz / timerRange.dividerMax;
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
pDivRange Address to store the timer divider range.
Function
DRV_TMR_OPERATION_MODE DRV_TMR_DividerRangeGet
(
DRV_HANDLE handle,
DRV_TMR_DIVIDER_RANGE* pDivRange
)
f) Data Types and Constants
DRV_TMR_CALLBACK Type
Pointer to a Timer driver callback function data type.
File
drv_tmr.h
C
typedef void (* DRV_TMR_CALLBACK)(uintptr_t context, uint32_t alarmCount);
Description
Timer Driver Callback Function Pointer
This data type defines a pointer to a Timer driver callback function.
Remarks
Useful only when timer alarm callback support is enabled by defining the DRV_TMR_ALARM_ENABLE configuration option.
DRV_TMR_INIT Structure
Defines the Timer driver initialization data.
File
drv_tmr.h
C
typedef struct {
SYS_MODULE_INIT moduleInit;
TMR_MODULE_ID tmrId;
DRV_TMR_CLK_SOURCES clockSource;
TMR_PRESCALE prescale;
INT_SOURCE interruptSource;
DRV_TMR_OPERATION_MODE mode;
bool asyncWriteEnable;
} DRV_TMR_INIT;
Members
Members Description
SYS_MODULE_INIT moduleInit; System module initialization.
TMR_MODULE_ID tmrId; Identifies timer hardware module (PLIB-level) ID
DRV_TMR_CLK_SOURCES clockSource; Clock Source select.
Volume V: MPLAB Harmony Framework Driver Libraries Help Timer Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1001
TMR_PRESCALE prescale; Prescaler Selection from the processor enumeration
INT_SOURCE interruptSource; Interrupt Source for TMR module. If 'DRV_TMR_OPERATION_MODE_32_BIT' flag is
selected the interrupt will be generated by the 2nd timer of the pair, the odd numbered one.
DRV_TMR_OPERATION_MODE mode; Select 16/32 bit operation mode. 32 bit mode will combine two 16 bit timer modules to form a
32 bit one. This is usually only necessary for very long delays.
bool asyncWriteEnable; Asynchronous write enable configuration. If true the asynchronous write is enabled. For timers
that do not support this feature the value is ignored
Description
Timer Driver Initialize Data
This data type defines data required to initialize the Timer driver.
Remarks
Not all initialization features are available on all devices.
DRV_TMR_CLIENT_STATUS Enumeration
Identifies the client-specific status of the Timer driver
File
drv_tmr.h
C
typedef enum {
DRV_TMR_CLIENT_STATUS_INVALID,
DRV_TMR_CLIENT_STATUS_BUSY,
DRV_TMR_CLIENT_STATUS_READY,
DRV_TMR_CLIENT_STATUS_RUNNING
} DRV_TMR_CLIENT_STATUS;
Members
Members Description
DRV_TMR_CLIENT_STATUS_INVALID Driver is invalid (or unopened) state
DRV_TMR_CLIENT_STATUS_BUSY An operation is currently in progress
DRV_TMR_CLIENT_STATUS_READY Ready, no operations running
DRV_TMR_CLIENT_STATUS_RUNNING Timer started and running, processing transactions
Description
Timer Driver Client Status
This enumeration identifies the client-specific status of the Timer driver.
Remarks
None.
DRV_TMR_DIVIDER_RANGE Structure
This data structure specifies the divider values that can be obtained by the timer module.
File
drv_tmr.h
C
typedef struct {
uint32_t dividerMin;
uint32_t dividerMax;
uint32_t dividerStep;
} DRV_TMR_DIVIDER_RANGE;
Members
Members Description
uint32_t dividerMin; The minimum divider value that the timer module can obtain
uint32_t dividerMax; The maximum divider value that the timer module can obtain
Volume V: MPLAB Harmony Framework Driver Libraries Help Timer Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1002
uint32_t dividerStep; The divider step value, between 2 divider values Should be 1 for most timers
Description
Timer Driver divider operating specification
This data structure specifies the divider values that can be obtained by the timer hardware.
Remarks
None.
DRV_TMR_OPERATION_MODE Enumeration
Lists the operation modes available for timer driver.
File
drv_tmr.h
C
typedef enum {
DRV_TMR_OPERATION_MODE_NONE,
DRV_TMR_OPERATION_MODE_16_BIT,
DRV_TMR_OPERATION_MODE_32_BIT
} DRV_TMR_OPERATION_MODE;
Members
Members Description
DRV_TMR_OPERATION_MODE_NONE The timer module operating mode none/invalid
DRV_TMR_OPERATION_MODE_16_BIT The timer module operates in 16 bit mode
DRV_TMR_OPERATION_MODE_32_BIT The timer module operates in 32 bit mode This will combine two 16 bit timer modules
Description
Timer Driver Operation mode
This enumeration lists all the available operation modes that are valid for the timer hardware.
Remarks
Not all modes are available on all devices.
DRV_TMR_INDEX_COUNT Macro
Number of valid Timer driver indices.
File
drv_tmr.h
C
#define DRV_TMR_INDEX_COUNT TMR_NUMBER_OF_MODULES
Description
Timer Driver Module Index Count
This constant identifies Timer driver index definitions.
Remarks
This constant should be used in place of hard-coded numeric literals.
This value is device-specific.
DRV_TMR_INDEX_0 Macro
Timer driver index definitions
File
drv_tmr.h
Volume V: MPLAB Harmony Framework Driver Libraries Help Timer Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1003
C
#define DRV_TMR_INDEX_0 0
Description
Timer Driver Module Index Numbers
These constants provide Timer driver index definitions.
Remarks
These constants should be used in place of hard-coded numeric literals. These values should be passed into the DRV_TMR_Initialize and
DRV_TMR_Open functions to identify the driver instance in use.
DRV_TMR_INDEX_1 Macro
File
drv_tmr.h
C
#define DRV_TMR_INDEX_1 1
Description
This is macro DRV_TMR_INDEX_1.
DRV_TMR_INDEX_2 Macro
File
drv_tmr.h
C
#define DRV_TMR_INDEX_2 2
Description
This is macro DRV_TMR_INDEX_2.
DRV_TMR_INDEX_3 Macro
File
drv_tmr.h
C
#define DRV_TMR_INDEX_3 3
Description
This is macro DRV_TMR_INDEX_3.
DRV_TMR_INDEX_4 Macro
File
drv_tmr.h
C
#define DRV_TMR_INDEX_4 4
Description
This is macro DRV_TMR_INDEX_4.
Volume V: MPLAB Harmony Framework Driver Libraries Help Timer Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1004
DRV_TMR_INDEX_5 Macro
File
drv_tmr.h
C
#define DRV_TMR_INDEX_5 5
Description
This is macro DRV_TMR_INDEX_5.
DRV_TMR_INDEX_6 Macro
File
drv_tmr.h
C
#define DRV_TMR_INDEX_6 6
Description
This is macro DRV_TMR_INDEX_6.
DRV_TMR_INDEX_7 Macro
File
drv_tmr.h
C
#define DRV_TMR_INDEX_7 7
Description
This is macro DRV_TMR_INDEX_7.
DRV_TMR_INDEX_8 Macro
File
drv_tmr.h
C
#define DRV_TMR_INDEX_8 8
Description
This is macro DRV_TMR_INDEX_8.
DRV_TMR_INDEX_9 Macro
File
drv_tmr.h
C
#define DRV_TMR_INDEX_9 9
Description
This is macro DRV_TMR_INDEX_9.
Volume V: MPLAB Harmony Framework Driver Libraries Help Timer Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1005
DRV_TMR_INDEX_10 Macro
File
drv_tmr.h
C
#define DRV_TMR_INDEX_10 10
Description
This is macro DRV_TMR_INDEX_10.
DRV_TMR_INDEX_11 Macro
File
drv_tmr.h
C
#define DRV_TMR_INDEX_11 11
Description
This is macro DRV_TMR_INDEX_11.
Files
Files
Name Description
drv_tmr.h Timer device driver interface header file.
drv_tmr_config_template.h Timer driver configuration definitions for the template version.
Description
This section lists the source and header files used by the Timer Driver Library.
drv_tmr.h
Timer device driver interface header file.
Enumerations
Name Description
DRV_TMR_CLIENT_STATUS Identifies the client-specific status of the Timer driver
DRV_TMR_OPERATION_MODE Lists the operation modes available for timer driver.
Functions
Name Description
DRV_TMR_AlarmDeregister Removes a previously set alarm.
Implementation: Dynamic
DRV_TMR_AlarmDisable Disables an alarm signal.
Implementation: Dynamic
DRV_TMR_AlarmEnable Re-enables an alarm signal.
Implementation: Dynamic
DRV_TMR_AlarmHasElapsed Provides the status of Timer's period elapse.
Implementation: Dynamic
DRV_TMR_AlarmPeriodGet Provides the Timer's period.
Implementation: Dynamic
DRV_TMR_AlarmPeriodSet Updates the Timer's period.
Implementation: Dynamic
DRV_TMR_AlarmRegister Sets up an alarm.
Implementation: Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help Timer Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1006
DRV_TMR_ClientStatus Gets the status of the client operation.
Implementation: Dynamic
DRV_TMR_ClockSet Sets the timers clock by selecting the source and prescaler.
Implementation: Dynamic
DRV_TMR_Close Closes an opened instance of the Timer driver.
Implementation: Dynamic
DRV_TMR_CounterClear Clears the Timer's counter register.
Implementation: Static/Dynamic
DRV_TMR_CounterFrequencyGet Provides the Timer input frequency.
Implementation: Dynamic
DRV_TMR_CounterValueGet Reads the Timer's counter register.
Implementation: Static/Dynamic
DRV_TMR_CounterValueSet Updates the Timer's counter register.
Implementation: Static/Dynamic
DRV_TMR_Deinitialize Deinitializes the specified instance of the Timer driver.
Implementation: Dynamic
DRV_TMR_DividerRangeGet Returns the Timer divider values.
Implementation: Dynamic
DRV_TMR_GateModeClear Enables the Gate mode.
Implementation: Dynamic
DRV_TMR_GateModeSet Enables the Gate mode.
Implementation: Dynamic
DRV_TMR_Initialize Initializes the Timer driver.
Implementation: Static/Dynamic
DRV_TMR_Open Opens the specified Timer driver instance and returns a handle to it.
Implementation: Dynamic
DRV_TMR_OperationModeGet This function gets the currently selected operation mode.
Implementation: Dynamic
DRV_TMR_PrescalerGet This function gets the currently selected prescaler.
Implementation: Dynamic
DRV_TMR_Start Starts the Timer counting.
Implementation: Static/Dynamic
DRV_TMR_Status Provides the current status of the Timer driver.
Implementation: Dynamic
DRV_TMR_Stop Stops the Timer from counting.
Implementation: Static/Dynamic
DRV_TMR_Tasks Maintains the driver's state machine.
Implementation: Dynamic
Macros
Name Description
DRV_TMR_INDEX_0 Timer driver index definitions
DRV_TMR_INDEX_1 This is macro DRV_TMR_INDEX_1.
DRV_TMR_INDEX_10 This is macro DRV_TMR_INDEX_10.
DRV_TMR_INDEX_11 This is macro DRV_TMR_INDEX_11.
DRV_TMR_INDEX_2 This is macro DRV_TMR_INDEX_2.
DRV_TMR_INDEX_3 This is macro DRV_TMR_INDEX_3.
DRV_TMR_INDEX_4 This is macro DRV_TMR_INDEX_4.
DRV_TMR_INDEX_5 This is macro DRV_TMR_INDEX_5.
DRV_TMR_INDEX_6 This is macro DRV_TMR_INDEX_6.
DRV_TMR_INDEX_7 This is macro DRV_TMR_INDEX_7.
DRV_TMR_INDEX_8 This is macro DRV_TMR_INDEX_8.
DRV_TMR_INDEX_9 This is macro DRV_TMR_INDEX_9.
DRV_TMR_INDEX_COUNT Number of valid Timer driver indices.
Volume V: MPLAB Harmony Framework Driver Libraries Help Timer Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1007
Structures
Name Description
DRV_TMR_DIVIDER_RANGE This data structure specifies the divider values that can be obtained by the timer module.
DRV_TMR_INIT Defines the Timer driver initialization data.
Types
Name Description
DRV_TMR_CALLBACK Pointer to a Timer driver callback function data type.
Description
Timer Device Driver Interface Definition
This header file contains the function prototypes and definitions of the data types and constants that make up the interface to the Timer device
driver.
File Name
drv_tmr.h
Company
Microchip Technology Inc.
drv_tmr_config_template.h
Timer driver configuration definitions for the template version.
Macros
Name Description
DRV_TMR_ASYNC_WRITE_ENABLE Controls Asynchronous Write mode of the Timer.
DRV_TMR_CLIENTS_NUMBER Sets up the maximum number of clients that can be supported by an instance of the
dynamic driver.
DRV_TMR_CLOCK_PRESCALER Sets the default timer driver clock prescaler.
DRV_TMR_CLOCK_SOURCE Sets the default timer driver clock source.
DRV_TMR_INSTANCES_NUMBER Sets up the maximum number of hardware instances that can be supported by the
dynamic driver.
DRV_TMR_INTERRUPT_MODE Controls operation of the driver in the interrupt or polled mode.
DRV_TMR_INTERRUPT_SOURCE Sets the default timer driver clock interrupt source
DRV_TMR_MODE Sets the default timer driver clock operating mode.
DRV_TMR_MODULE_ID Sets the default timer module ID to be used by the timer driver.
DRV_TMR_MODULE_INIT Sets the default module init value for the timer driver.
Description
Timer Driver Configuration Definitions for the Template Version
These definitions set up the driver for the default mode of operation of the driver.
File Name
drv_tmr_config_template.h
Company
Microchip Technology Inc.
Touch Driver Libraries Help
This section describes the Touch Driver Libraries.
Generic Touch Driver API
This library help section outlines the generic Touch Driver API to be followed by anyone who wants to use a custom created touch driver to go with
the MPLAB Harmony framework for their applications.
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1008
Description
This generic driver would still be used with the Touch System Service as described by the API. It provides the data structures and functions
required for the touch driver to interface with the graphics library as well as the Touch System Services.
The APIs provide routines to read the touch input data from the touch screen. The driver is based on the device notifying the availability of touch
input data through external interrupt.
Currently, the API and the system services only supports non-gestural single-fingered touch input.
Library Interface
Functions
Name Description
DRV_TOUCH_Close Closes an opened instance of an TOUCH module driver.
DRV_TOUCH_Deinitialize Deinitializes the index instance of the TOUCH module.
DRV_TOUCH_Initialize Initializes hardware and data for the index instance of the TOUCH module.
DRV_TOUCH_Open Opens the specified instance of the Touch driver for use and provides an "open-instance"
handle.
DRV_TOUCH_Read Notifies the driver that there is current touch data to read
DRV_TOUCH_Reinitialize
DRV_TOUCH_Status Provides the current status of the index instance of the TOUCH module.
DRV_TOUCH_Tasks Maintains the driver's state machine and implements its task queue processing.
Implementation: Dynamic
Data Types and Constants
Name Description
DRV_TOUCH_INIT Defines the data required to initialize or reinitialize the TOUCH driver
DRV_TOUCH_PEN_STATE Identifies the current state of the pen.
DRV_TOUCH_POSITION_STATUS Identifies the current status of the current touch point.
DRV_TOUCH_SAMPLE_POINTS This is type DRV_TOUCH_SAMPLE_POINTS.
DRV_TOUCH_INDEX_0 Touch driver index definitions.
DRV_TOUCH_INDEX_1 This is macro DRV_TOUCH_INDEX_1.
DRV_TOUCH_INDEX_COUNT Number of valid TOUCH driver indices.
Description
Functions
DRV_TOUCH_Close Function
Closes an opened instance of an TOUCH module driver.
File
drv_touch.h
C
void DRV_TOUCH_Close(DRV_HANDLE handle);
Returns
None.
Description
This function closes an opened instance of an TOUCH module driver, making the specified handle invalid.
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1009
Preconditions
The DRV_TOUCH_Initialize routine must have been called for the specified TOUCH device instance and the DRV_TOUCH_Status must have
returned SYS_STATUS_READY.
DRV_TOUCH_Open must have been called to obtain a valid opened device handle.
Example
myTouchHandle = DRV_TOUCH_Open(DRV_TOUCH_ID_1, DRV_IO_INTENT_NONBLOCKING|DRV_IO_INTENT_READWRITE);
DRV_TOUCH_Close(myTouchHandle);
Parameters
Parameters Description
drvHandle A valid open-instance handle, returned from the driver's open routine
Function
void DRV_TOUCH_Close ( const DRV_HANDLE drvHandle )
DRV_TOUCH_Deinitialize Function
Deinitializes the index instance of the TOUCH module.
File
drv_touch.h
C
void DRV_TOUCH_Deinitialize(const SYS_MODULE_INDEX index);
Returns
None.
Description
This function deinitializes the index instance of the TOUCH module, disabling its operation (and any hardware for driver modules). It deinitializes
only the specified module instance. It also resets all the internal data structures and fields for the specified instance to the default settings.
Preconditions
The DRV_TOUCH_Initialize function should have been called before calling this function.
Example
SYS_STATUS touchstatus;
DRV_TOUCH_Deinitialize(DRV_TOUCH_ID_1);
touchstatus = DRV_TOUCH_Status(DRV_TOUCH_ID_1);
Parameters
Parameters Description
index Index, identifying the instance of the TOUCH module to be deinitialized
Function
void DRV_TOUCH_Deinitialize ( const SYS_MODULE_ID index )
DRV_TOUCH_Initialize Function
Initializes hardware and data for the index instance of the TOUCH module.
File
drv_touch.h
C
SYS_MODULE_OBJ DRV_TOUCH_Initialize(const SYS_MODULE_INDEX index, const SYS_MODULE_INIT * const init);
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1010
Returns
None
Description
This function initializes hardware for the index instance of the TOUCH module, using the hardware initialization given data. It also initializes any
internal driver data structures making the driver ready to be opened.
Preconditions
None.
Example
DRV_TOUCH_INIT_DATA touchInitData;
SYS_STATUS touchStatus;
// Populate the touchInitData structure
touchInitData.moduleInit.powerState = SYS_MODULE_POWER_RUN_FULL;
touchInitData.moduleInit.moduleCode = (DRV_TOUCH_INIT_DATA_MASTER | DRV_TOUCH_INIT_DATA_SLAVE);
DRV_TOUCH_Initialize(DRV_TOUCH_ID_1, (SYS_MODULE_INIT*)&touchInitData);
touchStatus = DRV_TOUCH_Status(DRV_TOUCH_ID_1);
Parameters
Parameters Description
index Index, identifying the instance of the TOUCH module to be initialized
data Pointer to the data structure containing any data necessary to initialize the hardware. This
pointer may be null if no data is required and the default initialization is to be used.
Function
void DRV_TOUCH_Initialize ( const TOUCH_MODULE_ID index,
const SYS_MODULE_INIT *const data )
DRV_TOUCH_Open Function
Opens the specified instance of the Touch driver for use and provides an "open-instance" handle.
File
drv_touch.h
C
DRV_HANDLE DRV_TOUCH_Open(const SYS_MODULE_INDEX index, const DRV_IO_INTENT intent);
Returns
If successful, the routine returns a valid open-instance handle (a value identifying both the caller and the module instance). If an error occurs, the
returned value is DRV_HANDLE_INVALID.
Description
This function opens the specified instance of the Touch module for use and provides a handle that is required to use the remaining driver routines.
This function opens a specified instance of the Touch module driver for use by any client module and provides an "open-instance" handle that
must be provided to any of the other Touch driver operations to identify the caller and the instance of the Touch driver/hardware module.
Preconditions
The DRV_TOUCH_Initialize routine must have been called for the specified TOUCH device instance and the DRV_TOUCH_Status must have
returned SYS_STATUS_READY.
Example
DRV_HANDLE touchHandle;
DRV_TOUCH_CLIENT_STATUS touchClientStatus;
touchHandle = DRV_TOUCH_Open(DRV_TOUCH_ID_1, DRV_IO_INTENT_NONBLOCKING|DRV_IO_INTENT_READWRITE);
if (DRV_HANDLE_INVALID == touchHandle)
{
// Handle open error
}
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1011
touchClientStatus = DRV_TOUCH_ClientStatus(touchHandle);
// Close the device when it is no longer needed.
DRV_TOUCH_Close(touchHandle);
Parameters
Parameters Description
index Index, identifying the instance of the TOUCH module to be opened.
intent Flags parameter identifying the intended usage and behavior of the driver. Multiple flags may
be ORed together to specify the intended usage of the device. See the DRV_IO_INTENT
definition.
Function
DRV_HANDLE DRV_TOUCH_Open ( const SYS_MODULE_INDEX index,
const DRV_IO_INTENT intent )
DRV_TOUCH_Read Function
Notifies the driver that there is current touch data to read
File
drv_touch.h
C
size_t DRV_TOUCH_Read(DRV_HANDLE drvHandle, void * buffer, size_t size);
Description
Notifies the driver that there is current touch data to read
Example
Function
size_t DRV_TOUCH_Read ( DRV_HANDLE drvHandle, void *buffer, size_t size )
DRV_TOUCH_Reinitialize Function
File
drv_touch.h
C
void DRV_TOUCH_Reinitialize(const SYS_MODULE_INDEX index, const SYS_MODULE_INIT *const data);
Returns
None.
Preconditions
The DRV_TOUCH_Initialize function should have been called before calling this function.
Example
SYS_MODULE_INIT touchInit;
SYS_STATUS touchStatus;
DRV_TOUCH_Reinitialize(DRV_TOUCH_ID_1, &touchStatus);
Parameters
Parameters Description
index Index, identifying the instance of the TOUCH module to be reinitialized
data Pointer to the data structure containing any data necessary to reinitialize the hardware. This
pointer may be null if no data is required and default configuration is to be used.
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1012
Function
void DRV_TOUCH_Reinitialize( const SYS_MODULE_ID index,
const SYS_MODULE_INIT *const data )
DRV_TOUCH_Status Function
Provides the current status of the index instance of the TOUCH module.
File
drv_touch.h
C
SYS_STATUS DRV_TOUCH_Status(const SYS_MODULE_INDEX index);
Description
This function provides the current status of the index instance of the TOUCH module.
Preconditions
The DRV_TOUCH_Initialize function should have been called before calling this function.
Function
SYS_STATUS DRV_TOUCH_Status ( const TOUCH_MODULE_ID index )
DRV_TOUCH_Tasks Function
Maintains the driver's state machine and implements its task queue processing.
Implementation: Dynamic
File
drv_touch.h
C
void DRV_TOUCH_Tasks(SYS_MODULE_OBJ object);
Returns
None.
Description
This routine is used to maintain the driver's internal state machine and implement its command queue processing. It is always called from
SYS_Tasks() function. This routine decodes the touch input data available.
Remarks
This function is normally not called directly by an application. It is called by the system's Tasks routine (SYS_Tasks)
Preconditions
The DRV_TOUCH_Initialize routine must have been called for the specified MTCH6301 driver instance.
Example
SYS_MODULE_OBJ object; // Returned from DRV_TOUCH_MTCH6301_Initialize
void SYS_Tasks( void )
{
DRV_TOUCH_Tasks ( object );
// Do other tasks
}
Parameters
Parameters Description
object Object handle for the specified driver instance (returned from DRV_TOUCH_Initialize)
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1013
Function
void DRV_TOUCH_Tasks ( SYS_MODULE_OBJ object );
Data Types and Constants
DRV_TOUCH_INIT Structure
Defines the data required to initialize or reinitialize the TOUCH driver
File
drv_touch.h
C
typedef struct {
SYS_MODULE_INIT moduleInit;
int touchId;
SYS_MODULE_OBJ (* drvInitialize)(const SYS_MODULE_INDEX index, const SYS_MODULE_INIT * const init);
DRV_HANDLE (* drvOpen)(const SYS_MODULE_INDEX index, const DRV_IO_INTENT intent);
void (* drvCalibrationSet)(DRV_TOUCH_SAMPLE_POINTS * samplePoints);
short (* drvTouchGetX)(uint8_t touchNumber);
short (* drvTouchGetY)(uint8_t touchNumber);
DRV_TOUCH_POSITION_STATUS (* drvTouchStatus)(const SYS_MODULE_INDEX index);
void (* drvTouchDataRead)(const SYS_MODULE_INDEX index);
DRV_TOUCH_PEN_STATE (* drvTouchPenGet)(uint8_t touchNumber);
INT_SOURCE interruptSource;
uint16_t orientation;
uint16_t horizontalResolution;
uint16_t verticalResolution;
uint16_t (* pReadFunc)(uint32_t);
void (* pWriteFunc)(uint16_t, uint32_t);
void (* pSectorErase)(uint32_t);
int32_t minTouchDetectDelta;
} DRV_TOUCH_INIT;
Members
Members Description
SYS_MODULE_INIT moduleInit; System module initialization
int touchId; ID
uint16_t orientation; Orientation of the display (given in degrees of 0,90,180,270)
uint16_t horizontalResolution; Horizontal Resolution of the displayed orientation in Pixels
uint16_t (* pReadFunc)(uint32_t); typedef for read function pointer
void (* pWriteFunc)(uint16_t, uint32_t); typedef for write function pointer
Description
TOUCH Driver Initialization Data
This data type defines the data required to initialize or reinitialize the TOUCH driver. If the driver is built statically, the members of this data
structure are statically over-ridden by static override definitions in the system_config.h file.
Remarks
None.
DRV_TOUCH_PEN_STATE Type
Identifies the current state of the pen.
File
drv_touch.h
C
typedef enum DRV_TOUCH_PEN_STATE@2 DRV_TOUCH_PEN_STATE;
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1014
Description
TOUCH Controller Driver Pen State
Identifies the current state of the pen reported from a touch event.
Remarks
This enumeration is the return type for the TouchGetPen routine.
DRV_TOUCH_POSITION_STATUS Type
Identifies the current status of the current touch point.
File
drv_touch.h
C
typedef enum DRV_TOUCH_POSITION_STATUS@2 DRV_TOUCH_POSITION_STATUS;
Description
TOUCH Controller Driver Touch status
Identifies the current status of the current touch point.
Remarks
This enumeration is the return type for the status routine for the current touch point
DRV_TOUCH_SAMPLE_POINTS Type
File
drv_touch.h
C
typedef struct DRV_TOUCH_SAMPLE_POINTS@2 DRV_TOUCH_SAMPLE_POINTS;
Description
This is type DRV_TOUCH_SAMPLE_POINTS.
DRV_TOUCH_INDEX_0 Macro
Touch driver index definitions.
File
drv_touch.h
C
#define DRV_TOUCH_INDEX_0 0
Description
Touch Driver Module Index Numbers
These constants provide the Touch driver index definitions.
Remarks
These constants should be used in place of hard-coded numeric literals.
These values should be passed into the DRV_TOUCH_Initialize and DRV_TOUCH_Open functions to identify the driver instance in use.
DRV_TOUCH_INDEX_1 Macro
File
drv_touch.h
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1015
C
#define DRV_TOUCH_INDEX_1 1
Description
This is macro DRV_TOUCH_INDEX_1.
DRV_TOUCH_INDEX_COUNT Macro
Number of valid TOUCH driver indices.
File
drv_touch.h
C
#define DRV_TOUCH_INDEX_COUNT 1
Description
TOUCH Driver Module Index Count
This constant identifies the number of valid TOUCH driver indices.
Remarks
This constant should be used in place of hard-coded numeric literals.
This value is derived from device-specific header files defined as part of the peripheral libraries.
Files
Files
Name Description
drv_touch.h Touch device driver interface file.
Description
drv_touch.h
Touch device driver interface file.
Functions
Name Description
DRV_TOUCH_Close Closes an opened instance of an TOUCH module driver.
DRV_TOUCH_Deinitialize Deinitializes the index instance of the TOUCH module.
DRV_TOUCH_Initialize Initializes hardware and data for the index instance of the TOUCH module.
DRV_TOUCH_Open Opens the specified instance of the Touch driver for use and provides an "open-instance"
handle.
DRV_TOUCH_Read Notifies the driver that there is current touch data to read
DRV_TOUCH_Reinitialize
DRV_TOUCH_Status Provides the current status of the index instance of the TOUCH module.
DRV_TOUCH_Tasks Maintains the driver's state machine and implements its task queue processing.
Implementation: Dynamic
Macros
Name Description
DRV_TOUCH_INDEX_0 Touch driver index definitions.
DRV_TOUCH_INDEX_1 This is macro DRV_TOUCH_INDEX_1.
DRV_TOUCH_INDEX_COUNT Number of valid TOUCH driver indices.
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1016
Structures
Name Description
DRV_TOUCH_INIT Defines the data required to initialize or reinitialize the TOUCH driver
Types
Name Description
DRV_TOUCH_PEN_STATE Identifies the current state of the pen.
DRV_TOUCH_POSITION_STATUS Identifies the current status of the current touch point.
DRV_TOUCH_SAMPLE_POINTS This is type DRV_TOUCH_SAMPLE_POINTS.
Description
Touch Driver Interface
The Touch driver provides a abstraction to all touch drivers.
File Name
drv_touch.h
Company
Microchip Technology Inc.
10-bit ADC Touch Driver Library
This topic describes the 10-bit ADC Touch Driver Library.
Introduction
This library provides an interface to manage the 10-bit ADC Touch Driver module on the Microchip family of microcontrollers in different modes of
operation.
Description
The MPLAB Harmony 10-bit ADC Touch Driver provides a high-level interface to the 10-bit ADC touch device. This driver provides application
routines to read non-gestural single-point touch input data from the touch screen. The 10-bit ADC touch device can notify the availability of touch
input data through external interrupt. The 10-bit ADC Touch Driver allows the application to map a controller pin as an external interrupt pin.
Using the Library
This topic describes the basic architecture of the 10-bit ADC Touch Driver Library and provides information and examples on its use.
Description
Interface Header File: drv_adc10bit.h
The interface to the 10-bit ADC Touch Driver library is defined in the drv_adc10bit.h header file. Any C language source (.c) file that uses the
ADC 10-bit Touch Driver library should include this header.
Please refer to the What is MPLAB Harmony? section for how the driver interacts with the framework.
Library Overview
Refer to the Driver Library Overview section for information on how the driver operates in a system.
The library interface routines are divided into various sub-sections, which address one of the blocks or the overall operation of the 10-bit ADC
Touch Driver module.
Library Interface Section Description
System Functions Provides system module interfaces, device initialization, deinitialization, open, close,
task, and status functions.
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1017
Configuring the Library
Macros
Name Description
DRV_ADC10BIT_CALIBRATION_DELAY Defines the calibration delay.
DRV_ADC10BIT_CALIBRATION_INSET Defines the calibration inset.
DRV_ADC10BIT_CLIENTS_NUMBER Selects the maximum number of clients.
DRV_ADC10BIT_INDEX ADC10BIT static index selection.
DRV_ADC10BIT_INSTANCES_NUMBER Sets up the maximum number of hardware instances that can be supported.
DRV_ADC10BIT_INTERRUPT_MODE Controls operation of the driver in the interrupt or polled mode.
DRV_ADC10BIT_SAMPLE_POINTS Defines the sample points.
DRV_ADC10BIT_TOUCH_DIAMETER Defines the touch diameter.
Description
The configuration of the 10-bit ADC Touch Driver is based on the file system_config.h.
This header file contains the configuration selection for the ADC 10-bit Touch Driver. Based on the selections made, the driver may support the
selected features. These configuration settings will apply to all instances of the 10-bit ADC Touch Driver.
This header can be placed anywhere, the path of this header needs to be present in the include search path for a successful build. Refer to the
Applications Help section for more details.
DRV_ADC10BIT_CALIBRATION_DELAY Macro
Defines the calibration delay.
File
drv_adc10bit_config_template.h
C
#define DRV_ADC10BIT_CALIBRATION_DELAY 300
Description
ADC10BIT Calibration Delay
This macro enables the delay between calibration touch points.
Remarks
None.
DRV_ADC10BIT_CALIBRATION_INSET Macro
Defines the calibration inset.
File
drv_adc10bit_config_template.h
C
#define DRV_ADC10BIT_CALIBRATION_INSET 25
Description
ADC10BIT Calibration Inset
This macro defines the calibration inset.
Remarks
None.
DRV_ADC10BIT_CLIENTS_NUMBER Macro
Selects the maximum number of clients.
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1018
File
drv_adc10bit_config_template.h
C
#define DRV_ADC10BIT_CLIENTS_NUMBER 1
Description
ADC10BIT client number
This macro selects the maximum number of clients.
This definition selected the maximum number of clients that the ADC10BIT driver can support at run-time.
Remarks
None.
DRV_ADC10BIT_INDEX Macro
ADC10BIT static index selection.
File
drv_adc10bit_config_template.h
C
#define DRV_ADC10BIT_INDEX DRV_ADC10BIT_INDEX_0
Description
ADC10BIT Static Index Selection
This macro specifies the static index selection for the driver object reference.
Remarks
This index is required to make a reference to the driver object.
DRV_ADC10BIT_INSTANCES_NUMBER Macro
Sets up the maximum number of hardware instances that can be supported.
File
drv_adc10bit_config_template.h
C
#define DRV_ADC10BIT_INSTANCES_NUMBER 1
Description
ADC10BIT hardware instance configuration
This macro sets up the maximum number of hardware instances that can be supported.
Remarks
None.
DRV_ADC10BIT_INTERRUPT_MODE Macro
Controls operation of the driver in the interrupt or polled mode.
File
drv_adc10bit_config_template.h
C
#define DRV_ADC10BIT_INTERRUPT_MODE false
Description
ADC10BIT Interrupt And Polled Mode Operation Control
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1019
This macro controls the operation of the driver in the interrupt mode of operation. The possible values of this macro are:
• true - Select if interrupt mode of ADC10BIT operation is desired
• false - Select if polling mode of ADC10BIT operation is desired
Not defining this option to true or false will result in a build error.
Remarks
None.
DRV_ADC10BIT_SAMPLE_POINTS Macro
Defines the sample points.
File
drv_adc10bit_config_template.h
C
#define DRV_ADC10BIT_SAMPLE_POINTS 4
Description
ADC10BIT Sample Points
This macro defines the sample points.
Remarks
None.
DRV_ADC10BIT_TOUCH_DIAMETER Macro
Defines the touch diameter.
File
drv_adc10bit_config_template.h
C
#define DRV_ADC10BIT_TOUCH_DIAMETER 10
Description
ADC10BIT Touch Diameter
This macro defines the touch diameter.
Remarks
None.
Building the Library
This section lists the files that are available in the 10-bit ADC Touch Driver Library.
Description
This section list the files that are available in the \src folder of the 10-bit ADC Touch Driver. It lists which files need to be included in the build
based on either a hardware feature present on the board or configuration option selected by the system.
The following three tables list and describe the header (.h) and source (.c) files that implement this library. The parent folder for these files is
/framework/driver/touch/adc10bit.
Interface File(s)
This table lists and describes the header files that must be included (i.e., using #include) by any code that uses this library.
Source File Name Description
/drv_adc10bit.h Header file that exports the driver API.
Required File(s)
All of the required files listed in the following table are automatically added into the MPLAB X IDE project by the MHC
when the library is selected for use.
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1020
This table lists and describes the source and header files that must always be included in the MPLAB X IDE project to build this library.
Source File Name Description
/src/drv_adc10bit.c Basic 10-bit ADC Touch Driver implementation file.
Optional File(s)
This table lists and describes the source and header files that may optionally be included if required for the desired implementation.
Source File Name Description
N/A No optional files are available for this library.
Module Dependencies
The 10-bit ADC Touch Driver Library depends on the following modules:
• Interrupt System Service Library
• Ports System Service Library
• Touch System Service Library
• I2C Driver Library
Library Interface
a) System Functions
Name Description
DRV_TOUCH_ADC10BIT_CalibrationSet Loads calibration parameters from Non-volatile Memory.
DRV_TOUCH_ADC10BIT_Close Closes an opened instance of the 10-bit ADC Driver.
DRV_TOUCH_ADC10BIT_Deinitialize Deinitializes the specified instance of the ADC10BIT driver module.
DRV_TOUCH_ADC10BIT_Initialize Initializes the 10-bit ADC Driver instance for the specified driver index
DRV_TOUCH_ADC10BIT_Open Opens the specified ADC10BIT driver instance and returns a handle to it.
DRV_TOUCH_ADC10BIT_Status Provides the current status of the ADC10BIT driver module.
DRV_TOUCH_ADC10BIT_Tasks Maintains the driver's state machine and implements its ISR.
DRV_TOUCH_ADC10BIT_TouchGetRawX Returns raw x coordinate status when the touch screen is pressed.
DRV_TOUCH_ADC10BIT_TouchGetRawY Returns raw y coordinate status when the touch screen is pressed.
DRV_TOUCH_ADC10BIT_TouchGetX Returns x coordinate status when the touch screen is pressed.
DRV_TOUCH_ADC10BIT_TouchStoreCalibration Stores calibration parameters into Non-volatile Memory.
DRV_TOUCH_ADC10BIT_PositionDetect None.
DRV_TOUCH_ADC10BIT_TouchGetY Returns y coordinate status when the touch screen is pressed.
DRV_TOUCH_ADC10BIT_TouchDataRead Notifies the driver that the current touch data has been read
DRV_TOUCH_ADC10BIT_TouchStatus Returns the status of the current touch input.
b) Data Types and Constants
Name Description
_DRV_TOUCH_ADC10BIT_CLIENT_DATA Defines the data that can be changed per client.
_DRV_TOUCH_ADC10BIT_INIT Defines the data required to initialize or reinitialize the 10-bit ADC Driver.
DRV_ADC10BIT_MODULE_ID This is type DRV_ADC10BIT_MODULE_ID.
DRV_TOUCH_ADC10BIT_CLIENT_DATA Defines the data that can be changed per client.
DRV_TOUCH_ADC10BIT_HANDLE Driver handle.
DRV_TOUCH_ADC10BIT_INIT Defines the data required to initialize or reinitialize the 10-bit ADC Driver.
DRV_TOUCH_ADC10BIT_HANDLE_INVALID Definition of an invalid handle.
DRV_TOUCH_ADC10BIT_INDEX_0 ADC10BIT driver index definitions.
DRV_TOUCH_ADC10BIT_INDEX_1 This is macro DRV_TOUCH_ADC10BIT_INDEX_1.
DRV_TOUCH_ADC10BIT_INDEX_COUNT Number of valid ADC10BIT driver indices.
Description
This section describes the API functions of the 10-bit ADC Touch Driver library.
Refer to each section for a detailed description.
a) System Functions
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1021
DRV_TOUCH_ADC10BIT_CalibrationSet Function
Loads calibration parameters from Non-volatile Memory.
File
drv_adc10bit.h
C
void DRV_TOUCH_ADC10BIT_CalibrationSet(DRV_TOUCH_SAMPLE_POINTS * samplePoints);
Returns
None.
Description
This function loads calibration parameters from Non-volatile Memory.
Preconditions
The NVM initialization function must be called before calling this function.
Function
void DRV_TOUCH_ADC10BIT_TouchLoadCalibration(void)
DRV_TOUCH_ADC10BIT_Close Function
Closes an opened instance of the 10-bit ADC Driver.
File
drv_adc10bit.h
C
void DRV_TOUCH_ADC10BIT_Close(DRV_HANDLE handle);
Returns
None
Description
This function closes an opened instance of the 10-bit ADC Driver, invalidating the handle.
Remarks
After calling this routine, the handle passed in "handle" must not be used with any of the remaining driver routines. A new handle must be obtained
by calling DRV_TOUCH_ADC10BIT_Open before the caller may use the driver again. This function is thread safe in a RTOS application.
Usually there is no need for the driver client to verify that the Close operation has completed.
Preconditions
DRV_TOUCH_ADC10BIT_Initialize must have been called for the specified ADC10BIT driver instance.
DRV_TOUCH_ADC10BIT_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE handle; // Returned from DRV_TOUCH_ADC10BIT_Open
DRV_TOUCH_ADC10BIT_Close ( handle );
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
void DRV_TOUCH_ADC10BIT_Close ( DRV_HANDLE handle )
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1022
DRV_TOUCH_ADC10BIT_Deinitialize Function
Deinitializes the specified instance of the ADC10BIT driver module.
File
drv_adc10bit.h
C
void DRV_TOUCH_ADC10BIT_Deinitialize(SYS_MODULE_OBJ object);
Returns
None.
Description
This function deinitializes the specified instance of the 10-bit ADC Driver module, disabling its operation (and any hardware) and invalidates all of
the internal data.
Remarks
Once the Initialize operation has been called, the Deinitialize operation must be called before the Initialize operation can be called again.
This function will NEVER block waiting for hardware. If the operation requires time to allow the hardware to complete, this will be reported by the
DRV_TOUCH_ADC10BIT_Status operation. The system has to use DRV_TOUCH_ADC10BIT_Status to determine when the module is in the
ready state.
Preconditions
DRV_TOUCH_ADC10BIT_Initialize must have been called before calling this routine and a valid SYS_MODULE_OBJ must have been returned.
Example
SYS_MODULE_OBJ object; // Returned from DRV_TOUCH_ADC10BIT_Initialize
SYS_STATUS status;
DRV_TOUCH_ADC10BIT_Deinitialize ( object );
status = DRV_TOUCH_ADC10BIT_Status( object );
if( SYS_MODULE_UNINITIALIZED == status )
{
// Check again later if you need to know
// when the driver is deinitialized.
}
Parameters
Parameters Description
object Driver object handle, returned from DRV_TOUCH_ADC10BIT_Initialize
Function
void DRV_TOUCH_ADC10BIT_Deinitialize ( SYS_MODULE_OBJ object )
DRV_TOUCH_ADC10BIT_Initialize Function
Initializes the 10-bit ADC Driver instance for the specified driver index
File
drv_adc10bit.h
C
SYS_MODULE_OBJ DRV_TOUCH_ADC10BIT_Initialize(const SYS_MODULE_INDEX index, const SYS_MODULE_INIT * const
init);
Returns
If successful, returns a valid handle to a driver instance object. Otherwise, returns SYS_MODULE_OBJ_INVALID.
Description
This function initializes the 10-bit ADC Driver instance for the specified driver index, making it ready for clients to open and use it. The initialization
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1023
data is specified by the 'init' parameter. The initialization may fail if the number of driver objects allocated are insufficient or if the specified driver
instance is already initialized. The driver instance index is independent of the 10-bit ADC Driver module ID. For example, driver instance 0 can be
assigned to ADC10BIT2. If the driver is built statically, then some of the initialization parameters are overridden by configuration macros. Refer to
the description of the DRV_TOUCH_ADC10BIT_INIT data structure for more details on which members on this data structure are overridden.
Remarks
This routine must be called before any other ADC10BIT routine is called.
This routine should only be called once during system initialization unless DRV_TOUCH_ADC10BIT_Deinitialize is called to deinitialize the driver
instance. This routine will NEVER block for hardware access.
Preconditions
None.
Example
DRV_TOUCH_ADC10BIT_INIT init;
SYS_MODULE_OBJ objectHandle;
// Populate the ADC10BIT initialization structure
init.spiId = ADC10BIT_ID_1;
objectHandle = DRV_TOUCH_ADC10BIT_Initialize(DRV_TOUCH_ADC10BIT_INDEX_1, (SYS_MODULE_INIT*)usartInitData);
if (SYS_MODULE_OBJ_INVALID == objectHandle)
{
// Handle error
}
Parameters
Parameters Description
index Identifier for the instance to be initialized. Please note this is not the 10-bit ADC Driver ID. The
hardware 10-bit ADC Driver ID is set in the initialization structure. This is the index of the
driver index to use.
init Pointer to a data structure containing any data necessary to initialize the driver. If this pointer
is NULL, the driver uses the static initialization override macros for each member of the
initialization data structure.
Function
SYS_MODULE_OBJ DRV_TOUCH_ADC10BIT_Initialize( const SYS_MODULE_INDEX index,
const SYS_MODULE_INIT * const init )
DRV_TOUCH_ADC10BIT_Open Function
Opens the specified ADC10BIT driver instance and returns a handle to it.
File
drv_adc10bit.h
C
DRV_HANDLE DRV_TOUCH_ADC10BIT_Open(const SYS_MODULE_INDEX drvIndex, const DRV_IO_INTENT intent);
Returns
If successful, the routine returns a valid open-instance handle (a number identifying both the caller and the module instance).
If an error occurs, the return value is DRV_HANDLE_INVALID. An error can occur when the following is true:
• if the number of client objects allocated via DRV_TOUCH_ADC10BIT_CLIENTS_NUMBER is insufficient
• if the client is trying to open the driver but driver has been opened exclusively by another client
• if the driver hardware instance being opened is not initialized or is invalid
Description
This function opens the specified USART driver instance and provides a handle that must be provided to all other client-level operations to identify
the caller and the instance of the driver. The ioIntent parameter defines how the client interacts with this driver instance.
The DRV_IO_INTENT_BLOCKING and DRV_IO_INTENT_NONBLOCKING ioIntent options additionally affect the behavior of the
DRV_USART_Read() and DRV_USART_Write() functions. If the ioIntent is DRV_IO_INTENT_NONBLOCKING, then these function will not block
even if the required amount of data could not be processed. If the ioIntent is DRV_IO_INTENT_BLOCKING, these functions will block until the
required amount of data is processed.
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1024
If ioIntent is DRV_IO_INTENT_READ, the client will only be read from the driver. If ioIntent is DRV_IO_INTENT_WRITE, the client will only be able
to write to the driver. If the ioIntent in DRV_IO_INTENT_READWRITE, the client will be able to do both, read and write.
Specifying a DRV_IO_INTENT_EXCLUSIVE will cause the driver to provide exclusive access to this client. The driver cannot be opened by any
other client.
Remarks
The handle returned is valid until the DRV_TOUCH_ADC10BIT_Close routine is called. This routine will NEVER block waiting for hardware. If the
requested intent flags are not supported, the routine will return DRV_HANDLE_INVALID. This function is thread safe in a RTOS application. It
should not be called in an ISR.
Preconditions
DRV_TOUCH_ADC10BIT_Initialize must have been called before calling this function.
Example
DRV_HANDLE handle;
handle = DRV_TOUCH_ADC10BIT_Open( DRV_TOUCH_ADC10BIT_INDEX_0, DRV_IO_INTENT_EXCLUSIVE );
if( DRV_HANDLE_INVALID == handle )
{
// Unable to open the driver
}
Parameters
Parameters Description
drvIndex Index of the driver initialized with DRV_TOUCH_ADC10BIT_Initialize. Please note this is not
the SPI id.
intent Zero or more of the values from the enumeration DRV_IO_INTENT ORed together to indicate
the intended use of the driver
Function
DRV_HANDLE DRV_TOUCH_ADC10BIT_Open ( const SYS_MODULE_INDEX drvIndex,
const DRV_IO_INTENT intent )
DRV_TOUCH_ADC10BIT_Status Function
Provides the current status of the ADC10BIT driver module.
File
drv_adc10bit.h
C
SYS_STATUS DRV_TOUCH_ADC10BIT_Status(SYS_MODULE_OBJ object);
Returns
SYS_STATUS_READY - Indicates that the driver is busy with a previous system level operation and cannot start another
Description
This function provides the current status of the ADC10BIT driver module.
Remarks
Any value greater than SYS_STATUS_READY is also a normal running state in which the driver is ready to accept new operations.
SYS_MODULE_UNINITIALIZED - Indicates that the driver has been deinitialized
This value is less than SYS_STATUS_ERROR.
This function can be used to determine when any of the driver's module level operations has completed.
If the status operation returns SYS_STATUS_BUSY, the previous operation has not yet completed. Once the status operation returns
SYS_STATUS_READY, any previous operations have completed.
The value of SYS_STATUS_ERROR is negative (-1). Any value less than that is also an error state.
This function will NEVER block waiting for hardware.
If the Status operation returns an error value, the error may be cleared by calling the reinitialize operation. If that fails, the deinitialize operation will
need to be called, followed by the initialize operation to return to normal operations.
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1025
Preconditions
DRV_TOUCH_ADC10BIT_Initialize must have been called before calling this function.
Example
SYS_MODULE_OBJ object; // Returned from DRV_TOUCH_ADC10BIT_Initialize
SYS_STATUS status;
status = DRV_TOUCH_ADC10BIT_Status( object );
if( SYS_STATUS_READY != status )
{
// Handle error
}
Parameters
Parameters Description
object Driver object handle, returned from DRV_TOUCH_ADC10BIT_Initialize
Function
SYS_STATUS DRV_TOUCH_ADC10BIT_Status ( SYS_MODULE_OBJ object )
DRV_TOUCH_ADC10BIT_Tasks Function
Maintains the driver's state machine and implements its ISR.
File
drv_adc10bit.h
C
void DRV_TOUCH_ADC10BIT_Tasks(SYS_MODULE_OBJ object);
Returns
None.
Description
This routine is used to maintain the driver's internal state machine and implement its transmit ISR for interrupt-driven implementations. In polling
mode, this function should be called from the SYS_Tasks function. In Interrupt mode, this function should be called in the transmit interrupt service
routine of the USART that is associated with this USART driver hardware instance.
Remarks
This function is normally not called directly by an application. It is called by the system's Tasks routine (SYS_Tasks) or by the appropriate raw ISR.
This function may execute in an ISR context and will never block or access any resources that may cause it to block.
Preconditions
DRV_TOUCH_ADC10BIT_Initialize must have been called for the specified 10-bit ADC Driver instance.
Example
SYS_MODULE_OBJ object; // Returned from DRV_TOUCH_ADC10BIT_Initialize
while( true )
{
DRV_TOUCH_ADC10BIT_Tasks ( object );
// Do other tasks
}
Parameters
Parameters Description
object Object handle for the specified driver instance (returned from
DRV_TOUCH_ADC10BIT_Initialize)
Function
void DRV_TOUCH_ADC10BIT_Tasks ( SYS_MODULE_OBJ object );
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1026
DRV_TOUCH_ADC10BIT_TouchGetRawX Function
Returns raw x coordinate status when the touch screen is pressed.
File
drv_adc10bit.h
C
short DRV_TOUCH_ADC10BIT_TouchGetRawX();
Returns
• raw x coordinate - Indicates the touch screen was pressed
• -1 - Indicates the touch screen was not pressed
Description
This function returns the raw x coordinate status when the touch screen is pressed.
Remarks
None.
Preconditions
None.
Function
short DRV_TOUCH_ADC10BIT_TouchGetRawX()
DRV_TOUCH_ADC10BIT_TouchGetRawY Function
Returns raw y coordinate status when the touch screen is pressed.
File
drv_adc10bit.h
C
short DRV_TOUCH_ADC10BIT_TouchGetRawY();
Returns
• raw y coordinate - Indicates the touch screen was pressed
• -1 - Indicates the touch screen was not pressed
Description
This function returns the raw y coordinate status when the touch screen is pressed.
Remarks
None.
Preconditions
None.
Function
short DRV_TOUCH_ADC10BIT_TouchGetRawY()
DRV_TOUCH_ADC10BIT_TouchGetX Function
Returns x coordinate status when the touch screen is pressed.
File
drv_adc10bit.h
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1027
C
short DRV_TOUCH_ADC10BIT_TouchGetX(uint8_t touchNumber);
Returns
• x coordinate - Indicates the touch screen was pressed
• -1 - Indicates the touch screen was not pressed
Description
This function returns the x coordinate status when the touch screen is pressed.
Remarks
None.
Preconditions
None.
Parameters
Parameters Description
touchNumber touch input index.
Function
short DRV_TOUCH_ADC10BIT_TouchGetX( uint8_t touchNumber )
DRV_TOUCH_ADC10BIT_TouchStoreCalibration Function
Stores calibration parameters into Non-volatile Memory.
File
drv_adc10bit.h
C
void DRV_TOUCH_ADC10BIT_TouchStoreCalibration();
Returns
None.
Description
This function stores calibration parameters into Non-volatile Memory.
Remarks
This API is deprecated and its funcationality is handled via SYSTEM_INITIALIZATION
Preconditions
The NVM initialization function must be called before calling this function.
Function
void DRV_TOUCH_ADC10BIT_TouchStoreCalibration(void)
DRV_TOUCH_ADC10BIT_PositionDetect Function
None.
File
drv_adc10bit.h
C
short DRV_TOUCH_ADC10BIT_PositionDetect();
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1028
Returns
None.
Description
None.
Preconditions
None.
Function
void DRV_TOUCH_ADC10BIT_TouchLoadCalibration(void)
DRV_TOUCH_ADC10BIT_TouchGetY Function
Returns y coordinate status when the touch screen is pressed.
File
drv_adc10bit.h
C
short DRV_TOUCH_ADC10BIT_TouchGetY(uint8_t touchNumber);
Returns
• y coordinate - Indicates the touch screen was pressed
• -1 - Indicates the touch screen was not pressed
Description
This function returns the y coordinate status when the touch screen is pressed.
Remarks
None.
Preconditions
None.
Parameters
Parameters Description
handle driver client handle.
touchNumber touch input index.
Function
short DRV_TOUCH_ADC10BIT_TouchGetY( DRV_HANDLE handle, uint8_t touchNumber )
DRV_TOUCH_ADC10BIT_TouchDataRead Function
Notifies the driver that the current touch data has been read
File
drv_adc10bit.h
C
void DRV_TOUCH_ADC10BIT_TouchDataRead(const SYS_MODULE_INDEX index);
Returns
None.
Description
Notifies the driver that the current touch data has been read
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1029
Function
void DRV_TOUCH_ADC10BIT_TouchDataRead( const SYS_MODULE_INDEX index )
DRV_TOUCH_ADC10BIT_TouchStatus Function
Returns the status of the current touch input.
File
drv_adc10bit.h
C
DRV_TOUCH_POSITION_STATUS DRV_TOUCH_ADC10BIT_TouchStatus(const SYS_MODULE_INDEX index);
Returns
It returns the status of the current touch input.
Description
It returns the status of the current touch input.
Function
DRV_TOUCH_POSITION_SINGLE DRV_TOUCH_ADC10BIT_TouchStatus( const SYS_MODULE_INDEX index )
b) Data Types and Constants
DRV_ADC10BIT_MODULE_ID Enumeration
File
drv_adc10bit.h
C
typedef enum {
ADC10BIT_ID_1 = 0,
ADC10BIT_NUMBER_OF_MODULES
} DRV_ADC10BIT_MODULE_ID;
Description
This is type DRV_ADC10BIT_MODULE_ID.
DRV_TOUCH_ADC10BIT_CLIENT_DATA Structure
Defines the data that can be changed per client.
File
drv_adc10bit.h
C
typedef struct _DRV_TOUCH_ADC10BIT_CLIENT_DATA {
} DRV_TOUCH_ADC10BIT_CLIENT_DATA;
Description
Macro: ADC10BIT Driver Client Specific Configuration
This data type defines the data can be configured per client. This data can be per client, and overrides the configuration data contained inside of
DRV_TOUCH_ADC10BIT_INIT.
Remarks
None.
DRV_TOUCH_ADC10BIT_HANDLE Type
Driver handle.
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1030
File
drv_adc10bit.h
C
typedef uintptr_t DRV_TOUCH_ADC10BIT_HANDLE;
Description
Macro: ADC10BIT Driver Handle
Touch screen controller interfacing with the 10-bit Analog-to-Digital (ADC) converter device.
Remarks
None
DRV_TOUCH_ADC10BIT_INIT Structure
Defines the data required to initialize or reinitialize the 10-bit ADC Driver.
File
drv_adc10bit.h
C
typedef struct _DRV_TOUCH_ADC10BIT_INIT {
SYS_MODULE_INIT moduleInit;
DRV_ADC10BIT_MODULE_ID adc10bitId;
} DRV_TOUCH_ADC10BIT_INIT;
Members
Members Description
SYS_MODULE_INIT moduleInit; System module initialization
DRV_ADC10BIT_MODULE_ID adc10bitId; Identifies peripheral (PLIB-level) ID
Description
Macro: ADC10BIT Driver Initialization Data
This data type defines the data required to initialize or reinitialize the 10-bit ADC Driver. If the driver is built statically, the members of this data
structure are statically over-ridden by static override definitions in the system_config.h file.
Remarks
None.
DRV_TOUCH_ADC10BIT_HANDLE_INVALID Macro
Definition of an invalid handle.
File
drv_adc10bit.h
C
#define DRV_TOUCH_ADC10BIT_HANDLE_INVALID ((DRV_TOUCH_ADC10BIT_HANDLE)(-1))
Description
Macro: ADC10BIT Driver Invalid Handle
This is the definition of an invalid handle. An invalid handle is returned by DRV_ADC10BIT_RawRead and DRV_ADC10BIT_RawRead functions if
the request was not successful.
Remarks
None.
DRV_TOUCH_ADC10BIT_INDEX_0 Macro
ADC10BIT driver index definitions.
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1031
File
drv_adc10bit.h
C
#define DRV_TOUCH_ADC10BIT_INDEX_0 0
Description
Macro: ADC10BIT Driver Module Index Numbers
These constants provide the 10-bit ADC Driver index definitions.
Remarks
These constants should be used in place of hard-coded numeric literals.
These values should be passed into the DRV_ADC10BIT_Initialize and DRV_ADC10BIT_Open functions to identify the driver instance in use.
DRV_TOUCH_ADC10BIT_INDEX_1 Macro
File
drv_adc10bit.h
C
#define DRV_TOUCH_ADC10BIT_INDEX_1 1
Description
This is macro DRV_TOUCH_ADC10BIT_INDEX_1.
DRV_TOUCH_ADC10BIT_INDEX_COUNT Macro
Number of valid ADC10BIT driver indices.
File
drv_adc10bit.h
C
#define DRV_TOUCH_ADC10BIT_INDEX_COUNT 2
Description
Macro: ADC10BIT Driver Module Index Count
This constant identifies the number of valid 10-bit ADC Driver indices.
Remarks
This constant should be used in place of hard-coded numeric literals.
This value is derived from device-specific header files defined as part of the peripheral libraries.
Files
Files
Name Description
drv_adc10bit.h 10-bit ADC Touch Driver interface definitions
drv_adc10bit_config_template.h 10-bit ADC Touch Driver configuration template.
Description
This section lists the source and header files used by the 10-bit ADC Touch Driver Library.
drv_adc10bit.h
10-bit ADC Touch Driver interface definitions
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1032
Enumerations
Name Description
DRV_ADC10BIT_MODULE_ID This is type DRV_ADC10BIT_MODULE_ID.
Functions
Name Description
DRV_TOUCH_ADC10BIT_CalibrationSet Loads calibration parameters from Non-volatile Memory.
DRV_TOUCH_ADC10BIT_Close Closes an opened instance of the 10-bit ADC Driver.
DRV_TOUCH_ADC10BIT_Deinitialize Deinitializes the specified instance of the ADC10BIT driver module.
DRV_TOUCH_ADC10BIT_Initialize Initializes the 10-bit ADC Driver instance for the specified driver index
DRV_TOUCH_ADC10BIT_Open Opens the specified ADC10BIT driver instance and returns a handle to it.
DRV_TOUCH_ADC10BIT_PositionDetect None.
DRV_TOUCH_ADC10BIT_Status Provides the current status of the ADC10BIT driver module.
DRV_TOUCH_ADC10BIT_Tasks Maintains the driver's state machine and implements its ISR.
DRV_TOUCH_ADC10BIT_TouchDataRead Notifies the driver that the current touch data has been read
DRV_TOUCH_ADC10BIT_TouchGetRawX Returns raw x coordinate status when the touch screen is pressed.
DRV_TOUCH_ADC10BIT_TouchGetRawY Returns raw y coordinate status when the touch screen is pressed.
DRV_TOUCH_ADC10BIT_TouchGetX Returns x coordinate status when the touch screen is pressed.
DRV_TOUCH_ADC10BIT_TouchGetY Returns y coordinate status when the touch screen is pressed.
DRV_TOUCH_ADC10BIT_TouchStatus Returns the status of the current touch input.
DRV_TOUCH_ADC10BIT_TouchStoreCalibration Stores calibration parameters into Non-volatile Memory.
Macros
Name Description
DRV_TOUCH_ADC10BIT_HANDLE_INVALID Definition of an invalid handle.
DRV_TOUCH_ADC10BIT_INDEX_0 ADC10BIT driver index definitions.
DRV_TOUCH_ADC10BIT_INDEX_1 This is macro DRV_TOUCH_ADC10BIT_INDEX_1.
DRV_TOUCH_ADC10BIT_INDEX_COUNT Number of valid ADC10BIT driver indices.
Structures
Name Description
_DRV_TOUCH_ADC10BIT_CLIENT_DATA Defines the data that can be changed per client.
_DRV_TOUCH_ADC10BIT_INIT Defines the data required to initialize or reinitialize the 10-bit ADC Driver.
DRV_TOUCH_ADC10BIT_CLIENT_DATA Defines the data that can be changed per client.
DRV_TOUCH_ADC10BIT_INIT Defines the data required to initialize or reinitialize the 10-bit ADC Driver.
Types
Name Description
DRV_TOUCH_ADC10BIT_HANDLE Driver handle.
Description
10-bit ADC Touch Driver Interface Definition
This is a resistive touch screen driver that is using the Microchip Graphics Library. The calibration values are automatically checked (by reading a
specific memory location on the non-volatile memory) when initializing the module if the function pointers to the read and write callback functions
are initialized. If the read value is invalid calibration will automatically be executed. Otherwise, the calibration values will be loaded and used. The
driver assumes that the application side provides the read and write routines to a non-volatile memory. If the callback functions are not initialized,
the calibration routine will always be called at start-up to initialize the global calibration values. This driver assumes that the Graphics Library is
initialized and will be using the default font of the library.
File Name
drv_adc10bit.h
Company
Microchip Technology Inc.
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1033
drv_adc10bit_config_template.h
10-bit ADC Touch Driver configuration template.
Macros
Name Description
DRV_ADC10BIT_CALIBRATION_DELAY Defines the calibration delay.
DRV_ADC10BIT_CALIBRATION_INSET Defines the calibration inset.
DRV_ADC10BIT_CLIENTS_NUMBER Selects the maximum number of clients.
DRV_ADC10BIT_INDEX ADC10BIT static index selection.
DRV_ADC10BIT_INSTANCES_NUMBER Sets up the maximum number of hardware instances that can be supported.
DRV_ADC10BIT_INTERRUPT_MODE Controls operation of the driver in the interrupt or polled mode.
DRV_ADC10BIT_SAMPLE_POINTS Defines the sample points.
DRV_ADC10BIT_TOUCH_DIAMETER Defines the touch diameter.
Description
10-bit ADC Touch Driver Configuration Template
This header file contains the build-time configuration selections for the 10-bit ADC Touch Driver. This is the template file which give all possible
configurations that can be made. This file should not be included in any project.
File Name
drv_adc10bit_config_template.h
Company
Microchip Technology Inc.
ADC Touch Driver Library
This topic describes the ADC Touch Driver Library.
Introduction
This library provides an interface to manage the ADC Touch Driver module on the Microchip family of microcontrollers in different modes of
operation.
Description
The MPLAB Harmony ADC Touch Driver provides a high-level interface to the ADC touch device. This driver provides application routines to read
the touch input data from the touch screen. . The ADC touch device can notify the availability of touch input data through external interrupt. The
ADC Touch Driver allows the application to map a controller pin as an external interrupt pin.
Using the Library
This topic describes the basic architecture of the ADC Touch Driver Library and provides information and examples on its use.
Description
Interface Header File: drv_touch_adc.h
The interface to the ADC Touch Driver library is defined in the drv_touch_adc.h header file. Any C language source (.c) file that uses the ADC
Touch Driver library should include this header.
Please refer to the What is MPLAB Harmony? section for how the driver interacts with the framework.
Abstraction Model
This library provides a low-level abstraction of the ADC Touch Driver Library on the Microchip family microcontrollers with a convenient C language
interface. This topic describes how that abstraction is modeled in software and introduces the library's interface.
Description
The ADC Touch Driver has routines to perform the following operations. The driver initialization routines allow the application to initialize the driver.
The driver must be initialized before it can be used by application. Once driver is initialized the driver open routine allows retrieving the client
handle. Once the touch input is available a touch input read request is sent and input data is retrieved in a buffer. The buffer data is then decoded
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1034
to get the x and y coordinate of the touch screen in the form of the number of pixels.
ADC Touch Driver Abstraction Model
Library Overview
Refer to the Driver Library Overview section for information on how the driver operates in a system.
The library interface routines are divided into various sub-sections, which address one of the blocks or the overall operation of the ADC Touch
Driver module.
Library Interface Section Description
System Functions Provides system module interfaces, device initialization, deinitialization, open, close,
task, and status functions.
How the Library Works
The library provides interfaces to support system functions, which provide system module interfaces, device initialization, deinitialization, open,
close, task, and status functions.
During steady state operation, the DRV_TOUCH_ADC_Tasks is called continuously in System_Tasks to save the current touch position, or -1 if no
touch was detected.
At any time, DRV_TOUCH_ADC_TouchGetX and DRV_TOUCH_ADC_TouchGetY are called to retrieve the last touch position. Touch positions
are not queued.
Touch samples are configurable, the default is 300. The return integer can have the value between 0-screenWidth and 0-screenHeight.
Initializing the Driver
Before the ADC Touch Driver can be opened, it must be configured and initialized. The driver build time configuration is defined by the
configuration macros. Refer to the Building the Library section for the location of and more information on the various configuration macros and
how these macros should be designed. The driver initialization is configured through the DRV_TOUCH_INIT data structure that is passed to the
DRV_TOUCH_ADC_Initialize function. The initialization parameters include the interrupt source, interrupt pin remap configuration and touch
screen resolution. The following code shows an example of initializing the ADC Touch Touch Driver.
/* The following code shows an example of designing the
* DRV_TOUCH_INIT data structure. It also shows how an example
* usage of the DRV_TOUCH_ADC_Initialize function.
*/
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1035
DRV_TOUCH_INIT drvTouchInitData;
SYS_MODULE_OBJ objectHandle;
/* Touch Module Id*/
drvTouchInitData.touchId = DRV_TOUCH_INDEX_0;
/* I2C Bus driver open */
drvTouchInitData.drvOpen = DRV_I2C_Open;
/* Interrupt Source for Touch */
drvTouchInitData.interruptSource = INT_SOURCE_EXTERNAL_1;
/* Interrupt Pin function mapping */
drvTouchInitData.interruptPort.inputFunction = INPUT_FUNC_INT1;
/* Pin to be mapped as interrupt pin */
drvTouchInitData.interruptPort.inputPin = INPUT_PIN_RPE8;
/* Analog pin number */
drvTouchInitData.interruptPort.analogPin = PORTS_ANALOG_PIN_25;
/* Pin Mode of analog pin */
drvTouchInitData.interruptPort.pinMode = PORTS_PIN_MODE_DIGITAL;
/* Interrupt pin port */
drvTouchInitData.interruptPort.channel = PORT_CHANNEL_E;
/* Interrupt pin port maskl */
drvTouchInitData.interruptPort.dataMask = 0x8;
/* Touch screen orientation */
drvTouchInitData.orientation = DISP_ORIENTATION;
/* Touch screen horizontal resolution */
drvTouchInitData.horizontalResolution = DISP_HOR_RESOLUTION;
/* Touch screen vertical resolution */
drvTouchInitData.verticalResolution = DISP_VER_RESOLUTION;
/* Driver initialization */
objectHandle = DRV_TOUCH_ADC_Initialize(DRV_TOUCH_INDEX_0,
(SYS_MODULE_INIT*)drvTouchInitData);
if (SYS_MODULE_OBJ_INVALID == objectHandle)
{
// Handle error
}
Opening the Driver
To use the ADC Touch Driver, the application must open the driver. This is done by calling the DRV_TOUCH_ADC_Open function. If successful,
the DRV_TOUCH_ADC_Open function will return a handle to the driver. This handle records the association between the client and the driver
instance that was opened. The DRV_TOUCH_ADC_Open function may return DRV_HANDLE_INVALID in the situation where the driver is not
ready to be opened. When this occurs, the application can try opening the driver again. Note that the open function may return an invalid handle in
other (error) cases as well. The following code shows an example of the driver being opened.
DRV_HANDLE handle;
handle = DRV_TOUCH_ADC_Open( DRV_TOUCH_ADC_INDEX_0,
DRV_IO_INTENT_EXCLUSIVE );
if( DRV_HANDLE_INVALID == handle )
{
// Unable
}
Tasks Routine
To use the ADC Touch Driver, the application must open the driver. This is done by calling the DRV_TOUCH_ADC_Open function. If successful,
the DRV_TOUCH_ADC_Open function will return a handle to the driver. This handle records the association between the client and the driver
instance that was opened. The DRV_TOUCH_ADC_Open function may return DRV_HANDLE_INVALID in the situation where the driver is not
ready to be opened. When this occurs, the application can try opening the driver again. Note that the open function may return an invalid handle in
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1036
other (error) cases as well. The following code shows an example of the driver being opened.
DRV_HANDLE handle;
handle = DRV_TOUCH_ADC_Open( DRV_TOUCH_ADC_INDEX_0,
DRV_IO_INTENT_EXCLUSIVE );
if( DRV_HANDLE_INVALID == handle )
{
// Unable
}
Configuring the Library
The configuration of the ADC Touch Driver is based on the file system_config.h.
This header file contains the configuration selection for the ADC 10-bit Touch Driver. Based on the selections made, the driver may support the
selected features. These configuration settings will apply to all instances of the ADC Touch Driver.
This header can be placed anywhere, the path of this header needs to be present in the include search path for a successful build. Refer to the
Applications Help section for more details.
Building the Library
This section lists the files that are available in the ADC Touch Driver Library.
Description
This section list the files that are available in the \src folder of the ADC Touch Driver. It lists which files need to be included in the build based on
either a hardware feature present on the board or configuration option selected by the system.
The following three tables list and describe the header (.h) and source (.c) files that implement this library. The parent folder for these files is
/framework/driver/touch/touch_adc.
Interface File(s)
This table lists and describes the header files that must be included (i.e., using #include) by any code that uses this library.
Source File Name Description
/drv_touch_adc.h Header file that exports the driver API.
Required File(s)
All of the required files listed in the following table are automatically added into the MPLAB X IDE project by the MHC
when the library is selected for use.
This table lists and describes the source and header files that must always be included in the MPLAB X IDE project to build this library.
Source File Name Description
/src/drv_touch_adc.c Basic ADC Touch Driver implementation file.
Optional File(s)
This table lists and describes the source and header files that may optionally be included if required for the desired implementation.
Source File Name Description
N/A No optional files are available for this library.
Module Dependencies
The ADC Touch Driver Library depends on the following modules:
• Interrupt System Service Library
• Ports System Service Library
• Touch System Service Library
• I2C Driver Library
Library Interface
This section describes the API functions of the ADC Touch Driver library.
Refer to each section for a detailed description.
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1037
a) System Functions
b) Data Types and Constants
Files
This section lists the source and header files used by the ADC Touch Driver Library.
AR1021 Touch Driver Library
This topic describes the AR1021 Touch Driver Library.
Introduction
This library provides a low-level abstraction of the AR1021 Touch Driver Library that is available on the Microchip family of microcontrollers with a
convenient C language interface. It can be used to simplify low-level access to the module without the necessity of interacting directly with the
module's registers, thereby hiding differences from one microcontroller variant to another.
Description
The AR1021 Touch Driver Library, in conjunction with the Microchip AR1021 Resistive Touch Screen Controller module, allows an application to:
• Calibrate touch points
• Receive touch points
The following application services are provided by the AR1021 Touch Driver Library:
• Configuring the AR1021 controller (TouchThreshold, PenUpDelay, PenStateReportDelaylist, SensitivityFilter, etc.)
• Saving touch points to EEPROM
The operational services are not typically accessible to the application as this portion of the code resides within the Touch System Service Library
software layer and is used by the Graphics Library stack services to receive touch point data.
Using the Library
This topic describes the basic architecture of the AR1021 Touch Driver Library and provides information and examples on its use.
Description
Interface Header File: drv_ar1021.h
The interface to the AR1021 Touch Driver library is defined in the drv_ar1021.h header file. Any C language source (.c) file that uses the
AR1021 Touch Driver library should include this header.
Please refer to the What is MPLAB Harmony? section for how the driver interacts with the framework.
Abstraction Model
This library provides a low-level abstraction of the AR1021 Touch Driver Library on the Microchip family microcontrollers with a convenient C
language interface. This topic describes how that abstraction is modeled in software and introduces the library's interface.
Description
The AR1021 Touch Driver Library provides the following functionality:
• AR1021 library initialization
• AR1021 controller configuration
• AR1021 controller connectivity
• AR1021 polling for pen-down and pen-up touch point events
The abstraction model shown in the following diagram depicts how the AR1021 Touch Driver is positioned in the MPLAB Harmony framework. The
AR1021 Touch Driver Library uses the SPI Driver for control and touch data transfers to the AR1021 module.
AR1021 Touch Driver Abstraction Model
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1038
Library Overview
Refer to the Driver Library Overview section for information on how the driver operates in a system.
The library interface routines are divided into various sub-sections, which address one of the blocks or the overall operation of the AR1021 Touch
Driver module.
Library Interface Section Description
System Functions Provides system module interfaces, device initialization, deinitialization, task, and
status functions.
Client Functions Provides functions to open, close, and calibrate the AR1021 Touch Driver.
How the Library Works
The library provides interfaces to support:
• System functions, which provide system module interfaces, device initialization, deinitialization, task, touch, and status functions
• Client functions, which open, close, and calibrate the AR1021 Touch Driver
Initializing the Driver
Before the AR1021 Touch Driver can be opened, it must be configured and initialized. The driver build time configuration is defined by the
configuration macros. Refer to the Building the Library section for the location of and more information on the various configuration macros and
how these macros should be designed. The driver initialization is configured through the DRV_TOUCH_INIT data structure that is passed to the
DRV_TOUCH_AR1021_Initialize function. The initialization parameters include the interrupt source, interrupt pin remap configuration and touch
screen resolution. The following code shows an example of initializing the AR1021 Touch Driver.
Example:
/* The following code shows an example of designing the
* DRV_TOUCH_INIT data structure. It also shows how an example
* usage of the DRV_TOUCH_AR1021_Initialize function.
*/
DRV_TOUCH_INIT drvTouchInitData;
SYS_MODULE_OBJ objectHandle;
/* Driver initialization */
objectHandle = DRV_TOUCH_AR1021_Initialize(DRV_TOUCH_INDEX_0,
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1039
(SYS_MODULE_INIT*)drvTouchInitData);
if (SYS_MODULE_OBJ_INVALID == objectHandle)
{
// Handle error
}
Opening the Driver
To use the AR1021 Touch Driver, the application must open the driver. This is done by calling the DRV_TOUCH_AR1021_Open function.
If successful, the DRV_TOUCH_AR1021_Open function will return a handle to the driver. This handle records the association between the client
and the driver instance that was opened. The DRV_TOUCH_AR1021_Open function may return DRV_HANDLE_INVALID in the situation where
the driver is not ready to be opened. When this occurs, the application can try opening the driver again. Note that the open function may return an
invalid handle in other (error) cases as well. The following code shows an example of the driver being opened.
DRV_HANDLE handle;
handle = DRV_TOUCH_AR1021_Open( DRV_TOUCH_AR1021_INDEX_0,
DRV_IO_INTENT_EXCLUSIVE );
if( DRV_HANDLE_INVALID == handle )
{
// Unable to open the driver
}
Tasks Routine
This routine processes the AR1021 Touch Driver commands from the command queue. If the state of the command is initialize or done it returns.
If the read request registration is successful the state of command is to decode input. The tasks routine decodes the input and updates the global
variables storing the touch input data in form of x and y coordinates. The AR1021 Touch Driver task routine is to be called from SYS_Tasks. The
following code shows an example:
SYS_MODULE_OBJ object; // Returned from DRV_TOUCH_AR1021_Initialize
void SYS_Tasks( void )
{
DRV_TOUCH_AR1021_Tasks ( object );
// Do other tasks
}
Configuring the Library
Macros
Name Description
DRV_AR1021_CALIBRATION_DELAY Define the calibration delay.
DRV_AR1021_CALIBRATION_INSET Define the calibration inset.
DRV_AR1021_CLIENTS_NUMBER Selects the maximum number of clients.
DRV_AR1021_INDEX AR1021 static index selection.
DRV_AR1021_INSTANCES_NUMBER Sets up the maximum number of hardware instances that can be supported.
DRV_AR1021_INTERRUPT_MODE Controls operation of the driver in the interrupt or polled mode.
DRV_AR1021_SAMPLE_POINTS Define the sample points.
DRV_AR1021_TOUCH_DIAMETER Define the touch diameter.
Description
The configuration of the AR1021 Touch Driver is accomplished through AR1021 Touch Driver selections in the MPLAB Harmony Configurator
(MHC). Based on the selections made, a specific AR1021 Touch Driver is established automatically to execute all system configuration,
initialization, and steady-state touch acquisitions.
Refer to Volume III: MPLAB Harmony Configurator (MHC) for more details on system configuration. Refer to the Applications Help section for
additional information.
DRV_AR1021_CALIBRATION_DELAY Macro
Define the calibration delay.
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1040
File
drv_ar1021_config_template.h
C
#define DRV_AR1021_CALIBRATION_DELAY 300
Description
AR1021 Calibration Delay
This macro enables the delay between calibration touch points.
Remarks
None.
DRV_AR1021_CALIBRATION_INSET Macro
Define the calibration inset.
File
drv_ar1021_config_template.h
C
#define DRV_AR1021_CALIBRATION_INSET 25
Description
AR1021 Calibration Inset
This macro define the calibration inset.
Remarks
None.
DRV_AR1021_CLIENTS_NUMBER Macro
Selects the maximum number of clients.
File
drv_ar1021_config_template.h
C
#define DRV_AR1021_CLIENTS_NUMBER 1
Description
AR1021 Maximum Number of Clients
This definition selected the maximum number of clients that the AR1021 driver can support at run time.
Remarks
None.
DRV_AR1021_INDEX Macro
AR1021 static index selection.
File
drv_ar1021_config_template.h
C
#define DRV_AR1021_INDEX DRV_AR1021_INDEX_0
Description
AR1021 Static Index Selection
AR1021 static index selection for the driver object reference.
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1041
Remarks
This index is required to make a reference to the driver object.
DRV_AR1021_INSTANCES_NUMBER Macro
Sets up the maximum number of hardware instances that can be supported.
File
drv_ar1021_config_template.h
C
#define DRV_AR1021_INSTANCES_NUMBER 1
Description
AR1021 hardware instance configuration
This macro sets up the maximum number of hardware instances that can be supported.
Remarks
None.
DRV_AR1021_INTERRUPT_MODE Macro
Controls operation of the driver in the interrupt or polled mode.
File
drv_ar1021_config_template.h
C
#define DRV_AR1021_INTERRUPT_MODE false
Description
AR1021 Interrupt And Polled Mode Operation Control
This macro controls the operation of the driver in the interrupt mode of operation. The possible values of this macro are:
• true - Select if interrupt mode of AR1021 operation is desired
• false - Select if polling mode of AR1021 operation is desired
Not defining this option to true or false will result in a build error.
Remarks
None.
DRV_AR1021_SAMPLE_POINTS Macro
Define the sample points.
File
drv_ar1021_config_template.h
C
#define DRV_AR1021_SAMPLE_POINTS 4
Description
AR1021 Sample Points
AR1021 sample points
Remarks
None.
DRV_AR1021_TOUCH_DIAMETER Macro
Define the touch diameter.
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1042
File
drv_ar1021_config_template.h
C
#define DRV_AR1021_TOUCH_DIAMETER 10
Description
AR1021 Touch Diameter
This macro defines the touch diameter
Remarks
None.
Building the Library
This section lists the files that are available in the AR1021 Touch Driver Library.
Description
This section list the files that are available in the \src folder of the AR1021 Touch Driver. It lists which files need to be included in the build based
on either a hardware feature present on the board or configuration option selected by the system.
The following three tables list and describe the header (.h) and source (.c) files that implement this library. The parent folder for these files is
/framework/driver/touch/ar1021.
Interface File(s)
This table lists and describes the header files that must be included (i.e., using #include) by any code that uses this library.
Source File Name Description
/drv_ar1021.h Header file that exports the driver API.
Required File(s)
All of the required files listed in the following table are automatically added into the MPLAB X IDE project by the MHC
when the library is selected for use.
This table lists and describes the source and header files that must always be included in the MPLAB X IDE project to build this library.
Source File Name Description
/drv_ar1021.c Basic AR1021 Touch Driver implementation file.
Optional File(s)
This table lists and describes the source and header files that may optionally be included if required for the desired implementation.
Source File Name Description
N/A No optional files are available for this library.
Module Dependencies
The AR1021 Touch Driver Library depends on the following modules:
• Interrupt System Service Library
• Ports System Service Library
• Touch System Service Library
• I2C Driver Library
Library Interface
a) System Functions
Name Description
DRV_TOUCH_AR1021_Deinitialize De-initializes the specified instance of the AR1021 driver module.
DRV_TOUCH_AR1021_FactoryDefaultSet Set AR1021 controller to factory default configuration settings.
DRV_TOUCH_AR1021_Initialize Initializes the AR1021 instance for the specified driver index
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1043
DRV_TOUCH_AR1021_RegisterConfigWrite Write a value to the given AR1021 configuration register.
DRV_TOUCH_AR1021_Status Provides the current status of the AR1021 driver module.
DRV_TOUCH_AR1021_Tasks Maintains the driver's state machine and implements its task queue processing.
Implementation: Dynamic
DRV_TOUCH_AR1021_TouchDataRead Notifies the driver that the current touch data has been read
DRV_TOUCH_AR1021_TouchGetX Returns the x coordinate of touch input.
Implementation: Dynamic
DRV_TOUCH_AR1021_TouchGetY Returns the y coordinate of touch input.
Implementation: Dynamic
DRV_TOUCH_AR1021_TouchPenGet Returns the PEN state of the touch event.
DRV_TOUCH_AR1021_TouchStatus Returns the status of the current touch input.
b) Client Functions
Name Description
DRV_TOUCH_AR1021_Calibrate Calibrate the touch screen
DRV_TOUCH_AR1021_CalibrationSet Set calibration with pre-defined points..
DRV_TOUCH_AR1021_Close Closes an opened instance of the AR1021 driver
DRV_TOUCH_AR1021_Open Opens the specified AR1021 driver instance and returns a handle to it.
Implementation: Dynamic
c) Data Types and Constants
Name Description
DRV_TOUCH_AR1021_CALIBRATION_PROMPT_CALLBACK Defines the callback functions required to inform the user of touch
and release targets.
DRV_TOUCH_AR1021_HANDLE Touch screen controller AR1021 driver handle.
DRV_TOUCH_AR1021_MODULE_ID This is type DRV_TOUCH_AR1021_MODULE_ID.
DRV_TOUCH_AR1021_TASK_STATE Enumeration defining AR1021 touch controller driver task state.
DRV_TOUCH_AR1021_HANDLE_INVALID Definition of an invalid handle.
DRV_TOUCH_AR1021_INDEX_0 AR1021 driver index definitions.
DRV_TOUCH_AR1021_INDEX_COUNT Number of valid AR1021 driver indices.
Description
This section describes the API functions of the AR1021 Touch Driver Library.
a) System Functions
DRV_TOUCH_AR1021_Deinitialize Function
De-initializes the specified instance of the AR1021 driver module.
File
drv_ar1021.h
C
void DRV_TOUCH_AR1021_Deinitialize(SYS_MODULE_OBJ object);
Returns
None.
Description
De-initializes the specified instance of the AR1021 driver module, disabling its operation (and any hardware) and invalidates all of the internal data.
Remarks
Once the Initialize operation has been called, the De-initialize operation must be called before the Initialize operation can be called again.
This function will NEVER block waiting for hardware. If the operation requires time to allow the hardware to complete, this will be reported by the
DRV_TOUCH_AR1021_Status operation. The system has to use DRV_TOUCH_AR1021_Status to find out when the module is in the ready state.
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1044
Preconditions
Function DRV_TOUCH_AR1021_Initialize must have been called before calling this routine and a valid SYS_MODULE_OBJ must have been
returned.
Example
SYS_MODULE_OBJ object; // Returned from DRV_TOUCH_AR1021_Initialize
SYS_STATUS status;
DRV_TOUCH_AR1021_Deinitialize ( object );
status = DRV_TOUCH_AR1021_Status( object );
if( SYS_MODULE_UNINITIALIZED == status )
{
// Check again later if you need to know
// when the driver is deinitialized.
}
Parameters
Parameters Description
object Driver object handle, returned from DRV_TOUCH_AR1021_Initialize
Function
void DRV_TOUCH_AR1021_Deinitialize ( SYS_MODULE_OBJ object )
DRV_TOUCH_AR1021_FactoryDefaultSet Function
Set AR1021 controller to factory default configuration settings.
File
drv_ar1021.h
C
void DRV_TOUCH_AR1021_FactoryDefaultSet();
Returns
None
Description
This function returns the AR1021 to operate on factory default configuration settings.
Remarks
A power cycle is required to run on the default settings.
Preconditions
The DRV_TOUCH_AR1021_Open routine must have been called for the specified AR1021 driver instance.
Example
DRV_TOUCH_AR1021_FactoryDefaultSet ( void );
Function
void DRV_TOUCH_AR1021_FactoryDefaultSet(void)
DRV_TOUCH_AR1021_Initialize Function
Initializes the AR1021 instance for the specified driver index
File
drv_ar1021.h
C
SYS_MODULE_OBJ DRV_TOUCH_AR1021_Initialize(const SYS_MODULE_INDEX index, const SYS_MODULE_INIT * const
init);
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1045
Returns
If successful, returns a valid handle to a driver instance object. Otherwise, returns SYS_MODULE_OBJ_INVALID.
Description
This routine initializes the AR1021 driver instance for the specified driver index, making it ready for clients to open and use it. The initialization data
is specified by the 'init' parameter. The initialization may fail if the number of driver objects allocated are insufficient or if the specified driver
instance is already initialized. The driver instance index is independent of the AR1021 module ID. For example, driver instance 0 can be assigned
to AR10212. If the driver is built statically, then some of the initialization parameters are overridden by configuration macros. Refer to the
description of the DRV_TOUCH_AR1021_INIT data structure for more details on which members on this data structure are overridden.
Remarks
This routine must be called before any other AR1021 routine is called.
This routine should only be called once during system initialization unless DRV_TOUCH_AR1021_Deinitialize is called to deinitialize the driver
instance. This routine will NEVER block for hardware access.
Preconditions
None.
Example
DRV_TOUCH_INIT drvAr1021InitData;
SYS_MODULE_OBJ objectHandle;
objectHandle = DRV_TOUCH_AR1021_Initialize(DRV_TOUCH_AR1021_INDEX_1, (SYS_MODULE_INIT*)drvAr1021InitData);
if (SYS_MODULE_OBJ_INVALID == objectHandle)
{
// Handle error
}
Parameters
Parameters Description
index Identifier for the instance to be initialized. Please note this is not the AR1021 id. The hardware
AR1021 id is set in the initialization structure. This is the index of the driver index to use.
init Pointer to a data structure containing any data necessary to initialize the driver. If this pointer
is NULL, the driver uses the static initialization override macros for each member of the
initialization data structure.
Function
SYS_MODULE_OBJ DRV_TOUCH_AR1021_Initialize( const SYS_MODULE_INDEX index,
const SYS_MODULE_INIT * const init )
DRV_TOUCH_AR1021_RegisterConfigWrite Function
Write a value to the given AR1021 configuration register.
File
drv_ar1021.h
C
void DRV_TOUCH_AR1021_RegisterConfigWrite(uint16_t regOffset, uint8_t Value);
Returns
None
Description
This function set a value to the given AR1021 configuration register.
Remarks
none
Preconditions
The DRV_TOUCH_AR1021_Open routine must have been called for the specified AR1021 driver instance.
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1046
Example
DRV_TOUCH_AR1021_RegisterConfigWrite(uint16_t regOffset, uint8_t Value);
Function
void DRV_TOUCH_AR1021_RegisterConfigWrite(uint16_t regOffset, uint8_t Value)
DRV_TOUCH_AR1021_Status Function
Provides the current status of the AR1021 driver module.
File
drv_ar1021.h
C
SYS_STATUS DRV_TOUCH_AR1021_Status(SYS_MODULE_OBJ object);
Returns
SYS_STATUS_READY - Indicates that the driver is busy with a previous system level operation and cannot start another
Description
This function provides the current status of the AR1021 driver module.
Remarks
Any value greater than SYS_STATUS_READY is also a normal running state in which the driver is ready to accept new operations.
SYS_MODULE_UNINITIALIZED - Indicates that the driver has been deinitialized
This value is less than SYS_STATUS_ERROR.
This function can be used to determine when any of the driver's module level operations has completed.
If the status operation returns SYS_STATUS_BUSY, the previous operation has not yet completed. Once the status operation returns
SYS_STATUS_READY, any previous operations have completed.
The value of SYS_STATUS_ERROR is negative (-1). Any value less than that is also an error state.
This function will NEVER block waiting for hardware.
If the Status operation returns an error value, the error may be cleared by calling the reinitialize operation. If that fails, the deinitialize operation will
need to be called, followed by the initialize operation to return to normal operations.
Preconditions
The DRV_TOUCH_AR1021_Initialize function must have been called before calling this function.
Example
SYS_MODULE_OBJ object; // Returned from DRV_TOUCH_AR1021_Initialize
SYS_STATUS status;
status = DRV_TOUCH_AR1021_Status( object );
if( SYS_STATUS_READY != status )
{
// Handle error
}
Parameters
Parameters Description
object Driver object handle, returned from DRV_TOUCH_AR1021_Initialize
Function
SYS_STATUS DRV_TOUCH_AR1021_Status ( SYS_MODULE_OBJ object )
DRV_TOUCH_AR1021_Tasks Function
Maintains the driver's state machine and implements its task queue processing.
Implementation: Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1047
File
drv_ar1021.h
C
void DRV_TOUCH_AR1021_Tasks(SYS_MODULE_OBJ object);
Returns
None.
Description
This routine is used to maintain the driver's internal state machine and implement its command queue processing. It is always called from
SYS_Tasks() function.
Remarks
This function is normally not called directly by an application. It is called by the system's Tasks routine (SYS_Tasks)
Preconditions
The DRV_TOUCH_AR1021_Initialize routine must have been called for the specified AR1021 driver instance.
Example
SYS_MODULE_OBJ object; // Returned from DRV_TOUCH_AR1021_Initialize
while( true )
{
DRV_TOUCH_AR1021_Tasks ( object );
// Do other tasks
}
Parameters
Parameters Description
object Object handle for the specified driver instance (returned from
DRV_TOUCH_AR1021_Initialize)
Function
void DRV_TOUCH_AR1021_Tasks ( SYS_MODULE_OBJ object );
DRV_TOUCH_AR1021_TouchDataRead Function
Notifies the driver that the current touch data has been read
File
drv_ar1021.h
C
void DRV_TOUCH_AR1021_TouchDataRead(const SYS_MODULE_INDEX index);
Returns
None.
Description
Notifies the driver that the current touch data has been read
Function
void DRV_TOUCH_AR1021_TouchDataRead( const SYS_MODULE_INDEX index )
DRV_TOUCH_AR1021_TouchGetX Function
Returns the x coordinate of touch input.
Implementation: Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1048
File
drv_ar1021.h
C
short DRV_TOUCH_AR1021_TouchGetX(uint8_t touchNumber);
Returns
It returns the x coordinate of the touch input in terms of number of pixels.
Description
It returns the x coordinate in form of number of pixels for a touch input denoted by touchNumber.
Parameters
Parameters Description
touchNumber index to the touch input.
Function
short DRV_TOUCH_AR1021_TouchGetX( uint8 touchNumber )
DRV_TOUCH_AR1021_TouchGetY Function
Returns the y coordinate of touch input.
Implementation: Dynamic
File
drv_ar1021.h
C
short DRV_TOUCH_AR1021_TouchGetY(uint8_t touchNumber);
Returns
It returns the y coordinate of the touch input in terms of number of pixels.
Description
It returns the y coordinate in form of number of pixes for a touch input denoted by touchNumber.
Parameters
Parameters Description
touchNumber index to the touch input.
Function
short DRV_TOUCH_AR1021_TouchGetY( uint8 touchNumber )
DRV_TOUCH_AR1021_TouchPenGet Function
Returns the PEN state of the touch event.
File
drv_ar1021.h
C
DRV_TOUCH_PEN_STATE DRV_TOUCH_AR1021_TouchPenGet(uint8_t touchNumber);
Returns
It returns DRV_TOUCH_PEN_STATE
Description
It returns the PEN state of the last touch event corresponding to the x and y position.
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1049
Parameters
Parameters Description
touchNumber index to the touch input.
Function
DRV_TOUCH_PEN_STATE DRV_TOUCH_AR1021_TouchPenGet(uint8_t touchNumber)
DRV_TOUCH_AR1021_TouchStatus Function
Returns the status of the current touch input.
File
drv_ar1021.h
C
DRV_TOUCH_POSITION_STATUS DRV_TOUCH_AR1021_TouchStatus(const SYS_MODULE_INDEX index);
Returns
It returns the status of the current touch input.
Description
It returns the status of the current touch input.
Function
DRV_TOUCH_POSITION_SINGLE DRV_TOUCH_AR1021_TouchStatus( const SYS_MODULE_INDEX index )
b) Client Functions
DRV_TOUCH_AR1021_Calibrate Function
Calibrate the touch screen
File
drv_ar1021.h
C
void DRV_TOUCH_AR1021_Calibrate(const DRV_TOUCH_AR1021_CALIBRATION_PROMPT_CALLBACK * prompt);
Returns
None
Description
This function display calibration points on the display to enable calibration.
Remarks
None
Preconditions
The DRV_TOUCH_AR1021_Initialize routine must have been called for the specified AR1021 driver instance.
Example
DRV_TOUCH_AR1021_Calibrate ( handle );
Function
void DRV_TOUCH_AR1021_Calibrate ( ( const DRV_TOUCH_AR1021_CALIBRATION_PROMPT_CALLBACK * prompt ) )
DRV_TOUCH_AR1021_CalibrationSet Function
Set calibration with pre-defined points..
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1050
File
drv_ar1021.h
C
void DRV_TOUCH_AR1021_CalibrationSet(DRV_TOUCH_SAMPLE_POINTS * samplePoints);
Returns
None
Description
This function allows for the setting of pre-loaded calibration points.
Remarks
None
Preconditions
The DRV_TOUCH_AR1021_Open routine must have been called for the specified AR1021 driver instance.
Example
DRV_TOUCH_AR1021_CalibrationSet ( void );
Function
void DRV_TOUCH_AR1021_CalibrationSet(void)
DRV_TOUCH_AR1021_Close Function
Closes an opened instance of the AR1021 driver
File
drv_ar1021.h
C
void DRV_TOUCH_AR1021_Close(DRV_HANDLE handle);
Returns
None
Description
This function closes an opened instance of the AR1021 driver, invalidating the handle.
Remarks
After calling this routine, the handle passed in "handle" must not be used with any of the remaining driver routines. A new handle must be obtained
by calling DRV_TOUCH_AR1021_Open before the caller may use the driver again. This function is thread safe in a RTOS application.
Usually there is no need for the driver client to verify that the Close operation has completed.
Preconditions
The DRV_TOUCH_AR1021_Initialize routine must have been called for the specified AR1021 driver instance.
DRV_TOUCH_AR1021_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE handle; // Returned from DRV_TOUCH_AR1021_Open
DRV_TOUCH_AR1021_Close ( handle );
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
void DRV_TOUCH_AR1021_Close ( DRV_HANDLE handle )
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1051
DRV_TOUCH_AR1021_Open Function
Opens the specified AR1021 driver instance and returns a handle to it.
Implementation: Dynamic
File
drv_ar1021.h
C
DRV_HANDLE DRV_TOUCH_AR1021_Open(const SYS_MODULE_INDEX drvIndex, const DRV_IO_INTENT intent);
Returns
If successful, the routine returns a valid open-instance handle (a number identifying both the caller and the module instance).
If an error occurs, the return value is DRV_HANDLE_INVALID. An error can occur when the following is true:
• if the number of client objects allocated via DRV_TOUCH_AR1021_CLIENTS_NUMBER is insufficient
• if the client is trying to open the driver but driver has been opened exclusively by another client
• if the driver hardware instance being opened is not initialized or is invalid
Description
This routine opens the specified AR1021 driver instance and provides a handle that must be provided to all other client-level operations to identify
the caller and the instance of the driver. The ioIntent parameter defines how the client interacts with this driver instance.
The current version of driver does not support the DRV_IO_INTENT feature. The driver is by default non-blocking. The driver can perform both
read and write to the AR1021 device. The driver supports single client only.
Remarks
The handle returned is valid until the DRV_TOUCH_AR1021_Close routine is called. This routine will NEVER block waiting for hardware. If the
requested intent flags are not supported, the routine will return DRV_HANDLE_INVALID. This function is thread safe in a RTOS application. It
should not be called in an ISR.
Preconditions
The DRV_TOUCH_AR1021_Initialize function must have been called before calling this function.
Example
DRV_HANDLE handle;
handle = DRV_TOUCH_AR1021_Open( DRV_TOUCH_AR1021_INDEX_0, DRV_IO_INTENT_EXCLUSIVE );
if( DRV_HANDLE_INVALID == handle )
{
// Unable to open the driver
}
Parameters
Parameters Description
drvIndex Index of the driver initialized with DRV_TOUCH_AR1021_Initialize().
intent Zero or more of the values from the enumeration DRV_IO_INTENT ORed together to indicate
the intended use of the driver. The current version of driver does not support the selective IO
intent feature.
Function
DRV_HANDLE DRV_TOUCH_AR1021_Open ( const SYS_MODULE_INDEX drvIndex,
const DRV_IO_INTENT intent )
c) Data Types and Constants
DRV_TOUCH_AR1021_CALIBRATION_PROMPT_CALLBACK Structure
Defines the callback functions required to inform the user of touch and release targets.
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1052
File
drv_ar1021.h
C
typedef struct {
void (* firstPromptCallback)(void);
void (* secondPromptCallback)(void);
void (* thirdPromptCallback)(void);
void (* fourthPromptCallback)(void);
void (* completeCallback)(void);
} DRV_TOUCH_AR1021_CALIBRATION_PROMPT_CALLBACK;
Members
Members Description
void (* firstPromptCallback)(void); first calibration target
void (* secondPromptCallback)(void); second calibration target
void (* thirdPromptCallback)(void); third calibration target
void (* fourthPromptCallback)(void); fourth calibration target
void (* completeCallback)(void); complete calibration
Description
TOUCH Driver Calibration Initialization Data
This data type defines the callback function pointers required to inform of touch and release targets. The driver will invoke each callback in
sequential order. The host code can display graphic and/or textual content to direct the user when a where on the LCD display to touch and
release.
Remarks
None.
DRV_TOUCH_AR1021_HANDLE Type
Touch screen controller AR1021 driver handle.
File
drv_ar1021.h
C
typedef uintptr_t DRV_TOUCH_AR1021_HANDLE;
Description
AR1021 Driver Handle
Touch controller AR1021 driver handle is a handle for the driver client object. Each driver with successful open call will return a new handle to the
client object.
Remarks
None.
DRV_TOUCH_AR1021_MODULE_ID Enumeration
File
drv_ar1021.h
C
typedef enum {
AR1021_ID_1 = 0,
AR1021_NUMBER_OF_MODULES
} DRV_TOUCH_AR1021_MODULE_ID;
Description
This is type DRV_TOUCH_AR1021_MODULE_ID.
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1053
DRV_TOUCH_AR1021_TASK_STATE Enumeration
Enumeration defining AR1021 touch controller driver task state.
File
drv_ar1021.h
C
typedef enum {
DRV_TOUCH_AR1021_TASK_STATE_INIT = 0,
DRV_TOUCH_AR1021_TASK_STATE_DONE
} DRV_TOUCH_AR1021_TASK_STATE;
Members
Members Description
DRV_TOUCH_AR1021_TASK_STATE_INIT = 0 Task initialize state
DRV_TOUCH_AR1021_TASK_STATE_DONE Task complete state
Description
AR1021 Touch Controller Driver Task State
This enumeration defines the AR1021 touch controller driver task state. The task state helps to synchronize the operations of initialization the the
task, adding the read input task to the task queue once the touch controller notifies the available touch input and a decoding the touch input
received.
Remarks
None.
DRV_TOUCH_AR1021_HANDLE_INVALID Macro
Definition of an invalid handle.
File
drv_ar1021.h
C
#define DRV_TOUCH_AR1021_HANDLE_INVALID ((DRV_TOUCH_AR1021_HANDLE)(-1))
Description
AR1021 Driver Invalid Handle
This is the definition of an invalid handle. An invalid handle is is returned by DRV_TOUCH_AR1021_Open() and DRV_AR1021_Close() functions
if the request was not successful.
Remarks
None.
DRV_TOUCH_AR1021_INDEX_0 Macro
AR1021 driver index definitions.
File
drv_ar1021.h
C
#define DRV_TOUCH_AR1021_INDEX_0 0
Description
AR1021 Driver Module Index Numbers
These constants provide the AR1021 driver index definitions.
Remarks
These constants should be used in place of hard-coded numeric literals. These values should be passed into the DRV_AR1021_Initialize and
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1054
DRV_AR1021_Open functions to identify the driver instance in use.
DRV_TOUCH_AR1021_INDEX_COUNT Macro
Number of valid AR1021 driver indices.
File
drv_ar1021.h
C
#define DRV_TOUCH_AR1021_INDEX_COUNT 1
Description
AR1021 Driver Module Index Count
This constant identifies the number of valid AR1021 driver indices.
Remarks
This constant should be used in place of hard-coded numeric literals.
This value is derived from device-specific header files defined as part of the peripheral libraries.
Files
Files
Name Description
drv_ar1021.h Touch controller AR1021 driver implementation.
Description
This section lists the source and header files used by the AR1021 Touch Driver Library.
drv_ar1021.h
Touch controller AR1021 driver implementation.
Enumerations
Name Description
DRV_TOUCH_AR1021_MODULE_ID This is type DRV_TOUCH_AR1021_MODULE_ID.
DRV_TOUCH_AR1021_TASK_STATE Enumeration defining AR1021 touch controller driver task state.
Functions
Name Description
DRV_TOUCH_AR1021_Calibrate Calibrate the touch screen
DRV_TOUCH_AR1021_CalibrationSet Set calibration with pre-defined points..
DRV_TOUCH_AR1021_Close Closes an opened instance of the AR1021 driver
DRV_TOUCH_AR1021_Deinitialize De-initializes the specified instance of the AR1021 driver module.
DRV_TOUCH_AR1021_FactoryDefaultSet Set AR1021 controller to factory default configuration settings.
DRV_TOUCH_AR1021_Initialize Initializes the AR1021 instance for the specified driver index
DRV_TOUCH_AR1021_Open Opens the specified AR1021 driver instance and returns a handle to it.
Implementation: Dynamic
DRV_TOUCH_AR1021_RegisterConfigWrite Write a value to the given AR1021 configuration register.
DRV_TOUCH_AR1021_Status Provides the current status of the AR1021 driver module.
DRV_TOUCH_AR1021_Tasks Maintains the driver's state machine and implements its task queue processing.
Implementation: Dynamic
DRV_TOUCH_AR1021_TouchDataRead Notifies the driver that the current touch data has been read
DRV_TOUCH_AR1021_TouchGetX Returns the x coordinate of touch input.
Implementation: Dynamic
DRV_TOUCH_AR1021_TouchGetY Returns the y coordinate of touch input.
Implementation: Dynamic
DRV_TOUCH_AR1021_TouchPenGet Returns the PEN state of the touch event.
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1055
DRV_TOUCH_AR1021_TouchStatus Returns the status of the current touch input.
Macros
Name Description
DRV_TOUCH_AR1021_HANDLE_INVALID Definition of an invalid handle.
DRV_TOUCH_AR1021_INDEX_0 AR1021 driver index definitions.
DRV_TOUCH_AR1021_INDEX_COUNT Number of valid AR1021 driver indices.
Structures
Name Description
DRV_TOUCH_AR1021_CALIBRATION_PROMPT_CALLBACK Defines the callback functions required to inform the user of touch
and release targets.
Types
Name Description
DRV_TOUCH_AR1021_HANDLE Touch screen controller AR1021 driver handle.
Description
Touch controller AR1021 driver file
This file consist of touch controller AR1021 driver interfaces. It implements the driver interfaces which read the touch input data from AR1021
through SPI bus.
File Name
drv_ar1021.c
MTCH6301 Touch Driver Library
This topic describes the MTCH6301 Touch Driver Library.
Introduction
This library provides an interface to manage the MTCH6301 Touch Driver module on the Microchip family of microcontrollers in different modes of
operation.
Description
The MPLAB Harmony MTCH6301 Touch Driver provides a high-level interface to the MTCH6301 touch controller device. This driver provides
application routines to read the touch input data from the touch screen. The MTCH6301 device can notify the availability of touch input data
through external interrupt. The MTCH6301 driver allows the application to map a controller pin as an external interrupt pin.
Currently, the MTCH6301 Touch Driver only supports non-gestural single-fingered touch input.
Using the Library
This topic describes the basic architecture of the MTCH6301 Touch Driver Library and provides information and examples on its use.
Description
Interface Header File: drv_mtch6301.h
The interface to the MTCH6301 Touch Driver library is defined in the drv_mtch6301.h header file. Any C language source (.c) file that uses the
MTCH6301 Touch Driver library should include this header.
Please refer to the What is MPLAB Harmony? section for how the driver interacts with the framework.
Abstraction Model
This library provides a low-level abstraction of the MTCH6301 Touch Driver Library on the Microchip family microcontrollers with a convenient C
language interface. This topic describes how that abstraction is modeled in software and introduces the library's interface.
Description
The MTCH6301 Touch Driver has routines to perform the following operations:
• Sending read request
• Reading the touch input data
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1056
• Access to the touch input data
The driver initialization routines allow the application to initialize the driver. The driver must be initialized before it can be used by application. Once
the driver is initialized the driver open routine allows to retrieve the client handle. Once the touch input is available a touch input read request is
sent and input data is retrieved in a buffer. The buffer data is then decoded to get the x and y coordinate of the touch screen in the form of the
number of pixels.
MTCH6301 Driver Abstraction Model
Library Overview
Refer to the Driver Library Overview section for information on how the driver operates in a system.
The library interface routines are divided into various sub-sections, which address one of the blocks or the overall operation of the MTCH6301
Touch Driver.
Library Interface Section Description
System Functions Provides system module interfaces, device initialization, deinitialization, open, close,
task, and status functions.
How the Library Works
The library provides interfaces to support:
• System functions, which provide system module interfaces, device initialization, deinitialization, open, close, task, and status functions.
• Read Request function, which provides Touch input data read request function
• Read Touch Input function, which provides functions retrieving updated Touch input in the form x and y coordinates.
Initializing the Driver
Before the MTCH6301 Touch Driver can be opened, it must be configured and initialized. The driver build time configuration is defined by the
configuration macros. Refer to the Building the Library section for the location of and more information on the various configuration macros and
how these macros should be designed. The driver initialization is configured through the DRV_TOUCH_INIT data structure that is passed to the
DRV_TOUCH_MTCH6301_Initialize function. The initialization parameters include the interrupt source, interrupt pin remap configuration and touch
screen resolution. The following code shows an example of initializing the MTCH6301 Touch Driver.
Example:
/* The following code shows an example of designing the
* DRV_TOUCH_INIT data structure. It also shows how an example
* usage of the DRV_TOUCH_MTCH6301_Initialize function.
*/
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1057
DRV_TOUCH_INIT drvTouchInitData;
SYS_MODULE_OBJ objectHandle;
/* Touch Module Id*/
drvTouchInitData.touchId = DRV_TOUCH_INDEX_0;
/* I2C Bus driver open */
drvTouchInitData.drvOpen = DRV_I2C_Open;
/* Interrupt Source for Touch */
drvTouchInitData.interruptSource = INT_SOURCE_EXTERNAL_1;
/* Interrupt Pin function mapping */
drvTouchInitData.interruptPort.inputFunction = INPUT_FUNC_INT1;
/* Pin to be mapped as interrupt pin */
drvTouchInitData.interruptPort.inputPin = INPUT_PIN_RPE8;
/* Analog pin number */
drvTouchInitData.interruptPort.analogPin = PORTS_ANALOG_PIN_25;
/* Pin Mode of analog pin */
drvTouchInitData.interruptPort.pinMode = PORTS_PIN_MODE_DIGITAL;
/* Interrupt pin port */
drvTouchInitData.interruptPort.channel = PORT_CHANNEL_E;
/* Interrupt pin port maskl */
drvTouchInitData.interruptPort.dataMask = 0x8;
/* Touch screen orientation */
drvTouchInitData.orientation = DISP_ORIENTATION;
/* Touch screen horizontal resolution */
drvTouchInitData.horizontalResolution = DISP_HOR_RESOLUTION;
/* Touch screen vertical resolution */
drvTouchInitData.verticalResolution = DISP_VER_RESOLUTION;
/* Driver initialization */
objectHandle = DRV_TOUCH_MTCH6301_Initialize(DRV_TOUCH_INDEX_0,
(SYS_MODULE_INIT*)drvTouchInitData);
if (SYS_MODULE_OBJ_INVALID == objectHandle)
{
// Handle error
}
Opening the Driver
To use the MTCH6301 Touch Driver, the application must open the driver. This is done by calling the DRV_TOUCH_MTCH6301_Open function.
If successful, the DRV_TOUCH_MTCH6301_Open function will return a handle to the driver. This handle records the association between the
client and the driver instance that was opened. The DRV_TOUCH_MTCH6301_Open function may return DRV_HANDLE_INVALID in the situation
where the driver is not ready to be opened. When this occurs, the application can try opening the driver again. Note that the open function may
return an invalid handle in other (error) cases as well. The following code shows an example of the driver being opened.
DRV_HANDLE handle;
handle = DRV_TOUCH_MTCH6301_Open( DRV_TOUCH_MTCH6301_INDEX_0,
DRV_IO_INTENT_EXCLUSIVE );
if( DRV_HANDLE_INVALID == handle )
{
// Unable to open the driver
}
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1058
Touch Input Read Request
To read the touch input from the MTCH6301 touch controller device, a read request must be registered. This is done by calling the
DRV_TOUCH_MTCH6301_ReadRequest. If successful it registers a buffer read request to the I2C command queue. It also adds a input decode
command to the MTCH6301 command queue once the I2C returns with touch input data. It can return error if the driver instance object is invalid or
the MTCH6301 command queue is full. The read request is to be called from the MTCH6301 ISR. This ISR is triggered once the touch input is
available. The following code shows an example of a MTCH6301 read request registration:
SYS_MODULE_OBJ object; // Returned from DRV_TOUCH_MTCH6301_Initialize
void __ISR(_EXTERNAL_INT_VECTOR, ipl5) _IntHandlerDrvMtch6301(void)
{
DRV_TOUCH_MTCH6301_ReadRequest ( object );
// Do other tasks
}
Tasks Routine
This routine processes the MTCH6301 commands from the command queue. If the state of the command is initialize or done it returns. If the read
request registration is successful the state of command is to decode input. The tasks routine decodes the input and updates the global variables
storing the touch input data in form of x and y coordinates. The MTCH6301 Touch Driver task routine is to be called from SYS_Tasks. The
following code shows an example:
SYS_MODULE_OBJ object; // Returned from DRV_TOUCH_MTCH6301_Initialize
void SYS_Tasks( void )
{
DRV_TOUCH_MTCH6301_Tasks ( object );
// Do other tasks
}
Configuring the Library
Macros
Name Description
DRV_MTCH6301_CALIBRATION_DELAY Defines the calibration delay.
DRV_MTCH6301_CALIBRATION_INSET Defines the calibration inset.
DRV_MTCH6301_CLIENTS_NUMBER Selects the maximum number of clients.
DRV_MTCH6301_INDEX MTCH6301 static index selection.
DRV_MTCH6301_INSTANCES_NUMBER Sets up the maximum number of hardware instances that can be supported.
DRV_MTCH6301_INTERRUPT_MODE Controls operation of the driver in the interrupt or polled mode.
DRV_MTCH6301_SAMPLE_POINTS Define the sample points.
DRV_MTCH6301_TOUCH_DIAMETER Defines the touch diameter.
Description
The configuration of the MTCH6301 Touch Driver is based on the file system_config.h.
This header file contains the configuration selection for the MTCH6301 Touch Driver. Based on the selections made, the driver may support the
selected features. These configuration settings will apply to all instances of the MTCH6301 Touch Driver.
This header can be placed anywhere, the path of this header needs to be present in the include search path for a successful build. Refer to the
Applications Help section for more details.
DRV_MTCH6301_CALIBRATION_DELAY Macro
Defines the calibration delay.
File
drv_mtch6301_config_template.h
C
#define DRV_MTCH6301_CALIBRATION_DELAY 300
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1059
Description
MTCH6301 Calibration Delay
This macro enables the delay between calibration touch points.
Remarks
None.
DRV_MTCH6301_CALIBRATION_INSET Macro
Defines the calibration inset.
File
drv_mtch6301_config_template.h
C
#define DRV_MTCH6301_CALIBRATION_INSET 25
Description
MTCH6301 Calibration Inset
This macro defines the calibration inset.
Remarks
None.
DRV_MTCH6301_CLIENTS_NUMBER Macro
Selects the maximum number of clients.
File
drv_mtch6301_config_template.h
C
#define DRV_MTCH6301_CLIENTS_NUMBER 1
Description
MTCH6301 maximum number of clients
This macro selects the maximum number of clients.
This definition selected the maximum number of clients that the MTCH6301 driver can support at run time.
Remarks
None.
DRV_MTCH6301_INDEX Macro
MTCH6301 static index selection.
File
drv_mtch6301_config_template.h
C
#define DRV_MTCH6301_INDEX DRV_MTCH6301_INDEX_0
Description
MTCH6301 Static Index Selection
This macro specifies the static index selection for the driver object reference.
Remarks
This index is required to make a reference to the driver object.
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1060
DRV_MTCH6301_INSTANCES_NUMBER Macro
Sets up the maximum number of hardware instances that can be supported.
File
drv_mtch6301_config_template.h
C
#define DRV_MTCH6301_INSTANCES_NUMBER 1
Description
MTCH6301 hardware instance configuration
This macro sets up the maximum number of hardware instances that can be supported.
Remarks
None.
DRV_MTCH6301_INTERRUPT_MODE Macro
Controls operation of the driver in the interrupt or polled mode.
File
drv_mtch6301_config_template.h
C
#define DRV_MTCH6301_INTERRUPT_MODE false
Description
MTCH6301 Interrupt And Polled Mode Operation Control
This macro controls the operation of the driver in the interrupt mode of operation. The possible values of this macro are:
• true - Select if interrupt mode of MTCH6301 operation is desired
• false - Select if polling mode of MTCH6301 operation is desired
Not defining this option to true or false will result in a build error.
Remarks
None.
DRV_MTCH6301_SAMPLE_POINTS Macro
Define the sample points.
File
drv_mtch6301_config_template.h
C
#define DRV_MTCH6301_SAMPLE_POINTS 4
Description
MTCH6301 Sample Points
MTCH6301 sample points
Remarks
None.
DRV_MTCH6301_TOUCH_DIAMETER Macro
Defines the touch diameter.
File
drv_mtch6301_config_template.h
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1061
C
#define DRV_MTCH6301_TOUCH_DIAMETER 10
Description
MTCH6301 Touch Diameter
This macro defines the touch diameter
Remarks
None.
Building the Library
This section lists the files that are available in the MTCH6301 Touch Driver Library.
Description
This section list the files that are available in the \src folder of the MTCH6301 Touch Driver. It lists which files need to be included in the build
based on either a hardware feature present on the board or configuration option selected by the system.
The following three tables list and describe the header (.h) and source (.c) files that implement this library. The parent folder for these files is
/framework/driver/touch/mtch6301.
Interface File(s)
This table lists and describes the header files that must be included (i.e., using #include) by any code that uses this library.
Source File Name Description
/drv_mtch6301.h Header file that exports the driver API.
Required File(s)
All of the required files listed in the following table are automatically added into the MPLAB X IDE project by the MHC
when the library is selected for use.
This table lists and describes the source and header files that must always be included in the MPLAB X IDE project to build this library.
Source File Name Description
/src/drv_mtch6301.c Basic MTCH6301 Touch Driver implementation file.
Optional File(s)
This table lists and describes the source and header files that may optionally be included if required for the desired implementation.
Source File Name Description
N/A No optional files are available for this library.
Module Dependencies
The MTCH6301 Touch Driver Library depends on the following modules:
• Interrupt System Service Library
• Ports System Service Library
• Touch System Service Library
• I2C Driver Library
Library Interface
a) System Functions
Name Description
DRV_TOUCH_MTCH6301_Close Closes an opened instance of the MTCH6301 driver.
Implementation: Dynamic
DRV_TOUCH_MTCH6301_Deinitialize Deinitializes the specified instance of the MTCH6301 driver module.
Implementation: Dynamic
DRV_TOUCH_MTCH6301_Initialize Initializes the MTCH6301 instance for the specified driver index.
Implementation: Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1062
DRV_TOUCH_MTCH6301_Open Opens the specified MTCH6301 driver instance and returns a handle to it.
Implementation: Dynamic
DRV_TOUCH_MTCH6301_Status Provides the current status of the MTCH6301 driver module.
Implementation: Dynamic
DRV_TOUCH_MTCH6301_Tasks Maintains the driver's state machine and implements its task queue processing.
Implementation: Dynamic
DRV_TOUCH_MTCH6301_ReadRequest Sends a read request to I2C bus driver and adds the read task to queue.
Implementation: Dynamic
DRV_TOUCH_MTCH6301_TouchGetX Returns the x coordinate of touch input.
Implementation: Dynamic
DRV_TOUCH_MTCH6301_TouchGetY Returns the y coordinate of touch input.
Implementation: Dynamic
DRV_TOUCH_MTCH6301_TouchDataRead Notifies the driver that the current touch data has been read
DRV_TOUCH_MTCH6301_TouchStatus Returns the status of the current touch input.
b) Data Types and Constants
Name Description
_DRV_MTCH6301_CLIENT_OBJECT MTCH6301 Driver client object maintaining client data.
DRV_TOUCH_MTCH6301_HANDLE Touch screen controller MTCH6301 driver handle.
DRV_TOUCH_MTCH6301_MODULE_ID Number of valid MTCH6301 driver indices.
DRV_TOUCH_MTCH6301_HANDLE_INVALID Definition of an invalid handle.
DRV_TOUCH_MTCH6301_I2C_READ_FRAME_SIZE I2C Frame size for reading MTCH6301 touch input.
DRV_TOUCH_MTCH6301_CLIENT_OBJECT MTCH6301 Driver client object maintaining client data.
DRV_TOUCH_MTCH6301_INDEX_0 MTCH6301 driver index definitions.
DRV_TOUCH_MTCH6301_INDEX_1 This is macro DRV_TOUCH_MTCH6301_INDEX_1.
DRV_TOUCH_MTCH6301_INDEX_COUNT Number of valid Touch controller MTCH6301 driver indices.
DRV_TOUCH_MTCH6301_OBJECT Defines the data structure maintaining MTCH6301 driver instance object.
DRV_TOUCH_MTCH6301_TASK_QUEUE Defines the MTCH6301 Touch Controller driver task data structure.
DRV_TOUCH_MTCH6301_TASK_STATE Enumeration defining MTCH6301 touch controller driver task state.
DRV_TOUCH_MTCH6301_I2C_MASTER_READ_ID MTCH6301 input read, I2C address from where master reads touch input
data.
DRV_TOUCH_MTCH6301_I2C_MASTER_WRITE_ID MTCH6301 command register write, I2C address where master sends the
commands.
Description
This section describes the API functions of the MTCH6301 Touch Driver library.
Refer to each section for a detailed description.
a) System Functions
DRV_TOUCH_MTCH6301_Close Function
Closes an opened instance of the MTCH6301 driver.
Implementation: Dynamic
File
drv_mtch6301.h
C
void DRV_TOUCH_MTCH6301_Close(DRV_HANDLE handle);
Returns
None
Description
This function closes an opened instance of the MTCH6301 driver, invalidating the handle.
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1063
Remarks
After calling this routine, the handle passed in "handle" must not be used with any of the remaining driver routines. A new handle must be obtained
by calling DRV_TOUCH_MTCH6301_Open before the caller may use the driver again. This function is thread safe in a RTOS application.
Usually, there is no need for the driver client to verify that the Close operation has completed.
Preconditions
The DRV_TOUCH_MTCH6301_Initialize routine must have been called for the specified MTCH6301 driver instance.
DRV_TOUCH_MTCH6301_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE handle; // Returned from DRV_TOUCH_MTCH6301_Open
DRV_TOUCH_MTCH6301_Close ( handle );
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
void DRV_TOUCH_MTCH6301_Close ( DRV_HANDLE handle )
DRV_TOUCH_MTCH6301_Deinitialize Function
Deinitializes the specified instance of the MTCH6301 driver module.
Implementation: Dynamic
File
drv_mtch6301.h
C
void DRV_TOUCH_MTCH6301_Deinitialize(SYS_MODULE_OBJ object);
Returns
None.
Description
Deinitializes the specified instance of the MTCH6301 driver module, disabling its operation (and any hardware) and invalidates all of the internal
data.
Remarks
Once the Initialize operation has been called, the De-initialize operation must be called before the Initialize operation can be called again.
This function will NEVER block waiting for hardware. If the operation requires time to allow the hardware to complete, this will be reported by the
DRV_TOUCH_MTCH6301_Status operation. The system has to use DRV_TOUCH_MTCH6301_Status to determine when the module is in the
ready state.
Preconditions
Function DRV_TOUCH_MTCH6301_Initialize must have been called before calling this routine and a valid SYS_MODULE_OBJ must have been
returned.
Parameter: object - Driver object handle, returned from DRV_TOUCH_MTCH6301_Initialize
Example
SYS_MODULE_OBJ object; //Returned from DRV_TOUCH_MTCH6301_Initialize
SYS_STATUS status;
DRV_TOUCH_MTCH6301_Deinitialize ( object );
status = DRV_TOUCH_MTCH6301_Status( object );
if( SYS_MODULE_UNINITIALIZED == status )
{
// Check again later if you need to know
// when the driver is deinitialized.
}
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1064
Function
void DRV_TOUCH_MTCH6301_Deinitialize ( SYS_MODULE_OBJ object )
DRV_TOUCH_MTCH6301_Initialize Function
Initializes the MTCH6301 instance for the specified driver index.
Implementation: Dynamic
File
drv_mtch6301.h
C
SYS_MODULE_OBJ DRV_TOUCH_MTCH6301_Initialize(const SYS_MODULE_INDEX index, const SYS_MODULE_INIT * const
init);
Returns
If successful, returns a valid handle to a driver instance object. Otherwise, returns SYS_MODULE_OBJ_INVALID.
Description
This routine initializes the MTCH6301 driver instance for the specified driver index, making it ready for clients to open and use it. The initialization
data is specified by the 'init' parameter. The initialization may fail if the number of driver objects allocated are insufficient or if the specified driver
instance is already initialized. The driver instance index is independent of the MTCH6301 module ID. For example, driver instance 0 can be
assigned to MTCH63012. If the driver is built statically, then some of the initialization parameters are overridden by configuration macros. Refer to
the description of the DRV_TOUCH_MTCH6301_INIT data structure for more details on which members on this data structure are overridden.
Remarks
This routine must be called before any other MTCH6301 routine is called.
This routine should only be called once during system initialization unless DRV_TOUCH_MTCH6301_Deinitialize is called to deinitialize the driver
instance. This routine will NEVER block for hardware access.
Preconditions
None.
Example
DRV_TOUCH_MTCH6301_INIT init;
SYS_MODULE_OBJ objectHandle;
// Populate the MTCH6301 initialization structure
// Touch Module Id
init.touchId = DRV_TOUCH_INDEX_0;
// I2C Bus driver open
init.drvOpen = DRV_I2C_Open;
// Interrupt Source for Touch
init.interruptSource = INT_SOURCE_EXTERNAL_1;
// Interrupt Pin function mapping
init.interruptPort.inputFunction = INPUT_FUNC_INT1;
// Pin to be mapped as interrupt pin
init.interruptPort.inputPin = INPUT_PIN_RPE8;
// Analog pin number
init.interruptPort.analogPin = PORTS_ANALOG_PIN_25;
// Pin Mode of analog pin
init.interruptPort.pinMode = PORTS_PIN_MODE_DIGITAL;
// Interrupt pin port
init.interruptPort.channel = PORT_CHANNEL_E;
// Interrupt pin port maskl
init.interruptPort.dataMask = 0x8;
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1065
// Touch screen orientation
init.orientation = DISP_ORIENTATION;
// Touch screen horizontal resolution
init.horizontalResolution = DISP_HOR_RESOLUTION;
// Touch screen vertical resolution
init.verticalResolution = DISP_VER_RESOLUTION;
objectHandle = DRV_TOUCH_MTCH6301_Initialize(DRV_TOUCH_INDEX_0,
(SYS_MODULE_INIT*)init);
if (SYS_MODULE_OBJ_INVALID == objectHandle)
{
// Handle error
}
Parameters
Parameters Description
index Identifier for the instance to be initialized. Please note this is not the MTCH6301 ID. The
hardware MTCH6301 ID is set in the initialization structure. This is the index of the driver
index to use.
init Pointer to a data structure containing any data necessary to initialize the driver. If this pointer
is NULL, the driver uses the static initialization override macros for each member of the
initialization data structure.
Function
SYS_MODULE_OBJ DRV_TOUCH_MTCH6301_Initialize(const SYS_MODULE_INDEX index,
const SYS_MODULE_INIT * const init )
DRV_TOUCH_MTCH6301_Open Function
Opens the specified MTCH6301 driver instance and returns a handle to it.
Implementation: Dynamic
File
drv_mtch6301.h
C
DRV_HANDLE DRV_TOUCH_MTCH6301_Open(const SYS_MODULE_INDEX drvIndex, const DRV_IO_INTENT intent);
Returns
If successful, the routine returns a valid open-instance handle (a number identifying both the caller and the module instance).
If an error occurs, the return value is DRV_HANDLE_INVALID. An error can occur when the following is true:
• if the number of client objects allocated via DRV_TOUCH_MTCH6301_CLIENTS_NUMBER is insufficient
• if the client is trying to open the driver but driver has been opened exclusively by another client
• if the driver hardware instance being opened is not initialized or is invalid
Description
This routine opens the specified MTCH6301 driver instance and provides a handle that must be provided to all other client-level operations to
identify the caller and the instance of the driver. The ioIntent parameter defines how the client interacts with this driver instance.
The current version of driver does not support the DRV_IO_INTENT feature. The driver is by default non-blocking. The driver can perform both
read and write to the MTCH6301 device. The driver supports single client only.
Remarks
The handle returned is valid until the DRV_TOUCH_MTCH6301_Close routine is called. This routine will NEVER block waiting for hardware. If the
requested intent flags are not supported, the routine will return DRV_HANDLE_INVALID. This function is thread safe in a RTOS application. It
should not be called in an ISR.
Preconditions
The DRV_TOUCH_MTCH6301_Initialize function must have been called before calling this function.
Example
DRV_HANDLE handle;
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1066
handle = DRV_TOUCH_MTCH6301_Open( DRV_TOUCH_MTCH6301_INDEX_0,
DRV_IO_INTENT_EXCLUSIVE );
if( DRV_HANDLE_INVALID == handle )
{
// Unable to open the driver
}
Parameters
Parameters Description
drvIndex Index of the driver initialized with DRV_TOUCH_MTCH6301_Initialize().
intent Zero or more of the values from the enumeration DRV_IO_INTENT ORed together to indicate
the intended use of the driver. The current version of driver does not support the selective IO
intent feature.
Function
DRV_HANDLE DRV_TOUCH_MTCH6301_Open ( const SYS_MODULE_INDEX drvIndex,
const DRV_IO_INTENT intent )
DRV_TOUCH_MTCH6301_Status Function
Provides the current status of the MTCH6301 driver module.
Implementation: Dynamic
File
drv_mtch6301.h
C
SYS_STATUS DRV_TOUCH_MTCH6301_Status(SYS_MODULE_OBJ object);
Returns
SYS_STATUS_READY - Indicates that the driver is busy with a previous system-level operation and cannot start another
Description
This function provides the current status of the MTCH6301 driver module.
Remarks
Any value greater than SYS_STATUS_READY is also a normal running state in which the driver is ready to accept new operations.
SYS_MODULE_UNINITIALIZED - Indicates that the driver has been deinitialized
This value is less than SYS_STATUS_ERROR.
This function can be used to determine when any of the driver's module level operations has completed.
If the status operation returns SYS_STATUS_BUSY, the previous operation has not yet completed. Once the status operation returns
SYS_STATUS_READY, any previous operations have completed.
The value of SYS_STATUS_ERROR is negative (-1). Any value less than that is also an error state.
This function will NEVER block waiting for hardware.
If the Status operation returns an error value, the error may be cleared by calling the reinitialize operation. If that fails, the deinitialize operation will
need to be called, followed by the initialize operation to return to normal operations.
Preconditions
The DRV_TOUCH_MTCH6301_Initialize function must have been called before calling this function.
Example
SYS_MODULE_OBJ object; // Returned from DRV_TOUCH_MTCH6301_Initialize
SYS_STATUS status;
status = DRV_TOUCH_MTCH6301_Status( object );
if( SYS_STATUS_READY != status )
{
// Handle error
}
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1067
Parameters
Parameters Description
object Driver object handle, returned from DRV_TOUCH_MTCH6301_Initialize
Function
SYS_STATUS DRV_TOUCH_MTCH6301_Status ( SYS_MODULE_OBJ object )
DRV_TOUCH_MTCH6301_Tasks Function
Maintains the driver's state machine and implements its task queue processing.
Implementation: Dynamic
File
drv_mtch6301.h
C
void DRV_TOUCH_MTCH6301_Tasks(SYS_MODULE_OBJ object);
Returns
None.
Description
This routine is used to maintain the driver's internal state machine and implement its command queue processing. It is always called from
SYS_Tasks() function. This routine decodes the touch input data available in drvI2CReadFrameData.
Remarks
This function is normally not called directly by an application. It is called by the system's Tasks routine (SYS_Tasks)
Preconditions
The DRV_TOUCH_MTCH6301_Initialize routine must have been called for the specified MTCH6301 driver instance.
Example
SYS_MODULE_OBJ object; // Returned from DRV_TOUCH_MTCH6301_Initialize
void SYS_Tasks( void )
{
DRV_TOUCH_MTCH6301_Tasks ( object );
// Do other tasks
}
Parameters
Parameters Description
object Object handle for the specified driver instance (returned from
DRV_TOUCH_MTCH6301_Initialize)
Function
void DRV_TOUCH_MTCH6301_Tasks ( SYS_MODULE_OBJ object );
DRV_TOUCH_MTCH6301_ReadRequest Function
Sends a read request to I2C bus driver and adds the read task to queue.
Implementation: Dynamic
File
drv_mtch6301.h
C
void DRV_TOUCH_MTCH6301_ReadRequest(SYS_MODULE_OBJ object);
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1068
Returns
None.
Description
This routine is used to send a touch input read request to the I2C bus driver and adding the input read decode task to the queue. It is always called
from MTCH6301 interrupt ISR routine.
Remarks
This function is normally not called directly by an application. It is called by the MTCH6301 ISR routine.
Preconditions
The DRV_TOUCH_MTCH6301_Initialize routine must have been called for the specified MTCH6301 driver instance.
Example
SYS_MODULE_OBJ object; // Returned from DRV_TOUCH_MTCH6301_Initialize
void __ISR(_EXTERNAL_INT_VECTOR, ipl5) _IntHandlerDrvMtch6301(void)
{
DRV_TOUCH_MTCH6301_ReadRequest ( object );
// Do other tasks
}
Parameters
Parameters Description
object Object handle for the specified driver instance (returned from
DRV_TOUCH_MTCH6301_Initialize)
Function
void DRV_TOUCH_MTCH6301_ReadRequest( SYS_MODULE_OBJ object )
DRV_TOUCH_MTCH6301_TouchGetX Function
Returns the x coordinate of touch input.
Implementation: Dynamic
File
drv_mtch6301.h
C
short DRV_TOUCH_MTCH6301_TouchGetX(uint8_t touchNumber);
Returns
It returns the x coordinate of the touch input in terms of number of pixels.
Description
It returns the x coordinate in form of number of pixes for a touch input denoted by touchNumber.
Parameters
Parameters Description
touchNumber index to the touch input.
Function
short DRV_TOUCH_MTCH6301_TouchGetX( uint8 touchNumber )
DRV_TOUCH_MTCH6301_TouchGetY Function
Returns the y coordinate of touch input.
Implementation: Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1069
File
drv_mtch6301.h
C
short DRV_TOUCH_MTCH6301_TouchGetY(uint8_t touchNumber);
Returns
It returns the y coordinate of the touch input in terms of number of pixels.
Description
It returns the y coordinate in form of number of pixes for a touch input denoted by touchNumber.
Parameters
Parameters Description
touchNumber index to the touch input.
Function
short DRV_TOUCH_MTCH6301_TouchGetY( uint8 touchNumber )
DRV_TOUCH_MTCH6301_TouchDataRead Function
Notifies the driver that the current touch data has been read
File
drv_mtch6301.h
C
void DRV_TOUCH_MTCH6301_TouchDataRead(const SYS_MODULE_INDEX index);
Returns
None.
Description
Notifies the driver that the current touch data has been read
Function
void DRV_TOUCH_MTCH6301_TouchDataRead( const SYS_MODULE_INDEX index )
DRV_TOUCH_MTCH6301_TouchStatus Function
Returns the status of the current touch input.
File
drv_mtch6301.h
C
DRV_TOUCH_POSITION_STATUS DRV_TOUCH_MTCH6301_TouchStatus(const SYS_MODULE_INDEX index);
Returns
It returns the status of the current touch input.
Description
It returns the status of the current touch input.
Function
DRV_TOUCH_POSITION_SINGLE DRV_TOUCH_MTCH6301_TouchStatus( const SYS_MODULE_INDEX index )
b) Data Types and Constants
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1070
DRV_TOUCH_MTCH6301_HANDLE Type
Touch screen controller MTCH6301 driver handle.
File
drv_mtch6301.h
C
typedef uintptr_t DRV_TOUCH_MTCH6301_HANDLE;
Description
MTCH6301 Driver Handle
Touch controller MTCH6301 driver handle is a handle for the driver client object. Each driver with succesful open call will return a new handle to
the client object.
Remarks
None.
DRV_TOUCH_MTCH6301_MODULE_ID Enumeration
Number of valid MTCH6301 driver indices.
File
drv_mtch6301.h
C
typedef enum {
MTCH6301_ID_1 = 0,
MTCH6301_NUMBER_OF_MODULES
} DRV_TOUCH_MTCH6301_MODULE_ID;
Description
MTCH6301 Driver Module Index Count
This constant identifies the number of valid MTCH6301 driver indices.
Remarks
This constant should be used in place of hard-coded numeric literals.
This value is derived from device-specific header files defined as part of the peripheral libraries.
DRV_TOUCH_MTCH6301_HANDLE_INVALID Macro
Definition of an invalid handle.
File
drv_mtch6301.h
C
#define DRV_TOUCH_MTCH6301_HANDLE_INVALID ((DRV_TOUCH_MTCH6301_HANDLE)(-1))
Description
MTCH6301 Driver Invalid Handle
This is the definition of an invalid handle. An invalid handle is is returned by DRV_TOUCH_MTCH6301_Open() and DRV_MTCH6301_Close()
functions if the request was not successful.
Remarks
None.
DRV_TOUCH_MTCH6301_I2C_READ_FRAME_SIZE Macro
I2C Frame size for reading MTCH6301 touch input.
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1071
File
drv_mtch6301.h
C
#define DRV_TOUCH_MTCH6301_I2C_READ_FRAME_SIZE 7
Description
MTCH6301 Driver Module I2C Frame Size
This constant identifies the size of I2C frame required to read from MTCH6301 touch controller. MTCH6301 notifies the availability of input data
through interrupt pin.
Remarks
This constant should be used in place of hard-coded numeric literals. This value is derived from device-specific data sheets.
DRV_TOUCH_MTCH6301_CLIENT_OBJECT Structure
MTCH6301 Driver client object maintaining client data.
File
drv_mtch6301.h
C
typedef struct _DRV_MTCH6301_CLIENT_OBJECT {
DRV_TOUCH_MTCH6301_OBJECT* driverObject;
DRV_IO_INTENT intent;
struct DRV_TOUCH_MTCH6301_CLIENT_OBJECT* pNext;
} DRV_TOUCH_MTCH6301_CLIENT_OBJECT;
Members
Members Description
DRV_TOUCH_MTCH6301_OBJECT*
driverObject;
Driver Object associated with the client
DRV_IO_INTENT intent; The intent with which the client was opened
struct
DRV_TOUCH_MTCH6301_CLIENT_OBJECT*
pNext;
Next driver client object
Description
MTCH6301 Driver client object
This defines the object required for the maintenance of the software clients instance. This object exists once per client instance.
Remarks
None.
DRV_TOUCH_MTCH6301_INDEX_0 Macro
MTCH6301 driver index definitions.
File
drv_mtch6301.h
C
#define DRV_TOUCH_MTCH6301_INDEX_0 0
Description
MTCH6301 Driver Module Index Numbers
These constants provide the MTCH6301 driver index definitions.
Remarks
These constants should be used in place of hard-coded numeric literals. These values should be passed into the DRV_MTCH6301_Initialize and
DRV_MTCH6301_Open functions to identify the driver instance in use.
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1072
DRV_TOUCH_MTCH6301_INDEX_1 Macro
File
drv_mtch6301.h
C
#define DRV_TOUCH_MTCH6301_INDEX_1 1
Description
This is macro DRV_TOUCH_MTCH6301_INDEX_1.
DRV_TOUCH_MTCH6301_INDEX_COUNT Macro
Number of valid Touch controller MTCH6301 driver indices.
File
drv_mtch6301.h
C
#define DRV_TOUCH_MTCH6301_INDEX_COUNT 2
Description
MTCH6301 Driver Module Index Count
This constant identifies the number of valid Touch Controller MTCH6301 driver indices.
Remarks
This constant should be used in place of hard-coded numeric literals. This value is derived from device-specific header files defined as part of the
peripheral libraries.
DRV_TOUCH_MTCH6301_OBJECT Structure
Defines the data structure maintaining MTCH6301 driver instance object.
File
drv_mtch6301.h
C
typedef struct {
SYS_STATUS status;
int touchId;
SYS_MODULE_INDEX drvIndex;
bool inUse;
bool isExclusive;
uint8_t numClients;
INT_SOURCE interruptSource;
uint16_t orientation;
uint16_t horizontalResolution;
uint16_t verticalResolution;
DRV_HANDLE (* drvOpen)(const SYS_MODULE_INDEX index, const DRV_IO_INTENT intent);
int32_t readRequest;
DRV_TOUCH_MTCH6301_TASK_QUEUE* taskQueue;
DRV_HANDLE drvI2CHandle;
DRV_TOUCH_POSITION_STATUS touchStatus;
} DRV_TOUCH_MTCH6301_OBJECT;
Members
Members Description
SYS_STATUS status; The status of the driver
int touchId; The peripheral Id associated with the object
SYS_MODULE_INDEX drvIndex; Save the index of the driver. Important to know this as we are using reference based
accessing
bool inUse; Flag to indicate instance in use
bool isExclusive; Flag to indicate module used in exclusive access mode
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1073
uint8_t numClients; Number of clients possible with the hardware instance
INT_SOURCE interruptSource; Touch input interrupt source
uint16_t orientation; Orientation of the display (given in degrees of 0,90,180,270)
uint16_t horizontalResolution; Horizontal Resolution of the displayed orientation in Pixels
uint16_t verticalResolution; Vertical Resolution of the displayed orientaion in Pixels
DRV_HANDLE (* drvOpen)(const
SYS_MODULE_INDEX index, const
DRV_IO_INTENT intent);
Callback for I2C Driver Open call
int32_t readRequest; Touch Input read request counter
DRV_TOUCH_MTCH6301_TASK_QUEUE*
taskQueue;
Head of the task queue
DRV_HANDLE drvI2CHandle; I2C bus driver handle
DRV_TOUCH_POSITION_STATUS touchStatus; Touch status
Description
MTCH6301 Driver Instance Object.
This data structure maintains the MTCH6301 driver instance object. The object exists once per hardware instance.
Remarks
None.
DRV_TOUCH_MTCH6301_TASK_QUEUE Structure
Defines the MTCH6301 Touch Controller driver task data structure.
File
drv_mtch6301.h
C
typedef struct {
bool inUse;
DRV_TOUCH_MTCH6301_TASK_STATE taskState;
DRV_I2C_BUFFER_HANDLE drvI2CReadBufferHandle;
uint8_t drvI2CReadFrameData[DRV_TOUCH_MTCH6301_I2C_READ_FRAME_SIZE];
} DRV_TOUCH_MTCH6301_TASK_QUEUE;
Members
Members Description
bool inUse; Flag denoting the allocation of task
DRV_TOUCH_MTCH6301_TASK_STATE taskState; Enum maintaining the task state
DRV_I2C_BUFFER_HANDLE drvI2CReadBufferHandle; I2C Buffer handle
uint8_t
drvI2CReadFrameData[DRV_TOUCH_MTCH6301_I2C_READ_FRAME_SIZE];
Response to Read Touch Input Command
• Response = { MTCH6301 Read Address,
• Input Data Size,
• Touch Id, Pen status,
• Touch X coordinate (0 to 6),
• Touch X coordinate (7 to 11),
• Touch Y coordinate (0 to 6),
• Touch Y coordinate (7 to 11) }
Description
MTCH6301 Touch Controller driver task data structure.
This data type defines the data structure maintaing task context in the task queue. The inUse flag denotes the task context allocation for a task.
The enum variable taskState maintains the current task state. The I2C buffer handle drvI2CReadBufferHandle maintains the I2C driver buffer
handle returned by the I2C driver read request. The byte array variable drvI2CReadFrameData maintains the I2C frame data sent by MTCH6301
after a successful read request.
Remarks
None.
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1074
DRV_TOUCH_MTCH6301_TASK_STATE Enumeration
Enumeration defining MTCH6301 touch controller driver task state.
File
drv_mtch6301.h
C
typedef enum {
DRV_TOUCH_MTCH6301_TASK_STATE_INIT = 0,
DRV_TOUCH_MTCH6301_TASK_STATE_READ_INPUT,
DRV_TOUCH_MTCH6301_TASK_STATE_DECODE_INPUT,
DRV_TOUCH_MTCH6301_TASK_STATE_DONE
} DRV_TOUCH_MTCH6301_TASK_STATE;
Members
Members Description
DRV_TOUCH_MTCH6301_TASK_STATE_INIT = 0 Task initialize state
DRV_TOUCH_MTCH6301_TASK_STATE_READ_INPUT Task read touch input request state
DRV_TOUCH_MTCH6301_TASK_STATE_DECODE_INPUT Task touch input decode state
DRV_TOUCH_MTCH6301_TASK_STATE_DONE Task complete state
Description
MTCH6301 Touch Controller Driver Task State
This enumeration defines the MTCH6301 touch controller driver task state. The task state helps to synchronize the operations of initialization the
the task, adding the read input task to the task queue once the touch controller notifies the available touch input and a decoding the touch input
received.
Remarks
None.
DRV_TOUCH_MTCH6301_I2C_MASTER_READ_ID Macro
MTCH6301 input read, I2C address from where master reads touch input data.
File
drv_mtch6301.h
C
#define DRV_TOUCH_MTCH6301_I2C_MASTER_READ_ID 0x4B
Description
MTCH6301 Driver Module Master Input Read I2C address
This constant defines the MTCH6301 touch input read I2C address. This address is used as I2C address to read Touch input from MTCH6301
Touch controller.
Remarks
This constant should be used in place of hard-coded numeric literals.
This value is derived from device-specific data sheets.
DRV_TOUCH_MTCH6301_I2C_MASTER_WRITE_ID Macro
MTCH6301 command register write, I2C address where master sends the commands.
File
drv_mtch6301.h
C
#define DRV_TOUCH_MTCH6301_I2C_MASTER_WRITE_ID 0x4A
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1075
Description
MTCH6301 Driver Module Master Command Write I2C Address
This constant defines the MTCH6301 command register I2C write address. This address is used as I2C address to write commands into
MTCH6301 Touch controller register.
Remarks
This constant should be used in place of hard-coded numeric literals. This value is derived from device-specific data sheets.
Files
Files
Name Description
drv_mtch6301.h Touch controller MTCH6301 Driver interface header file.
drv_mtch6301_config_template.h MTCH6301 Touch Driver configuration template.
Description
This section lists the source and header files used by the MTCH6301 Touch Driver Library.
drv_mtch6301.h
Touch controller MTCH6301 Driver interface header file.
Enumerations
Name Description
DRV_TOUCH_MTCH6301_MODULE_ID Number of valid MTCH6301 driver indices.
DRV_TOUCH_MTCH6301_TASK_STATE Enumeration defining MTCH6301 touch controller driver task state.
Functions
Name Description
DRV_TOUCH_MTCH6301_Close Closes an opened instance of the MTCH6301 driver.
Implementation: Dynamic
DRV_TOUCH_MTCH6301_Deinitialize Deinitializes the specified instance of the MTCH6301 driver module.
Implementation: Dynamic
DRV_TOUCH_MTCH6301_Initialize Initializes the MTCH6301 instance for the specified driver index.
Implementation: Dynamic
DRV_TOUCH_MTCH6301_Open Opens the specified MTCH6301 driver instance and returns a handle to it.
Implementation: Dynamic
DRV_TOUCH_MTCH6301_ReadRequest Sends a read request to I2C bus driver and adds the read task to queue.
Implementation: Dynamic
DRV_TOUCH_MTCH6301_Status Provides the current status of the MTCH6301 driver module.
Implementation: Dynamic
DRV_TOUCH_MTCH6301_Tasks Maintains the driver's state machine and implements its task queue processing.
Implementation: Dynamic
DRV_TOUCH_MTCH6301_TouchDataRead Notifies the driver that the current touch data has been read
DRV_TOUCH_MTCH6301_TouchGetX Returns the x coordinate of touch input.
Implementation: Dynamic
DRV_TOUCH_MTCH6301_TouchGetY Returns the y coordinate of touch input.
Implementation: Dynamic
DRV_TOUCH_MTCH6301_TouchStatus Returns the status of the current touch input.
Macros
Name Description
DRV_TOUCH_MTCH6301_HANDLE_INVALID Definition of an invalid handle.
DRV_TOUCH_MTCH6301_I2C_MASTER_READ_ID MTCH6301 input read, I2C address from where master reads touch input
data.
DRV_TOUCH_MTCH6301_I2C_MASTER_WRITE_ID MTCH6301 command register write, I2C address where master sends the
commands.
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1076
DRV_TOUCH_MTCH6301_I2C_READ_FRAME_SIZE I2C Frame size for reading MTCH6301 touch input.
DRV_TOUCH_MTCH6301_INDEX_0 MTCH6301 driver index definitions.
DRV_TOUCH_MTCH6301_INDEX_1 This is macro DRV_TOUCH_MTCH6301_INDEX_1.
DRV_TOUCH_MTCH6301_INDEX_COUNT Number of valid Touch controller MTCH6301 driver indices.
Structures
Name Description
_DRV_MTCH6301_CLIENT_OBJECT MTCH6301 Driver client object maintaining client data.
DRV_TOUCH_MTCH6301_CLIENT_OBJECT MTCH6301 Driver client object maintaining client data.
DRV_TOUCH_MTCH6301_OBJECT Defines the data structure maintaining MTCH6301 driver instance object.
DRV_TOUCH_MTCH6301_TASK_QUEUE Defines the MTCH6301 Touch Controller driver task data structure.
Types
Name Description
DRV_TOUCH_MTCH6301_HANDLE Touch screen controller MTCH6301 driver handle.
Description
Touch Controller MTCH6301 Driver Interface File
This header file describes the macros, data structure and prototypes of the touch controller MTCH6301 driver interface.
File Name
drv_mtch6301.c
drv_mtch6301_config_template.h
MTCH6301 Touch Driver configuration template.
Macros
Name Description
DRV_MTCH6301_CALIBRATION_DELAY Defines the calibration delay.
DRV_MTCH6301_CALIBRATION_INSET Defines the calibration inset.
DRV_MTCH6301_CLIENTS_NUMBER Selects the maximum number of clients.
DRV_MTCH6301_INDEX MTCH6301 static index selection.
DRV_MTCH6301_INSTANCES_NUMBER Sets up the maximum number of hardware instances that can be supported.
DRV_MTCH6301_INTERRUPT_MODE Controls operation of the driver in the interrupt or polled mode.
DRV_MTCH6301_SAMPLE_POINTS Define the sample points.
DRV_MTCH6301_TOUCH_DIAMETER Defines the touch diameter.
Description
MTCH6301 Touch Driver Configuration Template
This header file contains the build-time configuration selections for the MTCH6301 Touch Driver. This is the template file which give all possible
configurations that can be made. This file should not be included in any project.
File Name
drv_mtch6301_config_template.h
Company
Microchip Technology Inc.
MTCH6303 Touch Driver Library
This topic describes the MTCH6303 Touch Driver Library.
Introduction
This library provides an interface to manage the MTCH6303 Touch Driver module on the Microchip family of microcontrollers in different modes of
operation.
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1077
Description
The MPLAB Harmony MTCH6303 Touch Driver provides a high-level interface to the MTCH6303 touch controller device. This driver provides
application routines to read the touch input data from the touch screen. The MTCH6303 device can notify the availability of touch input data
through external interrupt. The MTCH6303 driver allows the application to map a controller pin as an external interrupt pin.
Currently, the MTCH6303 Touch Driver only supports non-gestural single-finger touch screen input.
Using the Library
This topic describes the basic architecture of the MTCH6303 Touch Driver Library and provides information and examples on its use.
Description
Interface Header File: drv_mtch6303_static.h
The interface to the MTCH6303 Touch Driver Library is defined in the drv_mtch6303_static.h header file. This file is generated by the
MPLAB Harmony Configurator (MHC) during application code generation. It is included in system_definitions.h by MHC during application
code generation. Any configuration macros required for MTCH6303 Driver are included in system_config.h by MHC during code generation.
Any C language source (.c) file that uses the MTCH6303 Touch Driver Library should include system_config.h and
system_definitions.h, respectively.
Please refer to the What is MPLAB Harmony? section for how the driver interacts with the framework.
Abstraction Model
This library provides a low-level abstraction of the MTCH6303 Touch Driver Library on the Microchip family microcontrollers with a convenient C
language interface. This topic describes how that abstraction is modeled in software and introduces the library's interface.
Description
The MTCH6303 Touch Driver has routines to perform the following operations:
• MTCH6303 register read and write
• MTCh6303 message read and write
• MTCH6303 touch input read
• Mapping of the touch input to screen resolution
The driver Initialization routine allows the application to initialize the driver. The driver must be initialized before it can be used by the application.
Once the driver is initialized, the driver Open function allows retrieval of the client handle. If the client handle is valid, an event handler routine
needs to be registered by the application. The MTCH6303 Touch Driver triggers an interrupt once touch input is available to be read from the
MTCH6303 registers. A touch input Read function is called from the interrupt handler to initiate the touch input read task. An Event Handler
function is called once the touch input read task is completed. A valid touch input will be available only after the event handler routine is triggered.
The touch input must be read inside of the event handler function.
The touch input data is a raw value and needs to be mapped to the target screen resolution. At zero degree orientation, touch input is mapped on
the x axis from zero at the left and the maximum value at the right. At zero degree orientation, touch input is mapped on the y axis from zero at the
top and the maximum value at the bottom.
MTCH6303 Driver Abstraction Model
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1078
Library Overview
Refer to the Driver Library Overview section for information on how the driver operates in a system.
The library interface routines are divided into various sub-sections, which address one of the blocks or the overall operation of the MTCH6303
Touch Driver.
Library Interface Section Description
System Functions Provides system module interfaces, device initialization, deinitialization,
reinitialization, tasks, and status functions.
Client Setup Functions Provides open, close, status, and other setup function.
Read and Write Functions Provides functions to read and write to the MTCH6303 registers, messages, and
touch data.
Miscellaneous Functions Provides miscellaneous functions.
How the Library Works
The library provides interfaces to support:
• System functions, which provide system module interfaces, device initialization, deinitialization, task, and status functions
• Client setup functions, which provide client interfaces such as open, close and event handler registration
• Read and write functions, initiate the touch input or register or message read and write tasks
• Miscellaneous functions such as touch input map function are provided to process the raw touch input data
Configuring the Library
The configuration of the MTCH6303 Touch Driver is based on the file system_config.h.
This header file contains the configuration selection for the MTCH6303 Touch Driver. Based on the selections made, the driver may support the
selected features. These configuration settings will apply to all instances of the MTCH6303 Touch Driver.
This header can be placed anywhere, the path of this header needs to be present in the include search path for a successful build. Refer to the
Applications Help section for more details.
Building the Library
This section lists the files that are available in the MTCH6303 Touch Driver Library.
Description
This section list the files that are available in the /src folder of the MTCH6303 Touch Driver. It lists which files need to be included in the build
based on either a hardware feature present on the board or configuration option selected by the system.
The following three tables list and describe the header (.h) and source (.c) files that implement this library. The parent folder for these files is
/framework/driver/touch/mtch6303.
Interface File(s)
This table lists and describes the header files that must be included (i.e., using #include) by any code that uses this library.
Source File Name Description
/drv_mtch6303_static.h Header file that exports the driver API.
Required File(s)
All of the required files listed in the following table are automatically added into the MPLAB X IDE project by the MHC
when the library is selected for use.
This table lists and describes the source and header files that must always be included in the MPLAB X IDE project to build this library.
Source File Name Description
/src/drv_mtch6303_static.c Basic MTCH6303 Touch Driver implementation file.
/src/drv_mtch6303_buffer_queue_i2c_static.c MTCH6303 I2C buffer queue implementation file.
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1079
Optional File(s)
This table lists and describes the source and header files that may optionally be included if required for the desired implementation.
Source File Name Description
/drv_mtch6303_buffer_queue_touch_static.c MTCH6303 message buffer queue implementation file.
Module Dependencies
The MTCH6303 Touch Driver Library depends on the following modules:
• Interrupt System Service Library
• Ports System Service Library
• I2C Driver Library
Library Interface
a) System Functions
Name Description
DRV_MTCH6303_Deinitialize Deinitializes the instance of the MTCH6303 driver module.
DRV_MTCH6303_Initialize Initializes the MTCH6303 static single instance.
DRV_MTCH6303_Status Gets the current status of the MTCH6303 driver module.
DRV_MTCH6303_Tasks Maintains the driver's register read/write state machine and implements its ISR.
b) Client Setup Functions
Name Description
DRV_MTCH6303_Close Closes an opened-instance of the MTCH6303 driver.
DRV_MTCH6303_ErrorGet This function returns the error associated with the last client request.
DRV_MTCH6303_Open Opens the MTCH6303 driver instance and returns a handle to it.
c) Read and Write Functions
Name Description
DRV_MTCH6303_AddRegisterRead Schedules a non-blocking register read request to read I2C accessible
MTCH6303 registers.
DRV_MTCH6303_AddRegisterWrite Schedule a non-blocking driver register write operation to write I2C
accessible MTCH6303 registers.
DRV_MTCH6303_TOUCH_AddMessageCommandWrite Schedule a non-blocking driver command message write operation to
write command message to MTCH6303 registers.
DRV_MTCH6303_TOUCH_AddMessageReportRead Schedules a non-blocking report message read request to read the
report message from MTCH6303 device.
DRV_MTCH6303_TOUCH_AddTouchInputRead Schedules a non-blocking read buffer request to read touch input from
MTCH6303.
DRV_MTCH6303_TOUCH_BufferEventHandlerSet Allows a client to identify a buffer event handling function for the driver to
call back when queued message transfers have finished.
DRV_MTCH6303_TOUCH_Tasks Maintains the driver's message state machine and implements its ISR.
DRV_MTCH6303_TouchInputMap Maps the raw touch input to display resolution.
DRV_MTCH6303_TouchInputRead Schedules a non-blocking read buffer request to read touch input from
MTCH6303.
DRV_MTCH6303_BufferEventHandlerSet Allows a client to identify a buffer event handling function for the driver to
call back when queued buffer transfers have finished.
d) Data Types and Constants
Name Description
DRV_MTCH6303_BUFFER_HANDLE_INVALID Definition of an invalid buffer handle.
DRV_MTCH6303_TOUCH_BUFFER_HANDLE_INVALID Definition of an invalid buffer handle.
DRV_MTCH6303_TOUCH_NUM_INPUTS Definition of number of touch input packets can be identified by
MTCH6303.
DRV_MTCH6303_BUFFER_EVENT Lists the different conditions that happens during a buffer transfer.
DRV_MTCH6303_BUFFER_EVENT_HANDLER Points to a callback after completion of an register read -write or
message stream read - write.
DRV_MTCH6303_BUFFER_HANDLE Handle identifying a read or write buffer passed to the driver.
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1080
DRV_MTCH6303_CLIENT_STATUS Defines the client-specific status of the MTCH6303 driver.
DRV_MTCH6303_ERROR Defines the possible errors that can occur during driver operation.
DRV_MTCH6303_TOUCH_BUFFER_EVENT Lists the different conditions that happens during a touch message
buffer transfer.
DRV_MTCH6303_TOUCH_BUFFER_EVENT_HANDLER Points to a callback after completion of an message report read or
message command write.
DRV_MTCH6303_TOUCH_BUFFER_HANDLE Handle identifying a read or write touch message buffer passed to the
driver.
DRV_MTCH6303_TOUCH_DATA Defines MTCH6303 I2C Touch Data
DRV_MTCH6303_TOUCH_INPUT Defines MTCH6303 Touch Input Packet
DRV_MTCH6303_TOUCH_MESSAGE Defines MTCH6303 Touch Message.
DRV_MTCH6303_TOUCH_MESSAGE_HEADER Defines Touch Message Header.
DRV_MTCH6303_TOUCH_NIBBLE_0 Defines the I2C Nibble 0 of MTCH6303 Touch input packet.
DRV_MTCH6303_TOUCH_STATUS Defines the I2C touch status register bits
DRV_TOUCH_MTCH6303_MSG_ID List of report or command message identification.
DRV_TOUCH_MTCH6303_I2C_REGISTER_MAP List of MTCH6303 I2C Accessible Register Identification.
Description
This section describes the API functions of the MTCH6303 Touch Driver library.
Refer to each section for a detailed description.
a) System Functions
DRV_MTCH6303_Deinitialize Function
Deinitializes the instance of the MTCH6303 driver module.
File
drv_mtch6303.h
C
void DRV_MTCH6303_Deinitialize();
Returns
None.
Description
Deinitializes the instance of the MTCH6303 driver module, disabling its operation. Invalidates all the internal data.
Remarks
once the initialize operation has been called, the Deinitialize operation must be called before the Initialize operation can be called again. this
routine will NEVER block waiting for hardware.
Preconditions
Function DRV_MTCH6303_Initialize should have been called before calling this function.
Example
SYS_STATUS status;
DRV_MTCH6303_Deinitialize();
status = DRV_MTCH6303_Status();
if(SYS_MODULE_DEINITIALIZED != status)
{
//check again later if you need to know
//when the driver is deinitialized
}
Function
void DRV_MTCH6303_Deinitialize( void )
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1081
DRV_MTCH6303_Initialize Function
Initializes the MTCH6303 static single instance.
File
drv_mtch6303.h
C
SYS_MODULE_OBJ DRV_MTCH6303_Initialize();
Returns
If successful, returns a valid handle to a driver instance object. Otherwise, returns SYS_MODULE_OBJ_INVALID.
Description
This routine initializes the MTCH6303 static driver instance. It makes the instance ready for a client to open and use it. The instance parameters
are initialized by values set by MPLAB Harmony Configurator.
Preconditions
None.
Example
// The following code snippet shows an example MTCH6303 driver initialization.
SYS_MODULE_OBJ objectHandle;
objectHandle = DRV_MTCH6303_Initialize();
if( SYS_MODULE_OBJ_INVALID == objectHandle )
{
// Handle error
}
Remarks: This routine must be called before any other MTCH6303 routine is called.
This routine should only be called once during system initialization unless
DRV_MTCH6303_Deinitialize is called to deinitialize the driver instance.
This routine will NEVER block for hardware access.
Function
SYS_MODULE_OBJ DRV_MTCH6303_Initialize ( void )
DRV_MTCH6303_Status Function
Gets the current status of the MTCH6303 driver module.
File
drv_mtch6303.h
C
SYS_STATUS DRV_MTCH6303_Status();
Returns
SYS_STATUS_READY - Indicates that the driver is busy with a previous system level operation and cannot start another.
SYS_STATUS_DEINITIALIZED - Indicates that the driver has been deinitialized.
Description
This routine provides the current status of the MTCH6303 driver module.
Remarks
A driver can opened only when its status is SYS_STATUS_READY.
Preconditions
Function DRV_MTCH6303_Initialize should have been called before calling this function.
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1082
Example
SYS_STATUS mtch6303Status;
mtch6303Status = DRV_MTCH6303_Status();
if(SYS_STATUS_READY == mtch6303Status)
{
// This means the driver can be opened using the
// DRV_MTCH6303_Open() function.
}
Function
SYS_STATUS DRV_MTCH6303_Status( void )
DRV_MTCH6303_Tasks Function
Maintains the driver's register read/write state machine and implements its ISR.
File
drv_mtch6303.h
C
void DRV_MTCH6303_Tasks();
Returns
None.
Description
This routine is used to maintain the driver's register read/write state machine and implement its ISR for interrupt-driven implementations. In
interrupt mode, this function is called in I2C Driver event Handler routine. The I2C Driver event Handler routine is registered by MTCH6303 event
Handler register routine.
Remarks
This routine may execute in an ISR context and will never block or access any resources that may cause it to block.
Preconditions
Function DRV_MTCH6303_Initialize should have been called before calling this function. It also needs registration of the MTCH6303 Driver event
handler routine.
Function
void DRV_MTCH6303_Tasks( void )
b) Client Setup Functions
DRV_MTCH6303_Close Function
Closes an opened-instance of the MTCH6303 driver.
File
drv_mtch6303.h
C
DRV_MTCH6303_CLIENT_STATUS DRV_MTCH6303_Close();
Returns
DRV_MTCH6303_CLIENT_STATUS_ERROR - if driver fails to remove buffer objects from queue.
DRV_MTCHC6303_CLIENT_STATUS_CLOSED - client is successfully closed
Description
This routine closes an opened-instance of the MTCH6303 driver. Any buffers in the driver queue that were submitted by this client will be removed.
DRV_MTCH6303_Open must be called to before using the driver again.
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1083
Remarks
The driver will abort any ongoing operations when this routine is called.
Preconditions
The DRV_MTCH6303_Initialize routine must have been called. DRV_MTCH6303_Open must have been called.
Example
DRV_MTH6303_CLIENT_STATUS mtch6303Status;
mtch6303Status = DRV_MTCH6303_Close()
if( DRV_MTCH6303_CLIENT_STATUS_ERROR == mtch6303Status )
{
//retry closing the driver client
}
Function
DRV_MTCH6303_CLIENT_STATUS DRV_MTCH6303_Close ( void )
DRV_MTCH6303_ErrorGet Function
This function returns the error associated with the last client request.
File
drv_mtch6303.h
C
DRV_MTCH6303_ERROR DRV_MTCH6303_ErrorGet();
Returns
DRV_MTCH6303_ERROR_NONE - no error
Description
This function returns the error associated with the last client request.
Remarks
This routine always return DRV_MTCH6303_ERROR_NONE the client error is currently not updated by any of the MTCH6303 operations API's.
Preconditions
The DRV_MTCH6303_Initialize routine must have been called. DRV_MTCH6303_Open must have been called to open a device client.
Function
DRV_MTCH6303_ERROR DRV_MTCH6303_ErrorGet ( void )
DRV_MTCH6303_Open Function
Opens the MTCH6303 driver instance and returns a handle to it.
File
drv_mtch6303.h
C
DRV_HANDLE DRV_MTCH6303_Open();
Returns
If successful, the routine returns a valid open-instance handle. If an error occurs, the return value is DRV_HANDLE_INVALID. Error can occur
• if the driver is not ready to be opened, typically when the initialize routine has not completed execution.
• if the bus driver fails to open
• if the client is trying to open the driver but driver has been opened exclusively by another client.
Description
This routine opens the specified MTCH6303 driver instance and provides a handle.
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1084
Remarks
The handle returned is valid until the DRV_MTCH6303_Close routine is called. This routine will NEVER block waiting for hardware.If the requested
intent flags are not supported, the routine will return DRV_HANDLE_INVALID. This function is thread safe in a RTOS application.
Preconditions
Function DRV_MTCH6303_Initialize must have been called before calling this function.
Example
DRV_HANDLE handle;
handle = DRV_MTCH6303_Open( );
if (DRV_HANDLE_INVALID == handle)
{
// Unable to open the driver
// May be the driver is not initialized or the initialization
// is not complete.
}
Function
DRV_HANDLE DRV_MTCH6303_Open { void }
c) Read and Write Functions
DRV_MTCH6303_AddRegisterRead Function
Schedules a non-blocking register read request to read I2C accessible MTCH6303 registers.
File
drv_mtch6303.h
C
void DRV_MTCH6303_AddRegisterRead(DRV_MTCH6303_BUFFER_HANDLE * bufferHandle, uint8_t source, size_t nBytes,
uint8_t * destination);
Returns
None.
Description
This function schedules a non-blocking register read request to read I2C accessible MTCH6303 registers. The function returns with a valid buffer
handle in the bufferHandle argument if the register read request was scheduled successfully. The function adds the request to the hardware
instance queue and returns immediately. The function returns DRV_MTCH6303_BUFFER_HANDLE_INVALID in the bufferHandle argument:
• if a buffer could not be allocated to the request
• if the input buffer pointer is NULL
• if the buffer size is 0
• if the read queue size is full or queue depth is insufficient.
• if the driver handle is invalid
If the requesting client registered an event callback with the driver, the driver will issue a DRV_MTCH6303_BUFFER_EVENT_COMPLETE event
if the buffer was processed successfully or DRV_MTCH6303_BUFFER_EVENT_ERROR event if the buffer was not processed successfully. The
register data is collected into destination and can be read once a buffer event complete is reported. A event handler is called on buffer event
complete where the register data must be read from destination.
Preconditions
The DRV_MTCH6303_Initialize routine must have been called and the DRV_MTCH6303_Status must have returned SYS_STATUS_READY.
DRV_MTCH6303_Open must have been called to obtain a valid opened device handle.
Example
MY_APP_OBJ myAppObj;
uint8_t registerData[NUM_REGISTERS];
DRV_MTCH6303_BUFFER_HANDLE bufferHandle;
// Client registers an event handler with driver
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1085
DRV_MTCH6303_BufferEventHandlerSet( APP_MTCH6303BufferEventHandler,
(uintptr_t)&myAppObj);
DRV_MTCH6303_AddRegisterRead( &bufferHandle,
DRV_MTCH6303_REG_TOUCH_STATUS,
NUM_REGISTERS,
®isterData );
if(DRV_MTCH6303_BUFFER_HANDLE_INVALID == bufferHandle)
{
// Error handling here
}
// Event is received when
// the buffer is processed.
void APP_MTCH6303BufferEventHandler( DRV_MTCH6303_BUFFER_EVENT event,
DRV_MTCH6303_BUFFER_HANDLE bufferHandle,
uintptr_t contextHandle )
{
// contextHandle points to myAppObj.
switch(event)
{
case DRV_MTCH6303_BUFFER_EVENT_COMPLETE:
// This means the data was transferred.
break;
case DRV_MTCH6303_BUFFER_EVENT_ERROR:
// Error handling here.
break;
default:
break;
}
}
Remarks: None.
Parameters
Parameters Description
bufferHandle Handle to the buffer scheduled.
source Register index.
nBytes Number of registers to be read, starting from source.
destination buffer collecting register data.
Function
void DRV_MTCH6303_AddRegisterRead( DRV_MTCH6303_BUFFER_HANDLE * bufferHandle,
uint8_t source,
size_t nBytes,
uint8_t * destination )
DRV_MTCH6303_AddRegisterWrite Function
Schedule a non-blocking driver register write operation to write I2C accessible MTCH6303 registers.
File
drv_mtch6303.h
C
void DRV_MTCH6303_AddRegisterWrite(DRV_MTCH6303_BUFFER_HANDLE * bufferHandle, uint8_t destination, size_t
nBytes, uint8_t * source);
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1086
Returns
None.
Description
This function schedules a non-blocking register write request to write I2C accessible MTCH6303 registers. The function returns with a valid buffer
handle in the bufferHandle argument if the register write request was scheduled successfully. The function adds the request to the hardware
instance queue and returns immediately. While the request is in the queue, the application buffer is owned by the driver and should not be
modified. The function returns DRV_MTCH6303_BUFFER_HANDLE_INVALID in the bufferHandle argument:
• if a buffer could not be allocated to the request
• if the input buffer pointer is NULL
• if the buffer size is 0
• if the write queue size is full or queue depth is insufficient.
• if the driver handle is invalid
If the requesting client registered an event callback with the driver, the driver will issue a DRV_MTCH6303_BUFFER_EVENT_COMPLETE event
if the buffer was processed successfully or DRV_MTCH6303_BUFFER_EVENT_ERROR event if the buffer was not processed successfully. A
event handler is called on buffer event complete where the application data is written to the I2C accessible MTCH6303 Register.
Remarks
None.
Preconditions
The DRV_MTCH6303_Initialize routine must have been called and the DRV_MTCH6303_Status must have returned SYS_STATUS_READY.
DRV_MTCH6303_Open must have been called to obtain a valid opened device handle.
Example
MY_APP_OBJ myAppObj;
uint8_t registerData[NUM_REGISTERS];
DRV_MTCH6303_BUFFER_HANDLE bufferHandle;
// Client registers an event handler with driver
DRV_MTCH6303_BufferEventHandlerSet( APP_MTCH6303BufferEventHandler,
(uintptr_t)&myAppObj);
DRV_MTCH6303_AddRegisterWrite( &bufferHandle,
DRV_MTCH6303_REG_TOUCH_STATUS,
NUM_REGISTERS,
®isterData );
if(DRV_MTCH6303_BUFFER_HANDLE_INVALID == bufferHandle)
{
// Error handling here
}
// Event is received when
// the buffer is processed.
void APP_MTCH6303BufferEventHandler( DRV_MTCH6303_BUFFER_EVENT event,
DRV_MTCH6303_BUFFER_HANDLE bufferHandle,
uintptr_t contextHandle )
{
// contextHandle points to myAppObj.
switch(event)
{
case DRV_MTCH6303_BUFFER_EVENT_COMPLETE:
// This means the data was transferred.
break;
case DRV_MTCH6303_BUFFER_EVENT_ERROR:
// Error handling here.
break;
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1087
default:
break;
}
}
Parameters
Parameters Description
bufferHandle Pointer to an argument that will contain the return buffer handle.
destination Index to the start of destination register list.
nBytes number of registers.
source pointer to the data to be written to the register.
Function
void DRV_MTCH6303_AddRegisterWrite( DRV_MTCH6303_BUFFER_HANDLE * bufferHandle,
uint8_t destination,
size_t nBytes,
uint8_t * source )
DRV_MTCH6303_TOUCH_AddMessageCommandWrite Function
Schedule a non-blocking driver command message write operation to write command message to MTCH6303 registers.
File
drv_mtch6303.h
C
void DRV_MTCH6303_TOUCH_AddMessageCommandWrite(DRV_MTCH6303_TOUCH_BUFFER_HANDLE * bufferHandle,
DRV_MTCH6303_TOUCH_MESSAGE * messageCmd, size_t messageSize);
Returns
None.
Description
This function schedules a non-blocking command message write request to write command message to MTCH6303. The function returns with a
valid buffer handle in the bufferHandle argument if the register command message write request was scheduled successfully. The function adds
the request to the hardware instance queue and returns immediately. While the request is in the queue, the application message buffer is owned
by the driver and should not be modified. The function returns DRV_MTCH6303_TOUCH_BUFFER_HANDLE_INVALID in the bufferHandle
argument:
• if a buffer could not be allocated to the request
• if the input buffer pointer is NULL
• if the buffer size is 0
• if the message write queue size is full or queue depth is insufficient.
• if the driver handle is invalid
If the requesting client registered an event callback with the driver, the driver will issue a
DRV_MTCH6303_TOUCH_BUFFER_EVENT_COMPLETE event if the buffer was processed successfully or
DRV_MTCH6303_TOUCH_BUFFER_EVENT_ERROR event if the buffer was not processed successfully. A event handler is called on buffer
event complete where the application command message is written to MTCH6303.
Remarks
None.
Preconditions
The DRV_MTCH6303_Initialize routine must have been called and the DRV_MTCH6303_Status must have returned SYS_STATUS_READY.
DRV_MTCH6303_Open must have been called to obtain a valid opened device handle.
Example
MY_APP_OBJ myAppObj;
DRV_MTCH6303_TOUCH_MESSAGE messageCommand;
DRV_MTCH6303_TOUCH_BUFFER_HANDLE bufferHandle;
// Client registers an event handler with driver
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1088
DRV_MTCH6303_TOUCH_BufferEventHandlerSet( APP_MTCH6303BufferEventHandler,
(uintptr_t)&myAppObj);
DRV_MTCH6303_TOUCH_AddMessageCommandWrite( &bufferHandle,
&messageCommand,
MY_MESSAGE_SIZE );
if(DRV_MTCH6303_TOUCH_BUFFER_HANDLE_INVALID == bufferHandle)
{
// Error handling here
}
// Event is received when
// the buffer is processed.
void APP_MTCH6303BufferEventHandler( DRV_MTCH6303_TOUCH_BUFFER_EVENT event,
DRV_MTCH6303_TOUCH_BUFFER_HANDLE bufferHandle,
uintptr_t contextHandle )
{
// contextHandle points to myAppObj.
switch(event)
{
case DRV_MTCH6303_TOUCH_BUFFER_EVENT_COMPLETE:
// This means the data was transferred.
break;
case DRV_MTCH6303_TOUCH_BUFFER_EVENT_ERROR:
// Error handling here.
break;
default:
break;
}
}
Parameters
Parameters Description
bufferHandle Pointer to an argument that will contain the return buffer handle.
messageCmd command message to write to MTCH6303.
messageSize command message size. It includes message header and payload size.
Function
void DRV_MTCH6303_TOUCH_AddMessageCommandWrite
( DRV_MTCH6303_TOUCH_BUFFER_HANDLE * bufferHandle,
DRV_MTCH6303_TOUCH_MESSAGE * messageCmd,
size_t messageSize )
DRV_MTCH6303_TOUCH_AddMessageReportRead Function
Schedules a non-blocking report message read request to read the report message from MTCH6303 device.
File
drv_mtch6303.h
C
void DRV_MTCH6303_TOUCH_AddMessageReportRead(DRV_MTCH6303_TOUCH_BUFFER_HANDLE * bufferHandle,
DRV_MTCH6303_TOUCH_MESSAGE * messageRep, size_t messageSize);
Returns
None.
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1089
Description
This function schedules a non-blocking report message read request to read the report message from MTCH6303 device. The function returns
with a valid buffer handle in the bufferHandle argument if the register read request was scheduled successfully. The function adds the request to
the hardware instance queue and returns immediately. The function returns DRV_MTCH6303_TOUCH_BUFFER_HANDLE_INVALID in the
bufferHandle argument:
• if a buffer could not be allocated to the request
• if the input buffer pointer is NULL
• if the buffer size is 0
• if the read queue size is full or queue depth is insufficient.
• if the driver handle is invalid
If the requesting client registered an event callback with the driver, the driver will issue a
DRV_MTCH6303_TOUCH_BUFFER_EVENT_COMPLETE event if the buffer was processed successfully or
DRV_MTCH6303_TOUCH_BUFFER_EVENT_ERROR event if the buffer was not processed successfully. The register data is collected into
destination and can be read once a buffer event complete is reported. A event handler is called on buffer event complete where the register data
must be read from destination.
Remarks
None.
Preconditions
The DRV_MTCH6303_Initialize routine must have been called and the DRV_MTCH6303_Status must have returned SYS_STATUS_READY.
DRV_MTCH6303_Open must have been called to obtain a valid opened device handle.
Example
MY_APP_OBJ myAppObj;
DRV_MTCH6303_TOUCH_MESSAGE messageReport;
DRV_MTCH6303_TOUCH_BUFFER_HANDLE bufferHandle;
// Client registers an event handler with driver
DRV_MTCH6303_TOUCH_BufferEventHandlerSet( APP_MTCH6303BufferEventHandler,
(uintptr_t)&myAppObj);
DRV_MTCH6303_TOUCH_AddMessageReportRead( &bufferHandle,
&messageReport,
MY_MESSAGE_SIZE );
if(DRV_MTCH6303_TOUCH_BUFFER_HANDLE_INVALID == bufferHandle)
{
// Error handling here
}
// Event is received when
// the buffer is processed.
void APP_MTCH6303BufferEventHandler( DRV_MTCH6303_TOUCH_BUFFER_EVENT event,
DRV_MTCH6303_TOUCH_BUFFER_HANDLE bufferHandle,
uintptr_t contextHandle )
{
// contextHandle points to myAppObj.
switch(event)
{
case DRV_MTCH6303_TOUCH_BUFFER_EVENT_COMPLETE:
// This means the data was transferred.
break;
case DRV_MTCH6303_TOUCH_BUFFER_EVENT_ERROR:
// Error handling here.
break;
default:
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1090
break;
}
}
Parameters
Parameters Description
bufferHandle Handle to the buffer scheduled.
messageRep report message buffer.
messageSize report message size. It includes message header and payload size.
Function
void DRV_MTCH6303_TOUCH_AddMessageReportRead
( DRV_MTCH6303_TOUCH_BUFFER_HANDLE * bufferHandle,
DRV_MTCH6303_TOUCH_MESSAGE * messageRep,
size_t messageSize )
DRV_MTCH6303_TOUCH_AddTouchInputRead Function
Schedules a non-blocking read buffer request to read touch input from MTCH6303.
File
drv_mtch6303.h
C
void DRV_MTCH6303_TOUCH_AddTouchInputRead(DRV_MTCH6303_TOUCH_BUFFER_HANDLE * bufferHandle,
DRV_MTCH6303_TOUCH_DATA * touchData);
Returns
None.
Description
This function schedules a non-blocking read buffer request to read touch input from MTCH6303. The function returns with a valid buffer handle in
the bufferHandle argument if the read request was scheduled successfully. The function adds the request to the hardware instance queue and
returns immediately. The function returns DRV_MTCH6303_TOUCH_BUFFER_HANDLE_INVALID in the bufferHandle argument:
• if a buffer could not be allocated to the request
• if the input buffer pointer is NULL
• if the buffer size is 0
• if the read queue size is full or queue depth is insufficient.
• if the driver handle is invalid
If the requesting client registered an event callback with the driver, the driver will issue a
DRV_MTCH6303_TOUCH_BUFFER_EVENT_COMPLETE event if the buffer was processed successfully or
DRV_MTCH6303_TOUCH_BUFFER_EVENT_ERROR event if the buffer was not processed successfully. The touch data is collected into
touchData and can be read once a buffer event complete is reported. A event handler is called on buffer event complete where the touch data
must be read from touchData.
Remarks
None.
Preconditions
The DRV_MTCH6303_Initialize routine must have been called and the DRV_MTCH6303_Status must have returned SYS_STATUS_READY.
DRV_MTCH6303_Open must have been called to obtain a valid opened device handle.
Example
MY_APP_OBJ myAppObj;
DRV_MTCH6303_TOUCH_DATA touchData;
DRV_MTCH6303_BUFFER_HANDLE bufferHandle;
// Client registers an event handler with driver
DRV_MTCH6303_TOUCH_BufferEventHandlerSet( APP_MTCH6303BufferEventHandler,
(uintptr_t)&myAppObj);
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1091
DRV_MTCH6303_TOUCH_AddTouchInputRead( &bufferHandle, &touchData );
if(DRV_MTCH6303_TOUCH_BUFFER_HANDLE_INVALID == bufferHandle)
{
// Error handling here
}
// Event is received when
// the buffer is processed.
void APP_MTCH6303BufferEventHandler( DRV_MTCH6303_TOUCH_BUFFER_EVENT event,
DRV_MTCH6303_TOUCH_BUFFER_HANDLE bufferHandle,
uintptr_t contextHandle )
{
// contextHandle points to myAppObj.
switch(event)
{
case DRV_MTCH6303_TOUCH_BUFFER_EVENT_COMPLETE:
// This means the data was transferred.
break;
case DRV_MTCH6303_TOUCH_BUFFER_EVENT_ERROR:
// Error handling here.
break;
default:
break;
}
}
Parameters
Parameters Description
bufferHandle Handle to the buffer scheduled.
touchData Buffer collecting touch data.
Function
void DRV_MTCH6303_TOUCH_AddTouchInputRead
( DRV_MTCH6303_TOUCH_BUFFER_HANDLE * bufferHandle,
DRV_MTCH6303_TOUCH_DATA * touchData )
DRV_MTCH6303_TOUCH_BufferEventHandlerSet Function
Allows a client to identify a buffer event handling function for the driver to call back when queued message transfers have finished.
File
drv_mtch6303.h
C
void DRV_MTCH6303_TOUCH_BufferEventHandlerSet(const DRV_MTCH6303_TOUCH_BUFFER_EVENT_HANDLER eventHandler,
const uintptr_t context);
Returns
None.
Description
This function allows a client to identify a message event handling function for the driver to call back when queued message transfers have finished.
When a client calls either the DRV_MTCH6303_TOUCH_AddTouchInputRead, DRV_MTCH6303_TOUCH_AddMessageReportRead or
DRV_MTCH6303_TOUCH_AddMessageCommandWrite function, it is provided with a handle identifying the message that was added to the
driver's message queue. The driver will pass this handle back to the client by calling "eventHandler" function when the message transfer has
completed.
The event handler should be set before the client performs any "message add" operations that could generate events. The event handler once set,
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1092
persists until the client closes the driver or sets another event handler (which could be a "NULL" pointer to indicate no callback).
Remarks
None.
Preconditions
The DRV_MTCH6303_Initialize routine must have been called and the DRV_MTCH6303_Status must have returned SYS_STATUS_READY.
Example
// myAppObj is an application specific state data object.
MY_APP_OBJ myAppObj;
DRV_MTCH6303_TOUCH_MESSAGE messageReport;
DRV_MTCH6303_TOUCH_BUFFER_HANDLE bufferHandle;
// myMTCH6303Handle is the handle returned
// by the DRV_MTCH6303_Open function.
// Client registers an event handler with driver. This is done once
DRV_MTCH6303_TOUCH_BufferEventHandlerSet( APP_MTCH6303BufferEventHandler,
(uintptr_t)&myAppObj );
DRV_MTCH6303_TOUCH_AddMessageReportRead( &bufferHandle, &messageReport );
if(DRV_MTCH6303_TOUCH_BUFFER_HANDLE_INVALID == bufferHandle)
{
// Error handling here
}
// Event is received when
// the buffer is processed.
void APP_MTCH6303BufferEventHandler( DRV_MTCH6303_TOUCH_BUFFER_EVENT event,
DRV_MTCH6303_TOUCH_BUFFER_HANDLE bufferHandle,
uintptr_t contextHandle )
{
// contextHandle points to myAppObj.
switch(event)
{
case DRV_MTCH6303_TOUCH_BUFFER_EVENT_COMPLETE:
// This means the data was transferred.
break;
case DRV_MTCH6303_TOUCH_BUFFER_EVENT_ERROR:
// Error handling here.
break;
default:
break;
}
}
Parameters
Parameters Description
eventHandler Pointer to the event handler function.
context The value of parameter will be passed back to the client unchanged, when the eventHandler
function is called. It can be used to identify any client specific data object that identifies the
instance of the client module (for example, it may be a pointer to the client module's state
structure).
Function
void DRV_MTCH6303_TOUCH_BufferEventHandlerSet
(
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1093
const DRV_MTCH6303_TOUCH_BUFFER_EVENT_HANDLER eventHandler,
const uintptr_t context
)
DRV_MTCH6303_TOUCH_Tasks Function
Maintains the driver's message state machine and implements its ISR.
File
drv_mtch6303.h
C
void DRV_MTCH6303_TOUCH_Tasks();
Returns
None.
Description
This routine is used to maintain the driver's message state machine and implement its ISR for interrupt-driven implementations. In interrupt mode,
this function is called in I2C Driver event Handler routine. The I2C Driver event Handler routine is registered by MTCH6303 Touch event Handler
register routine.
Remarks
This routine may execute in an ISR context and will never block or access any resources that may cause it to block.
Preconditions
Function DRV_MTCH6303_Initialize should have been called before calling this function. It also needs registration of the MTCH6303 Driver Touch
event handler routine.
Function
void DRV_MTCH6303_TOUCH_Tasks( void )
DRV_MTCH6303_TouchInputMap Function
Maps the raw touch input to display resolution.
File
drv_mtch6303.h
C
inline uint16_t DRV_MTCH6303_TouchInputMap(uint16_t touchValue, uint16_t dispResolution);
Returns
This function returns the raw touch input mapped to display resolution in form of number of pixels.
Description
This function maps the raw touch input to display resolution. Raw touch input touchValue is obtained from the individual x or y value of
DRV_MTCH6303_TOUCH_DATA. Raw touch value varies from 0 to 0x7FFF. The displayResolution is either horizontal or vertical resolution of the
display in pixels. The function returns the raw touch input mapped to display resolution in form of number of pixels.
Remarks
None.
Preconditions
None.
Example
// Display with resolution 800 x 480
#define DISP_HOR_RESOUTION 800
#define DISP_VER_RESOLUTION 480
DRV_MTCH6303_TOUCH_DATA touchData;
uint16_t rawTouchX;
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1094
uint16_t rawTouchY;
uint16_t touchX;
uint16_t touchY;
// map 0th touch packet to display resolution
rawTouchX = touchData.touch[0].x;
rawTouchY = touchData.touch[0].y;
// map raw touch input in x direction to display horizontal resolution
touchX = DRV_MTCH6303_TouchInputMap( rawTouchX, DISP_HOR_RESOLUTION );
// map raw touch input in y direction to display vertical resolution
touchY = DRV_MTCH6303_TouchInputMap( rawTouchY, DISP_VER_RESOLUTION );
// use touchX and touchY as input to graphics objects.
Parameters
Parameters Description
touchValue raw touch input either in x or y direction (0 - 0x7FFF).
dispResolution display resolution specifying either width or height of the display in pixels.
Function
uint16_t DRV_MTCH6303_TouchInputMap( uint16_t touchValue, uint16_t dispResolution )
DRV_MTCH6303_TouchInputRead Function
Schedules a non-blocking read buffer request to read touch input from MTCH6303.
File
drv_mtch6303.h
C
void DRV_MTCH6303_TouchInputRead(DRV_MTCH6303_BUFFER_HANDLE * bufferHandle, DRV_MTCH6303_TOUCH_DATA *
touchData);
Returns
None.
Description
This function schedules a non-blocking read buffer request to read touch input from MTCH6303. The function returns with a valid buffer handle in
the bufferHandle argument if the read request was scheduled successfully. The function adds the request to the hardware instance queue and
returns immediately. The function returns DRV_MTCH6303_BUFFER_HANDLE_INVALID in the bufferHandle argument:
• if a buffer could not be allocated to the request
• if the input buffer pointer is NULL
• if the buffer size is 0
• if the read queue size is full or queue depth is insufficient.
• if the driver handle is invalid
If the requesting client registered an event callback with the driver, the driver will issue a DRV_MTCH6303_BUFFER_EVENT_COMPLETE event
if the buffer was processed successfully or DRV_MTCH6303_BUFFER_EVENT_ERROR event if the buffer was not processed successfully. The
touch data is collected into touchData and can be read once a buffer event complete is reported. A event handler is called on buffer event
complete where the touch data must be read from touchData.
Remarks
None.
Preconditions
The DRV_MTCH6303_Initialize routine must have been called and the DRV_MTCH6303_Status must have returned SYS_STATUS_READY.
DRV_MTCH6303_Open must have been called to obtain a valid opened device handle.
Example
MY_APP_OBJ myAppObj;
DRV_MTCH6303_TOUCH_DATA touchData;
DRV_MTCH6303_BUFFER_HANDLE bufferHandle;
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1095
// Client registers an event handler with driver
DRV_MTCH6303_BufferEventHandlerSet( APP_MTCH6303BufferEventHandler,
(uintptr_t)&myAppObj);
DRV_MTCH6303_TouchInputRead( &bufferHandle, &touchData );
if(DRV_MTCH6303_BUFFER_HANDLE_INVALID == bufferHandle)
{
// Error handling here
}
// Event is received when
// the buffer is processed.
void APP_MTCH6303BufferEventHandler( DRV_MTCH6303_BUFFER_EVENT event,
DRV_MTCH6303_BUFFER_HANDLE bufferHandle,
uintptr_t contextHandle )
{
// contextHandle points to myAppObj.
switch(event)
{
case DRV_MTCH6303_BUFFER_EVENT_COMPLETE:
// This means the data was transferred.
break;
case DRV_MTCH6303_BUFFER_EVENT_ERROR:
// Error handling here.
break;
default:
break;
}
}
Parameters
Parameters Description
bufferHandle Handle to the buffer scheduled.
touchData Buffer collecting touch data.
Function
void DRV_MTCH6303_TouchInputRead( DRV_MTCH6303_BUFFER_HANDLE * bufferHandle,
DRV_MTCH6303_TOUCH_DATA * touchData )
DRV_MTCH6303_BufferEventHandlerSet Function
Allows a client to identify a buffer event handling function for the driver to call back when queued buffer transfers have finished.
File
drv_mtch6303.h
C
void DRV_MTCH6303_BufferEventHandlerSet(const DRV_MTCH6303_BUFFER_EVENT_HANDLER eventHandler, const
uintptr_t context);
Returns
None.
Description
This function allows a client to identify a buffer event handling function for the driver to call back when queued buffer transfers have finished. When
a client calls either the DRV_MTCH6303_TouchInputRead, DRV_MTCH6303_AddRegisterRead or DRV_MTCH6303_AddRegisterWrite function,
it is provided with a handle identifying the buffer that was added to the driver's buffer queue. The driver will pass this handle back to the client by
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1096
calling "eventHandler" function when the buffer transfer has completed.
The event handler should be set before the client performs any "buffer add" operations that could generate events. The event handler once set,
persists until the client closes the driver or sets another event handler (which could be a "NULL" pointer to indicate no callback).
Remarks
None.
Preconditions
The DRV_MTCH6303_Initialize routine must have been called and the DRV_MTCH6303_Status must have returned SYS_STATUS_READY.
Example
// myAppObj is an application specific state data object.
MY_APP_OBJ myAppObj;
uint8_t mybuffer[MY_BUFFER_SIZE];
// myMTCH6303Handle is the handle returned
// by the DRV_MTCH6303_Open function.
// Client registers an event handler with driver. This is done once
DRV_MTCH6303_BufferEventHandlerSet( APP_MTCH6303BufferEventHandle,
(uintptr_t)&myAppObj );
DRV_MTCH6303_AddRegisterRead( &bufferHandle
DRV_MTCH6303_REG_TOUCH_STATUS,
MY_BUFFER_SIZE,
&mybuffer);
if(DRV_MTCH6303_BUFFER_HANDLE_INVALID == bufferHandle)
{
// Error handling here
}
// Event Processing Technique. Event is received when
// the buffer is processed.
void APP_MTCH6303BufferEventHandle( DRV_MTCH6303_BUFFER_EVENT event,
DRV_MTCH6303_BUFFER_HANDLE handle,
uintptr_t context)
{
// contextHandle points to myAppObj.
switch(event)
{
case DRV_MTCH6303_BUFFER_EVENT_COMPLETE:
// This means the data was transferred.
break;
case DRV_MTCH6303_BUFFER_EVENT_ERROR:
// Error handling here.
break;
default:
break;
}
}
Parameters
Parameters Description
eventHandler Pointer to the event handler function.
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1097
context The value of parameter will be passed back to the client unchanged, when the eventHandler
function is called. It can be used to identify any client specific data object that identifies the
instance of the client module (for example, it may be a pointer to the client module's state
structure).
Function
void DRV_MTCH6303_BufferEventHandlerSet
(
const DRV_MTCH6303_BUFFER_EVENT_HANDLER eventHandler,
const uintptr_t context
)
d) Data Types and Constants
DRV_MTCH6303_BUFFER_HANDLE_INVALID Macro
Definition of an invalid buffer handle.
File
drv_mtch6303.h
C
#define DRV_MTCH6303_BUFFER_HANDLE_INVALID
Description
MTCH6303 Driver Invalid Buffer Handle
This is the definition of an invalid buffer handle. An invalid buffer handle is returned by DRV_MTCH6303_AddRegisterRead,
DRV_MTCH6303_AddRegisterWrite or DRV_MTCH6303_TouchInputRead functions if the request was not successful.
Remarks
None
DRV_MTCH6303_TOUCH_BUFFER_HANDLE_INVALID Macro
Definition of an invalid buffer handle.
File
drv_mtch6303.h
C
#define DRV_MTCH6303_TOUCH_BUFFER_HANDLE_INVALID
Description
MTCH6303 Driver Invalid Buffer Handle
This is the definition of an invalid buffer handle. An invalid buffer handle is returned by DRV_MTCH6303_TOUCH_AddMessageReportRead,
DRV_MTCH6303_TOUCH_AddMessageCommandWrite or DRV_MTCH6303_TOUCH_AddTouchInputRead functions if the request was not
successful.
Remarks
None
DRV_MTCH6303_TOUCH_NUM_INPUTS Macro
Definition of number of touch input packets can be identified by MTCH6303.
File
drv_mtch6303.h
C
#define DRV_MTCH6303_TOUCH_NUM_INPUTS 0xA
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1098
Description
MTCH6303 Number of touch input packets
MTCH6303 supports multi-touch and can identify upto 10 different touch input packets.
Remarks
None.
DRV_MTCH6303_BUFFER_EVENT Enumeration
Lists the different conditions that happens during a buffer transfer.
File
drv_mtch6303.h
C
typedef enum {
DRV_MTCH6303_BUFFER_EVENT_COMPLETE,
DRV_MTCH6303_BUFFER_EVENT_ERROR,
DRV_MTCH6303_BUFFER_EVENT_ABORT
} DRV_MTCH6303_BUFFER_EVENT;
Members
Members Description
DRV_MTCH6303_BUFFER_EVENT_COMPLETE Event buffer transfer complete
DRV_MTCH6303_BUFFER_EVENT_ERROR Event buffer transfer error
DRV_MTCH6303_BUFFER_EVENT_ABORT Event buffer transfer abort
Description
MTCH6303 Buffer Events
This enumeration identifies the different conditions that can happen during a buffer transaction. Callbacks can be made with the appropriate buffer
condition passed as a parameter to execute the desired action.
The values act like flags and multiple flags can be set.
Remarks
None.
DRV_MTCH6303_BUFFER_EVENT_HANDLER Type
Points to a callback after completion of an register read -write or message stream read - write.
File
drv_mtch6303.h
C
typedef void (* DRV_MTCH6303_BUFFER_EVENT_HANDLER)(DRV_MTCH6303_BUFFER_EVENT event,
DRV_MTCH6303_BUFFER_HANDLE bufferHandle, uintptr_t context);
Description
MTCH6303 Buffer Event Callback
This type identifies the MTCH6303 Buffer Event. It allows the client driver to register a callback using
DRV_MTCH6303_BUFFER_EVENT_HANDLER. By using this mechanism, the driver client will be notified at the completion of the corresponding
transfer.
Remarks
A transfer can be composed of various transfer segments. Once a transfer is completed the driver will call the client registered transfer callback.
The callback could be called from ISR context and should be kept as short as possible. It is meant for signaling and it should not be blocking.
Parameters
Parameters Description
DRV_MTCH6303_BUFFER_EVENT Status of MTCH6303 transfer
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1099
bufferHandle Handle that identifies the particular Buffer Object
context pointer to the object to be processed.
Function
void ( *DRV_MTCH6303_BUFFER_EVENT_HANDLER ) ( DRV_MTCH6303_BUFFER_EVENT event,
DRV_MTCH6303_BUFFER_HANDLE bufferHandle,
uintptr_t context )
DRV_MTCH6303_BUFFER_HANDLE Type
Handle identifying a read or write buffer passed to the driver.
File
drv_mtch6303.h
C
typedef uintptr_t DRV_MTCH6303_BUFFER_HANDLE;
Description
MTCH6303 Driver Buffer Handle
A buffer handle value is returned by a call to the DRV_MTCH6303_AddRegisterRead, DRV_MTCH6303_AddRegisterWrite or
DRV_MTCH6303_TouchInputRead functions. This handle is associated with the buffer passed into the function and it allows the application to
track the completion of the data from (or into) that buffer. The buffer handle value returned from these functions is returned back to the client by the
"event handler callback" function registered with the driver.
The buffer handle assigned to a client request expires when the client has been notified of the completion of the buffer transfer (after event handler
function that notifies the client returns) or after the buffer has been retired by the driver if no event handler callback was set.
Remarks
None
DRV_MTCH6303_CLIENT_STATUS Enumeration
Defines the client-specific status of the MTCH6303 driver.
File
drv_mtch6303.h
C
typedef enum {
DRV_MTCH6303_CLIENT_STATUS_ERROR = DRV_CLIENT_STATUS_ERROR,
DRV_MTCH6303_CLIENT_STATUS_CLOSED = DRV_CLIENT_STATUS_CLOSED,
DRV_MTCH6303_CLIENT_STATUS_BUSY = DRV_CLIENT_STATUS_BUSY,
DRV_MTCH6303_CLIENT_STATUS_READY = DRV_CLIENT_STATUS_READY
} DRV_MTCH6303_CLIENT_STATUS;
Members
Members Description
DRV_MTCH6303_CLIENT_STATUS_ERROR =
DRV_CLIENT_STATUS_ERROR
An error has occurred.
DRV_MTCH6303_CLIENT_STATUS_CLOSED =
DRV_CLIENT_STATUS_CLOSED
The driver is closed, no operations for this client are ongoing, and/or the given handle is
invalid.
DRV_MTCH6303_CLIENT_STATUS_BUSY =
DRV_CLIENT_STATUS_BUSY
The driver is currently busy and cannot start additional operations.
DRV_MTCH6303_CLIENT_STATUS_READY =
DRV_CLIENT_STATUS_READY
The module is running and ready for additional operations
Description
MTCH6303 Client-Specific Driver Status
This enumeration defines the client-specific status codes of the MTCH6303 driver.
Remarks
Returned by the DRV_MTCH6303_ClientStatus function.
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1100
DRV_MTCH6303_ERROR Enumeration
Defines the possible errors that can occur during driver operation.
File
drv_mtch6303.h
C
typedef enum {
} DRV_MTCH6303_ERROR;
Description
MTCH6303 Driver Errors.
This data type defines the possible errors that can occur when occur during MTCH6303 driver operation. These values are returned by
DRV_MTCH6303_ErrorGet function.
Remarks
None
DRV_MTCH6303_TOUCH_BUFFER_EVENT Enumeration
Lists the different conditions that happens during a touch message buffer transfer.
File
drv_mtch6303.h
C
typedef enum {
DRV_MTCH6303_TOUCH_BUFFER_EVENT_COMPLETE,
DRV_MTCH6303_TOUCH_BUFFER_EVENT_ERROR,
DRV_MTCH6303_TOUCH_BUFFER_EVENT_ABORT
} DRV_MTCH6303_TOUCH_BUFFER_EVENT;
Members
Members Description
DRV_MTCH6303_TOUCH_BUFFER_EVENT_COMPLETE Event touch message buffer transfer complete
DRV_MTCH6303_TOUCH_BUFFER_EVENT_ERROR Event touch message buffer transfer error
DRV_MTCH6303_TOUCH_BUFFER_EVENT_ABORT Event touch message buffer transfer abort
Description
MTCH6303 Touch Message Buffer Events
This enumeration identifies the different conditions that can happen during a touch message buffer transaction. Callbacks can be made with the
appropriate touch message buffer condition passed as a parameter to execute the desired action.
The values act like flags and multiple flags can be set.
Remarks
None.
DRV_MTCH6303_TOUCH_BUFFER_EVENT_HANDLER Type
Points to a callback after completion of an message report read or message command write.
File
drv_mtch6303.h
C
typedef void (* DRV_MTCH6303_TOUCH_BUFFER_EVENT_HANDLER)(DRV_MTCH6303_TOUCH_BUFFER_EVENT event,
DRV_MTCH6303_TOUCH_BUFFER_HANDLE bufferHandle, uintptr_t context);
Description
MTCH6303 Touch Buffer Event Callback
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1101
This type identifies the MTCH6303 Touch Buffer Event. It allows the client driver to register a callback using
DRV_MTCH6303_TOUCH_BUFFER_EVENT_HANDLER. By using this mechanism, the driver client will be notified at the completion of the
corresponding transfer.
Remarks
A transfer can be composed of various transfer segments. Once a transfer is completed the driver will call the client registered transfer callback.
The callback could be called from ISR context and should be kept as short as possible. It is meant for signaling and it should not be blocking.
Parameters
Parameters Description
DRV_MTCH6303_TOUCH_BUFFER_EVENT Status of MTCH6303 touch message transfer
bufferHandle Handle that identifies the particular Buffer Object
context pointer to the object to be processed.
Function
void ( *DRV_MTCH6303_TOUCH_BUFFER_EVENT_HANDLER ) ( DRV_MTCH6303_TOUCH_BUFFER_EVENT event,
DRV_MTCH6303_TOUCH_BUFFER_HANDLE bufferHandle,
uintptr_t context )
DRV_MTCH6303_TOUCH_BUFFER_HANDLE Type
Handle identifying a read or write touch message buffer passed to the driver.
File
drv_mtch6303.h
C
typedef uintptr_t DRV_MTCH6303_TOUCH_BUFFER_HANDLE;
Description
MTCH6303 Driver Touch Message Queue Buffer Handle
A touch message buffer handle value is returned by a call to the DRV_MTCH6303_TOUCH_AddMessageReportRead,
DRV_MTCH6303_TOUCH_AddMessageCommandWrite or DRV_MTCH6303_TOUCH_AddTouchInputRead. This handle is associated with the
buffer passed into the function and it allows the application to track the completion of the data from (or into) that buffer. The buffer handle value
returned from these functions is returned back to the client by the "event handler callback" function registered with the driver.
The buffer handle assigned to a client request expires when the client has been notified of the completion of the buffer transfer (after event handler
function that notifies the client returns) or after the buffer has been retired by the driver if no event handler callback was set.
Remarks
None.
DRV_MTCH6303_TOUCH_DATA Structure
Defines MTCH6303 I2C Touch Data
File
drv_mtch6303.h
C
typedef struct {
uint8_t i2cReadAddr;
DRV_MTCH6303_TOUCH_STATUS status;
DRV_MTCH6303_TOUCH_INPUT touch[ DRV_MTCH6303_TOUCH_NUM_INPUTS ];
} DRV_MTCH6303_TOUCH_DATA;
Members
Members Description
uint8_t i2cReadAddr; Dummy I2C Read Address required for bitbang driver
DRV_MTCH6303_TOUCH_STATUS status; MTCH6303 Touch Status
DRV_MTCH6303_TOUCH_INPUT touch[
DRV_MTCH6303_TOUCH_NUM_INPUTS ];
MTCH6303 Touch Input array of size DRV_MTCH6303_TOUCH_NUM_INPUTS
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1102
Description
MTCH6303 I2C Touch Data
This structure defines MTCH6303 I2C Touch Data. The structure DRV_MTCH6303_TOUCH_DATA is passed to API's
DRV_MTCH6303_AddRegisterRead or DRV_MTCH6303_TOUCH_AddTouchInputRead. The API's will update the structure with touch input.
Remarks
It is packed to form structure of size 62 bytes. The structure member i2cReadAddr is only applicable if the I2C driver is of type bitbang. Otherwise
the variable required to be commented out.
DRV_MTCH6303_TOUCH_INPUT Structure
Defines MTCH6303 Touch Input Packet
File
drv_mtch6303.h
C
typedef struct {
DRV_MTCH6303_TOUCH_NIBBLE_0 nibble_0;
uint8_t touchId;
uint16_t x;
uint16_t y;
} DRV_MTCH6303_TOUCH_INPUT;
Members
Members Description
DRV_MTCH6303_TOUCH_NIBBLE_0 nibble_0; MTCH6303 I2C Touch Input Packet Nibble 0
uint8_t touchId; MTCH6303 I2C Touch Input Packet ID (0 - 16)
uint16_t x; MTCH6303 I2C Touch Input Packet position x (0 - 0x7FFF)
uint16_t y; MTCH6303 I2C Touch Input Packet position y (0 - 0x7FFF)
Description
MTCH6303 Touch Input Packet.
This structure defines the MTCH6303 Touch Input Packet.
Remarks
It is part of DRV_MTCH6303_TOUCH_DATA structure. It is packed to form structure of size 6 bytes.
DRV_MTCH6303_TOUCH_MESSAGE Structure
Defines MTCH6303 Touch Message.
File
drv_mtch6303.h
C
typedef struct {
DRV_MTCH6303_TOUCH_MESSAGE_HEADER header;
uint8_t payload[0x3E];
} DRV_MTCH6303_TOUCH_MESSAGE;
Members
Members Description
DRV_MTCH6303_TOUCH_MESSAGE_HEADER
header;
MTCH6303 Touch Message Header
uint8_t payload[0x3E]; MTCH6303 Touch Message payload. First byte of payload is of type
DRV_TOUCH_MTCH6303_MSG_ID in case of first fragment of message. Otherwise the first
byte acts as a normal payload.
Description
MTCH6303 Touch Message
This structure defines MTCH6303 Touch Message. The variable pointer of type DRV_MTCH6303_TOUCH_MESSAGE is passed to the API's
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1103
DRV_MTCH6303_TOUCH_AddMessageReportRead or DRV_MTCH6303_TOUCH_AddMessageCommandWrite.
Remarks
It is packed to form structure of size 63 bytes.
DRV_MTCH6303_TOUCH_MESSAGE_HEADER Structure
Defines Touch Message Header.
File
drv_mtch6303.h
C
typedef struct {
uint32_t msgFragSize : 6;
uint32_t continued : 1;
uint32_t moreMessages : 1;
} DRV_MTCH6303_TOUCH_MESSAGE_HEADER;
Members
Members Description
uint32_t msgFragSize : 6; MTCH6303 Message Fragment Size. If Message Fragment size is 0x3F the Fragment is
incomplete and uses up ALL of the parent transport layer packet.
uint32_t continued : 1; MTCH6303 Message continued from last fragment if set to 1.
uint32_t moreMessages : 1; MTCH6303 more messages to follow in this block if set to 1.
Description
MTCH6303 Touch Message Header
This structure defines Touch Message Header.
Remarks
It is part of structure DRV_MTCH6303_TOUCH_MESSAGE. It is packed to form structure of size 1 byte.
DRV_MTCH6303_TOUCH_NIBBLE_0 Structure
Defines the I2C Nibble 0 of MTCH6303 Touch input packet.
File
drv_mtch6303.h
C
typedef struct {
uint32_t touchState : 1;
uint32_t inRange : 1;
uint32_t reserved : 6;
} DRV_MTCH6303_TOUCH_NIBBLE_0;
Members
Members Description
uint32_t touchState : 1; Touch packet available
uint32_t inRange : 1; Touch packet in range
uint32_t reserved : 6; Reserved bits
Description
MTCH6303 I2C Touch Input Packet Nibble 0
This structure defines the I2C Nibble 0 of MTCH6303 Touch input packet.
Remarks
It is part of DRV_MTCH6303_TOUCH_INPUT structure. It is packed to form structure of size 1 byte.
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1104
DRV_MTCH6303_TOUCH_STATUS Structure
Defines the I2C touch status register bits
File
drv_mtch6303.h
C
typedef struct {
uint32_t nTouch : 4;
uint32_t streamReady : 1;
uint32_t gestureReady : 1;
uint32_t gestICData : 1;
uint32_t reserved : 1;
} DRV_MTCH6303_TOUCH_STATUS;
Members
Members Description
uint32_t nTouch : 4; Number of available touch packets
uint32_t streamReady : 1; stream data ready
uint32_t gestureReady : 1; gesture data ready
uint32_t gestICData : 1; GestIC data ready
uint32_t reserved : 1; reserved bit
Description
MTCH6303 I2C touch status
This structure defines the I2C touch status register bits.
Remarks
It is part of DRV_MTCH6303_TOUCH_DATA structure. It is packed to form structure of size 1 byte.
DRV_TOUCH_MTCH6303_MSG_ID Enumeration
List of report or command message identification.
File
drv_mtch6303.h
C
typedef enum {
DRV_TOUCH_MTCH6303_MSG_CMD_QUERY_VERSION
} DRV_TOUCH_MTCH6303_MSG_ID;
Members
Members Description
DRV_TOUCH_MTCH6303_MSG_CMD_QUERY_VERSION Message sends firmware version query command. Bytes 124:127 =
Rev[2].Minor.Major
Description
MTCH6303 Touch message Identification.
This enumeration identifies the different report or command messages supported by MTCH6303. This identifier identifies the type of the message.
The identifier is passed in the message DRV_MTCH6303_TOUCH_MESSAGE as first byte of the payload. It is applicable only for first fragment of
message. If message involves multiple fragments, the payload of message fragments other than first fragment should start with normal payload
byte. The touch message is read or send to MTCH6303 by using DRV_MTCH6303_TOUCH_AddMessageReportRead or
DRV_MTCH6303_TOUCH_AddMessageCommandWrite.
Remarks
To be passed as first byte of message payload. Applicable only for first fragment of message.
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1105
DRV_TOUCH_MTCH6303_I2C_REGISTER_MAP Enumeration
List of MTCH6303 I2C Accessible Register Identification.
File
drv_mtch6303.h
C
typedef enum {
} DRV_TOUCH_MTCH6303_I2C_REGISTER_MAP;
Description
MTCH6303 I2C Accessible Register Identification.
This enumeration identifies the different I2C accessible MTCH6303 Registers. The identifier is passed as source to the register read routine or as
destination to the register write routine. The MTCH6303 driver routine to read the I2C accessible MTCH6303 registers is
DRV_MTCH6303_AddRegisterRead. The MTCH6303 driver routine to write the I2C accessible MTCH6303 registers is
DRV_MTCH6303_AddRegisterWrite.
Remarks
To read or write multiple registers, identifier of only first register is sufficient as source or destination respectively.
Files
Files
Name Description
drv_mtch6303.h MTCH6303 driver interface declarations for the static single instance driver.
Description
This section lists the source and header files used by the MTCH6303 Touch Driver Library.
drv_mtch6303.h
MTCH6303 driver interface declarations for the static single instance driver.
Enumerations
Name Description
DRV_MTCH6303_BUFFER_EVENT Lists the different conditions that happens during a buffer transfer.
DRV_MTCH6303_CLIENT_STATUS Defines the client-specific status of the MTCH6303 driver.
DRV_MTCH6303_ERROR Defines the possible errors that can occur during driver operation.
DRV_MTCH6303_TOUCH_BUFFER_EVENT Lists the different conditions that happens during a touch message buffer
transfer.
DRV_TOUCH_MTCH6303_I2C_REGISTER_MAP List of MTCH6303 I2C Accessible Register Identification.
DRV_TOUCH_MTCH6303_MSG_ID List of report or command message identification.
Functions
Name Description
DRV_MTCH6303_AddRegisterRead Schedules a non-blocking register read request to read I2C accessible
MTCH6303 registers.
DRV_MTCH6303_AddRegisterWrite Schedule a non-blocking driver register write operation to write I2C
accessible MTCH6303 registers.
DRV_MTCH6303_BufferEventHandlerSet Allows a client to identify a buffer event handling function for the driver to
call back when queued buffer transfers have finished.
DRV_MTCH6303_Close Closes an opened-instance of the MTCH6303 driver.
DRV_MTCH6303_Deinitialize Deinitializes the instance of the MTCH6303 driver module.
DRV_MTCH6303_ErrorGet This function returns the error associated with the last client request.
DRV_MTCH6303_Initialize Initializes the MTCH6303 static single instance.
DRV_MTCH6303_Open Opens the MTCH6303 driver instance and returns a handle to it.
DRV_MTCH6303_Status Gets the current status of the MTCH6303 driver module.
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1106
DRV_MTCH6303_Tasks Maintains the driver's register read/write state machine and implements
its ISR.
DRV_MTCH6303_TOUCH_AddMessageCommandWrite Schedule a non-blocking driver command message write operation to
write command message to MTCH6303 registers.
DRV_MTCH6303_TOUCH_AddMessageReportRead Schedules a non-blocking report message read request to read the
report message from MTCH6303 device.
DRV_MTCH6303_TOUCH_AddTouchInputRead Schedules a non-blocking read buffer request to read touch input from
MTCH6303.
DRV_MTCH6303_TOUCH_BufferEventHandlerSet Allows a client to identify a buffer event handling function for the driver to
call back when queued message transfers have finished.
DRV_MTCH6303_TOUCH_Tasks Maintains the driver's message state machine and implements its ISR.
DRV_MTCH6303_TouchInputMap Maps the raw touch input to display resolution.
DRV_MTCH6303_TouchInputRead Schedules a non-blocking read buffer request to read touch input from
MTCH6303.
Macros
Name Description
DRV_MTCH6303_BUFFER_HANDLE_INVALID Definition of an invalid buffer handle.
DRV_MTCH6303_TOUCH_BUFFER_HANDLE_INVALID Definition of an invalid buffer handle.
DRV_MTCH6303_TOUCH_NUM_INPUTS Definition of number of touch input packets can be identified by
MTCH6303.
Structures
Name Description
DRV_MTCH6303_TOUCH_DATA Defines MTCH6303 I2C Touch Data
DRV_MTCH6303_TOUCH_INPUT Defines MTCH6303 Touch Input Packet
DRV_MTCH6303_TOUCH_MESSAGE Defines MTCH6303 Touch Message.
DRV_MTCH6303_TOUCH_MESSAGE_HEADER Defines Touch Message Header.
DRV_MTCH6303_TOUCH_NIBBLE_0 Defines the I2C Nibble 0 of MTCH6303 Touch input packet.
DRV_MTCH6303_TOUCH_STATUS Defines the I2C touch status register bits
Types
Name Description
DRV_MTCH6303_BUFFER_EVENT_HANDLER Points to a callback after completion of an register read -write or
message stream read - write.
DRV_MTCH6303_BUFFER_HANDLE Handle identifying a read or write buffer passed to the driver.
DRV_MTCH6303_TOUCH_BUFFER_EVENT_HANDLER Points to a callback after completion of an message report read or
message command write.
DRV_MTCH6303_TOUCH_BUFFER_HANDLE Handle identifying a read or write touch message buffer passed to the
driver.
Description
MTCH6303 Driver Interface Declarations for Static Single Instance Driver
The MTCH6303 device driver provides a simple interface to manage the MTCH6303 module. This file defines the interface Declarations for the
MTCH6303 driver.
Remarks
Static single instance driver interface eliminates the need for an object ID or object handle. Static single-open interfaces also eliminate the need for
the open handle.
File Name
drv_mtch6303_static.h
Company
Microchip Technology Inc.
mXT336T Touch Driver Library
This topic describes the mXT336T Touch Driver Library.
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1107
Introduction
This library provides an interface to manage the mXT336T Touch Driver module on the Microchip family of microcontrollers in different modes of
operation.
Description
The MPLAB Harmony mXT336T Touch Driver provides a high-level interface to the mXT336T touch controller device. This driver provides
application routines to read the touch input data from the touch screen. The mXT336T device can notify the availability of touch input data through
external interrupt. The mXT336T driver allows the application to map a controller pin as an external interrupt pin.
Currently, the mXT336T Touch Driver only supports non-gestural single-fingered touch input.
Using the Library
This topic describes the basic architecture of the mXT336T Touch Driver Library and provides information and examples on its use.
Description
Interface Header Files: drv_mxt336t.h, drv_mxt.h
The interface to the mXT336T Touch Driver library is defined in the drv_mxt336t.h and drv_mxt.h header files. Any C language source (.c)
file that uses the mXT336T Touch Driver library should include this header.
The mXT336T Touch Driver is based on the Object Protocol for the Atmel® maXTouch® mXT336T Touchscreen Controller.
The functioning of the driver is divided into two file sets:
• drv_mxt.h has the system touch interface (API’s, Initialization and tasks)
• drv_mxt336t.h has the device specific interface for getting the device ready for communication and receiving commands.
The device specific interface is based on the Object Protocol previously mentioned.
The aria_quickstart demonstration interfaces with the mXT336T Touch Driver Library. Please refer to the What is MPLAB Harmony? section for
how the driver interacts with the framework.
Abstraction Model
This library provides a low-level abstraction of the mXT336T Touch Driver Library on the Microchip family microcontrollers with a convenient C
language interface. This topic describes how that abstraction is modeled in software and introduces the library's interface.
Description
The mXT336T Touch Driver has routines to perform the following operations:
• Sending read request
• Reading the touch input data
• Access to the touch input data
The driver initialization routines allow the application to initialize the driver. The driver must be initialized before it can be used by application. Once
the driver is initialized the driver open routine allows retrieving the client handle. Once the touch input is available a touch input read request is
sent and input data is retrieved in a buffer. The buffer data is then decoded to get the x and y coordinate of the touch screen in the form of the
number of pixels.
mXT336T Driver Abstraction Model
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1108
Library Overview
This section contains information about how the Touch Driver operates in a system.
Description
The library interface routines are divided into various sub-sections, which address one of the blocks or the overall operation of the mXT336T
Touch Driver.
Library Interface Section Description
Device-specific Functions Provides mXT336T-specific system module interfaces, device initialization, deinitialization, open, close, task, and
status functions.
Generic Functions Provides generic system module interfaces, device initialization, deinitialization, open, close, task, and status
functions.
How the Library Works
This section describes the workings of the Touch Driver Library.
Description
The library provides interfaces to support:
• System functions, which provide system module interfaces, device initialization, deinitialization, open, close, task, and status functions.
• Read Request function, which provides Touch input data read request function
• Read Touch Input function, which provides functions retrieving updated Touch input in the form x and y coordinates.
Initializing the Driver
Before the mXT336T Touch Driver can be opened, it must be configured and initialized. The driver build time configuration is defined by the
configuration macros. Refer to the Building the Library section for the location of and more information on the various configuration macros and
how these macros should be designed. The driver initialization is configured through the DRV_TOUCH_INIT data structure that is passed to the
DRV_MXT336T_Initialize and the DRV_MXT_Initialize functions. The initialization parameters include the interrupt source, interrupt pin
remap configuration and touch screen resolution. The following code shows an example of initializing the mXT336T Touch Driver.
Example:
/* The following code shows an example of designing the
* DRV_TOUCH_INIT data structure. It also shows how an example
* usage of the DRV_TOUCH_MXT336T_Initialize function.
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1109
*/
DRV_TOUCH_INIT drvTouchInitData;
DRV_MXT_INIT drvMxtInitData;
SYS_MODULE_OBJ objectHandle;
const DRV_MXT336T_INIT drvTouchInitData =
{
.moduleInit = {0},
.touchId = DRV_TOUCH_INDEX_0,
.drvInitialize = NULL,
.drvOpen = DRV_I2C_Open,
.orientation = 0,
.horizontalResolution = 480,
.verticalResolution = 272,
.interruptSource = INT_SOURCE_EXTERNAL_1,
.interruptChannel = PORT_CHANNEL_E,
.interruptPin = PORTS_BIT_POS_8,
.resetChannel = PORT_CHANNEL_A,
.resetPin = PORTS_BIT_POS_2,
};
const DRV_MXT_INIT drvMxtInitData =
{
.moduleInit = {0},
.mxtId = DRV_MXT_INDEX_0,
.drvInitialize = NULL,
.orientation = 0,
.horizontalResolution = 480,
.verticalResolution = 272,
};
/* Driver initialization */
sysObj.drvMXT336T = DRV_MXT336T_Initialize(DRV_MXT336T_INDEX_0,
(SYS_MODULE_INIT *)&drvTouchInitData);
sysObj.drvMxt0 = DRV_MXT_Initialize(DRV_MXT_INDEX_0,
(SYS_MODULE_INIT *)&drvMxtInitData);
Opening the Driver
To use the mXT336T Touch Driver, the application must open the driver. This is done by calling the DRV_MXT_Open function.
If successful, the DRV_MXT_Open function will return a handle to the driver. This handle records the association between the client and the driver
instance that was opened. The DRV_MXT_Open function may return DRV_HANDLE_INVALID in the situation where the driver is not ready to be
opened. When this occurs, the application can try opening the driver again. Note that the open function may return an invalid handle in other
(error) cases as well. The following code shows an example of the driver being opened.
The open function in the driver is called from the system initialization routine by assigning a function pointer from sys_init object.
const DRV_TOUCH_INIT sysTouchInit0 =
{
.drvInitialize = DRV_MXT_Initialize,
.drvOpen = DRV_MXT_Open,
.
.
};
SYS_TOUCH_HANDLE SYS_TOUCH_Open
(
const SYS_MODULE_INDEX moduleIndex
)
{
SYS_TOUCH_CLIENT_OBJ *clientObj;
SYS_TOUCH_OBJ *dObj;
.
.
.
/* open touch driver */
dObj->driverInitData->drvOpen(moduleIndex, DRV_IO_INTENT_READWRITE);
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1110
}
Touch Input Read Request
To read the touch input from the mXT336T touch controller device, a read request must be registered. This is done by calling
DRV_MXT336T_ReadRequest. If successful, it registers a buffer read request to the I2C command queue. It also adds an input decode command
to the mXT336T command queue once the I2C returns with touch input data. It can return error if the driver instance object is invalid or the
mXT336T command queue is full. The read request is to be called from the mXT336T ISR. This ISR is triggered once the touch input is available.
The following code shows an example of a mXT336T read request registration:
SYS_MODULE_OBJ object; // Returned from DRV_TOUCH_MXT336T_Initialize
void ISR(_EXTERNAL_INT_VECTOR, ipl5) _IntHandlerDrvMxt336t(void)
{
DRV__MXT336T_ReadRequest ( object );
// Do other tasks
Tasks Routine
This routine processes the mXT336T commands from the command queue. If the state of the command is initialize or done it returns. If the read
request registration is successful the state of command is to decode input. The tasks routine decodes the input and updates the global variables
storing the touch input data in form of x and y coordinates. The mXT336T Touch Driver task routine is to be called from SYS_Tasks. The following
code shows an example:
SYS_MODULE_OBJ drvMXT336T;
SYS_MODULE_OBJ drvMxt0;; // Returned from DRV_TOUCH_MXT336T_Initialize
void SYS_Tasks( void )
{
DRV_MXT336T_Tasks(sysObj.drvMXT336T);
DRV_MXT_Tasks(sysObj.drvMxt0);
// Do other tasks
}
Configuring the Library
Macros
Name Description
DRV_MXT336T_CALIBRATION_DELAY Defines the calibration delay.
DRV_MXT336T_CALIBRATION_INSET Defines the calibration inset.
DRV_MXT336T_CLIENTS_NUMBER Selects the maximum number of clients.
DRV_MXT336T_INDEX MXT336T static index selection.
DRV_MXT336T_INSTANCES_NUMBER Sets up the maximum number of hardware instances that can be supported.
DRV_MXT336T_INTERRUPT_MODE Controls operation of the driver in the interrupt or polled mode.
DRV_MXT336T_SAMPLE_POINTS Define the sample points.
DRV_MXT336T_TOUCH_DIAMETER Defines the touch diameter.
Description
The configuration of the mXT336T Touch Driver is based on the file system_config.h.
This header file contains the configuration selection for the mXT336T Touch Driver. Based on the selections made, the driver may support the
selected features. These configuration settings will apply to all instances of the mXT336T Touch Driver.
This header can be placed anywhere, the path of this header needs to be present in the include search path for a successful build. Refer to the
Applications Help section for more details.
DRV_MXT336T_CALIBRATION_DELAY Macro
Defines the calibration delay.
File
drv_mxt336t_config_template.h
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1111
C
#define DRV_MXT336T_CALIBRATION_DELAY 300
Description
MXT336T Calibration Delay
This macro enables the delay between calibration touch points.
Remarks
None.
DRV_MXT336T_CALIBRATION_INSET Macro
Defines the calibration inset.
File
drv_mxt336t_config_template.h
C
#define DRV_MXT336T_CALIBRATION_INSET 25
Description
MXT336T Calibration Inset
This macro defines the calibration inset.
Remarks
None.
DRV_MXT336T_CLIENTS_NUMBER Macro
Selects the maximum number of clients.
File
drv_mxt336t_config_template.h
C
#define DRV_MXT336T_CLIENTS_NUMBER 5
Description
MXT336T maximum number of clients
This macro selects the maximum number of clients.
This definition selected the maximum number of clients that the MXT336T driver can support at run time.
Remarks
None.
DRV_MXT336T_INDEX Macro
MXT336T static index selection.
File
drv_mxt336t_config_template.h
C
#define DRV_MXT336T_INDEX DRV_MXT336T_INDEX_0
Description
MXT336T Static Index Selection
This macro specifies the static index selection for the driver object reference.
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1112
Remarks
This index is required to make a reference to the driver object.
DRV_MXT336T_INSTANCES_NUMBER Macro
Sets up the maximum number of hardware instances that can be supported.
File
drv_mxt336t_config_template.h
C
#define DRV_MXT336T_INSTANCES_NUMBER 1
Description
MXT336T hardware instance configuration
This macro sets up the maximum number of hardware instances that can be supported.
Remarks
None.
DRV_MXT336T_INTERRUPT_MODE Macro
Controls operation of the driver in the interrupt or polled mode.
File
drv_mxt336t_config_template.h
C
#define DRV_MXT336T_INTERRUPT_MODE false
Description
MXT336T Interrupt And Polled Mode Operation Control
This macro controls the operation of the driver in the interrupt mode of operation. The possible values of this macro are:
• true - Select if interrupt mode of MXT336T operation is desired
• false - Select if polling mode of MXT336T operation is desired
Not defining this option to true or false will result in a build error.
Remarks
None.
DRV_MXT336T_SAMPLE_POINTS Macro
Define the sample points.
File
drv_mxt336t_config_template.h
C
#define DRV_MXT336T_SAMPLE_POINTS 4
Description
MXT336T Sample Points
MXT336T sample points
Remarks
None.
DRV_MXT336T_TOUCH_DIAMETER Macro
Defines the touch diameter.
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1113
File
drv_mxt336t_config_template.h
C
#define DRV_MXT336T_TOUCH_DIAMETER 10
Description
MXT336T Touch Diameter
This macro defines the touch diameter
Remarks
None.
Configuring the MHC
The following figure details the settings required to configure the MHC for the mXT336T Touch Driver.
Building the Library
This section lists the files that are available in the mXT336T Touch Driver Library.
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1114
Description
This section list the files that are available in the \src folder of the mXT336T Touch Driver. It lists which files need to be included in the build
based on either a hardware feature present on the board or configuration option selected by the system.
The following three tables list and describe the header (.h) and source (.c) files that implement this library. The parent folder for these files is
/framework/driver/touch/mxt336t.
Interface File(s)
This table lists and describes the header files that must be included (i.e., using #include) by any code that uses this library.
Source File Name Description
/drv_mxt336t.h Header file that exports the device-specific driver API.
/drv_mxt.h Header file for generic driver API.
Required File(s)
All of the required files listed in the following table are automatically added into the MPLAB X IDE project by the MHC
when the library is selected for use.
This table lists and describes the source and header files that must always be included in the MPLAB X IDE project to build this library.
Source File Name Description
src/drv_mxt336t.c Basic mXT336T Touch Driver implementation file.
src/drv_mxt.c Generic maXTouch touch driver implementation file.
Optional File(s)
This table lists and describes the source and header files that may optionally be included if required for the desired implementation.
Source File Name Description
N/A No optional files are available for this library.
Module Dependencies
The mXT336T Touch Driver Library depends on the following modules:
• Interrupt System Service Library
• Ports System Service Library
• Touch System Service Library
• I2C Driver Library
Library Interface
a) Device-specific Functions
Name Description
DRV_MXT336T_Close Closes an opened instance of the MXT336T driver.
Implementation: Dynamic
DRV_MXT336T_ReadRequest Sends a read request to I2C bus driver and adds the read task to queue.
Implementation: Dynamic
DRV_MXT336T_Open Opens the specified MXT336T driver instance and returns a handle to it.
Implementation: Dynamic
DRV_MXT336T_CloseObject Closes an opened instance of the MXT336T client object
DRV_MXT336T_OpenObject Opens the specified MXT336T object driver instance and returns a
handle to it.
Implementation: Dynamic
DRV_MXT336T_DEVICE_ClientObjectEventHandlerSet Sets the event handler for a MXT336T client object
DRV_MXT336T_Deinitialize Deinitializes the specified instance of the MXT336T driver module.
Implementation: Dynamic
DRV_MXT336T_Initialize Initializes the MXT336T instance for the specified driver index
DRV_MXT336T_Status Provides the current status of the MXT336T driver module.
Implementation: Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1115
DRV_MXT336T_Tasks Maintains the driver's state machine and implements its task queue
processing.
Implementation: Dynamic
b) Generic Functions
Name Description
DRV_MXT_Close Closes an opened instance of the MXT driver.
Implementation: Dynamic
DRV_MXT_MaxtouchEventCallback
DRV_MXT_Deinitialize Deinitializes the specified instance of the MXT driver module.
Implementation: Dynamic
DRV_MXT_Open Opens the specified MXT driver instance and returns a handle to it.
Implementation: Dynamic
DRV_MXT_TouchDataRead Notifies the driver that the current touch data has been read
DRV_MXT_Initialize Initializes the MXT instance for the specified driver index.
Implementation: Dynamic
DRV_MXT_ReadRequest Sends a read request to I2C bus driver and adds the read task to queue.
Implementation: Dynamic
DRV_MXT_TouchGetX Returns the x coordinate of touch input.
Implementation: Dynamic
DRV_MXT_TouchGetY Returns the y coordinate of touch input.
Implementation: Dynamic
DRV_MXT_Status Provides the current status of the MXT driver module.
Implementation: Dynamic
DRV_MXT_Tasks Maintains the driver's state machine and implements its task queue processing.
Implementation: Dynamic
DRV_MXT_TouchStatus Returns the status of the current touch input.
c) Data Types and Constants
Name Description
_DRV_MXT_CLIENT_OBJECT MXT Driver client object maintaining client data.
DRV_MXT_CLIENT_OBJECT MXT Driver client object maintaining client data.
DRV_MXT_HANDLE Touch screen controller MXT driver handle.
DRV_MXT_INIT Defines the data required to initialize or reinitialize the MXT driver
DRV_MXT_MODULE_ID Number of valid MXT driver indices.
DRV_MXT_OBJECT Defines the data structure maintaining MXT driver instance object.
DRV_MXT_TASK_QUEUE Defines the MXT Touch Controller driver task data structure.
DRV_MXT_TASK_STATE Enumeration defining MXT touch controller driver task state.
DRV_MXT336T_CLIENT_CALLBACK Pointer to a MXT336T client callback function data type.
DRV_MXT336T_HANDLE Touch screen controller MXT336T driver handle.
DRV_MXT336T_INIT Defines the data required to initialize or reinitialize the MXT336T driver
DRV_MXT336T_OBJECT_CLIENT_EVENT_DATA This structure maintains the information associated with each msg received or
event that occurs
DRV_MXT336T_OBJECT_TYPE The enum lists the different objects supported by the maxtouch device.
DRV_MXT_HANDLE_INVALID Definition of an invalid handle.
_DRV_MXT336T_H This is macro _DRV_MXT336T_H.
DRV_MXT_I2C_MASTER_READ_ID MXT input read, I2C address from where master reads touch input data.
DRV_MXT_I2C_MASTER_WRITE_ID MXT command register write, I2C address where master sends the
commands.
DRV_MXT_I2C_READ_FRAME_SIZE I2C Frame size for reading MXT touch input.
DRV_MXT_INDEX_0 MXT driver index definitions.
DRV_MXT_INDEX_1 This is macro DRV_MXT_INDEX_1.
DRV_MXT_INDEX_COUNT Number of valid Touch controller MXT driver indices.
DRV_MXT336T_HANDLE_INVALID Definition of an invalid handle.
DRV_MXT336T_I2C_FRAME_SIZE I2C Frame size for reading MXT336T touch input.
DRV_MXT336T_I2C_MASTER_READ_ID MXT336T input read, I2C address from where master reads touch input data.
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1116
DRV_MXT336T_I2C_MASTER_WRITE_ID MXT336T command register write, I2C address where master sends the
commands.
DRV_MXT336T_I2C_READ_ID_FRAME_SIZE This is macro DRV_MXT336T_I2C_READ_ID_FRAME_SIZE.
DRV_MXT336T_INDEX_0 MXT336T driver index definitions.
DRV_MXT336T_INDEX_1 This is macro DRV_MXT336T_INDEX_1.
DRV_MXT336T_INDEX_COUNT Number of valid Touch controller MXT336T driver indices.
t100_event Types of touch events reported by the Maxtouch Multi touch object
t100_type Types of touch types reported by the Maxtouch Multi touch object
DRV_MXT336T_T100_XRANGE MXT336T Driver Object Register Adresses for the registers being read in the
driver
DRV_MXT336T_T100_YRANGE This is macro DRV_MXT336T_T100_YRANGE.
Description
This section describes the functions of the mXT336T Touch Driver Library.
Refer to each section for a detailed description.
a) Device-specific Functions
DRV_MXT336T_Close Function
Closes an opened instance of the MXT336T driver.
Implementation: Dynamic
File
drv_mxt336t.h
C
void DRV_MXT336T_Close(DRV_HANDLE handle);
Returns
None
Description
This function closes an opened instance of the MXT336T driver, invalidating the handle.
Remarks
After calling this routine, the handle passed in "handle" must not be used with any of the remaining driver routines. A new handle must be obtained
by calling DRV_MXT336T_Open before the caller may use the driver again. This function is thread safe in a RTOS application.
Usually, there is no need for the driver client to verify that the Close operation has completed.
Preconditions
The DRV_MXT336T_Initialize routine must have been called for the specified MXT336T driver instance.
DRV_MXT336T_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE handle; // Returned from DRV_MXT336T_Open
DRV_MXT336T_Close ( handle );
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
void DRV_MXT336T_Close ( DRV_HANDLE handle )
DRV_MXT336T_ReadRequest Function
Sends a read request to I2C bus driver and adds the read task to queue.
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1117
Implementation: Dynamic
File
drv_mxt336t.h
C
void DRV_MXT336T_ReadRequest(SYS_MODULE_OBJ object);
Returns
None.
Description
This routine is used to send a touch input read request to the I2C bus driver and adding the input read decode task to the queue. It is always called
from MXT336T interrupt ISR routine.
Remarks
This function is normally not called directly by an application. It is called by the MXT336T ISR routine.
Preconditions
The DRV_MXT336T_Initialize routine must have been called for the specified MXT336T driver instance.
Example
SYS_MODULE_OBJ object; // Returned from DRV_MXT336T_Initialize
void __ISR(_EXTERNAL_INT_VECTOR, ipl5) _IntHandlerDrvMXT(void)
{
DRV_MXT336T_ReadRequest ( object );
// Do other tasks
}
Parameters
Parameters Description
object Object handle for the specified driver instance (returned from DRV_MXT336T_Initialize)
Function
void DRV_MXT336T_ReadRequest( SYS_MODULE_OBJ object )
DRV_MXT336T_Open Function
Opens the specified MXT336T driver instance and returns a handle to it.
Implementation: Dynamic
File
drv_mxt336t.h
C
DRV_HANDLE DRV_MXT336T_Open(const SYS_MODULE_INDEX drvIndex, const DRV_IO_INTENT intent);
Returns
If successful, the routine returns a valid open-instance handle (a number identifying both the caller and the module instance).
If an error occurs, the return value is DRV_HANDLE_INVALID. An error can occur when the following is true:
• if the number of client objects allocated via DRV_MXT336T_CLIENTS_NUMBER is insufficient
• if the client is trying to open the driver but driver has been opened exclusively by another client
• if the driver hardware instance being opened is not initialized or is invalid
Description
This routine opens the specified MXT336T driver instance and provides a handle that must be provided to all other client-level operations to
identify the caller and the instance of the driver. The ioIntent parameter defines how the client interacts with this driver instance.
The current version of driver does not support the DRV_IO_INTENT feature. The driver is by default non-blocking. The driver can perform both
read and write to the MXT336T device. The driver supports single client only.
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1118
Remarks
The handle returned is valid until the DRV_MXT336T_Close routine is called. This routine will NEVER block waiting for hardware. If the requested
intent flags are not supported, the routine will return DRV_HANDLE_INVALID. This function is thread safe in a RTOS application. It should not be
called in an ISR.
Preconditions
The DRV_MXT336T_Initialize function must have been called before calling this function.
Example
DRV_HANDLE handle;
handle = DRV_MXT336T_Open( DRV_MXT336T_INDEX_0,
DRV_IO_INTENT_EXCLUSIVE );
if( DRV_HANDLE_INVALID == handle )
{
// Unable to open the driver
}
Parameters
Parameters Description
drvIndex Index of the driver initialized with DRV_MXT336T_Initialize().
intent Zero or more of the values from the enumeration DRV_IO_INTENT ORed together to indicate
the intended use of the driver. The current version of driver does not support the selective IO
intent feature.
Function
DRV_HANDLE DRV_MXT336T_Open ( const SYS_MODULE_INDEX drvIndex,
const DRV_IO_INTENT intent )
DRV_MXT336T_CloseObject Function
Closes an opened instance of the MXT336T client object
File
drv_mxt336t.h
C
void DRV_MXT336T_CloseObject(DRV_HANDLE handle);
Returns
None
Description
This function closes an opened instance of the MXT336T client object, invalidating the handle.
Remarks
After calling this routine, the handle passed in "handle" must not be used with any of the remaining driver routines. A new handle must be obtained
by calling DRV_MXT336T_OpenObject before the caller may use the driver again. This function is thread safe in a RTOS application.
Usually, there is no need for the driver client to verify that the Close operation has completed.
Preconditions
The DRV_MXT336T_Initialize routine must have been called for the specified MXT336T driver instance.
DRV_MXT336T_OpenObject must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE handle; // Returned from DRV_MXT336T_Open
DRV_MXT336T_CloseObject ( handle );
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1119
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
void DRV_MXT336T_CloseObject ( DRV_HANDLE handle )
DRV_MXT336T_OpenObject Function
Opens the specified MXT336T object driver instance and returns a handle to it.
Implementation: Dynamic
File
drv_mxt336t.h
C
DRV_HANDLE DRV_MXT336T_OpenObject(const DRV_HANDLE deviceHandle, const uint8_t objType, const uint8_t
objInstance);
Returns
If successful, the routine returns a valid object-instance handle (
Description
This routine opens the specified MXT336T object driver instance and provides a handle that must be provided to all other client-level operations to
identify the caller and the instance of the driver.
Preconditions
The DRV_MXT336T_Initialize function must have been called before calling this function. The driver must have been opened.
Example
DRV_HANDLE handle;
handle = DRV_MXT336T_OpenObject(drvHandle, GEN_PROCESSOR_T5, 1);
Parameters
Parameters Description
deviceHandle Handle of the MXT336T device
objType Object type being requested
objInstance Instance of the object of this type
Function
DRV_HANDLE DRV_MXT336T_OpenObject ( const DRV_HANDLE deviceHandle, const uint8_t objType,
const uint8_t objInstance )
DRV_MXT336T_DEVICE_ClientObjectEventHandlerSet Function
Sets the event handler for a MXT336T client object
File
drv_mxt336t.h
C
bool DRV_MXT336T_DEVICE_ClientObjectEventHandlerSet(const DRV_HANDLE clientHandle, const
DRV_MXT336T_CLIENT_CALLBACK callback, uintptr_t context);
Returns
bool - true if the handler was successfully set
• false if the handler could not be set
Description
This function sets the event handler used to handle report messages from a MXT336T object.
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1120
Preconditions
The DRV_MXT336T_OpenObject routine must have been called for the specified MXT336T driver instance.
DRV_MXT336T_OpenObject must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE handle; // Returned from DRV_MXT336T_OpenObject
DRV_MXT336T_DEVICE_ClientObjectEventHandlerSet(handle, objectCallback, NULL);
Parameters
Parameters Description
clientHandle A valid open-instance handle, returned from the driver's openobject routine
callback A callback function to handle report messages
context The context for the call
Function
bool DRV_MXT336T_DEVICE_ClientObjectEventHandlerSet(const DRV_HANDLE clientHandle,
const DRV_MXT336T_CLIENT_CALLBACK callback, uintptr_t context)
DRV_MXT336T_Deinitialize Function
Deinitializes the specified instance of the MXT336T driver module.
Implementation: Dynamic
File
drv_mxt336t.h
C
void DRV_MXT336T_Deinitialize(SYS_MODULE_OBJ object);
Returns
None.
Description
Deinitializes the specified instance of the MXT336T driver module, disabling its operation (and any hardware) and invalidates all of the internal
data.
Remarks
Once the Initialize operation has been called, the De-initialize operation must be called before the Initialize operation can be called again.
This function will NEVER block waiting for hardware. If the operation requires time to allow the hardware to complete, this will be reported by the
DRV_MXT336T_Status operation. The system has to use DRV_MXT336T_Status to determine when the module is in the ready state.
Preconditions
Function DRV_MXT336T_Initialize must have been called before calling this routine and a valid SYS_MODULE_OBJ must have been returned.
Parameter: object - Driver object handle, returned from DRV_MXT336T_Initialize
Example
SYS_MODULE_OBJ object; //Returned from DRV_MXT336T_Initialize
SYS_STATUS status;
DRV_MXT336T_Deinitialize ( object );
status = DRV_MXT336T_Status( object );
if( SYS_MODULE_UNINITIALIZED == status )
{
// Check again later if you need to know
// when the driver is deinitialized.
}
Function
void DRV_MXT336T_Deinitialize ( SYS_MODULE_OBJ object )
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1121
DRV_MXT336T_Initialize Function
Initializes the MXT336T instance for the specified driver index
File
drv_mxt336t.h
C
SYS_MODULE_OBJ DRV_MXT336T_Initialize(const SYS_MODULE_INDEX index, const SYS_MODULE_INIT * const init);
Returns
If successful, returns a valid handle to a driver instance object. Otherwise, returns SYS_MODULE_OBJ_INVALID.
Description
This routine initializes the MXT336T driver instance for the specified driver index, making it ready for clients to open and use it. The initialization
data is specified by the 'init' parameter. The initialization may fail if the number of driver objects allocated are insufficient or if the specified driver
instance is already initialized. The driver instance index is independent of the MXT336T module ID. For example, driver instance 0 can be
assigned to MXT336T2. If the driver is built statically, then some of the initialization parameters are overridden by configuration macros. Refer to
the description of the DRV_MXT336T_INIT data structure for more details on which members on this data structure are overridden.
Remarks
This routine must be called before any other MXT336T routine is called.
This routine should only be called once during system initialization unless DRV_MXT336T_Deinitialize is called to deinitialize the driver instance.
This routine will NEVER block for hardware access.
Preconditions
None.
Example
DRV_MXT336T_INIT init;
SYS_MODULE_OBJ objectHandle;
// Populate the MXT336T initialization structure
// Touch Module Id
init.moduleInit = {0},
init.touchId = DRV_TOUCH_INDEX_0,
init.drvInitialize = NULL,
init.drvOpen = DRV_I2C_Open,
init.interruptSource = INT_SOURCE_EXTERNAL_1,
init.interruptChannel = PORT_CHANNEL_D,
init.interruptPin = PORTS_BIT_POS_1,
init.resetChannel = PORT_CHANNEL_A,
init.resetPin = PORTS_BIT_POS_14,
objectHandle = DRV_MXT336T_Initialize(DRV_TOUCH_INDEX_0,
(SYS_MODULE_INIT*)init);
if (SYS_MODULE_OBJ_INVALID == objectHandle)
{
// Handle error
}
Parameters
Parameters Description
index Identifier for the instance to be initialized. Please note this is not the MXT336T ID. The
hardware MXT336T ID is set in the initialization structure. This is the index of the driver index
to use.
init Pointer to a data structure containing any data necessary to initialize the driver. If this pointer
is NULL, the driver uses the static initialization override macros for each member of the
initialization data structure.
Function
SYS_MODULE_OBJ DRV_MXT336T_Initialize(const SYS_MODULE_INDEX index,
const SYS_MODULE_INIT * const init )
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1122
DRV_MXT336T_Status Function
Provides the current status of the MXT336T driver module.
Implementation: Dynamic
File
drv_mxt336t.h
C
SYS_STATUS DRV_MXT336T_Status(SYS_MODULE_OBJ object);
Returns
SYS_STATUS_READY - Indicates that the driver is busy with a previous system-level operation and cannot start another
Description
This function provides the current status of the MXT336T driver module.
Remarks
Any value greater than SYS_STATUS_READY is also a normal running state in which the driver is ready to accept new operations.
SYS_MODULE_UNINITIALIZED - Indicates that the driver has been deinitialized
This value is less than SYS_STATUS_ERROR.
This function can be used to determine when any of the driver's module level operations has completed.
If the status operation returns SYS_STATUS_BUSY, the previous operation has not yet completed. Once the status operation returns
SYS_STATUS_READY, any previous operations have completed.
The value of SYS_STATUS_ERROR is negative (-1). Any value less than that is also an error state.
This function will NEVER block waiting for hardware.
If the Status operation returns an error value, the error may be cleared by calling the reinitialize operation. If that fails, the deinitialize operation will
need to be called, followed by the initialize operation to return to normal operations.
Preconditions
The DRV_MXT336T_Initialize function must have been called before calling this function.
Example
SYS_MODULE_OBJ object; // Returned from DRV_MXT336T_Initialize
SYS_STATUS status;
status = DRV_MXT336T_Status( object );
if( SYS_STATUS_READY != status )
{
// Handle error
}
Parameters
Parameters Description
object Driver object handle, returned from DRV_MXT336T_Initialize
Function
SYS_STATUS DRV_MXT336T_Status ( SYS_MODULE_OBJ object )
DRV_MXT336T_Tasks Function
Maintains the driver's state machine and implements its task queue processing.
Implementation: Dynamic
File
drv_mxt336t.h
C
void DRV_MXT336T_Tasks(SYS_MODULE_OBJ object);
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1123
Returns
None.
Description
This routine is used to maintain the driver's internal state machine and implement its command queue processing. It is always called from
SYS_Tasks() function. This routine decodes the touch input data available in drvI2CReadFrameData.
Remarks
This function is normally not called directly by an application. It is called by the system's Tasks routine (SYS_Tasks)
Preconditions
The DRV_MXT336T_Initialize routine must have been called for the specified MXT336T driver instance.
Example
SYS_MODULE_OBJ object; // Returned from DRV_MXT336T_Initialize
void SYS_Tasks( void )
{
DRV_MXT336T_Tasks ( object );
// Do other tasks
}
Parameters
Parameters Description
object Object handle for the specified driver instance (returned from DRV_MXT336T_Initialize)
Function
void DRV_MXT336T_Tasks ( SYS_MODULE_OBJ object );
b) Generic Functions
DRV_MXT_Close Function
Closes an opened instance of the MXT driver.
Implementation: Dynamic
File
drv_mxt.h
C
void DRV_MXT_Close(DRV_HANDLE handle);
Returns
None
Description
This function closes an opened instance of the MXT driver, invalidating the handle.
Remarks
After calling this routine, the handle passed in "handle" must not be used with any of the remaining driver routines. A new handle must be obtained
by calling DRV_MXT_Open before the caller may use the driver again. This function is thread safe in a RTOS application.
Usually, there is no need for the driver client to verify that the Close operation has completed.
Preconditions
The DRV_MXT_Initialize routine must have been called for the specified MXT driver instance.
DRV_MXT_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE handle; // Returned from DRV_MXT_Open
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1124
DRV_MXT_Close ( handle );
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
void DRV_MXT_Close ( DRV_HANDLE handle )
DRV_MXT_MaxtouchEventCallback Function
File
drv_mxt.h
C
void DRV_MXT_MaxtouchEventCallback(DRV_HANDLE clientObject, DRV_MXT336T_OBJECT_CLIENT_EVENT_DATA *
updateObject, uintptr_t context);
Remarks
See prototype in app.h.
Function
void DRV_MXT_MaxtouchEventCallback ( DRV_HANDLE clientObject,
DRV_MAXTOUCH_OBJECT_CLIENT_EVENT_DATA *updateObject, uintptr_t context);
DRV_MXT_Deinitialize Function
Deinitializes the specified instance of the MXT driver module.
Implementation: Dynamic
File
drv_mxt.h
C
void DRV_MXT_Deinitialize(SYS_MODULE_OBJ object);
Returns
None.
Description
Deinitializes the specified instance of the MXT driver module, disabling its operation (and any hardware) and invalidates all of the internal data.
Remarks
Once the Initialize operation has been called, the De-initialize operation must be called before the Initialize operation can be called again.
This function will NEVER block waiting for hardware. If the operation requires time to allow the hardware to complete, this will be reported by the
DRV_MXT_Status operation. The system has to use DRV_MXT_Status to determine when the module is in the ready state.
Preconditions
Function DRV_MXT_Initialize must have been called before calling this routine and a valid SYS_MODULE_OBJ must have been returned.
Parameter: object - Driver object handle, returned from DRV_MXT_Initialize
Example
SYS_MODULE_OBJ object; //Returned from DRV_MXT_Initialize
SYS_STATUS status;
DRV_MXT_Deinitialize ( object );
status = DRV_MXT_Status( object );
if( SYS_MODULE_UNINITIALIZED == status )
{
// Check again later if you need to know
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1125
// when the driver is deinitialized.
}
Function
void DRV_MXT_Deinitialize ( SYS_MODULE_OBJ object )
DRV_MXT_Open Function
Opens the specified MXT driver instance and returns a handle to it.
Implementation: Dynamic
File
drv_mxt.h
C
DRV_HANDLE DRV_MXT_Open(const SYS_MODULE_INDEX drvIndex, const DRV_IO_INTENT intent);
Returns
If successful, the routine returns a valid open-instance handle (a number identifying both the caller and the module instance).
If an error occurs, the return value is DRV_HANDLE_INVALID. An error can occur when the following is true:
• if the number of client objects allocated via DRV_MXT_CLIENTS_NUMBER is insufficient
• if the client is trying to open the driver but driver has been opened exclusively by another client
• if the driver hardware instance being opened is not initialized or is invalid
Description
This routine opens the specified MXT driver instance and provides a handle that must be provided to all other client-level operations to identify the
caller and the instance of the driver. The ioIntent parameter defines how the client interacts with this driver instance.
The current version of driver does not support the DRV_IO_INTENT feature. The driver is by default non-blocking. The driver can perform both
read and write to the MXT device. The driver supports single client only.
Remarks
The handle returned is valid until the DRV_MXT_Close routine is called. This routine will NEVER block waiting for hardware. If the requested intent
flags are not supported, the routine will return DRV_HANDLE_INVALID. This function is thread safe in a RTOS application. It should not be called
in an ISR.
Preconditions
The DRV_MXT_Initialize function must have been called before calling this function.
Example
DRV_HANDLE handle;
handle = DRV_MXT_Open( DRV_MXT_INDEX_0,
DRV_IO_INTENT_EXCLUSIVE );
if( DRV_HANDLE_INVALID == handle )
{
// Unable to open the driver
}
Parameters
Parameters Description
drvIndex Index of the driver initialized with DRV_MXT_Initialize().
intent Zero or more of the values from the enumeration DRV_IO_INTENT ORed together to indicate
the intended use of the driver. The current version of driver does not support the selective IO
intent feature.
Function
DRV_HANDLE DRV_MXT_Open ( const SYS_MODULE_INDEX drvIndex,
const DRV_IO_INTENT intent )
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1126
DRV_MXT_TouchDataRead Function
Notifies the driver that the current touch data has been read
File
drv_mxt.h
C
void DRV_MXT_TouchDataRead(const SYS_MODULE_INDEX index);
Returns
None.
Description
Notifies the driver that the current touch data has been read
Function
void DRV_MXT_TouchDataRead( const SYS_MODULE_INDEX index )
DRV_MXT_Initialize Function
Initializes the MXT instance for the specified driver index.
Implementation: Dynamic
File
drv_mxt.h
C
SYS_MODULE_OBJ DRV_MXT_Initialize(const SYS_MODULE_INDEX index, const SYS_MODULE_INIT * const init);
Returns
If successful, returns a valid handle to a driver instance object. Otherwise, returns SYS_MODULE_OBJ_INVALID.
Description
This routine initializes the MXT driver instance for the specified driver index, making it ready for clients to open and use it. The initialization data is
specified by the 'init' parameter. The initialization may fail if the number of driver objects allocated are insufficient or if the specified driver instance
is already initialized. The driver instance index is independent of the MXT module ID. For example, driver instance 0 can be assigned to MXT2. If
the driver is built statically, then some of the initialization parameters are overridden by configuration macros. Refer to the description of the
DRV_MXT_INIT data structure for more details on which members on this data structure are overridden.
Remarks
This routine must be called before any other MXT routine is called.
This routine should only be called once during system initialization unless DRV_MXT_Deinitialize is called to deinitialize the driver instance. This
routine will NEVER block for hardware access.
Preconditions
None.
Example
DRV_MXT_INIT init;
SYS_MODULE_OBJ objectHandle;
// Populate the MXT initialization structure
// Touch Module Id
init.touchId = DRV_TOUCH_INDEX_0;
// I2C Bus driver open
init.drvOpen = DRV_I2C_Open;
// Interrupt Source for Touch
init.interruptSource = INT_SOURCE_EXTERNAL_1;
// Interrupt Pin function mapping
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1127
init.interruptPort.inputFunction = INPUT_FUNC_INT1;
// Pin to be mapped as interrupt pin
init.interruptPort.inputPin = INPUT_PIN_RPE8;
// Analog pin number
init.interruptPort.analogPin = PORTS_ANALOG_PIN_25;
// Pin Mode of analog pin
init.interruptPort.pinMode = PORTS_PIN_MODE_DIGITAL;
// Interrupt pin port
init.interruptPort.channel = PORT_CHANNEL_E;
// Interrupt pin port maskl
init.interruptPort.dataMask = 0x8;
// Touch screen orientation
init.orientation = DISP_ORIENTATION;
// Touch screen horizontal resolution
init.horizontalResolution = DISP_HOR_RESOLUTION;
// Touch screen vertical resolution
init.verticalResolution = DISP_VER_RESOLUTION;
objectHandle = DRV_MXT_Initialize(DRV_TOUCH_INDEX_0,
(SYS_MODULE_INIT*)init);
if (SYS_MODULE_OBJ_INVALID == objectHandle)
{
// Handle error
}
Parameters
Parameters Description
index Identifier for the instance to be initialized. Please note this is not the MXT ID. The hardware
MXT ID is set in the initialization structure. This is the index of the driver index to use.
init Pointer to a data structure containing any data necessary to initialize the driver. If this pointer
is NULL, the driver uses the static initialization override macros for each member of the
initialization data structure.
Function
SYS_MODULE_OBJ DRV_MXT_Initialize(const SYS_MODULE_INDEX index,
const SYS_MODULE_INIT * const init )
DRV_MXT_ReadRequest Function
Sends a read request to I2C bus driver and adds the read task to queue.
Implementation: Dynamic
File
drv_mxt.h
C
void DRV_MXT_ReadRequest(SYS_MODULE_OBJ object);
Returns
None.
Description
This routine is used to send a touch input read request to the I2C bus driver and adding the input read decode task to the queue. It is always called
from MXT interrupt ISR routine.
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1128
Remarks
This function is normally not called directly by an application. It is called by the MXT ISR routine.
Preconditions
The DRV_MXT_Initialize routine must have been called for the specified MXT driver instance.
Example
SYS_MODULE_OBJ object; // Returned from DRV_MXT_Initialize
void __ISR(_EXTERNAL_INT_VECTOR, ipl5) _IntHandlerDrvMXT(void)
{
DRV_MXT_ReadRequest ( object );
// Do other tasks
}
Parameters
Parameters Description
object Object handle for the specified driver instance (returned from DRV_MXT_Initialize)
Function
void DRV_MXT_ReadRequest( SYS_MODULE_OBJ object )
DRV_MXT_TouchGetX Function
Returns the x coordinate of touch input.
Implementation: Dynamic
File
drv_mxt.h
C
short DRV_MXT_TouchGetX(uint8_t touchNumber);
Returns
It returns the x coordinate of the touch input in terms of number of pixels.
Description
It returns the x coordinate in form of number of pixes for a touch input denoted by touchNumber.
Parameters
Parameters Description
touchNumber index to the touch input.
Function
short DRV_MXT_TouchGetX( uint8 touchNumber )
DRV_MXT_TouchGetY Function
Returns the y coordinate of touch input.
Implementation: Dynamic
File
drv_mxt.h
C
short DRV_MXT_TouchGetY(uint8_t touchNumber);
Returns
It returns the y coordinate of the touch input in terms of number of pixels.
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1129
Description
It returns the y coordinate in form of number of pixes for a touch input denoted by touchNumber.
Parameters
Parameters Description
touchNumber index to the touch input.
Function
short DRV_MXT_TouchGetY( uint8 touchNumber )
DRV_MXT_Status Function
Provides the current status of the MXT driver module.
Implementation: Dynamic
File
drv_mxt.h
C
SYS_STATUS DRV_MXT_Status(SYS_MODULE_OBJ object);
Returns
SYS_STATUS_READY - Indicates that the driver is busy with a previous system-level operation and cannot start another
Description
This function provides the current status of the MXT driver module.
Remarks
Any value greater than SYS_STATUS_READY is also a normal running state in which the driver is ready to accept new operations.
SYS_MODULE_UNINITIALIZED - Indicates that the driver has been deinitialized
This value is less than SYS_STATUS_ERROR.
This function can be used to determine when any of the driver's module level operations has completed.
If the status operation returns SYS_STATUS_BUSY, the previous operation has not yet completed. Once the status operation returns
SYS_STATUS_READY, any previous operations have completed.
The value of SYS_STATUS_ERROR is negative (-1). Any value less than that is also an error state.
This function will NEVER block waiting for hardware.
If the Status operation returns an error value, the error may be cleared by calling the reinitialize operation. If that fails, the deinitialize operation will
need to be called, followed by the initialize operation to return to normal operations.
Preconditions
The DRV_MXT_Initialize function must have been called before calling this function.
Example
SYS_MODULE_OBJ object; // Returned from DRV_MXT_Initialize
SYS_STATUS status;
status = DRV_MXT_Status( object );
if( SYS_STATUS_READY != status )
{
// Handle error
}
Parameters
Parameters Description
object Driver object handle, returned from DRV_MXT_Initialize
Function
SYS_STATUS DRV_MXT_Status ( SYS_MODULE_OBJ object )
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1130
DRV_MXT_Tasks Function
Maintains the driver's state machine and implements its task queue processing.
Implementation: Dynamic
File
drv_mxt.h
C
void DRV_MXT_Tasks(SYS_MODULE_OBJ object);
Returns
None.
Description
This routine is used to maintain the driver's internal state machine and implement its command queue processing. It is always called from
SYS_Tasks() function. This routine decodes the touch input data available in drvI2CReadFrameData.
Remarks
This function is normally not called directly by an application. It is called by the system's Tasks routine (SYS_Tasks)
Preconditions
The DRV_MXT_Initialize routine must have been called for the specified MXT driver instance.
Example
SYS_MODULE_OBJ object; // Returned from DRV_MXT_Initialize
void SYS_Tasks( void )
{
DRV_MXT_Tasks ( object );
// Do other tasks
}
Parameters
Parameters Description
object Object handle for the specified driver instance (returned from DRV_MXT_Initialize)
Function
void DRV_MXT_Tasks ( SYS_MODULE_OBJ object );
DRV_MXT_TouchStatus Function
Returns the status of the current touch input.
File
drv_mxt.h
C
DRV_TOUCH_POSITION_STATUS DRV_MXT_TouchStatus(const SYS_MODULE_INDEX index);
Returns
It returns the status of the current touch input.
Description
It returns the status of the current touch input.
Function
DRV_TOUCH_POSITION_SINGLE DRV_MXT_TouchStatus( const SYS_MODULE_INDEX index )
c) Data Types and Constants
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1131
DRV_MXT_CLIENT_OBJECT Structure
MXT Driver client object maintaining client data.
File
drv_mxt.h
C
typedef struct _DRV_MXT_CLIENT_OBJECT {
DRV_MXT_OBJECT* driverObject;
DRV_IO_INTENT intent;
} DRV_MXT_CLIENT_OBJECT;
Members
Members Description
DRV_MXT_OBJECT* driverObject; Driver Object associated with the client
DRV_IO_INTENT intent; The intent with which the client was opened
Description
Structure DRV_MXT_CLIENT_OBJECT
This defines the object required for the maintenance of the software clients instance. This object exists once per client instance.
Remarks
None.
DRV_MXT_HANDLE Type
Touch screen controller MXT driver handle.
File
drv_mxt.h
C
typedef uintptr_t DRV_MXT_HANDLE;
Description
MXT Driver Handle
Touch controller MXT driver handle is a handle for the driver client object. Each driver with succesful open call will return a new handle to the client
object.
Remarks
None.
DRV_MXT_INIT Structure
Defines the data required to initialize or reinitialize the MXT driver
File
drv_mxt.h
C
typedef struct {
SYS_MODULE_INIT moduleInit;
int mxtId;
SYS_MODULE_OBJ (* drvInitialize)(const SYS_MODULE_INDEX index, const SYS_MODULE_INIT * const init);
SYS_MODULE_INDEX maxtouchID;
uint16_t orientation;
uint16_t horizontalResolution;
uint16_t verticalResolution;
} DRV_MXT_INIT;
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1132
Members
Members Description
SYS_MODULE_INIT moduleInit; System module initialization
int mxtId; ID
SYS_MODULE_OBJ (* drvInitialize)(const
SYS_MODULE_INDEX index, const
SYS_MODULE_INIT * const init);
initialize function for module (normally called statically
SYS_MODULE_INDEX maxtouchID; index for the maxtouch driver instance used by this driver
uint16_t orientation; Orientation of the display (given in degrees of 0,90,180,270)
uint16_t horizontalResolution; Horizontal Resolution of the displayed orientation in Pixels
Description
Structure DRV_MXT_INIT
This data type defines the data required to initialize or reinitialize the MXT driver. If the driver is built statically, the members of this data structure
are statically over-ridden by static override definitions in the system_config.h file.
Remarks
None.
DRV_MXT_MODULE_ID Enumeration
Number of valid MXT driver indices.
File
drv_mxt.h
C
typedef enum {
MXT_ID_1 = 0,
MXT_NUMBER_OF_MODULES
} DRV_MXT_MODULE_ID;
Description
Enumeration: DRV_MXT_MODULE_ID
This constant identifies the number of valid MXT driver indices.
Remarks
This constant should be used in place of hard-coded numeric literals.
This value is derived from device-specific header files defined as part of the peripheral libraries.
DRV_MXT_OBJECT Structure
Defines the data structure maintaining MXT driver instance object.
File
drv_mxt.h
C
typedef struct {
SYS_STATUS status;
int mxtId;
SYS_MODULE_INDEX drvIndex;
bool inUse;
bool isExclusive;
uint8_t numClients;
uint16_t orientation;
uint16_t horizontalResolution;
uint16_t verticalResolution;
int32_t readRequest;
SYS_MODULE_INDEX maxtouchID;
DRV_HANDLE hMaxtouch;
DRV_HANDLE hMaxtouchGestureClient;
DRV_TOUCH_POSITION_STATUS touchStatus;
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1133
bool maxtouchDataAvailable;
uint8_t maxtouchData[32];
uint16_t xRange;
uint16_t yRange;
} DRV_MXT_OBJECT;
Members
Members Description
SYS_STATUS status; The status of the driver
int mxtId; The peripheral Id associated with the object
SYS_MODULE_INDEX drvIndex; Save the index of the driver. Important to know this as we are using reference based
accessing
bool inUse; Flag to indicate instance in use
bool isExclusive; Flag to indicate module used in exclusive access mode
uint8_t numClients; Number of clients possible with the hardware instance
uint16_t orientation; Orientation of the display (given in degrees of 0,90,180,270)
uint16_t horizontalResolution; Horizontal Resolution of the displayed orientation in Pixels
uint16_t verticalResolution; Vertical Resolution of the displayed orientaion in Pixels
int32_t readRequest; Touch Input read request counter
SYS_MODULE_INDEX maxtouchID; index of the maxtouch driver being used
DRV_HANDLE hMaxtouch; handle for the maxtouch driver being used
DRV_HANDLE hMaxtouchGestureClient; handle for the maxtouch driver object we are listening to
DRV_TOUCH_POSITION_STATUS touchStatus; Touch status
bool maxtouchDataAvailable; flag to indicate new maxtouch data is available
uint8_t maxtouchData[32]; data from the maxtouch device
Description
Structure DRV_MXT_OBJECT
This data structure maintains the MXT driver instance object. The object exists once per hardware instance.
Remarks
None.
DRV_MXT_TASK_QUEUE Structure
Defines the MXT Touch Controller driver task data structure.
File
drv_mxt.h
C
typedef struct {
bool inUse;
DRV_MXT_TASK_STATE taskState;
DRV_I2C_BUFFER_HANDLE drvI2CReadBufferHandle;
uint8_t drvI2CReadFrameData[DRV_MXT_I2C_READ_FRAME_SIZE];
} DRV_MXT_TASK_QUEUE;
Members
Members Description
bool inUse; Flag denoting the allocation of task
DRV_MXT_TASK_STATE taskState; Enum maintaining the task state
DRV_I2C_BUFFER_HANDLE drvI2CReadBufferHandle; I2C Buffer handle
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1134
uint8_t
drvI2CReadFrameData[DRV_MXT_I2C_READ_FRAME_SIZE];
Response to Read Touch Input Command
• Response = { MXT Read Address,
• Input Data Size,
• Touch Id, Pen status,
• Touch X coordinate (0 to 6),
• Touch X coordinate (7 to 11),
• Touch Y coordinate (0 to 6),
• Touch Y coordinate (7 to 11) }
Description
Structure DRV_MXT_TASK_QUEUE
This data type defines the data structure maintaing task context in the task queue. The inUse flag denotes the task context allocation for a task.
The enum variable taskState maintains the current task state. The I2C buffer handle drvI2CReadBufferHandle maintains the I2C driver buffer
handle returned by the I2C driver read request. The byte array variable drvI2CReadFrameData maintains the I2C frame data sent by MXT after a
successful read request.
Remarks
None.
DRV_MXT_TASK_STATE Enumeration
Enumeration defining MXT touch controller driver task state.
File
drv_mxt.h
C
typedef enum {
DRV_MXT_TASK_STATE_INIT = 0,
DRV_MXT_TASK_STATE_READ_INPUT,
DRV_MXT_TASK_STATE_DECODE_INPUT,
DRV_MXT_TASK_STATE_DONE
} DRV_MXT_TASK_STATE;
Members
Members Description
DRV_MXT_TASK_STATE_INIT = 0 Task initialize state
DRV_MXT_TASK_STATE_READ_INPUT Task read touch input request state
DRV_MXT_TASK_STATE_DECODE_INPUT Task touch input decode state
DRV_MXT_TASK_STATE_DONE Task complete state
Description
Enumeration DRV_MXT_TASK_STATE
This enumeration defines the MXT touch controller driver task state. The task state helps to synchronize the operations of initialization the the task,
adding the read input task to the task queue once the touch controller notifies the available touch input and a decoding the touch input received.
Remarks
None.
DRV_MXT336T_CLIENT_CALLBACK Type
Pointer to a MXT336T client callback function data type.
File
drv_mxt336t.h
C
typedef void (* DRV_MXT336T_CLIENT_CALLBACK)(DRV_HANDLE clientObject, DRV_MXT336T_OBJECT_CLIENT_EVENT_DATA
*updateObject, uintptr_t context);
Description
MXT336T Driver Callback Function Pointer
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1135
This data type defines a pointer to a MXT336T client callback function.
DRV_MXT336T_HANDLE Type
Touch screen controller MXT336T driver handle.
File
drv_mxt336t.h
C
typedef uintptr_t DRV_MXT336T_HANDLE;
Description
MXT336T Driver Handle
Touch controller MXT336T driver handle is a handle for the driver client object. Each driver with successful open call will return a new handle to
the client object.
Remarks
None.
DRV_MXT336T_INIT Type
Defines the data required to initialize or reinitialize the MXT336T driver
File
drv_mxt336t.h
C
typedef struct DRV_MXT336T_INIT@2 DRV_MXT336T_INIT;
Description
Structure DRV_MXT336T_INIT
This data type defines the data required to initialize or reinitialize the MXT336T driver. If the driver is built statically, the members of this data
structure are statically over-ridden by static override definitions in the system_config.h file.
Remarks
None.
DRV_MXT336T_OBJECT_CLIENT_EVENT_DATA Structure
This structure maintains the information associated with each msg received or event that occurs
File
drv_mxt336t.h
C
typedef struct {
uint8_t reportID;
uint8_t dataSize;
uint8_t * pData;
uint16_t xRange;
uint16_t yRange;
} DRV_MXT336T_OBJECT_CLIENT_EVENT_DATA;
Members
Members Description
uint8_t reportID; report ID within the object
uint8_t dataSize; max size of data
uint8_t * pData; data associated with the report
Description
Structure DRV_MXT336T_OBJECT_CLIENT_EVENT_DATA
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1136
This structure maintains the information associated with each msg received or event that occurs. Each msg gets a reportID that identifies the
object reporting the change in status. For touch messages the xRange and yRange for the touch device gets reported and the data pointer
contains the status msg information which has the touch type, touch event and touch coordinates.
Remarks
None.
DRV_MXT336T_OBJECT_TYPE Enumeration
The enum lists the different objects supported by the maxtouch device.
File
drv_mxt336t.h
C
typedef enum {
DRV_MXT336T_OBJECT_RESERVED_T0 = 0,
DRV_MXT336T_OBJECT_RESERVED_T1 = 1,
DRV_MXT336T_OBJECT_DEBUG_DELTAS_T2 = 2,
DRV_MXT336T_OBJECT_DEBUG_REFERENCES_T3 = 3,
DRV_MXT336T_OBJECT_DEBUG_SIGNALS_T4 = 4,
DRV_MXT336T_OBJECT_GEN_MESSAGEPROCESSOR_T5 = 5,
DRV_MXT336T_OBJECT_GEN_COMMANDPROCESSOR_T6 = 6,
DRV_MXT336T_OBJECT_GEN_POWERCONFIG_T7 = 7,
DRV_MXT336T_OBJECT_GEN_ACQUISITIONCONFIG_T8 = 8,
DRV_MXT336T_OBJECT_TOUCH_MULTITOUCHSCREEN_T9 = 9,
DRV_MXT336T_OBJECT_TOUCH_SINGLETOUCHSCREEN_T10 = 10,
DRV_MXT336T_OBJECT_TOUCH_XSLIDER_T11 = 11,
DRV_MXT336T_OBJECT_TOUCH_YSLIDER_T12 = 12,
DRV_MXT336T_OBJECT_TOUCH_XWHEEL_T13 = 13,
DRV_MXT336T_OBJECT_TOUCH_YWHEEL_T14 = 14,
DRV_MXT336T_OBJECT_TOUCH_KEYARRAY_T15 = 15,
DRV_MXT336T_OBJECT_PROCG_SIGNALFILTER_T16 = 16,
DRV_MXT336T_OBJECT_PROCI_LINEARIZATIONTABLE_T17 = 17,
DRV_MXT336T_OBJECT_SPT_COMMSCONFIG_T18 = 18,
DRV_MXT336T_OBJECT_SPT_GPIOPWM_T19 = 19,
DRV_MXT336T_OBJECT_PROCI_GRIPFACESUPPRESSION_T20 = 20,
DRV_MXT336T_OBJECT_RESERVED_T21 = 21,
DRV_MXT336T_OBJECT_PROCG_NOISESUPPRESSION_T22 = 22,
DRV_MXT336T_OBJECT_TOUCH_PROXIMITY_T23 = 23,
DRV_MXT336T_OBJECT_PROCI_ONETOUCHGESTUREPROCESSOR_T24 = 24,
DRV_MXT336T_OBJECT_SPT_SELFTEST_T25 = 25,
DRV_MXT336T_OBJECT_DEBUG_CTERANGE_T26 = 26,
DRV_MXT336T_OBJECT_PROCI_TWOTOUCHGESTUREPROCESSOR_T27 = 27,
DRV_MXT336T_OBJECT_SPT_CTECONFIG_T28 = 28,
DRV_MXT336T_OBJECT_SPT_GPI_T29 = 29,
DRV_MXT336T_OBJECT_SPT_GATE_T30 = 30,
DRV_MXT336T_OBJECT_TOUCH_KEYSET_T31 = 31,
DRV_MXT336T_OBJECT_TOUCH_XSLIDERSET_T32 = 32,
DRV_MXT336T_OBJECT_RESERVED_T33 = 33,
DRV_MXT336T_OBJECT_GEN_MESSAGEBLOCK_T34 = 34,
DRV_MXT336T_OBJECT_SPT_PROTOTYPE_T35 = 35,
DRV_MXT336T_OBJECT_RESERVED_T36 = 36,
DRV_MXT336T_OBJECT_DEBUG_DIAGNOSTIC_T37 = 37,
DRV_MXT336T_OBJECT_SPT_USERDATA_T38 = 38,
DRV_MXT336T_OBJECT_SPARE_T39 = 39,
DRV_MXT336T_OBJECT_PROCI_GRIPSUPPRESSION_T40 = 40,
DRV_MXT336T_OBJECT_PROCI_PALMSUPPRESSION_T41 = 41,
DRV_MXT336T_OBJECT_PROCI_TOUCHSUPPRESSION_T42 = 42,
DRV_MXT336T_OBJECT_SPT_DIGITIZER_T43 = 43,
DRV_MXT336T_OBJECT_SPT_MESSAGECOUNT_T44 = 44,
DRV_MXT336T_OBJECT_PROCI_VIRTUALKEY_T45 = 45,
DRV_MXT336T_OBJECT_SPT_CTECONFIG_T46 = 46,
DRV_MXT336T_OBJECT_PROCI_STYLUS_T47 = 47,
DRV_MXT336T_OBJECT_PROCG_NOISESUPPRESSION_T48 = 48,
DRV_MXT336T_OBJECT_GEN_DUALPULSE_T49 = 49,
DRV_MXT336T_OBJECT_SPARE_T50 = 50,
DRV_MXT336T_OBJECT_SPT_SONY_CUSTOM_T51 = 51,
DRV_MXT336T_OBJECT_TOUCH_PROXKEY_T52 = 52,
DRV_MXT336T_OBJECT_GEN_DATASOURCE_T53 = 53,
DRV_MXT336T_OBJECT_PROCG_NOISESUPPRESSION_T54 = 54,
DRV_MXT336T_OBJECT_PROCI_ADAPTIVETHRESHOLD_T55 = 55,
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1137
DRV_MXT336T_OBJECT_PROCI_SHIELDLESS_T56 = 56,
DRV_MXT336T_OBJECT_PROCI_EXTRATOUCHSCREENDATA_T57 = 57,
DRV_MXT336T_OBJECT_SPT_EXTRANOISESUPCTRLS_T58 = 58,
DRV_MXT336T_OBJECT_SPT_FASTDRIFT_T59 = 59,
DRV_MXT336T_OBJECT_SPT_TIMER_T61 = 61,
DRV_MXT336T_OBJECT_PROCG_NOISESUPPRESSION_T62 = 62,
DRV_MXT336T_OBJECT_PROCI_ACTIVESTYLUS_T63 = 63,
DRV_MXT336T_OBJECT_SPT_REFERENCERELOAD_T64 = 64,
DRV_MXT336T_OBJECT_PROCI_LENSBENDING_T65 = 65,
DRV_MXT336T_OBJECT_SPT_GOLDENREFERENCES_T66 = 66,
DRV_MXT336T_OBJECT_PROCI_CUSTOMGESTUREPROCESSOR_T67 = 67,
DRV_MXT336T_OBJECT_SERIAL_DATA_COMMAND_T68 = 68,
DRV_MXT336T_OBJECT_PROCI_PALMGESTUREPROCESSOR_T69 = 69,
DRV_MXT336T_OBJECT_SPT_DYNAMICCONFIGURATIONCONTROLLER_T70 = 70,
DRV_MXT336T_OBJECT_SPT_DYNAMICCONFIGURATIONCONTAINER_T71 = 71,
DRV_MXT336T_OBJECT_PROCG_NOISESUPPRESSION_T72 = 72,
DRV_MXT336T_OBJECT_PROCI_ZONEINDICATION_T73 = 73,
DRV_MXT336T_OBJECT_PROCG_SIMPLEGESTUREPROCESSOR_T74 = 74,
DRV_MXT336T_OBJECT_MOTION_SENSING_OBJECT_T75 = 75,
DRV_MXT336T_OBJECT_PROCI_MOTION_GESTURES_T76 = 76,
DRV_MXT336T_OBJECT_SPT_CTESCANCONFIG_T77 = 77,
DRV_MXT336T_OBJECT_PROCI_GLOVEDETECTION_T78 = 78,
DRV_MXT336T_OBJECT_SPT_TOUCHEVENTTRIGGER_T79 = 79,
DRV_MXT336T_OBJECT_PROCI_RETRANSMISSIONCOMPENSATION_T80 = 80,
DRV_MXT336T_OBJECT_PROCI_UNLOCKGESTURE_T81 = 81,
DRV_MXT336T_OBJECT_SPT_NOISESUPEXTENSION_T82 = 82,
DRV_MXT336T_OBJECT_ENVIRO_LIGHTSENSING_T83 = 83,
DRV_MXT336T_OBJECT_PROCI_GESTUREPROCESSOR_T84 = 84,
DRV_MXT336T_OBJECT_PEN_ACTIVESTYLUSPOWER_T85 = 85,
DRV_MXT336T_OBJECT_PROCG_NOISESUPACTIVESTYLUS_T86 = 86,
DRV_MXT336T_OBJECT_PEN_ACTIVESTYLUSDATA_T87 = 87,
DRV_MXT336T_OBJECT_PEN_ACTIVESTYLUSRECEIVE_T88 = 88,
DRV_MXT336T_OBJECT_PEN_ACTIVESTYLUSTRANSMIT_T89 = 89,
DRV_MXT336T_OBJECT_PEN_ACTIVESTYLUSWINDOW_T90 = 90,
DRV_MXT336T_OBJECT_DEBUG_CUSTOMDATACONFIG_T91 = 91,
DRV_MXT336T_OBJECT_PROCI_SYMBOLGESTUREPROCESSOR_T92 = 92,
DRV_MXT336T_OBJECT_PROCI_TOUCHSEQUENCELOGGER_T93 = 93,
DRV_MXT336T_OBJECT_SPT_PTCCONFIG_T95 = 95,
DRV_MXT336T_OBJECT_SPT_PTCTUNINGPARAMS_T96 = 96,
DRV_MXT336T_OBJECT_TOUCH_PTCKEYS_T97 = 97,
DRV_MXT336T_OBJECT_PROCG_PTCNOISESUPPRESSION_T98 = 98,
DRV_MXT336T_OBJECT_PROCI_KEYGESTUREPROCESSOR_T99 = 99,
DRV_MXT336T_OBJECT_TOUCH_MULTITOUCHSCREEN_T100 = 100,
DRV_MXT336T_OBJECT_SPT_TOUCHSCREENHOVER_T101 = 101,
DRV_MXT336T_OBJECT_SPT_SELFCAPHOVERCTECONFIG_T102 = 102,
DRV_MXT336T_OBJECT_PROCI_SCHNOISESUPPRESSION_T103 = 103,
DRV_MXT336T_OBJECT_SPT_AUXTOUCHCONFIG_T104 = 104,
DRV_MXT336T_OBJECT_SPT_DRIVENPLATEHOVERCONFIG_T105 = 105,
DRV_MXT336T_OBJECT_SPT_ACTIVESTYLUSMMBCONFIG_T106 = 106,
DRV_MXT336T_OBJECT_PROCI_ACTIVESTYLUS_T107 = 107,
DRV_MXT336T_OBJECT_PROCG_NOISESUPSELFCAP_T108 = 108,
DRV_MXT336T_OBJECT_SPT_SELFCAPGLOBALCONFIG_T109 = 109,
DRV_MXT336T_OBJECT_SPT_SELFCAPTUNINGPARAMS_T110 = 110,
DRV_MXT336T_OBJECT_SPT_SELFCAPCONFIG_T111 = 111,
DRV_MXT336T_OBJECT_PROCI_SELFCAPGRIPSUPPRESSION_T112 = 112,
DRV_MXT336T_OBJECT_SPT_PROXMEASURECONFIG_T113 = 113,
DRV_MXT336T_OBJECT_SPT_ACTIVESTYLUSMEASCONFIG_T114 = 114,
DRV_MXT336T_OBJECT_PROCI_SYMBOLGESTURE_T115 = 115,
DRV_MXT336T_OBJECT_SPT_SYMBOLGESTURECONFIG_T116 = 116,
DRV_MXT336T_OBJECT_GEN_INFOBLOCK16BIT_T254 = 254,
DRV_MXT336T_OBJECT_SPT_PROTOTYPE_T220 = 220,
DRV_MXT336T_OBJECT_SPT_PROTOTYPE_T221 = 221,
DRV_MXT336T_OBJECT_SPT_PROTOTYPE_T222 = 222,
DRV_MXT336T_OBJECT_SPT_PROTOTYPE_T223 = 223,
DRV_MXT336T_OBJECT_SPT_PROTOTYPE_T224 = 224,
DRV_MXT336T_OBJECT_SPT_PROTOTYPE_T225 = 225,
DRV_MXT336T_OBJECT_SPT_PROTOTYPE_T226 = 226,
DRV_MXT336T_OBJECT_SPT_PROTOTYPE_T227 = 227,
DRV_MXT336T_OBJECT_SPT_PROTOTYPE_T228 = 228,
DRV_MXT336T_OBJECT_SPT_PROTOTYPE_T229 = 229,
DRV_MXT336T_OBJECT_SPT_PROTOTYPE_T230 = 230,
DRV_MXT336T_OBJECT_SPT_PROTOTYPE_T231 = 231,
DRV_MXT336T_OBJECT_SPT_PROTOTYPE_T232 = 232,
DRV_MXT336T_OBJECT_SPT_PROTOTYPE_T233 = 233,
DRV_MXT336T_OBJECT_SPT_PROTOTYPE_T234 = 234,
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1138
DRV_MXT336T_OBJECT_SPT_PROTOTYPE_T235 = 235,
DRV_MXT336T_OBJECT_SPT_PROTOTYPE_T236 = 236,
DRV_MXT336T_OBJECT_SPT_PROTOTYPE_T237 = 237,
DRV_MXT336T_OBJECT_SPT_PROTOTYPE_T238 = 238,
DRV_MXT336T_OBJECT_SPT_PROTOTYPE_T239 = 239,
DRV_MXT336T_OBJECT_RESERVED_T255 = 255
} DRV_MXT336T_OBJECT_TYPE;
Description
Enumeration DRV_MXT336T_OBJECT_TYPE
The MAxtouch devices follow a Object protocol for their driver implementation. This makes it possible to implement a generic driver for many
maxtouch devices. The device communicates the different properties or status like touch messages etc with the driver through an Object table.
The different types of objects associated with the maxtouch device are listed in the enum below.
Remarks
None.
DRV_MXT_HANDLE_INVALID Macro
Definition of an invalid handle.
File
drv_mxt.h
C
#define DRV_MXT_HANDLE_INVALID ((DRV_MXT_HANDLE)(-1))
Description
MXT Driver Invalid Handle
This is the definition of an invalid handle. An invalid handle is is returned by DRV_MXT_Open() and DRV_MXT_Close() functions if the request
was not successful.
Remarks
None.
_DRV_MXT336T_H Macro
File
drv_mxt336t.h
C
#define _DRV_MXT336T_H
Description
This is macro _DRV_MXT336T_H.
DRV_MXT_I2C_MASTER_READ_ID Macro
MXT input read, I2C address from where master reads touch input data.
File
drv_mxt.h
C
#define DRV_MXT_I2C_MASTER_READ_ID 0x4B
Description
MXT Driver Module Master Input Read I2C address
This constant defines the MXT touch input read I2C address. This address is used as I2C address to read Touch input from MXT Touch controller.
Remarks
This constant should be used in place of hard-coded numeric literals.
This value is derived from device-specific data sheets.
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1139
DRV_MXT_I2C_MASTER_WRITE_ID Macro
MXT command register write, I2C address where master sends the commands.
File
drv_mxt.h
C
#define DRV_MXT_I2C_MASTER_WRITE_ID 0x4A
Description
MXT Driver Module Master Command Write I2C Address
This constant defines the MXT command register I2C write address. This address is used as I2C address to write commands into MXT Touch
controller register.
Remarks
This constant should be used in place of hard-coded numeric literals. This value is derived from device-specific data sheets.
DRV_MXT_I2C_READ_FRAME_SIZE Macro
I2C Frame size for reading MXT touch input.
File
drv_mxt.h
C
#define DRV_MXT_I2C_READ_FRAME_SIZE 7
Description
MXT Driver Module I2C Frame Size
This constant identifies the size of I2C frame required to read from MXT touch controller. MXT notifies the availability of input data through interrupt
pin.
Remarks
This constant should be used in place of hard-coded numeric literals. This value is derived from device-specific data sheets.
DRV_MXT_INDEX_0 Macro
MXT driver index definitions.
File
drv_mxt.h
C
#define DRV_MXT_INDEX_0 0
Description
MXT Driver Module Index Numbers
These constants provide the MXT driver index definitions.
Remarks
These constants should be used in place of hard-coded numeric literals. These values should be passed into the DRV_MXT_Initialize and
DRV_MXT_Open functions to identify the driver instance in use.
DRV_MXT_INDEX_1 Macro
File
drv_mxt.h
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1140
C
#define DRV_MXT_INDEX_1 1
Description
This is macro DRV_MXT_INDEX_1.
DRV_MXT_INDEX_COUNT Macro
Number of valid Touch controller MXT driver indices.
File
drv_mxt.h
C
#define DRV_MXT_INDEX_COUNT 2
Description
MXT Driver Module Index Count
This constant identifies the number of valid Touch Controller MXT driver indices.
Remarks
This constant should be used in place of hard-coded numeric literals. This value is derived from device-specific header files defined as part of the
peripheral libraries.
DRV_MXT336T_HANDLE_INVALID Macro
Definition of an invalid handle.
File
drv_mxt336t.h
C
#define DRV_MXT336T_HANDLE_INVALID ((DRV_MXT336T_HANDLE)(-1))
Description
MXT336T Driver Invalid Handle
This is the definition of an invalid handle. An invalid handle is is returned by DRV_MXT336T_Open() and DRV_MXT336T_Close() functions if the
request was not successful.
Remarks
None.
DRV_MXT336T_I2C_FRAME_SIZE Macro
I2C Frame size for reading MXT336T touch input.
File
drv_mxt336t.h
C
#define DRV_MXT336T_I2C_FRAME_SIZE 32
Description
MXT336T Driver Module I2C Frame Size
This constant identifies the size of I2C frame required to read from MXT336T touch controller. MXT336T notifies the availability of input data
through interrupt pin.
Remarks
This constant should be used in place of hard-coded numeric literals. This value is derived from device-specific data sheets.
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1141
DRV_MXT336T_I2C_MASTER_READ_ID Macro
MXT336T input read, I2C address from where master reads touch input data.
File
drv_mxt336t.h
C
#define DRV_MXT336T_I2C_MASTER_READ_ID 0x95
Description
MXT336T Driver Module Master Input Read I2C address
This constant defines the MXT336T touch input read I2C address. This address is used as I2C address to read Touch input from MXT336T Touch
controller.
Remarks
This constant should be used in place of hard-coded numeric literals.
This value is derived from device-specific data sheets.
DRV_MXT336T_I2C_MASTER_WRITE_ID Macro
MXT336T command register write, I2C address where master sends the commands.
File
drv_mxt336t.h
C
#define DRV_MXT336T_I2C_MASTER_WRITE_ID 0x94
Description
MXT336T Driver Module Master Command Write I2C Address
This constant defines the MXT336T command register I2C write address. This address is used as I2C address to write commands into MXT336T
Touch controller register.
Remarks
This constant should be used in place of hard-coded numeric literals. This value is derived from device-specific data sheets.
DRV_MXT336T_I2C_READ_ID_FRAME_SIZE Macro
File
drv_mxt336t.h
C
#define DRV_MXT336T_I2C_READ_ID_FRAME_SIZE 8
Description
This is macro DRV_MXT336T_I2C_READ_ID_FRAME_SIZE.
DRV_MXT336T_INDEX_0 Macro
MXT336T driver index definitions.
File
drv_mxt336t.h
C
#define DRV_MXT336T_INDEX_0 0
Description
MXT336T Driver Module Index Numbers
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1142
These constants provide the MXT336T driver index definitions.
Remarks
These constants should be used in place of hard-coded numeric literals. These values should be passed into the DRV_MXT336T_Initialize and
DRV_MXT336T_Open functions to identify the driver instance in use.
DRV_MXT336T_INDEX_1 Macro
File
drv_mxt336t.h
C
#define DRV_MXT336T_INDEX_1 1
Description
This is macro DRV_MXT336T_INDEX_1.
DRV_MXT336T_INDEX_COUNT Macro
Number of valid Touch controller MXT336T driver indices.
File
drv_mxt336t.h
C
#define DRV_MXT336T_INDEX_COUNT 2
Description
MXT336T Driver Module Index Count
This constant identifies the number of valid Touch Controller MXT336T driver indices.
Remarks
This constant should be used in place of hard-coded numeric literals. This value is derived from device-specific header files defined as part of the
peripheral libraries.
t100_event Enumeration
Types of touch events reported by the Maxtouch Multi touch object
File
drv_mxt.h
C
enum t100_event {
MXT_T100_EVENT_NO_EVENT = 0,
MXT_T100_EVENT_MOVE = 1,
MXT_T100_EVENT_UNSUP = 2,
MXT_T100_EVENT_SUP = 3,
MXT_T100_EVENT_DOWN = 4,
MXT_T100_EVENT_UP = 5,
MXT_T100_EVENT_UNSUPSUP = 6,
MXT_T100_EVENT_UNSUPUP = 7,
MXT_T100_EVENT_DOWNSUP = 8,
MXT_T100_EVENT_DOWNUP = 9
};
Description
Enumeration: t100_event
The maxtouch multi touch object DRV_MXT336T_OBJECT_TOUCH_MULTITOUCHSCREEN_T100 return a number of different types of touch
events. Each touch event has a return type associated with it. These are listed in this enum. These events are returned in the touch status
message associated with the multi touch object.
Remarks
None.
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1143
t100_type Enumeration
Types of touch types reported by the Maxtouch Multi touch object
File
drv_mxt.h
C
enum t100_type {
MXT_T100_TYPE_FINGER = 1,
MXT_T100_TYPE_PASSIVE_STYLUS = 2,
MXT_T100_TYPE_ACTIVE_STYLUS = 3,
MXT_T100_TYPE_HOVERING_FINGER = 4,
MXT_T100_TYPE_GLOVE = 5,
MXT_T100_TYPE_LARGE_TOUCH = 6
};
Description
Enumeration: t100_type
The maxtouch multi touch object DRV_MXT336T_OBJECT_TOUCH_MULTITOUCHSCREEN_T100 return a number of different types of touch
types. These are listed in this enum. The touch type is returned in the touch status message associated with the multi touch object.
Remarks
None.
DRV_MXT336T_T100_XRANGE Macro
MXT336T Driver Object Register Adresses for the registers being read in the driver
File
drv_mxt336t.h
C
#define DRV_MXT336T_T100_XRANGE 13
Description
MXT336T Driver Object Register Adresses for the registers being read in the driver
MXT336T Objects have different registers that contain certain values regarding display resoltuion etc. These register addresses are used to read
the values from object tables.
Remarks
This constant should be used in place of hard-coded numeric literals.
This value is derived from device-specific protocol guides.
DRV_MXT336T_T100_YRANGE Macro
File
drv_mxt336t.h
C
#define DRV_MXT336T_T100_YRANGE 24
Description
This is macro DRV_MXT336T_T100_YRANGE.
Files
Files
Name Description
drv_mxt.h Touch controller MXT Driver interface header file.
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1144
drv_mxt336t.h Touch controller MXT336T Driver interface header file.
Description
drv_mxt.h
Touch controller MXT Driver interface header file.
Enumerations
Name Description
t100_event Types of touch events reported by the Maxtouch Multi touch object
t100_type Types of touch types reported by the Maxtouch Multi touch object
DRV_MXT_MODULE_ID Number of valid MXT driver indices.
DRV_MXT_TASK_STATE Enumeration defining MXT touch controller driver task state.
Functions
Name Description
DRV_MXT_Close Closes an opened instance of the MXT driver.
Implementation: Dynamic
DRV_MXT_Deinitialize Deinitializes the specified instance of the MXT driver module.
Implementation: Dynamic
DRV_MXT_Initialize Initializes the MXT instance for the specified driver index.
Implementation: Dynamic
DRV_MXT_MaxtouchEventCallback
DRV_MXT_Open Opens the specified MXT driver instance and returns a handle to it.
Implementation: Dynamic
DRV_MXT_ReadRequest Sends a read request to I2C bus driver and adds the read task to queue.
Implementation: Dynamic
DRV_MXT_Status Provides the current status of the MXT driver module.
Implementation: Dynamic
DRV_MXT_Tasks Maintains the driver's state machine and implements its task queue processing.
Implementation: Dynamic
DRV_MXT_TouchDataRead Notifies the driver that the current touch data has been read
DRV_MXT_TouchGetX Returns the x coordinate of touch input.
Implementation: Dynamic
DRV_MXT_TouchGetY Returns the y coordinate of touch input.
Implementation: Dynamic
DRV_MXT_TouchStatus Returns the status of the current touch input.
Macros
Name Description
DRV_MXT_HANDLE_INVALID Definition of an invalid handle.
DRV_MXT_I2C_MASTER_READ_ID MXT input read, I2C address from where master reads touch input data.
DRV_MXT_I2C_MASTER_WRITE_ID MXT command register write, I2C address where master sends the commands.
DRV_MXT_I2C_READ_FRAME_SIZE I2C Frame size for reading MXT touch input.
DRV_MXT_INDEX_0 MXT driver index definitions.
DRV_MXT_INDEX_1 This is macro DRV_MXT_INDEX_1.
DRV_MXT_INDEX_COUNT Number of valid Touch controller MXT driver indices.
Structures
Name Description
_DRV_MXT_CLIENT_OBJECT MXT Driver client object maintaining client data.
DRV_MXT_CLIENT_OBJECT MXT Driver client object maintaining client data.
DRV_MXT_INIT Defines the data required to initialize or reinitialize the MXT driver
DRV_MXT_OBJECT Defines the data structure maintaining MXT driver instance object.
DRV_MXT_TASK_QUEUE Defines the MXT Touch Controller driver task data structure.
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1145
Types
Name Description
DRV_MXT_HANDLE Touch screen controller MXT driver handle.
Description
Touch Controller MXT Driver Interface File
This header file describes the macros, data structure and prototypes of the touch controller MXT driver interface.
File Name
drv_MXT.c
drv_mxt336t.h
Touch controller MXT336T Driver interface header file.
Enumerations
Name Description
DRV_MXT336T_OBJECT_TYPE The enum lists the different objects supported by the maxtouch device.
Functions
Name Description
DRV_MXT336T_Close Closes an opened instance of the MXT336T driver.
Implementation: Dynamic
DRV_MXT336T_CloseObject Closes an opened instance of the MXT336T client object
DRV_MXT336T_Deinitialize Deinitializes the specified instance of the MXT336T driver module.
Implementation: Dynamic
DRV_MXT336T_DEVICE_ClientObjectEventHandlerSet Sets the event handler for a MXT336T client object
DRV_MXT336T_Initialize Initializes the MXT336T instance for the specified driver index
DRV_MXT336T_Open Opens the specified MXT336T driver instance and returns a handle to it.
Implementation: Dynamic
DRV_MXT336T_OpenObject Opens the specified MXT336T object driver instance and returns a
handle to it.
Implementation: Dynamic
DRV_MXT336T_ReadRequest Sends a read request to I2C bus driver and adds the read task to queue.
Implementation: Dynamic
DRV_MXT336T_Status Provides the current status of the MXT336T driver module.
Implementation: Dynamic
DRV_MXT336T_Tasks Maintains the driver's state machine and implements its task queue
processing.
Implementation: Dynamic
Macros
Name Description
_DRV_MXT336T_H This is macro _DRV_MXT336T_H.
DRV_MXT336T_HANDLE_INVALID Definition of an invalid handle.
DRV_MXT336T_I2C_FRAME_SIZE I2C Frame size for reading MXT336T touch input.
DRV_MXT336T_I2C_MASTER_READ_ID MXT336T input read, I2C address from where master reads touch input data.
DRV_MXT336T_I2C_MASTER_WRITE_ID MXT336T command register write, I2C address where master sends the
commands.
DRV_MXT336T_I2C_READ_ID_FRAME_SIZE This is macro DRV_MXT336T_I2C_READ_ID_FRAME_SIZE.
DRV_MXT336T_INDEX_0 MXT336T driver index definitions.
DRV_MXT336T_INDEX_1 This is macro DRV_MXT336T_INDEX_1.
DRV_MXT336T_INDEX_COUNT Number of valid Touch controller MXT336T driver indices.
DRV_MXT336T_T100_XRANGE MXT336T Driver Object Register Adresses for the registers being read in the driver
DRV_MXT336T_T100_YRANGE This is macro DRV_MXT336T_T100_YRANGE.
Volume V: MPLAB Harmony Framework Driver Libraries Help Touch Driver Libraries Help
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1146
Structures
Name Description
DRV_MXT336T_OBJECT_CLIENT_EVENT_DATA This structure maintains the information associated with each msg received or
event that occurs
Types
Name Description
DRV_MXT336T_CLIENT_CALLBACK Pointer to a MXT336T client callback function data type.
DRV_MXT336T_HANDLE Touch screen controller MXT336T driver handle.
DRV_MXT336T_INIT Defines the data required to initialize or reinitialize the MXT336T driver
Description
Touch Controller MXT336T Driver Interface File
This header file describes the macros, data structure and prototypes of the touch controller MXT336T driver interface.
File Name
drv_MXT336T.c
USB Driver Libraries
Common Interface
Provides information on the USB Driver interface that is common to all PIC32 devices.
Description
The USB Driver Common Interface definition specifies the functions and their behavior that a USB Driver must implement so that the driver can be
used by the MPLAB Harmony USB Host and Device Stack.
Note:
The MPLAB Harmony USB Driver for PIC32MX and PIC32MZ devices implements the USB Driver Common Interface.
The USB Driver Common Interface contains functions that are grouped as follows:
• Driver System Functions - These functions are called by MPLAB Harmony to initialize and maintain the operational state of the USB Driver. The
system functions can vary between different PIC32 device USB Drivers. As such, the USB Driver Common Interface does not require these
functions to be of the same type. These functions are not called by the USB Host or Device Stack and therefore are allowed to (and can) vary
across different PIC32 device USB Drivers. A description of these functions, along with a description of how to initialize the USB Driver for
Host, Device or Dual Role operation, is provided in the specific PIC32 device USB Driver help section (see PIC32MX USB Driver and PIC32MZ
USB Driver).
• Driver General Client Functions -These functions are called by the USB Host or Device Stack to gain access to the driver
• Driver Host Mode Client Functions - These functions are called exclusively by the USB Host Stack to operate and access the USB as a Host
• Driver Device Mode Client Functions - These functions are called exclusively by the USB Device Stack to operate and access the USB as a
Device
The USB Driver Common Interface is defined in the \framework\driver\usb\drv_usb.h file. This file contains the data
types and structures that define the interface. Specifically, the DRV_USB_HOST_INTERFACE structure, contained in this file, is the common
interface for USB Driver Host mode functions. It is a structure of function pointers, pointing to functions that define the Driver Host mode Client
functions. The following code example shows this structure and the function pointer it contains.
// *****************************************************************************
/* USB Driver Client Functions Interface (For Host mode)
Summary:
Group of function pointers to the USB Driver Host mode Client Functions.
Description:
This structure is a group of function pointers pointing to the USB Driver
Host mode Client routines. The USB Driver should export this group of
functions so that the Host layer can access the driver functionality.
Remarks:
None.
*/
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1147
typedef struct
{
/* This is a pointer to the driver Open function. This function may be
* called twice in a Dual Role application, once by the Host Stack and then
* by the Device Stack */
DRV_HANDLE (*open)(const SYS_MODULE_INDEX drvIndex, const DRV_IO_INTENT intent);
/* This is pointer to the driver Close function */
void (*close)(DRV_HANDLE handle);
/* This is a pointer to the event call back set function */
void (*eventHandlerSet)(DRV_HANDLE handle, uintptr_t hReferenceData,
DRV_USB_EVENT_CALLBACK eventHandler);
/* This is a pointer to the Host IRP submit function */
USB_ERROR (*hostIRPSubmit)(DRV_USB_HOST_PIPE_HANDLE pipeHandle, USB_HOST_IRP * irp);
/* This is a pointer to the Host IRP Cancel all function */
void (*hostIRPCancel)(USB_HOST_IRP * irp);
/* This is pointer to the Host event disable function */
bool (*hostEventsDisable)(DRV_HANDLE handle);
/* This is a pointer to the Host event enable function */
void (*hostEventsEnable)(DRV_HANDLE handle, bool eventContext);
/* This is a pointer to the Host pipe setup function */
DRV_USB_HOST_PIPE_HANDLE (*hostPipeSetup)
(
DRV_HANDLE client,
uint8_t deviceAddress,
USB_ENDPOINT endpointAndDirection,
uint8_t hubAddress,
uint8_t hubPort,
USB_TRANSFER_TYPE pipeType,
uint8_t bInterval,
uint16_t wMaxPacketSize,
USB_SPEED speed
);
/* This is a pointer to the Host Pipe Close function */
void (*hostPipeClose)(DRV_USB_HOST_PIPE_HANDLE pipeHandle);
/* This is a pointer to the Host Root Hub functions */
DRV_USB_ROOT_HUB_INTERFACE rootHubInterface;
} DRV_USB_HOST_INTERFACE;
The DRV_USB_DEVICE_INTERFACE structure, contained in this file, is the common interface for USB Driver Device mode functions. It is a
structure of function pointers, pointer to functions that define the Driver Device mode Client functions. The following code example shows this
structure and the function pointer it contains.
// *****************************************************************************
/* USB Driver Client Functions Interface (For Device Mode)
Summary:
Group of function pointers to the USB Driver Device Mode Client Functions.
Description:
This structure is a group of function pointers pointing to the USB Driver
Device Mode Client routines. The USB Driver should export this group of
functions so that the Device Layer can access the driver functionality.
Remarks:
None.
*/
typedef struct
{
/* This is a pointer to the driver Open function */
DRV_HANDLE (*open)(const SYS_MODULE_INDEX drvIndex, const DRV_IO_INTENT intent);
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1148
/* This is pointer to the driver Close function */
void (*close)(DRV_HANDLE handle);
/* This is a pointer to the event call back set function */
void (*eventHandlerSet)(DRV_HANDLE handle, uintptr_t hReferenceData,
DRV_USB_EVENT_CALLBACK eventHandler);
/* This is a pointer to the device address set function */
void (*deviceAddressSet)(DRV_HANDLE handle, uint8_t address);
/* This is a pointer to the device current speed get function */
USB_SPEED (*deviceCurrentSpeedGet)(DRV_HANDLE handle);
/* This is a pointer to the SOF Number get function */
uint16_t (*deviceSOFNumberGet)(DRV_HANDLE handle);
/* This is a pointer to the device attach function */
void (*deviceAttach)(DRV_HANDLE handle);
/* This is a pointer to the device detach function */
void (*deviceDetach)(DRV_HANDLE handle);
/* This is a pointer to the device endpoint enable function */
USB_ERROR (*deviceEndpointEnable)(DRV_HANDLE handle, USB_ENDPOINT endpoint,
USB_TRANSFER_TYPE transferType, uint16_t endpointSize);
/* This is a pointer to the device endpoint disable function */
USB_ERROR (*deviceEndpointDisable)(DRV_HANDLE handle, USB_ENDPOINT endpoint);
/* This is a pointer to the device endpoint stall function */
USB_ERROR (*deviceEndpointStall)(DRV_HANDLE handle, USB_ENDPOINT endpoint);
/* This is a pointer to the device endpoint stall clear function */
USB_ERROR (*deviceEndpointStallClear)(DRV_HANDLE handle, USB_ENDPOINT endpoint);
/* This is pointer to the device endpoint enable status query function */
bool (*deviceEndpointIsEnabled)(DRV_HANDLE handle, USB_ENDPOINT endpoint);
/* This is pointer to the device endpoint stall status query function */
bool (*deviceEndpointIsStalled)(DRV_HANDLE handle, USB_ENDPOINT endpoint);
/* This is a pointer to the device IRP submit function */
USB_ERROR (*deviceIRPSubmit)(DRV_HANDLE handle, USB_ENDPOINT endpoint,
USB_DEVICE_IRP * irp);
/* This is a pointer to the device IRP Cancel all function */
USB_ERROR (*deviceIRPCancelAll)(DRV_HANDLE handle, USB_ENDPOINT endpoint);
/* This is a pointer to the device remote wakeup start function */
void (*deviceRemoteWakeupStart)(DRV_HANDLE handle);
/* This is a pointer to the device remote wakeup stop function */
void (*deviceRemoteWakeupStop)(DRV_HANDLE handle);
/* This is a pointer to the device Test mode enter function */
USB_ERROR (*deviceTestModeEnter)(DRV_HANDLE handle, USB_TEST_MODE_SELECTORS testMode);
} DRV_USB_DEVICE_INTERFACE;
Both of these structures also contain pointers to General Client functions. The specific PIC32 device USB Driver allocates and initializes such a
structure. The following code example shows how the PIC32MX USB Host mode Driver allocates and initializes the
DRV_USB_HOST_INTERFACE structure. This code is contained in the
\framework\driver\usb\usbhs\src\dynamic\drv_usbfs_host.c file.
/**********************************************************
* This structure is a set of pointer to the USBFS driver
* functions. It is provided to the Host layer as the
* interface to the driver.
* *******************************************************/
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1149
DRV_USB_HOST_INTERFACE gDrvUSBFSHostInterface =
{
.open = DRV_USBFS_Open,
.close = DRV_USBFS_Close,
.eventHandlerSet = DRV_USBFS_ClientEventCallBackSet,
.hostIRPSubmit = DRV_USBFS_HOST_IRPSubmit,
.hostIRPCancel = DRV_USBFS_HOST_IRPCancel,
.hostPipeSetup = DRV_USBFS_HOST_PipeSetup,
.hostPipeClose = DRV_USBFS_HOST_PipeClose,
.hostEventsDisable = DRV_USBFS_HOST_EventsDisable,
.hostEventsEnable = DRV_USBFS_HOST_EventsEnable,
.rootHubInterface.rootHubPortInterface.hubPortReset = DRV_USBFS_HOST_ROOT_HUB_PortReset,
.rootHubInterface.rootHubPortInterface.hubPortSpeedGet =
DRV_USBFS_HOST_ROOT_HUB_PortSpeedGet,
.rootHubInterface.rootHubPortInterface.hubPortResetIsComplete =
DRV_USBFS_HOST_ROOT_HUB_PortResetIsComplete,
.rootHubInterface.rootHubPortInterface.hubPortSuspend = DRV_USBFS_HOST_ROOT_HUB_PortSuspend,
.rootHubInterface.rootHubPortInterface.hubPortResume = DRV_USBFS_HOST_ROOT_HUB_PortResume,
.rootHubInterface.rootHubMaxCurrentGet = DRV_USBFS_HOST_ROOT_HUB_MaximumCurrentGet,
.rootHubInterface.rootHubPortNumbersGet = DRV_USBFS_HOST_ROOT_HUB_PortNumbersGet,
.rootHubInterface.rootHubSpeedGet = DRV_USBFS_HOST_ROOT_HUB_BusSpeedGet,
.rootHubInterface.rootHubInitialize = DRV_USBFS_HOST_ROOT_HUB_Initialize,
.rootHubInterface.rootHubOperationEnable = DRV_USBFS_HOST_ROOT_HUB_OperationEnable,
.rootHubInterface.rootHubOperationIsEnabled = DRV_USBFS_HOST_ROOT_HUB_OperationIsEnabled,
};
Similarly, the PIC32MX USB Device mode Driver allocates and initializes the DRV_USB_DEVICE_INTERFACE structure. This can be reviewed in
the \framework\driver\usb\usbhs\src\dynamic\drv_usbfs_device.c file.
/*****************************************************
* This structure is a pointer to a set of USB Driver
* Device mode functions. This set is exported to the
* Device Layer when the Device Layer must use the
* PIC32MX USB Controller.
******************************************************/
DRV_USB_DEVICE_INTERFACE gDrvUSBFSDeviceInterface =
{
.open = DRV_USBFS_Open,
.close = DRV_USBFS_Close,
.eventHandlerSet = DRV_USBFS_ClientEventCallBackSet,
.deviceAddressSet = DRV_USBFS_DEVICE_AddressSet,
.deviceCurrentSpeedGet = DRV_USBFS_DEVICE_CurrentSpeedGet,
.deviceSOFNumberGet = DRV_USBFS_DEVICE_SOFNumberGet,
.deviceAttach = DRV_USBFS_DEVICE_Attach,
.deviceDetach = DRV_USBFS_DEVICE_Detach,
.deviceEndpointEnable = DRV_USBFS_DEVICE_EndpointEnable,
.deviceEndpointDisable = DRV_USBFS_DEVICE_EndpointDisable,
.deviceEndpointStall = DRV_USBFS_DEVICE_EndpointStall,
.deviceEndpointStallClear = DRV_USBFS_DEVICE_EndpointStallClear,
.deviceEndpointIsEnabled = DRV_USBFS_DEVICE_EndpointIsEnabled,
.deviceEndpointIsStalled = DRV_USBFS_DEVICE_EndpointIsStalled,
.deviceIRPSubmit = DRV_USBFS_DEVICE_IRPSubmit,
.deviceIRPCancelAll = DRV_USBFS_DEVICE_IRPCancelAll,
.deviceRemoteWakeupStop = DRV_USBFS_DEVICE_RemoteWakeupStop,
.deviceRemoteWakeupStart = DRV_USBFS_DEVICE_RemoteWakeupStart,
.deviceTestModeEnter = NULL
};
A pointer to the DRV_USB_HOST_INTERFACE structure is passed to the USB Host Stack as part of USB Host Stack initialization. The following
code example shows how this is done.
/********************************************************************************
* This is a table of the USB Host mode drivers that this application will
* support. Also contained in the driver index. In this example, the
* application will want to use instance 0 of the PIC32MX USB Full-Speed driver.
* *****************************************************************************/
const USB_HOST_HCD hcdTable =
{
.drvIndex = DRV_USBFS_INDEX_0,
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1150
.hcdInterface = DRV_USBFS_HOST_INTERFACE
};
/* Here the pointer to the USB Driver Common Interface is provided to the USB
* Host Layer via the hostControllerDrivers member of the Host Layer
* Initialization data structure. */
const USB_HOST_INIT usbHostInitData =
{
.nTPLEntries = 1 ,
.tplList = (USB_HOST_TPL_ENTRY *)USBTPList,
.hostControllerDrivers = (USB_HOST_HCD *)&hcdTable
};
A pointer to the DRV_USB_DEVICE_INTERFACE structure is passed to the USB Device Stack as part of the USB Device Stack initialization. The
Host Stack and Device Stack then access the driver functions through the function pointers contained in these structures.
The Driver General Client, Host mode and Device mode Client functions are described in this section. Any references to a USB Driver Client in the
following sections, implies the client is a USB Host Stack and/or the USB Device Stack.
Driver General Client Functions
Provides information on the General Client functions for the USB Driver.
Description
The DRV_USB_HOST_INTERFACE and the DRV_USB_DEVICE_INTERFACE structures contain pointers to the USB Driver’s General Client
functions. These functions are not specific to the operation mode (Host, Device, or Dual Role) of the driver. A USB Driver must implement these
functions and ensure that the Host or Device Stack can access these functions through the driver’s common interface structures. The common
interface contains three general client functions:
• Driver Open Function
• Driver Close Function
• Driver Event Handler Set Function
Driver Open Function
The open member of the DRV_USB_HOST_INTERFACE and the DRV_USB_DEVICE_INTERFACE structures should point to the USB Driver
Open function. The signature of the Open function is as follows:
DRV_HANDLE (*open)(const SYS_MODULE_INDEX drvIndex, const DRV_IO_INTENT intent);
The USB Driver Open function must match this signature. The Driver Client uses the USB Driver index (drvIndex) to specify the instance of the
USB module that Host Stack or the Device Stack should open. The USB Driver should ignore the intent parameter. The function should return a
driver handle. If the driver is not ready to be opened, it should return an invalid handle (DRV_HANDLE_INVALID). In such a case, the client will
continue trying to open the driver by calling the Open function again. The driver may also fail to open for an invalid index parameter or if USB
module is in an error condition.
When supporting Dual Role operation, both the Host Stack and Device Stack will call the Driver Open function in one application. The USB Driver
must support multiple calls to the Open function in the same application. The Open function should be thread-safe.
Driver Close Function
The close member of the DRV_USB_HOST_INTERFACE and the DRV_USB_DEVICE_INTERFACE structures should point to the USB Driver
Close function. The signature of the Close function is as follows:
void (*close)(DRV_HANDLE handle);
The USB Driver Close function must match this signature. The Driver Client passes the handle obtained from the Driver Open function as a
parameter to the close. The USB Host Stack or USB Device Stack will close the driver only when the stack is deinitialized (which is typically a rare
case). The USB Driver should deallocate any client-related resources in the Close function. If the specified driver handle is not valid, the Close
function should not have any side effects. The USB Driver expects the Close function to be called from the context of the thread in which the driver
was opened; therefore, this function is not expected to be thread-safe.
Driver Event Handler Set Function
The eventHandlerSet member of the DRV_USB_HOST_INTERFACE and the DRV_USB_DEVICE_INTERFACE structures should point to the
USB Driver Event Handler Set function. The signature of the Event Handler Set function is as follows:
void (*eventHandlerSet)(DRV_HANDLE handle, uintptr_t hReferenceData, DRV_USB_EVENT_CALLBACK eventHandler);
The USB Driver Event Handler Set function must match this signature. The signature of the Client Event Handling function should match
DRV_USB_EVENT_CALLBACK. The USB Driver calls this function when it must communicate USB events to the client. The client can set the
eventHandler parameter to NULL if it does not want to receive USB Driver events. The client will receive Host mode events if the USB Driver is
operating in Host mode. It will receive Device mode events if the USB Driver is operating in Device mode. The DRV_USB_EVENT type
enumeration contains all the possible events that the USB Driver would generate. The following code example shows the enumeration.
// *****************************************************************************
/* USB Driver Events Enumeration
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1151
Summary:
Identifies the different events that the USB Driver provides.
Description:
Identifies the different events that the USB Driver provides. The USB Driver
should be able to provide these events.
Remarks:
None.
*/
typedef enum
{
/* Bus error occurred and was reported. This event can be generated in both
* Host and Device mode. */
DRV_USB_EVENT_ERROR = 1,
/* Host has issued a device Reset. This event occurs only in Device mode */
DRV_USB_EVENT_RESET_DETECT,
/* Resume detected while USB in suspend mode. This event can be generated in
* both Host and Device mode. In Host mode, the events occurs when a remote
* wakeup capable device has generated resume signaling. In Device mode,
* this event will occur when the Host has issued resume signaling. */
DRV_USB_EVENT_RESUME_DETECT,
/* This event is generated in Device mode only. It occurs when the Host
* suspends the bus and the bus goes idle. */
DRV_USB_EVENT_IDLE_DETECT,
/* This event is generated in Host mode and Device mode. In Host mode, this
* event occurs when the device has stalled the Host. In Device mode, this
* event occurs when the Host has accessed a stalled endpoint thus
* triggering the device to send a STALL to the Host. */
DRV_USB_EVENT_STALL,
/* This event is generated in Host mode and Device mode. In Device mode,
* this event occurs when a SOF has been generated by the Host. In Host
* mode, this event occurs when controller is about to generate an SOF.
* */
DRV_USB_EVENT_SOF_DETECT,
/* This event is generated in Device mode when the VBUS voltage is above
* VBUS session valid. */
DRV_USB_EVENT_DEVICE_SESSION_VALID,
/* This event is generated in Device mode when the VBUS voltage falls
* below VBUS session valid. */
DRV_USB_EVENT_DEVICE_SESSION_INVALID,
} DRV_USB_EVENT;
This completes the discussion on the Driver General Client Functions.
Driver Host Mode Client Functions
Provides information on the Host mode Client functions for the USB Driver.
Description
The DRV_USB_HOST_INTERFACE structure contains pointers to the USB Driver’s Host mode Client functions. These functions are only
applicable when the USB module is operating as a USB Host. Along with the function pointers to the driver’s Host mode specific functions, the
DRV_USB_HOST_INTERFACE structure also contains another structure of function pointers of the type DRV_USB_ROOT_HUB_INTERFACE.
This structure contains function pointers to the USB Driver’s Root Hub functions. A USB Driver must implement these functions and ensure that
the Host Stack can access these functions through the driver’s DRV_USB_HOST_INTERFACE structure. The Driver Host mode Client functions in
the DRV_USB_HOST_INTERFACE structure are:
• Driver Host Pipe Setup Function
• Driver Host Pipe Close Function
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1152
• Driver Host Events Disable Function
• Driver Host Events Enable Function
• Driver Host IRP Submit Function
• Driver Host IRP Cancel Function
Driver Host Pipe Setup Function
The hostPipeSetup member of the DRV_USB_HOST_INTERFACE structure should point to the USB Driver Host Pipe Setup function. The
signature of the Host Pipe Setup function is as follows:
DRV_USB_HOST_PIPE_HANDLE (*hostPipeSetup) ( DRV_HANDLE client, uint8_t deviceAddress,
USB_ENDPOINT endpointAndDirection, uint8_t hubAddress,
uint8_t hubPort, USB_TRANSFER_TYPE pipeType, uint8_t bInterval,
uint16_t wMaxPacketSize, USB_SPEED speed);
The USB Driver Host mode Pipe Setup function must match this signature. The USB Host Stack calls this function to create a communication pipe
to the attached device. The function parameters define the property of this communication pipe. The driverHandle parameter is the handle to
the driver obtained through the driver Open function. The deviceAddress and the endpointAddress parameters specify the address of the
USB device and the endpoint on this device to which this pipe must connect.
If the device is connected to the Host though a hub, hubAddress and hubPort must specify the address of the hub and port to which the device
is connected. The USB Driver will use these parameters to schedule split transactions if the target device is a Low-Speed or Full-Speed device
and is connected to the Host through a high-speed hub. If the device is connected directly to the Host, these parameters should be set to zero ('0').
The pipeType parameter specifies the type of USB transfers that this pipe would support. The bInterval parameter is interpreted as per the
USB 2.0 Specification based on the transfer type and the speed of the pipe. The wMaxPacketSize parameter defines the maximum size of a
transaction that the driver should use while transporting a transfer on the pipe. The Host layer will use the information obtained from the USB
device descriptors of the attached device to decide the wMaxPacketSize parameter.
The Driver Host Pipe Setup function should be thread-safe, but does not have to be event safe. The Host layer (or the Host Client Drivers) will not,
and should not attempt to create a pipe in an interrupt, and therefore, an event context. The function should return
DRV_USB_PIPE_HANDLE_INVALID if the driver could not open the pipe. The driver may not be able to open a pipe due to incorrect function
parameters or due to lack of resources.
Driver Host Pipe Close Function
The hostPipeClose member of the DRV_USB_HOST_INTERFACE structure should point to the USB Driver Host Pipe Close function. The
signature of the Host Pipe Close function is as follows:
void (*hostPipeClose)(DRV_USB_HOST_PIPE_HANDLE pipeHandle);
The USB Driver Host mode Pipe Close function must match this signature. The USB Host Stack calls this function to close communication pipes.
The pipeHandle parameter is the pipe handle obtained from the Pipe Setup function. The Host Client Driver typically closes pipes when a device
detach was detected. The Client Driver may also close pipes when a device configuration needs to change or when the Client Driver is being
unloaded by the Host. The Pipe Close function has no side effect if the pipe handle is invalid. Closing the pipe will abort all I/O Request Packets
(IRP) that are scheduled on the pipe. Any transaction in progress will complete. The IRP callback functions for each IRP scheduled in the pipe will
be called with a USB_HOST_IRP_STATUS_ABORTED status.
The USB Driver Pipe Close function must be thread-safe and event-safe. The latter requirement allows the Pipe Close function to be called in the
context of the device detach Interrupt Service Routine.
Driver Host Event Disable Function
The hostEventsDisable member of the DRV_USB_HOST_INTERFACE structure should point to the USB Driver Host mode Driver Events
Disable function. The signature of the Events Disable function is as follows:
bool (*hostEventsDisable)(DRV_HANDLE handle);
The USB Driver Host mode Driver Events Disable function must match this signature. The Host Stack will call this function when it wants to
execute a section of code that should not be interrupted by the USB Driver. Calling this function should disable USB Driver event generation. The
handle parameter is set to the driver handle obtained via the driver Open function. The function will return the present state of the event
generation, whether it is enabled or disabled. The Host Stack will pass this value to the USB Driver Host mode Driver Events Enable function when
it needs to enable the driver events.
Driver Host Events Enable Function
The hostEventsEnable member of the DRV_USB_HOST_INTERFACE structure should point to the USB Driver Host mode Driver Events
Enable function. The signature of the events enable function is as follows:
void (*hostEventsEnable)(DRV_HANDLE handle, bool eventContext);
The USB Driver Host mode Driver Events Enable function must match this signature. The USB Host Stack calls this function to re-enable the USB
Driver Host mode Events (if they were enabled) after it called the USB Driver Host mode Events Disable function to disable driver events. The
handle parameter is set to the driver handle obtained via the driver Open function. The eventContext parameter is set to the value returned by
the Host mode Driver Events Disable function. The USB Driver will use the eventContext parameter to restore the event generation status
(enabled or disabled) to what it was when the USB Driver Host mode Driver Events Disable function was called.
Driver Host IRP Submit Function
The hostIRPSubmit member of the DRV_USB_HOST_INTERFACE structure should point to the USB Driver Host IRP Submit function. The
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1153
signature of the IRP Submit function is as follows:
USB_ERROR (*hostIRPSubmit)(DRV_USB_HOST_PIPE_HANDLE pipeHandle, USB_HOST_IRP * irp);
The USB Driver Host IRP Submit function must match this signature. The Host Stack calls this function to submit an IRP to the USB Driver. The
USB Driver provides this mechanism to transfer data between the Host Stack and the attached device. The pipeHandle parameter should be set
to the pipe handle obtained by the Pipe Setup function. The pipe handle specifies the pipe, and therefore, the target device, endpoint, speed and
transfer type, on which the I/O must be processed. The irp parameter should point to the IRP data structure. The IRP data structure will transport
an entire transfer over the pipe. The USB Driver will split up the transfer into transactions based on the parameters specified at the time of pipe
creation. This process does not require Host Stack intervention.
The function will return USB_ERROR_HOST_PIPE_INVALID if the pipe handle is not valid. It will return USB_ERROR_OSAL_FUNCTION if an
error occurred while performing a RTOS-related operation. It will return USB_ERROR_NONE if the IRP was submitted successfully.
The USB Driver will queue the IRP if there is already an IRP being processed on the pipe. The completion of the IRP processing is indicated by
the USB Driver calling the IRP Callback function specified within the IRP. The Host IRP Submit function must be thread-safe and IRP
callback-safe. The Host Stack may resubmit the IRP within the IRP Callback function. The IRP Callback function itself executes within an interrupt
context. The completion status of the IRP will be available in the status member of the IRP when the IRP callback function is invoked.
Driver Host IRP Cancel Function
The hostIRPCancel member of the DRV_USB_HOST_INTERFACE structure should point to the USB Driver Host IRP Cancel function. The
signature of the IRP Cancel function is as follows
void (*hostIRPCancel)(USB_HOST_IRP * irp);
The USB Driver Host IRP Cancel function must match this signature. The Host Stack and Host Client Drivers will call this function to cancel an IRP
that was submitted. The IRP will be aborted successfully if it is not in progress. If the IRP processing has begun, the on-going transaction will
complete and pending transactions in the transfer will be aborted. In either case, the IRP Callback function will be called with the IRP status as
USB_HOST_IRP_STATUS_ABORTED.
Driver Host USB Root Hub Port Interface
Provides information on the Root Hub Port interface of the USB Host Driver.
Description
The rootHubPortInterface member of the DRV_USB_ROOT_HUB_INTERFACE structure should point to the USB Driver Root Hub Port
functions. The data type of this member is USB_HUB_INTERFACE. This data type is a structure containing function pointers pointing to the port
control functions of the root hub. The USB Driver must assign the function pointers in this structure to the root hub port control functions. These
same functions are also exported by a Hub Driver to the USB Host Stack, which allow the Host Stack to control a device regardless of whether it is
connected to a root hub or an external hub. The port functions are valid only when a device is attached to the port. The behavior of these functions
on a port to which no device is connected is not defined. Descriptions of the port control functions are provided, which include:
• Driver Host Hub Port Reset Function
• Driver Host Hub Port Reset Completion Status Function
• Driver Host Hub Port Suspend Function
• Driver Host Hub Port Resume Function
• Driver Host Hub Port Speed Get Function
Driver Host Hub Port Reset Function
The hubPortReset member of the USB_HUB_INTERFACE structure should point to the USB Driver Root Hub Port Reset function. The
signature of this function is as follows:
USB_ERROR (*hubPortReset)(uintptr_t hubAddress, uint8_t port);
The USB Driver Root Hub Port Reset function must follow this signature. This function starts reset signaling on the port. If the device is connected
to the root hub, the USB Host Stack will set the hubAddress parameter to the driver handle obtained through the driver Open function. The USB
Host Stack uses the parent identifier provided by the root hub driver when the USB_HOST_DeviceEnumerate function was called to query the
driver handle that is linked to this root hub. If the device is connected to an external hub, the hubAddress parameter is directly set to the parent
identifier.
For the PIC32MX and PIC32MZ USB Drivers, the port parameter is ignored. For an external hub, this must be set to the port to which the device
is connected. The function returns USB_ERROR_NONE if the function was successful. If the reset signaling is already in progress on the port,
calling this function has no effect. The USB Driver will itself time duration of the reset signal. This does not require USB Host Stack intervention.
The USB Host Stack will call the port reset completion status function to check if the reset signaling has completed. Calling this function on a port
which exists on an external hub will cause the hub driver to issue a control transfer to start the port reset procedure.
Driver Host Hub Port Reset Completion Status Function
The hubPortResetIsComplete member of the USB_HUB_INTERFACE structure should point to the USB Driver Root Hub Port Reset
Completion Status function. The signature of this function is as follows:
bool (*hubPortResetIsComplete)(uintptr_t hubAddress, uint8_t port);
The USB Driver Root Hub Port Reset Completion Status function must follow this signature. The USB Host Stack calls this function to check if the
port reset sequence that was started on a port has completed. The function returns true if the reset signaling has completed. If the device is
connected to the root hub, the USB Host Stack will set the hubAddress parameter to the driver handle obtained through the driver Open function.
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1154
If the device is connected to an external hub, the hubAddress parameter is directly set to the parent identifier.
For the PIC32MX and PIC32MZ USB Drivers, the port parameter is ignored. For an external hub, this parameter must be set to the port to which
the device is connected.
Driver Host Hub Port Suspend Function
The hubPortSuspend member of the USB_HUB_INTERFACE structure should point to the USB Driver Root Hub Port Suspend function. The
signature of this function is as follows:
USB_ERROR(*hubPortSuspend)(uintptr_t hubAddress, uint8_t port);
The USB Driver Root Hub Port Suspend function must follow this signature. The USB Host Stack calls this function to suspend the port. If the
device is connected to the root hub, the USB Host Stack will set the hubAddress parameter to the driver handle obtained through the driver Open
function. If the device is connected to an external hub, the hubAddress parameter is directly set to the parent identifier.
For the PIC32MX and PIC32MZ USB Drivers, the port parameter is ignored. For an external hub, this parameter must be set to the port to which
the device is connected. The function returns USB_ERROR_NONE if the request was successful. Calling this function on a suspended port will not
have any effect.
Driver Host Hub Port Resume Function
The hubPortResume member of the USB_HUB_INTERFACE structure should point to the USB Driver Root Hub Port Resume function. The
signature of this function is as follows:
USB_ERROR(*hubPortResume)(uintptr_t hubAddress, uint8_t port);
The USB Driver Root Hub Port Resume function must follow this signature. The USB Host Stack calls this function to resume a suspended port. If
the device is connected to the root hub, the USB Host Stack will set the hubAddress parameter to the driver handle obtained through the driver
Open function. If the device is connected to an external hub, the hubAddress parameter is directly set to the parent identifier.
For the PIC32MX and PIC32MZ USB Drivers, the port parameter is ignored. For an external hub, this parameter must be set to the port to which
the device is connected. The function returns USB_ERROR_NONE if the request was successful. Calling this function on a port that is not
suspended will not have any effect.
Driver Host Hub Port Speed Get Function
The hubPortSpeedGet member of the USB_HUB_INTERFACE structure should point to the USB Driver Root Hub Port Speed Get function. The
signature of this function is as follows:
USB_SPEED(*hubPortSpeedGet)(uintptr_t hubAddress, uint8_t port);
The USB Driver Root Hub Port Speed Get function must follow this signature. The USB Host Stack calls this function to obtain the USB speed of
the device that is attached to the port. The Host Stack calls this function only after it has completed reset of the port. If the device is connected to
the root hub, the USB Host Stack will set the hubAddress parameter to the driver handle obtained through the driver Open function. If the device
is connected to an external hub, the hubAddress parameter is directly set to the parent identifier.
For the PIC32MX and PIC32MZ USB Drivers, the port parameter is ignored. For an external hub, this parameter must be set to the port to which
the device is connected. The function returns USB_SPEED_ERROR if the request was not successful. It will return the functional USB speed
otherwise.
This concludes the section describing the USB Driver Host mode Client Functions. The USB Driver Device Mode Client Functions are discussed in
the next section.
Driver Host Root Hub Interface
Provides information on the Root Hub interface for the USB Host Driver.
Description
The USB Driver Common Interface requires the USB Driver to be operating in Host mode to provide root hub control functions. If the USB
peripheral does not contain root hub features in hardware, these features must be emulated in software by the driver. The USB peripheral on
PIC32MX and PIC32MZ devices does not contain root hub features; therefore, the USB Driver for these peripherals emulates the root hub
functionality in software. The rootHubInterface member of the DRV_USB_HOST_INTERFACE structure is a structure of type
DRV_USB_ROOT_HUB_INTERFACE. The members of this structure are function pointers to the root hub control functions of the USB Driver.
Along with other Host mode functions, the USB Driver while operating in Host mode must also ensure that the rootHubInterface member of
DRV_USB_HOST_INTERFACE is set up correctly so that the USB Host Stack can access the root hub functions. Descriptions of the function
pointer types in the DRV_USB_ROOT_HUB_INTERFACE include:
• Driver Host Root Hub Speed Get Function
• Driver Host Root Hub Port Numbers Get Function
• Driver Host Root Hub Maximum Current Get Function
• Driver Host Root Hub Operation Enable Function
• Driver Host Root Hub Operation Enable Status Function
• Driver Host Root Hub Initialize Function
Driver Host Root Hub Speed Get Function
The rootHubSpeedGet member of the DRV_USB_ROOT_HUB_INTERFACE structure should point to the USB Driver Root Hub Speed Get
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1155
function. The signature of this function is as follows:
USB_SPEED (*rootHubSpeedGet)(DRV_HANDLE handle);
The USB Driver Root Hub Speed Get function must match this signature. The USB Host Stack calls this function to identify the speed at which the
root hub is operating. The handle parameter is the handle obtained by calling the USB Driver Open function. The operation speed is configured
by the USB Driver initialization and depends on the capability of the USB peripheral. For example, the USB peripheral on PIC32MZ devices
supports both Hi-Speed and Full-Speed Host mode operation. It can be configured through initialization to only operate at Full-Speed. The Root
Hub Speed Get function must return the USB speed at which the USB peripheral is operating. This should not be confused with the speed of the
attached device.
Driver Host Root Hub Port Numbers Get Function
The rootHubPortNumbersGet member of the DRV_USB_ROOT_HUB_INTERFACE structure should point to the USB Driver Root Hub Port
Numbers Get function. The signature of this function is as follows:
USB_SPEED (*rootHubSpeedGet)(DRV_HANDLE handle);
The USB Driver Root Hub Speed Get function must match this signature. This function should return the number of ports that the root hub
contains. On the USB peripheral for both PIC32MZ and PIC32MX devices, this value is always '1'.
Driver Host Root Hub Maximum Current Get Function
The rootHubMaxCurrentGet member of the DRV_USB_ROOT_HUB_INTERFACE structure should point to the USB Driver Root Hub
Maximum Current Get function. The signature of this function is as follows:
uint32_t (*rootHubMaxCurrentGet)(DRV_HANDLE handle);
The USB Driver Root Hub Maximum Current Get function must match this signature. This function returns the maximum VBUS current that the
root hub can provide. The USB Host Stack calls this function to know the maximum current that the root hub VBUS power supply can provide. This
value is then used to determine if the Host can support the current requirements of the attached device. The handle parameter is the driver
handle obtained by calling the driver Open function.
The PIC32MX and the PIC32MZ USB peripherals cannot supply VBUS. The root hub driver only switches the VBUS supply. The current rating of
the VBUS is specified through the USB Driver initialization. The root hub maximum current get function implementation in these drivers returns this
value to the Host Stack.
Driver Host Root Hub Operation Enable Function
The rootHubOperationEnable member of the DRV_USB_ROOT_HUB_INTERFACE structure should point to the USB Driver Root Hub
Operation Enable function. The signature of this function is as follows"
void (*rootHubOperationEnable)(DRV_HANDLE handle, bool enable);
The USB Driver Root Hub Operation Enable function must match this signature. The USB Host Stack calls this function when it ready to receive
device attach events from the root hub. Calling this function will cause the USB Driver root hub functionality to enable detection of device attach
and detach. The USB Driver will then raise events to the USB Host Stack. The handle parameter is the driver handle obtained by calling the
driver Open function. Setting the enable parameter to true enables the root hub operation. Setting the enable parameter to false disables the
root hub operation.
Driver Host Root Hub Operation Enable Status Function
The rootHubOperationIsEnabled member of the DRV_USB_ROOT_HUB_INTERFACE structure should point to the USB Driver Root Hub
Operation Enable Status function. The signature of this function is as follows:
bool (*rootHubOperationIsEnabled)(DRV_HANDLE handle);
The USB Driver Root Hub Operation Enable Status function must match this signature. This USB Host Stack calls this function after calling the
operation enable function to check if this has completed. The function returns true if the operation enable function has completed. The USB Host
Stack will call this function periodically until it returns true.
Driver Host Root Hub Initialize Function
The rootHubInitialize member of the DRV_USB_ROOT_HUB_INTERFACE structure should point to the USB Driver Root Hub Initialize
function. The signature of this function is as follows:
void (*rootHubInitialize)(DRV_HANDLE handle, USB_HOST_DEVICE_OBJ_HANDLE usbHostDeviceInfo);
The USB Driver Root Hub Initialize function must match this signature. The USB Host Stack calls this function to assign a device identifier
(usbHostDeviceInfo) to the root hub. This function is called before the Host Stack enables the root hub operation. The USB Driver root hub should
use this identifier as the parent identifier when it calls the USB_HOST_DeviceEnumerate function to enumerate the attached device. At the time of
enumeration, the USB Host Stack will use this parent identifier to identify the parent hub (whether root hub or external hub) of the attached device.
The USB Driver root hub should retain the usbHostDeviceInfo parameter for the life time of its operation.
Driver Device Mode Client Functions
Provides information on the USB Driver Device mode Client functions.
Description
The DRV_USB_DEVICE_INTERFACE structure contains pointers to the USB Driver’s Device mode Client Functions. These functions are only
applicable when the USB module is operating as a USB Device. A USB Driver must implement these functions and ensure that the Device Stack
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1156
can access these functions through the driver’s DRV_USB_DEVICE_INTERFACE structure. Descriptions of the Driver Device Mode Client
functions in the DRV_USB_DEVICE_INTERFACE structure include:
• Driver Device Address Set Function
• Driver Device Current Speed Get Function
• Driver Device SOF Number Get Function
• Driver Device Attach Function
• Driver Device Detach Function
• Driver Device Endpoint Enable Function
• Driver Device Endpoint Disable Function
• Driver Device Endpoint Stall Function
• Driver Device Endpoint Stall Clear Function
• Driver Device Endpoint Enable Status Function
• Driver Device Endpoint Stall Status Function
• Driver Device IRP Submit Function
• Driver Device IRP Cancel All Function
• Driver Device IRP Cancel Function
• Driver Device Remote Wakeup Start Function
• Driver Device Remote Wakeup Stop Function
• Driver Device Test Mode Enter Function
The PIC32MZ and the PIC32MX USB peripheral drivers implement the Device mode functions and export these functions to the Device Stack
though their respective DRV_USB_DEVICE_INTERFACE structure.
Driver Device Address Set Function
The deviceAddressSet member of the DRV_USB_DEVICE_INTERFACE structure should point to the USB Driver Device Address Set function.
The signature of this function is as follows:
void (*deviceAddressSet)(DRV_HANDLE handle, uint8_t address);
The USB Driver Device Address Set Function should match this signature. The USB Device Stack will call this function to set the Device USB
Address. The function will be called in an interrupt context and hence the function implementation must be interrupt-safe. The handle parameter
is the driver handle obtained from calling the driver Open function. The address parameter is the address provided by the USB Host through the
Set Device Address Standard request.
Driver Device Current Speed Get Function
The deviceCurrentSpeedGet member of the DRV_USB_DEVICE_INTERFACE structure should point to the USB Driver Current Speed Get
function. The signature of this function is as follows:
USB_SPEED (*deviceCurrentSpeedGet)(DRV_HANDLE handle);
The USB Driver Device Current Speed Get function should match this signature. The USB Device Stack will call this function to obtain the speed
at which the device has connected to the USB. It will call this function after reset signaling has completed. The handle parameter is driver handle
obtained from calling the driver Open function. This function is called in an interrupt context and should be interrupt-safe.
Driver Device SOF Number Get Function
The deviceSOFNumberGet member of the DRV_USB_DEVICE_INTERFACE structure should point to the USB Driver Start-Of-Frame Number
Get function. The signature of this function is as follows:
uint16_t (*deviceSOFNumberGet)(DRV_HANDLE handle);
The USB Driver SOF Number Get function should match this signature. The USB Device Stack will call this function to obtain the current SOF
number. The USB peripheral uses a 16 bit counter to count the number of SOFs that have occurred since USB reset. This value is returned along
with the Device Stack Start of Frame event. This function is called from an interrupt context and should be interrupt-safe. The handle parameter
is the driver handle obtained from calling the driver Open function.
Driver Device Attach Function
The deviceAttach member of the DRV_USB_DEVICE_INTERFACE structure should point to the USB Driver Attach function. The signature of
this function is as follows:
uint16_t(*deviceAttach)(DRV_HANDLE handle);
The USB Driver Attach function should match this signature. The USB Device Stack will call this function when the Device application calls the
USB Device Stack Device Attach function. The USB Driver will enable the required signaling resistors for indicate attach to the Host. The
application could call this function in response to a VBUS power available event. This function must be interrupt-safe. The handle parameter is
the driver handle obtained from calling the driver Open function.
Driver Device Detach Function
The deviceDetach member of the DRV_USB_DEVICE_INTERFACE structure should point to the USB Driver Detach function. The signature of
this function is as follows:
uint16_t(*deviceDetach)(DRV_HANDLE handle);
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1157
The USB Driver Detach function should match this signature. The USB Device Stack will call this function when the Device application calls the
USB Device Stack Device Detach function. The USB Driver will disable the required signaling resistors to indicate detach to the Host. The
application could call this function in response to a VBUS power not available event. This function should be interrupt-safe. The handle parameter
is driver handle obtained from calling the driver Open function.
Driver Device Endpoint Enable Function
The deviceEndpointEnable member of the DRV_USB_DEVICE_INTERFACE structure should point to the USB Driver Endpoint Enable
function. The signature of this function is as follows:
USB_ERROR (*deviceEndpointEnable)(DRV_HANDLE handle, USB_ENDPOINT endpoint,
USB_TRANSFER_TYPE transferType, uint16_t endpointSize);
The USB Driver Endpoint Enable function should match this signature. The USB Device Stack Function Driver will call this function when it is
initialized by the USB Device Layer. The Device Layer, on receiving the Set Configuration request from the Host, identifies the function drivers that
are required by the configuration and initializes them. The function drivers will call the endpoint enable function to enable the endpoints required for
their operation. Enabling the endpoint will cause it reply to transaction requests from the Host and accept transfer requests from the device
application.
The handle parameter is the driver handle obtained from calling the driver Open function. The endpoint parameter is the USB endpoint (which
indicates the direction along with endpoint number) that should be enabled. The transferType is the type of the USB transfer that this endpoint will
handle. The endpointSize is the size of the maximum transaction that the endpoint will handle. This should match the endpoint size communicated
to the Host via the device endpoint descriptors.
The function will return USB_ERRROR_NONE if the endpoint was configured successfully. The function will return
USB_ERROR_DEVICE_ENDPOINT_INVALID if the specified endpoint is not provisioned in the system configuration. It will return
USB_ERROR_PARAMETER_INVALID if the driver handle is not valid.
The endpoint enable function will be called in an interrupt context and should be interrupt-safe. It is not expected to be thread safe. For standard
function drivers, the endpoint enable function will be called in the context of the USB Device Layer Client. For vendor USB devices, the vendor
application must call the endpoint enable function in response to and within the context of the device configured event. Again this event itself will
execute in the context of the Device Layer.
Driver Device Endpoint Disable Function
The deviceEndpointDisable member of the DRV_USB_DEVICE_INTERFACE structure should point to the USB Driver Endpoint Disable
function. The signature of this function is as follows:
USB_ERROR (*deviceEndpointDisable)(DRV_HANDLE handle, USB_ENDPOINT endpoint);
The USB Driver Endpoint Disable function should match this signature. The USB Device Stack Function Driver will call this function when it is
deinitialized by the USB Device Layer. The Device Layer will deinitialize function drivers when it receives a USB reset event from the driver or on
receiving the Set Configuration request from the Host with configuration parameter 0. Disabling the endpoint will cause it NAK transaction request
from the Host and not accept transfer requests from the device application.
The handle parameter is the driver handle obtained from calling the driver Open function. The endpoint parameter is the USB endpoint (which
indicates the direction along with endpoint number) that should be disabled.
The function will return USB_ERRROR_NONE if the function executed successfully. The function will return
USB_ERROR_DEVICE_ENDPOINT_INVALID if the specified endpoint is not provisioned in the system configuration. It will return
USB_ERROR_PARAMETER_INVALID if the driver handle is not valid.
The endpoint disable function will be called in an interrupt context and should be interrupt-safe. It is not expected to be thread safe. For standard
function drivers, the endpoint disable function will be called in the context of the USB Device Layer Client. For vendor USB devices, the vendor
application must call the endpoint enable function in response to and within the context of the device reset event. Again this event itself will
execute in the context of the Device Layer. Disabling the endpoint will not cancel any transfers that have been queued against the endpoint. The
function drivers will call the IRP Cancel All function to cancel any pending transfers.
Driver Device Endpoint Stall Function
The deviceEndpointStall member of the DRV_USB_DEVICE_INTERFACE structure should point to the USB Driver Endpoint Stall function.
The signature of this function is as follows:
USB_ERROR (*deviceEndpointStall)(DRV_HANDLE handle, USB_ENDPOINT endpoint);
The USB Driver Endpoint Stall function should match this signature. The USB Device Stack Function Driver will call this function to stall an
endpoint. The Device Layer itself will stall endpoint 0 for several reasons including non-support of the Host request or failure while executing the
request. A function driver will also stall an endpoint for protocol specific reasons. The driver will stall both, receive and transmit directions when
stalling Endpoint 0. The driver will stall the specified direction while stalling a non-zero endpoint.
This function must be thread safe and interrupt safe. Stalling the endpoint will abort all the transfers queued on the endpoint with the completion
status set to USB_DEVICE_IRP_STATUS_ABORTED_ENDPOINT_HALT. The handle parameter is the driver handle obtained from calling the
driver Open function. The endpoint parameter is the USB endpoint (which indicates the direction along with endpoint number) that should be
stalled. The function will return USB_ERRROR_NONE if the function executed successfully. The function will return
USB_ERROR_DEVICE_ENDPOINT_INVALID if the specified endpoint is not provisioned in the system configuration. It will return
USB_ERROR_PARAMETER_INVALID if the driver handle is not valid.
Driver Device Endpoint Stall Clear Function
The deviceEndpointStallClear member of the DRV_USB_DEVICE_INTERFACE structure should point to the USB Driver Endpoint Stall
Clear function. The signature of this function is as follows:
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1158
USB_ERROR (*deviceEndpointStallClear)(DRV_HANDLE handle, USB_ENDPOINT endpoint);
The USB Driver Endpoint Stall Clear function should match this signature. The USB Device Stack Function Driver will call this function to clear the
stall on a non-zero endpoint. The Device Layer will call this function to clear the stall condition on Endpoint 0. Clearing the stall on a non-zero
endpoint will clear all transfers scheduled on the endpoint and transfer completion status will be set to
USB_DEVICE_IRP_STATUS_TERMINATED_BY_HOST. When the stall is cleared, the data toggle for non-zero endpoint will be set to DATA0.
The data toggle on Endpoint 0 OUT endpoint will be set to DATA1. The USB Driver will clear the Stall condition on an endpoint even if it was not
stalled.
This function must be thread safe and interrupt safe. Stalling the endpoint will flush all the transfers queued on the endpoint. The handle
parameter is the driver handle obtained from calling the driver Open function. The endpoint parameter is the USB endpoint (which indicates the
direction along with endpoint number) whose stall condition must be cleared. The function will return USB_ERRROR_NONE if the function
executed successfully. The function will return USB_ERROR_DEVICE_ENDPOINT_INVALID if the specified endpoint is not provisioned in the
system configuration. It will return USB_ERROR_PARAMETER_INVALID if the driver handle is not valid.
Driver Device Endpoint Enable Status Function
The deviceEndpointIsEnabled member of the DRV_USB_DEVICE_INTERFACE structure should point to the USB Driver Endpoint Enable
Status function. The signature of this function is as follows:
bool (*deviceEndpointIsEnabled)(DRV_HANDLE handle, USB_ENDPOINT endpoint);
The USB Driver Endpoint Enable Status function should match this signature. The USB Device Stack function will call this function to check if an
endpoint has been enabled. The function returns true if the endpoint is enabled. The endpoint is enabled through the USB Driver Endpoint Enable
function. The handle parameter is the driver handle obtained from calling the driver Open function. The endpoint parameter is the USB
endpoint (which indicates the direction along with endpoint number) whose enable status needs to be queried.
Driver Device Endpoint Stall Status Function
The deviceEndpointIsStalled member of the DRV_USB_DEVICE_INTERFACE structure should point to the USB Driver Endpoint Stall
Status function. The signature of this function is as follows:
bool (*deviceEndpointIsStalled)(DRV_HANDLE handle, USB_ENDPOINT endpoint);
The USB Driver Endpoint Stall Status function should match this signature. The USB Device Stack function will call this function to check if an
endpoint has been stalled. The function returns true if the endpoint is stalled. The endpoint is stalled through the USB Driver Endpoint Stall
function. The handle parameter is the driver handle obtained from calling the driver Open function. The endpoint parameter is the USB
endpoint (which indicates the direction along with endpoint number) whose stall status needs to be queried.
Driver Device IRP Submit Function
The deviceIRPSubmit member of the DRV_USB_DEVICE_INTERFACE structure should point to the USB Driver Device IRP Submit function. The
signature of the IRP submit function is as follows:
USB_ERROR (*deviceIRPSubmit)(DRV_HANDLE handle, USB_ENDPOINT endpoint, USB_DEVICE_IRP * irp);
The USB Driver Device IRP Submit function must match this signature. The Device Stack (USB Device calls this function to submit an IRP to the
USB Driver. The USB Driver provides this mechanism to transfer data between the device and the Host. The handle parameter is the driver
handle obtained from calling the driver Open function. The endpoint parameter should set to endpoint through which transfer must be
processed. The irp parameter should point to the Device IRP data structure. The IRP data structure will transport an entire transfer over the
endpoint. The USB Driver will split up the transfer into transactions based on the endpoint size specified at the time of enabling the endpoint. This
process does not require Device Stack intervention.
The function will return USB_ERRROR_NONE if the function executed successfully. The function will return
USB_ERROR_DEVICE_ENDPOINT_INVALID if the specified endpoint is not provisioned in the system configuration. It will return
USB_ERROR_PARAMETER_INVALID if the driver handle is not valid. It will return USB_ERROR_DEVICE_IRP_IN_USE if an in progress IRP is
resubmitted. It will return USB_ERROR_ENDPOINT_NOT_CONFIGURED if the IRP is submitted to an endpoint that is not enabled.
The USB Driver will queue the IRP if there is already an IRP being processed on the endpoint. The completion of the IRP processing is indicated
by the USB Driver calling the IRP callback function specified within the IRP. The Device IRP Submit function must be thread safe and IRP callback
safe. The Device Stack may resubmit the IRP within the IRP callback function. The IRP callback function itself executes within an interrupt context.
The completion status of the IRP will be available in the status member of the IRP when the IRP callback function is invoked.
Driver Device IRP Cancel All Function
The deviceIRPCancelAll member of the DRV_USB_DEVICE_INTERFACE structure should point to the USB Driver Device IRP Cancel All
function. The signature of this is as follows:
USB_ERROR (*deviceIRPCancelAll)(DRV_HANDLE handle, USB_ENDPOINT endpoint);
The USB Driver Device IRP Cancel All function must match this signature. The USB Device Stack will call this function before disabling the
endpoint. Calling this function will call all IRPs that are queued on the endpoint to be canceled. The callback of each IRP will be invoked and the
IRP completion status will be set to USB_DEVICE_IRP_STATUS_ABORTED. If an IRP is in progress, an ongoing transaction will be allowed to
complete and pending transactions will be canceled. The handle parameter is the driver handle obtained from calling the driver Open function.
The endpoint parameter is the USB endpoint (which indicates the direction along with endpoint number) whose queued IRPs must be canceled.
The function is thread safe and interrupt safe and will return USB_ERRROR_NONE if it executed successfully. The function will return
USB_ERROR_DEVICE_ENDPOINT_INVALID if the specified endpoint is not provisioned in the system configuration. It will return
USB_ERROR_PARAMETER_INVALID if the driver handle is not valid.
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1159
Driver Device IRP Cancel Function
The deviceIRPCancel member of the DRV_USB_DEVICE_INTERFACE structure should point to the USB Driver Device IRP Cancel function.
The signature of this is as follows:
USB_ERROR (*deviceIRPCancel)(DRV_HANDLE handle, USB_DEVICE_IRP * IRP);
The USB Driver Device IRP Cancel function must match this signature. This function is called by the USB Device Stack function driver to cancel a
scheduled IRP. If the IRP is in the queue but it’s processing has not started, the IRP will removed from the queue and the IRP callback function will
be called from within the cancel function. The callback will be invoked with the IRP completion status set to
USB_DEVICE_IRP_STATUS_ABORTED. If an IRP is in progress, an ongoing transaction will be allowed to complete and pending transactions
will be canceled. The handle parameter is the driver handle obtained from calling the driver Open function. The irp parameter is the IRP to be
canceled.
The function is thread safe and will return USB_ERRROR_NONE if it executed successfully. It will return USB_ERROR_PARAMETER_INVALID if
the driver handle is not valid or if the IRP has status indicates that this IRP is not queued or not in progress. The application should not release the
data memory associated with IRP unless the callback has been received.
Driver Device Remote Wakeup Start Function
The deviceRemoteWakeupStart member of the DRV_USB_DEVICE_INTERFACE structure should point to the USB Driver Device Remote
Wakeup Start function. The signature of this function is as follows:
void (*deviceRemoteWakeupStart)(DRV_HANDLE handle);
The USB Driver Device Remote Wakeup Start function must match this signature. The USB Device Stack will call the function when the device
application wants to start remote wakeup signaling. This would happen if the device supports remote wake-up capability and this has been
enabled by the Host. The handle parameter is the driver handle obtained from calling the driver Open function.
Driver Device Remote Wakeup Stop Function
The deviceRemoteWakeupStop member of the DRV_USB_DEVICE_INTERFACE structure should point to the USB Driver Device Remote
Wakeup Stop function. The signature of this function is as follows:
void (*deviceRemoteWakeupStop)(DRV_HANDLE handle);
The USB Driver Device Remote Wakeup Stop function must match this signature. The USB Device Stack will call the function when the device
application wants to stop remote wakeup signaling. The application would call after calling the remote wakeup start function. The handle
parameter is the driver handle obtained from calling the driver Open function.
Driver Device Test Mode Enter Function
The deviceTestModeEnter parameter of the DRV_USB_DEVICE_INTERFACE structure should point to the USB Driver Device Test Mode
Enter function. The signature of this function is as follows:
USB_ERROR (*deviceTestModeEnter)(DRV_HANDLE handle, USB_TEST_MODE_SELECTORS testMode);
The USB Driver Device Test Mode Enter function should match this signature. The USB Device Stack calls this driver function to place the driver
into test mode. This is required when the USB Host (operating at Hi-Speed) send the Set Feature request with the feature selector test set to test
mode. This request also specifies which of the test mode signals, the driver should enable. The handle parameter is the driver handle obtained
from calling the driver Open function. The testMode parameter should be set to one of the test modes as defined in table 9-7 of the USB 2.0
specification.
The test mode enter function is only supported by the PIC32MZ USB Driver as the USB peripheral on this controller supports Hi-Speed operation.
The function will return USB_ERRROR_NONE if it executed successfully. It will return USB_ERROR_PARAMETER_INVALID if the driver handle
is not valid.
This concludes the discussion on the DRV_USB_DEVICE_INTERFACE structure. The following sections describe using the USB Common Driver.
Opening the Driver
Provides information and examples for opening the driver.
Description
The USB Host Stack and the USB Device Stack must obtain a handle to the USB Driver to access the functionality of the driver. This handle is
obtained through the USB Driver Open function. The DRV_USB_DEVICE_INTERFACE structure and DRV_USB_DEVICE_HOST_INTERFACE
structure provide access to the USB Driver Open function through the open member of these structures. Calling the Open function may not return
a valid driver handle the first time the function is called. In fact, the USB Driver will return an invalid driver handle until the driver is ready to be
opened. The Host and the Device Stack call the Open function repetitively in a state machine, until the function returns a valid handle.
The USB Host Stack can open the USB Driver but can call its Host mode functions only if the USB Driver was initialized for Host mode or Dual
Role operation. The USB Host Stack accesses the driver functions through the DRV_USB_HOST_INTERFACE pointer that was provided to the
Host Layer through the Host Stack initialization. The USB Device Stack can open the USB Driver but can call its Device mode functions only if the
USB Driver was initialized for Device mode or Dual Role operation. The USB Device Stack accesses the driver functions through the
DRV_USB_HOST_INTERFACE pointer that was provided to the Host Layer through the Host Stack initialization
The following code example shows how the USB Host Layer opens the USB Driver.
/* This code example shows how the Host Layer open the HCD via the hcdInterface.
* The driver handle is stored in hcdHandle member of the busObj data structure.
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1160
* The busObj data structure Host Layer local data structure. The Host Layer
* opens the HCD when the bus is enabled. This operation takes place in the
* USB_HOST_BUS_STATE_ENABLING state. */
/* Note the Host Layer calls the Open function by accessing the open member of
* the hcdInterface which is of the type DRV_USB_HOST_INTERFACE. Also note how
* the function is called repetitively until the Open function returns a valid
* handle. */
case USB_HOST_BUS_STATE_ENABLING:
/* The bus is being enabled. Try opening the HCD */
busObj->hcdHandle = busObj->hcdInterface->open(busObj->hcdIndex, DRV_IO_INTENT_EXCLUSIVE |
DRV_IO_INTENT_NONBLOCKING | DRV_IO_INTENT_READWRITE );
/* Validate the Open function status */
if (DRV_HANDLE_INVALID == busObj->hcdHandle )
{
/* The driver may not open the first time. This is okay. We
* should try opening it again. The state of bus is not
* changed. */
}
The following code example shows how the USB Device Layer opens the USB Driver.
/* This code example shows how the USB Device Layer calls the USBCD open
* function to open the USBCD. The Device Layer accesses the USBCD Open function
* through the driverInterface member of the usbDeviceInstanceState object. The
* driverInterface member is a DRV_USB_DEVICE_INTERFACE type. The
* usbDeviceInstanceState is a USB Device Layer local object. */
/* The Device Layer attempts to open the USBCD when it is initializing. Note how
* the Device Layer advances to the next state only when the USBCD returns a
* valid handle. */
switch(usbDeviceThisInstance->taskState)
{
case USB_DEVICE_TASK_STATE_OPENING_USBCD:
/* Try to open the driver handle. This could fail if the driver is
* not ready to be opened. */
usbDeviceThisInstance->usbCDHandle =
usbDeviceThisInstance->driverInterface->open( usbDeviceThisInstance->driverIndex,
DRV_IO_INTENT_EXCLUSIVE|DRV_IO_INTENT_NONBLOCKING|DRV_IO_INTENT_READWRITE);
/* Check if the driver was opened */
if(usbDeviceThisInstance->usbCDHandle != DRV_HANDLE_INVALID)
{
/* Yes the driver could be opened. */
/* Advance the state to the next state */
usbDeviceThisInstance->taskState = USB_DEVICE_TASK_STATE_RUNNING;
/* Update the USB Device Layer state to indicate that it can be
* opened */
usbDeviceThisInstance->usbDeviceInstanceState = SYS_STATUS_READY;
}
break;
USB Driver Host Mode Operation
Provides information on Host mode operation.
Description
The USB Driver operates or can operate in the Host mode when it is initialized for Host mode or Dual Role operation. When operating in Host
mode, the USB Driver is also referred to as the Host Controller Driver (HCD). In Dual Role mode, the USB Driver will switch to Host mode when
the USB Driver Host Root Hub Operation Enable function is called.
The USB Driver Client must perform these steps to operate the USB Driver in Host mode.
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1161
1. Open the USB Driver to obtain the driver handle.
2. Set the event handler.
3. Call the Root Hub Control function to obtain the speed of the root hub, the number of ports that the root hub supports, and the maximum
current that the root hub VBUS can supply.
4. Calls the Root Hub Initialize function with an identifier parameter. This identifier parameter allows the Host Stack to uniquely identify the
root hub when where there are multiple root hubs.
5. The Driver Client will then enable the root hub operation and will wait until the root hub operation is enabled.
6. The Driver Client can now call the USB Driver Host mode functions.
The following sections explain Steps 2 through 6 in more detail.
Handling Host Mode Driver Events
Currently, the HCD does not provide any events to the client. The client can optionally register an event handler through the eventHandlerSet
function pointer in the DRV_USB_HOST_INTERFACE structure. Future releases of the USB Driver may contain features that provide events to
the Driver Client. Please refer to the following Root Hub Operation section for details on how the driver indicates device attach and detach to the
client.
Root Hub Operation
A key feature of the HCD is the Root Hub Driver. The Root Hub Driver emulates hub operation in USB Driver software and provides a hub like
interface to the USB Host Layer. The USB Host Layer treats the root hub like an external hub. This simplifies the implementation of USB Host
Layer while supporting multiple devices through a hub. In that, the USB Host layer does not have to treat a device connected directly to the USB
peripheral differently than a device connected to an external hub. The following code example shows how the USB Host Layer calls the root hub
function to obtain information about the root hub.
/* This code example shows how the USB Host Layer calls the root hub functions to
* obtain information about the root. The USB Host Layer first opens the HCD and
* then accesses the root hub functions through the rootHubInterface member of
* hcdInterface. rootHubInterface is of the type DRV_USB_ROOT_HUB_INTERFACE and
* the hcdInterface is of the type of DRV_USB_HOST_INTERFACE. */
/* The code example shows how the Host Layer gets to know the root hub operation
* speed, number of root hub ports and the maximum amount of current that the
* root can supply. These function can be called only after HCD was opened and a
* valid driver handle obtained. */
case USB_HOST_BUS_STATE_ENABLING:
/* The bus is being enabled. Try opening the HCD */
busObj->hcdHandle = busObj->hcdInterface->open(busObj->hcdIndex, DRV_IO_INTENT_EXCLUSIVE |
DRV_IO_INTENT_NONBLOCKING | DRV_IO_INTENT_READWRITE );
/* Validate the Open function status */
if (DRV_HANDLE_INVALID == busObj->hcdHandle )
{
/* The driver may not open the first time. This is okay. We
* should try opening it again. The state of bus is not
* changed. */
}
else
{
/* Update the bus root hub information with the
* details of the controller. Get the bus speed, number of
* ports, the maximum current that the HCD can supply,
* pointer to the root hub port functions. */
SYS_DEBUG_PRINT(SYS_ERROR_INFO,
"\r\nUSB Host Layer: Bus %d Root Hub Driver Opened.",hcCount);
busObj->rootHubInfo.speed =
busObj->hcdInterface->rootHubInterface.rootHubSpeedGet(busObj->hcdHandle);
busObj->rootHubInfo.ports =
busObj->hcdInterface->rootHubInterface.rootHubPortNumbersGet(busObj->hcdHandle);
busObj->rootHubInfo.power =
busObj->hcdInterface->rootHubInterface.rootHubMaxCurrentGet(busObj->hcdHandle);
busObj->rootHubInfo.rootHubPortInterface =
busObj->hcdInterface->rootHubInterface.rootHubPortInterface;
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1162
The USB Host Layer must initialize and enable the operation of the root hub. While initializing the Root Hub Driver, the Host layer will assign a
unique identifier to the root hub. The root hub will return this value as the parent identifier while calling the USB_HOST_DeviceEnumerate function.
The USB Host Layer must then enable the operation of the root hub driver. This will cause the root hub driver to detect device attach and detach.
The following code example shows how the USB Host Layer initializes and enables the root hub driver
/* The following code example show how the USB Host Layer initializes the root
* hub and then enables the root hub operation. The
* rootHubDevice->deviceIdentifier is a unique identifier that allows the USB
* Host layer to identify this root hub. It is returned by the root hub driver
* in the USB_HOST_DeviceEnumerate() function as the parent identifier when the
* device is connected to the root hub. */
/* The hcdHandle is the driver handle. The hcdInterface pointer is of the type
* DRV_USB_HOST_INTERFACE and points to the HCD interface. */
busObj->hcdInterface->rootHubInterface.rootHubInitialize( busObj->hcdHandle ,
rootHubDevice->deviceIdentifier );
busObj->hcdInterface->rootHubInterface.rootHubOperationEnable( busObj->hcdHandle , true );
When a device is attached, the Root Hub Driver will implement the required settling attach settling delay and will then call the USB Host Layer’s
USB_HOST_DeviceEnumerate function to enumerate the device. While calling this function, the root hub driver will provide the identifier that was
provided to it in its initialize function. The USB_HOST_DeviceEnumerate function will return an identifier which uniquely identifies the attached
device. The root hub driver uses this value to identify the device to the Host when the USB_HOST_DeviceDenumerate function is called on device
detach. The following code example shows how the Root Hub driver calls the USB_HOST_DeviceEnumerate and the
USB_HOST_DeviceDenumerate functions.
/* The following code shows how the root hub driver calls the
* USB_HOST_DeviceEnumerate() function in the device attach interrupt. As seen
* here, the root hub returns the identifier that the USB Host Layer assigned to
* it the rootHubInitialize function call. The pUSBDrvObj->usbHostDeviceInfo
* variable contains this identifier. */
if(PLIB_USB_InterruptFlagGet(usbID, USB_INT_ATTACH))
{
/* We can treat this as a valid attach. We then clear the
* detach flag and enable the detach interrupt. We enable
* the Transaction interrupt */
PLIB_USB_InterruptFlagClear(usbID, USB_INT_HOST_DETACH);
PLIB_USB_InterruptEnable(usbID, USB_INT_HOST_DETACH);
PLIB_USB_InterruptEnable(usbID, USB_INT_TOKEN_DONE);
/* Ask the Host layer to enumerate this device. While calling
* this function, the UHD of the parent device which is the
* root hub in this case.
* */
pUSBDrvObj->attachedDeviceObjHandle = USB_HOST_DeviceEnumerate
(pUSBDrvObj->usbHostDeviceInfo, 0);
}
/* The following code example shows how the root hub driver calls the
* USB_HOST_DeviceDenumerate() function in the device detach interrupt. Note how
* the attachedDeviceObjHandle that was assigned at the time of device
* enumeration is returned to the Host Layer to let the Host know which device
* is being detached. */
if((usbInterrupts & USB_INT_HOST_DETACH) && (enabledUSBInterrupts & USB_INT_HOST_DETACH))
{
/* Perform other detach related handling */
/* Ask the Host Layer to de-enumerate this device. */
USB_HOST_DeviceDenumerate (pUSBDrvObj->attachedDeviceObjHandle);
/* Disable the LS Direct Connect. It may have been enabled if the last
attach was for a Low-Speed device. */
PLIB_USB_EP0LSDirectConnectDisable(pUSBDrvObj->usbID);
/* Continue to perform detach handling */
}
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1163
Root Hub Port Operation
The HCD Root Hub Driver exposes a set of port related functions that allow the USB Host Layer to control the port. The most commonly used
functions are the function to reset the port and get the port speed. In this case, this is the speed of the attached device. The following code
example shows how the USB Host Layer calls the hubPortReset, hubPortResetIsComplete and hubPortSpeedGet port functions.
/* The following code shows an example of how the Host Layer called the
* hubPortReset function to reset the port to which the device is connected.
* The code proceeds with the port reset if no device on the bus is in an
* enumeration state. It will then call the hubPortReset function of the parent
* hub of the device. The parent hub, hubInterface member of deviceObj points to
* this driver, can be the root hub or an external hub */
if(!busObj->deviceIsEnumerating)
{
/* Remember which device is enumerating */
busObj->enumeratingDeviceIdentifier = deviceObj->deviceIdentifier;
/* Grab the flag */
busObj->deviceIsEnumerating = true;
/* Reset the device */
deviceObj->hubInterface->hubPortReset( deviceObj->hubHandle, deviceObj->devicePort );
}
/* The following code example shows how the Host checks if the port reset
* operation has completed. If the reset operation has completed, the speed of
* the attached device can be obtained. The reset settling delay can then be
* started. */
case USB_HOST_DEVICE_STATE_WAITING_FOR_RESET_COMPLETE:
/* Check if the reset has completed */
if(deviceObj->hubInterface->hubPortResetIsComplete
( deviceObj->hubHandle ,deviceObj->devicePort ))
{
/* The reset has completed. We can also obtain the speed of the
* device. We give a reset recovery delay to the device */
deviceObj->speed = deviceObj->hubInterface->hubPortSpeedGet
(deviceObj->hubHandle, deviceObj->devicePort);
deviceObj->deviceState = USB_HOST_DEVICE_STATE_START_RESET_SETTLING_DELAY;
}
Opening and Closing a Pipe
The HCD client can open a pipe to the device after resetting the device. The USB Host Layer calls the hostPipeSetup function in the
DRV_USB_HOST_INTERFACE structure to open a pipe. The USB Host Layer must open a pipe to communicate to a specific endpoint on a target
device. While opening the pipe, the USB Host Layer must specify parameters which specify the address of the target device, the type of the
transfer that the pipe must support and the speed of the pipe. If the device is connected to a hub, the address of the hub must be specified. The
HCD Pipe Setup function is not interrupt-safe. It should not be called in any event handler that executes in an interrupt context.
The Pipe Setup function returns a valid pipe handle if the pipe was opened successfully. Pipe creation may fail if the target device was
disconnected or if there are insufficient resources to open the pipe. The pipe handle is then used along with the hostIRPSubmit function to transfer
data between the Host and the device. The following code shows example usage of a Pipe Open function.
/* The following code example shows how the Host Layer uses the hostPipeSetup
* function to open a control pipe to the attached device. Most of the
* parameters that are passed to this function become known when the device is
* attached. The pipe handle is checked for validity after the hostPipeSetup
* function call. */
if(busObj->timerExpired)
{
busObj->busOperationsTimerHandle = SYS_TMR_HANDLE_INVALID;
/* Settling delay has completed. Now we can open default address
* pipe and and get the configuration descriptor */
SYS_DEBUG_PRINT(SYS_ERROR_INFO,
"\r\nUSB Host Layer: Bus %d Device Reset Complete.", busIndex);
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1164
deviceObj->controlPipeHandle =
deviceObj->hcdInterface->hostPipeSetup( deviceObj->hcdHandle,
USB_HOST_DEFAULT_ADDRESS , 0 /* Endpoint */,
deviceObj->hubAddress /* Address of the hub */,
deviceObj->devicePort /* Address of the port */,
USB_TRANSFER_TYPE_CONTROL, /* Type of pipe to open */
0 /* bInterval */, 8 /* Endpoint Size */, deviceObj->speed );
if(DRV_USB_HOST_PIPE_HANDLE_INVALID == deviceObj->controlPipeHandle)
{
/* We need a pipe else we cannot proceed */
SYS_DEBUG_PRINT(SYS_ERROR_DEBUG,
"\r\nUSB Host Layer: Bus %d Could not open control pipe. Device not supported.", busIndex);
}
}
An open pipe consumes computational and memory resources and must therefore must be closed if it will not be used. This is especially true of
pipes to a device that is detached. The Host Layer calls the hostPipeClose function in the DRV_USB_HOST_INTERFACE structure to close the
pipe. The pipe to be closed is specified by the pipe handle. The Pipe Close function can be called from an event handler. It is interrupt safe.
Closing a pipe will cancel all pending transfers on that pipe. The IRP callback for such canceled transfers will be called with the status
USB_HOST_IRP_STATUS_ABORTED. The following code example shows an example of closing the pipe.
/* The following code example shows an example of how the Host Layer calls the
* hostPipeClose function to close an open pipe. Pipe should be closed if it
* will not used. An open pipe consumes memory resources. In this example, the
* Host Layer closes the pipe if it was not able successfully submit an IRP to
* this pipe. */
/* Submit the IRP */
if(USB_ERROR_NONE != deviceObj->hcdInterface->hostIRPSubmit
( deviceObj->controlPipeHandle, & (deviceObj->controlTransferObj.controlIRP)))
{
/* We need to be able to send the IRP. We move the device to
* an error state. Close the pipe and send an event to the
* application. The assigned address will be released when
* the device in unplugged. */
SYS_DEBUG_PRINT(SYS_ERROR_DEBUG,
"\r\nUSB Host Layer: Bus %d Set Address IRP failed. Device not supported.", busIndex);
/* Move the device to error state */
deviceObj->deviceState = USB_HOST_DEVICE_STATE_ERROR;
/* Close the pipe as we are about mark this device as unsupported. */
deviceObj->hcdInterface->hostPipeClose(deviceObj->controlPipeHandle);
}
Transferring Data to an Attached Device
The USB Host Layer, the HCD client, needs to transfer data to the attached device to understand the device capabilities and to operate the device.
The HCD uses a concept of Input Output Request Packet (IRP) to transfer data to and from the attached device. IRPs are transported over pipes
which are setup by calling the USB Driver Pipe Setup function.
A Host IRP is a USB_HOST_IRP type data structure. The IRP is created by the Host layer and submitted to the HCD for processing through the
hostIRPSubmit function. At the time of submitting the IRP, the pipe over which the IRP must be transported is specified. The data request in the
IRP is transported using the attributes of pipe. When an IRP is submitted to the HCD, it is owned by the HCD and cannot be modified by the Host
Layer until the HCD issues an IRP callback. The HCD will issue the IRP callback when it has completed or terminated processing of the IRP.
An IRP does not have its own transfer type. It inherits the properties of the pipe to which it is submitted. Hence an IRP becomes a control transfer
IRP it was submitted to a control transfer pipe. A pipe allows multiple IRPs to be queued. This allows the Host Layer to submit IRPs to a pipe even
while an IRP is being processed on the pipe. The HCD will process an IRP in the order that it was received. The following code example shows the
USB_HOST_IRP data structure.
/* The following code example shows the USB_HOST_IRP structure. The Host Layer
* uses this structure to place data transfer requests on a pipe. */
typedef struct _USB_HOST_IRP
{
/* Points to the 8 byte setup command packet in case this is a IRP is
* scheduled on a CONTROL pipe. Should be NULL otherwise */
void * setup;
/* Pointer to data buffer */
void * data;
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1165
/* Size of the data buffer */
unsigned int size;
/* Status of the IRP */
USB_HOST_IRP_STATUS status;
/* Request specific flags */
USB_HOST_IRP_FLAG flags;
/* User data */
uintptr_t userData;
/* Pointer to function to be called when IRP is terminated. Can be NULL, in
* which case the function will not be called. */
void (*callback)(struct _USB_HOST_IRP * irp);
/****************************************
* These members of the IRP should not be
* modified by client
****************************************/
uintptr_t privateData[7];
} USB_HOST_IRP;
The setup member of the USB_HOST_IRP structure must point to the 8 byte setup packet for control transfers. The driver will send this 8 byte
data in the Setup phase of the control transfer. It can be NULL for non-control transfers. This member is only considered if the IRP is submitted to
a control transfer pipe. It is ignored for non-control transfer pipes. The structure of the setup command should match that specified in the USB 2.0
specification.
The data member of the USB_HOST_IRP structure points to a data buffer. This data buffer will contain the data that needs to be sent to the
device for data stage of a OUT transfer, or it will contain the data that was received from the device during an IN transfer. Any hardware specific
cache coherency and address alignment requirements must be considered while allocating this data buffer. The Driver Client should not modify or
examine the contents of the IRP after the IRP has been submitted and is being processed. It can be examined after the driver has released the
IRP.
The size member of the USB_HOST_IRP structure contains the size of the transfer. for Bulk transfers, the size of the transfer can exceed the
size of the transaction (which is equal to size of the endpoint reported by the device). The HCD in such a case will split up the transfer into
transactions. This process does not require external intervention. For control transfers, the size of the transfer is specified in the setup packet
(pointed to by the setup member of the USB_HOST_IRP structure). The driver will itself process the Setup, Data (if required) and Handshake
stages of control transfer. This process again does not require external intervention. For interrupt and isochronous transfers, the size of transfer
specified in the IRP cannot exceed the size of the transaction. If size is specified as 0, then the driver will send a zero length packet. The size
parameter of the IRP is updated by the driver when IRP processing is completed. This will contain the size of the completed transfer.
The status member of the IRP provides the completion status of the IRP and should be checked only when the IRP processing has completed.
This is indicated by the driver calling the IRP callback function. The IRP status is a USB_HOST_IRP_STATUS type. The following code example
shows the different possible values of the status member and an example of submit a control transfer IRP.
/* The following code shows an example of how the Host Layer populates
* the IRP object and then submits it. IRP_Callback function is called when an
* IRP has completed processing. The status of the IRP at completion can be
* checked in the status flag. The size field of the irp will contain the amount
* of data transferred. */
void IRP_Callback(USB_HOST_IRP * irp)
{
/* irp is pointing to the IRP for which the callback has occurred. In most
* cases this function will execute in an interrupt context. The application
* should not perform any hardware access or interrupt unsafe operations in
* this function. */
switch(irp->status)
{
case USB_HOST_IRP_STATUS_ERROR_UNKNOWN:
/* IRP was terminated due to an unknown error */
break;
case USB_HOST_IRP_STATUS_ABORTED:
/* IRP was terminated by the application */
break;
case USB_HOST_IRP_STATUS_ERROR_BUS:
/* IRP was terminated due to a bus error */
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1166
break;
case USB_HOST_IRP_STATUS_ERROR_DATA:
/* IRP was terminated due to data error */
break;
case USB_HOST_IRP_STATUS_ERROR_NAK_TIMEOUT:
/* IRP was terminated because of a NAK timeout */
break;
case USB_HOST_IRP_STATUS_ERROR_STALL:
/* IRP was terminated because of a device sent a STALL */
break;
case USB_HOST_IRP_STATUS_COMPLETED:
/* IRP has been completed */
break;
case USB_HOST_IRP_STATUS_COMPLETED_SHORT:
/* IRP has been completed but the amount of data processed was less
* than requested. */
break;
default:
break;
}
}
/* In the following code example the a control transfer IRP is submitted to a
* control pipe. The setup parameter of the IRP points to the Setup command of
* the control transfer. The direction of the data stage is specified by the
* Setup packet. */
USB_HOST_IRP irp;
USB_ERROR result;
USB_HOST_PIPE_HANDLE controlPipe;
USB_SETUP_PACKET setup;
uint8_t controlTransferData[32];
irp.setup = setup;
irp.data = controlTransferData;
irp.size = 32;
irp.flags = USB_HOST_IRP_FLAG_NONE ;
irp.userData = &someApplicationObject;
irp.callback = IRP_Callback;
result = DRV_USBFS_HOST_IRPSubmit(controlPipeHandle, &irp);
switch(result)
{
case USB_ERROR_NONE:
/* The IRP was submitted successfully */
break;
case USB_ERROR_HOST_PIPE_INVALID:
/* The specified pipe handle is not valid */
break;
case USB_ERROR_OSAL_FUNCTION:
/* An error occurred while trying to grab mutex */
break;
default:
break;
}
The flags member of the USB_HOST_IRP structure specifies flags which affect the behavior of the IRP. The USB_HOST_IRP_FLAG
enumeration specifies the available option. The USB_HOST_IRP_FLAG_SEND_ZLP causes the driver to add a Zero Length Packet (ZLP) to the
data stage of the transfer when the transfer size is an exact multiple of the endpoint size. The USB_HOST_IRP_WAIT_FOR_ZLP flag will cause
the driver to wait for a ZLP from the device in a case where the size of data received thus far in the transfer is an exact multiple of the endpoint
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1167
size.
The callback member of the USB_HOST_IRP structure points to a function which the driver calls when the IRP processing is completed. The
Driver Client must implement this function and assign the pointer to this function to the callback member of the IRP. Every IRP can have its own
callback function or one common callback function could be used. The callback function will execute in an interrupt context. The Driver Client
should not execute interrupt unsafe, blocking, or computationally intensive operations in the callback function. The client can call hostIRPSubmit
function in the IRP callback function to submit another IRP or resubmit the same IRP. The client can check the status and size of the IRP in the
callback function.
The userData member of the USB_HOST_IRP structure can be used by the client to associate a client specific context with the Host. This
context can then be used by the client, in the IRP callback function to identify the context in which the IRP was submitted. This member is
particularly useful if the client wants to implement one callback function for all IRPs.
The privateData member of the IRP is used by the driver and should not be accessed or manipulated by the Driver Client. The following code
examples show usage of IRPs to transfer data between the Host and the attached device and along with the different flags.
/* The following code shows an example of submitting an IRP to send data
* to a device. In this example we will request the driver to send a ZLP after
* sending the last transaction. The driver will send the ZLP only if the size
* of the transfer is a multiple of the endpoint size. This is not a control
* transfer IRP. So the setup field of the IRP will be ignored. */
USB_HOST_IRP irp;
USB_ERROR result;
USB_HOST_PIPE_HANDLE bulkOUTPipeHandle;
uint8_t data[128];
irp.data = data;
irp.size = 128;
irp.flags = USB_HOST_IRP_FLAG_SEND_ZLP ;
irp.userData = &someApplicationObject;
irp.callback = IRP_Callback;
result = DRV_USBFS_HOST_IPRSubmit( bulkOUTPipeHandle, &irp );
/* The following code shows an example of submitting an IRP to receive
* data to a device. In this example we will request the driver to wait for a
* ZLP after receiving the last transaction. The driver will wait for the ZLP
* only if the size of the transfer is a multiple of the endpoint size. This is
* not a control transfer IRP. So the setup field of the IRP will be ignored.
* */
USB_HOST_IRP irp;
USB_ERROR result;
USB_HOST_PIPE_HANDLE bulkINPipeHandle;
uint8_t data[128];
irp.data = data;
irp.size = 128;
irp.flags = USB_HOST_IRP_FLAG_WAIT_FOR_ZLP ;
irp.userData = &someApplicationObject;
irp.callback = IRP_Callback;
result = DRV_USBFS_HOST_IPRSubmit( bulkINPipeHandle, &irp );
USB Driver Device Mode Operation
Provides information on Device mode operation.
Description
The USB Driver operates can operate in the Device mode when it is initialized for Device mode or Dual Role operation. When operating in Device
mode, the USB Driver is also referred to as the USB Controller Driver (USBCD). In Dual-Role mode, the USB Driver will switch to USBCD mode
when the USB Driver Device Attach function is called.
The USB Driver Client must perform these steps to operate the USB Driver in Device mode.
1. Open the USB Driver to obtain the driver handle.
2. Set the event handler.
3. Wait for the application to attach the device to the bus.
4. Enable Endpoint 0 and respond to USB Host Enumeration requests.
5. Allow the application and function drivers to enable other endpoints and communicate with the Host.
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1168
The following sections discuss these operations in more detail.
General Device Mode Operations
Provides information on general Device mode operations.
Description
This section describes the USBCD operations such as setting event handlers and attaching and detaching the device.
Handling Device Mode Driver Events
The Device Layer will call the USBCD eventHandlerSet function to register the Device mode event handling function. The USBCD generates
various events that indicate different states of the USB. These events are defined by the DRV_USB_EVENT enumeration. The following code
example shows how the Device Layer registers the driver event handling function.
/* This code example shows the implementation of the USB_DEVICE_Attach and the
* USB_DEVICE_Detach function. These functions are actually macro that map
* directly deviceAttach and the deviceDetach function of the driverInterface
* member of the deviceClient Object (which is the macro parameter) */
#define USB_DEVICE_Attach( x ) ((USB_DEVICE_OBJ *)x)->driverInterface->deviceAttach
( ((USB_DEVICE_OBJ *)(x))->usbCDHandle)
#define USB_DEVICE_Detach( x ) ((USB_DEVICE_OBJ *)x)->driverInterface->deviceDetach
( ((USB_DEVICE_OBJ *)x)->usbCDHandle)
If the driver is operating in interrupt mode, the client event handling function will execute in an interrupt context. The client should not call interrupt
unsafe, computationally intensive or blocking functions in the event handler. The following code shows a small example of the Device Layer
USBCD Event Handler:
/* This code example shows a partial implementation of the USB Device Layer
* event handler. Note how the code type casts the referenceHandle parameter to
* a USB_DEVICE_OBJ type. This referenceHandle is the same value that the Device
* Layer passed when the event handler was set. This now easily allows one
* implementation of the event handling code to be used by multiple Device
* Layer instances. */
void _USB_DEVICE_EventHandler
(
uintptr_t referenceHandle,
DRV_USB_EVENT eventType,
void * eventData
)
{
USB_DEVICE_OBJ* usbDeviceThisInstance;
USB_DEVICE_MASTER_DESCRIPTOR * ptrMasterDescTable;
USB_DEVICE_EVENT_DATA_SOF SOFFrameNumber;
usbDeviceThisInstance = (USB_DEVICE_OBJ *)referenceHandle;
/* Handle events, only if this instance is in initialized state */
if( usbDeviceThisInstance->usbDeviceInstanceState <= SYS_STATUS_UNINITIALIZED )
{
/* The device should anyway not be attached when the Device Layer is
* not initialized. If we receive driver event when the Device Layer is
* not initialized, there is nothing we can do but ignore them. */
return;
}
switch(eventType)
{
case DRV_USB_EVENT_RESET_DETECT:
/* Clear the suspended state */
usbDeviceThisInstance->usbDeviceStatusStruct.isSuspended = false;
/* Cancel any IRP already submitted in the RX direction. */
DRV_USB_DEVICE_IRPCancelAll( usbDeviceThisInstance->usbCDHandle,
controlEndpointRx );
/* Code not shown for the sake of brevity. */
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1169
}
}
In the previous code example, the Device Layer (the Driver Client) sets the hReferenceData parameter, of the Event Handler Set function, to
point to a local object. This pointer is returned to the Device Layer, in the event handler when an event occurs. For multiple instances of USB
drivers in one application, this allows the Device Layer to easily associate a Device Layer specific context to the driver instance, thus simplifying
implementation of the event handler.
Attaching and Detaching the Device
The USB Device Layer calls the USBCD deviceAttach and deviceDetach functions to attach and detach the device on the USB. The USB Device
Layer should be ready to handle events which would occur when the device is attached on the bus. Hence the USB Device Layer should register
the USBCD event handler before the attach function is called. The deviceAttach and deviceDetach functions can be called in an interrupt context.
These functions are respectively called when the USB Device application detects a valid VBUS voltage and when the VBUS voltage is not valid.
Setting the Device Address
The USB Device Layer will call the USBCD deviceAddressSet function to set the USB address of the device. The Device Layer will do this when it
receives the Set Address control request from the Host. The USBCD will reset the device address to '0' when it has received reset signaling from
the root hub. The following code example shows how the USB Device Layer calls this function.
/* The following code example shows how the USB Device Layer calls the
* DRV_USB_DEVICE_AddressSet function to set the address. The
* DRV_USB_DEVICE_AddressSet function is actually a macro that calls the
* deviceAddressSet function of the driverInterface of usbDeviceThisInstance
* object. The usbDeviceThisInstance is Device Layer object.
*
* As seen in this code, the Device Layer calls the address set function when
* the it a pending set address control request from the Host has completed. */
void _USB_DEVICE_Ep0TransmitCompleteCallback(USB_DEVICE_IRP * handle)
{
USB_DEVICE_IRP * irpHandle = (USB_DEVICE_IRP *)handle;
USB_DEVICE_OBJ * usbDeviceThisInstance;
USB_DEVICE_CONTROL_TRANSFER_STRUCT * controlTransfer;
usbDeviceThisInstance = (USB_DEVICE_OBJ *)irpHandle->userData;
controlTransfer = &(usbDeviceThisInstance->controlTransfer);
if(irpHandle->status == USB_DEVICE_IRP_STATUS_ABORTED)
{
return;
}
if(usbDeviceThisInstance->usbDeviceStatusStruct.setAddressPending)
{
DRV_USB_DEVICE_AddressSet(usbDeviceThisInstance->usbCDHandle,
usbDeviceThisInstance->deviceAddress);
usbDeviceThisInstance->usbDeviceStatusStruct.setAddressPending = false;
}
/* Code not shown for the sake of brevity */
}
Device Current Speed and SOF Number
The USB Device Layer will call the USBCD deviceCurrentSpeedGet function to know the speed at which the device is attached to the USB. This
allows the Device Layer to select the correct endpoint settings at the time of processing the Set Configuration request issued by the Host. The
USB Device Layer will call the deviceSOFNumberGet function to return the SOF number at the time of the SOF event.
Device Remote Wake-up
The USB Device Layer will call the USBCD deviceRemoteWakeupStop and deviceRemoteWakeupStart functions to stop and start remote
signaling. The Device layer application will call the USB Device Layer Stop and Start Remote Wakeup Signaling functions to remotely let the root
hub know that the device is ready to be woken up. The timing of the remote signaling is controlled by the Device Layer. The client should call the
remote wakeup function only when the device is suspended by the Host.
Device Endpoint Operations
Provides information on Device Endpoint operations.
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1170
Description
The UBSCD Endpoint functions allow the Driver Client to enable, disable, stall and clear the stall condition on an endpoint. The client submits
requests to transmit and receive data from the USB Host on an endpoint.
Endpoint Enable and Disable functions
The USBCD client must enable an endpoint it must use the endpoint for communicating with the USB Host. The client will call the USBCD
deviceEndpointEnable function to enable the endpoint. While calling this function, the client must specify the endpoint address, the transfer type to
be processed on this endpoint and the maximum size of a transaction on this endpoint. This function is thread-safe when called in an RTOS
application. The USBCD allows an endpoint to be accessed by one thread only. The USB Device Layer and the device function drivers will enable
the endpoint when the Host sets the device configuration. The USBCD deviceEndpointIsEnabled function is available to check if an endpoint is
enabled. The following code example shows how the USB Device Layer enables the device endpoint.
/* The following code example shows the USB Device Layer enables Endpoint 0 to
* prepare for the enumeration process after it has received reset signaling
* from the Host. The Device Layer calls the deviceEndpointEnable function to
* to enable the endpoint. The driverInterface member of the
* usbDeviceThisInstance structure points to the USB Device Mode Driver Common
* Interface. */
void _USB_DEVICE_EventHandler
(
uintptr_t referenceHandle,
DRV_USB_EVENT eventType,
void * eventData
)
{
/* Code not shown due to space constraints */
switch(eventType)
{
case DRV_USB_EVENT_RESET_DETECT:
/* Clear the suspended state */
usbDeviceThisInstance->usbDeviceStatusStruct.isSuspended = false;
/* Cancel any IRP already submitted in the RX direction. */
DRV_USB_DEVICE_IRPCancelAll( usbDeviceThisInstance->usbCDHandle,
controlEndpointRx );
/* Cancel any IRP already submitted in the TX direction. */
DRV_USB_DEVICE_IRPCancelAll( usbDeviceThisInstance->usbCDHandle,
controlEndpointTx );
/* Deinitialize all function drivers.*/
_USB_DEVICE_DeInitializeAllFunctionDrivers ( usbDeviceThisInstance );
/* Disable all endpoints except for EP0.*/
DRV_USB_DEVICE_EndpointDisableAll(usbDeviceThisInstance->usbCDHandle);
/* Enable EP0 endpoint in RX direction */
(void)usbDeviceThisInstance->driverInterface->deviceEndpointEnable
(usbDeviceThisInstance->usbCDHandle,
controlEndpointTx, USB_TRANSFER_TYPE_CONTROL, USB_DEVICE_EP0_BUFFER_SIZE);
/* Code not shown due to space constraints */
break;
}
}
The USB Device Layer and the Function drivers will disable an endpoint when the Host sets a zero-device configuration or when the Host resets
the device. The USBCD deviceEndpointDisable function disables an endpoint. When an endpoint is disabled, it does not accept requests for Host
communication. Disabling an endpoint does not cancel any communication requests that that have been submitted on the endpoint. These
requests must be canceled explicitly.
Device Endpoint Stall and Stall Clear
The USBCD client can call the deviceEndpointStall and deviceEndpointStallClear functions to stall and cleat the stall on an endpoint respectively.
The USB Device Layer and function driver may stall endpoint to indicate error or to indicate a protocol state. The endpoint stall condition may be
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1171
cleared in response to a USB Host Clear Feature request. Stalling or clearing the stall on an endpoint will cause all communication requests on the
endpoint to be canceled. The function calls are thread safe and interrupt safe. The deviceEndpointIsStalled function is also available to check if an
endpoint is in a stalled state. The following code example shows how the USB Device Layer calls these functions to stall and clear the stall on an
endpoint.
/* The following code example shows how the USB Device Layer calls the driver
* endpoint stall function (deviceEndpointStall) to stall an endpoint when the a
* Host send a Set Feature request with feature selector set to endpoint halt.
* The endpoint to be halted is identified in the setup packet and is identified
* in this code example as usbEndpoint. Also shown is how the stall clear
* (deviceEndpointStallClear) and stall status check (deviceEndpointIsStalled)
* functions are called. */
/* The driverInterface member of the usbDeviceThisInstance structure is a
* pointer to the USB Driver Common Interface. */
void _USB_DEVICE_ProcessStandardEndpointRequest
(
USB_DEVICE_OBJ * usbDeviceThisInstance,
uint8_t interfaceNumber,
USB_SETUP_PACKET * setupPkt
)
{
USB_ENDPOINT usbEndpoint;
usbEndpoint = setupPkt->bEPID;
if( setupPkt->bRequest == USB_REQUEST_GET_STATUS )
{
usbDeviceThisInstance->getStatusResponse.status = 0x00;
usbDeviceThisInstance->getStatusResponse.endPointHalt
= usbDeviceThisInstance->driverInterface->deviceEndpointIsStalled
(usbDeviceThisInstance->usbCDHandle, usbEndpoint );
USB_DEVICE_ControlSend( (USB_DEVICE_HANDLE)usbDeviceThisInstance,
(uint8_t *)&usbDeviceThisInstance->getStatusResponse, 2 );
}
else if( setupPkt->bRequest == USB_REQUEST_CLEAR_FEATURE )
{
if( setupPkt->wValue == USB_FEATURE_SELECTOR_ENDPOINT_HALT )
{
usbDeviceThisInstance->driverInterface->deviceEndpointStallClear
(usbDeviceThisInstance->usbCDHandle, usbEndpoint );
USB_DEVICE_ControlStatus((USB_DEVICE_HANDLE)usbDeviceThisInstance,
USB_DEVICE_CONTROL_STATUS_OK );
}
}
else if (setupPkt->bRequest == USB_REQUEST_SET_FEATURE )
{
if( setupPkt->wValue == USB_FEATURE_SELECTOR_ENDPOINT_HALT )
{
usbEndpoint = setupPkt->bEPID;
usbDeviceThisInstance->driverInterface->deviceEndpointStall
(usbDeviceThisInstance->usbCDHandle, usbEndpoint );
USB_DEVICE_ControlStatus((USB_DEVICE_HANDLE)usbDeviceThisInstance,
USB_DEVICE_CONTROL_STATUS_OK );
}
}
/* Additional code is not shown due to space constraints */
}
Transferring Data to the Host
Provides information on transferring data to the Host.
Description
The USB Device Layer, the USBCD client, needs to transfer data to the Host in response to enumeration requests for general operation on the
device. The USB uses a concept of Input Output Request Packet (IRP) to transfer data to and from the Host. IRPs are transported over endpoints
which are enabled by calling the USBCD Endpoint Enable function.
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1172
A Device IRP is a USB_DEVICE_IRP type data structure. The IRP is created by the Device Layer and submitted to the USBCD for processing
through the deviceIRPSubmit function. At the time of submitting the IRP, the endpoint over which the IRP must be transported is specified. The
data request in the IRP is transported using the attributes of the endpoint. When an IRP is submitted to the USBCD, it is owned by the USBCD and
cannot be modified by the Device Layer until the USBCD issues an IRP callback. The USBCD will issue the IRP callback when it has completed or
terminated processing of the IRP.
An IRP does not have its own transfer type. It inherits the properties of the endpoint to which it is submitted. Hence an IRP becomes a control
transfer IRP it was submitted to a control endpoint. An endpoint allows multiple IRPs to be queued. This allows the Device Layer to submit IRPs to
an endpoint even while an IRP is being processed on the endpoint. The USBCD will process an IRP in the order that it was received. The following
code example shows the USB_DEVICE_IRP data structure:
/* This code example shows the USB_DEVICE_IPR structure. The Device Layer
* uses such a structure to transfer data through the driver. A structure of
* this type is allocated by the Device Layer and the other function drivers and
* passed to the deviceIRPSubmit function. */
typedef struct _USB_DEVICE_IRP
{
/* Pointer to the data buffer */
void * data;
/* Size of the data buffer */
unsigned int size;
/* Status of the IRP */
USB_DEVICE_IRP_STATUS status;
/* IRP Callback. If this is NULL, then there is no callback generated */
void (*callback)(struct _USB_DEVICE_IRP * irp);
/* Request specific flags */
USB_DEVICE_IRP_FLAG flags;
/* User data */
uintptr_t userData;
/***********************************
* The following members should not
* be modified by the client
***********************************/
uint32_t privateData[3];
} USB_DEVICE_IRP;
The data member of the USB_DEVICE_IRP structure points to a data buffer. This data buffer will contain the data that needs to be sent to the
Host for the data stage of an IN transfer. For an OUT transfer, it will contain the data that was received from the Host. Any hardware specific cache
coherency and address alignment requirements must be considered while allocating this data buffer. The Driver Client should not modify or
examine the contents of the IRP after the IRP has been submitted and is being processed. It can be examined after the driver has released the
IRP.
The size member of the USB_DEVICE_IRP structure specifies the size of the data buffer. The transfer will end when the device has sent or
received size number of bytes. While sending data to the Host, the IRP size can exceed the size of the transaction (which is equal to the size of
the endpoint). The USBCD in such a case will split up the transfer into transactions. This process does not require external intervention. The driver
uses receive and transmit IRPs to process control transfers. When the driver receives a Setup packet, the IRP completion status would be
USB_DEVICE_IRP_STATUS. The Driver Client should then use additional receive and transmit IRPs to complete the control transfer.
For interrupt and isochronous transfers, the size of transfer specified in the IRP cannot exceed the size of the transaction. If size is specified as 0,
then the driver will send or expect a zero length packet. The size parameter of the IRP is updated by the driver when IRP processing is
completed. This will contain the size of the completed transfer.
The status member of the IRP provides the completion status of the IRP and should be checked only when the IRP processing has completed.
This is indicated by the driver calling the IRP callback function. The IRP status is a USB_DEVICE_IRP_STATUS type. The following code example
shows the different possible values of the status member and example usage of IRPs to transfer data between the device and the Host.
/* The followoing code shows example usage of the device IRP. The submit status
* of the IRP is available when IRP submit function returns. The completion
* status of the IRP is available when the IRP has terminated and the IRP
* callback function is invoked. The IRP callback
* function shown in this example shows the possible complete status of the IRP.
* The end application may or may not handle all the cases. Multiple IRPs can be
* queued on an endpoint. */
void IRP_Callback(USB_DEVICE_IRP * irp)
{
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1173
/* irp is pointing to the IRP for which the callback has occurred. In most
* cases this function will execute in an interrupt context. The application
* should not perform any hardware access or interrupt unsafe operations in
* this function. */
switch(irp->status)
{
case USB_DEVICE_IRP_STATUS_TERMINATED_BY_HOST:
/* The IRP was aborted because the Host cleared the stall on the
* endpoint */
break;
case USB_DEVICE_IRP_STATUS_ABORTED_ENDPOINT_HALT:
/* IRP was aborted because the endpoint halted */
break;
case USB_DEVICE_IRP_STATUS_ABORTED:
/* USB Device IRP was aborted by the function driver */
break;
case USB_DEVICE_IRP_STATUS_ERROR:
/* An error occurred on the bus when the IRP was being processed */
break;
case USB_DEVICE_IRP_STATUS_COMPLETED:
/* The IRP was completed */
break;
case USB_DEVICE_IRP_STATUS_COMPLETED_SHORT:
/* The IRP was completed but the amount of data received was less
* than the requested size */
break;
default:
break;
}
}
/* In the following example, the IRP is submitted to Endpoint 0x84. This is
* interpreted as an IN direction endpoint (MSB of 0x84 is 1) and Endpoint 4.
* The data contained in source will be sent to the USB Host. Assuming
* the endpoint size is 64, the 130 bytes of data in this case will be sent to
* the Host in three transaction of 64, 64 and 2 bytes. A transaction completes
* when the Host polls (sends an IN token) the device. The callback function
* will then called indicating the completion status of the IRP. The application
* should not modify the privateData field of the IRP. If the IRP was submitted
* successfully, the buffer will be owned by the driver until the IRP callback
* function has been called. Because the size of the transfer is not a multiple
* of the endpoint size, the IRP flag must be set
* USB_DEVICE_IRP_FLAG_DATA_COMPLETE. This directs the driver to not perform any
* explicit signaling to the Host to indicate end of transfer. The last packet
* in this case is a short packet and this signals the end of the transfer. */
USB_DEVICE_IRP irp;
USB_ERROR result;
uint8_t source[130];
irp.data = source;
irp.size = 130;
irp.called = IRP_Callback;
flags = USB_DEVICE_IRP_FLAG_DATA_COMPLETE;
userData = &someApplicationObject;
result = DRV_USBFS_DEVICE_IRPSubmit(driverHandle, 0x84, &irp);
switch(result)
{
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1174
case USB_ERROR_PARAMETER_INVALID:
/* This can happen if the driverHandle is invalid */
break;
case USB_ERROR_DEVICE_IRP_IN_USE:
/* This can happen if the IRP is being resubmitted while it is still in
* process (it was submitted before but processing has not completed */
break;
case USB_ERROR_DEVICE_ENDPOINT_INVALID;
/* The endpoint to which this IRP is being submitted is not provisioned
* in the system. This is controller by DRV_USBFS_ENDPOINTS_NUMBER
* configuration parameter. */
break;
case USB_ERROR_ENDPOINT_NOT_CONFIGURED:
/* The endpoint to which this IRP is being submitted is not enabled. It
* must be enabled by calling the DRV_USBFS_DEVICE_EndpointEnable()
* function. */
break;
case USB_ERROR_PARAMETER_INVALID:
/* The USB_DEVICE_IRP_FLAG_DATA_PENDING flag was specified but the
* transfer size is not a multiple of the endpoint size. If the IRP was
* submitted to a receive endpoint, this error can occur if the size is
* not a multiple of the endpoint size. */
break;
case USB_ERROR_OSAL_FUNCTION:
/* An error occurred while trying to grab a mutex. This is applicable
* when the driver is running with a RTOS. */
break;
case USB_ERROR_NONE:
/* The IRP was submitted successfully. */
break;
default:
break;
}
/* The following code example shows how an IRP is submitted to an OUT endpoint.
* In this case data will be pointing to a buffer where the received data will
* be stored. Note that the size of the IRP should be a multiple of the endpoint
* size. The flags parameter is ignored in the data receive case. The IRP
* terminates when the specified size of bytes has been received (the Host sends
* OUT packets) or when a short packet has been received. */
USB_DEVICE_IRP irp;
USB_ERROR result;
uint8_t destination[128];
irp.data = destination;
irp.size = 128;
irp.called = IRP_Callback;
userData = &someApplicationObject;
result = DRV_USBFS_DEVICE_IRPSubmit(driverHandle, 0x04, &irp);
For IRPs submitted to an Interrupt or Isochronous endpoints, the driver will always send either the less than or equal to the maximum endpoint
packet size worth of bytes in a transaction. The application could either submit an IRP per Interrupt/Isochronous polling interval or it could submit
one IRP for multiple polling intervals.
The flags member of the USB_DEVICE_IRP structure specifies flags which affect the behavior of the IRP. The USB_DEVICE_IRP_FLAG
enumeration specifies the available option. The USB_DEVICE_IRP_FLAG_DATA_COMPLETE causes the driver to add a Zero Length Packet
(ZLP) to the data stage of the IN transfer when the transfer size is an exact multiple of the endpoint size. If the transfer size is not a multiple of the
endpoint size, no ZLP will be sent. The USB_DEVICE_IRP_FLAG_PENDING flag will cause the driver to not send a ZLP in a case where the size
of the IN transfer is an exact multiple of the endpoint size. The following code example demonstrates this.
/* In the following code example, the IRP is submitted to an IN endpoint whose size
* is 64. The transfer size is 128, which is an exact multiple of the endpoint
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1175
* size. The flag is set to USB_DEVICE_IRP_FLAG_DATA_COMPLETE. The driver
* will send two transactions of 64 bytes each and will then automatically send a
* Zero Length Packet (ZLP), thus completing the transfer. The IRP callback will
* be invoked when the ZLP transaction has completed. */
USB_DEVICE_IRP irp;
USB_ERROR result;
uint8_t source[128];
irp.data = source;
irp.size = 128;
irp.called = IRP_Callback;
flags = USB_DEVICE_IRP_FLAG_DATA_COMPLETE;
userData = &someApplicationObject;
result = DRV_USBFS_DEVICE_IRPSubmit(driverHandle, 0x84, &irp);
/* In the following code example, the IRP is submitted to an IN endpoint whose size
* is 64. The transfer size is 128, which is an exact multiple of the endpoint
* size. The flag is set to to USB_DEVICE_IRP_FLAG_DATA_PENDING. The driver will
* send two transactions of 64 bytes each but will not send a ZLP. The USB Host
* can then consider that there is more data pending in the transfer. The IRP
* callback will be invoked when the two transactions have completed. */
USB_DEVICE_IRP irp;
USB_ERROR result;
uint8_t source[128];
irp.data = source;
irp.size = 128;
irp.called = IRP_Callback;
flags = USB_DEVICE_IRP_FLAG_DATA_COMPLETE;
userData = &someApplicationObject;
result = DRV_USBFS_DEVICE_IRPSubmit(driverHandle, 0x84, &irp);
The callback member of the USB_DEVICE_IRP structure points to a function which the driver calls when the IRP processing is completed. The
Driver Client must implement this function and assign the pointer to this function to the callback member of the IRP. Every IRP can have its own
callback function or one common callback function could be used. The callback function will execute in an interrupt context. The Driver Client
should not execute interrupt unsafe, blocking or computationally intensive operations in the callback function. The client can call deviceIRPSubmit
function in the IRP callback function to submit another IRP or resubmit the same IRP. The client can check the status and size of the IRP in the
callback function.
The userData member of the USB_DEVICE_IRP structure can be used by the client to associate a client specific context with the Host. This
context can then be used by the client, in the IRP callback function to identify the context in which the IRP was submitted. This member is
particularly useful if the client wants to implement one callback function for all IRPs.
The privateData member of the IRP is used by the driver and should not be accessed or manipulated by the Driver Client.
PIC32MX USB Driver
Provides information on the USB Driver specific to PIC32MX devices.
Description
The PIC32MX USB Driver in MPLAB Harmony provides API functions that allow the MPLAB Harmony USB Host and Device Stack to access the
USB while operating on a PIC32MX microcontroller. The driver implements the USB Driver Common Interface required by the USB Host and
Device Stack. It abstracts the USB module operational details from the Host and Device Stack and provides the stacks with a modular access
mechanism to the USB. The PIC32MX USB Driver features the following:
• USB 2.0 Full Speed operation in Peripheral mode
• USB 2.0 Full Speed and Low Speed USB Peripheral Support in Host mode
• Designed for Dual Role Operation
• Capable of operating multiple USB modules
• Features non-blocking function and is interoperable with other MPLAB Harmony modules
• Features thread safe functions when operating within an RTOS
• Capable of operating in Polled and Interrupt modes
• Implements the USB Driver Common Interface required by the MPLAB Harmony USB Host and Device Stack
• Completely configurable through MPLAB Harmony Configurator (MHC) tool
• Implements feature separation (Host and Device mode functions are implemented across different files)
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1176
Note:
This help section only discusses features that are unique to the PIC32MX USB Driver and are not a part of the USB Driver
Common Interface. The driver functions that implement the USB Driver Common Interface are described in the Common Interface
Help section.
While the PIC32MX USB module supports USB "On-The-Go" (OTG), this release of the PIC32MX Driver does not implement USB OTG protocol
support.
This help section only provides relevant information about the operation of the USB. The reader is encouraged to refer to the USB 2.0
Specification available at www.usb.org for a detailed explanation of USB protocol.
Using the Library
This topic describes the basic architecture of the PIC32MX USB Driver Library and provides information and examples on its use.
Description
Interface Header File: drv_usbfs.h
The interface to the PIC32MX USB Driver library is defined in the drv_usbfs.h header file.
Please refer to the What is MPLAB Harmony? section for how the Driver interacts with the framework.
Library Overview
Provides an overview of the library.
Description
The PIC32MX USB Driver will typically be used by a USB Host and/or Device Stack. The USB Host and Device Stack operate as driver client
applications. The driver is initialized as part of the MPLAB Harmony System Initialization. The driver initialization data structure specifies the
operation mode (Host, Device, or Dual Role) of the driver. The driver features task routines to be called in the MPLAB Harmony application tasks
function (SYS_Tasks function) and the USB Module Interrupt Service Routine (ISR).
The Host and the Device Stack can open the driver only when initialization has completed. It will continue to return an invalid driver handle while
the initialization is in progress. Once opened, the Device Mode function can be called if the driver is operating in Device mode. The Host Mode
function can be called if the driver is operating in Host mode. In Dual Role operation mode, the driver supports Host and Device operation in the
same application. Even then, the driver will either operate as a USB Host or Device. OTG operation is not supported.
The PIC32MX USB Driver features RTOS thread-safe functions. This allows the driver client application to safely call driver functions across
different RTOS threads. Not all of the driver functions are interrupt-safe.
In addition to the USB Driver, which implements the USB Driver Common Interface, the PIC32MX USB Driver implements functions which are
required for its operation in the MPLAB Harmony framework. The following table lists the different categories of functions in the PIC32MX USB
Driver.
Library
Interface
Section
Description
System
Function
These functions are accessed by the MPLAB Harmony System module. They allow the driver to be initialized, deinitialized and
maintained. These functions are implemented in the drv_usbfs.c source file.
Client Core
Functions
These functions allow the USB Host and Device Stack to open, close and perform other general driver operations. These
functions are a part of the USB Driver Common Interface and are implemented in drv_usbfs.c source file.
Device Mode
Operation
Functions
These functions allow the USB Device Stack to perform USB Device mode specific driver operations. These functions are a
part of the USB Driver Common Interface and are implemented in drv_usbfs_device.c source file
Host Mode
Operation
Functions
These functions allow the USB Host Stack to perform USB Host mode specific driver operations. These functions are a part of
the USB Driver Common Interface and are implemented in drv_usbfs_host.c source file.
Root Hub
Functions
These functions allow the USB Host Stack to access the driver Root hub operation. These functions are a part of the USB
Driver Common Interface and are implemented in drv_usbfs_host.c source file.
Abstraction Model
Provides information on the abstraction model for the library.
Description
The PIC32MX USB Driver implements the abstraction model defined by the USB Driver Common interface. This interface abstracts USB module
specific details and provides a module independent interface to the driver client applications.
While operating in Device mode, the driver expects the client application (the USB Device Stack) to enable endpoints and then submit I/O request
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1177
packet (IRP) requests to the enabled endpoints. Multiple IRPs can be queued on an endpoint. The driver calls the IRP callback function when the
IRP is processed. The driver allows the client application to also attach and detach the device on the bus. It generates events which indicate USB
states.
While operating in Host mode, the driver expects the client application (the USB Host Stack) to open pipes to endpoints on the connected device.
The client application can then submit IRPs to the pipes. Multiple IRPs can be queued on a pipe. The driver calls the IRP callback function when
the IRP is processed. The driver will call application defined functions to enumerate and denumerate a device. These functions are called when
the driver detect device attach and detach respectively. The driver also exports root hub functions to the client application. This allows the client
application to treat the driver as a single port hub
Please refer to the PIC32 USB Driver Common Interface help section for more details on the driver abstraction model.
How the Library Works
Provides information on how the library works.
Description
This section only explains aspects of driver operation which are unique to the PIC32MX USB Driver. Major driver operations are described in the
PIC32 USB Driver Common Interface help section.
Driver Initialization
Note:
While generating a MPLAB Harmony USB project with MHC, the initialization code for the driver is generated automatically based
on selections made in the USB Host stack or Device Stack Configuration trees.
The PIC32MX USB Driver must be initialized so that a client application can open. The client application will not be able to open the driver if the
initialization is in progress or has failed. The driver is initialized by calling the DRV_USBFS_Initialize function. This function is called from the
SYS_Initialize function in the MPLAB Harmony application project and accepts two input parameters. The index parameter defines the instance of
the USB Driver to be initialized. This becomes significant when the PIC32MX microcontroller has more than one USB module. The init parameter
is a driver specific data structure of the type DRV_USBFS_INIT. This structure is shown in the following code example.
/* This code snippet show the PIC32MX USB Driver Initialization data structure.
* A structure of this type must be provided to the DRV_USBFS_Initialize()
* function. */
typedef struct
{
/* System Module Initialization */
SYS_MODULE_INIT moduleInit;
/* Identifies the USB peripheral to be used. This should be the USB PLIB
module instance identifier. */
uint8_t usbID;
/* This should be set to true if the USB module must stop operation in IDLE
mode */
bool stopInIdle;
/* This should be set to true if the USB module must suspend when the CPU
enters sleep mode. */
bool suspendInSleep;
/* Specify the interrupt source for the USB module. This should be Interrupt
PLIB Interrupt source identifier for the USB module instance specified in
usbID. */
INT_SOURCE interruptSource;
/* Specify the operational speed of the USB module. This should always be
set to USB_SPEED_FULL. The use of this parameter is deprecated. */
USB_SPEED operationSpeed;
/* Specify the operation mode of the USB module. This defines if the USB
* module will support Device, Host or Dual Role operation */
DRV_USBFS_OPMODES operationMode;
/* A pointer to the endpoint descriptor table. This should be aligned at 512
byte address boundary. The size of the table is equal to the
DRV_USBFS_ENDPOINT_TABLE_ENTRY_SIZE times the number of endpoints needed
in the application. */
void * endpointTable;
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1178
/* Root hub available current in mA. This specifies the amount of current
that root hub can provide to the attached device. This should be
specified in mA. This is required when the driver is required to operate
in host mode. */
uint32_t rootHubAvailableCurrent;
/* When operating in Host mode, the application can specify a Root Hub port
enable function. This parameter should point to Root Hub port enable
function. If this parameter is NULL, it implies that the Port is always
enabled. */
DRV_USBFS_ROOT_HUB_PORT_POWER_ENABLE portPowerEnable;
/* When operating in Host mode, the application can specify a Root Port
Indication. This parameter should point to the Root Port Indication
function. If this parameter is NULL, it implies that Root Port Indication
is not supported. */
DRV_USBFS_ROOT_HUB_PORT_INDICATION portIndication;
/* When operating is Host mode, the application can specify a Root Port
Overcurrent detection. This parameter should point to the Root Port
Indication function. If this parameter is NULL, it implies that
Overcurrent detection is not supported. */
DRV_USBFS_ROOT_HUB_PORT_OVER_CURRENT_DETECT portOverCurrentDetect;
} DRV_USBFS_INIT;
The operationMode parameter defines by the driver operation mode. parameter in the initialization data structure. This can be set
DRV_USBFS_OPMODE_DEVICE, DRV_USBFS_OPMODE_HOST or DRV_USBFS_OPMODE_DUAL_ROLE for device, host and dual role
operation respectively.
The endpointTable parameter must point to a byte array. The size of the array depends on the maximum number of device endpoints that
application needs. A direction of an endpoint counts as one endpoint. Each endpoint requires 32 bytes. Therefore, if the USB Device requires 3
endpoints (Endpoint 0 + Endpoint 1 IN + Endpoint 2 OUT), the size of the array will 96 bytes (32 * 3). The byte array start address must be located
on a 512 byte boundary. When operating in host mode, the driver will use only one endpoint and size of the endpoint table array should be set to
32.
The rootHubAvailableCurrent parameter should be set to the maximum current that VBUS power supply can provide on the bus. The driver
does not use this information directly. It provides this data to the client application while operating in host mode.
The portPowerEnable parameter must point to a Port Power Enable function. The driver, while operating in host mode, will call this function to
enable the VBUS switch. This function should activate the VBUS switch if the driver calls this function with the enable parameter set to true. It
should deactivate the switch if the driver calls this function with the enable parameter set to false. This parameter should be set to NULL if such a
switch (of the switch control) is not available in the application.
The portIndication parameter must point to a Port Indication function. The driver, while operating in host mode, will call this function to
indicate the current state of the port. The driver will call this function with LED color status as defined in the Chapter 11 of the USB 2.0
Specification. This parameter should be set to NULL if such a LED indication is not available in the application.
The portOverCurrentDetect parameter must point to a Port Overcurrent Detect function. The driver, while operating in Host mode, will call
this function periodically to check if the attached device is overdrawing current. If the function should return true if such a condition exists. This
parameter should be set to NULL if such detection is not available in the application.
The following code example shows initialization of the driver for device mode operation.
/* This code shows an example of DRV_USBFS_INIT data structure for
* device mode operation. Here the driver is initialized to work with USB1 USB
* module. Note how the endPointTable is defined. It should be aligned on a 512
* byte boundary. */
DRV_USBFS_INIT init;
SYS_MODULE_OBJ usbDriverObj;
uint8_t __attribute__((aligned(512))) endPointTable[DRV_USBFS_ENDPOINTS_NUMBER * 32];
const DRV_USBFS_INIT drvUSBInit =
{
/* Assign the endpoint table */
.endpointTable = endPointTable,
/* Interrupt Source for USB module */
.interruptSource = INT_SOURCE_USB_1,
/* System module initialization. */
.moduleInit = {SYS_MODULE_POWER_RUN_FULL},
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1179
/* Configure the driver for device mode operation. */
.operationMode = DRV_USBFS_OPMODE_DEVICE,
/* Configure the driver to operate at full speed. */
.operationSpeed = USB_SPEED_FULL,
/* Stop in idle */
.stopInIdle = false,
/* Suspend in sleep */
.suspendInSleep = false,
/* Identifies peripheral (PLIB-level) ID */
.usbID = USB_ID_1
};
void SYS_Initialize(void)
{
/* Initialize the USB Driver. Note how the init parameter is typecasted to
* SYS_MODULE_INIT type. The SYS_MODULE_OBJ returned by this function call
* is passed to the driver tasks routine. DRV_USBFS_INDEX_0 is helper
* constant defined in drv_usbfs.h */
usbDriverObj = DRV_USBFS_Initialize(DRV_USBFS_INDEX_0, (SYS_MODULE_INIT *)(drvUSBInit));
}
void SYS_Tasks(void)
{
/* The polled state of the USB driver is updated by calling the
* DRV_USBFS_Tasks function in the SYS_Tasks() function. The
* DRV_USBFS_Tasks() takes the driver module object returned by the
* DRV_USBFS_Initialize funciton as a parameter. */
DRV_USBFS_Tasks(usbDriverObj);
}
void __ISR(_USB_1_VECTOR, ipl4AUTO) _IntHandlerUSBInstance0(void)
{
/* The DRV_USBFS_Tasks_ISR function update the interrupt state of the USB
* Driver. If the driver is configured for polling mode, this function need
* not be invoked or included in the project. */
DRV_USBFS_Tasks_ISR(sysObj.drvUSBObject);
}
The following code example shows initialization of the driver for host mode operation.
/* This code shows an example of the USBFS driver can be configured for
* host mode operation. For host mode operation, only one endpoint is needed and
* hence the size of the endpoint table is 32 bytes (for one endpoint). In this
* example, the BSP_USBVBUSSwitchOverCurrentDetect function checks for over
* current condition and the BSP_USBVBUSPowerEnable function enables the VBUS
* power. The port indication function is not implemented and hence the
* portIndication member of the initialization data structure is set to NULL. */
/* The implementation of the port over current detect, indication and the VBUS
* power supply functions is discussed later in this help section. */
uint8_t __attribute__((aligned(512))) endpointTable[32];
DRV_USBFS_INIT drvUSBFSInit =
{
/* Pointer to the endpoint table */
.endpointTable = endpointTable,
/* Interrupt Source for the USB module */
.interruptSource = INT_SOURCE_USB_1,
/* This should always be set to SYS_MODULE_POWER_RUN_FULL. */
.moduleInit = {SYS_MODULE_POWER_RUN_FULL},
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1180
/* Configure for host mode operation. */
.operationMode = DRV_USBFS_OPMODE_HOST,
/* The driver should run at full speed. */
.operationSpeed = USB_SPEED_FULL,
/* Port indication function is not implemented. */
.portIndication = NULL,
/* This is the over current detect function. */
.portOverCurrentDetect = BSP_USBVBUSSwitchOverCurrentDetect,
/* This is the VBUS Power enable function */
.portPowerEnable = BSP_USBVBUSPowerEnable,
/* Here we state that the VBUS power supply can provide at most 500 mA of
* current */
.rootHubAvailableCurrent = 500,
/* Module will operate in IDLE. */
.stopInIdle = false,
/* Module will not suspend automatically in sleep */
.suspendInSleep = false,
/* USB Module ID is 1 */
.usbID = USB_ID_1
};
void SYS_Initialize(void)
{
/* Initialize the USB Driver. Note how the init parameter is typecasted to
* SYS_MODULE_INIT type. The SYS_MODULE_OBJ returned by this function call
* is passed to the driver tasks routine. DRV_USBFS_INDEX_0 is helper
* constant defined in drv_usbfs.h */
usbDriverObj = DRV_USBFS_Initialize(DRV_USBFS_INDEX_0,
(SYS_MODULE_INIT *)(drvUSBInit));
}
void SYS_Tasks(void)
{
/* The polled state of the USB driver is updated by calling the
* DRV_USBFS_Tasks function in the SYS_Tasks() function. The
* DRV_USBFS_Tasks() takes the driver module object returned by the
* DRV_USBFS_Initialize funciton as a parameter. */
DRV_USBFS_Tasks(usbDriverObj);
}
void __ISR(_USB_1_VECTOR, ipl4AUTO) _IntHandlerUSBInstance0(void)
{
/* The DRV_USBFS_Tasks_ISR function update the interrupt state of the USB
* Driver. If the driver is configured for polling mode, this function need
* not be invoked or included in the project. */
DRV_USBFS_Tasks_ISR(sysObj.drvUSBObject);
}
The PIC32MX USB Driver requires definition of configuration constants to be available in the system_config.h file of the MPLAB Harmony
Application Project Configuration. Refer to the Configuring the Library section for details.
Multi-client Operation
The PIC32MX USB Driver supports multi-client operation. In that, it can be opened by two application clients. This is required where Dual
Operation is desired. The following should be noted when using multi-client operation:
• The driver should be initialized for Dual Role Operation mode.
• The DRV_USBFS_Open function can be called at the most twice in the application. The driver supports a maximum of two clients.
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1181
• A client can access either the host or device functionality of the driver. It cannot do both.
• It is possible for the two clients to operate in two different threads while operating with an RTOS.
Note:
The typical the application clients for PIC32MX USB Driver would be the MPLAB Harmony USB Host and Device Stack. The
complexity of operating the driver in Dual Role mode is handled by the stack operation. The MHC will configure the driver for Dual
Role operation when such operation is selected in USB Stack configuration tree.
USB Driver Common Interface
The PIC32MX USB Driver exports its implementation of the USB Driver Common Interface to the Host and Device Layer via the
DRV_USBFS_HOST_INTERFACE and DRV_USBFS_DEVICE_INTERFACE structures. The DRV_USBFS_HOST_INTERFACE structure is
defined in the drv_usbfs_host.c file. The following code example shows this structure.
/**********************************************************
* This structure is a set of pointer to the USBFS driver
* functions. It is provided to the host and device layer
* as the interface to the driver.
* *******************************************************/
DRV_USB_HOST_INTERFACE gDrvUSBFSHostInterface =
{
.open = DRV_USBFS_Open,
.close = DRV_USBFS_Close,
.eventHandlerSet = DRV_USBFS_ClientEventCallBackSet,
.hostIRPSubmit = DRV_USBFS_HOST_IRPSubmit,
.hostIRPCancel = DRV_USBFS_HOST_IRPCancel,
.hostPipeSetup = DRV_USBFS_HOST_PipeSetup,
.hostPipeClose = DRV_USBFS_HOST_PipeClose,
.hostEventsDisable = DRV_USBFS_HOST_EventsDisable,
.hostEventsEnable = DRV_USBFS_HOST_EventsEnable,
.rootHubInterface.rootHubPortInterface.hubPortReset = DRV_USBFS_HOST_ROOT_HUB_PortReset,
.rootHubInterface.rootHubPortInterface.hubPortSpeedGet = DRV_USBFS_HOST_ROOT_HUB_PortSpeedGet,
.rootHubInterface.rootHubPortInterface.hubPortResetIsComplete =
DRV_USBFS_HOST_ROOT_HUB_PortResetIsComplete,
.rootHubInterface.rootHubPortInterface.hubPortSuspend = DRV_USBFS_HOST_ROOT_HUB_PortSuspend,
.rootHubInterface.rootHubPortInterface.hubPortResume = DRV_USBFS_HOST_ROOT_HUB_PortResume,
.rootHubInterface.rootHubMaxCurrentGet = DRV_USBFS_HOST_ROOT_HUB_MaximumCurrentGet,
.rootHubInterface.rootHubPortNumbersGet = DRV_USBFS_HOST_ROOT_HUB_PortNumbersGet,
.rootHubInterface.rootHubSpeedGet = DRV_USBFS_HOST_ROOT_HUB_BusSpeedGet,
.rootHubInterface.rootHubInitialize = DRV_USBFS_HOST_ROOT_HUB_Initialize,
.rootHubInterface.rootHubOperationEnable = DRV_USBFS_HOST_ROOT_HUB_OperationEnable,
.rootHubInterface.rootHubOperationIsEnabled = DRV_USBFS_HOST_ROOT_HUB_OperationIsEnabled,
};
The DRV_USBFS_DEVICE_INTERFACE structure is defined in the drv_usbfs_device.c file. The following code example shows this
structure. The MPLAB Harmony USB Host and Device stack perform driver independent access through the function pointers contained in these
structures.
/*****************************************************
* This structure is a pointer to a set of USB Driver
* Device mode functions. This set is exported to the
* device layer when the device layer must use the
* PIC32MX USB Controller.
******************************************************/
DRV_USB_DEVICE_INTERFACE gDrvUSBFSDeviceInterface =
{
.open = DRV_USBFS_Open,
.close = DRV_USBFS_Close,
.eventHandlerSet = DRV_USBFS_ClientEventCallBackSet,
.deviceAddressSet = DRV_USBFS_DEVICE_AddressSet,
.deviceCurrentSpeedGet = DRV_USBFS_DEVICE_CurrentSpeedGet,
.deviceSOFNumberGet = DRV_USBFS_DEVICE_SOFNumberGet,
.deviceAttach = DRV_USBFS_DEVICE_Attach,
.deviceDetach = DRV_USBFS_DEVICE_Detach,
.deviceEndpointEnable = DRV_USBFS_DEVICE_EndpointEnable,
.deviceEndpointDisable = DRV_USBFS_DEVICE_EndpointDisable,
.deviceEndpointStall = DRV_USBFS_DEVICE_EndpointStall,
.deviceEndpointStallClear = DRV_USBFS_DEVICE_EndpointStallClear,
.deviceEndpointIsEnabled = DRV_USBFS_DEVICE_EndpointIsEnabled,
.deviceEndpointIsStalled = DRV_USBFS_DEVICE_EndpointIsStalled,
.deviceIRPSubmit = DRV_USBFS_DEVICE_IRPSubmit,
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1182
.deviceIRPCancel = DRV_USBFS_DEVICE_IRPCancel,
.deviceIRPCancelAll = DRV_USBFS_DEVICE_IRPCancelAll,
.deviceRemoteWakeupStop = DRV_USBFS_DEVICE_RemoteWakeupStop,
.deviceRemoteWakeupStart = DRV_USBFS_DEVICE_RemoteWakeupStart,
.deviceTestModeEnter = NULL
};
Operation with RTOS
The PIC32MX USB Driver is designed to operate with a RTOS. The driver implementation uses the MPLAB Harmony Operating System
Abstraction Layer (OSAL). This allows the driver to function with entire range of RTOSes supported in MPLAB Harmony. The following points must
be considered while using the driver with an RTOS.
• The driver can be opened from different threads
• In Device mode, an enabled endpoint should only be accessed from one thread. For example, if an application requires two endpoints,
Endpoint 2 and Endpoint 3, the application could contain two threads, one accessing Endpoint 2 and another accessing Endpoint 3. The thread
accessing Endpoint 2 cannot access Endpoint 3.
• While operating in Host mode, endpoint pipes can be opened from different threads. A pipe handle to an open pipe cannot be shared across
threads.
Host Mode Attach Detach Operation
When the PIC32MX USB Driver operating in Host mode detects a device attach or detach, it implements debouncing before signaling attach
detach signal to the USB Host Stack. When the device is attached, the driver waits for DRV_USBFS_HOST_ATTACH_DEBOUNCE_DURATION
milliseconds to allow for the mechanical chatter, which occurs when the device is inserted into the host receptacle, to settle. If the device is still
attached after the DRV_USBFS_HOST_ATTACH_DEBOUNCE_DURATION expires, the driver calls the USB_HOST_DeviceEnumerate function
to let the host stack enumerate the device. It also starts checking for Device Detach.
When the device is detached, the driver waits for DRV_USBFS_POST_DETACH_DELAY milliseconds to allow for the detach operation to settle. If
the device is indeed detached after the DRV_USBFS_POST_DETACH_DELAY delay expires, the driver calls USB_HOST_DeviceDenumerate
function to let the USB Host stack denumerate the device. It then starts checking for device attach.
Root Hub Operation
The PIC32MX USB Driver implements a Root Hub Driver Interface. This allows the driver to emulate a hub. The USB Host Stack enumerates the
Root Hub as a device. The Host Stack then does not differentiate between an external hub and the root hub. While emulating a hub, the PIC32MX
USB Driver Root Hub appears as a single port hub.
As a part of the root hub interface, the PIC32MX USB Driver requires the application to supply functions for hub features that it does not
implement. These features are:
• Port Overcurrent Detect
• VBUS Switch Control
• Port Indication
A pointer to these functions (if implemented) must be supplied through the driver initialization data (of the type DRV_USBFS_INIT) structure at the
time of driver initialization. The application has the option of not implementing these functions. In such a case, the function pointers for the
unimplemented function, in the initialization data structure should be set to NULL.
The root hub driver must also be able to communicate the maximum current capability of its port to the USB Host Layer. The PIC32MX USB
Controller does not contain built-in (hardware implemented) functionality for controlling the root hub port current. To facilitate this request, the
driver will report the current capability that was specified in the rootHubAvailableCurrent parameter of the driver initialization data structure.
The application must set this parameter to report the current supply capability of the VBUS power supply. The USB Host Layer uses this value to
manage the bus current budget. If a connected device reports a configuration that requires more current than what the VBUS power supply can
provide, the host will not set the configuration.
Port Overcurrent Detect
The Root Hub operation in PIC32MX USB Driver will periodically call a Port Overcurrent Detect function to detect if an overcurrent condition is
active on the port. The application must supply this function if port overcurrent detection is needed. The PIC32MX USB Controller does not contain
built-in (hardware implemented) functionality for checking overcurrent condition. The overcurrent condition on the port can occur in a case where
the attached device has malfunctioned or when the USB VBUS line has short circuited to ground.
The signature of the function and an example implementation is shown in the following code example. The function must return (and must continue
to return) true if an overcurrent condition exists on the port.
/* This code shows an example implementation of the
* portOverCurrentDetect function. The PIC32MX USB Driver will call this
* function periodically to check if an over current condition exists on the
* port. In this example, we assume that the over current detect pin from an
* external circuit in the system, is connected to port RD0 and the pin logic
* is active high. The function must return true if an over current condition is
* present on this pin */
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1183
bool BSP_USBVBUSSwitchOverCurrentDetect(uint8_t port)
{
if(PLIB_PORTS_PinGet(PORTS_ID_0, PORT_CHANNEL_D, 0) == 1)
{
return(true);
}
else
{
return(false);
}
}
VBUS Switch Control
The PIC32MX USB Driver Root Hub operation will attempt to control the VBUS power supply to the port. Because the PIC32MX USB Controller
does not contain built-in (hardware implemented) functionality for checking controlling VBUS, such a control function must be supplied by the
application. The root hub operation will access this function when the PIC32MX USB Driver will call the portPowerEnable function as a part of the
Bus Enable sequence.
The following code shows an example of how this function can be implemented.
/* This code shows an example implementation of the VBUS Power Enable
* function. The PIC32MX USB Driver will call this function as a part of bus
* enable function. In this example, it is assumed that system contains an
* external VBUS power switch and this is control by port RB5.
*/
void BSP_USBVBUSPowerEnable(uint8_t port, bool enable)
{
if(enable)
{
PLIB_PORTS_PinSet(PORTS_ID_0, PORT_CHANNEL_B, PORTS_BIT_POS_5);
}
else
{
PLIB_PORTS_PinClear(PORTS_ID_0, PORT_CHANNEL_B, PORTS_BIT_POS_5);
}
}
Port Indication function
The Root Hub Operation in the PIC32MX USB Driver allows display of Port LED status. If the application requires this indication, it must implement
a function which the Root Hub operation would call when a change in the Root Hub port has occurred. The port indication operation is specified in
Section 11.5.3 of the USB 2.0 Specification.
/* This code shows an example implementation of the port indication
* function. The PIC32MX USB Driver calls this function when it wants to indicate
* port status. It is assumed that three function to switch off, blink and
* switch on an LED are available. It is further assumed that these function
* accept the color of the LED to operated on. */
void BSP_RootHubPortIndication
(
uint8_t port,
USB_HUB_PORT_INDICATOR_COLOR color,
USB_HUB_PORT_INDICATOR_STATE state
)
{
/* The color parameter indicates the color of the LED to be affected. The
* color will be either USB_HUB_PORT_INDICATOR_COLOR_GREEN or
* USB_HUB_PORT_INDICATOR_COLOR_AMBER. */
switch (state)
{
case USB_HUB_PORT_INDICATOR_STATE_OFF:
BSP_SwitchLEDOff(color);
break;
case USB_HUB_PORT_INDICATOR_STATE_BLINKING:
BSP_LEDBlink(color);
break;
case USB_HUB_PORT_INDICATOR_STATE_ON:
BSP_SwitchLEDOn(color);
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1184
break;
default:
break;
}
}
Configuring the Library
Provides information on the configuring the library.
Macros
Name Description
DRV_USBFS_DEVICE_SUPPORT Determines if the USB Device Functionality should be enabled.
DRV_USBFS_ENDPOINTS_NUMBER Configures the number of endpoints to be provisioned in the driver.
DRV_USBFS_HOST_ATTACH_DEBOUNCE_DURATION Configures the time duration (in milliseconds) that the driver will wait to
re-confirm a device attach.
DRV_USBFS_HOST_NAK_LIMIT Configures the NAK Limit for Host Mode Control Transfers.
DRV_USBFS_HOST_PIPES_NUMBER Configures the maximum number of pipes that are can be opened
when the driver is operating in Host mode.
DRV_USBFS_HOST_RESET_DURATION Configures the time duration (in milliseconds) of the Reset Signal.
DRV_USBFS_HOST_SUPPORT Determines if the USB Host Functionality should be enabled.
DRV_USBFS_INSTANCES_NUMBER Specifies the number of driver instances to be enabled in the
application.
DRV_USBFS_INTERRUPT_MODE Configures the driver for interrupt or polling mode operation.
Description
The PIC32MX USB Driver requires the specification of compile-time configuration macros. These macros define resource usage, feature
availability, and dynamic behavior of the driver. These configuration macros should be defined in the system_config.h file.
This header can be placed anywhere, the path of this header needs to be present in the include search path for a successful build. Refer to the
Applications Help section for more details.
DRV_USBFS_DEVICE_SUPPORT Macro
Determines if the USB Device Functionality should be enabled.
File
drv_usbfs_config_template.h
C
#define DRV_USBFS_DEVICE_SUPPORT true
Description
USB Full Speed Driver Device Mode Support.
This constant should be set to true if USB device support is required in the application. It should be set to false if device support is not required.
Remarks
This constant should always be defined.
DRV_USBFS_ENDPOINTS_NUMBER Macro
Configures the number of endpoints to be provisioned in the driver.
File
drv_usbfs_config_template.h
C
#define DRV_USBFS_ENDPOINTS_NUMBER 3
Description
USB Full Speed Driver Endpoint Numbers.
This constant configures the number of endpoints that the driver needs to manage. When DRV_USBFS_DEVICE_SUPPORT is enabled, this
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1185
constant should be set to the total number of endpoints to be enabled in the device. When enabled, a endpoint can be used for communication.
Using any direction of an endpoint will require that entire endpoint to be enabled.
Consider the case of a composite USB Device that containing a CDC and MSD function. The CDC function will require 1 Bulk endpoint (OUT and
IN directions) and 1 Interrupt endpoint (IN direction). The MSD function will require 1 Bulk endpoint (IN and OUT directions). This design can be
implemented by using 4 endpoints. Endpoint 0 is used for the mandatory control interface. Endpoint 1 is used for CDC Bulk interface. Endpoint 2 is
used for CDC interrupt interface and endpoint 3 is used for MSD Bulk Interface. The constant should then be set to 4.
For Host mode operation, this constant should be set to 1. Setting this to greater than 1 will result in unused data memory allocation.
Remarks
This constant should always be defined.
DRV_USBFS_HOST_ATTACH_DEBOUNCE_DURATION Macro
Configures the time duration (in milliseconds) that the driver will wait to re-confirm a device attach.
File
drv_usbfs_config_template.h
C
#define DRV_USBFS_HOST_ATTACH_DEBOUNCE_DURATION 500
Description
USB Full Speed Driver Host Mode Attach Debounce Duration.
This constant configures the time duration (in milliseconds) that driver will wait to re-confirm a device attach. When the driver first detects device
attach, it start, it will start a timer for the duration specified by the constant. When the timer expires, the driver will check if the device is still
attached. If so, the driver will then signal attach to the host stack. The duration allows for device attach to become electro-mechanically stable.
Remarks
This constant should always be defined when DRV_USBFS_HOST_SUPPORT is set to true.
DRV_USBFS_HOST_NAK_LIMIT Macro
Configures the NAK Limit for Host Mode Control Transfers.
File
drv_usbfs_config_template.h
C
#define DRV_USBFS_HOST_NAK_LIMIT 2000
Description
USB Full Speed Driver Host Mode Control Transfers NAK Limit.
This constant configures the number of NAKs that the driver can accept from the device in the data stage of a control transfer before aborting the
control transfer with a USB_HOST_IRP_STATUS_ERROR_NAK_TIMEOUT. Setting this constant to 0 will disable NAK limit checking. This
constant should be adjusted to enable USB host compatibility with USB Devices which require more time to process control transfers.
Remarks
This constant should always be defined when DRV_USBFS_HOST_SUPPORT is set to true.
DRV_USBFS_HOST_PIPES_NUMBER Macro
Configures the maximum number of pipes that are can be opened when the driver is operating in Host mode.
File
drv_usbfs_config_template.h
C
#define DRV_USBFS_HOST_PIPES_NUMBER 10
Description
USB Full Speed Driver Host Mode Pipes Number.
This constant configures the maximum number of pipes that can be opened when the driver is operating in Host mode. Calling the
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1186
DRV_USBFS_HOST_PipeSetup function will cause a pipe to be opened. Calling this function when DRV_USBFS_HOST_PIPES_NUMBER
number of pipes have already been opened will cause the function to return an Invalid Pipe Handle. This constant should be configured to account
for the maximum number of devices and the device types to be supported by the host application.
For example if the USB Host application must support 2 USB Mass Storage devices and 1 CDC device, it must set this constant 9 ( 4 bulk pipes
for 2 Mass Storage devices + 2 bulk pipes and 1 interrupt pipe for 1 CDC device and 2 control pipes for 2 devices). Allocating pipes consumes
data memory.
Remarks
This constant should always be defined when DRV_USBFS_HOST_SUPPORT is set to true.
DRV_USBFS_HOST_RESET_DURATION Macro
Configures the time duration (in milliseconds) of the Reset Signal.
File
drv_usbfs_config_template.h
C
#define DRV_USBFS_HOST_RESET_DURATION 100
Description
USB Full Speed Driver Host Mode Reset Duration.
This constant configures the duration of the reset signal. The driver generates reset signal when the USB Host stack requests for root hub port
reset. The driver will generate the reset signal for the duration specified by this constant and will then stop generating the reset signal.
Remarks
This constant should always be defined when DRV_USBFS_HOST_SUPPORT is set to true.
DRV_USBFS_HOST_SUPPORT Macro
Determines if the USB Host Functionality should be enabled.
File
drv_usbfs_config_template.h
C
#define DRV_USBFS_HOST_SUPPORT false
Description
USB Full Speed Driver Host Mode Support.
This constant should be set to true if USB Host mode support is required in the application. It should be set to false if host support is not required.
Remarks
This constant should always be defined.
DRV_USBFS_INSTANCES_NUMBER Macro
Specifies the number of driver instances to be enabled in the application.
File
drv_usbfs_config_template.h
C
#define DRV_USBFS_INSTANCES_NUMBER 1
Description
USB Full Speed Driver Instances Number.
This constant defines the number of driver instances to be enabled in the application. This will be typically be the number of USB controllers to be
used in the application. On PIC32MX microcontrollers that have one USB controller, this value will always be 1. On PIC32MX microcontrollers
which have 2 USB controllers, this value could 1 or 2, depending on whether 1 or 2 USB segments are required. To conserve data memory, this
constant should be set to exactly the number of USB controller that are required in the system.
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1187
Remarks
This constant should always be defined.
DRV_USBFS_INTERRUPT_MODE Macro
Configures the driver for interrupt or polling mode operation.
File
drv_usbfs_config_template.h
C
#define DRV_USBFS_INTERRUPT_MODE true
Description
USB Full Speed Driver Interrupt Mode.
This constant configures the driver for interrupt or polling operation. If this flag is set to true, the driver will operate in interrupt mode. If the flag is
set to false, the driver will operate in polled mode. In polled, the driver interrupt state machine gets updated in the SYS_Tasks(). If the driver is
configured interrupt mode, the driver interrupt state machine gets updated in the driver interrupt service routine. It is always recommended for the
driver to operate in interrupt mode.
Remarks
This constant should always be defined.
Building the Library
This section lists the files that are available in the PIC32MX USB Driver Library.
Description
This section list the files that are available in the \src folder of the PIC32MX USB Driver. It lists which files need to be included in the build based
on either a hardware feature present on the board or configuration option selected by the system.
The following three tables list and describe the header (.h) and source (.c) files that implement this library. The parent folder for these files is
/framework/driver/usb/usbfs.
Interface File(s)
This table lists and describes the header files that must be included (i.e., using #include) by any code that uses this library.
Source File Name Description
/drv_usbfs.h This file should be included by any .c file which accesses the PIC32MX USB Driver API. This one file contains the
prototypes for all driver API.
Required File(s)
All of the required files listed in the following table are automatically added into the MPLAB X IDE project by the MHC
when the library is selected for use.
This table lists and describes the source and header files that must always be included in the MPLAB X IDE project to build this library.
Source File Name Description
/src/dynamic/drv_usbfs.c This file should always be included in the project when using the PIC3MX USB Driver.
Optional File(s)
This table lists and describes the source and header files that may optionally be included if required for the desired implementation.
Source File Name Description
/src/dynamic/drv_usbfs_device.c This file should be included in the project if Device mode operation is required.
/src/dynamic/drv_usbfs_host.c This file should be included in the project if Host mode operation is required.
Module Dependencies
The PIC32MX USB Driver Library depends on the following modules:
• Interrupt System Service Library
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1188
Library Interface
a) System Functions
Name Description
DRV_USBFS_Status Provides the current status of the USB Driver module.
DRV_USBFS_Tasks Maintains the driver's state machine when the driver is configured for Polled mode.
DRV_USBFS_Tasks_ISR Maintains the driver's Interrupt state machine and implements its ISR.
b) Client Core Functions
Name Description
DRV_USBFS_ClientEventCallBackSet This function sets up the event callback function that is invoked by the USB controller
driver to notify the client of USB bus events.
DRV_USBFS_Close Closes an opened-instance of the USB Driver.
DRV_USBFS_Initialize Initializes the USB Driver.
DRV_USBFS_Open Opens the specified USB Driver instance and returns a handle to it.
c) Device Mode Operation Functions
Name Description
DRV_USBFS_DEVICE_AddressSet This function will set the USB module address that is obtained from the Host.
DRV_USBFS_DEVICE_Attach This function will enable the attach signaling resistors on the D+ and D- lines thus
letting the USB Host know that a device has been attached on the bus.
DRV_USBFS_DEVICE_CurrentSpeedGet This function returns the USB speed at which the device is operating.
DRV_USBFS_DEVICE_Detach This function will disable the attach signaling resistors on the D+ and D- lines thus
letting the USB Host know that the device has detached from the bus.
DRV_USBFS_DEVICE_EndpointDisable This function disables an endpoint.
DRV_USBFS_DEVICE_EndpointDisableAll This function disables all provisioned endpoints.
DRV_USBFS_DEVICE_EndpointEnable This function enables an endpoint for the specified direction and endpoint size.
DRV_USBFS_DEVICE_EndpointIsEnabled This function returns the enable/disable status of the specified endpoint and
direction.
DRV_USBFS_DEVICE_EndpointIsStalled This function returns the stall status of the specified endpoint and direction.
DRV_USBFS_DEVICE_EndpointStall This function stalls an endpoint in the specified direction.
DRV_USBFS_DEVICE_EndpointStallClear This function clears the stall on an endpoint in the specified direction.
DRV_USBFS_DEVICE_IRPCancel This function cancels the specific IRP that are queued and in progress at the
specified endpoint.
DRV_USBFS_DEVICE_IRPCancelAll This function cancels all IRPs that are queued and in progress at the specified
endpoint.
DRV_USBFS_DEVICE_IRPSubmit This function submits an I/O Request Packet (IRP) for processing to the Hi-Speed
USB Driver.
DRV_USBFS_DEVICE_RemoteWakeupStart This function causes the device to start Remote Wakeup Signalling on the bus.
DRV_USBFS_DEVICE_RemoteWakeupStop This function causes the device to stop the Remote Wakeup Signalling on the bus.
DRV_USBFS_DEVICE_SOFNumberGet This function will return the USB SOF packet number.
d) Host Mode Operation Functions
Name Description
DRV_USBFS_HOST_EventsDisable Disables Host mode events.
DRV_USBFS_HOST_EventsEnable Restores the events to the specified the original value.
DRV_USBFS_HOST_IRPCancel Cancels the specified IRP.
DRV_USBFS_HOST_IRPSubmit Submits an IRP on a pipe.
DRV_USBFS_HOST_PipeClose Closes an open pipe.
DRV_USBFS_HOST_PipeSetup Open a pipe with the specified attributes.
e) Root Hub Functions
Name Description
DRV_USBFS_HOST_ROOT_HUB_BusSpeedGet This function returns the operating speed of the bus to which this root
hub is connected.
DRV_USBFS_HOST_ROOT_HUB_Initialize This function initializes the root hub driver.
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1189
DRV_USBFS_HOST_ROOT_HUB_MaximumCurrentGet Returns the maximum amount of current that this root hub can provide
on the bus.
DRV_USBFS_HOST_ROOT_HUB_OperationEnable This function enables or disables root hub operation.
DRV_USBFS_HOST_ROOT_HUB_OperationIsEnabled Returns the operation enabled status of the root hub.
DRV_USBFS_HOST_ROOT_HUB_PortNumbersGet Returns the number of ports this root hub contains.
DRV_USBFS_HOST_ROOT_HUB_PortReset Resets the specified root hub port.
DRV_USBFS_HOST_ROOT_HUB_PortResetIsComplete Returns true if the root hub has completed the port reset operation.
DRV_USBFS_HOST_ROOT_HUB_PortResume Resumes the specified root hub port.
DRV_USBFS_HOST_ROOT_HUB_PortSpeedGet Returns the speed of at which the port is operating.
DRV_USBFS_HOST_ROOT_HUB_PortSuspend Suspends the specified root hub port.
f) Data Types and Constants
Name Description
DRV_USBFS_EVENT Identifies the different events that the USB Driver provides.
DRV_USBFS_EVENT_CALLBACK Type of the USB Driver event callback function.
DRV_USBFS_HOST_PIPE_HANDLE Defines the USB Driver Host Pipe Handle type.
DRV_USBFS_INIT This type definition defines the Driver Initialization Data
Structure.
DRV_USBFS_OPMODES Identifies the operating modes supported by the USB Driver.
DRV_USBFS_ROOT_HUB_PORT_INDICATION USB Root hub Application Hooks (Port Indication).
DRV_USBFS_ROOT_HUB_PORT_OVER_CURRENT_DETECT USB Root hub Application Hooks (Port Overcurrent detection).
DRV_USBFS_ROOT_HUB_PORT_POWER_ENABLE USB Root hub Application Hooks (Port Power Enable/ Disable).
DRV_USBFS_DEVICE_INTERFACE USB Driver Device Mode Interface Functions.
DRV_USBFS_ENDPOINT_TABLE_ENTRY_SIZE USB Driver Endpoint Table Entry Size in bytes.
DRV_USBFS_HOST_INTERFACE USB Driver Host Mode Interface Functions.
DRV_USBFS_HOST_PIPE_HANDLE_INVALID Value of an Invalid Host Pipe Handle.
DRV_USBFS_INDEX_0 USB Driver Module Index 0 Definition.
DRV_USBFS_INDEX_1 USB Driver Module Index 1 Definition.
Description
This section describes the functions of the PIC32MX USB Driver Library.
Refer to each section for a detailed description.
a) System Functions
DRV_USBFS_Status Function
Provides the current status of the USB Driver module.
File
drv_usbfs.h
C
SYS_STATUS DRV_USBFS_Status(SYS_MODULE_OBJ object);
Returns
• SYS_STATUS_READY - Indicates that the driver is ready.
• SYS_STATUS_UNINITIALIZED - Indicates that the driver has never been initialized.
Description
This function provides the current status of the USB Driver module.
Remarks
None.
Preconditions
The DRV_USBFS_Initialize function must have been called before calling this function.
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1190
Example
SYS_MODULE_OBJ object; // Returned from DRV_USBFS_Initialize
SYS_STATUS status;
DRV_USBFS_INIT moduleInit;
uint8_t __attribute__((aligned(512))) endpointTable[DRV_USBFS_ENDPOINT_TABLE_ENTRY_SIZE * 2];
usbInitData.usbID = USB_ID_1;
usbInitData.opMode = DRV_USBFS_OPMODE_DEVICE;
usbInitData.stopInIdle = false;
usbInitData.suspendInSleep = false;
usbInitData.operationSpeed = USB_SPEED_FULL;
usbInitData.interruptSource = INT_SOURCE_USB;
usbInitData.sysModuleInit.powerState = SYS_MODULE_POWER_RUN_FULL ;
// This is how this data structure is passed to the initialize
// function.
DRV_USBFS_Initialize(DRV_USBFS_INDEX_0, (SYS_MODULE_INIT *) &usbInitData);
// The status of the driver can be checked.
status = DRV_USBFS_Status(object);
if(SYS_STATUS_READY == status)
{
// Driver is ready to be opened.
}
Parameters
Parameters Description
object Driver object handle, returned from the DRV_USBFS_Initialize function.
Function
SYS_STATUS DRV_USBFS_Status ( SYS_MODULE_OBJ object )
DRV_USBFS_Tasks Function
Maintains the driver's state machine when the driver is configured for Polled mode.
File
drv_usbfs.h
C
void DRV_USBFS_Tasks(SYS_MODULE_OBJ object);
Returns
None.
Description
Maintains the driver's Polled state machine. This function should be called from the SYS_Tasks function.
Remarks
This routine is normally not called directly by an application. It is called by the system's Tasks routine (SYS_Tasks). This function will never block.
Preconditions
The DRV_USBFS_Initialize function must have been called for the specified USB Driver instance.
Example
SYS_MODULE_OBJ object; // Returned from DRV_USBFS_Initialize
while (true)
{
DRV_USBFS_Tasks(object);
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1191
// Do other tasks
}
Parameters
Parameters Description
object Object handle for the specified driver instance (returned from DRV_USBFS_Initialize function).
Function
void DRV_USBFS_Tasks( SYS_MODULE_OBJ object )
DRV_USBFS_Tasks_ISR Function
Maintains the driver's Interrupt state machine and implements its ISR.
File
drv_usbfs.h
C
void DRV_USBFS_Tasks_ISR(SYS_MODULE_OBJ object);
Returns
None.
Description
This function is used to maintain the driver's internal Interrupt state machine and implement its ISR for interrupt-driven implementations.
Remarks
This routine should be called from the USB interrupt service routine. In case of multiple USB modules, it should be ensured that the correct USB
driver system module object is passed to this routine.
Preconditions
The DRV_USBFS_Initialize function must have been called for the specified USB Driver instance.
Example
SYS_MODULE_OBJ object; // Returned from DRV_USBFS_Initialize
while (true)
{
DRV_USBFS_Tasks_ISR (object);
// Do other tasks
}
Parameters
Parameters Description
object Object handle for the specified driver instance (returned from DRV_USBFS_Initialize).
Function
void DRV_USBFS_Tasks_ISR( SYS_MODULE_OBJ object )
b) Client Core Functions
DRV_USBFS_ClientEventCallBackSet Function
This function sets up the event callback function that is invoked by the USB controller driver to notify the client of USB bus events.
File
drv_usbfs.h
C
void DRV_USBFS_ClientEventCallBackSet(DRV_HANDLE handle, uintptr_t hReferenceData, DRV_USB_EVENT_CALLBACK
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1192
myEventCallBack);
Returns
None.
Description
This function sets up the event callback function that is invoked by the USB controller driver to notify the client of USB bus events. The callback is
disabled by either not calling this function after the DRV_USBFS_Open function has been called or by setting the myEventCallBack argument as
NULL. When the callback function is called, the hReferenceData argument is returned.
Remarks
Typical usage of the USB Driver requires a client to register a callback.
Preconditions
None.
Example
// Set the client event callback for the Device Layer. The
// USBDeviceLayerEventHandler function is the event handler. When this
// event handler is invoked by the driver, the driver returns back the
// second argument specified in the following function (which in this case
// is the Device Layer data structure). This allows the application
// firmware to identify, as an example, the Device Layer object associated
// with this callback.
DRV_USBFS_ClientEventCallBackSet(myUSBDevice.usbDriverHandle, (uintptr_t)&myUSBDevice,
USBDeviceLayerEventHandler);
Parameters
Parameters Description
handle Client's driver handle (returned from DRV_USBFS_Open function).
hReferenceData Object (could be a pointer) that is returned with the callback.
myEventCallBack Callback function for all USB events.
Function
void DRV_USBFS_ClientEventCallBackSet
(
DRV_HANDLE handle,
uintptr_t hReferenceData,
DRV_USBFS_EVENT_CALLBACK myEventCallBack
);
DRV_USBFS_Close Function
Closes an opened-instance of the USB Driver.
File
drv_usbfs.h
C
void DRV_USBFS_Close(DRV_HANDLE handle);
Returns
None.
Description
This function closes an opened-instance of the USB Driver, invalidating the handle.
Remarks
After calling this function, the handle passed in handle parameter must not be used with any of the other driver functions. A new handle must be
obtained by calling DRV_USBFS_Open function before the caller may use the driver again.
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1193
Preconditions
The DRV_USBFS_Initialize function must have been called for the specified USB Driver instance. DRV_USBFS_Open function must have been
called to obtain a valid opened device handle.
Example
DRV_HANDLE handle; // Returned from DRV_USBFS_Open
DRV_USBFS_Close(handle);
Parameters
Parameters Description
handle Client's driver handle (returned from DRV_USBFS_Open function).
Function
void DRV_USBFS_Close( DRV_HANDLE handle )
DRV_USBFS_Initialize Function
Initializes the USB Driver.
File
drv_usbfs.h
C
SYS_MODULE_OBJ DRV_USBFS_Initialize(const SYS_MODULE_INDEX drvIndex, const SYS_MODULE_INIT * const init);
Returns
• SYS_MODULE_OBJ_INVALID - The driver initialization failed.
• A valid System Module Object - The driver initialization was able to start. It may have not completed and requires the DRV_USBFS_Tasks
function to be called periodically. This value will never be the same as SYS_MODULE_OBJ_INVALID.
Description
This function initializes the USB Driver, making it ready for clients to open. The driver initialization does not complete when this function returns.
The DRV_USBFS_Tasks function must called periodically to complete the driver initialization. The DRV_USBHS_Open function will fail if the driver
was not initialized or if initialization has not completed.
Remarks
This routine must be called before any other USB driver routine is called. This routine should only be called once during system initialization unless
DRV_USBFS_Deinitialize is called to deinitialize the driver instance.
Preconditions
None.
Example
// The following code shows an example initialization of the
// driver. The USB module to be used is USB1. The module should not
// automatically suspend when the microcontroller enters Sleep mode. The
// module should continue operation when the CPU enters Idle mode. The
// power state is set to run at full clock speeds. Device Mode operation
// should be at FULL speed. The size of the endpoint table is set for 2
// endpoints.
DRV_USBFS_INIT moduleInit;
uint8_t __attribute__((aligned(512))) endpointTable[DRV_USBFS_ENDPOINT_TABLE_ENTRY_SIZE * 2];
usbInitData.usbID = USB_ID_1;
usbInitData.opMode = DRV_USBFS_OPMODE_DEVICE;
usbInitData.stopInIdle = false;
usbInitData.suspendInSleep = false;
usbInitData.operationSpeed = USB_SPEED_FULL;
usbInitData.interruptSource = INT_SOURCE_USB;
usbInitData.sysModuleInit.powerState = SYS_MODULE_POWER_RUN_FULL ;
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1194
// This is how this data structure is passed to the initialize
// function.
DRV_USBFS_Initialize(DRV_USBFS_INDEX_0, (SYS_MODULE_INIT *) &usbInitData);
Parameters
Parameters Description
drvIndex Ordinal number of driver instance to be initialized. This should be set to
DRV_USBFS_INDEX_0 if driver instance 0 needs to be initialized.
init Pointer to a data structure containing data necessary to initialize the driver. This should be a
DRV_USBFS_INIT structure reference typecast to SYS_MODULE_INIT reference.
Function
SYS_MODULE_OBJ DRV_USBHS_Initialize
(
const SYS_MODULE_INDEX drvIndex,
const SYS_MODULE_INIT * const init
)
DRV_USBFS_Open Function
Opens the specified USB Driver instance and returns a handle to it.
File
drv_usbfs.h
C
DRV_HANDLE DRV_USBFS_Open(const SYS_MODULE_INDEX drvIndex, const DRV_IO_INTENT intent);
Returns
• DRV_HANDLE_INVALID - The driver could not be opened successfully.This can happen if the driver initialization was not complete or if an
internal error has occurred.
• A Valid Driver Handle - This is an arbitrary value and is returned if the function was successful. This value will never be the same as
DRV_HANDLE_INVALID.
Description
This function opens the specified USB Driver instance and provides a handle that must be provided to all other client-level operations to identify
the caller and the instance of the driver. The intent flag should always be
DRV_IO_INTENT_EXCLUSIVE|DRV_IO_INTENT_READWRITE|DRV_IO_INTENT_NON_BLOCKING. Any other setting of the intent flag will
return a invalid driver handle. A driver instance can only support one client. Trying to open a driver that has an existing client will result in an
unsuccessful function call.
Remarks
The handle returned is valid until the DRV_USBFS_Close function is called. The function will typically return DRV_HANDLE_INVALID if the driver
was not initialized. In such a case the client should try to open the driver again.
Preconditions
Function DRV_USBFS_Initialize must have been called before calling this function.
Example
DRV_HANDLE handle;
// This code assumes that the driver has been initialized.
handle = DRV_USBFS_Open(DRV_USBFS_INDEX_0, DRV_IO_INTENT_EXCLUSIVE| DRV_IO_INTENT_READWRITE|
DRV_IO_INTENT_NON_BLOCKING);
if(DRV_HANDLE_INVALID == handle)
{
// The application should try opening the driver again.
}
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1195
Parameters
Parameters Description
drvIndex Identifies the driver instance to be opened. As an example, this value can be set to
DRV_USBFS_INDEX_0 if instance 0 of the driver has to be opened.
intent Should always be (DRV_IO_INTENT_EXCLUSIVE|DRV_IO_INTENT_READWRITE|
DRV_IO_INTENT_NON_BLOCKING).
Function
DRV_HANDLE DRV_USBFS_Open
(
const SYS_MODULE_INDEX drvIndex,
const DRV_IO_INTENT intent
)
c) Device Mode Operation Functions
DRV_USBFS_DEVICE_AddressSet Function
This function will set the USB module address that is obtained from the Host.
File
drv_usbfs.h
C
void DRV_USBFS_DEVICE_AddressSet(DRV_HANDLE handle, uint8_t address);
Returns
None.
Description
This function will set the USB module address that is obtained from the Host in a setup transaction. The address is obtained from the
SET_ADDRESS command issued by the Host. The primary (first) client of the driver uses this function to set the module's USB address after
decoding the setup transaction from the Host.
Remarks
None.
Preconditions
None.
Example
// This function should be called by the first client of the driver,
// which is typically the Device Layer. The address to set is obtained
// from the Host during enumeration.
DRV_USBFS_DEVICE_AddressSet(deviceLayer, 4);
Parameters
Parameters Description
handle Client's driver handle (returned from DRV_USBFS_Open function).
address The address of this module on the USB bus.
Function
void DRV_USBFS_DEVICE_AddressSet( DRV_HANDLE handle, uint8_t address);
DRV_USBFS_DEVICE_Attach Function
This function will enable the attach signaling resistors on the D+ and D- lines thus letting the USB Host know that a device has been attached on
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1196
the bus.
File
drv_usbfs.h
C
void DRV_USBFS_DEVICE_Attach(DRV_HANDLE handle);
Returns
None.
Description
This function enables the pull-up resistors on the D+ or D- lines thus letting the USB Host know that a device has been attached on the bus . This
function should be called when the driver client is ready to receive communication from the Host (typically after all initialization is complete). The
USB 2.0 specification requires VBUS to be detected before the data line pull-ups are enabled. The application must ensure the same.
Remarks
None.
Preconditions
The Client handle should be valid.
Example
// Open the device driver and attach the device to the USB.
handle = DRV_USBFS_Open(DRV_USBFS_INDEX_0, DRV_IO_INTENT_EXCLUSIVE| DRV_IO_INTENT_READWRITE|
DRV_IO_INTENT_NON_BLOCKING);
// Register a callback
DRV_USBFS_ClientEventCallBackSet(handle, (uintptr_t)&myDeviceLayer, MyDeviceLayerEventCallback);
// The device can be attached when VBUS Session Valid event occurs
void MyDeviceLayerEventCallback(uintptr_t handle, DRV_USBFS_EVENT event, void * hReferenceData)
{
switch(event)
{
case DRV_USBFS_EVENT_DEVICE_SESSION_VALID:
// A valid VBUS was detected.
DRV_USBFS_DEVICE_Attach(handle);
break;
case DRV_USBFS_EVENT_DEVICE_SESSION_INVALID:
// VBUS is not valid anymore. The device can be disconnected.
DRV_USBFS_DEVICE_Detach(handle);
break;
default:
break;
}
}
}
Parameters
Parameters Description
handle Client's driver handle (returned from DRV_USBFS_Open function).
Function
void DRV_USBFS_DEVICE_Attach( DRV_HANDLE handle);
DRV_USBFS_DEVICE_CurrentSpeedGet Function
This function returns the USB speed at which the device is operating.
File
drv_usbfs.h
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1197
C
USB_SPEED DRV_USBFS_DEVICE_CurrentSpeedGet(DRV_HANDLE handle);
Returns
• USB_SPEED_ERROR - The device speed is not valid.
• USB_SPEED_FULL - The device is operating at Full speed.
Description
This function returns the USB speed at which the device is operating.
Remarks
None.
Preconditions
Only valid after the device is attached to the Host and Host has completed reset signaling.
Example
// Get the current speed.
USB_SPEED deviceSpeed;
deviceSpeed = DRV_USBFS_DEVICE_CurrentSpeedGet(deviceLayer);
Parameters
Parameters Description
handle Client's driver handle (returned from DRV_USBFS_Open function).
Function
USB_SPEED DRV_USBFS_DEVICE_CurrentSpeedGet( DRV_HANDLE handle);
DRV_USBFS_DEVICE_Detach Function
This function will disable the attach signaling resistors on the D+ and D- lines thus letting the USB Host know that the device has detached from
the bus.
File
drv_usbfs.h
C
void DRV_USBFS_DEVICE_Detach(DRV_HANDLE handle);
Returns
None.
Description
This function disables the pull-up resistors on the D+ or D- lines. This function should be called when the application wants to disconnect the
device from the bus (typically to implement a soft detach or switch to Host mode operation). A self-powered device should be detached from the
bus when the VBUS is not valid.
Remarks
None.
Preconditions
The Client handle should be valid.
Example
// Open the device driver and attach the device to the USB.
handle = DRV_USBFS_Open(DRV_USBFS_INDEX_0, DRV_IO_INTENT_EXCLUSIVE| DRV_IO_INTENT_READWRITE|
DRV_IO_INTENT_NON_BLOCKING);
// Register a callback
DRV_USBFS_ClientEventCallBackSet(handle, (uintptr_t)&myDeviceLayer, MyDeviceLayerEventCallback);
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1198
// The device can be detached when VBUS Session Invalid event occurs
void MyDeviceLayerEventCallback(uintptr_t handle, DRV_USBFS_EVENT event, void * hReferenceData)
{
switch(event)
{
case DRV_USBFS_EVENT_DEVICE_SESSION_VALID:
// A valid VBUS was detected.
DRV_USBFS_DEVICE_Attach(handle);
break;
case DRV_USBFS_EVENT_DEVICE_SESSION_INVALID:
// VBUS is not valid anymore. The device can be disconnected.
DRV_USBFS_DEVICE_Detach(handle);
break;
default:
break;
}
}
}
Parameters
Parameters Description
handle Client's driver handle (returned from DRV_USBFS_Open function).
Function
void DRV_USBFS_DEVICE_Detach( DRV_HANDLE handle);
DRV_USBFS_DEVICE_EndpointDisable Function
This function disables an endpoint.
File
drv_usbfs.h
C
USB_ERROR DRV_USBFS_DEVICE_EndpointDisable(DRV_HANDLE handle, USB_ENDPOINT endpointAndDirection);
Returns
• USB_ERROR_NONE - The endpoint was successfully enabled.
• USB_ERROR_DEVICE_ENDPOINT_INVALID - The endpoint that is being accessed is not a valid endpoint (endpoint was not provisioned
through the DRV_USBFS_ENDPOINTS_NUMBER configuration constant) defined for this driver instance.
Description
This function disables an endpoint. If the endpoint type is a control endpoint type, both directions are disabled. For non-control endpoints, the
function disables the specified direction only. The direction to be disabled is specified by the Most Significant Bit (MSB) of the
endpointAndDirection parameter.
Remarks
None.
Preconditions
The Client handle should be valid.
Example
// This code shows an example of how to disable
// a control endpoint. Note that the direction parameter is ignored.
// For a control endpoint, both the directions are disabled.
USB_ENDPOINT ep;
ep = USB_ENDPOINT_AND_DIRECTION(USB_DATA_DIRECTION_DEVICE_TO_HOST, 0);
DRV_USBFS_DEVICE_EndpointDisable(handle, ep );
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1199
// This code shows an example of how to disable a BULK IN
// endpoint
USB_ENDPOINT ep;
ep = USB_ENDPOINT_AND_DIRECTION(USB_DATA_DIRECTION_DEVICE_TO_HOST, 1);
DRV_USBFS_DEVICE_EndpointDisable(handle, ep );
Parameters
Parameters Description
handle Client's driver handle (returned from DRV_USBFS_Open function).
endpointAndDirection Specifies the endpoint and direction.
Function
USB_ERROR DRV_USBFS_DEVICE_EndpointDisable
(
DRV_HANDLE handle,
USB_ENDPOINT endpointAndDirection
)
DRV_USBFS_DEVICE_EndpointDisableAll Function
This function disables all provisioned endpoints.
File
drv_usbfs.h
C
USB_ERROR DRV_USBFS_DEVICE_EndpointDisableAll(DRV_HANDLE handle);
Returns
• USB_ERROR_NONE - The function exited successfully.
• USB_ERROR_PARAMETER_INVALID - The driver handle is invalid.
Description
This function disables all provisioned endpoints in both directions.
Remarks
This function is typically called by the USB Device Layer to disable all endpoints upon detecting a bus reset.
Preconditions
The Client handle should be valid.
Example
// This code shows an example of how to disable all endpoints.
DRV_USBFS_DEVICE_EndpointDisableAll(handle);
Parameters
Parameters Description
handle Client's driver handle (returned from DRV_USBFS_Open function).
Function
USB_ERROR DRV_USBFS_DEVICE_EndpointDisableAll( DRV_HANDLE handle)
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1200
DRV_USBFS_DEVICE_EndpointEnable Function
This function enables an endpoint for the specified direction and endpoint size.
File
drv_usbfs.h
C
USB_ERROR DRV_USBFS_DEVICE_EndpointEnable(DRV_HANDLE handle, USB_ENDPOINT endpointAndDirection,
USB_TRANSFER_TYPE transferType, uint16_t endpointSize);
Returns
• USB_ERROR_NONE - The endpoint was successfully enabled.
• USB_ERROR_DEVICE_ENDPOINT_INVALID - If the endpoint that is being accessed is not a valid endpoint defined for this driver instance.
The value of DRV_USBFS_ENDPOINTS_NUMBER configuration constant should be adjusted.
• USB_ERROR_PARAMETER_INVALID - The driver handle is invalid.
Description
This function enables an endpoint for the specified direction and endpoint size. The function will enable the endpoint for communication in one
direction at a time. It must be called twice if the endpoint is required to communicate in both the directions, with the exception of control endpoints.
If the endpoint type is a control endpoint, the endpoint is always bidirectional and the function needs to be called only once.
The size of the endpoint must match the wMaxPacketSize reported in the endpoint descriptor for this endpoint. A transfer that is scheduled over
this endpoint will be scheduled in wMaxPacketSize transactions. The function does not check if the endpoint is already in use. It is the client's
responsibility to make sure that a endpoint is not accidentally reused.
Remarks
None.
Preconditions
The Client handle should be valid.
Example
// This code shows an example of how to enable Endpoint
// 0 for control transfers. Note that for a control endpoint, the
// direction parameter is ignored. A control endpoint is always
// bidirectional. Endpoint size is 64 bytes.
uint8_t ep;
ep = USB_ENDPOINT_AND_DIRECTION(USB_DATA_DIRECTION_DEVICE_TO_HOST, 0);
DRV_USBFS_DEVICE_EndpointEnable(handle, ep, USB_TRANSFER_TYPE_CONTROL, 64);
// This code shows an example of how to set up a endpoint
// for BULK IN transfer. For an IN transfer, data moves from device
// to Host. In this example, Endpoint 1 is enabled. The maximum
// packet size is 64.
uint8_t ep;
ep = USB_ENDPOINT_AND_DIRECTION(USB_DATA_DIRECTION_DEVICE_TO_HOST, 1);
DRV_USBFS_DEVICE_EndpointEnable(handle, ep, USB_TRANSFER_TYPE_BULK, 64);
// If Endpoint 1 must also be set up for BULK OUT, the
// DRV_USBFS_DEVICE_EndpointEnable function must be called again, as shown
// here.
ep = USB_ENDPOINT_AND_DIRECTION(USB_DATA_DIRECTION_HOST_TO_DEVICE, 1);
DRV_USBFS_DEVICE_EndpointEnable(handle, ep, USB_TRANSFER_TYPE_BULK, 64);
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1201
Parameters
Parameters Description
handle Client's driver handle (returned from DRV_USBFS_Open function).
endpointAndDirection Specifies the endpoint and direction.
transferType Should be USB_TRANSFER_TYPE_CONTROL for control endpoint,
USB_TRANSFER_TYPE_BULK for bulk endpoint, USB_TRANSFER_TYPE_INTERRUPT for
interrupt endpoint and USB_TRANSFER_TYPE_ISOCHRONOUS for isochronous endpoint.
endpointSize Maximum size (in bytes) of the endpoint as reported in the endpoint descriptor.
Function
USB_ERROR DRV_USBFS_DEVICE_EndpointEnable
(
DRV_HANDLE handle,
USB_ENDPOINT endpointAndDirection,
USB_TRANSFER_TYPE transferType,
uint16_t endpointSize
);
DRV_USBFS_DEVICE_EndpointIsEnabled Function
This function returns the enable/disable status of the specified endpoint and direction.
File
drv_usbfs.h
C
bool DRV_USBFS_DEVICE_EndpointIsEnabled(DRV_HANDLE client, USB_ENDPOINT endpointAndDirection);
Returns
• true - The endpoint is enabled.
• false - The endpoint is disabled.
Description
This function returns the enable/disable status of the specified endpoint and direction.
Remarks
None.
Preconditions
The Client handle should be valid.
Example
// This code shows an example of how the
// DRV_USBFS_DEVICE_EndpointIsEnabled function can be used to obtain the
// status of Endpoint 1 and IN direction.
USB_ENDPOINT ep;
ep = USB_ENDPOINT_AND_DIRECTION(USB_DATA_DIRECTION_DEVICE_TO_HOST, 1);
if(DRV_USBFS_ENDPOINT_STATE_DISABLED ==
DRV_USBFS_DEVICE_EndpointIsEnabled(handle, ep))
{
// Endpoint is disabled. Enable endpoint.
DRV_USBFS_DEVICE_EndpointEnable(handle, ep, USB_ENDPOINT_TYPE_BULK, 64);
}
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1202
Parameters
Parameters Description
handle Client's driver handle (returned from DRV_USBFS_Open function).
endpointAndDirection Specifies the endpoint and direction.
Function
bool DRV_USBFS_DEVICE_EndpointIsEnabled
(
DRV_HANDLE handle,
USB_ENDPOINT endpointAndDirection
)
DRV_USBFS_DEVICE_EndpointIsStalled Function
This function returns the stall status of the specified endpoint and direction.
File
drv_usbfs.h
C
bool DRV_USBFS_DEVICE_EndpointIsStalled(DRV_HANDLE client, USB_ENDPOINT endpoint);
Returns
• true - The endpoint is stalled.
• false - The endpoint is not stalled.
Description
This function returns the stall status of the specified endpoint and direction.
Remarks
None.
Preconditions
The Client handle should be valid.
Example
// This code shows an example of how the
// DRV_USBFS_DEVICE_EndpointIsStalled function can be used to obtain the
// stall status of Endpoint 1 and IN direction.
USB_ENDPOINT ep;
ep = USB_ENDPOINT_AND_DIRECTION(USB_DATA_DIRECTION_DEVICE_TO_HOST, 1);
if(true == DRV_USBFS_DEVICE_EndpointIsStalled (handle, ep))
{
// Endpoint stall is enabled. Clear the stall.
DRV_USBFS_DEVICE_EndpointStallClear(handle, ep);
}
Parameters
Parameters Description
handle Client's driver handle (returned from DRV_USBFS_Open function).
endpointAndDirection Specifies the endpoint and direction.
Function
bool DRV_USBFS_DEVICE_EndpointIsStalled
(
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1203
DRV_HANDLE handle,
USB_ENDPOINT endpointAndDirection
)
DRV_USBFS_DEVICE_EndpointStall Function
This function stalls an endpoint in the specified direction.
File
drv_usbfs.h
C
USB_ERROR DRV_USBFS_DEVICE_EndpointStall(DRV_HANDLE handle, USB_ENDPOINT endpointAndDirection);
Returns
• USB_ERROR_NONE - The endpoint was successfully enabled.
• USB_ERROR_PARAMETER_INVALID - The driver handle is not valid.
• USB_ERROR_DEVICE_ENDPOINT_INVALID - If the endpoint that is being accessed is out of the valid endpoint defined for this driver
instance.
• USB_ERROR_OSAL_FUNCTION - An error with an OSAL function called in this function.
Description
This function stalls an endpoint in the specified direction.
Remarks
None.
Preconditions
The Client handle should be valid.
Example
// This code shows an example of how to stall an endpoint. In
// this example, Endpoint 1 IN direction is stalled.
USB_ENDPOINT ep;
ep = USB_ENDPOINT_AND_DIRECTION(USB_DATA_DIRECTION_DEVICE_TO_HOST, 1);
DRV_USBFS_DEVICE_EndpointStall(handle, ep);
Parameters
Parameters Description
handle Client's driver handle (returned from DRV_USBFS_Open function).
endpointAndDirection Specifies the endpoint and direction.
Function
USB_ERROR DRV_USBFS_DEVICE_EndpointStall
(
DRV_HANDLE handle,
USB_ENDPOINT endpointAndDirection
)
DRV_USBFS_DEVICE_EndpointStallClear Function
This function clears the stall on an endpoint in the specified direction.
File
drv_usbfs.h
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1204
C
USB_ERROR DRV_USBFS_DEVICE_EndpointStallClear(DRV_HANDLE handle, USB_ENDPOINT endpointAndDirection);
Returns
• USB_ERROR_NONE - The endpoint was successfully enabled.
• USB_ERROR_PARAMETER_INVALID - The driver handle is not valid.
• USB_ERROR_DEVICE_ENDPOINT_INVALID - If the endpoint that is being accessed is out of the valid endpoint defined for this driver
instance.
Description
This function clears the stall on an endpoint in the specified direction.
Remarks
None.
Preconditions
The Client handle should be valid.
Example
// This code shows an example of how to clear a stall. In this
// example, the stall condition on Endpoint 1 IN direction is cleared.
USB_ENDPOINT ep;
ep = USB_ENDPOINT_AND_DIRECTION(USB_DATA_DIRECTION_DEVICE_TO_HOST, 1);
DRV_USBFS_DEVICE_EndpointStallClear(handle, ep);
Parameters
Parameters Description
handle Client's driver handle (returned from DRV_USBFS_Open function).
endpointAndDirection Specifies the endpoint and direction.
Function
USB_ERROR DRV_USBFS_DEVICE_EndpointStallClear
(
DRV_HANDLE handle,
USB_ENDPOINT endpointAndDirection
)
DRV_USBFS_DEVICE_IRPCancel Function
This function cancels the specific IRP that are queued and in progress at the specified endpoint.
File
drv_usbfs.h
C
USB_ERROR DRV_USBFS_DEVICE_IRPCancel(DRV_HANDLE client, USB_DEVICE_IRP * irp);
Returns
• USB_ERROR_NONE - The IRP have been canceled successfully.
• USB_ERROR_PARAMETER_INVALID - Invalid parameter or the IRP already has been aborted or completed
• USB_ERROR_OSAL_FUNCTION - An OSAL function called in this function did not execute successfully.
Description
This function attempts to cancel the processing of a queued IRP. An IRP that was in the queue but yet to be processed will be cancelled
successfully and the IRP callback function will be called from this function with the USB_DEVICE_IRP_STATUS_ABORTED status. The
application can release the data buffer memory used by the IRP when this callback occurs. If the IRP was in progress (a transaction in on the bus)
when the cancel function was called, the IRP will be canceled only when an ongoing or the next transaction has completed. The IRP callback
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1205
function will then be called in an interrupt context. The application should not release the related data buffer unless the IRP callback has occurred.
Remarks
The size returned after the ABORT callback will be always 0 regardless of the amount of data that has been sent or received. The client should not
assume any data transaction has happened for an canceled IRP. If the last transaction of the IRP was in progress, the IRP cancel does not have
any effect. The first transaction of any ongoing IRP cannot be canceled.
Preconditions
The Client handle should be valid.
Example
// This code shows an example of how to cancel IRP. In this example the IRP
// has been scheduled from a device to the Host.
USB_ENDPOINT ep;
USB_DEVICE_IRP irp;
ep.direction = USB_ENDPOINT_AND_DIRECTION(USB_DATA_DIRECTION_DEVICE_TO_HOST, 1);
irp.data = myDataBufferToSend;
irp.size = 130;
irp.flags = USB_DEVICE_IRP_FLAG_DATA_COMPLETE;
irp.callback = MyIRPCompletionCallback;
irp.referenceData = (uintptr_t)&myDeviceLayerObj;
if (DRV_USBFS_DEVICE_IRPSubmit(handle, ep, &irp) != USB_ERROR_NONE)
{
// This means there was an error.
}
else
{
// Check the status of the IRP.
if(irp.status != USB_DEVICE_IRP_STATUS_COMPLETED)
{
// Cancel the submitted IRP.
if (DRV_USBFS_DEVICE_IRPCancel(handle, &irp) != USB_ERROR_NONE)
{
// The IRP Cancel request submission was successful.
// IRP cancel status will be notified through the callback
// function.
}
else
{
// The IRP may have been completed before IRP cancel operation.
// could start. No callback notification will be generated.
}
}
else
{
// The IRP processing must have been completed before IRP cancel was
// submitted.
}
}
void MyIRPCallback(USB_DEVICE_IRP * irp)
{
// Check if the IRP callback is for a Cancel request
if(irp->status == USB_DEVICE_IRP_STATUS_ABORTED)
{
// IRP cancel completed
}
}
Parameters
Parameters Description
handle Client's driver handle (returned from DRV_USBFS_Open function).
irp Pointer to the IRP to cancel.
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1206
Function
USB_ERROR DRV_USBFS_DEVICE_IRPCancel
(
DRV_HANDLE client,
USB_DEVICE_IRP * irp
)
DRV_USBFS_DEVICE_IRPCancelAll Function
This function cancels all IRPs that are queued and in progress at the specified endpoint.
File
drv_usbfs.h
C
USB_ERROR DRV_USBFS_DEVICE_IRPCancelAll(DRV_HANDLE client, USB_ENDPOINT endpointAndDirection);
Returns
• USB_ERROR_NONE - The endpoint was successfully enabled.
• USB_ERROR_DEVICE_ENDPOINT_INVALID - If the endpoint that is being accessed is out of the valid endpoint defined for this driver
instance.
• USB_ERROR_PARAMETER_INVALID - The driver handle is not valid.
• USB_ERROR_OSAL_FUNCTION - An OSAL function called in this function did not execute successfully.
Description
This function cancels all IRPs that are queued and in progress at the specified endpoint.
Remarks
None.
Preconditions
The Client handle should be valid.
Example
// This code shows an example of how to cancel all IRPs.
void MyIRPCallback(USB_DEVICE_IRP * irp)
{
// Check if this is setup command
if(irp->status == USB_DEVICE_IRP_STATUS_SETUP)
{
if(IsSetupCommandSupported(irp->data) == false)
{
// This means that this setup command is not
// supported. Stall the some related endpoint and cancel all
// queue IRPs.
DRV_USBFS_DEVICE_EndpointStall(handle, ep);
DRV_USBFS_DEVICE_IRPCancelAll(handle, ep);
}
}
}
Parameters
Parameters Description
handle Client's driver handle (returned from DRV_USBFS_Open function).
endpointAndDirection Specifies the endpoint and direction.
Function
USB_ERROR DRV_USBFS_DEVICE_IRPCancelAll
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1207
(
DRV_HANDLE client,
USB_ENDPOINT endpointAndDirection
);
DRV_USBFS_DEVICE_IRPSubmit Function
This function submits an I/O Request Packet (IRP) for processing to the Hi-Speed USB Driver.
File
drv_usbfs.h
C
USB_ERROR DRV_USBFS_DEVICE_IRPSubmit(DRV_HANDLE client, USB_ENDPOINT endpointAndDirection, USB_DEVICE_IRP *
irp);
Returns
• USB_ERROR_NONE - if the IRP was submitted successful.
• USB_ERROR_IRP_SIZE_INVALID - if the size parameter of the IRP is not correct.
• USB_ERROR_PARAMETER_INVALID - If the client handle is not valid.
• USB_ERROR_ENDPOINT_NOT_CONFIGURED - If the endpoint is not enabled.
• USB_ERROR_DEVICE_ENDPOINT_INVALID - The specified endpoint is not valid.
• USB_ERROR_OSAL_FUNCTION - An OSAL call in the function did not complete successfully.
Description
This function submits an I/O Request Packet (IRP) for processing to the USB Driver. The IRP allows a client to send and receive data from the
USB Host. The data will be sent or received through the specified endpoint. The direction of the data transfer is indicated by the direction flag in
the endpointAndDirection parameter. Submitting an IRP arms the endpoint to either send data to or receive data from the Host. If an IRP is already
being processed on the endpoint, the subsequent IRP submit operation will be queued. The contents of the IRP (including the application buffers)
should not be changed until the IRP has been processed.
Particular attention should be paid to the size parameter of IRP. The following should be noted:
• The size parameter while sending data to the Host can be less than, greater than, equal to, or be an exact multiple of the maximum packet size
for the endpoint. The maximum packet size for the endpoint determines the number of transactions required to process the IRP.
• If the size parameter, while sending data to the Host is less than the maximum packet size, the transfer will complete in one transaction.
• If the size parameter, while sending data to the Host is greater than the maximum packet size, the IRP will be processed in multiple
transactions.
• If the size parameter, while sending data to the Host is equal to or an exact multiple of the maximum packet size, the client can optionally ask
the driver to send a Zero Length Packet(ZLP) by specifying the USB_DEVICE_IRP_FLAG_DATA_COMPLETE flag as the flag parameter.
• The size parameter, while receiving data from the Host must be an exact multiple of the maximum packet size of the endpoint. If this is not the
case, the driver will return a USB_ERROR_IRP_SIZE_INVALID result. If while processing the IRP, the driver receives less than maximum
packet size or a ZLP from the Host, the driver considers the IRP as processed. The size parameter at this point contains the actual amount of
data received from the Host. The IRP status is returned as USB_DEVICE_IRP_STATUS_COMPLETED_SHORT.
• If a ZLP needs to be sent to Host, the IRP size should be specified as 0 and the flag parameter should be set as
USB_DEVICE_IRP_FLAG_DATA_COMPLETE.
• If the IRP size is an exact multiple of the endpoint size, the client can request the driver to not send a ZLP by setting the flag parameter to
USB_DEVICE_IRP_FLAG_DATA_PENDING. This flag indicates that there is more data pending in this transfer.
• Specifying a size less than the endpoint size along with the USB_DEVICE_IRP_FLAG_DATA_PENDING flag will cause the driver to return a
USB_ERROR_IRP_SIZE_INVALID.
• If the size is greater than but not a multiple of the endpoint size, and the flag is specified as USB_DEVICE_IRP_FLAG_DATA_PENDING, the
driver will send multiple of endpoint size number of bytes. For example, if the IRP size is 130 and the endpoint size if 64, the number of bytes
sent will 128.
Remarks
This function can be called from the ISR of the USB module to associated with the client.
Preconditions
The Client handle should be valid.
Example
// The following code shows an example of how to schedule a IRP to send data
// from a device to the Host. Assume that the max packet size is 64 and
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1208
// and this data needs to sent over Endpoint 1. In this example, the
// transfer is processed as three transactions of 64, 64 and 2 bytes.
USB_ENDPOINT ep;
USB_DEVICE_IRP irp;
ep.direction = USB_ENDPOINT_AND_DIRECTION(USB_DATA_DIRECTION_DEVICE_TO_HOST, 1);
irp.data = myDataBufferToSend;
irp.size = 130;
irp.flags = USB_DEVICE_IRP_FLAG_DATA_COMPLETE;
irp.callback = MyIRPCompletionCallback;
irp.referenceData = (uintptr_t)&myDeviceLayerObj;
if (DRV_USBFS_DEVICE_IRPSubmit(handle, ep, &irp) != USB_ERROR_NONE)
{
// This means there was an error.
}
else
{
// The status of the IRP can be checked.
while(irp.status != USB_DEVICE_IRP_STATUS_COMPLETED)
{
// Wait or run a task function.
}
}
// The following code shows how the client can request
// the driver to send a ZLP when the size is an exact multiple of
// endpoint size.
irp.data = myDataBufferToSend;
irp.size = 128;
irp.flags = USB_DEVICE_IRP_FLAG_DATA_COMPLETE;
irp.callback = MyIRPCompletionCallback;
irp.referenceData = (uintptr_t)&myDeviceLayerObj;
// Note that while receiving data from the Host, the size should be an
// exact multiple of the maximum packet size of the endpoint. In the
// following example, the DRV_USBFS_DEVICE_IRPSubmit function will return a
// USB_DEVICE_IRP_SIZE_INVALID value.
ep = USB_ENDPOINT_AND_DIRECTION(USB_DATA_DIRECTION_HOST_TO_DEVICE, 1);
irp.data = myDataBufferToSend;
irp.size = 60; // THIS SIZE IS NOT CORRECT
irp.flags = USB_DEVICE_IRP_FLAG_DATA_COMPLETE;
irp.callback = MyIRPCompletionCallback;
irp.referenceData = (uintptr_t)&myDeviceLayerObj;
Parameters
Parameters Description
handle Client's driver handle (returned from DRV_USBFS_Open function).
endpointAndDirection Specifies the endpoint and direction.
irp Pointer to the IRP to be added to the queue for processing.
Function
USB_ERROR DRV_USBFS_DEVICE_IRPSubmit
(
DRV_HANDLE client,
USB_ENDPOINT endpointAndDirection,
USB_DEVICE_IRP * irp
);
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1209
DRV_USBFS_DEVICE_RemoteWakeupStart Function
This function causes the device to start Remote Wakeup Signalling on the bus.
File
drv_usbfs.h
C
void DRV_USBFS_DEVICE_RemoteWakeupStart(DRV_HANDLE handle);
Returns
None.
Description
This function causes the device to start Remote Wakeup Signalling on the bus. This function should be called when the device, presently placed in
suspend mode by the Host, wants to be wakeup. Note that the device can do this only when the Host has enabled the device's Remote Wakeup
capability.
Remarks
None.
Preconditions
The handle should be valid.
Example
DRV_HANDLE handle;
// If the Host has enabled the Remote Wakeup capability, and if the device
// is in suspend mode, then start Remote Wakeup signaling.
if(deviceIsSuspended && deviceRemoteWakeupEnabled)
{
DRV_USBFS_DEVICE_RemoteWakeupStart(handle);
}
Parameters
Parameters Description
handle Handle to the driver (returned from DRV_USBFS_Open function).
Function
void DRV_USBFS_DEVICE_RemoteWakeupStart( DRV_HANDLE handle);
DRV_USBFS_DEVICE_RemoteWakeupStop Function
This function causes the device to stop the Remote Wakeup Signalling on the bus.
File
drv_usbfs.h
C
void DRV_USBFS_DEVICE_RemoteWakeupStop(DRV_HANDLE handle);
Returns
None.
Description
This function causes the device to stop Remote Wakeup Signalling on the bus. This function should be called after the
DRV_USBFS_DEVICE_RemoteWakeupStart function was called to start the Remote Wakeup signaling on the bus.
Remarks
This function should be 1 to 15 milliseconds after the DRV_USBFS_DEVICE_RemoteWakeupStart function was called.
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1210
Preconditions
The handle should be valid. The DRV_USBFS_DEVICE_RemoteWakeupStart function was called to start the Remote Wakeup signaling on the
bus.
Example
DRV_HANDLE handle;
// If the Host has enabled the Remote Wakeup capability, and if the device
// is in suspend mode, then start Remote Wakeup signaling. Wait for 10
// milliseconds and then stop the Remote Wakeup signaling
if(deviceIsSuspended && deviceRemoteWakeupEnabled)
{
DRV_USBFS_DEVICE_RemoteWakeupStart(handle);
DelayMilliSeconds(10);
DRV_USBFS_DEVICE_RemoteWakeupStop(handle);
}
Parameters
Parameters Description
handle Handle to the driver (returned from DRV_USBFS_Open function).
Function
void DRV_USBFS_DEVICE_RemoteWakeupStop( DRV_HANDLE handle);
DRV_USBFS_DEVICE_SOFNumberGet Function
This function will return the USB SOF packet number.
File
drv_usbfs.h
C
uint16_t DRV_USBFS_DEVICE_SOFNumberGet(DRV_HANDLE handle);
Returns
The SOF packet number.
Description
This function will return the USB SOF packet number..
Remarks
None.
Preconditions
This function will return a valid value only when the device is attached to the bus. The SOF packet count will not increment if the bus is suspended.
Example
// This code shows how the DRV_USBFS_DEVICE_SOFNumberGet function is called
// to read the current SOF number.
DRV_HANDLE handle;
uint16_t sofNumber;
sofNumber = DRV_USBFS_DEVICE_SOFNumberGet(handle);
Parameters
Parameters Description
handle Client's driver handle (returned from DRV_USBFS_Open function).
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1211
Function
uint16_t DRV_USBFS_DEVICE_SOFNumberGet( DRV_HANDLE handle);
d) Host Mode Operation Functions
DRV_USBFS_HOST_EventsDisable Function
Disables Host mode events.
File
drv_usbfs.h
C
bool DRV_USBFS_HOST_EventsDisable(DRV_HANDLE handle);
Returns
• true - Driver event generation was enabled when this function was called.
• false - Driver event generation was not enabled when this function was called.
Description
This function disables the Host mode events. This function is called by the Host Layer when it wants to execute code atomically.
Remarks
None.
Preconditions
The handle should be valid.
Example
// This code shows how the DRV_USBFS_HOST_EventsDisable and
// DRV_USBFS_HOST_EventsEnable function can be called to disable and enable
// events.
DRV_HANDLE driverHandle;
bool eventsWereEnabled;
// Disable the driver events.
eventsWereEnabled = DRV_USBFS_HOST_EventsDisable(driverHandle);
// Code in this region will not be interrupted by driver events.
// Enable the driver events.
DRV_USBFS_HOST_EventsEnable(driverHandle, eventsWereEnabled);
Parameters
Parameters Description
handle Client's driver handle (returned from DRV_USBFS_Open function).
Function
bool DRV_USBFS_HOST_EventsDisable
(
DRV_HANDLE handle
);
DRV_USBFS_HOST_EventsEnable Function
Restores the events to the specified the original value.
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1212
File
drv_usbfs.h
C
void DRV_USBFS_HOST_EventsEnable(DRV_HANDLE handle, bool eventContext);
Returns
None.
Description
This function will restore the enable disable state of the events. The eventRestoreContext parameter should be equal to the value returned by the
DRV_USBFS_HOST_EventsDisable function.
Remarks
None.
Preconditions
The handle should be valid.
Example
// This code shows how the DRV_USBFS_HOST_EventsDisable and
// DRV_USBFS_HOST_EventsEnable function can be called to disable and enable
// events.
DRV_HANDLE driverHandle;
bool eventsWereEnabled;
// Disable the driver events.
eventsWereEnabled = DRV_USBFS_HOST_EventsDisable(driverHandle);
// Code in this region will not be interrupted by driver events.
// Enable the driver events.
DRV_USBFS_HOST_EventsEnable(driverHandle, eventsWereEnabled);
Parameters
Parameters Description
handle Handle to the driver (returned from DRV_USBFS_Open function).
eventRestoreContext Value returned by the DRV_USBFS_HOST_EventsDisable function.
Function
void DRV_USBFS_HOST_EventsEnable
(
DRV_HANDLE handle
bool eventRestoreContext
);
DRV_USBFS_HOST_IRPCancel Function
Cancels the specified IRP.
File
drv_usbfs.h
C
void DRV_USBFS_HOST_IRPCancel(USB_HOST_IRP * inputIRP);
Returns
None.
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1213
Description
This function attempts to cancel the specified IRP. If the IRP is queued and its processing has not started, it will be cancelled successfully. If the
IRP in progress, the ongoing transaction will be allowed to complete.
Remarks
None.
Preconditions
None.
Example
// This code shows how a submitted IRP can be cancelled.
USB_HOST_IRP irp;
USB_ERROR result;
USB_HOST_PIPE_HANDLE controlPipe;
USB_SETUP_PACKET setup;
uint8_t controlTransferData[32];
irp.setup = setup;
irp.data = controlTransferData;
irp.size = 32;
irp.flags = USB_HOST_IRP_FLAG_NONE ;
irp.userData = &someApplicationObject;
irp.callback = IRP_Callback;
DRV_USBFS_HOST_IRPSubmit(controlPipeHandle, &irp);
// Additional application logic may come here. This logic may decide to
// cancel the submitted IRP.
DRV_USBFS_HOST_IRPCancel(&irp);
Parameters
Parameters Description
inputIRP Pointer to the IRP to cancel.
Function
void DRV_USBFS_HOST_IRPCancel(USB_HOST_IRP * inputIRP);
DRV_USBFS_HOST_IRPSubmit Function
Submits an IRP on a pipe.
File
drv_usbfs.h
C
USB_ERROR DRV_USBFS_HOST_IRPSubmit(DRV_USBFS_HOST_PIPE_HANDLE hPipe, USB_HOST_IRP * pinputIRP);
Returns
• USB_ERROR_NONE - The IRP was submitted successfully.
• USB_ERROR_PARAMETER_INVALID - The pipe handle is not valid.
• USB_ERROR_OSAL_FUNCTION - An error occurred in an OSAL function called in this function.
Description
This function submits an IRP on the specified pipe. The IRP will be added to the queue and will be processed in turn. The data will be transferred
on the bus based on the USB bus scheduling rules. When the IRP has been processed, the callback function specified in the IRP will be called.
The IRP status will be updated to reflect the completion status of the IRP.
Remarks
An IRP can also be submitted in an IRP callback function.
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1214
Preconditions
The pipe handle should be valid.
Example
// The following code shows an example of how the host layer populates
// the IRP object and then submits it. IRP_Callback function is called when an
// IRP has completed processing. The status of the IRP at completion can be
// checked in the status flag. The size field of the irp will contain the amount
// of data transferred.
void IRP_Callback(USB_HOST_IRP * irp)
{
// irp is pointing to the IRP for which the callback has occurred. In most
// cases this function will execute in an interrupt context. The application
// should not perform any hardware access or interrupt un-safe operations in
// this function.
switch(irp->status)
{
case USB_HOST_IRP_STATUS_ERROR_UNKNOWN:
// IRP was terminated due to an unknown error
break;
case USB_HOST_IRP_STATUS_ABORTED:
// IRP was terminated by the application
break;
case USB_HOST_IRP_STATUS_ERROR_BUS:
// IRP was terminated due to a bus error
break;
case USB_HOST_IRP_STATUS_ERROR_DATA:
// IRP was terminated due to data error
break;
case USB_HOST_IRP_STATUS_ERROR_NAK_TIMEOUT:
// IRP was terminated because of a NAK timeout
break;
case USB_HOST_IRP_STATUS_ERROR_STALL:
// IRP was terminated because of a device sent a STALL
break;
case USB_HOST_IRP_STATUS_COMPLETED:
// IRP has been completed
break;
case USB_HOST_IRP_STATUS_COMPLETED_SHORT:
// IRP has been completed but the amount of data processed was less
// than requested.
break;
default:
break;
}
}
// In the following code snippet the a control transfer IRP is submitted to a
// control pipe. The setup parameter of the IRP points to the Setup command of
// the control transfer. The direction of the data stage is specified by the
// Setup packet.
USB_HOST_IRP irp;
USB_ERROR result;
USB_HOST_PIPE_HANDLE controlPipe;
USB_SETUP_PACKET setup;
uint8_t controlTransferData[32];
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1215
irp.setup = setup;
irp.data = controlTransferData;
irp.size = 32;
irp.flags = USB_HOST_IRP_FLAG_NONE ;
irp.userData = &someApplicationObject;
irp.callback = IRP_Callback;
result = DRV_USBFS_HOST_IRPSubmit(controlPipeHandle, &irp);
Parameters
Parameters Description
hPipe Handle to the pipe to which the IRP has to be submitted.
pInputIRP Pointer to the IRP.
Function
USB_ERROR DRV_USBFS_HOST_IRPSubmit
(
DRV_USBFS_HOST_PIPE_HANDLE hPipe,
USB_HOST_IRP * pInputIRP
);
DRV_USBFS_HOST_PipeClose Function
Closes an open pipe.
File
drv_usbfs.h
C
void DRV_USBFS_HOST_PipeClose(DRV_USBFS_HOST_PIPE_HANDLE pipeHandle);
Returns
None.
Description
This function closes an open pipe. Any IRPs scheduled on the pipe will be aborted and IRP callback functions will be called with the status as
DRV_USB_HOST_IRP_STATE_ABORTED. The pipe handle will become invalid and the pipe will not accept IRPs.
Remarks
None.
Preconditions
The pipe handle should be valid.
Example
// This code shows how an open Host pipe can be closed.
DRV_HANDLE driverHandle;
DRV_USBFS_HOST_PIPE_HANDLE pipeHandle;
// Close the pipe.
DRV_USBFS_HOST_PipeClose(pipeHandle);
Parameters
Parameters Description
pipeHandle Handle to the pipe to close.
Function
void DRV_USBFS_HOST_PipeClose
(
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1216
DRV_USBFS_HOST_PIPE_HANDLE pipeHandle
);
DRV_USBFS_HOST_PipeSetup Function
Open a pipe with the specified attributes.
File
drv_usbfs.h
C
DRV_USBFS_HOST_PIPE_HANDLE DRV_USBFS_HOST_PipeSetup(DRV_HANDLE client, uint8_t deviceAddress, USB_ENDPOINT
endpointAndDirection, uint8_t hubAddress, uint8_t hubPort, USB_TRANSFER_TYPE pipeType, uint8_t bInterval,
uint16_t wMaxPacketSize, USB_SPEED speed);
Returns
• DRV_USB_HOST_PIPE_HANDLE_INVALID - The pipe could not be created.
• A valid Pipe Handle - The pipe was created successfully. This is an arbitrary value and will never be the same as
DRV_USB_HOST_PIPE_HANDLE_INVALID.
Description
This function opens a communication pipe between the Host and the device endpoint. The transfer type and other attributes are specified through
the function parameters. The driver does not check for available bus bandwidth, which should be done by the application (the USB Host Layer in
this case)
Remarks
None.
Preconditions
The driver handle should be valid.
Example
// This code shows how the DRV_USBFS_HOST_PipeSetup function is called for
// create a communication pipe. In this example, Bulk pipe is created
// between the Host and a device. The Device address is 2 and the target
// endpoint on this device is 4 . The direction of the data transfer over
// this pipe is from the Host to the device. The device is connected to Port
// 1 of a Hub, whose USB address is 3. The maximum size of a transaction
// on this pipe is 64 bytes. This is a Bulk Pipe and hence the bInterval
// field is set to 0. The target device is operating at Full Speed.
DRV_HANDLE driverHandle;
DRV_USBFS_HOST_PIPE_HANDLE pipeHandle;
pipeHandle = DRV_USBFS_HOST_PipeSetup(driverHandle, 0x02, 0x14, 0x03, 0x01, USB_TRANSFER_TYPE_BULK, 0, 64,
USB_SPEED_FULL);
if(pipeHandle != DRV_USBFS_HOST_PIPE_HANDLE_INVALID)
{
// The pipe was created successfully.
}
Parameters
Parameters Description
client Handle to the driver (returned from DRV_USBFS_Open function).
deviceAddress USB Address of the device to connect to.
endpoint Endpoint on the device to connect to.
hubAddress Address of the hub to which this device is connected. If not connected to a hub, this value
should be set to 0.
hubPort Port number of the hub to which this device is connected.
pipeType Transfer type of the pipe to open.
bInterval Polling interval for periodic transfers. This should be specified as defined by the USB 2.0
Specification.
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1217
wMaxPacketSize This should be set to the endpoint size reported by the device in its configuration descriptors.
This defines the maximum size of the transaction in a transfer on this pipe.
speed The speed of the pipe. This should match the speed at which the device connected to the
Host.
Function
DRV_USBFS_HOST_PIPE_HANDLE DRV_USBFS_HOST_PipeSetup
(
DRV_HANDLE client,
uint8_t deviceAddress,
USB_ENDPOINT endpointAndDirection,
uint8_t hubAddress,
uint8_t hubPort,
USB_TRANSFER_TYPE pipeType,
uint8_t bInterval,
uint16_t wMaxPacketSize,
USB_SPEED speed
);
e) Root Hub Functions
DRV_USBFS_HOST_ROOT_HUB_BusSpeedGet Function
This function returns the operating speed of the bus to which this root hub is connected.
File
drv_usbfs.h
C
USB_SPEED DRV_USBFS_HOST_ROOT_HUB_BusSpeedGet(DRV_HANDLE handle);
Returns
• USB_SPEED_FULL - The Root hub is connected to a bus that is operating at Full Speed.
Description
This function returns the operating speed of the bus to which this root hub is connected.
Remarks
None.
Preconditions
None.
Example
// This code shows how the DRV_USBFS_HOST_ROOT_HUB_BusSpeedGet function is
// called to know the operating speed of the bus to which this Root hub is
// connected.
DRV_HANDLE driverHandle;
USB_SPEED speed;
speed = DRV_USBFS_HOST_ROOT_HUB_BusSpeedGet(driverHandle);
Parameters
Parameters Description
handle Handle to the driver (returned from DRV_USBFS_Open function).
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1218
Function
USB_SPEED DRV_USBFS_HOST_ROOT_HUB_BusSpeedGet( DRV_HANDLE handle);
DRV_USBFS_HOST_ROOT_HUB_Initialize Function
This function initializes the root hub driver.
File
drv_usbfs.h
C
void DRV_USBFS_HOST_ROOT_HUB_Initialize(DRV_HANDLE handle, USB_HOST_DEVICE_OBJ_HANDLE usbHostDeviceInfo);
Returns
None.
Description
This function initializes the root hub driver. It is called by the Host Layer at the time of processing the root hub devices. The Host Layer assigns a
USB_HOST_DEVICE_INFO reference to this root hub driver. This identifies the relationship between the root hub and the Host Layer.
Remarks
None.
Preconditions
None.
Example
// This code shows how the USB Host Layer calls the
// DRV_USBFS_HOST_ROOT_HUB_Initialize function. The usbHostDeviceInfo
// parameter is an arbitrary identifier assigned by the USB Host Layer. Its
// interpretation is opaque to the Root hub Driver.
DRV_HANDLE drvHandle;
USB_HOST_DEVICE_OBJ_HANDLE usbHostDeviceInfo = 0x10003000;
DRV_USBFS_HOST_ROOT_HUB_Initialize(drvHandle, usbHostDeviceInfo);
Parameters
Parameters Description
handle Handle to the driver.
usbHostDeviceInfo Reference provided by the Host.
Function
void DRV_USBFS_HOST_ROOT_HUB_Initialize
(
DRV_HANDLE handle,
USB_HOST_DEVICE_OBJ_HANDLE usbHostDeviceInfo,
)
DRV_USBFS_HOST_ROOT_HUB_MaximumCurrentGet Function
Returns the maximum amount of current that this root hub can provide on the bus.
File
drv_usbfs.h
C
uint32_t DRV_USBFS_HOST_ROOT_HUB_MaximumCurrentGet(DRV_HANDLE handle);
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1219
Returns
Returns the maximum current (in milliamperes) that the root hub can supply.
Description
This function returns the maximum amount of current that this root hub can provide on the bus.
Remarks
None.
Preconditions
None.
Example
// This code shows how the DRV_USBFS_HOST_ROOT_HUB_MaximumCurrentGet
// function is called to obtain the maximum VBUS current that the Root hub
// can supply.
DRV_HANDLE driverHandle;
uint32_t currentMilliAmperes;
currentMilliAmperes = DRV_USBFS_HOST_ROOT_HUB_MaximumCurrentGet(driverHandle);
Parameters
Parameters Description
handle Handle to the driver (returned from DRV_USBFS_Open function).
Function
uint32_t DRV_USBFS_HOST_ROOT_HUB_MaximumCurrentGet( DRV_HANDLE);
DRV_USBFS_HOST_ROOT_HUB_OperationEnable Function
This function enables or disables root hub operation.
File
drv_usbfs.h
C
void DRV_USBFS_HOST_ROOT_HUB_OperationEnable(DRV_HANDLE handle, bool enable);
Returns
None.
Description
This function enables or disables root hub operation. When enabled, the root hub will detect devices attached to the port and will request the Host
Layer to enumerate the device. This function is called by the Host Layer when it is ready to receive enumeration requests from the Host. If the
operation is disabled, the root hub will not detect attached devices.
Remarks
None.
Preconditions
None.
Example
// This code shows how the DRV_USBFS_HOST_ROOT_HUB_OperationEnable and the
// DRV_USBFS_HOST_ROOT_HUB_OperationIsEnabled functions are called to enable
// the Root hub operation.
DRV_HANDLE driverHandle;
// Enable Root hub operation.
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1220
DRV_USBFS_HOST_ROOT_HUB_OperationEnable(driverHandle);
// Wait till the Root hub operation is enabled.
if(DRV_USBFS_HOST_ROOT_HUB_OperationIsEnabled(driverHandle) == false)
{
// The operation has not completed. Call the
// DRV_USBFS_HOST_ROOT_HUB_OperationIsEnabled function again to check if
// the operation has completed. Note that the DRV_USBFS_Tasks function
// must be allowed to run at periodic intervals to allow the enable
// operation to completed.
}
Parameters
Parameters Description
handle Handle to the driver (returned from DRV_USBFS_Open function).
enable If this is set to true, root hub operation is enabled. If this is set to false, root hub operation is
disabled.
Function
void DRV_USBFS_HOST_ROOT_HUB_OperationEnable
(
DRV_HANDLE handle,
bool enable
);
DRV_USBFS_HOST_ROOT_HUB_OperationIsEnabled Function
Returns the operation enabled status of the root hub.
File
drv_usbfs.h
C
bool DRV_USBFS_HOST_ROOT_HUB_OperationIsEnabled(DRV_HANDLE handle);
Returns
• true - Root hub operation is enabled.
• false - Root hub operation is not enabled.
Description
This function returns true if the DRV_USBFS_HOST_ROOT_HUB_OperationEnable function has completed enabling the Host.
Remarks
None.
Preconditions
None.
Example
// This code shows how the DRV_USBFS_HOST_ROOT_HUB_OperationEnable and the
// DRV_USBFS_HOST_ROOT_HUB_OperationIsEnabled functions are called to enable
// the Root hub operation.
DRV_HANDLE driverHandle;
// Enable Root hub operation.
DRV_USBFS_HOST_ROOT_HUB_OperationEnable(driverHandle);
// Wait till the Root hub operation is enabled.
if(DRV_USBFS_HOST_ROOT_HUB_OperationIsEnabled(driverHandle) == false)
{
// The operation has not completed. Call the
// DRV_USBFS_HOST_ROOT_HUB_OperationIsEnabled function again to check if
// the operation has completed. Note that the DRV_USBFS_Tasks function
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1221
// must be allowed to run at periodic intervals to allow the enable
// operation to completed.
}
Parameters
Parameters Description
handle Handle to the driver (returned from DRV_USBFS_Open function).
Function
bool DRV_USBFS_HOST_ROOT_HUB_OperationIsEnabled( DRV_HANDLE handle);
DRV_USBFS_HOST_ROOT_HUB_PortNumbersGet Function
Returns the number of ports this root hub contains.
File
drv_usbfs.h
C
uint8_t DRV_USBFS_HOST_ROOT_HUB_PortNumbersGet(DRV_HANDLE handle);
Returns
This function will always return 1.
Description
This function returns the number of ports that this root hub contains.
Remarks
None.
Preconditions
None.
Example
// This code shows how DRV_USBFS_HOST_ROOT_HUB_PortNumbersGet function can
// be called to obtain the number of Root hub ports.
DRV_HANDLE driverHandle;
uint8_t nPorts;
nPorts = DRV_USBFS_HOST_ROOT_HUB_PortNumbersGet(driverHandle);
Parameters
Parameters Description
handle Handle to the driver (returned from DRV_USBFS_Open function).
Function
uint8_t DRV_USBFS_HOST_ROOT_HUB_PortNumbersGet( DRV_HANDLE handle);
DRV_USBFS_HOST_ROOT_HUB_PortReset Function
Resets the specified root hub port.
File
drv_usbfs.h
C
USB_ERROR DRV_USBFS_HOST_ROOT_HUB_PortReset(DRV_HANDLE handle, uint8_t port);
Returns
None.
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1222
Description
This function resets the root hub port. The reset duration is defined by DRV_USBFS_ROOT_HUB_RESET_DURATION. The status of the reset
signaling can be checked using the DRV_USBFS_ROOT_HUB_PortResetIsComplete function.
Remarks
The root hub on the PIC32MZ USB controller contains only one port - port 0.
Preconditions
None.
Example
// This code shows how the DRV_USB_HOST_ROOT_HUB_PortReset and the
// DRV_USBFS_ROOT_HUB_PortResetIsComplete functions are called to complete a
// port reset sequence.
DRV_HANDLE driverHandle;
// Reset Port 0.
DRV_USB_HOST_ROOT_HUB_PortReset(driverHandle, 0);
// Check if the Reset operation has completed.
if(DRV_USBFS_ROOT_HUB_PortResetIsComplete(driverHandle, 0) == false)
{
// This means that the Port Reset operation has not completed yet. The
// DRV_USBFS_ROOT_HUB_PortResetIsComplete function should be called
// again after some time to check the status.
}
Parameters
Parameters Description
handle Handle to the driver (returned from DRV_USBFS_Open function).
port Port to reset.
Function
void DRV_USBFS_ROOT_HUB_PortReset( DRV_HANDLE handle, uint8_t port );
DRV_USBFS_HOST_ROOT_HUB_PortResetIsComplete Function
Returns true if the root hub has completed the port reset operation.
File
drv_usbfs.h
C
bool DRV_USBFS_HOST_ROOT_HUB_PortResetIsComplete(DRV_HANDLE handle, uint8_t port);
Returns
• true - The reset signaling has completed.
• false - The reset signaling has not completed.
Description
This function returns true if the port reset operation has completed. It should be called after the DRV_USB_HOST_ROOT_HUB_PortReset
function to check if the reset operation has completed.
Remarks
The root hub on this particular hardware only contains one port - port 0.
Preconditions
None.
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1223
Example
// This code shows how the DRV_USB_HOST_ROOT_HUB_PortReset and the
// DRV_USBFS_ROOT_HUB_PortResetIsComplete functions are called to complete a
// port reset sequence.
DRV_HANDLE driverHandle;
// Reset Port 0.
DRV_USB_HOST_ROOT_HUB_PortReset(driverHandle, 0);
// Check if the Reset operation has completed.
if(DRV_USBFS_ROOT_HUB_PortResetIsComplete(driverHandle, 0) == false)
{
// This means that the Port Reset operation has not completed yet. The
// DRV_USBFS_ROOT_HUB_PortResetIsComplete function should be called
// again after some time to check the status.
}
Parameters
Parameters Description
handle Handle to the driver (returned from DRV_USBFS_Open function).
port Port to check
Function
bool DRV_USBFS_ROOT_HUB_PortResetIsComplete
(
DRV_HANDLE handle,
uint8_t port
);
DRV_USBFS_HOST_ROOT_HUB_PortResume Function
Resumes the specified root hub port.
File
drv_usbfs.h
C
USB_ERROR DRV_USBFS_HOST_ROOT_HUB_PortResume(DRV_HANDLE handle, uint8_t port);
Returns
• USB_ERROR_NONE - The function executed successfully.
• USB_ERROR_PARAMETER_INVALID - The driver handle is not valid or the port number does not exist.
Description
This function resumes the root hub. The resume duration is defined by DRV_USBFS_ROOT_HUB_RESUME_DURATION. The status of the
resume signaling can be checked using the DRV_USBFS_ROOT_HUB_PortResumeIsComplete function.
Remarks
The root hub on this particular hardware only contains one port - port 0.
Preconditions
None.
Example
// This code shows how the DRV_USBFS_HOST_ROOT_HUB_PortResume function is
// called to resume the specified port.
DRV_HANDLE driverHandle;
// Resume Port 0.
DRV_USBFS_HOST_ROOT_HUB_PortResume(driverHandle, 0);
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1224
Parameters
Parameters Description
handle Handle to the driver (returned from DRV_USBFS_Open function).
port Port to resume.
Function
USB_ERROR DRV_USBFS_HOST_ROOT_HUB_PortResume
(
DRV_HANDLE handle,
uint8_t port
);
DRV_USBFS_HOST_ROOT_HUB_PortSpeedGet Function
Returns the speed of at which the port is operating.
File
drv_usbfs.h
C
USB_SPEED DRV_USBFS_HOST_ROOT_HUB_PortSpeedGet(DRV_HANDLE handle, uint8_t port);
Returns
• USB_SPEED_ERROR - This value is returned if the driver handle is not or if the speed information is not available or if the specified port is not
valid.
• USB_SPEED_FULL - A Full Speed device has been connected to the port.
• USB_SPEED_LOW - A Low Speed device has been connected to the port.
Description
This function returns the speed at which the port is operating.
Remarks
The root hub on this particular hardware only contains one port - port 0.
Preconditions
None.
Example
// This code shows how the DRV_USBFS_HOST_ROOT_HUB_PortSpeedGet function is
// called to know the operating speed of the port. This also indicates the
// operating speed of the device connected to this port.
DRV_HANDLE driverHandle;
USB_SPEED speed;
speed = DRV_USBFS_HOST_ROOT_HUB_PortSpeedGet(driverHandle, 0);
Parameters
Parameters Description
handle Handle to the driver (returned from DRV_USBFS_Open function).
port Port number of the port to be analyzed..
Function
USB_SPEED DRV_USBFS_HOST_ROOT_HUB_PortSpeedGet
(
DRV_HANDLE handle,
uint8_t port
);
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1225
DRV_USBFS_HOST_ROOT_HUB_PortSuspend Function
Suspends the specified root hub port.
File
drv_usbfs.h
C
USB_ERROR DRV_USBFS_HOST_ROOT_HUB_PortSuspend(DRV_HANDLE handle, uint8_t port);
Returns
• USB_ERROR_NONE - The function executed successfully.
• USB_ERROR_PARAMETER_INVALID - The driver handle is not valid or the port number does not exist.
Description
This function suspends the root hub port.
Remarks
The root hub on this particular hardware only contains one port - port 0.
Preconditions
None.
Example
// This code shows how the DRV_USBFS_HOST_ROOT_HUB_PortSuspend function is
// called to suspend the specified port.
DRV_HANDLE driverHandle;
// Suspend Port 0.
DRV_USBFS_HOST_ROOT_HUB_PortSuspend(driverHandle, 0);
Parameters
Parameters Description
handle Handle to the driver (returned from DRV_USBFS_Open function).
port Port to suspend.
Function
USB_ERROR DRV_USBFS_ROOT_HUB_PortSuspend( DRV_HANDLE handle, uint8_t port);
f) Data Types and Constants
DRV_USBFS_EVENT Enumeration
Identifies the different events that the USB Driver provides.
File
drv_usbfs.h
C
typedef enum {
DRV_USBFS_EVENT_ERROR = DRV_USB_EVENT_ERROR,
DRV_USBFS_EVENT_RESET_DETECT = DRV_USB_EVENT_RESET_DETECT,
DRV_USBFS_EVENT_RESUME_DETECT = DRV_USB_EVENT_RESUME_DETECT,
DRV_USBFS_EVENT_IDLE_DETECT = DRV_USB_EVENT_IDLE_DETECT,
DRV_USBFS_EVENT_STALL = DRV_USB_EVENT_STALL,
DRV_USBFS_EVENT_SOF_DETECT = DRV_USB_EVENT_SOF_DETECT,
DRV_USBFS_EVENT_DEVICE_SESSION_VALID = DRV_USB_EVENT_DEVICE_SESSION_VALID,
DRV_USBFS_EVENT_DEVICE_SESSION_INVALID = DRV_USB_EVENT_DEVICE_SESSION_INVALID
} DRV_USBFS_EVENT;
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1226
Members
Members Description
DRV_USBFS_EVENT_ERROR =
DRV_USB_EVENT_ERROR
Bus error occurred and was reported
DRV_USBFS_EVENT_RESET_DETECT =
DRV_USB_EVENT_RESET_DETECT
Host has issued a device reset
DRV_USBFS_EVENT_RESUME_DETECT =
DRV_USB_EVENT_RESUME_DETECT
Resume detected while USB in suspend mode
DRV_USBFS_EVENT_IDLE_DETECT =
DRV_USB_EVENT_IDLE_DETECT
Idle detected
DRV_USBFS_EVENT_STALL =
DRV_USB_EVENT_STALL
Stall handshake has occurred
DRV_USBFS_EVENT_SOF_DETECT =
DRV_USB_EVENT_SOF_DETECT
Either Device received SOF or SOF threshold was reached in the Host mode operation
DRV_USBFS_EVENT_DEVICE_SESSION_VALID =
DRV_USB_EVENT_DEVICE_SESSION_VALID
Session valid
DRV_USBFS_EVENT_DEVICE_SESSION_INVALID
= DRV_USB_EVENT_DEVICE_SESSION_INVALID
Session Invalid
Description
USB Driver Events Enumeration.
This enumeration identifies the different events that are generated by the USB Driver.
Remarks
None.
DRV_USBFS_EVENT_CALLBACK Type
Type of the USB Driver event callback function.
File
drv_usbfs.h
C
typedef void (* DRV_USBFS_EVENT_CALLBACK)(uintptr_t hClient, DRV_USBFS_EVENT eventType, void * eventData);
Returns
None.
Description
Type of the USB Driver Event Callback Function.
Define the type of the USB Driver event callback function. The client should register an event callback function of this type when it intends to
receive events from the USB Driver. The event callback function is registered using the DRV_USBFS_ClientEventCallBackSet function.
Remarks
None.
Parameters
Parameters Description
hClient Handle to the driver client that registered this callback function.
eventType This parameter identifies the event that caused the callback function to be called.
eventData Pointer to a data structure that is related to this event. This value will be NULL if the event has
no related data.
DRV_USBFS_HOST_PIPE_HANDLE Type
Defines the USB Driver Host Pipe Handle type.
File
drv_usbfs.h
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1227
C
typedef uintptr_t DRV_USBFS_HOST_PIPE_HANDLE;
Description
USB Driver Host Pipe Handle.
This type definition defines the type of the USB Driver Host Pipe Handle.
Remarks
None.
DRV_USBFS_INIT Structure
This type definition defines the Driver Initialization Data Structure.
File
drv_usbfs.h
C
typedef struct {
SYS_MODULE_INIT moduleInit;
USB_MODULE_ID usbID;
bool stopInIdle;
bool suspendInSleep;
INT_SOURCE interruptSource;
USB_SPEED operationSpeed;
DRV_USBFS_OPMODES operationMode;
void * endpointTable;
uint32_t rootHubAvailableCurrent;
DRV_USBFS_ROOT_HUB_PORT_POWER_ENABLE portPowerEnable;
DRV_USBFS_ROOT_HUB_PORT_INDICATION portIndication;
DRV_USBFS_ROOT_HUB_PORT_OVER_CURRENT_DETECT portOverCurrentDetect;
} DRV_USBFS_INIT;
Members
Members Description
SYS_MODULE_INIT moduleInit; System Module Initialization
USB_MODULE_ID usbID; Identifies the USB peripheral to be used. This should be the USB PLIB module
instance identifier.
bool stopInIdle; This should be set to true if the USB module must stop operation in IDLE mode
bool suspendInSleep; This should be set to true if the USB module must suspend when the CPU
enters sleep mode.
INT_SOURCE interruptSource; Specify the interrupt source for the USB module. This should be the interrupt
source identifier for the USB module instance specified in usbID.
USB_SPEED operationSpeed; Specify the operational speed of the USB module. This should always be set
to USB_SPEED_FULL.
DRV_USBFS_OPMODES operationMode; Specify the operation mode of the USB module. This specifies if the USB
module should operate as a Device, Host, or both (Dual Role operation).
void * endpointTable; A pointer to the endpoint descriptor table. This should be aligned at 512 byte
address boundary. The size of the table is equal to
DRV_USBFS_ENDPOINT_TABLE_ENTRY_SIZE times the number of
endpoints needed in the application.
uint32_t rootHubAvailableCurrent; Root hub available current in milliamperes. This specifies the amount of
current that root hub can provide to the attached device. This should be
specified in mA. This is required when the driver is required to operate in host
mode.
DRV_USBFS_ROOT_HUB_PORT_POWER_ENABLE
portPowerEnable;
When operating in Host mode, the application can specify a Root Hub port
enable function. This parameter should point to Root Hub port enable function.
If this parameter is NULL, it implies that the Port is always enabled.
DRV_USBFS_ROOT_HUB_PORT_INDICATION portIndication; When operating in Host mode, the application can specify a Root Port
Indication. This parameter should point to the Root Port Indication function. If
this parameter is NULL, it implies that Root Port Indication is not supported.
DRV_USBFS_ROOT_HUB_PORT_OVER_CURRENT_DETECT
portOverCurrentDetect;
When operating is Host mode, the application can specify a Root Port
Overcurrent detection. This parameter should point to the Root Port Indication
function. If this parameter is NULL, it implies that Overcurrent detection is not
supported.
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1228
Description
USB Device Driver Initialization Data.
This structure contains all the data necessary to initialize the USB Driver. A pointer to a structure of this type, containing the desired initialization
data, must be passed into the DRV_USBFS_Initialize function.
Remarks
None.
DRV_USBFS_OPMODES Enumeration
Identifies the operating modes supported by the USB Driver.
File
drv_usbfs.h
C
typedef enum {
DRV_USBFS_OPMODE_DUAL_ROLE = DRV_USB_OPMODE_DUAL_ROLE,
DRV_USBFS_OPMODE_DEVICE = DRV_USB_OPMODE_DEVICE,
DRV_USBFS_OPMODE_HOST = DRV_USB_OPMODE_HOST,
DRV_USBFS_OPMODE_OTG = DRV_USB_OPMODE_OTG
} DRV_USBFS_OPMODES;
Members
Members Description
DRV_USBFS_OPMODE_DUAL_ROLE =
DRV_USB_OPMODE_DUAL_ROLE
The driver should be able to switch between host and device mode
DRV_USBFS_OPMODE_DEVICE =
DRV_USB_OPMODE_DEVICE
The driver should support device mode operation only
DRV_USBFS_OPMODE_HOST =
DRV_USB_OPMODE_HOST
The driver should support host mode operation only
DRV_USBFS_OPMODE_OTG =
DRV_USB_OPMODE_OTG
The driver should support the OTG protocol
Description
USB Operating Modes Enumeration.
This enumeration identifies the operating modes supported by the USB Driver.
Remarks
None.
DRV_USBFS_ROOT_HUB_PORT_INDICATION Type
USB Root hub Application Hooks (Port Indication).
File
drv_usbfs.h
C
typedef void (* DRV_USBFS_ROOT_HUB_PORT_INDICATION)(uint8_t port, USB_HUB_PORT_INDICATOR_COLOR color,
USB_HUB_PORT_INDICATOR_STATE state);
Description
USB Root hub Application Hooks (Port Indication).
A function of the type defined here should be provided to the driver root to implement Port Indication. The root hub driver calls this function when it
needs to update the state of the port indication LEDs. The application can choose to implement the Amber and Green colors as one LED or two
different LEDs. The root hub driver specifies the color and the indicator attribute (on, off or blinking) when it calls this function.
Remarks
None.
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1229
DRV_USBFS_ROOT_HUB_PORT_OVER_CURRENT_DETECT Type
USB Root hub Application Hooks (Port Overcurrent detection).
File
drv_usbfs.h
C
typedef bool (* DRV_USBFS_ROOT_HUB_PORT_OVER_CURRENT_DETECT)(uint8_t port);
Description
USB Root hub Application Hooks (Port Overcurrent detection).
A function of the type defined here should be provided to the driver root hub to check for port over current condition. This function will be called
periodically by the root hub driver to check the Overcurrent status of the port. It should continue to return true while the Overcurrent condition
exists on the port. It should return false when the Overcurrent condition does not exist.
Remarks
None.
DRV_USBFS_ROOT_HUB_PORT_POWER_ENABLE Type
USB Root hub Application Hooks (Port Power Enable/ Disable).
File
drv_usbfs.h
C
typedef void (* DRV_USBFS_ROOT_HUB_PORT_POWER_ENABLE)(uint8_t port, bool control);
Description
USB Root hub Application Hooks (Port Power Enable/ Disable).
A function of the type defined here should be provided to the driver root to control port power. The root hub driver will call this function when it
needs to enable port power. If the application circuit contains a VBUS switch, the switch should be accessed and controlled by this function. If the
enable parameter is true, the switch should be enabled and VBUS should be available on the port. If the enable parameter is false, the switch
should be disabled and VBUS should not be available on the port.
Remarks
None.
DRV_USBFS_DEVICE_INTERFACE Macro
USB Driver Device Mode Interface Functions.
File
drv_usbfs.h
C
#define DRV_USBFS_DEVICE_INTERFACE
Description
USB Driver Device Mode Interface Functions.
The Device Driver interface in the Device Layer Initialization data structure should be set to this value so that Device Layer can access the USB
Driver Device Mode functions.
Remarks
None.
DRV_USBFS_ENDPOINT_TABLE_ENTRY_SIZE Macro
USB Driver Endpoint Table Entry Size in bytes.
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1230
File
drv_usbfs.h
C
#define DRV_USBFS_ENDPOINT_TABLE_ENTRY_SIZE 32
Description
USB Driver Endpoint Table Entry Size in bytes.
This constant defines the size (in bytes) of an entry in the endpoint table.
Remarks
None.
DRV_USBFS_HOST_INTERFACE Macro
USB Driver Host Mode Interface Functions.
File
drv_usbfs.h
C
#define DRV_USBFS_HOST_INTERFACE
Description
USB Driver Host Mode Interface Functions.
The Host Controller Driver interface in the Host Layer Initialization data structure should be set to this value so that Host Layer can access the
USB Driver Host Mode functions.
Remarks
None.
DRV_USBFS_HOST_PIPE_HANDLE_INVALID Macro
Value of an Invalid Host Pipe Handle.
File
drv_usbfs.h
C
#define DRV_USBFS_HOST_PIPE_HANDLE_INVALID ((DRV_USBFS_HOST_PIPE_HANDLE)(-1))
Description
USB Driver Invalid Host Pipe Handle.
This constant defines the value of an Invalid Host Pipe Handle.
Remarks
None.
DRV_USBFS_INDEX_0 Macro
USB Driver Module Index 0 Definition.
File
drv_usbfs.h
C
#define DRV_USBFS_INDEX_0 0
Description
USB Driver Module Index 0 Definition.
This constant defines the value of USB Driver Index 0. The SYS_MODULE_INDEX parameter of the DRV_USBFS_Initialize and
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1231
DRV_USBFS_Open functions should be set to this value to identify instance 0 of the driver.
Remarks
These constants should be used in place of hard-coded numeric literals and should be passed into the DRV_USBFS_Initialize and
DRV_USBFS_Open functions to identify the driver instance in use. These are not indicative of the number of modules that are actually supported
by the microcontroller.
DRV_USBFS_INDEX_1 Macro
USB Driver Module Index 1 Definition.
File
drv_usbfs.h
C
#define DRV_USBFS_INDEX_1 1
Description
USB Driver Module Index 1 Definition.
This constant defines the value of USB Driver Index 1. The SYS_MODULE_INDEX parameter of the DRV_USBFS_Initialize and
DRV_USBFS_Open functions should be set to this value to identify instance 1 of the driver.
Remarks
These constants should be used in place of hard-coded numeric literals and should be passed into the DRV_USBFS_Initialize and
DRV_USBFS_Open functions to identify the driver instance in use. These are not indicative of the number of modules that are actually supported
by the microcontroller.
Files
Files
Name Description
drv_usbfs.h PIC32MX USB Module Driver Interface File.
drv_usbfs_config_template.h USB Full Speed (USBFS) Driver Configuration Template.
Description
drv_usbfs.h
PIC32MX USB Module Driver Interface File.
Enumerations
Name Description
DRV_USBFS_EVENT Identifies the different events that the USB Driver provides.
DRV_USBFS_OPMODES Identifies the operating modes supported by the USB Driver.
Functions
Name Description
DRV_USBFS_ClientEventCallBackSet This function sets up the event callback function that is invoked by the
USB controller driver to notify the client of USB bus events.
DRV_USBFS_Close Closes an opened-instance of the USB Driver.
DRV_USBFS_DEVICE_AddressSet This function will set the USB module address that is obtained from the
Host.
DRV_USBFS_DEVICE_Attach This function will enable the attach signaling resistors on the D+ and Dlines
thus letting the USB Host know that a device has been attached
on the bus.
DRV_USBFS_DEVICE_CurrentSpeedGet This function returns the USB speed at which the device is operating.
DRV_USBFS_DEVICE_Detach This function will disable the attach signaling resistors on the D+ and Dlines
thus letting the USB Host know that the device has detached from
the bus.
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1232
DRV_USBFS_DEVICE_EndpointDisable This function disables an endpoint.
DRV_USBFS_DEVICE_EndpointDisableAll This function disables all provisioned endpoints.
DRV_USBFS_DEVICE_EndpointEnable This function enables an endpoint for the specified direction and
endpoint size.
DRV_USBFS_DEVICE_EndpointIsEnabled This function returns the enable/disable status of the specified endpoint
and direction.
DRV_USBFS_DEVICE_EndpointIsStalled This function returns the stall status of the specified endpoint and
direction.
DRV_USBFS_DEVICE_EndpointStall This function stalls an endpoint in the specified direction.
DRV_USBFS_DEVICE_EndpointStallClear This function clears the stall on an endpoint in the specified direction.
DRV_USBFS_DEVICE_IRPCancel This function cancels the specific IRP that are queued and in progress
at the specified endpoint.
DRV_USBFS_DEVICE_IRPCancelAll This function cancels all IRPs that are queued and in progress at the
specified endpoint.
DRV_USBFS_DEVICE_IRPSubmit This function submits an I/O Request Packet (IRP) for processing to the
Hi-Speed USB Driver.
DRV_USBFS_DEVICE_RemoteWakeupStart This function causes the device to start Remote Wakeup Signalling on
the bus.
DRV_USBFS_DEVICE_RemoteWakeupStop This function causes the device to stop the Remote Wakeup Signalling
on the bus.
DRV_USBFS_DEVICE_SOFNumberGet This function will return the USB SOF packet number.
DRV_USBFS_HOST_EventsDisable Disables Host mode events.
DRV_USBFS_HOST_EventsEnable Restores the events to the specified the original value.
DRV_USBFS_HOST_IRPCancel Cancels the specified IRP.
DRV_USBFS_HOST_IRPSubmit Submits an IRP on a pipe.
DRV_USBFS_HOST_PipeClose Closes an open pipe.
DRV_USBFS_HOST_PipeSetup Open a pipe with the specified attributes.
DRV_USBFS_HOST_ROOT_HUB_BusSpeedGet This function returns the operating speed of the bus to which this root
hub is connected.
DRV_USBFS_HOST_ROOT_HUB_Initialize This function initializes the root hub driver.
DRV_USBFS_HOST_ROOT_HUB_MaximumCurrentGet Returns the maximum amount of current that this root hub can provide
on the bus.
DRV_USBFS_HOST_ROOT_HUB_OperationEnable This function enables or disables root hub operation.
DRV_USBFS_HOST_ROOT_HUB_OperationIsEnabled Returns the operation enabled status of the root hub.
DRV_USBFS_HOST_ROOT_HUB_PortNumbersGet Returns the number of ports this root hub contains.
DRV_USBFS_HOST_ROOT_HUB_PortReset Resets the specified root hub port.
DRV_USBFS_HOST_ROOT_HUB_PortResetIsComplete Returns true if the root hub has completed the port reset operation.
DRV_USBFS_HOST_ROOT_HUB_PortResume Resumes the specified root hub port.
DRV_USBFS_HOST_ROOT_HUB_PortSpeedGet Returns the speed of at which the port is operating.
DRV_USBFS_HOST_ROOT_HUB_PortSuspend Suspends the specified root hub port.
DRV_USBFS_Initialize Initializes the USB Driver.
DRV_USBFS_Open Opens the specified USB Driver instance and returns a handle to it.
DRV_USBFS_Status Provides the current status of the USB Driver module.
DRV_USBFS_Tasks Maintains the driver's state machine when the driver is configured for
Polled mode.
DRV_USBFS_Tasks_ISR Maintains the driver's Interrupt state machine and implements its ISR.
Macros
Name Description
DRV_USBFS_DEVICE_INTERFACE USB Driver Device Mode Interface Functions.
DRV_USBFS_ENDPOINT_TABLE_ENTRY_SIZE USB Driver Endpoint Table Entry Size in bytes.
DRV_USBFS_HOST_INTERFACE USB Driver Host Mode Interface Functions.
DRV_USBFS_HOST_PIPE_HANDLE_INVALID Value of an Invalid Host Pipe Handle.
DRV_USBFS_INDEX_0 USB Driver Module Index 0 Definition.
DRV_USBFS_INDEX_1 USB Driver Module Index 1 Definition.
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1233
Structures
Name Description
DRV_USBFS_INIT This type definition defines the Driver Initialization Data Structure.
Types
Name Description
DRV_USBFS_EVENT_CALLBACK Type of the USB Driver event callback function.
DRV_USBFS_HOST_PIPE_HANDLE Defines the USB Driver Host Pipe Handle type.
DRV_USBFS_ROOT_HUB_PORT_INDICATION USB Root hub Application Hooks (Port Indication).
DRV_USBFS_ROOT_HUB_PORT_OVER_CURRENT_DETECT USB Root hub Application Hooks (Port Overcurrent detection).
DRV_USBFS_ROOT_HUB_PORT_POWER_ENABLE USB Root hub Application Hooks (Port Power Enable/ Disable).
Description
PIC32MX USB Module Driver Interface Header File.
The PIC32MX Full speed USB Module driver provides a simple interface to manage the "USB" peripheral on PIC32MX microcontrollers. This file
defines the interface definitions and prototypes for the USB driver. The driver interface meets the requirements of the MPLAB Harmony USB Host
and Device Layer.
File Name
drv_usbfs.h
Company
Microchip Technology Inc.
drv_usbfs_config_template.h
USB Full Speed (USBFS) Driver Configuration Template.
Macros
Name Description
DRV_USBFS_DEVICE_SUPPORT Determines if the USB Device Functionality should be enabled.
DRV_USBFS_ENDPOINTS_NUMBER Configures the number of endpoints to be provisioned in the driver.
DRV_USBFS_HOST_ATTACH_DEBOUNCE_DURATION Configures the time duration (in milliseconds) that the driver will wait to
re-confirm a device attach.
DRV_USBFS_HOST_NAK_LIMIT Configures the NAK Limit for Host Mode Control Transfers.
DRV_USBFS_HOST_PIPES_NUMBER Configures the maximum number of pipes that are can be opened
when the driver is operating in Host mode.
DRV_USBFS_HOST_RESET_DURATION Configures the time duration (in milliseconds) of the Reset Signal.
DRV_USBFS_HOST_SUPPORT Determines if the USB Host Functionality should be enabled.
DRV_USBFS_INSTANCES_NUMBER Specifies the number of driver instances to be enabled in the
application.
DRV_USBFS_INTERRUPT_MODE Configures the driver for interrupt or polling mode operation.
Description
USB Full Speed Driver Configuration Template.
This file lists all the configurations constants that affect the operation of the USBFS Driver.
File Name
drv_usbfs_config_template.h
Company
Microchip Technology Inc.
PIC32MZ USB Driver
Provides information on the USB Driver specific to PIC32MZ devices.
Description
The PIC32MZ USB Driver in MPLAB Harmony provides API functions that allow the MPLAB Harmony USB Host and Device Stack to access the
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1234
USB while operating on a PIC32MZ microcontroller. The driver implements the USB Driver Common Interface required by the USB Host and
Device Stack. It abstracts the USB module operational details from the Host and Device Stack and provides the stacks with a modular access
mechanism to the USB. The PIC32MZ USB Driver features the following:
• USB 2.0 High Speed and Full Speed operation in Peripheral mode
• USB 2.0 High Speed, Full Speed and Low Speed USB Peripheral Support in Host mode
• Designed for Dual Role Operation
• Capable of operating multiple USB modules
• Features non-blocking function and is interoperable with other MPLAB Harmony modules
• Features thread safe functions when operating within an RTOS
• Capable of operating in Polled and Interrupt modes
• Implements the USB Driver Common Interface required by the MPLAB Harmony USB Host and Device Stack
• Completely configurable through the MPLAB Harmony Configurator (MHC)
• Implements feature separation (Host and Device mode functions are implemented across different files)
• Designed to use the module’s built-in DMA controller and transfer scheduler
Note:
This help section only discusses features that are unique to the PIC32MZ USB Driver and are not a part of the USB Driver
Common Interface. The driver functions that implement the USB Driver Common Interface are described in the Common Interface
Help section.
While the PIC32MZ USB module supports USB "On-The-Go" (OTG), the PIC32MZ Driver does not currently implement USB OTG protocol
support.
This help section only provides relevant information about the operation of the USB. The reader is encouraged to refer to the USB 2.0
Specification available at www.usb.org for a detailed explanation of USB protocol.
Using the Library
This topic describes the basic architecture of the USB PIC32MZ Driver Library and provides information and examples on its use.
Description
Interface Header File: drv_usbhs.h
The interface to the PIC32MZ USB Driver library is defined in the drv_usbhs.h header file.
Please refer to the What is MPLAB Harmony? section for how the driver interacts with the framework.
Library Overview
Provides an overview of the library.
Description
The PIC32MZ USB Driver will typically be used by a USB Host and/or Device Stack. The USB Host and Device Stack operate as driver client
applications. The driver is initialized as part of the MPLAB Harmony System Initialization. The driver initialization data structure specifies the
operation mode (Host, Device, or Dual Role) of the driver. The driver features task routines to be called in the MPLAB Harmony application tasks
function (SYS_Tasks function) and the USB Module Interrupt Service Routine (ISR).
The Host and the Device Stack can open the driver only when initialization has completed. It will continue to return an invalid driver handle while
the initialization is in progress. Once opened, the Device Mode function can be called if the driver is operating in Device mode. The Host Mode
function can be called if the driver is operating in Host mode. In Dual Role operation mode, the driver supports Host and Device operation in the
same application. Even then, the driver will either operate as a USB Host or Device. OTG operation is not supported.
The PIC32MZ USB Driver features RTOS thread-safe functions. This allows the driver client application to safely call driver functions across
different RTOS threads. Not all of the driver functions are interrupt-safe.
In addition to the USB Driver, which implements the USB Driver Common Interface, the PIC32MZ USB Driver implements functions which are
required for its operation in the MPLAB Harmony framework. The following table lists the different categories of functions in the PIC32MZ USB
Driver.
Library
Interface
Section
Description
System
Function
These functions are accessed by the MPLAB Harmony System module. They allow the driver to be initialized, deinitialized and
maintained. These functions are implemented in the drv_usbhs.c source file.
Client Core
Functions
These functions allow the USB Host and Device Stack to open, close and perform other general driver operations. These
functions are a part of the USB Driver Common Interface and are implemented in drv_usbhs.c source file.
Device Mode
Operation
Functions
These functions allow the USB Device Stack to perform USB Device mode specific driver operations. These functions are a
part of the USB Driver Common Interface and are implemented in drv_usbhs_device.c source file
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1235
Host Mode
Operation
Functions
These functions allow the USB Host Stack to perform USB Host mode specific driver operations. These functions are a part of
the USB Driver Common Interface and are implemented in drv_usbhs_host.c source file.
Root Hub
Functions
These functions allow the USB Host Stack to access the driver Root hub operation. These functions are a part of the USB
Driver Common Interface and are implemented in drv_usbhs_host.c source file.
Abstraction Model
Provides information on the abstraction model for the library.
Description
The PIC32MZ USB Driver implements the abstraction model defined by the USB Driver Common interface. This interface abstracts USB module
specific details and provides a module independent interface to the driver client applications.
While operating in Device mode, the driver expects the client application (the USB Device Stack) to enable endpoints and then submit I/O request
packet (IRP) requests to the enabled endpoints. Multiple IRPs can be queued on an endpoint. The driver calls the IRP callback function when the
IRP is processed. The driver allows the client application to also attach and detach the device on the bus. It generates events which indicate USB
states.
While operating in Host mode, the driver expects the client application (the USB Host Stack) to open pipes to endpoints on the connected device.
The client application can then submit IRPs to the pipes. Multiple IRPs can be queued on a pipe. The driver calls the IRP callback function when
the IRP is processed. The driver will call application defined functions to enumerate and denumerate a device. These functions are called when
the driver detect device attach and detach respectively. The driver also exports root hub functions to the client application. This allows the client
application to treat the driver as a single port hub
Please refer to the PIC32 USB Driver Common Interface help section for more details on the driver abstraction model.
How the Library Works
Provides information on how the library works.
Description
This section only explains aspects of driver operation which are unique to the PIC32MZ USB Driver. Major driver operations are described in the
PIC32 USB Driver Common Interface help section.
Driver Initialization
Note:
While generating a MPLAB Harmony USB project with MHC, the initialization code for the driver is generated automatically based
on selections made in the USB Host stack or Device Stack Configuration trees.
The PIC32MZ USB Driver must be initialized so that a client application can open. The client application will not be able to open the driver if the
initialization is in progress or has failed. The driver is initialized by calling the DRV_USBHS_Initialize function. This function is called from the
SYS_Initialize function in the MPLAB Harmony application project and accepts two input parameters. The index parameter defines the instance
of the USB Driver to be initialized. This becomes significant when the PIC32MZ microcontroller has more than one USB module. The init
parameter is a driver-specific data structure of the type DRV_USBHS_INIT. This structure is shown in the following code example.
/* This code show the PIC32MZ USB Driver Initialization data structure.
* A structure of this type must be provided to the DRV_USBHS_Initialize
* function. */
typedef struct
{
/* System Module Initialization */
SYS_MODULE_INIT moduleInit;
/* Identifies the USB peripheral to be used. This should be the USB PLIB
module instance identifier. */
uint8_t usbID;
/* This should be set to true if the USB module must stop operation in Idle
mode */
bool stopInIdle;
/* This should be set to true if the USB module must suspend when the CPU
enters Sleep mode. */
bool suspendInSleep;
/* Specify the interrupt source for the USB module. This should be Interrupt
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1236
PLIB Interrupt source identifier for the USB module instance specified in
usbID. */
INT_SOURCE interruptSource;
/* Specify the interrupt source for the USB module specific DMA controller.
* This should be the PLIB Interrupt source identified for the USB
* module instance specified in usbID. */
INT_SOURCE interruptSourceUSBDma;
/* Specify the operational speed of the USB module. This should always be
set to USB_SPEED_FULL. */
USB_SPEED operationSpeed;
/* Specify the operation mode of the USB module. This defines if the USB
* module will support Device, Host or Dual Role operation */
DRV_USBHS_OPMODES operationMode;
/* A pointer to the endpoint descriptor table. This should be aligned at 512
byte address boundary. The size of the table is equal to the
DRV_USBHS_ENDPOINT_TABLE_ENTRY_SIZE times the number of endpoints needed
in the application. */
void * endpointTable;
/* Root hub available current in mA. This specifies the amount of current
that root hub can provide to the attached device. This should be
specified in mA. This is required when the driver is required to operate
in host mode. */
uint32_t rootHubAvailableCurrent;
/* When operating in Host mode, the application can specify a Root Hub port
enable function. This parameter should point to Root Hub port enable
function. If this parameter is NULL, it implies that the Port is always
enabled. */
DRV_USBHS_ROOT_HUB_PORT_POWER_ENABLE portPowerEnable;
/* When operating in Host mode, the application can specify a Root Port
Indication. This parameter should point to the Root Port Indication
function. If this parameter is NULL, it implies that Root Port Indication
is not supported. */
DRV_USBHS_ROOT_HUB_PORT_INDICATION portIndication;
/* When operating is Host mode, the application can specify a Root Port
Overcurrent detection. This parameter should point to the Root Port
Indication function. If this parameter is NULL, it implies that
Overcurrent detection is not supported. */
DRV_USBHS_ROOT_HUB_PORT_OVER_CURRENT_DETECT portOverCurrentDetect;
} DRV_USBHS_INIT;
The operationMode parameter defines the driver operation mode. This can be set to DRV_USBFS_OPMODE_DEVICE,
DRV_USBFS_OPMODE_HOST, or DRV_USBFS_OPMODE_DUAL_ROLE for Device, Host and Dual Role operation, respectively.
The rootHubAvailableCurrent parameter should be set to the maximum current that the VBUS power supply can provide on the bus. The
driver does not use this information directly. It provides this data to the client application while operating in Host mode.
The portPowerEnable parameter must point to a Port Power Enable function. The driver, while operating in Host mode, will call this function to
enable the VBUS switch. This function should activate the VBUS switch if the driver calls this function with the enable parameter set to true. It
should deactivate the switch if the driver calls this function with the enable parameter set to false. This parameter should be set to NULL if such a
switch (of the switch control) is not available in the application.
The portIndication parameter must point to a Port Indication function. The driver, while operating in Host mode, will call this function to
indicate the current state of the port. The driver will call this function with LED color status as defined in Chapter 11 of the USB 2.0 Specification.
This parameter should be set to NULL if such a LED indication is not available in the application.
The portOverCurrentDetect parameter must point to a Port Overcurrent Detect function. The driver, while operating in Host mode, will call
this function periodically to check if the attached device is overdrawing current. If the function should return true if such a condition exists. This
parameter should be set to NULL if such detection is not available in the application.
The following code example shows initialization of the driver for Device mode operation.
/* This code shows an example of DRV_USBHS_INIT data structure for
* Device mode operation. Here the driver is initialized to work with USB0 USB
* module. */
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1237
DRV_USBHS_INIT init;
SYS_MODULE_OBJ usbDriverObj;
const DRV_USBHS_INIT drvUSBInit =
{
/* Interrupt Source for USB module */
.interruptSource = INT_SOURCE_USB_1,
/* DMA Interrupt Source for USB module */
.interruptSourceUSBDma = INT_SOURCE_USB_1_DMA,
/* System module initialization */
.moduleInit = {SYS_MODULE_POWER_RUN_FULL},
/* Module operate in device mode */
.operationMode = DRV_USBHS_OPMODE_DEVICE,
/* Module operated at high speed */
.operationSpeed = USB_SPEED_HIGH,
/* Stop in idle */
.stopInIdle = false,
/* Suspend in sleep */
.suspendInSleep = false,
/* Identifies peripheral (PLIB-level) ID */
.usbID = USBHS_ID_0
};
void SYS_Initialize(void)
{
/* Initialize the USB Driver. Note how the init parameter is typecast to
* SYS_MODULE_INIT type. The SYS_MODULE_OBJ returned by this function call
* is passed to the driver tasks routine. DRV_USBHS_INDEX_0 is helper
* constant defined in drv_usbfs.h */
usbDriverObj = DRV_USBHS_Initialize(DRV_USBHS_INDEX_0, (SYS_MODULE_INIT *)(drvUSBInit));
}
void SYS_Tasks(void)
{
/* The polled state of the USB driver is updated by calling the
* DRV_USBHS_Tasks function in the SYS_Tasks() function. The
* DRV_USBHS_Tasks() takes the driver module object returned by the
* DRV_USBHS_Initialize funciton as a parameter. */
DRV_USBHS_Tasks(usbDriverObj);
}
void __ISR(_USB_VECTOR, ipl4AUTO) _IntHandlerUSBInstance0(void)
{
/* The DRV_USBHS_Tasks_ISR function update the interrupt state of the USB
* Driver. If the driver is configured for Polling mode, this function need
* not be invoked or included in the project. */
DRV_USBHS_Tasks_ISR(usbDriverObj);
}
void __ISR ( _USB_DMA_VECTOR,ipl4AUTO) _IntHandlerUSBInstance0_USBDMA ( void )
{
DRV_USBHS_Tasks_ISR_USBDMA(usbDriverObj);
}
The following code example shows initialization of the driver for Host mode operation.
/* This code shows an example of how the Hi-Speed USB (USBHS) driver can be configured
* for Host mode operation. In this example, the
* BSP_USBVBUSSwitchOverCurrentDetect function checks for over current condition
* and the BSP_USBVBUSPowerEnable function enables the VBUS power. The port
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1238
* indication function is not implemented and hence the portIndication member of
* the initialization data structure is set to NULL. */
/* The implementation of the port over current detect, indication and the VBUS
* power supply functions is discussed later in this help section. */
DRV_USBHS_INIT drvUSBHSInit =
{
/* This should always be set to SYS_MODULE_POWER_RUN_FULL. */
.moduleInit = {SYS_MODULE_POWER_RUN_FULL},
/* Interrupt Source for the USB module */
.interruptSource = INT_SOURCE_USB_1,
/* Interrupt Source for the USB DMA module */
.interruptSourceUSBDma = INT_SOURCE_USB_1_DMA,
/* Configure for host mode operation. */
.operationMode = DRV_USBHS_OPMODE_HOST,
/* The driver should run at high speed. */
.operationSpeed = USB_SPEED_HIGH,
/* Port indication function is not implemented and is not available */
.portIndication = NULL,
/* This is the VBUS Power enable function */
.portPowerEnable = BSP_USBVBUSPowerEnable,
/* This is the over current detect function. */
.portOverCurrentDetect = BSP_USBVBUSSwitchOverCurrentDetect,
/* Here we state that the VBUS power supply can provide at most 500 mA of
* current */
.rootHubAvailableCurrent = 500,
/* Moudule will operate in IDLE. */
.stopInIdle = false,
/* Module will not suspend automatically in sleep */
.suspendInSleep = false,
/* USB Module ID is 1 */
.usbID = USBHS_ID_0
};
void SYS_Initialize(void)
{
/* Initialize the USB Driver. Note how the init parameter is typecast to
* SYS_MODULE_INIT type. The SYS_MODULE_OBJ returned by this function call
* is passed to the driver tasks routine. DRV_USBHS_INDEX_0 is helper
* constant defined in drv_usbfs.h */
usbDriverObj = DRV_USBHS_Initialize(DRV_USBHS_INDEX_0, (SYS_MODULE_INIT *)(drvUSBInit));
}
void SYS_Tasks(void)
{
/* The polled state of the USB driver is updated by calling the
* DRV_USBHS_Tasks function in the SYS_Tasks() function. The
* DRV_USBHS_Tasks takes the driver module object returned by the
* DRV_USBHS_Initialize funciton as a parameter. */
DRV_USBHS_Tasks(usbDriverObj);
}
void __ISR( _USB_VECTOR , IPL4AUTO)_IntHandler_USB_stub ( void )
{
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1239
/* The DRV_USBHS_Tasks_ISR function updates the interrupt state of the USB
* Driver. If the driver is configured for polling mode, this function need
* not be invoked or included in the project. */
DRV_USBHS_Tasks_ISR(usbDriverObj);
}
void __ISR ( _USB_DMA_VECTOR, IPL4AUTO) _IntHandlerUSBInstance0_USBDMA ( void )
{
/* The DRV_USBHS_Tasks_ISR_USBDMA function update the DMA transfer state of
* the USB Driver. */
DRV_USBHS_Tasks_ISR_USBDMA(usbDriverObj);
}
The PIC32MX USB Driver requires definition of configuration constants to be available in the system_config.h file of the MPLAB Harmony
Application Project Configuration. Refer to the Configuring the Library section for details.
Multi-client Operation
The PIC32MZ USB Driver supports multi-client operation. In that, it can be opened by two application clients. This is required where Dual
Operation is desired. The following should be noted when using multi-client operation:
• The driver should be initialized for Dual Role Operation mode.
• The DRV_USBHS_Open function can be called at the most twice in the application. The driver supports a maximum of two clients.
• A client can access either the host or device functionality of the driver. It cannot do both.
• It is possible for the two clients to operate in two different threads while operating with an RTOS.
Note:
The typical the application clients for PIC32MZ USB Driver would be the MPLAB Harmony USB Host and Device Stack. The
complexity of operating the driver in Dual Role mode is handled by the stack operation. The MHC will configure the driver for Dual
Role operation when such operation is selected in USB Stack configuration tree.
USB Driver Common Interface
The PIC32MZ USB Driver exports its implementation of the USB Driver Common Interface to the Host and Device Layer via the
DRV_USBHS_HOST_INTERFACE and DRV_USBHS_DEVICE_INTERFACE structures. The DRV_USBHS_HOST_INTERFACE structure is
defined in the drv_usbhs_host.c file. The following code example shows this structure.
/**********************************************************
* This structure is a set of pointer to the USBHS driver
* functions. It is provided to the host and device layer
* as the interface to the driver.
* *******************************************************/
DRV_USB_HOST_INTERFACE gDrvUSBHSHostInterface =
{
.open = DRV_USBHS_Open,
.close = DRV_USBHS_Close,
.eventHandlerSet = DRV_USBHS_ClientEventCallBackSet,
.hostIRPSubmit = DRV_USBHS_HOST_IRPSubmit,
.hostIRPCancel = DRV_USBHS_HOST_IRPCancel,
.hostPipeSetup = DRV_USBHS_HOST_PipeSetup,
.hostPipeClose = DRV_USBHS_HOST_PipeClose,
.hostEventsDisable = DRV_USBHS_HOST_EventsDisable,
.hostEventsEnable = DRV_USBHS_HOST_EventsEnable,
.rootHubInterface.rootHubPortInterface.hubPortReset = DRV_USBHS_HOST_ROOT_HUB_PortReset,
.rootHubInterface.rootHubPortInterface.hubPortSpeedGet = DRV_USBHS_HOST_ROOT_HUB_PortSpeedGet,
.rootHubInterface.rootHubPortInterface.hubPortResetIsComplete =
DRV_USBHS_HOST_ROOT_HUB_PortResetIsComplete,
.rootHubInterface.rootHubPortInterface.hubPortSuspend = DRV_USBHS_HOST_ROOT_HUB_PortSuspend,
.rootHubInterface.rootHubPortInterface.hubPortResume = DRV_USBHS_HOST_ROOT_HUB_PortResume,
.rootHubInterface.rootHubMaxCurrentGet = DRV_USBHS_HOST_ROOT_HUB_MaximumCurrentGet,
.rootHubInterface.rootHubPortNumbersGet = DRV_USBHS_HOST_ROOT_HUB_PortNumbersGet,
.rootHubInterface.rootHubSpeedGet = DRV_USBHS_HOST_ROOT_HUB_BusSpeedGet,
.rootHubInterface.rootHubInitialize = DRV_USBHS_HOST_ROOT_HUB_Initialize,
.rootHubInterface.rootHubOperationEnable = DRV_USBHS_HOST_ROOT_HUB_OperationEnable,
.rootHubInterface.rootHubOperationIsEnabled = DRV_USBHS_HOST_ROOT_HUB_OperationIsEnabled,
};
The DRV_USBFS_DEVICE_INTERFACE structure is defined in the drv_usbhs_device.c file. The following code example shows this structure.
The MPLAB Harmony USB Host and Device stack perform driver independent access through the function pointers contained in these structures.
/*****************************************************
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1240
* This structure is a pointer to a set of USB Driver
* Device mode functions. This set is exported to the
* device layer when the device layer must use the
* PIC32MZ USB Controller.
******************************************************/
DRV_USB_DEVICE_INTERFACE gDrvUSBHSDeviceInterface =
{
.open = DRV_USBHS_Open,
.close = DRV_USBHS_Close,
.eventHandlerSet = DRV_USBHS_ClientEventCallBackSet,
.deviceAddressSet = DRV_USBHS_DEVICE_AddressSet,
.deviceCurrentSpeedGet = DRV_USBHS_DEVICE_CurrentSpeedGet,
.deviceSOFNumberGet = DRV_USBHS_DEVICE_SOFNumberGet,
.deviceAttach = DRV_USBHS_DEVICE_Attach,
.deviceDetach = DRV_USBHS_DEVICE_Detach,
.deviceEndpointEnable = DRV_USBHS_DEVICE_EndpointEnable,
.deviceEndpointDisable = DRV_USBHS_DEVICE_EndpointDisable,
.deviceEndpointStall = DRV_USBHS_DEVICE_EndpointStall,
.deviceEndpointStallClear = DRV_USBHS_DEVICE_EndpointStallClear,
.deviceEndpointIsEnabled = DRV_USBHS_DEVICE_EndpointIsEnabled,
.deviceEndpointIsStalled = DRV_USBHS_DEVICE_EndpointIsStalled,
.deviceIRPSubmit = DRV_USBHS_DEVICE_IRPSubmit,
.deviceIRPCancelAll = DRV_USBHS_DEVICE_IRPCancelAll,
.deviceRemoteWakeupStop = DRV_USBHS_DEVICE_RemoteWakeupStop,
.deviceRemoteWakeupStart = DRV_USBHS_DEVICE_RemoteWakeupStart,
.deviceTestModeEnter = DRV_USBHS_DEVICE_TestModeEnter
};
Operation with RTOS
The PIC32MZ USB Driver is designed to operate with a RTOS. The driver implementation uses the MPLAB Harmony Operating System
Abstraction Layer (OSAL). This allows the driver to function with entire range of RTOSes supported in MPLAB Harmony. The following points must
be considered while using the driver with an RTOS.
• The driver can be opened from different threads
• In Device mode, an enabled endpoint should only be accessed from one thread. For example, if an application requires two endpoints,
Endpoint 2 and Endpoint 3, the application could contain two threads, one accessing Endpoint 2 and another accessing Endpoint 3. The thread
accessing Endpoint 2 cannot access Endpoint 3.
• While operating in Host mode, endpoint pipes can be opened from different threads. A pipe handle to an open pipe cannot be shared across
threads.
USB DMA Operation
The PIC32MZ USB module features a built-in DMA controller. This controller works independently of the PIC32MZ DMA controller. The PIC32MZ
USB Driver uses USB DMA controller to expedite transfer of memory from the USB module FIFO to user application memory. The following should
be noted for the USB DMA controller:
• If the PIC32MZ USB Driver could not allocate a DMA channel (all channels are busy), it will use the CPU instructions to unload the endpoint
FIFOs
• The USB module and the USB DMA controller interrupt priorities should be the same
• The application buffer start address should always be aligned on a 16-byte boundary and should be placed in coherent memory. Refer to the
description of the DRV_USBHS_HOST_IRPSubmit and DRV_USBHS_DEVICE_IRPSubmit functions for details on how the user application
buffer should be allocated.
Root Hub Operation
The PIC32MZ USB Driver implements a Root Hub Driver Interface. This allows the driver to emulate a hub. The USB Host Stack enumerates the
Root Hub as a device. The Host Stack then does not differentiate between an external hub and the root hub. While emulating a hub, the PIC32MZ
USB Driver Root Hub appears as a single port hub.
As a part of the Root Hub interface, the PIC32MZ USB Driver requires the application to supply functions for hub features that it does not
implement. These features are:
• Port Overcurrent Detect
• VBUS Switch Control
• Port Indication
A pointer to these functions (if implemented) must be supplied through the driver initialization data (of the type DRV_USBHS_INIT) structure at the
time of driver initialization. The application has the option of not implementing these functions. In such a case, the function pointers for the
unimplemented function, in the initialization data structure should be set to NULL.
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1241
The root hub driver must also be able to communicate the maximum current capability of its port to the USB Host Layer. The PIC32MZ USB
Controller does not contain built-in (hardware implemented) functionality for controlling the root hub port current. To facilitate this request, the
driver will report the current capability that was specified in the rootHubAvailableCurrent parameter of the driver initialization data structure.
The application must set this parameter to report the current supply capability of the VBUS power supply. The USB Host Layer uses this value to
manage the bus current budget. If a connected device reports a configuration that requires more current than what the VBUS power supply can
provide, the host will not set the configuration.
Port Overcurrent Detect
The Root Hub operation in PIC32MZ USB Driver will periodically call a Port Overcurrent Detect function to detect if an overcurrent condition is
active on the port. The application must supply this function if port overcurrent detection is needed. The PIC32MZ USB Controller does not contain
built-in (hardware implemented) functionality for checking overcurrent condition. The overcurrent condition on the port can occur in a case where
the attached device has malfunctioned or when the USB VBUS line has short circuited to ground.
The signature of the function and an example implementation is shown in the following code example. The function must return (and must continue
to return) true if an overcurrent condition exists on the port.
/* This code shows an example implementation of the
* portOverCurrentDetect function. The PIC32MZ USB Driver will call this
* function periodically to check if an over current condition exists on the
* port. In this example, we assume that the over current detect pin from an
* external circuit in the system, is connected to port RD0 and the pin logic
* is active high. The function must return true if an over current condition is
* present on this pin */
bool BSP_USBVBUSSwitchOverCurrentDetect(uint8_t port)
{
if(PLIB_PORTS_PinGet(PORTS_ID_0, PORT_CHANNEL_D, 0) == 1)
{
return(true);
}
else
{
return(false);
}
}
VBUS Switch Control
The PIC32MZ USB Driver Root Hub operation will attempt to control the VBUS power supply to the port. Because the PIC32MZ USB Controller
does not contain built-in (hardware implemented) functionality for checking controlling VBUS, such a control function must be supplied by the
application. The root hub operation will access this function when the PIC32MX USB Driver will call the portPowerEnable function as a part of the
Bus Enable sequence.
The following code shows an example of how this function can be implemented.
/* This code shows an example implementation of the VBUS Power Enable
* function. The PIC32MZ USB Driver will call this function as a part of bus
* enable function. In this example, it is assumed that system contains an
* external VBUS power switch and this is control by port RB5.
*/
void BSP_USBVBUSPowerEnable(uint8_t port, bool enable)
{
if(enable)
{
PLIB_PORTS_PinSet(PORTS_ID_0, PORT_CHANNEL_B, PORTS_BIT_POS_5);
}
else
{
PLIB_PORTS_PinClear(PORTS_ID_0, PORT_CHANNEL_B, PORTS_BIT_POS_5);
}
}
Port Indication Function
The Root Hub Operation in the PIC32MZ USB Driver allows display of Port LED status. If the application requires this indication, it must implement
a function which the Root Hub operation would call when a change in the Root Hub port has occurred. The port indication operation is specified in
Section 11.5.3 of the USB 2.0 Specification.
/* This code shows an example implementation of the port indication
* function. The PIC32MZ USB Driver call this function when it wants to indicate
* port status. It is assumed that three function to switch off, blink and
* switch on an LED are available. It is further assumed that these function
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1242
* accept the color of the LED to operated on. */
void BSP_RootHubPortIndication
(
uint8_t port,
USB_HUB_PORT_INDICATOR_COLOR color,
USB_HUB_PORT_INDICATOR_STATE state
)
{
/* The color parameter indicates the color of the LED to be affected. The
* color will be either USB_HUB_PORT_INDICATOR_COLOR_GREEN or
* USB_HUB_PORT_INDICATOR_COLOR_AMBER. */
switch (state)
{
case USB_HUB_PORT_INDICATOR_STATE_OFF:
BSP_SwitchLEDOff(color);
break;
case USB_HUB_PORT_INDICATOR_STATE_BLINKING:
BSP_LEDBlink(color);
break;
case USB_HUB_PORT_INDICATOR_STATE_ON:
BSP_SwitchLEDOn(color);
break;
default:
break;
}
}
Configuring the Library
Provides information on the configuring the library.
Macros
Name Description
DRV_USBHS_DEVICE_SUPPORT Determines if the USB Device Functionality should be enabled.
DRV_USBHS_ENDPOINTS_NUMBER Configures the number of endpoints to be provisioned in the driver.
DRV_USBHS_HOST_ATTACH_DEBOUNCE_DURATION Configures the time duration (in milliseconds) that the driver will wait to
reconfirm a device attach.
DRV_USBHS_HOST_NAK_LIMIT Configures the NAK Limit for Host Mode Control Transfers.
DRV_USBHS_HOST_PIPES_NUMBER Configures the maximum number of pipes that are can be opened
when the driver is operating in Host mode.
DRV_USBHS_HOST_RESET_DURATION Configures the time duration (in milliseconds) of the Reset Signal.
DRV_USBHS_HOST_SUPPORT Determines if the USB Host Functionality should be enabled.
DRV_USBHS_INSTANCES_NUMBER Specifies the number of driver instances to be enabled in the
application.
DRV_USBHS_INTERRUPT_MODE Configures the driver for interrupt or polling mode operation.
Description
The PIC32MZ USB Driver requires the specification of compile-time configuration macros. These macros define resource usage, feature
availability, and dynamic behavior of the driver. These configuration macros should be defined in the system_config.h file.
This header can be placed anywhere, the path of this header needs to be present in the include search path for a successful build. Refer to the
Applications Help section for more details.
DRV_USBHS_DEVICE_SUPPORT Macro
Determines if the USB Device Functionality should be enabled.
File
drv_usbhs_config_template.h
C
#define DRV_USBHS_DEVICE_SUPPORT true
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1243
Description
Hi-Speed USB Driver Device Mode Support.
This constant should be set to true if USB device support is required in the application. It should be set to false if device support is not required.
Remarks
This constant should always be defined.
DRV_USBHS_ENDPOINTS_NUMBER Macro
Configures the number of endpoints to be provisioned in the driver.
File
drv_usbhs_config_template.h
C
#define DRV_USBHS_ENDPOINTS_NUMBER 3
Description
Hi-Speed USB Driver Endpoint Numbers.
This constant configures the number of endpoints that the driver needs to manage. When DRV_USBHS_DEVICE_SUPPORT is enabled, this
constant should be set to the total number of endpoints to be enabled in the device. When enabled, an endpoint can be used for communication.
Using any direction of an endpoint will require that the entire endpoint to be enabled.
Consider the case of a composite USB Device that contains a CDC and MSD function. The CDC function will require one Bulk endpoint (OUT and
IN directions) and one Interrupt endpoint (IN direction). The MSD function will require one Bulk endpoint (IN and OUT directions). This design can
be implemented by using four endpoints. Endpoint 0 is used for the mandatory control interface. Endpoint 1 is used for CDC Bulk interface.
Endpoint 2 is used for CDC Interrupt interface and Endpoint 3 is used for MSD Bulk Interface. The constant should then be set to 4.
For Host mode operation, this constant should be set to 1. Setting this value to greater than 1 will result in unused data memory allocation.
Remarks
This constant should always be defined.
DRV_USBHS_HOST_ATTACH_DEBOUNCE_DURATION Macro
Configures the time duration (in milliseconds) that the driver will wait to reconfirm a device attach.
File
drv_usbhs_config_template.h
C
#define DRV_USBHS_HOST_ATTACH_DEBOUNCE_DURATION 500
Description
Hi-Speed USB Driver Host Mode Attach Debounce Duration.
This constant configures the time duration (in milliseconds) that the driver will wait to reconfirm a device attach. When the driver first detects a
device attach, it will start a timer for the duration specified by the constant. When the timer expires, the driver will check if the device is still
attached. If so, the driver will then signal an attach event to the host stack. The duration allows for the device attach to become
electro-mechanically stable.
Remarks
This constant should always be defined when DRV_USBHS_HOST_SUPPORT is set to true.
DRV_USBHS_HOST_NAK_LIMIT Macro
Configures the NAK Limit for Host Mode Control Transfers.
File
drv_usbhs_config_template.h
C
#define DRV_USBHS_HOST_NAK_LIMIT 2000
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1244
Description
Hi-Speed USB Driver Host Mode Control Transfers NAK Limit.
This constant configures the number of NAKs that the driver can accept from the device in the data stage of a control transfer before aborting the
control transfer with a USB_HOST_IRP_STATUS_ERROR_NAK_TIMEOUT. Setting this constant to 0 will disable NAK limit checking. This
constant should be adjusted to enable USB host compatibility with USB Devices that require more time to process control transfers.
Remarks
This constant should always be defined when DRV_USBHS_HOST_SUPPORT is set to true.
DRV_USBHS_HOST_PIPES_NUMBER Macro
Configures the maximum number of pipes that are can be opened when the driver is operating in Host mode.
File
drv_usbhs_config_template.h
C
#define DRV_USBHS_HOST_PIPES_NUMBER 10
Description
Hi-Speed USB Driver Host Mode Pipes Number.
This constant configures the maximum number of pipes that can be opened when the driver is operating in Host mode. Calling the
DRV_USBHS_HOST_PipeSetup function will cause a pipe to be opened. Calling this function when DRV_USBHS_HOST_PIPES_NUMBER
number of pipes have already been opened will cause the function to return an Invalid Pipe Handle. This constant should be configured to account
for the maximum number of devices and the device types to be supported by the host application.
For example, if the USB Host application must support two USB Mass Storage devices and one CDC device. A CDC device requires four pipes
and a Mass Storage Device requires three pipes. This constant should therefore be set to a value of 9 ( four bulk pipes for two Mass Storage
devices + two bulk pipes and one Interrupt pipe for one CDC device and two control pipes for two devices). Allocating pipes consumes data
memory.
While enabling support for multiple devices, through a Hub, the application should consider the worst case requirement while configuring this
constant. For example, a case where devices with the most number of pipe requirements are connected to the hub. At the same time, setting this
constant to more than what is required will consume data memory.
Remarks
This constant should always be defined when DRV_USBHS_HOST_SUPPORT is set to true.
DRV_USBHS_HOST_RESET_DURATION Macro
Configures the time duration (in milliseconds) of the Reset Signal.
File
drv_usbhs_config_template.h
C
#define DRV_USBHS_HOST_RESET_DURATION 100
Description
Hi-Speed USB Driver Host Mode Reset Duration.
This constant configures the duration of the reset signal. The driver generates a reset signal when the USB Host stack requests for a root hub port
reset. The driver will generate the reset signal for the duration specified by this constant and will then stop generating the reset signal.
Remarks
This constant should always be defined when DRV_USBHS_HOST_SUPPORT is set to true.
DRV_USBHS_HOST_SUPPORT Macro
Determines if the USB Host Functionality should be enabled.
File
drv_usbhs_config_template.h
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1245
C
#define DRV_USBHS_HOST_SUPPORT false
Description
Hi-Speed USB Driver Host Mode Support.
This constant should be set to true if USB Host mode support is required in the application. It should be set to false if host support is not required.
Remarks
This constant should always be defined.
DRV_USBHS_INSTANCES_NUMBER Macro
Specifies the number of driver instances to be enabled in the application.
File
drv_usbhs_config_template.h
C
#define DRV_USBHS_INSTANCES_NUMBER 1
Description
Hi-Speed USB Driver Instances Number.
This constant defines the number of driver instances to be enabled in the application. This will be typically be the number of USB controllers to be
used in the application. On PIC32MZ microcontrollers that have one USB controller, this value will always be 1. On PIC32MZ microcontrollers that
have two USB controllers, this value could be one or two, depending on whether one or two USB segments are required. To conserve data
memory, this constant should be set to exactly the number of USB controllers that are required in the system.
Remarks
This constant should always be defined.
DRV_USBHS_INTERRUPT_MODE Macro
Configures the driver for interrupt or polling mode operation.
File
drv_usbhs_config_template.h
C
#define DRV_USBHS_INTERRUPT_MODE true
Description
Hi-Speed USB Driver Interrupt Mode.
This constant configures the driver for interrupt or polling operation. If this flag is set to true, the driver will operate in Interrupt mode. If the flag is
set to false, the driver will operate in Polled mode. In Polled mode, the driver interrupt state machine gets updated in the SYS_Tasks function. If
the driver is configured for Interrupt mode, the driver Interrupt state machine gets updated in the driver Interrupt Service Routine(ISR). It is always
recommended for the driver to operate in Interrupt mode.
Remarks
This constant should always be defined.
Building the Library
This section lists the files that are available in the PIC32MZ USB Driver Library.
Description
This section list the files that are available in the \src folder of the PIC32MZ USB Driver. It lists which files need to be included in the build based
on either a hardware feature present on the board or configuration option selected by the system.
The following three tables list and describe the header (.h) and source (.c) files that implement this library. The parent folder for these files is
/framework/driver/usb/usbhs.
Interface File(s)
This table lists and describes the header files that must be included (i.e., using #include) by any code that uses this library.
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1246
Source File Name Description
/drv_usbhs.h This file should be included by any .c file which accesses the PIC32MZ USB Driver API. This one file contains the
prototypes for all driver API.
Required File(s)
All of the required files listed in the following table are automatically added into the MPLAB X IDE project by the MHC
when the library is selected for use.
This table lists and describes the source and header files that must always be included in the MPLAB X IDE project to build this library.
Source File Name Description
/src/dynamic/drv_usbhs.c This file should always be included in the project when using the PIC3MZ USB Driver.
Optional File(s)
This table lists and describes the source and header files that may optionally be included if required for the desired implementation.
Source File Name Description
/src/dynamic/drv_usbhs_device.c This file should be included in the project if Device mode operation is required.
/src/dynamic/drv_usbhs_host.c This file should be included in the project if Host mode operation is required.
Module Dependencies
The PIC32MZ USB Driver Library depends on the following modules:
• Interrupt System Service Library
Library Interface
a) System Functions
Name Description
DRV_USBHS_Initialize Initializes the Hi-Speed USB Driver.
DRV_USBHS_Status Provides the current status of the Hi-Speed USB Driver module.
DRV_USBHS_Tasks Maintains the driver's state machine when the driver is configured for Polled mode.
DRV_USBHS_Tasks_ISR Maintains the driver's Interrupt state machine and implements its ISR.
DRV_USBHS_Tasks_ISR_USBDMA Maintains the driver's DMA Transfer state machine and implements its ISR.
b) Client Core Functions
Name Description
DRV_USBHS_ClientEventCallBackSet This function sets up the event callback function that is invoked by the USB controller
driver to notify the client of USB bus events.
DRV_USBHS_Close Closes an opened-instance of the Hi-Speed USB Driver.
DRV_USBHS_Open Opens the specified Hi-Speed USB Driver instance and returns a handle to it.
c) Device Mode Operation Functions
Name Description
DRV_USBHS_DEVICE_AddressSet This function will set the USB module address that is obtained from the Host.
DRV_USBHS_DEVICE_Attach This function will enable the attach signaling resistors on the D+ and D- lines thus
letting the USB Host know that a device has been attached on the bus.
DRV_USBHS_DEVICE_CurrentSpeedGet This function will return the USB speed at which the device is operating.
DRV_USBHS_DEVICE_Detach This function will disable the attach signaling resistors on the D+ and D- lines thus
letting the USB Host know that the device has detached from the bus.
DRV_USBHS_DEVICE_EndpointDisable This function disables an endpoint.
DRV_USBHS_DEVICE_EndpointDisableAll This function disables all provisioned endpoints.
DRV_USBHS_DEVICE_EndpointEnable This function enables an endpoint for the specified direction and endpoint size.
DRV_USBHS_DEVICE_EndpointIsEnabled This function returns the enable/disable status of the specified endpoint and
direction.
DRV_USBHS_DEVICE_EndpointIsStalled This function returns the stall status of the specified endpoint and direction.
DRV_USBHS_DEVICE_EndpointStall This function stalls an endpoint in the specified direction.
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1247
DRV_USBHS_DEVICE_EndpointStallClear This function clears the stall on an endpoint in the specified direction.
DRV_USBHS_DEVICE_IRPCancel This function cancels the specific IRP that are queued and in progress at the
specified endpoint.
DRV_USBHS_DEVICE_IRPCancelAll This function cancels all IRPs that are queued and in progress at the specified
endpoint.
DRV_USBHS_DEVICE_IRPSubmit This function submits an I/O Request Packet (IRP) for processing to the Hi-Speed
USB Driver.
DRV_USBHS_DEVICE_RemoteWakeupStart This function causes the device to start Remote Wakeup Signalling on the bus.
DRV_USBHS_DEVICE_RemoteWakeupStop This function causes the device to stop the Remote Wakeup Signalling on the bus.
DRV_USBHS_DEVICE_SOFNumberGet This function will return the USB SOF packet number.
DRV_USBHS_DEVICE_TestModeEnter This function enables the specified USB 2.0 Test Mode.
DRV_USBHS_DEVICE_TestModeExit This function disables the specified USB 2.0 Test Mode.
d) Host Mode Operation Functions
Name Description
DRV_USBHS_HOST_EventsDisable Disables Host mode events.
DRV_USBHS_HOST_EventsEnable Restores the events to the specified the original value.
DRV_USBHS_HOST_IRPCancel Cancels the specified IRP.
DRV_USBHS_HOST_IRPSubmit Submits an IRP on a pipe.
DRV_USBHS_HOST_PipeClose Closes an open pipe.
DRV_USBHS_HOST_PipeSetup Open a pipe with the specified attributes.
e) Root Hub Functions
Name Description
DRV_USBHS_HOST_ROOT_HUB_BusSpeedGet This function returns the operating speed of the bus to which this root
hub is connected.
DRV_USBHS_HOST_ROOT_HUB_Initialize This function initializes the root hub driver.
DRV_USBHS_HOST_ROOT_HUB_MaximumCurrentGet Returns the maximum amount of current that this root hub can provide
on the bus.
DRV_USBHS_HOST_ROOT_HUB_OperationEnable This function enables or disables root hub operation.
DRV_USBHS_HOST_ROOT_HUB_OperationIsEnabled Returns the operation enabled status of the root hub.
DRV_USBHS_HOST_ROOT_HUB_PortNumbersGet Returns the number of ports this root hub contains.
DRV_USBHS_HOST_ROOT_HUB_PortReset Resets the specified root hub port.
DRV_USBHS_HOST_ROOT_HUB_PortResetIsComplete Returns true if the root hub has completed the port reset operation.
DRV_USBHS_HOST_ROOT_HUB_PortResume Resumes the specified root hub port.
DRV_USBHS_HOST_ROOT_HUB_PortSpeedGet Returns the speed of at which the port is operating.
DRV_USBHS_HOST_ROOT_HUB_PortSuspend Suspends the specified root hub port.
f) Data Types and Constants
Name Description
DRV_USBHS_EVENT Identifies the different events that the Hi-Speed USB Driver
provides.
DRV_USBHS_EVENT_CALLBACK Type of the Hi-Speed USB Driver event callback function.
DRV_USBHS_HOST_PIPE_HANDLE Defines the Hi-Speed USB Driver Host Pipe Handle type.
DRV_USBHS_INIT This type definition defines the Driver Initialization Data
Structure.
DRV_USBHS_OPMODES Identifies the operating modes supported by the Hi-Speed USB
Driver.
DRV_USBHS_ROOT_HUB_PORT_INDICATION USB Root hub Application Hooks (Port Indication).
DRV_USBHS_ROOT_HUB_PORT_OVER_CURRENT_DETECT USB Root hub Application Hooks (Port Overcurrent detection).
DRV_USBHS_ROOT_HUB_PORT_POWER_ENABLE USB Root hub Application Hooks (Port Power Enable/ Disable).
DRV_USBHS_DEVICE_INTERFACE Hi-Speed USB Driver Device Mode Interface Functions.
DRV_USBHS_HOST_INTERFACE Hi-Speed USB Driver Host Mode Interface Functions.
DRV_USBHS_HOST_PIPE_HANDLE_INVALID Value of an Invalid Host Pipe Handle.
DRV_USBHS_INDEX_0 Hi-Speed USB Driver Module Index 0 Definition.
Description
This section describes the functions of the PIC32MZ USB Driver Library.
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1248
Refer to each section for a detailed description.
a) System Functions
DRV_USBHS_Initialize Function
Initializes the Hi-Speed USB Driver.
File
drv_usbhs.h
C
SYS_MODULE_OBJ DRV_USBHS_Initialize(const SYS_MODULE_INDEX drvIndex, const SYS_MODULE_INIT * const init);
Returns
• SYS_MODULE_OBJ_INVALID - The driver initialization failed.
• A valid System Module Object - The driver initialization was able to start. It may have not completed and requires the DRV_USBHS_Tasks
function to be called periodically. This value will never be the same as SYS_MODULE_OBJ_INVALID.
Description
This function initializes the Hi-Speed USB Driver, making it ready for clients to open. The driver initialization does not complete when this function
returns. The DRV_USBHS_Tasks function must called periodically to complete the driver initialization. The DRV_USBHS_Open function will fail if
the driver was not initialized or if initialization has not completed.
Remarks
This function must be called before any other Hi-Speed USB Driver function is called. This function should only be called once during system
initialization unless DRV_USBHS_Deinitialize is called to deinitialize the driver instance.
Preconditions
None.
Example
// The following code shows an example initialization of the
// driver. The USB module to be used is USB1. The module should not
// automatically suspend when the microcontroller enters Sleep mode. The
// module should continue operation when the module enters Idle mode. The
// power state is set to run at full clock speeds. Device Mode operation
// should be at FULL speed. The size of the endpoint table is set for two
// endpoints.
DRV_USBHS_INIT moduleInit;
usbInitData.usbID = USBHS_ID_0;
usbInitData.opMode = DRV_USBHS_OPMODE_DEVICE;
usbInitData.stopInIdle = false;
usbInitData.suspendInSleep = false;
usbInitData.operationSpeed = USB_SPEED_FULL;
usbInitData.interruptSource = INT_SOURCE_USB;
usbInitData.sysModuleInit.powerState = SYS_MODULE_POWER_RUN_FULL ;
// This is how this data structure is passed to the initialize
// function.
DRV_USBHS_Initialize(DRV_USBHS_INDEX_0, (SYS_MODULE_INIT *) &usbInitData);
Parameters
Parameters Description
drvIndex Ordinal number of driver instance to be initialized. This should be set to
DRV_USBHS_INDEX_0 if driver instance 0 needs to be initialized.
init Pointer to a data structure containing data necessary to initialize the driver. This should be a
DRV_USBHS_INIT structure reference typecast to SYS_MODULE_INIT reference.
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1249
Function
SYS_MODULE_OBJ DRV_USBHS_Initialize
(
const SYS_MODULE_INDEX drvIndex,
const SYS_MODULE_INIT * const init
)
DRV_USBHS_Status Function
Provides the current status of the Hi-Speed USB Driver module.
File
drv_usbhs.h
C
SYS_STATUS DRV_USBHS_Status(SYS_MODULE_OBJ object);
Returns
• SYS_STATUS_READY - Indicates that the driver is ready.
• SYS_STATUS_UNINITIALIZED - Indicates that the driver has never been initialized.
Description
This function provides the current status of the Hi-Speed USB Driver module.
Remarks
None.
Preconditions
The DRV_USBHS_Initialize function must have been called before calling this function.
Example
SYS_MODULE_OBJ object; // Returned from DRV_USBHS_Initialize
SYS_STATUS status;
DRV_USBHS_INIT moduleInit;
usbInitData.usbID = USBHS_ID_0;
usbInitData.opMode = DRV_USBHS_OPMODE_DEVICE;
usbInitData.stopInIdle = false;
usbInitData.suspendInSleep = false;
usbInitData.operationSpeed = USB_SPEED_FULL;
usbInitData.interruptSource = INT_SOURCE_USB;
usbInitData.sysModuleInit.powerState = SYS_MODULE_POWER_RUN_FULL ;
// This is how this data structure is passed to the initialize
// function.
DRV_USBHS_Initialize(DRV_USBHS_INDEX_0, (SYS_MODULE_INIT *) &usbInitData);
// The status of the driver can be checked.
status = DRV_USBHS_Status(object);
if(SYS_STATUS_READY == status)
{
// Driver is ready to be opened.
}
Parameters
Parameters Description
object Driver object handle, returned from the DRV_USBHS_Initialize function.
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1250
Function
SYS_STATUS DRV_USBHS_Status ( SYS_MODULE_OBJ object )
DRV_USBHS_Tasks Function
Maintains the driver's state machine when the driver is configured for Polled mode.
File
drv_usbhs.h
C
void DRV_USBHS_Tasks(SYS_MODULE_OBJ object);
Returns
None.
Description
Maintains the driver's Polled state machine. This function should be called from the SYS_Tasks function.
Remarks
This function is normally not called directly by an application. It is called by the system's Tasks function (SYS_Tasks). This function will never block.
Preconditions
The DRV_USBHS_Initialize function must have been called for the specified Hi-Speed USB Driver instance.
Example
SYS_MODULE_OBJ object; // Returned from DRV_USBHS_Initialize
while (true)
{
DRV_USBHS_Tasks(object);
// Do other tasks
}
Parameters
Parameters Description
object Object handle for the specified driver instance (returned from DRV_USBHS_Initialize function).
Function
void DRV_USBHS_Tasks( SYS_MODULE_OBJ object )
DRV_USBHS_Tasks_ISR Function
Maintains the driver's Interrupt state machine and implements its ISR.
File
drv_usbhs.h
C
void DRV_USBHS_Tasks_ISR(SYS_MODULE_OBJ object);
Returns
None.
Description
This function is used to maintain the driver's internal Interrupt state machine and implement its ISR for interrupt-driven implementations.
Remarks
This function should be called from the USB ISR. For multiple USB modules, it should be ensured that the correct Hi-Speed USB Driver system
module object is passed to this function.
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1251
Preconditions
The DRV_USBHS_Initialize function must have been called for the specified Hi-Speed USB Driver instance.
Example
SYS_MODULE_OBJ object; // Returned from DRV_USBHS_Initialize
while (true)
{
DRV_USBHS_Tasks_ISR (object);
// Do other tasks
}
Parameters
Parameters Description
object Object handle for the specified driver instance (returned from DRV_USBHS_Initialize).
Function
void DRV_USBHS_Tasks_ISR( SYS_MODULE_OBJ object )
DRV_USBHS_Tasks_ISR_USBDMA Function
Maintains the driver's DMA Transfer state machine and implements its ISR.
File
drv_usbhs.h
C
void DRV_USBHS_Tasks_ISR_USBDMA(SYS_MODULE_OBJ object);
Returns
None.
Description
This function is used to maintain the driver's internal DMA Transfer state machine and implement its ISR for interrupt-driven implementations.
Remarks
This function should be called from the USB DMA ISR. For multiple USB modules, it should be ensured that the correct Hi-Speed USB Driver
system module object is passed to this function.
Preconditions
The DRV_USBHS_Initialize function must have been called for the specified Hi-Speed USB Driver instance.
Example
SYS_MODULE_OBJ object; // Returned from DRV_USBHS_Initialize
while (true)
{
DRV_USBHS_Tasks_ISR_USBDMA (object);
// Do other tasks
}
Parameters
Parameters Description
object Object handle for the specified driver instance (returned from DRV_USBHS_Initialize).
Function
void DRV_USBHS_Tasks_ISR_USBDMA( SYS_MODULE_OBJ object )
b) Client Core Functions
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1252
DRV_USBHS_ClientEventCallBackSet Function
This function sets up the event callback function that is invoked by the USB controller driver to notify the client of USB bus events.
File
drv_usbhs.h
C
void DRV_USBHS_ClientEventCallBackSet(DRV_HANDLE handle, uintptr_t hReferenceData, DRV_USB_EVENT_CALLBACK
myEventCallBack);
Returns
None.
Description
This function sets up the event callback function that is invoked by the USB controller driver to notify the client of USB bus events. The callback is
disabled by either not calling this function after the DRV_USBHS_Open function has been called or by setting the myEventCallBack argument as
NULL. When the callback function is called, the hReferenceData argument is returned.
Remarks
Typical usage of the Hi-Speed USB Driver requires a client to register a callback.
Preconditions
None.
Example
// Set the client event callback for the Device Layer. The
// USBDeviceLayerEventHandler function is the event handler. When this
// event handler is invoked by the driver, the driver returns back the
// second argument specified in the following function (which in this case
// is the Device Layer data structure). This allows the application
// firmware to identify, as an example, the Device Layer object associated
// with this callback.
DRV_USBHS_ClientEventCallBackSet(myUSBDevice.usbDriverHandle, (uintptr_t)&myUSBDevice,
USBDeviceLayerEventHandler);
Parameters
Parameters Description
handle Client's driver handle (returned from DRV_USBHS_Open function).
hReferenceData Object (could be a pointer) that is returned with the callback.
myEventCallBack Callback function for all USB events.
Function
void DRV_USBHS_ClientEventCallBackSet
(
DRV_HANDLE handle,
uintptr_t hReferenceData,
DRV_USBHS_EVENT_CALLBACK myEventCallBack
);
DRV_USBHS_Close Function
Closes an opened-instance of the Hi-Speed USB Driver.
File
drv_usbhs.h
C
void DRV_USBHS_Close(DRV_HANDLE handle);
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1253
Returns
None.
Description
This function closes an opened-instance of the Hi-Speed USB Driver, invalidating the handle.
Remarks
After calling this function, the handle passed in handle parameter must not be used with any of the other driver functions. A new handle must be
obtained by calling DRV_USBHS_Open function before the caller may use the driver again.
Preconditions
The DRV_USBHS_Initialize function must have been called for the specified Hi-Speed USB Driver instance. DRV_USBHS_Open function must
have been called to obtain a valid opened device handle.
Example
DRV_HANDLE handle; // Returned from DRV_USBHS_Open
DRV_USBHS_Close(handle);
Parameters
Parameters Description
handle Client's driver handle (returned from DRV_USBHS_Open function).
Function
void DRV_USBHS_Close( DRV_HANDLE handle )
DRV_USBHS_Open Function
Opens the specified Hi-Speed USB Driver instance and returns a handle to it.
File
drv_usbhs.h
C
DRV_HANDLE DRV_USBHS_Open(const SYS_MODULE_INDEX drvIndex, const DRV_IO_INTENT intent);
Returns
• DRV_HANDLE_INVALID - The driver could not be opened successfully.This can
happen if the driver initialization was not complete or if an internal error has occurred.
• A Valid Driver Handle - This is an arbitrary value and is returned if the function was successful. This value will never be the same as
DRV_HANDLE_INVALID.
Description
This function opens the specified Hi-Speed USB Driver instance and provides a handle that must be provided to all other client-level operations to
identify the caller and the instance of the driver. The intent flag should always be
DRV_IO_INTENT_EXCLUSIVE|DRV_IO_INTENT_READWRITE|DRV_IO_INTENT_NON_BLOCKING. Any other setting of the intent flag will
return a invalid driver handle. A driver instance can only support one client. Trying to open a driver that has an existing client will result in an
unsuccessful function call.
Remarks
The handle returned is valid until the DRV_USBHS_Close function is called. The function will typically return DRV_HANDLE_INVALID if the driver
was not initialized. In such a case the client should try to open the driver again.
Preconditions
Function DRV_USBHS_Initialize must have been called before calling this function.
Example
DRV_HANDLE handle;
// This code assumes that the driver has been initialized.
handle = DRV_USBHS_Open(DRV_USBHS_INDEX_0, DRV_IO_INTENT_EXCLUSIVE| DRV_IO_INTENT_READWRITE|
DRV_IO_INTENT_NON_BLOCKING);
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1254
if(DRV_HANDLE_INVALID == handle)
{
// The application should try opening the driver again.
}
Parameters
Parameters Description
drvIndex Identifies the driver instance to be opened. As an example, this value can be set to
DRV_USBHS_INDEX_0 if instance 0 of the driver has to be opened.
intent Should always be (DRV_IO_INTENT_EXCLUSIVE|DRV_IO_INTENT_READWRITE|
DRV_IO_INTENT_NON_BLOCKING).
Function
DRV_HANDLE DRV_USBHS_Open
(
const SYS_MODULE_INDEX drvIndex,
const DRV_IO_INTENT intent
)
c) Device Mode Operation Functions
DRV_USBHS_DEVICE_AddressSet Function
This function will set the USB module address that is obtained from the Host.
File
drv_usbhs.h
C
void DRV_USBHS_DEVICE_AddressSet(DRV_HANDLE handle, uint8_t address);
Returns
None.
Description
This function will set the USB module address that is obtained from the Host in a setup transaction. The address is obtained from the
SET_ADDRESS command issued by the Host. The primary (first) client of the driver uses this function to set the module's USB address after
decoding the setup transaction from the Host.
Remarks
None.
Preconditions
None.
Example
// This function should be called by the first client of the driver,
// which is typically the Device Layer. The address to set is obtained
// from the Host during enumeration.
DRV_USBHS_DEVICE_AddressSet(deviceLayer, 4);
Parameters
Parameters Description
handle Client's driver handle (returned from DRV_USBHS_Open function).
address The address of this module on the USB bus.
Function
void DRV_USBHS_DEVICE_AddressSet( DRV_HANDLE handle, uint8_t address);
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1255
DRV_USBHS_DEVICE_Attach Function
This function will enable the attach signaling resistors on the D+ and D- lines thus letting the USB Host know that a device has been attached on
the bus.
File
drv_usbhs.h
C
void DRV_USBHS_DEVICE_Attach(DRV_HANDLE handle);
Returns
None.
Description
This function enables the pull-up resistors on the D+ or D- lines thus letting the USB Host know that a device has been attached on the bus . This
function should be called when the driver client is ready to receive communication from the Host (typically after all initialization is complete). The
USB 2.0 specification requires VBUS to be detected before the data line pull-ups are enabled. The application must ensure the same.
Remarks
None.
Preconditions
The Client handle should be valid.
Example
// Open the device driver and attach the device to the USB.
handle = DRV_USBHS_Open(DRV_USBHS_INDEX_0, DRV_IO_INTENT_EXCLUSIVE| DRV_IO_INTENT_READWRITE|
DRV_IO_INTENT_NON_BLOCKING);
// Register a callback
DRV_USBHS_ClientEventCallBackSet(handle, (uintptr_t)&myDeviceLayer, MyDeviceLayerEventCallback);
// The device can be attached when VBUS Session Valid event occurs
void MyDeviceLayerEventCallback(uintptr_t handle, DRV_USBHS_EVENT event, void * hReferenceData)
{
switch(event)
{
case DRV_USBHS_EVENT_DEVICE_SESSION_VALID:
// A valid VBUS was detected.
DRV_USBHS_DEVICE_Attach(handle);
break;
case DRV_USBHS_EVENT_DEVICE_SESSION_INVALID:
// VBUS is not valid anymore. The device can be disconnected.
DRV_USBHS_DEVICE_Detach(handle);
break;
default:
break;
}
}
}
Parameters
Parameters Description
handle Client's driver handle (returned from DRV_USBHS_Open function).
Function
void DRV_USBHS_DEVICE_Attach( DRV_HANDLE handle);
DRV_USBHS_DEVICE_CurrentSpeedGet Function
This function will return the USB speed at which the device is operating.
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1256
File
drv_usbhs.h
C
USB_SPEED DRV_USBHS_DEVICE_CurrentSpeedGet(DRV_HANDLE handle);
Returns
Returns a member of the USB_SPEED type.
Description
This function will return the USB speed at which the device is operating.
Remarks
None.
Preconditions
Only valid after the device is attached to the Host and Host has completed reset signaling.
Example
// Get the current speed.
USB_SPEED deviceSpeed;
deviceSpeed = DRV_USBHS_DEVICE_CurrentSpeedGet(deviceLayer);
if(deviceLayer == USB_SPEED_HIGH)
{
// Possibly adjust buffers for higher throughput.
}
Parameters
Parameters Description
handle Client's driver handle (returned from DRV_USBHS_Open function).
Function
USB_SPEED DRV_USBHS_DEVICE_CurrentSpeedGet( DRV_HANDLE handle);
DRV_USBHS_DEVICE_Detach Function
This function will disable the attach signaling resistors on the D+ and D- lines thus letting the USB Host know that the device has detached from
the bus.
File
drv_usbhs.h
C
void DRV_USBHS_DEVICE_Detach(DRV_HANDLE handle);
Returns
None.
Description
This function disables the pull-up resistors on the D+ or D- lines. This function should be called when the application wants to disconnect the
device from the bus (typically to implement a soft detach or switch to Host mode operation). A self-powered device should be detached from the
bus when the VBUS is not valid.
Remarks
None.
Preconditions
The Client handle should be valid.
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1257
Example
// Open the device driver and attach the device to the USB.
handle = DRV_USBHS_Open(DRV_USBHS_INDEX_0, DRV_IO_INTENT_EXCLUSIVE| DRV_IO_INTENT_READWRITE|
DRV_IO_INTENT_NON_BLOCKING);
// Register a callback
DRV_USBHS_ClientEventCallBackSet(handle, (uintptr_t)&myDeviceLayer, MyDeviceLayerEventCallback);
// The device can be detached when VBUS Session Invalid event occurs
void MyDeviceLayerEventCallback(uintptr_t handle, DRV_USBHS_EVENT event, void * hReferenceData)
{
switch(event)
{
case DRV_USBHS_EVENT_DEVICE_SESSION_VALID:
// A valid VBUS was detected.
DRV_USBHS_DEVICE_Attach(handle);
break;
case DRV_USBHS_EVENT_DEVICE_SESSION_INVALID:
// VBUS is not valid anymore. The device can be disconnected.
DRV_USBHS_DEVICE_Detach(handle);
break;
default:
break;
}
}
}
Parameters
Parameters Description
handle Client's driver handle (returned from DRV_USBHS_Open function).
Function
void DRV_USBHS_DEVICE_Detach( DRV_HANDLE handle);
DRV_USBHS_DEVICE_EndpointDisable Function
This function disables an endpoint.
File
drv_usbhs.h
C
USB_ERROR DRV_USBHS_DEVICE_EndpointDisable(DRV_HANDLE handle, USB_ENDPOINT endpointAndDirection);
Returns
• USB_ERROR_NONE - The endpoint was successfully enabled.
• USB_ERROR_DEVICE_ENDPOINT_INVALID - The endpoint that is being accessed is not a valid endpoint (endpoint was not provisioned
through the DRV_USBHS_ENDPOINTS_NUMBER configuration constant) defined for this driver instance.
Description
This function disables an endpoint. If the endpoint type is a control endpoint type, both directions are disabled. For non-control endpoints, the
function disables the specified direction only. The direction to be disabled is specified by the Most Significant Bit (MSB) of the
endpointAndDirection parameter.
Remarks
None.
Preconditions
The Client handle should be valid.
Example
// This code shows an example of how to disable
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1258
// a control endpoint. Note that the direction parameter is ignored.
// For a control endpoint, both the directions are disabled.
USB_ENDPOINT ep;
ep = USB_ENDPOINT_AND_DIRECTION(USB_DATA_DIRECTION_DEVICE_TO_HOST, 0);
DRV_USBHS_DEVICE_EndpointDisable(handle, ep );
// This code shows an example of how to disable a BULK IN
// endpoint
USB_ENDPOINT ep;
ep = USB_ENDPOINT_AND_DIRECTION(USB_DATA_DIRECTION_DEVICE_TO_HOST, 1);
DRV_USBHS_DEVICE_EndpointDisable(handle, ep );
Parameters
Parameters Description
handle Client's driver handle (returned from DRV_USBHS_Open function).
endpointAndDirection Specifies the endpoint and direction.
Function
USB_ERROR DRV_USBHS_DEVICE_EndpointDisable
(
DRV_HANDLE handle,
USB_ENDPOINT endpointAndDirection
)
DRV_USBHS_DEVICE_EndpointDisableAll Function
This function disables all provisioned endpoints.
File
drv_usbhs.h
C
USB_ERROR DRV_USBHS_DEVICE_EndpointDisableAll(DRV_HANDLE handle);
Returns
• USB_ERROR_NONE - The function exited successfully.
• USB_ERROR_PARAMETER_INVALID - The driver handle is invalid.
Description
This function disables all provisioned endpoints in both directions.
Remarks
This function is typically called by the USB Device Layer to disable all endpoints upon detecting a bus reset.
Preconditions
The Client handle should be valid.
Example
// This code shows an example of how to disable all endpoints.
DRV_USBHS_DEVICE_EndpointDisableAll(handle);
Parameters
Parameters Description
handle Client's driver handle (returned from DRV_USBHS_Open function).
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1259
Function
USB_ERROR DRV_USBHS_DEVICE_EndpointDisableAll( DRV_HANDLE handle)
DRV_USBHS_DEVICE_EndpointEnable Function
This function enables an endpoint for the specified direction and endpoint size.
File
drv_usbhs.h
C
USB_ERROR DRV_USBHS_DEVICE_EndpointEnable(DRV_HANDLE handle, USB_ENDPOINT endpointAndDirection,
USB_TRANSFER_TYPE transferType, uint16_t endpointSize);
Returns
• USB_ERROR_NONE - The endpoint was successfully enabled.
• USB_ERROR_DEVICE_ENDPOINT_INVALID - If the endpoint that is being accessed is not a valid endpoint defined for this driver instance.
The value of DRV_USBHS_ENDPOINTS_NUMBER configuration constant should be adjusted.
• USB_ERROR_PARAMETER_INVALID - The driver handle is invalid.
Description
This function enables an endpoint for the specified direction and endpoint size. The function will enable the endpoint for communication in one
direction at a time. It must be called twice if the endpoint is required to communicate in both the directions, with the exception of control endpoints.
If the endpoint type is a control endpoint, the endpoint is always bidirectional and the function needs to be called only once.
The size of the endpoint must match the wMaxPacketSize reported in the endpoint descriptor for this endpoint. A transfer that is scheduled over
this endpoint will be scheduled in wMaxPacketSize transactions. The function does not check if the endpoint is already in use. It is the client's
responsibility to make sure that a endpoint is not accidentally reused.
Remarks
None.
Preconditions
The Client handle should be valid.
Example
// This code shows an example of how to enable Endpoint
// 0 for control transfers. Note that for a control endpoint, the
// direction parameter is ignored. A control endpoint is always
// bidirectional. Endpoint size is 64 bytes.
uint8_t ep;
ep = USB_ENDPOINT_AND_DIRECTION(USB_DATA_DIRECTION_DEVICE_TO_HOST, 0);
DRV_USBHS_DEVICE_EndpointEnable(handle, ep, USB_TRANSFER_TYPE_CONTROL, 64);
// This code shows an example of how to set up a endpoint
// for BULK IN transfer. For an IN transfer, data moves from device
// to Host. In this example, Endpoint 1 is enabled. The maximum
// packet size is 64.
uint8_t ep;
ep = USB_ENDPOINT_AND_DIRECTION(USB_DATA_DIRECTION_DEVICE_TO_HOST, 1);
DRV_USBHS_DEVICE_EndpointEnable(handle, ep, USB_TRANSFER_TYPE_BULK, 64);
// If Endpoint 1 must also be set up for BULK OUT, the
// DRV_USBHS_DEVICE_EndpointEnable function must be called again, as shown
// here.
ep = USB_ENDPOINT_AND_DIRECTION(USB_DATA_DIRECTION_HOST_TO_DEVICE, 1);
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1260
DRV_USBHS_DEVICE_EndpointEnable(handle, ep, USB_TRANSFER_TYPE_BULK, 64);
Parameters
Parameters Description
handle Client's driver handle (returned from DRV_USBHS_Open function).
endpointAndDirection Specifies the endpoint and direction.
transferType Should be USB_TRANSFER_TYPE_CONTROL for control endpoint,
USB_TRANSFER_TYPE_BULK for bulk endpoint, USB_TRANSFER_TYPE_INTERRUPT for
interrupt endpoint and USB_TRANSFER_TYPE_ISOCHRONOUS for isochronous endpoint.
endpointSize Maximum size (in bytes) of the endpoint as reported in the endpoint descriptor.
Function
USB_ERROR DRV_USBHS_DEVICE_EndpointEnable
(
DRV_HANDLE handle,
USB_ENDPOINT endpointAndDirection,
USB_TRANSFER_TYPE transferType,
uint16_t endpointSize
);
DRV_USBHS_DEVICE_EndpointIsEnabled Function
This function returns the enable/disable status of the specified endpoint and direction.
File
drv_usbhs.h
C
bool DRV_USBHS_DEVICE_EndpointIsEnabled(DRV_HANDLE client, USB_ENDPOINT endpointAndDirection);
Returns
• true - The endpoint is enabled.
• false - The endpoint is disabled.
Description
This function returns the enable/disable status of the specified endpoint and direction.
Remarks
None.
Preconditions
The Client handle should be valid.
Example
// This code shows an example of how the
// DRV_USBHS_DEVICE_EndpointIsEnabled function can be used to obtain the
// status of Endpoint 1 and IN direction.
USB_ENDPOINT ep;
ep = USB_ENDPOINT_AND_DIRECTION(USB_DATA_DIRECTION_DEVICE_TO_HOST, 1);
if(DRV_USBHS_ENDPOINT_STATE_DISABLED ==
DRV_USBHS_DEVICE_EndpointIsEnabled(handle, ep))
{
// Endpoint is disabled. Enable endpoint.
DRV_USBHS_DEVICE_EndpointEnable(handle, ep, USB_ENDPOINT_TYPE_BULK, 64);
}
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1261
Parameters
Parameters Description
handle Client's driver handle (returned from DRV_USBHS_Open function).
endpointAndDirection Specifies the endpoint and direction.
Function
bool DRV_USBHS_DEVICE_EndpointIsEnabled
(
DRV_HANDLE handle,
USB_ENDPOINT endpointAndDirection
)
DRV_USBHS_DEVICE_EndpointIsStalled Function
This function returns the stall status of the specified endpoint and direction.
File
drv_usbhs.h
C
bool DRV_USBHS_DEVICE_EndpointIsStalled(DRV_HANDLE client, USB_ENDPOINT endpoint);
Returns
• true - The endpoint is stalled.
• false - The endpoint is not stalled.
Description
This function returns the stall status of the specified endpoint and direction.
Remarks
None.
Preconditions
The Client handle should be valid.
Example
// This code shows an example of how the
// DRV_USBHS_DEVICE_EndpointIsStalled function can be used to obtain the
// stall status of Endpoint 1 and IN direction.
USB_ENDPOINT ep;
ep = USB_ENDPOINT_AND_DIRECTION(USB_DATA_DIRECTION_DEVICE_TO_HOST, 1);
if(true == DRV_USBHS_DEVICE_EndpointIsStalled (handle, ep))
{
// Endpoint stall is enabled. Clear the stall.
DRV_USBHS_DEVICE_EndpointStallClear(handle, ep);
}
Parameters
Parameters Description
handle Client's driver handle (returned from DRV_USBHS_Open function).
endpointAndDirection Specifies the endpoint and direction.
Function
bool DRV_USBHS_DEVICE_EndpointIsStalled
(
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1262
DRV_HANDLE handle,
USB_ENDPOINT endpointAndDirection
)
DRV_USBHS_DEVICE_EndpointStall Function
This function stalls an endpoint in the specified direction.
File
drv_usbhs.h
C
USB_ERROR DRV_USBHS_DEVICE_EndpointStall(DRV_HANDLE handle, USB_ENDPOINT endpointAndDirection);
Returns
• USB_ERROR_NONE - The endpoint was successfully enabled.
• USB_ERROR_PARAMETER_INVALID - The driver handle is not valid.
• USB_ERROR_DEVICE_ENDPOINT_INVALID - If the endpoint that is being accessed is out of the valid endpoint defined for this driver
instance.
• USB_ERROR_OSAL_FUNCTION - An error with an OSAL function called in this function.
Description
This function stalls an endpoint in the specified direction.
Remarks
None.
Preconditions
The Client handle should be valid.
Example
// This code shows an example of how to stall an endpoint. In
// this example, Endpoint 1 IN direction is stalled.
USB_ENDPOINT ep;
ep = USB_ENDPOINT_AND_DIRECTION(USB_DATA_DIRECTION_DEVICE_TO_HOST, 1);
DRV_USBHS_DEVICE_EndpointStall(handle, ep);
Parameters
Parameters Description
handle Client's driver handle (returned from DRV_USBHS_Open function).
endpointAndDirection Specifies the endpoint and direction.
Function
USB_ERROR DRV_USBHS_DEVICE_EndpointStall
(
DRV_HANDLE handle,
USB_ENDPOINT endpointAndDirection
)
DRV_USBHS_DEVICE_EndpointStallClear Function
This function clears the stall on an endpoint in the specified direction.
File
drv_usbhs.h
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1263
C
USB_ERROR DRV_USBHS_DEVICE_EndpointStallClear(DRV_HANDLE handle, USB_ENDPOINT endpointAndDirection);
Returns
• USB_ERROR_NONE - The endpoint was successfully enabled.
• USB_ERROR_PARAMETER_INVALID - The driver handle is not valid.
• USB_ERROR_DEVICE_ENDPOINT_INVALID - If the endpoint that is being accessed is out of the valid endpoint defined for this driver
instance.
Description
This function clears the stall on an endpoint in the specified direction.
Remarks
None.
Preconditions
The Client handle should be valid.
Example
// This code shows an example of how to clear a stall. In this
// example, the stall condition on Endpoint 1 IN direction is cleared.
USB_ENDPOINT ep;
ep = USB_ENDPOINT_AND_DIRECTION(USB_DATA_DIRECTION_DEVICE_TO_HOST, 1);
DRV_USBHS_DEVICE_EndpointStallClear(handle, ep);
Parameters
Parameters Description
handle Client's driver handle (returned from DRV_USBHS_Open function).
endpointAndDirection Specifies the endpoint and direction.
Function
USB_ERROR DRV_USBHS_DEVICE_EndpointStallClear
(
DRV_HANDLE handle,
USB_ENDPOINT endpointAndDirection
)
DRV_USBHS_DEVICE_IRPCancel Function
This function cancels the specific IRP that are queued and in progress at the specified endpoint.
File
drv_usbhs.h
C
USB_ERROR DRV_USBHS_DEVICE_IRPCancel(DRV_HANDLE client, USB_DEVICE_IRP * irp);
Returns
• USB_ERROR_NONE - The IRP have been canceled successfully.
• USB_ERROR_PARAMETER_INVALID - Invalid parameter or the IRP already has been aborted or completed
• USB_ERROR_OSAL_FUNCTION - An OSAL function called in this function did not execute successfully.
Description
This function attempts to cancel the processing of a queued IRP. An IRP that was in the queue but yet to be processed will be cancelled
successfully and the IRP callback function will be called from this function with the USB_DEVICE_IRP_STATUS_ABORTED status. The
application can release the data buffer memory used by the IRP when this callback occurs. If the IRP was in progress (a transaction in on the bus)
when the cancel function was called, the IRP will be canceled only when an ongoing or the next transaction has completed. The IRP callback
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1264
function will then be called in an interrupt context. The application should not release the related data buffer unless the IRP callback has occurred.
Remarks
The size returned after the ABORT callback will be always 0 regardless of the amount of data that has been sent or received. The client should not
assume any data transaction has happened for an canceled IRP. If the last transaction of the IRP was in progress, the IRP cancel does not have
any effect. The first transaction of any ongoing IRP cannot be canceled.
Preconditions
The Client handle should be valid.
Example
// This code shows an example of how to cancel IRP. In this example the IRP
// has been scheduled from a device to the Host.
USB_ENDPOINT ep;
USB_DEVICE_IRP irp;
ep.direction = USB_ENDPOINT_AND_DIRECTION(USB_DATA_DIRECTION_DEVICE_TO_HOST, 1);
irp.data = myDataBufferToSend;
irp.size = 130;
irp.flags = USB_DEVICE_IRP_FLAG_DATA_COMPLETE;
irp.callback = MyIRPCompletionCallback;
irp.referenceData = (uintptr_t)&myDeviceLayerObj;
if (DRV_USBHS_DEVICE_IRPSubmit(handle, ep, &irp) != USB_ERROR_NONE)
{
// This means there was an error.
}
else
{
// Check the status of the IRP.
if(irp.status != USB_DEVICE_IRP_STATUS_COMPLETED)
{
// Cancel the submitted IRP.
if (DRV_USBHS_DEVICE_IRPCancel(handle, &irp) != USB_ERROR_NONE)
{
// The IRP Cancel request submission was successful.
// IRP cancel status will be notified through the callback
// function.
}
else
{
// The IRP may have been completed before IRP cancel operation.
// could start. No callback notification will be generated.
}
}
else
{
// The IRP processing must have been completed before IRP cancel was
// submitted.
}
}
void MyIRPCallback(USB_DEVICE_IRP * irp)
{
// Check if the IRP callback is for a Cancel request
if(irp->status == USB_DEVICE_IRP_STATUS_ABORTED)
{
// IRP cancel completed
}
}
Parameters
Parameters Description
handle Client's driver handle (returned from DRV_USBHS_Open function).
irp Pointer to the IRP to cancel.
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1265
Function
USB_ERROR DRV_USBHS_DEVICE_IRPCancel
(
DRV_HANDLE client,
USB_DEVICE_IRP * irp
)
DRV_USBHS_DEVICE_IRPCancelAll Function
This function cancels all IRPs that are queued and in progress at the specified endpoint.
File
drv_usbhs.h
C
USB_ERROR DRV_USBHS_DEVICE_IRPCancelAll(DRV_HANDLE client, USB_ENDPOINT endpointAndDirection);
Returns
• USB_ERROR_NONE - The endpoint was successfully enabled.
• USB_ERROR_DEVICE_ENDPOINT_INVALID - If the endpoint that is being accessed is out of the valid endpoint defined for this driver
instance.
• USB_ERROR_PARAMETER_INVALID - The driver handle is not valid.
• USB_ERROR_OSAL_FUNCTION - An OSAL function called in this function did not execute successfully.
Description
This function cancels all IRPs that are queued and in progress at the specified endpoint.
Remarks
None.
Preconditions
The Client handle should be valid.
Example
// This code shows an example of how to cancel all IRPs.
void MyIRPCallback(USB_DEVICE_IRP * irp)
{
// Check if this is setup command
if(irp->status == USB_DEVICE_IRP_STATUS_SETUP)
{
if(IsSetupCommandSupported(irp->data) == false)
{
// This means that this setup command is not
// supported. Stall the some related endpoint and cancel all
// queue IRPs.
DRV_USBHS_DEVICE_EndpointStall(handle, ep);
DRV_USBHS_DEVICE_IRPCancelAll(handle, ep);
}
}
}
Parameters
Parameters Description
handle Client's driver handle (returned from DRV_USBHS_Open function).
endpointAndDirection Specifies the endpoint and direction.
Function
USB_ERROR DRV_USBHS_DEVICE_IRPCancelAll
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1266
(
DRV_HANDLE client,
USB_ENDPOINT endpointAndDirection
);
DRV_USBHS_DEVICE_IRPSubmit Function
This function submits an I/O Request Packet (IRP) for processing to the Hi-Speed USB Driver.
File
drv_usbhs.h
C
USB_ERROR DRV_USBHS_DEVICE_IRPSubmit(DRV_HANDLE client, USB_ENDPOINT endpointAndDirection, USB_DEVICE_IRP *
irp);
Returns
• USB_ERROR_NONE - if the IRP was submitted successful.
• USB_ERROR_IRP_SIZE_INVALID - if the size parameter of the IRP is not correct.
• USB_ERROR_PARAMETER_INVALID - If the client handle is not valid.
• USB_ERROR_ENDPOINT_NOT_CONFIGURED - If the endpoint is not enabled.
• USB_ERROR_DEVICE_ENDPOINT_INVALID - The specified endpoint is not valid.
• USB_ERROR_OSAL_FUNCTION - An OSAL call in the function did not complete successfully.
Description
This function submits an I/O Request Packet (IRP) for processing to the USB Driver. The IRP allows a client to send and receive data from the
USB Host. The data will be sent or received through the specified endpoint. The direction of the data transfer is indicated by the direction flag in
the endpointAndDirection parameter. Submitting an IRP arms the endpoint to either send data to or receive data from the Host. If an IRP is already
being processed on the endpoint, the subsequent IRP submit operation will be queued. The contents of the IRP (including the application buffers)
should not be changed until the IRP has been processed.
Particular attention should be paid to the size parameter of IRP. The following should be noted:
• The size parameter while sending data to the Host can be less than, greater than, equal to, or be an exact multiple of the maximum packet size
for the endpoint. The maximum packet size for the endpoint determines the number of transactions required to process the IRP.
• If the size parameter, while sending data to the Host is less than the maximum packet size, the transfer will complete in one transaction.
• If the size parameter, while sending data to the Host is greater than the maximum packet size, the IRP will be processed in multiple
transactions.
• If the size parameter, while sending data to the Host is equal to or an exact multiple of the maximum packet size, the client can optionally ask
the driver to send a Zero Length Packet(ZLP) by specifying the USB_DEVICE_IRP_FLAG_DATA_COMPLETE flag as the flag parameter.
• The size parameter, while receiving data from the Host must be an exact multiple of the maximum packet size of the endpoint. If this is not the
case, the driver will return a USB_ERROR_IRP_SIZE_INVALID result. If while processing the IRP, the driver receives less than maximum
packet size or a ZLP from the Host, the driver considers the IRP as processed. The size parameter at this point contains the actual amount of
data received from the Host. The IRP status is returned as USB_DEVICE_IRP_STATUS_COMPLETED_SHORT.
• If a ZLP needs to be sent to Host, the IRP size should be specified as 0 and the flag parameter should be set as
USB_DEVICE_IRP_FLAG_DATA_COMPLETE.
• If the IRP size is an exact multiple of the endpoint size, the client can request the driver to not send a ZLP by setting the flag parameter to
USB_DEVICE_IRP_FLAG_DATA_PENDING. This flag indicates that there is more data pending in this transfer.
• Specifying a size less than the endpoint size along with the USB_DEVICE_IRP_FLAG_DATA_PENDING flag will cause the driver to return a
USB_ERROR_IRP_SIZE_INVALID.
• If the size is greater than but not a multiple of the endpoint size, and the flag is specified as USB_DEVICE_IRP_FLAG_DATA_PENDING, the
driver will send multiple of endpoint size number of bytes. For example, if the IRP size is 130 and the endpoint size if 64, the number of bytes
sent will 128.
Remarks
This function can be called from the ISR of the USB module to associated with the client.
Preconditions
The Client handle should be valid.
Example
// The following code shows an example of how to schedule a IRP to send data
// from a device to the Host. Assume that the max packet size is 64 and
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1267
// and this data needs to sent over Endpoint 1. In this example, the
// transfer is processed as three transactions of 64, 64 and 2 bytes.
USB_ENDPOINT ep;
USB_DEVICE_IRP irp;
ep.direction = USB_ENDPOINT_AND_DIRECTION(USB_DATA_DIRECTION_DEVICE_TO_HOST, 1);
irp.data = myDataBufferToSend;
irp.size = 130;
irp.flags = USB_DEVICE_IRP_FLAG_DATA_COMPLETE;
irp.callback = MyIRPCompletionCallback;
irp.referenceData = (uintptr_t)&myDeviceLayerObj;
if (DRV_USBHS_DEVICE_IRPSubmit(handle, ep, &irp) != USB_ERROR_NONE)
{
// This means there was an error.
}
else
{
// The status of the IRP can be checked.
while(irp.status != USB_DEVICE_IRP_STATUS_COMPLETED)
{
// Wait or run a task function.
}
}
// The following code shows how the client can request
// the driver to send a ZLP when the size is an exact multiple of
// endpoint size.
irp.data = myDataBufferToSend;
irp.size = 128;
irp.flags = USB_DEVICE_IRP_FLAG_DATA_COMPLETE;
irp.callback = MyIRPCompletionCallback;
irp.referenceData = (uintptr_t)&myDeviceLayerObj;
// Note that while receiving data from the Host, the size should be an
// exact multiple of the maximum packet size of the endpoint. In the
// following example, the DRV_USBHS_DEVICE_IRPSubmit function will return a
// USB_DEVICE_IRP_SIZE_INVALID value.
ep = USB_ENDPOINT_AND_DIRECTION(USB_DATA_DIRECTION_HOST_TO_DEVICE, 1);
irp.data = myDataBufferToSend;
irp.size = 60; // THIS SIZE IS NOT CORRECT
irp.flags = USB_DEVICE_IRP_FLAG_DATA_COMPLETE;
irp.callback = MyIRPCompletionCallback;
irp.referenceData = (uintptr_t)&myDeviceLayerObj;
Parameters
Parameters Description
handle Client's driver handle (returned from DRV_USBHS_Open function).
endpointAndDirection Specifies the endpoint and direction.
irp Pointer to the IRP to be added to the queue for processing.
Function
USB_ERROR DRV_USBHS_DEVICE_IRPSubmit
(
DRV_HANDLE client,
USB_ENDPOINT endpointAndDirection,
USB_DEVICE_IRP * irp
);
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1268
DRV_USBHS_DEVICE_RemoteWakeupStart Function
This function causes the device to start Remote Wakeup Signalling on the bus.
File
drv_usbhs.h
C
void DRV_USBHS_DEVICE_RemoteWakeupStart(DRV_HANDLE handle);
Returns
None.
Description
This function causes the device to start Remote Wakeup Signalling on the bus. This function should be called when the device, presently placed in
suspend mode by the Host, wants to be wakeup. Note that the device can do this only when the Host has enabled the device's Remote Wakeup
capability.
Remarks
None.
Preconditions
The handle should be valid.
Example
DRV_HANDLE handle;
// If the Host has enabled the Remote Wakeup capability, and if the device
// is in suspend mode, then start Remote Wakeup signaling.
if(deviceIsSuspended && deviceRemoteWakeupEnabled)
{
DRV_USBHS_DEVICE_RemoteWakeupStart(handle);
}
Parameters
Parameters Description
handle Handle to the driver (returned from DRV_USBHS_Open function).
Function
void DRV_USBHS_DEVICE_RemoteWakeupStart( DRV_HANDLE handle);
DRV_USBHS_DEVICE_RemoteWakeupStop Function
This function causes the device to stop the Remote Wakeup Signalling on the bus.
File
drv_usbhs.h
C
void DRV_USBHS_DEVICE_RemoteWakeupStop(DRV_HANDLE handle);
Returns
None.
Description
This function causes the device to stop Remote Wakeup Signalling on the bus. This function should be called after the
DRV_USBHS_DEVICE_RemoteWakeupStart function was called to start the Remote Wakeup signaling on the bus.
Remarks
This function should be 1 to 15 milliseconds after the DRV_USBHS_DEVICE_RemoteWakeupStart function was called.
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1269
Preconditions
The handle should be valid. The DRV_USBHS_DEVICE_RemoteWakeupStart function was called to start the Remote Wakeup signaling on the
bus.
Example
DRV_HANDLE handle;
// If the Host has enabled the Remote Wakeup capability, and if the device
// is in suspend mode, then start Remote Wakeup signaling. Wait for 10
// milliseconds and then stop the Remote Wakeup signaling
if(deviceIsSuspended && deviceRemoteWakeupEnabled)
{
DRV_USBHS_DEVICE_RemoteWakeupStart(handle);
DelayMilliSeconds(10);
DRV_USBHS_DEVICE_RemoteWakeupStop(handle);
}
Parameters
Parameters Description
handle Handle to the driver (returned from DRV_USBHS_Open function).
Function
void DRV_USBHS_DEVICE_RemoteWakeupStop( DRV_HANDLE handle);
DRV_USBHS_DEVICE_SOFNumberGet Function
This function will return the USB SOF packet number.
File
drv_usbhs.h
C
uint16_t DRV_USBHS_DEVICE_SOFNumberGet(DRV_HANDLE handle);
Returns
The SOF packet number.
Description
This function will return the USB SOF packet number..
Remarks
None.
Preconditions
This function will return a valid value only when the device is attached to the bus. The SOF packet count will not increment if the bus is suspended.
Example
// This code shows how the DRV_USBHS_DEVICE_SOFNumberGet function is called
// to read the current SOF number.
DRV_HANDLE handle;
uint16_t sofNumber;
sofNumber = DRV_USBHS_DEVICE_SOFNumberGet(handle);
Parameters
Parameters Description
handle Client's driver handle (returned from DRV_USBHS_Open function).
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1270
Function
uint16_t DRV_USBHS_DEVICE_SOFNumberGet( DRV_HANDLE handle);
DRV_USBHS_DEVICE_TestModeEnter Function
This function enables the specified USB 2.0 Test Mode.
File
drv_usbhs.h
C
USB_ERROR DRV_USBHS_DEVICE_TestModeEnter(DRV_HANDLE handle, USB_TEST_MODE_SELECTORS testMode);
Returns
• USB_ERROR_NONE - The function executed successfully.
• USB_ERROR_PARAMETER_INVALID - The handle or the value of testMode parameter is not valid.
Description
This function causes the device to enter the specified USB 2.0 defined test mode. It is called in response to Set Feature command from the host.
The wValue field of this command specifies the Test Mode to enter. The USB module will perform the action identified by the testMode parameter.
Remarks
This function should be called only when the USB device has attached to the Host at High speed and only in response to the Set Feature
command from the Host.
Preconditions
The handle should be valid.
Example
DRV_HANDLE handle;
// This code shows how the DRV_USBHS_DEVICE_TestModeEnter function is
// called to make the USB device enter the Test_J test mode.
DRV_USBHS_DEVICE_TestModeEnter(handle, USB_TEST_MODE_SELECTOR_TEST_J);
Parameters
Parameters Description
handle Handle to the driver (returned from DRV_USBHS_Open function).
testMode This parameter identifies the USB 2.0 specification test mode (see table 9-7 of the USB 2.0
specification).
Function
USB_ERROR DRV_USBHS_DEVICE_TestModeEnter
(
DRV_HANDLE handle,
USB_TEST_MODE_SELECTORS testMode
);
DRV_USBHS_DEVICE_TestModeExit Function
This function disables the specified USB 2.0 Test Mode.
File
drv_usbhs.h
C
USB_ERROR DRV_USBHS_DEVICE_TestModeExit(DRV_HANDLE handle, USB_TEST_MODE_SELECTORS testMode);
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1271
Returns
• USB_ERROR_NONE - The function executed successfully.
• USB_ERROR_PARAMETER_INVALID - The handle or the value of testMode parameter is not valid.
Description
This function causes the device to stop the specified USB 2.0 defined test mode. This function can be called after calling the
DRV_USBHS_DEVICE_TestModeEnter function to stop the test mode execution.
Remarks
None.
Preconditions
The handle should be valid.
Example
DRV_HANDLE handle;
// This code shows how the DRV_USBHS_DEVICE_TestModeEnter function is
// called to make the USB device enter the Test_J test mode.
DRV_USBHS_DEVICE_TestModeEnter(handle, USB_TEST_MODE_SELECTOR_TEST_J);
// Now the DRV_USBHS_DEVICE_TestModeExit function is called to stop the
// Test_J test mode.
DRV_USBHS_DEVICE_TestModeExit(handle, USB_TEST_MODE_SELECTOR_TEST_J);
Parameters
Parameters Description
handle Handle to the driver (returned from DRV_USBHS_Open function).
testMode This parameter identifies the USB 2.0 specification test mode (see table 9-7 of the USB 2.0
specification).
Function
USB_ERROR DRV_USBHS_DEVICE_TestModeExit
(
DRV_HANDLE handle,
USB_TEST_MODE_SELECTORS testMode
);
d) Host Mode Operation Functions
DRV_USBHS_HOST_EventsDisable Function
Disables Host mode events.
File
drv_usbhs.h
C
bool DRV_USBHS_HOST_EventsDisable(DRV_HANDLE handle);
Returns
• true - Driver event generation was enabled when this function was called.
• false - Driver event generation was not enabled when this function was called.
Description
This function disables the Host mode events. This function is called by the Host Layer when it wants to execute code atomically.
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1272
Remarks
None.
Preconditions
The handle should be valid.
Example
// This code shows how the DRV_USBHS_HOST_EventsDisable and
// DRV_USBHS_HOST_EventsEnable function can be called to disable and enable
// events.
DRV_HANDLE driverHandle;
bool eventsWereEnabled;
// Disable the driver events.
eventsWereEnabled = DRV_USBHS_HOST_EventsDisable(driverHandle);
// Code in this region will not be interrupted by driver events.
// Enable the driver events.
DRV_USBHS_HOST_EventsEnable(driverHandle, eventsWereEnabled);
Parameters
Parameters Description
handle Client's driver handle (returned from DRV_USBHS_Open function).
Function
bool DRV_USBHS_HOST_EventsDisable
(
DRV_HANDLE handle
);
DRV_USBHS_HOST_EventsEnable Function
Restores the events to the specified the original value.
File
drv_usbhs.h
C
void DRV_USBHS_HOST_EventsEnable(DRV_HANDLE handle, bool eventContext);
Returns
None.
Description
This function will restore the enable disable state of the events. The eventRestoreContext parameter should be equal to the value returned by the
DRV_USBHS_HOST_EventsDisable function.
Remarks
None.
Preconditions
The handle should be valid.
Example
// This code shows how the DRV_USBHS_HOST_EventsDisable and
// DRV_USBHS_HOST_EventsEnable function can be called to disable and enable
// events.
DRV_HANDLE driverHandle;
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1273
bool eventsWereEnabled;
// Disable the driver events.
eventsWereEnabled = DRV_USBHS_HOST_EventsDisable(driverHandle);
// Code in this region will not be interrupted by driver events.
// Enable the driver events.
DRV_USBHS_HOST_EventsEnable(driverHandle, eventsWereEnabled);
Parameters
Parameters Description
handle Handle to the driver (returned from DRV_USBHS_Open function).
eventRestoreContext Value returned by the DRV_USBHS_HOST_EventsDisable function.
Function
void DRV_USBHS_HOST_EventsEnable
(
DRV_HANDLE handle
bool eventRestoreContext
);
DRV_USBHS_HOST_IRPCancel Function
Cancels the specified IRP.
File
drv_usbhs.h
C
void DRV_USBHS_HOST_IRPCancel(USB_HOST_IRP * inputIRP);
Returns
None.
Description
This function attempts to cancel the specified IRP. If the IRP is queued and its processing has not started, it will be cancelled successfully. If the
IRP in progress, the ongoing transaction will be allowed to complete.
Remarks
None.
Preconditions
None.
Example
// This code shows how a submitted IRP can be cancelled.
USB_HOST_IRP irp;
USB_ERROR result;
USB_HOST_PIPE_HANDLE controlPipe;
USB_SETUP_PACKET setup;
uint8_t controlTransferData[32];
irp.setup = setup;
irp.data = controlTransferData;
irp.size = 32;
irp.flags = USB_HOST_IRP_FLAG_NONE ;
irp.userData = &someApplicationObject;
irp.callback = IRP_Callback;
DRV_USBHS_HOST_IRPSubmit(controlPipeHandle, &irp);
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1274
// Additional application logic may come here. This logic may decide to
// cancel the submitted IRP.
DRV_USBHS_HOST_IRPCancel(&irp);
Parameters
Parameters Description
inputIRP Pointer to the IRP to cancel.
Function
void DRV_USBHS_HOST_IRPCancel(USB_HOST_IRP * inputIRP);
DRV_USBHS_HOST_IRPSubmit Function
Submits an IRP on a pipe.
File
drv_usbhs.h
C
USB_ERROR DRV_USBHS_HOST_IRPSubmit(DRV_USBHS_HOST_PIPE_HANDLE hPipe, USB_HOST_IRP * pinputIRP);
Returns
• USB_ERROR_NONE - The IRP was submitted successfully.
• USB_ERROR_PARAMETER_INVALID - The pipe handle is not valid.
• USB_ERROR_OSAL_FUNCTION - An error occurred in an OSAL function called in this function.
Description
This function submits an IRP on the specified pipe. The IRP will be added to the queue and will be processed in turn. The data will be transferred
on the bus based on the USB bus scheduling rules. When the IRP has been processed, the callback function specified in the IRP will be called.
The IRP status will be updated to reflect the completion status of the IRP.
Remarks
An IRP can also be submitted in an IRP callback function.
Preconditions
The pipe handle should be valid.
Example
// The following code shows an example of how the host layer populates
// the IRP object and then submits it. IRP_Callback function is called when an
// IRP has completed processing. The status of the IRP at completion can be
// checked in the status flag. The size field of the irp will contain the amount
// of data transferred.
void IRP_Callback(USB_HOST_IRP * irp)
{
// irp is pointing to the IRP for which the callback has occurred. In most
// cases this function will execute in an interrupt context. The application
// should not perform any hardware access or interrupt un-safe operations in
// this function.
switch(irp->status)
{
case USB_HOST_IRP_STATUS_ERROR_UNKNOWN:
// IRP was terminated due to an unknown error
break;
case USB_HOST_IRP_STATUS_ABORTED:
// IRP was terminated by the application
break;
case USB_HOST_IRP_STATUS_ERROR_BUS:
// IRP was terminated due to a bus error
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1275
break;
case USB_HOST_IRP_STATUS_ERROR_DATA:
// IRP was terminated due to data error
break;
case USB_HOST_IRP_STATUS_ERROR_NAK_TIMEOUT:
// IRP was terminated because of a NAK timeout
break;
case USB_HOST_IRP_STATUS_ERROR_STALL:
// IRP was terminated because of a device sent a STALL
break;
case USB_HOST_IRP_STATUS_COMPLETED:
// IRP has been completed
break;
case USB_HOST_IRP_STATUS_COMPLETED_SHORT:
// IRP has been completed but the amount of data processed was less
// than requested.
break;
default:
break;
}
}
// In the following code snippet the a control transfer IRP is submitted to a
// control pipe. The setup parameter of the IRP points to the Setup command of
// the control transfer. The direction of the data stage is specified by the
// Setup packet.
USB_HOST_IRP irp;
USB_ERROR result;
USB_HOST_PIPE_HANDLE controlPipe;
USB_SETUP_PACKET setup;
uint8_t controlTransferData[32];
irp.setup = setup;
irp.data = controlTransferData;
irp.size = 32;
irp.flags = USB_HOST_IRP_FLAG_NONE ;
irp.userData = &someApplicationObject;
irp.callback = IRP_Callback;
result = DRV_USBHS_HOST_IRPSubmit(controlPipeHandle, &irp);
Parameters
Parameters Description
hPipe Handle to the pipe to which the IRP has to be submitted.
pInputIRP Pointer to the IRP.
Function
USB_ERROR DRV_USBHS_HOST_IRPSubmit
(
DRV_USBHS_HOST_PIPE_HANDLE hPipe,
USB_HOST_IRP * pInputIRP
);
DRV_USBHS_HOST_PipeClose Function
Closes an open pipe.
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1276
File
drv_usbhs.h
C
void DRV_USBHS_HOST_PipeClose(DRV_USBHS_HOST_PIPE_HANDLE pipeHandle);
Returns
None.
Description
This function closes an open pipe. Any IRPs scheduled on the pipe will be aborted and IRP callback functions will be called with the status as
DRV_USB_HOST_IRP_STATE_ABORTED. The pipe handle will become invalid and the pipe and will not accept IRPs.
Remarks
None.
Preconditions
The pipe handle should be valid.
Example
// This code shows how an open Host pipe can be closed.
DRV_HANDLE driverHandle;
DRV_USBHS_HOST_PIPE_HANDLE pipeHandle;
// Close the pipe.
DRV_USBHS_HOST_PipeClose(pipeHandle);
Parameters
Parameters Description
pipeHandle Handle to the pipe to close.
Function
void DRV_USBHS_HOST_PipeClose
(
DRV_USBHS_HOST_PIPE_HANDLE pipeHandle
);
DRV_USBHS_HOST_PipeSetup Function
Open a pipe with the specified attributes.
File
drv_usbhs.h
C
DRV_USBHS_HOST_PIPE_HANDLE DRV_USBHS_HOST_PipeSetup(DRV_HANDLE client, uint8_t deviceAddress, USB_ENDPOINT
endpointAndDirection, uint8_t hubAddress, uint8_t hubPort, USB_TRANSFER_TYPE pipeType, uint8_t bInterval,
uint16_t wMaxPacketSize, USB_SPEED speed);
Returns
• DRV_USB_HOST_PIPE_HANDLE_INVALID - The pipe could not be created.
• A valid Pipe Handle - The pipe was created successfully. This is an arbitrary value and will never be the same as
DRV_USB_HOST_PIPE_HANDLE_INVALID.
Description
This function opens a communication pipe between the Host and the device endpoint. The transfer type and other attributes are specified through
the function parameters. The driver does not check for available bus bandwidth, which should be done by the application (the USB Host Layer in
this case)
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1277
Remarks
None.
Preconditions
The driver handle should be valid.
Example
// This code shows how the DRV_USBHS_HOST_PipeSetup function is called for
// create a communication pipe. In this example, Bulk pipe is created
// between the Host and a device. The Device address is 2 and the target
// endpoint on this device is 4 . The direction of the data transfer over
// this pipe is from the Host to the device. The device is connected to Port
// 1 of a Hub, whose USB address is 3. The maximum size of a transaction
// on this pipe is 64 bytes. This is a Bulk Pipe and hence the bInterval
// field is set to 0. The target device is operating at Full Speed.
DRV_HANDLE driverHandle;
DRV_USBHS_HOST_PIPE_HANDLE pipeHandle;
pipeHandle = DRV_USBHS_HOST_PipeSetup(driverHandle, 0x02, 0x14, 0x03, 0x01, USB_TRANSFER_TYPE_BULK, 0, 64,
USB_SPEED_FULL);
if(pipeHandle != DRV_USBHS_HOST_PIPE_HANDLE_INVALID)
{
// The pipe was created successfully.
}
Parameters
Parameters Description
client Handle to the driver (returned from DRV_USBHS_Open function).
deviceAddress USB Address of the device to connect to.
endpoint Endpoint on the device to connect to.
hubAddress Address of the hub to which this device is connected. If not connected to a hub, this value
should be set to 0.
hubPort Port number of the hub to which this device is connected.
pipeType Transfer type of the pipe to open.
bInterval Polling interval for periodic transfers. This should be specified as defined by the USB 2.0
Specification.
wMaxPacketSize This should be set to the endpoint size reported by the device in its configuration descriptors.
This defines the maximum size of the transaction in a transfer on this pipe.
speed The speed of the pipe. This should match the speed at which the device connected to the
Host.
Function
DRV_USBHS_HOST_PIPE_HANDLE DRV_USBHS_HOST_PipeSetup
(
DRV_HANDLE client,
uint8_t deviceAddress,
USB_ENDPOINT endpointAndDirection,
uint8_t hubAddress,
uint8_t hubPort,
USB_TRANSFER_TYPE pipeType,
uint8_t bInterval,
uint16_t wMaxPacketSize,
USB_SPEED speed
);
e) Root Hub Functions
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1278
DRV_USBHS_HOST_ROOT_HUB_BusSpeedGet Function
This function returns the operating speed of the bus to which this root hub is connected.
File
drv_usbhs.h
C
USB_SPEED DRV_USBHS_HOST_ROOT_HUB_BusSpeedGet(DRV_HANDLE handle);
Returns
• USB_SPEED_HIGH - The Root hub is connected to a bus that is operating at High Speed.
• USB_SPEED_FULL - The Root hub is connected to a bus that is operating at Full Speed.
Description
This function returns the operating speed of the bus to which this root hub is connected.
Remarks
None.
Preconditions
None.
Example
// This code shows how the DRV_USBHS_HOST_ROOT_HUB_BusSpeedGet function is
// called to know the operating speed of the bus to which this Root hub is
// connected.
DRV_HANDLE driverHandle;
USB_SPEED speed;
speed = DRV_USBHS_HOST_ROOT_HUB_BusSpeedGet(driverHandle);
Parameters
Parameters Description
handle Handle to the driver (returned from DRV_USBHS_Open function).
Function
USB_SPEED DRV_USBHS_HOST_ROOT_HUB_BusSpeedGet( DRV_HANDLE handle);
DRV_USBHS_HOST_ROOT_HUB_Initialize Function
This function initializes the root hub driver.
File
drv_usbhs.h
C
void DRV_USBHS_HOST_ROOT_HUB_Initialize(DRV_HANDLE handle, USB_HOST_DEVICE_OBJ_HANDLE usbHostDeviceInfo);
Returns
None.
Description
This function initializes the root hub driver. It is called by the Host Layer at the time of processing the root hub devices. The Host Layer assigns a
USB_HOST_DEVICE_INFO reference to this root hub driver. This identifies the relationship between the root hub and the Host Layer.
Remarks
None.
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1279
Preconditions
None.
Example
// This code shows how the USB Host Layer calls the
// DRV_USBHS_HOST_ROOT_HUB_Initialize function. The usbHostDeviceInfo
// parameter is an arbitrary identifier assigned by the USB Host Layer. Its
// interpretation is opaque to the Root hub Driver.
DRV_HANDLE drvHandle;
USB_HOST_DEVICE_OBJ_HANDLE usbHostDeviceInfo = 0x10003000;
DRV_USBHS_HOST_ROOT_HUB_Initialize(drvHandle, usbHostDeviceInfo);
Parameters
Parameters Description
handle Handle to the driver.
usbHostDeviceInfo Reference provided by the Host.
Function
void DRV_USBHS_HOST_ROOT_HUB_Initialize
(
DRV_HANDLE handle,
USB_HOST_DEVICE_OBJ_HANDLE usbHostDeviceInfo,
)
DRV_USBHS_HOST_ROOT_HUB_MaximumCurrentGet Function
Returns the maximum amount of current that this root hub can provide on the bus.
File
drv_usbhs.h
C
uint32_t DRV_USBHS_HOST_ROOT_HUB_MaximumCurrentGet(DRV_HANDLE handle);
Returns
Returns the maximum current (in milliamperes) that the root hub can supply.
Description
This function returns the maximum amount of current that this root hub can provide on the bus.
Remarks
None.
Preconditions
None.
Example
// This code shows how the DRV_USBHS_HOST_ROOT_HUB_MaximumCurrentGet
// function is called to obtain the maximum VBUS current that the Root hub
// can supply.
DRV_HANDLE driverHandle;
uint32_t currentMilliAmperes;
currentMilliAmperes = DRV_USBHS_HOST_ROOT_HUB_MaximumCurrentGet(driverHandle);
Parameters
Parameters Description
handle Handle to the driver (returned from DRV_USBHS_Open function).
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1280
Function
uint32_t DRV_USBHS_HOST_ROOT_HUB_MaximumCurrentGet( DRV_HANDLE);
DRV_USBHS_HOST_ROOT_HUB_OperationEnable Function
This function enables or disables root hub operation.
File
drv_usbhs.h
C
void DRV_USBHS_HOST_ROOT_HUB_OperationEnable(DRV_HANDLE handle, bool enable);
Returns
None.
Description
This function enables or disables root hub operation. When enabled, the root hub will detect devices attached to the port and will request the Host
Layer to enumerate the device. This function is called by the Host Layer when it is ready to receive enumeration requests from the Host. If the
operation is disabled, the root hub will not detect attached devices.
Remarks
None.
Preconditions
None.
Example
// This code shows how the DRV_USBHS_HOST_ROOT_HUB_OperationEnable and the
// DRV_USBHS_HOST_ROOT_HUB_OperationIsEnabled functions are called to enable
// the Root hub operation.
DRV_HANDLE driverHandle;
// Enable Root hub operation.
DRV_USBHS_HOST_ROOT_HUB_OperationEnable(driverHandle);
// Wait till the Root hub operation is enabled.
if(DRV_USBHS_HOST_ROOT_HUB_OperationIsEnabled(driverHandle) == false)
{
// The operation has not completed. Call the
// DRV_USBHS_HOST_ROOT_HUB_OperationIsEnabled function again to check if
// the operation has completed. Note that the DRV_USBHS_Tasks function
// must be allowed to run at periodic intervals to allow the enable
// operation to completed.
}
Parameters
Parameters Description
handle Handle to the driver (returned from DRV_USBHS_Open function).
enable If this is set to true, root hub operation is enabled. If this is set to false, root hub operation is
disabled.
Function
void DRV_USBHS_HOST_ROOT_HUB_OperationEnable
(
DRV_HANDLE handle,
bool enable
);
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1281
DRV_USBHS_HOST_ROOT_HUB_OperationIsEnabled Function
Returns the operation enabled status of the root hub.
File
drv_usbhs.h
C
bool DRV_USBHS_HOST_ROOT_HUB_OperationIsEnabled(DRV_HANDLE handle);
Returns
• true - Root hub operation is enabled.
• false - Root hub operation is not enabled.
Description
This function returns true if the DRV_USBHS_HOST_ROOT_HUB_OperationEnable function has completed enabling the Host.
Remarks
None.
Preconditions
None.
Example
// This code shows how the DRV_USBHS_HOST_ROOT_HUB_OperationEnable and the
// DRV_USBHS_HOST_ROOT_HUB_OperationIsEnabled functions are called to enable
// the Root hub operation.
DRV_HANDLE driverHandle;
// Enable Root hub operation.
DRV_USBHS_HOST_ROOT_HUB_OperationEnable(driverHandle);
// Wait till the Root hub operation is enabled.
if(DRV_USBHS_HOST_ROOT_HUB_OperationIsEnabled(driverHandle) == false)
{
// The operation has not completed. Call the
// DRV_USBHS_HOST_ROOT_HUB_OperationIsEnabled function again to check if
// the operation has completed. Note that the DRV_USBHS_Tasks function
// must be allowed to run at periodic intervals to allow the enable
// operation to completed.
}
Parameters
Parameters Description
handle Handle to the driver (returned from DRV_USBHS_Open function).
Function
bool DRV_USBHS_HOST_ROOT_HUB_OperationIsEnabled( DRV_HANDLE handle);
DRV_USBHS_HOST_ROOT_HUB_PortNumbersGet Function
Returns the number of ports this root hub contains.
File
drv_usbhs.h
C
uint8_t DRV_USBHS_HOST_ROOT_HUB_PortNumbersGet(DRV_HANDLE handle);
Returns
This function will always return 1.
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1282
Description
This function returns the number of ports that this root hub contains.
Remarks
None.
Preconditions
None.
Example
// This code shows how DRV_USBHS_HOST_ROOT_HUB_PortNumbersGet function can
// be called to obtain the number of Root hub ports.
DRV_HANDLE driverHandle;
uint8_t nPorts;
nPorts = DRV_USBHS_HOST_ROOT_HUB_PortNumbersGet(driverHandle);
Parameters
Parameters Description
handle Handle to the driver (returned from DRV_USBHS_Open function).
Function
uint8_t DRV_USBHS_HOST_ROOT_HUB_PortNumbersGet( DRV_HANDLE handle);
DRV_USBHS_HOST_ROOT_HUB_PortReset Function
Resets the specified root hub port.
File
drv_usbhs.h
C
USB_ERROR DRV_USBHS_HOST_ROOT_HUB_PortReset(DRV_HANDLE handle, uint8_t port);
Returns
None.
Description
This function resets the root hub port. The reset duration is defined by DRV_USBHS_ROOT_HUB_RESET_DURATION. The status of the reset
signaling can be checked using the DRV_USBHS_ROOT_HUB_PortResetIsComplete function.
Remarks
The root hub on the PIC32MZ USB controller contains only one port - port 0.
Preconditions
None.
Example
// This code shows how the DRV_USB_HOST_ROOT_HUB_PortReset and the
// DRV_USBHS_ROOT_HUB_PortResetIsComplete functions are called to complete a
// port reset sequence.
DRV_HANDLE driverHandle;
// Reset Port 0.
DRV_USB_HOST_ROOT_HUB_PortReset(driverHandle, 0);
// Check if the Reset operation has completed.
if(DRV_USBHS_ROOT_HUB_PortResetIsComplete(driverHandle, 0) == false)
{
// This means that the Port Reset operation has not completed yet. The
// DRV_USBHS_ROOT_HUB_PortResetIsComplete function should be called
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1283
// again after some time to check the status.
}
Parameters
Parameters Description
handle Handle to the driver (returned from DRV_USBHS_Open function).
port Port to reset.
Function
void DRV_USBHS_ROOT_HUB_PortReset( DRV_HANDLE handle, uint8_t port );
DRV_USBHS_HOST_ROOT_HUB_PortResetIsComplete Function
Returns true if the root hub has completed the port reset operation.
File
drv_usbhs.h
C
bool DRV_USBHS_HOST_ROOT_HUB_PortResetIsComplete(DRV_HANDLE handle, uint8_t port);
Returns
• true - The reset signaling has completed.
• false - The reset signaling has not completed.
Description
This function returns true if the port reset operation has completed. It should be called after the DRV_USB_HOST_ROOT_HUB_PortReset
function to check if the reset operation has completed.
Remarks
The root hub on this particular hardware only contains one port - port 0.
Preconditions
None.
Example
// This code shows how the DRV_USB_HOST_ROOT_HUB_PortReset and the
// DRV_USBHS_ROOT_HUB_PortResetIsComplete functions are called to complete a
// port reset sequence.
DRV_HANDLE driverHandle;
// Reset Port 0.
DRV_USB_HOST_ROOT_HUB_PortReset(driverHandle, 0);
// Check if the Reset operation has completed.
if(DRV_USBHS_ROOT_HUB_PortResetIsComplete(driverHandle, 0) == false)
{
// This means that the Port Reset operation has not completed yet. The
// DRV_USBHS_ROOT_HUB_PortResetIsComplete function should be called
// again after some time to check the status.
}
Parameters
Parameters Description
handle Handle to the driver (returned from DRV_USBHS_Open function).
port Port to check
Function
bool DRV_USBHS_ROOT_HUB_PortResetIsComplete
(
DRV_HANDLE handle,
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1284
uint8_t port
);
DRV_USBHS_HOST_ROOT_HUB_PortResume Function
Resumes the specified root hub port.
File
drv_usbhs.h
C
USB_ERROR DRV_USBHS_HOST_ROOT_HUB_PortResume(DRV_HANDLE handle, uint8_t port);
Returns
• USB_ERROR_NONE - The function executed successfully.
• USB_ERROR_PARAMETER_INVALID - The driver handle is not valid or the port number does not exist.
Description
This function resumes the root hub. The resume duration is defined by DRV_USBHS_ROOT_HUB_RESUME_DURATION. The status of the
resume signaling can be checked using the DRV_USBHS_ROOT_HUB_PortResumeIsComplete function.
Remarks
The root hub on this particular hardware only contains one port - port 0.
Preconditions
None.
Example
// This code shows how the DRV_USBHS_HOST_ROOT_HUB_PortResume function is
// called to resume the specified port.
DRV_HANDLE driverHandle;
// Resume Port 0.
DRV_USBHS_HOST_ROOT_HUB_PortResume(driverHandle, 0);
Parameters
Parameters Description
handle Handle to the driver (returned from DRV_USBHS_Open function).
port Port to resume.
Function
USB_ERROR DRV_USBHS_HOST_ROOT_HUB_PortResume
(
DRV_HANDLE handle,
uint8_t port
);
DRV_USBHS_HOST_ROOT_HUB_PortSpeedGet Function
Returns the speed of at which the port is operating.
File
drv_usbhs.h
C
USB_SPEED DRV_USBHS_HOST_ROOT_HUB_PortSpeedGet(DRV_HANDLE handle, uint8_t port);
Returns
• USB_SPEED_ERROR - This value is returned if the driver handle is not or if the speed information is not available or if the specified port is not
valid.
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1285
• USB_SPEED_HIGH - A High Speed device has been connected to the port.
• USB_SPEED_FULL - A Full Speed device has been connected to the port.
• USB_SPEED_LOW - A Low Speed device has been connected to the port.
Description
This function returns the speed at which the port is operating.
Remarks
The root hub on this particular hardware only contains one port - port 0.
Preconditions
None.
Example
// This code shows how the DRV_USBHS_HOST_ROOT_HUB_PortSpeedGet function is
// called to know the operating speed of the port. This also indicates the
// operating speed of the device connected to this port.
DRV_HANDLE driverHandle;
USB_SPEED speed;
speed = DRV_USBHS_HOST_ROOT_HUB_PortSpeedGet(driverHandle, 0);
Parameters
Parameters Description
handle Handle to the driver (returned from DRV_USBHS_Open function).
port Port number of the port to be analyzed..
Function
USB_SPEED DRV_USBHS_HOST_ROOT_HUB_PortSpeedGet
(
DRV_HANDLE handle,
uint8_t port
);
DRV_USBHS_HOST_ROOT_HUB_PortSuspend Function
Suspends the specified root hub port.
File
drv_usbhs.h
C
USB_ERROR DRV_USBHS_HOST_ROOT_HUB_PortSuspend(DRV_HANDLE handle, uint8_t port);
Returns
• USB_ERROR_NONE - The function executed successfully.
• USB_ERROR_PARAMETER_INVALID - The driver handle is not valid or the port number does not exist.
Description
This function suspends the root hub port.
Remarks
The root hub on this particular hardware only contains one port - port 0.
Preconditions
None.
Example
// This code shows how the DRV_USBHS_HOST_ROOT_HUB_PortSuspend function is
// called to suspend the specified port.
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1286
DRV_HANDLE driverHandle;
// Suspend Port 0.
DRV_USBHS_HOST_ROOT_HUB_PortSuspend(driverHandle, 0);
Parameters
Parameters Description
handle Handle to the driver (returned from DRV_USBHS_Open function).
port Port to suspend.
Function
USB_ERROR DRV_USBHS_ROOT_HUB_PortSuspend( DRV_HANDLE handle, uint8_t port);
f) Data Types and Constants
DRV_USBHS_EVENT Enumeration
Identifies the different events that the Hi-Speed USB Driver provides.
File
drv_usbhs.h
C
typedef enum {
DRV_USBHS_EVENT_ERROR = DRV_USB_EVENT_ERROR,
DRV_USBHS_EVENT_RESET_DETECT = DRV_USB_EVENT_RESET_DETECT,
DRV_USBHS_EVENT_RESUME_DETECT = DRV_USB_EVENT_RESUME_DETECT,
DRV_USBHS_EVENT_IDLE_DETECT = DRV_USB_EVENT_IDLE_DETECT,
DRV_USBHS_EVENT_STALL = DRV_USB_EVENT_STALL,
DRV_USBHS_EVENT_SOF_DETECT = DRV_USB_EVENT_SOF_DETECT,
DRV_USBHS_EVENT_DEVICE_SESSION_VALID = DRV_USB_EVENT_DEVICE_SESSION_VALID,
DRV_USBHS_EVENT_DEVICE_SESSION_INVALID = DRV_USB_EVENT_DEVICE_SESSION_INVALID
} DRV_USBHS_EVENT;
Members
Members Description
DRV_USBHS_EVENT_ERROR =
DRV_USB_EVENT_ERROR
Bus error occurred and was reported
DRV_USBHS_EVENT_RESET_DETECT =
DRV_USB_EVENT_RESET_DETECT
Host has issued a device reset
DRV_USBHS_EVENT_RESUME_DETECT =
DRV_USB_EVENT_RESUME_DETECT
Resume detected while USB in suspend mode
DRV_USBHS_EVENT_IDLE_DETECT =
DRV_USB_EVENT_IDLE_DETECT
Idle detected
DRV_USBHS_EVENT_STALL =
DRV_USB_EVENT_STALL
Stall handshake has occurred
DRV_USBHS_EVENT_SOF_DETECT =
DRV_USB_EVENT_SOF_DETECT
Device received SOF operation
DRV_USBHS_EVENT_DEVICE_SESSION_VALID =
DRV_USB_EVENT_DEVICE_SESSION_VALID
VBUS voltage had Session valid
DRV_USBHS_EVENT_DEVICE_SESSION_INVALID
= DRV_USB_EVENT_DEVICE_SESSION_INVALID
Session Invalid
Description
Hi-Speed USB Driver Events Enumeration.
This enumeration identifies the different events that are generated by the Hi-Speed USB Driver.
Remarks
None.
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1287
DRV_USBHS_EVENT_CALLBACK Type
Type of the Hi-Speed USB Driver event callback function.
File
drv_usbhs.h
C
typedef void (* DRV_USBHS_EVENT_CALLBACK)(uintptr_t hClient, DRV_USBHS_EVENT eventType, void * eventData);
Returns
None.
Description
Type of the Hi-Speed USB Driver Event Callback Function.
Define the type of the Hi-Speed USB Driver event callback function. The client should register an event callback function of this type when it
intends to receive events from the Hi-Speed USB Driver. The event callback function is registered using the
DRV_USBHS_ClientEventCallBackSet function.
Remarks
None.
Parameters
Parameters Description
hClient Handle to the driver client that registered this callback function.
eventType This parameter identifies the event that caused the callback function to be called.
eventData Pointer to a data structure that is related to this event. This value will be NULL if the event has
no related data.
DRV_USBHS_HOST_PIPE_HANDLE Type
Defines the Hi-Speed USB Driver Host Pipe Handle type.
File
drv_usbhs.h
C
typedef uintptr_t DRV_USBHS_HOST_PIPE_HANDLE;
Description
Hi-Speed USB Driver Host Pipe Handle.
This type definition defines the type of the Hi-Speed USB Driver Host Pipe Handle.
Remarks
None.
DRV_USBHS_INIT Structure
This type definition defines the Driver Initialization Data Structure.
File
drv_usbhs.h
C
typedef struct {
SYS_MODULE_INIT moduleInit;
USBHS_MODULE_ID usbID;
bool stopInIdle;
bool suspendInSleep;
INT_SOURCE interruptSource;
INT_SOURCE interruptSourceUSBDma;
USB_SPEED operationSpeed;
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1288
DRV_USBHS_OPMODES operationMode;
void * endpointTable;
uint32_t rootHubAvailableCurrent;
DRV_USBHS_ROOT_HUB_PORT_POWER_ENABLE portPowerEnable;
DRV_USBHS_ROOT_HUB_PORT_INDICATION portIndication;
DRV_USBHS_ROOT_HUB_PORT_OVER_CURRENT_DETECT portOverCurrentDetect;
} DRV_USBHS_INIT;
Members
Members Description
SYS_MODULE_INIT moduleInit; System Module Initialization
USBHS_MODULE_ID usbID; Identifies the USB peripheral to be used. This should be the USB PLIB
module instance identifier.
bool stopInIdle; This should be set to true if the USB module must stop operation in Idle mode
bool suspendInSleep; This should be set to true if the USB module must suspend when the CPU
enters Sleep mode.
INT_SOURCE interruptSource; Specify the interrupt source for the USB module. This should be the interrupt
source for the USB module instance specified in usbID.
INT_SOURCE interruptSourceUSBDma; Specify the interrupt source for the USB module specific DMA controller. This
should be the USB DMA interrupt source for the USB Module instance
specified in usbID.
USB_SPEED operationSpeed; Specify the operational speed of the USB module. This should always be set
to USB_SPEED_FULL.
DRV_USBHS_OPMODES operationMode; Specify the operation mode of the USB module. This specifies if the USB
module should operate as a Device, Host, or both (Dual Role operation).
void * endpointTable; A pointer to the endpoint descriptor table. This should be aligned at 512 byte
address boundary. The size of the table is equal to the
DRV_USBHS_ENDPOINT_TABLE_ENTRY_SIZE times the number of
endpoints needed in the application.
uint32_t rootHubAvailableCurrent; Root hub available current in milliamperes. This specifies the amount of
current that root hub can provide to the attached device. This should be
specified in mA. This is required when the driver is required to operate in Host
mode.
DRV_USBHS_ROOT_HUB_PORT_POWER_ENABLE
portPowerEnable;
When operating in Host mode, the application can specify a Root hub port
enable function. This parameter should point to Root hub port enable function.
If this parameter is NULL, it implies that the port is always enabled.
DRV_USBHS_ROOT_HUB_PORT_INDICATION portIndication; When operating in Host mode, the application can specify a Root Port
Indication. This parameter should point to the Root Port Indication function. If
this parameter is NULL, it implies that Root Port Indication is not supported.
DRV_USBHS_ROOT_HUB_PORT_OVER_CURRENT_DETECT
portOverCurrentDetect;
When operating is Host mode, the application can specify a Root Port
Overcurrent detection. This parameter should point to the Root Port Indication
function. If this parameter is NULL, it implies that Overcurrent detection is not
supported.
Description
USB Device Driver Initialization Data.
This structure contains all the data necessary to initialize the Hi-Speed USB Driver. A pointer to a structure of this type, containing the desired
initialization data, must be passed into the DRV_USBHS_Initialize function.
Remarks
None.
DRV_USBHS_OPMODES Enumeration
Identifies the operating modes supported by the Hi-Speed USB Driver.
File
drv_usbhs.h
C
typedef enum {
DRV_USBHS_OPMODE_DUAL_ROLE = DRV_USB_OPMODE_DUAL_ROLE,
DRV_USBHS_OPMODE_DEVICE = DRV_USB_OPMODE_DEVICE,
DRV_USBHS_OPMODE_HOST = DRV_USB_OPMODE_HOST,
DRV_USBHS_OPMODE_OTG = DRV_USB_OPMODE_OTG
} DRV_USBHS_OPMODES;
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1289
Members
Members Description
DRV_USBHS_OPMODE_DUAL_ROLE =
DRV_USB_OPMODE_DUAL_ROLE
The driver should be able to switch between Host and Device mode
DRV_USBHS_OPMODE_DEVICE =
DRV_USB_OPMODE_DEVICE
The driver should support Device mode operation only
DRV_USBHS_OPMODE_HOST =
DRV_USB_OPMODE_HOST
The driver should support Host mode operation only
DRV_USBHS_OPMODE_OTG =
DRV_USB_OPMODE_OTG
The driver should support the OTG protocol
Description
USB Operating Modes Enumeration.
This enumeration identifies the operating modes supported by the Hi-Speed USB Driver.
Remarks
None.
DRV_USBHS_ROOT_HUB_PORT_INDICATION Type
USB Root hub Application Hooks (Port Indication).
File
drv_usbhs.h
C
typedef void (* DRV_USBHS_ROOT_HUB_PORT_INDICATION)(uint8_t port, USB_HUB_PORT_INDICATOR_COLOR color,
USB_HUB_PORT_INDICATOR_STATE state);
Description
USB Root hub Application Hooks (Port Indication).
A function of the type defined here should be provided to the driver root to implement Port Indication. The root hub driver calls this function when it
needs to update the state of the port indication LEDs. The application can choose to implement the Amber and Green colors as one LED or two
different LEDs. The root hub driver specifies the color and the indicator attribute (on, off or blinking) when it calls this function.
Remarks
None.
DRV_USBHS_ROOT_HUB_PORT_OVER_CURRENT_DETECT Type
USB Root hub Application Hooks (Port Overcurrent detection).
File
drv_usbhs.h
C
typedef bool (* DRV_USBHS_ROOT_HUB_PORT_OVER_CURRENT_DETECT)(uint8_t port);
Description
USB Root hub Application Hooks (Port Overcurrent detection).
A function of the type defined here should be provided to the driver root hub to check for port over current condition. This function will be called
periodically by the root hub driver to check the Overcurrent status of the port. It should continue to return true while the Overcurrent condition
exists on the port. It should return false when the Overcurrent condition does not exist.
Remarks
None.
DRV_USBHS_ROOT_HUB_PORT_POWER_ENABLE Type
USB Root hub Application Hooks (Port Power Enable/ Disable).
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1290
File
drv_usbhs.h
C
typedef void (* DRV_USBHS_ROOT_HUB_PORT_POWER_ENABLE)(uint8_t port, bool control);
Description
USB Root hub Application Hooks (Port Power Enable/ Disable).
A function of the type defined here should be provided to the driver root to control port power. The root hub driver will call this function when it
needs to enable port power. If the application circuit contains a VBUS switch, the switch should be accessed and controlled by this function. If the
enable parameter is true, the switch should be enabled and VBUS should be available on the port. If the enable parameter is false, the switch
should be disabled and VBUS should not be available on the port.
Remarks
None.
DRV_USBHS_DEVICE_INTERFACE Macro
Hi-Speed USB Driver Device Mode Interface Functions.
File
drv_usbhs.h
C
#define DRV_USBHS_DEVICE_INTERFACE
Description
Hi-Speed USB Driver Device Mode Interface Functions.
The Device Controller Driver Interface member of the Device Stack Initialization data structure should be set to this value so that the Device Stack
can access the Hi-Speed USB Driver Device Mode functions.
Remarks
None.
DRV_USBHS_HOST_INTERFACE Macro
Hi-Speed USB Driver Host Mode Interface Functions.
File
drv_usbhs.h
C
#define DRV_USBHS_HOST_INTERFACE
Description
Hi-Speed USB Driver Host Mode Interface Functions.
The Host Controller Driver Interface member of the Host Layer Initialization data structure should be set to this value so that the Host Layer can
access the Hi-Speed USB Driver Host Mode functions.
Remarks
None.
DRV_USBHS_HOST_PIPE_HANDLE_INVALID Macro
Value of an Invalid Host Pipe Handle.
File
drv_usbhs.h
C
#define DRV_USBHS_HOST_PIPE_HANDLE_INVALID
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1291
Description
Hi-Speed USB Driver Invalid Host Pipe Handle.
This constant defines the value of an Invalid Host Pipe Handle.
Remarks
None.
DRV_USBHS_INDEX_0 Macro
Hi-Speed USB Driver Module Index 0 Definition.
File
drv_usbhs.h
C
#define DRV_USBHS_INDEX_0 0
Description
Hi-Speed USB Driver Module Index 0 Definition.
This constant defines the value of Hi-Speed USB Driver Index 0. The SYS_MODULE_INDEX parameter of the DRV_USBHS_Initialize and
DRV_USBHS_Open functions should be set to this value to identify instance 0 of the driver.
Remarks
These constants should be used in place of hard-coded numeric literals and should be passed into the DRV_USBHS_Initialize and
DRV_USBHS_Open functions to identify the driver instance in use. These are not indicative of the number of modules that are actually supported
by the microcontroller.
Files
Files
Name Description
drv_usbhs.h PIC32MZ USB Module Driver Interface File
drv_usbhs_config_template.h Hi-Speed USB (USBHS) Driver Configuration Template.
Description
drv_usbhs.h
PIC32MZ USB Module Driver Interface File
Enumerations
Name Description
DRV_USBHS_EVENT Identifies the different events that the Hi-Speed USB Driver provides.
DRV_USBHS_OPMODES Identifies the operating modes supported by the Hi-Speed USB Driver.
Functions
Name Description
DRV_USBHS_ClientEventCallBackSet This function sets up the event callback function that is invoked by the
USB controller driver to notify the client of USB bus events.
DRV_USBHS_Close Closes an opened-instance of the Hi-Speed USB Driver.
DRV_USBHS_DEVICE_AddressSet This function will set the USB module address that is obtained from the
Host.
DRV_USBHS_DEVICE_Attach This function will enable the attach signaling resistors on the D+ and Dlines
thus letting the USB Host know that a device has been attached
on the bus.
DRV_USBHS_DEVICE_CurrentSpeedGet This function will return the USB speed at which the device is operating.
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1292
DRV_USBHS_DEVICE_Detach This function will disable the attach signaling resistors on the D+ and Dlines
thus letting the USB Host know that the device has detached from
the bus.
DRV_USBHS_DEVICE_EndpointDisable This function disables an endpoint.
DRV_USBHS_DEVICE_EndpointDisableAll This function disables all provisioned endpoints.
DRV_USBHS_DEVICE_EndpointEnable This function enables an endpoint for the specified direction and
endpoint size.
DRV_USBHS_DEVICE_EndpointIsEnabled This function returns the enable/disable status of the specified endpoint
and direction.
DRV_USBHS_DEVICE_EndpointIsStalled This function returns the stall status of the specified endpoint and
direction.
DRV_USBHS_DEVICE_EndpointStall This function stalls an endpoint in the specified direction.
DRV_USBHS_DEVICE_EndpointStallClear This function clears the stall on an endpoint in the specified direction.
DRV_USBHS_DEVICE_IRPCancel This function cancels the specific IRP that are queued and in progress
at the specified endpoint.
DRV_USBHS_DEVICE_IRPCancelAll This function cancels all IRPs that are queued and in progress at the
specified endpoint.
DRV_USBHS_DEVICE_IRPSubmit This function submits an I/O Request Packet (IRP) for processing to the
Hi-Speed USB Driver.
DRV_USBHS_DEVICE_RemoteWakeupStart This function causes the device to start Remote Wakeup Signalling on
the bus.
DRV_USBHS_DEVICE_RemoteWakeupStop This function causes the device to stop the Remote Wakeup Signalling
on the bus.
DRV_USBHS_DEVICE_SOFNumberGet This function will return the USB SOF packet number.
DRV_USBHS_DEVICE_TestModeEnter This function enables the specified USB 2.0 Test Mode.
DRV_USBHS_DEVICE_TestModeExit This function disables the specified USB 2.0 Test Mode.
DRV_USBHS_HOST_EventsDisable Disables Host mode events.
DRV_USBHS_HOST_EventsEnable Restores the events to the specified the original value.
DRV_USBHS_HOST_IRPCancel Cancels the specified IRP.
DRV_USBHS_HOST_IRPSubmit Submits an IRP on a pipe.
DRV_USBHS_HOST_PipeClose Closes an open pipe.
DRV_USBHS_HOST_PipeSetup Open a pipe with the specified attributes.
DRV_USBHS_HOST_ROOT_HUB_BusSpeedGet This function returns the operating speed of the bus to which this root
hub is connected.
DRV_USBHS_HOST_ROOT_HUB_Initialize This function initializes the root hub driver.
DRV_USBHS_HOST_ROOT_HUB_MaximumCurrentGet Returns the maximum amount of current that this root hub can provide
on the bus.
DRV_USBHS_HOST_ROOT_HUB_OperationEnable This function enables or disables root hub operation.
DRV_USBHS_HOST_ROOT_HUB_OperationIsEnabled Returns the operation enabled status of the root hub.
DRV_USBHS_HOST_ROOT_HUB_PortNumbersGet Returns the number of ports this root hub contains.
DRV_USBHS_HOST_ROOT_HUB_PortReset Resets the specified root hub port.
DRV_USBHS_HOST_ROOT_HUB_PortResetIsComplete Returns true if the root hub has completed the port reset operation.
DRV_USBHS_HOST_ROOT_HUB_PortResume Resumes the specified root hub port.
DRV_USBHS_HOST_ROOT_HUB_PortSpeedGet Returns the speed of at which the port is operating.
DRV_USBHS_HOST_ROOT_HUB_PortSuspend Suspends the specified root hub port.
DRV_USBHS_Initialize Initializes the Hi-Speed USB Driver.
DRV_USBHS_Open Opens the specified Hi-Speed USB Driver instance and returns a
handle to it.
DRV_USBHS_Status Provides the current status of the Hi-Speed USB Driver module.
DRV_USBHS_Tasks Maintains the driver's state machine when the driver is configured for
Polled mode.
DRV_USBHS_Tasks_ISR Maintains the driver's Interrupt state machine and implements its ISR.
DRV_USBHS_Tasks_ISR_USBDMA Maintains the driver's DMA Transfer state machine and implements its
ISR.
Macros
Name Description
DRV_USBHS_DEVICE_INTERFACE Hi-Speed USB Driver Device Mode Interface Functions.
DRV_USBHS_HOST_INTERFACE Hi-Speed USB Driver Host Mode Interface Functions.
Volume V: MPLAB Harmony Framework Driver Libraries Help USB Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1293
DRV_USBHS_HOST_PIPE_HANDLE_INVALID Value of an Invalid Host Pipe Handle.
DRV_USBHS_INDEX_0 Hi-Speed USB Driver Module Index 0 Definition.
Structures
Name Description
DRV_USBHS_INIT This type definition defines the Driver Initialization Data Structure.
Types
Name Description
DRV_USBHS_EVENT_CALLBACK Type of the Hi-Speed USB Driver event callback function.
DRV_USBHS_HOST_PIPE_HANDLE Defines the Hi-Speed USB Driver Host Pipe Handle type.
DRV_USBHS_ROOT_HUB_PORT_INDICATION USB Root hub Application Hooks (Port Indication).
DRV_USBHS_ROOT_HUB_PORT_OVER_CURRENT_DETECT USB Root hub Application Hooks (Port Overcurrent detection).
DRV_USBHS_ROOT_HUB_PORT_POWER_ENABLE USB Root hub Application Hooks (Port Power Enable/ Disable).
Description
PIC32MZ USB Module Driver Interface Header File
The PIC32MZ Hi-Speed USB Module driver provides a simple interface to manage the "USB" peripheral on the PIC32MZ microcontroller. This file
defines the interface definitions and prototypes for the Hi-Speed USB Driver. The driver interface meets the requirements of the MPLAB Harmony
USB Host and Device Layer.
File Name
drv_usbhs.h
Company
Microchip Technology Inc.
drv_usbhs_config_template.h
Hi-Speed USB (USBHS) Driver Configuration Template.
Macros
Name Description
DRV_USBHS_DEVICE_SUPPORT Determines if the USB Device Functionality should be enabled.
DRV_USBHS_ENDPOINTS_NUMBER Configures the number of endpoints to be provisioned in the driver.
DRV_USBHS_HOST_ATTACH_DEBOUNCE_DURATION Configures the time duration (in milliseconds) that the driver will wait to
reconfirm a device attach.
DRV_USBHS_HOST_NAK_LIMIT Configures the NAK Limit for Host Mode Control Transfers.
DRV_USBHS_HOST_PIPES_NUMBER Configures the maximum number of pipes that are can be opened
when the driver is operating in Host mode.
DRV_USBHS_HOST_RESET_DURATION Configures the time duration (in milliseconds) of the Reset Signal.
DRV_USBHS_HOST_SUPPORT Determines if the USB Host Functionality should be enabled.
DRV_USBHS_INSTANCES_NUMBER Specifies the number of driver instances to be enabled in the
application.
DRV_USBHS_INTERRUPT_MODE Configures the driver for interrupt or polling mode operation.
Description
Hi-Speed USB Driver Configuration Template
This file lists all the configurations constants that affect the operation of the USBHS Driver.
File Name
drv_usbhs_config_template.h
Company
Microchip Technology Inc.
USART Driver Library
This section describes the USART Driver Library.
Volume V: MPLAB Harmony Framework Driver Libraries Help USART Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1294
Introduction
This section introduces the MPLAB Harmony USART Driver.
Description
The MPLAB Harmony USART Driver (also referred to as the USART Driver) provides a high-level interface to the USART and UART peripherals
on Microchip's PIC32 microcontrollers. This driver provides application ready routines to read and write data to the UART using common data
transfer models, which eliminates the need for the application to implement this code. The USART driver features the following:
• Provides byte transfer, read/write, and buffer queue data transfer models
• Supports Interrupt and Polled modes of operation
• Supports point-to-point data communication
• Supports multi-client and multi-instance operation
• Provides data transfer events
• Supports blocking and non-blocking operation with the read/write data transfer model
• Features thread-safe functions for use in RTOS applications
• Supports DMA transfers
• Supports high baud rate setting
• Major features are implemented in separate source code files and can be included only if needed. This helps optimize overall application code
size.
Using the Library
This topic describes the basic architecture of the USART Driver Library and provides information and examples on its use.
Description
Interface Header File: drv_usart.h
The interface to the USART library is defined in the drv_usart.h header file.
Please refer to the What is MPLAB Harmony? section for how the driver interacts with the framework.
Abstraction Model
This section describes how the USART Driver abstracts the USART peripheral features.
Description
The USART driver features routines to perform the following functions:
• Driver initialization
• Transfer data
• Manage communication properties of the module
The Driver initialization routines allow the system to initialize the driver. The driver must be initialized before it can be opened by a client. The data
transfer routines allow the application to receive and transmit data through the USART. The driver also provides routines to change the
communication properties such as USART baud or line control settings.
Volume V: MPLAB Harmony Framework Driver Libraries Help USART Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1295
As seen in the previous figure, the USART driver clients transfer data through the USART Driver Data Transfer model. The driver abstracts out the
hardware details of the UART module FIFO mechanism and shift registers, and provides a low overhead data transfer mechanism to the
application. The USART driver provides three different data transfer models for transferring data.
• The Byte Transfer Model
• The File I/O Type Read/Write Transfer Model
• Buffer Queue Transfer Model
Byte Transfer Model:
The byte transfer model allows the application to transfer data through USART driver one byte at a time. With this model, the driver reads one byte
from the receive FIFO or writes one byte to the transmit FIFO. The application must check if data has been received before reading the data.
Similarly, it must check if the transmit FIFO is not full before writing to the FIFO. The byte transfer model places the responsibility of maintaining
the USART peripheral on the Application. The driver cannot support other data transfer models if support for this data transfer model is enabled.
The byte transfer model is only recommended for simple data transfer applications.
To use the byte transfer model, the drv_usart_byte_model.c file must be included in the project and the
DRV_USART_BYTE_MODEL_SUPPORT configuration macro should be set to true.
File I/O Type Read/Write Transfer Model:
This data transfer model is similar to file read and write API model in a UNIX operating system application. The application calls the USART driver
read and write routines to transfer data through the USART. Unlike the byte transfer model, the read/write data model can process a block of data.
Depending on the mode (blocking or non-blocking) in which the client opened the driver, the driver will either block until all of the data is
transferred or will immediately return with the number of bytes transferred. The application does not have to check the FIFO status while using this
mode. The application can instead use the return status (number of bytes transferred) to maintain its logic and complete the data transfer. The
read/write model can be used with the non-DMA buffer queue model. It cannot be used with the byte transfer model and the DMA-enabled buffer
queue model in the same application.
To use the file I/O type read/write data transfer model, the drv_usart_read_write.c file must be included in the project and the
DRV_USART_READ_WRITE_MODEL_SUPPORT configuration macro should be set to true.
See File I/O Type Read/Write Data Transfer Modef for additional information.
Volume V: MPLAB Harmony Framework Driver Libraries Help USART Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1296
Buffer Queue Transfer Model:
The buffer queue data transfer model allows clients to queue data transfers for processing. This data transfer model is always non-blocking. The
USART driver returns a buffer handle for a queued request. The clients can track the completion of a buffer through events and API. If the USART
driver is busy processing a data transfer, other data transfer requests are queued. This allows the clients to optimize their application logic and
increase throughput. To optimize memory usage, the USART driver implements a shared buffer object pool concept to add a data transfer request
to the queue. The following figure shows a conceptual representation of the buffer queue model.
Buffer Queue Transfer Model
As shown in the previous figure, each USART driver hardware instance has a read and write queue. The system designer must configure the sizes
of these read and write queues. The USART driver additionally employs a global pool of buffer queue objects. This pool is common to all USART
Driver hardware instances and its size is defined by the DRV_USART_QUEUE_DEPTH_COMBINED configuration macro. When a client places a
request to add a data transfer, the driver performs the following actions:
• It checks if a buffer object is free in the global pool. If not, the driver rejects the request.
• It then checks if the hardware instance specific queue is full. If not, the buffer object from the global pool is added to the hardware instance
specific queue. If the queue is full, the driver rejects the request.
The buffer queue model can be used along with the file I/O type read/write data transfer model.
To use the Buffer Queue Data Transfer model, the drv_usart_buffer_queue.c file must be included in the project and
DRV_USART_BUFFER_QUEUE_SUPPORT configuration macro should be set to true.
The USART Driver DMA feature is only available while using the Buffer Queue Model. If enabled, the USART Driver uses the DMA module
channels to transfer data directly from application memory to USART transmit or receive registers. This reduces CPU resource consumption and
improves system performance. To use the buffer queue model with DMA, the drv_usart_buffer_queue_dma.c file should be included in the
project instead of drv_usart_buffer_queue.c.
See Buffer Queue Transfer Model for additional information.
Communication Management
The USART Driver API contains functions to control the USART Driver communication properties. These functions allow the client to change the
parity, stop bits, number of data bits and the communication baud rate. A change in the communication setting affects all ongoing communication
and all driver clients.
Library Overview
Refer to the Driver Library Overview section for information on how the driver operates in a system.
Volume V: MPLAB Harmony Framework Driver Libraries Help USART Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1297
The library interface routines are divided into various sub-sections, which address one of the blocks or the overall operation of the USART Driver
Library.
Library Interface Section Description
System Routines These routines are accessed by the MPLAB Harmony system module. They allow the driver to be
initialized, deinitialized and maintained.
Core Client Routines These routines allow the application client to open and close the driver.
Communication Management Client
Routines
These routines allow the client to change the properties of the communication channel (such as baud,
parity, etc.).
Buffer Queue Read/Write Client
Routines
These routines allow the client to use the buffer queue data transfer model.
File I/O Type Read/Write Routines These routines allow the client to use the file I/O type read/write routines.
Byte Transfer Routines These routines allow the client to use the byte data transfer model.
The USART driver must be first initialized. One or more application clients can then open the USART Driver in Blocking or non-Blocking mode.
The Open function returns a handle which allows the client to access the driver client functionality. The Driver tasks routines should be invoked
regularly from the SYS_Tasks routine in case of Polled mode operation or from USART Driver Interrupt Service Routine (ISR), in case of Interrupt
mode.
The driver implementation is split across multiple files to optimize the application project code size. The application project must include the
drv_usart.c file if the USART driver is needed in the application. If DMA-enabled data transfers are required, the drv_usart_dma.c file
should be included into the project instead of the drv_usart.c file. These files implement the system and core Client routines. Other driver files
can be included based on the required driver features.
The USART Driver API, unless otherwise specified, should not be called from an interrupt context. That is, they should not be called from an ISR
or from event handlers that are executing within an ISR context.
How the Library Works
This section describes how to use the USART Driver.
Description
Prior to using the USART Driver, the application must decide on which USART data transfer models are required. The application project should
then include the USART Driver files, required to support the data transfer model into the application project. Additionally, the application design
must consider the need for USART Driver to be opened in blocking or non blocking modes. This will also affect the application flow.
Initializing the USART Driver
Describes how to initialize the USART Driver.
Description
The USART Driver must be configured and initialized for clients to be able to open the driver. The driver build time configuration is defined by the
configuration macros. Refer to the Building the Library section for the location of and more information on the various configuration macros and
how these macros should be designed. The driver initialization is configured through the DRV_USART_INIT data structure that is passed to the
DRV_USART_Initialize function. The initialization parameters include the USART baud, the USART Peripheral, USART interrupts and read queue
and write queue sizes (which are applicable only when buffer queue data transfer is used). The following code shows an example of initializing the
USART driver for 300 bps and uses USART2. If the driver is configured for Interrupt mode of operation, the priority of the USART interrupts needs
to be specified.
/* The following code shows an example of designing the
* DRV_USART_INIT data structure. It also shows how an example
* usage of the DRV_USART_Initialize() function and how Interrupt
* System Service routines are used to set USART Interrupt
* priority. */
DRV_USART_INIT usartInit;
SYS_MODULE_OBJ usartModule1;
/* Set the baud to 300 */
usartInit.baud = 300;
/* Auto Baud detection or Stop Idle is not needed */
usartInit.flags = DRV_USART_INIT_FLAG_NONE;
/* Handshaking is not needed */
usartInit.handshake = DRV_USART_HANDSHAKE_NONE;
Volume V: MPLAB Harmony Framework Driver Libraries Help USART Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1298
/* USART Error Interrupt source for this USART
* driver instance. Note that INT_SOURCE_USART_2_ERROR
* value is defined by the Interrupt System Service and
* is the error interrupt for USART 2*/
usartInit.interruptError = INT_SOURCE_USART_2_ERROR;
/* USART Receive Interrupt source for this USART
* driver instance. Note that INT_SOURCE_USART_2_RECEIVE
* value is defined by the Interrupt System Service and
* is the error interrupt for USART 2 */
usartInit.interruptReceive = INT_SOURCE_USART_2_RECEIVE;
/* USART Transmit Interrupt source for this USART
* driver instance. Note that INT_SOURCE_USART_2_TRANSMIT
* value is defined by the Interrupt System Service and
* is the error interrupt for USART 2 */
usartInit.interruptTransmit = INT_SOURCE_USART_2_TRANSMIT;
/* Line control mode */
usartInit.lineControl = DRV_USART_LINE_CONTROL_8NONE1;
/* Operation mode is normal. Loopback or addressed is not
* needed */
usartInit.mode = DRV_USART_OPERATION_MODE_NORMAL;
/* Peripheral Bus clock frequency at which the USART is
* operating */
usartInit.brgClock = 80000000;
/* System module power setting. Typically set to
* SYS_MODULE_POWER_RUN_FULL */
usartInit.moduleInit.value = SYS_MODULE_POWER_RUN_FULL;
/* Receive buffer queue size. In this case a maximum of 2
* receive buffers can be queued. Only applicable if the
* Buffer Queue Data Transfer Model is included in the
* application. */
usartInit.queueSizeReceive = 2;
/* Transmit buffer queue size. In this case a maximum of 3
* transmit buffers can be queued. Only applicable if the
* Buffer Queue Data Transfer Model is included in the
* application. */
usartInit.queueSizeTransmit = 3;
/* The USART peripheral instance index associated with this
* driver instance. Note that this value is defined by the
* USART Peripheral Library */
usartInit.usartID = USART_ID_2;
/* Initialize USART Driver Instance 0 */
usartModule1 = DRV_USART_Initialize(DRV_USART_0, (SYS_MODULE_INIT*)&usartInit);
/* The result of the driver initialization can be checked */
if(SYS_MODULE_OBJ_INVALID == usartModule1)
{
/* There was an error in initialization. */
}
/* If the USART driver is configured for interrupt mode of
* operation, the interrupt priorities should be configured.
* Here the Interrupt System Service is used to set the
* priority to level 4 */
/* Initialize the interrupt system service */
SYS_INT_Initialize();
/* Set the USART 2 module interrupt priority to 4*/
SYS_INT_VectorPrioritySet(INT_VECTOR_UART2, INT_PRIORITY_LEVEL4);
Volume V: MPLAB Harmony Framework Driver Libraries Help USART Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1299
/* Set the USART 2 module interrupt sub-priority to 0*/
SYS_INT_VectorSubprioritySet(INT_VECTOR_UART2, INT_SUBPRIORITY_LEVEL0);
/* Enable global interrupt */
SYS_INT_Enable();
The USART Driver can be configured to transfer data through the DMA. In such a case, the DMA channels to be used for USART transmit and
receive need to be specified. The USART Driver depends on the DMA System Service to access the DMA module. The DMA channels to be used
for transmit and receive transfers should be specified in the DRV_USART_INIT data structure.
The following code shows an example of using the USART Driver initialization to use DMA for transferring data. The code also shows example
initialization of the DMA System Service.
/* The following code shows an example of designing the
* DRV_USART_INIT data structure. It also shows how an example
* usage of the DRV_USART_Initialize() function and how Interrupt
* System Service routines are used to set USART Interrupt
* priority. */
DRV_USART_INIT usartInit;
SYS_DMA_INIT dmaInit;
SYS_MODULE_OBJ usartModule1;
SYS_MODULE_OBJ dmaModule;
/* Set the baud to 300 */
usartInit.baud = 300;
/* Auto Baud detection or Stop Idle is not needed */
usartInit.flags = DRV_USART_INIT_FLAG_NONE;
/* Handshaking is not needed */
usartInit.handshake = DRV_USART_HANDSHAKE_NONE;
/* USART Error Interrupt source for this USART
* driver instance. Note that INT_SOURCE_USART_2_ERROR
* value is defined by the Interrupt System Service and
* is the error interrupt for USART2*/
usartInit.interruptError = INT_SOURCE_USART_2_ERROR;
/* USART Receive Interrupt source for this USART
* driver instance. Note that INT_SOURCE_USART_2_RECEIVE
* value is defined by the Interrupt System Service and
* is the receive interrupt for USART2 */
usartInit.interruptReceive = INT_SOURCE_USART_2_RECEIVE;
/* USART Transmit Interrupt source for this USART
* driver instance. Note that INT_SOURCE_USART_2_TRANSMIT
* value is defined by the Interrupt System Service and
* is the transmit interrupt for USART2 */
usartInit.interruptTransmit = INT_SOURCE_USART_2_TRANSMIT;
/* Line control mode */
usartInit.lineControl = DRV_USART_LINE_CONTROL_8NONE1;
/* Operation mode is normal. Loopback or addressed is not
* needed */
usartInit.mode = DRV_USART_OPERATION_MODE_NORMAL;
/* Peripheral Bus clock frequency at which the USART is
* operating */
usartInit.brgClock = 80000000;
/* System module power setting. Typically set to
* SYS_MODULE_POWER_RUN_FULL */
usartInit.moduleInit.value = SYS_MODULE_POWER_RUN_FULL;
/* Receive buffer queue size. In this case a maximum of 2
* receive buffers can be queued. Only applicable if the
* Buffer Queue Data Transfer Model is included in the
* application. */
Volume V: MPLAB Harmony Framework Driver Libraries Help USART Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1300
usartInit.queueSizeReceive = 2;
/* Transmit buffer queue size. In this case a maximum of 3
* transmit buffers can be queued. Only applicable if the
* Buffer Queue Data Transfer Model is included in the
* application. */
usartInit.queueSizeTransmit = 3;
/* The USART peripheral instance index associated with this
* driver instance. Note that this value is defined by the
* USART Peripheral Library */
usartInit.usartID = USART_ID_2;
/* Use DMA channel 1 for transmit. If transmit via DMA is
* not required, set this to DMA_CHANNEL_NONE. These values
* are defined by the DMA System Service. */
usartInit.dmaChannelTransmit = DMA_CHANNEL_1;
/* Use DMA channel 2 for receive. If receive via DMA is
* not required, set this to DMA_CHANNEL_NONE. These values
* are defined by the DMA System Service. */
usartInit.dmaChannelReceive = DMA_CHANNEL_2;
/* Set the interrupt source for the Transmit DMA channel.
* This parameter is ignored if the dmaChannelTransmit
* parameter is set to DMA_CHANNEL_NONE. */
usartInit.dmaInterruptTransmit = INT_SOURCE_DMA_1;
/* Set the interrupt source for the Receive DMA channel.
* This parameter is ignored if the dmaChannelReceive
* parameter is set to DMA_CHANNEL_NONE. */
usartInit.dmaInterruptReceive = INT_SOURCE_DMA_2;
/********* End of DRV_USART_INIT Initialization *************/
/* If the USART driver is configured for interrupt mode of
* operation, the interrupt priorities should be configured.
* Here the Interrupt System Service is used to set the
* priority to level 4 */
/* Initialize the interrupt system service */
SYS_INT_Initialize();
/* Set the USART 2 module interrupt priority to 4*/
SYS_INT_VectorPrioritySet(INT_VECTOR_UART2, INT_PRIORITY_LEVEL4);
/* Set the USART 2 module interrupt sub-priority to 0*/
SYS_INT_VectorSubprioritySet(INT_VECTOR_UART2, INT_SUBPRIORITY_LEVEL0);
/* Set the DMA 1 channel interrupt priority to 4*/
SYS_INT_VectorPrioritySet(INT_VECTOR_DMA1, INT_PRIORITY_LEVEL4);
/* Set the DMA 1 channel interrupt sub-priority to 0*/
SYS_INT_VectorSubprioritySet(INT_VECTOR_DMA1, INT_SUBPRIORITY_LEVEL0);
/* Set the DMA 2 channel interrupt priority to 4*/
SYS_INT_VectorPrioritySet(INT_VECTOR_DMA2, INT_PRIORITY_LEVEL4);
/* Set the DMA 2 channel interrupt sub-priority to 0*/
SYS_INT_VectorSubprioritySet(INT_VECTOR_DMA2, INT_SUBPRIORITY_LEVEL0);
/* Enable global interrupt */
SYS_INT_Enable();
/* This is the DMA System Service Initialization */
dmaInit.sidl = SYS_DMA_SIDL_DISABLE;
dmaModule = SYS_DMA_Initialize((SYS_MODULE_INIT*)&dmaInit);
Volume V: MPLAB Harmony Framework Driver Libraries Help USART Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1301
/* The result of the DMA System Service initialization can be checked */
if(SYS_MODULE_OBJ_INVALID == dmaModule)
{
/* DMA System Service initialization was not successful */
}
/* Initialize USART Driver Instance 0 */
usartModule1 = DRV_USART_Initialize(DRV_USART_0, (SYS_MODULE_INIT*)&usartInit);
/* The result of the driver initialization can be checked */
if(SYS_MODULE_OBJ_INVALID == usartModule1)
{
/* There was an error in initialization. */
}
Opening the USART Driver
Describes how to open the USART Driver.
Description
To use the USART driver, the application must open the driver. This is done by calling the DRV_USART_Open function. Calling this function with
DRV_IO_INTENT_NONBLOCKING will cause the driver to be opened in non blocking mode. The DRV_USART_Read and DRV_USART_Write
functions when called by this client will be non blocking. . Calling this function with DRV_IO_INTENT_BLOCKING will cause the driver to be
opened in blocking mode. The DRV_USART_Read and DRV_USART_Write functions when called by this client will be blocking.
If successful, the DRV_USART_Open function will return a valid handle to the driver. This handle records the association between the client and
the driver instance that was opened. The DRV_USART_Open function may return DRV_HANDLE_INVALID in the situation where the driver is not
ready to be opened. When this occurs, the application can try opening the driver again. Note that the open function may return an invalid handle in
other (error) cases as well.
The following code shows an example of the driver being opened in different modes.
DRV_HANDLE usartHandle1, usartHandle2;
/* Client 1 opens the USART driver in non blocking mode */
usartHandle1 = DRV_USART_Open(DRV_USART_0, DRV_IO_INTENT_READWRITE|DRV_IO_INTENT_NONBLOCKING);
/* Check if the handle is valid */
if(DRV_HANDLE_INVALID == usartHandle1)
{
/* The driver was not opened successfully. The client
* can try opening it again */
}
/* Client 2 opens the USART driver in blocking mode */
usartHandle2 = DRV_USART_Open(DRV_USART_0, DRV_IO_INTENT_READWRITE|DRV_IO_INTENT_BLOCKING);
/* Check if the handle is valid */
if(DRV_HANDLE_INVALID == usartHandle2)
{
/* The driver was not opened successfully. The client
* can try opening it again */
}
/* The client can also open the USART driver in read only mode
* (DRV_IO_INTENT_READ), write only mode (DRV_IO_INTENT_WRITE)
* and exclusive mode (DRV_IO_INTENT_EXCLUSIVE). If the driver
* has been opened exclusively by a client, it cannot be opened
* again by another client */
Byte Transfer Model
Describes the USART Driver byte transfer model.
Description
To use the byte transfer model, the DRV_USART_BYTE_MODEL_SUPPORT configuration macro should be true. The
drv_usart_byte_model.c function should be included in the application project. The application cannot support the read/write and buffer
queue data transfer model when the byte model is enabled.
The following code shows an example of how the DRV_USART_WriteByte function and the DRV_USART_ReadByte function are used.
Volume V: MPLAB Harmony Framework Driver Libraries Help USART Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1302
/* Client uses the a byte model API to write a byte*/
if(!DRV_USART_TransmitBufferIsFull(usartHandle1))
{
byte = '1';
DRV_USART_WriteByte(usartHandle1,byte);
}
/* Client waits until data is available and then reads
* byte */
while(DRV_USART_ReceiverBufferIsEmpty(usartHandle1));
byte = DRV_USART_ReadByte(usartHandle1);
File I/O Type Read/Write Data Transfer Model
This topic describes the file I/O type read/write data transfer model.
Description
To use the file I/O type read/write data transfer model, the DRV_USART_READ_WRITE_MODEL_SUPPORT configuration macro should be 'true'.
The file drv_usart_read_write.c file should be included in the application project. The driver can support the non-DMA buffer queue data
transfer model along with the file I/O type read/write data transfer model. The byte transfer model and DMA buffer queue model cannot be enabled
if the file I/O type read/write data transfer model is enabled.
The DRV_USART_Read and DRV_USART_Write function represent the file I/O type read/write data transfer model. The functional behavior of
these API is affected by the mode in which the client opened the driver. If the client opened the driver in blocking mode these API will block. In
blocking mode, the DRV_USART_Read and DRV_USART_Write functions will not return until the requested number of bytes have been read or
written. When operating in a RTOS application, the application thread that has opened driver in blocking mode, will enter a blocked state when it
calls DRV_USART_Write or DRV_USART_Read function. This will allow the RTOS scheduler to schedule other threads which are ready to run. If
the client opened the driver in non-blocking mode these API will not block. In non-blocking mode, the DRV_USART_Read and
DRV_USART_Write functions will return immediately with the amount of data that could be read or written.
Note:
Do not open the driver in Blocking mode when the driver is configured for polling operation (DRV_USART_INTERRUPT_MODE is
false) in a bare-metal (non-RTOS) application. This will cause the system to enter an infinite loop condition when the
DRV_USART_Read or DRV_USART_Write function is called.
The following code shows an example of file I/O type read/write data transfer model usage when the driver is opened in Blocking mode.
/* This code shows the functionality of the DRV_USART_Write and
* DRV_USART_Read function when the driver is opened in blocking mode */
DRV_HANDLE usartHandle1;
uint8_t myData[10];
size_t bytesProcessed;
/* The driver is opened in blocking mode */
usartHandle1 = DRV_USART_Open(DRV_USART_0, DRV_IO_INTENT_READWRITE|DRV_IO_INTENT_BLOCKING);
/* Check if the driver was opened successfully */
if(DRV_HANDLE_INVALID == usartHandle1)
{
/* The driver could not be opened successfully */
}
/* Transmit 10 bytes from the myData array. Function will not return until 10 bytes
* have been accepted by the driver. This is because the client opened the driver
* in blocking mode. */
bytesProcessed = DRV_USART_Write(usartHandle1, myData, 10);
/* Read 10 bytes from the myData array. Function will not return until all 10 bytes
* have been received by the driver. This is because the client opened the driver
* in blocking mode. */
bytesProcessed = DRV_USART_Read(usartHandle1, myData, 10);
In non-Blocking mode, the driver uses the internal USART hardware FIFO as storage. The DRV_USART_Read function checks if bytes are
available in USART receive hardware FIFO. If bytes are available, these are read and the number of bytes read is returned. The
DRV_USART_Write function checks if USART transmit hardware FIFO has empty location. If locations are empty, the bytes to be transmitted are
queued up in the FIFO and the number of queued bytes is returned. In either case, the number of bytes read or written may be less than the
number requested by the client. The client can, in such a case, call the DRV_USART_Read and/or the DRV_USART_Write functions again to
process the pending bytes. The following code shows how this can be done.
Volume V: MPLAB Harmony Framework Driver Libraries Help USART Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1303
/* This code shows the functionality of the DRV_USART_Write and
* DRV_USART_Read functions when the driver is opened in non-blocking mode */
DRV_HANDLE usartHandle1;
uint8_t myData[10];
size_t bytesProcessed;
/* The driver is opened in non-blocking mode */
usartHandle1 = DRV_USART_Open(DRV_USART_0,
DRV_IO_INTENT_READWRITE|DRV_IO_INTENT_NONBLOCKING);
/* Check if the driver was opened successfully */
if(DRV_HANDLE_INVALID == usartHandle1)
{
/* The driver could not be opened successfully */
}
/* The following code call the DRV_USART_Write function
* multiple times to write 10 bytes completely. Note how the
* function return value is used to update the location of
* user source data. */
bytesProcessed = 0;
do
{
/* Write data to the USART and use the return value to
* update the source data pointer and pending bytes number. */
bytesProcessed += DRV_USART_Write(usartHandle1,
myData + bytesProcessed, (10 - bytesProcessed));
} while(bytesProcessed < 10);
/* The following code calls the DRV_USART_Read function multiple times to read
* 10 bytes completely. Note how the function return value is used to update the
* location of user destination array. */
bytesProcessed = 0;
do
{
/* Read data from the USART and use the return value to update the
* destination pointer and pending bytes number. */
bytesProcessed += DRV_USART_Read(usartHandle1,
myData + bytesProcessed, (10 - bytesProcessed));
}while (bytesProcessed < 10);
Buffer Queue Transfer Model
This topic describes the buffer queue data transfer model.
Description
To use the buffer queue data transfer model, the DRV_USART_BUFFER_QUEUE_SUPPORT configuration macro should be true. The file,
drv_usart_buffer_queue.c, should be included in the application project. If the DMA-enabled buffer queue model is required, the
drv_usart_buffer_queue_dma.c file (and not the drv_usart_buffer_queue.c ) should be included in the application project. The DMA
and non-DMA buffer queue model API is the same. The driver can support the non-DMA buffer queue data transfer model along with the file I/O
type read/write data transfer model. The byte transfer model cannot be enabled if the buffer queue data transfer model is enabled.
The DRV_USART_BufferAddRead and DRV_USART_BufferAddWrite functions represent the buffer queue data transfer model. These functions
are always non-blocking. The Buffer Queue Data Transfer Model employs queuing of read and write request. Each driver instance contains a read
and write queue. The size of the read queue is determined by the queueSizeRead member of the DRV_USART_INIT data structure. The size of
the write queue is determined by the queueSizeWrite member of the DRV_USART_INIT data structure. The driver provides driver events
(DRV_USART_BUFFER_EVENT) that indicates termination of the buffer requests.
When the driver is configured for Interrupt mode operation (that is defined and registered by the driver client), the buffer event handler executes in
an interrupt context. Calling computationally intensive or hardware polling routines within the event handlers is not recommended. Calling interrupt
unsafe functions in the event handler when the driver is configured for Interrupt mode could result in unpredictable system behavior.
When the driver adds request to the queue, it returns a buffer handle. This unique handle allows the client to track the request as it progresses
through the queue. The buffer handle is returned with the buffer event and expires when the event associated with the buffer has been generated
and the event handler returns. The following code shows an example of using the buffer queue data transfer model.
Volume V: MPLAB Harmony Framework Driver Libraries Help USART Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1304
/* This code shows an example of using the
* Buffer Queue Data Transfer Model. */
DRV_HANDLE usartHandle1;
uint8_t myData1[10], myData2[10];
uint8_t myData3[10], myData4[10];
size_t bytesProcessed;
DRV_USART_BUFFER_HANDLE bufferHandle1, bufferHandle2;
DRV_USART_BUFFER_HANDLE bufferHandle3, bufferHandle4;
/* The driver is opened in non blocking mode */
usartHandle1 = DRV_USART_Open(DRV_USART_0,
DRV_IO_INTENT_READWRITE|DRV_IO_INTENT_NONBLOCKING);
/* Check if the driver was opened successfully */
if(DRV_HANDLE_INVALID == usartHandle1)
{
/* The driver could not be opened successfully */
}
/* Register a Buffer Event Handler with USART driver.
* This event handler function will be called whenever
* there is a buffer event. An application defined
* context can also be specified. This is returned when
* the event handler is called.
* */
DRV_USART_BufferEventHandlerSet(usartHandle1,
APP_USARTBufferEventHandler, NULL);
/* Queue up two buffers for transmit */
DRV_USART_BufferAddWrite(usartHandle1, &bufferHandle1, myData1, 10);
DRV_USART_BufferAddWrite(usartHandle1, &bufferHandle2, myData2, 10);
/* Queue up two buffers for receive */
DRV_USART_BufferAddRead(usartHandle1, &bufferHandle3, myData3, 10);
DRV_USART_BufferAddRead(usartHandle1, &bufferHandle4, myData4, 10);
/* This is application USART Driver Buffer Event Handler */
void APP_USARTBufferEventHandler(DRV_USART_BUFFER_EVENT event,
DRV_USART_BUFFER_HANDLE bufferHandle, uintptr_t contextHandle)
{
switch(event)
{
case DRV_USART_BUFFER_EVENT_COMPLETE:
/* This means the data was transferred */
break;
case DRV_USART_BUFFER_EVENT_ERROR:
/* Error handling here. */
break;
default:
break;
}
}
Driver Tasks Routine
This topic describes the Driver "Task" routines.
Description
The USART driver contains three task routines, DRV_USART_TasksTransmit, DRV_USART_TasksReceive and DRV_USART_TasksError.
These task routines implement the USART Driver state machines for transmit, receive and error related operations. If the driver is configured for
polling operation, the required task routine should be called in SYS_Tasks routine of the system. If the driver is configured for interrupt mode of
operation, the task routine should be called from the ISR. The following code shows an example of both.
/* The following code shows an example of
* USART2 Interrupt Service Routine. This function
* will be called when a USART2 interrupt occurs
Volume V: MPLAB Harmony Framework Driver Libraries Help USART Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1305
* and the driver is configured for interrupt mode
* operation */
void __ISR ( _UART_2_VECTOR,ipl4 ) _InterruptHandler_USART ( void )
{
/* usartModule1 is the System Module Object
* that was returned by the DRV_USART_Initialize
* function. */
DRV_USART_TasksTransmit(usartModule1);
DRV_USART_TasksReceive(usartModule1);
DRV_USART_TasksError(usartModule1);
}
/* In case of Polled mode, the tasks routines are
* invoked from the SYS_Tasks() routine. */
void SYS_Tasks(void)
{
DRV_USART_TasksTransmit(usartModule1);
DRV_USART_TasksReceive(usartModule1);
DRV_USART_TasksError(usartModule1);
}
/* The SYS_Tasks routine is invoked from the main
* application while(1) loop. */
while(1)
{
SYS_Tasks();
}
Using the USART Driver with DMA
This topic provides information on using the USART Driver with DMA.
Description
To use the USART Driver with DMA, the following should be noted:
• Include drv_usart_dma.c in the project. Do not include drv_usart.c.
• Include drv_usart_buffer_queue_dma.c in the project. Do not include drv_usart_buffer_queue.c.
• Initialize the driver to use DMA. Refer to Initializing the USART Driver for details.
• Refer to the DMA System Service section for details on initializing and using the DMA system service in Polling or Interrupt mode
• The DRV_USART_INTERRUPT_MODE configuration macro should be set to 'true'
• Do not directly invoke the DRV_USART_TasksTransmit and DRV_USART_TasksReceive functions
Configuring the Library
Macros
Name Description
DRV_USART_CLIENTS_NUMBER Sets up the maximum number of clients that can be connected to any
hardware instance.
DRV_USART_INDEX USART Static Index selection.
DRV_USART_INTERRUPT_MODE Macro controls interrupt based operation of the driver.
DRV_USART_INTERRUPT_SOURCE_ERROR Defines the error interrupt source for the static driver.
DRV_USART_PERIPHERAL_ID Configures the USART PLIB Module ID.
DRV_USART_INSTANCES_NUMBER Sets up the maximum number of hardware instances that can be
supported.
DRV_USART_BUFFER_QUEUE_SUPPORT Specifies if the Buffer Queue support should be enabled.
DRV_USART_BYTE_MODEL_SUPPORT Specifies if the Byte Model support should be enabled.
DRV_USART_INTERRUPT_SOURCE_RECEIVE Defines the Receive interrupt source for the static driver.
DRV_USART_INTERRUPT_SOURCE_RECEIVE_DMA Defines the Receive DMA Channel interrupt source for the static driver.
Volume V: MPLAB Harmony Framework Driver Libraries Help USART Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1306
DRV_USART_INTERRUPT_SOURCE_TRANSMIT Defines the Transmit interrupt source for the static driver.
DRV_USART_INTERRUPT_SOURCE_TRANSMIT_DMA Defines the Transmit DMA Channel interrupt source for the static driver.
DRV_USART_QUEUE_DEPTH_COMBINED Defines the number of entries of all queues in all instances of the driver.
DRV_USART_READ_WRITE_MODEL_SUPPORT Specifies if Read/Write Model support should be enabled.
DRV_USART_RECEIVE_DMA Defines the USART Driver Receive DMA Channel for the static driver.
DRV_USART_TRANSMIT_DMA Defines the USART Driver Transmit DMA Channel in case of static
driver.
DRV_USART_BAUD_RATE_IDXn Specifies the USART Baud at which the USART driver is initialized.
DRV_USART_BYTE_MODEL_BLOCKING Enables or Disables DRV_USART_ByteWrite function blocking
behavior.
DRV_USART_BYTE_MODEL_CALLBACK Enables or Disables Callback Feature of the Byte Transfer Model.
DRV_USART_RCV_QUEUE_SIZE_IDXn Sets the USART Driver Receive Queue Size while using the Buffer
Queue Data Transfer Model.
DRV_USART_XMIT_QUEUE_SIZE_IDXn Sets the USART Driver Transmit Queue Size while using the Buffer
Queue Data Transfer Model.
Description
The USART Driver requires the specification of compile-time configuration macros. These macros define resource usage, feature availability, and
dynamic behavior of the driver. These configuration macros should be defined in the system_config.h file.
This header can be placed anywhere in the application specific folders and the path of this header needs to be presented to the include search for
a successful build. Refer to the Applications Help section for more details.
Note:
Initialization overrides are not supported in this version.
/* In this configuration example, the USART driver
* must manage only on USART peripheral instance.
* This macro can be greater than one if more
* USART peripherals are needed. Not defining this
* macro will cause the driver to be built in
* static mode */
#define DRV_USART_INSTANCES_NUMBER 1
/* There will be 3 different client that use the
* one instance of the USART peripheral. Note that
* this macro configures the total (combined) number of clients
* across all instance of the USART driver. Not defining
* this macro will cause the driver to be configured
* for single client operation */
#define DRV_USART_CLIENTS_NUMBER 3
/* USART Driver should be built for interrupt mode.
* Set this to false for Polled mode operation */
#define DRV_USART_INTERRUPT_MODE true
/* Combined buffer queue depth is 5. Refer to the
* description of the Buffer Queue data transfer model
* and the DRV_USART_QUEUE_DEPTH_COMBINED macro
* for more details on how this is configured. */
#define DRV_USART_QUEUE_DEPTH_COMBINED 5
/* Set this macro to true is Buffer Queue data
* transfer model is to be enabled. */
#define DRV_USART_BUFFER_QUEUE_SUPPORT true
/* Set this macro to true if Byte by Byte data
* transfer model is to be enabled. */
#define DRV_USART_BYTE_MODEL_SUPPORT false
/* Set this macro to true File IO type Read Write
* data transfer model is to be enabled */
#define DRV_USART_READ_WRITE_MODEL_SUPPORT false
Volume V: MPLAB Harmony Framework Driver Libraries Help USART Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1307
DRV_USART_CLIENTS_NUMBER Macro
Sets up the maximum number of clients that can be connected to any hardware instance.
File
drv_usart_config_template.h
C
#define DRV_USART_CLIENTS_NUMBER 4
Description
USART Client Count Configuration
This macro sets up the maximum number of clients that can be connected to any hardware instance. This value represents the total number of
clients to be supported across all hardware instances. Therefore, if USART1 will be accessed by two clients and USART2 will accessed by three
clients, this number should be 5. It is recommended that this value be set exactly equal to the number of expected clients, as client support
consumes RAM memory space. If this macro is not defined and the DRV_USART_INSTANCES_NUMBER macro is not defined, the driver will be
built for static - single client operation. If this macro is defined and the DRV_USART_INSTANCES_NUMBER macro is not defined, the driver will
be built for static - multi client operation.
Remarks
None.
DRV_USART_INDEX Macro
USART Static Index selection.
File
drv_usart_config_template.h
C
#define DRV_USART_INDEX DRV_USART_INDEX_2
Description
Index - Used for static drivers
USART Static Index selection for the driver object reference. This macro defines the driver index for static and static multi-client builds. For
example, if this macro is set to DRV_USART_INDEX_2, the static driver APIs would be DRV_USART2_Initialize, DRV_USART2_Open, etc. When
building static drivers, this macro should be different for each static build of the USART driver that needs to be included in the project.
Remarks
This index is required to make a reference to the driver object
DRV_USART_INTERRUPT_MODE Macro
Macro controls interrupt based operation of the driver.
File
drv_usart_config_template.h
C
#define DRV_USART_INTERRUPT_MODE true
Description
USART Interrupt Mode Operation Control
This macro controls the interrupt based operation of the driver. The possible values are:
• true - Enables the interrupt mode
• false - Enables the polling mode
If the macro value is true, the Interrupt Service Routine (ISR) for the interrupt should be defined in the system. The DRV_USART_Tasks routine
should be called in the ISR. While using the USART driver with DMA, this flag should always be true.
Remarks
None.
Volume V: MPLAB Harmony Framework Driver Libraries Help USART Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1308
DRV_USART_INTERRUPT_SOURCE_ERROR Macro
Defines the error interrupt source for the static driver.
File
drv_usart_config_template.h
C
#define DRV_USART_INTERRUPT_SOURCE_ERROR INT_SOURCE_USART_2_ERROR
Description
Error Interrupt Source
This macro defines the Error interrupt source for the static driver. The interrupt source defined by this macro will override the errorInterruptSource
member of the DRV_USB_INIT initialization data structure in the driver initialization routine. This value should be set to the USART module error
interrupt enumeration in the Interrupt PLIB for the microcontroller.
Remarks
None.
DRV_USART_PERIPHERAL_ID Macro
Configures the USART PLIB Module ID.
File
drv_usart_config_template.h
C
#define DRV_USART_PERIPHERAL_ID USART_ID_2
Description
USART Peripheral Library Module ID
This macro configures the PLIB ID if the driver is built statically. This value will override the usartID member of the DRV_USART_INIT initialization
data structure. In that when the driver is built statically, the usartID member of the DRV_USART_INIT data structure will be ignored by the driver
initialization routine and this macro will be considered. This should be set to the PLIB ID of USART module (USART_ID_1, USART_ID_2, and so
on).
Remarks
None.
DRV_USART_INSTANCES_NUMBER Macro
Sets up the maximum number of hardware instances that can be supported.
File
drv_usart_config_template.h
C
#define DRV_USART_INSTANCES_NUMBER 2
Description
USART driver objects configuration
This macro sets up the maximum number of hardware instances that can be supported. It is recommended that this number be set exactly equal to
the number of USART modules that are needed by the application, as hardware Instance support consumes RAM memory space. If this macro is
not defined, the driver will be built statically.
Remarks
None
DRV_USART_BUFFER_QUEUE_SUPPORT Macro
Specifies if the Buffer Queue support should be enabled.
Volume V: MPLAB Harmony Framework Driver Libraries Help USART Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1309
File
drv_usart_config_template.h
C
#define DRV_USART_BUFFER_QUEUE_SUPPORT true
Description
USART Driver Buffer Queue Support
This macro defines whether or not Buffer Queue support should be enabled. Setting this macro to true will enable buffer queue support and all
buffer related driver function. The driver should be built along with the drv_usart_buffer_queue.c file, which contains the functional implementation
for buffer queues. If buffer queue operation is enabled, the DRV_USART_BYTE_MODEL_SUPPORT function should not be true. If this macro is
set to false, the behavior of the USART Driver Buffer Queue API is not defined. While using the USART driver with DMA, the driver supports Buffer
Queue Data transfer model regardless of the value of this configuration macro.
Remarks
None.
DRV_USART_BYTE_MODEL_SUPPORT Macro
Specifies if the Byte Model support should be enabled.
File
drv_usart_config_template.h
C
#define DRV_USART_BYTE_MODEL_SUPPORT false
Description
USART Driver Byte Model Support
This macro defines whether or Byte Model support should be enabled. Setting this macro to true will enable byte model support and all byte
operation related driver functions. The driver should be built along with the drv_usart_byte_model.c file, which contains the functional
implementation for byte model operation. If byte model operation is enabled, the driver will not support buffer queue and read write models. The
behavior of the byte mode API when this macro is set to false is not defined.
Remarks
None.
DRV_USART_INTERRUPT_SOURCE_RECEIVE Macro
Defines the Receive interrupt source for the static driver.
File
drv_usart_config_template.h
C
#define DRV_USART_INTERRUPT_SOURCE_RECEIVE INT_SOURCE_USART_2_RECEIVE
Description
Receive Interrupt Source
This macro defines the Receive interrupt source for the static driver. The interrupt source defined by this macro will override the rxInterruptSource
member of the DRV_USB_INIT initialization data structure in the driver initialization routine. This value should be set to the USART module receive
interrupt enumeration in the Interrupt PLIB for the microcontroller.
Remarks
None.
DRV_USART_INTERRUPT_SOURCE_RECEIVE_DMA Macro
Defines the Receive DMA Channel interrupt source for the static driver.
Volume V: MPLAB Harmony Framework Driver Libraries Help USART Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1310
File
drv_usart_config_template.h
C
#define DRV_USART_INTERRUPT_SOURCE_RECEIVE_DMA
Description
Receive DMA Channel Interrupt Source
This macro defines the Receive DMA Channel interrupt source for the static driver. The interrupt source defined by this macro will override the
dmaInterruptReceive member of the DRV_USB_INIT initialization data structure in the driver initialization routine. This value should be set to the
DMA channel interrupt enumeration in the Interrupt PLIB for the microcontroller.
Remarks
None.
DRV_USART_INTERRUPT_SOURCE_TRANSMIT Macro
Defines the Transmit interrupt source for the static driver.
File
drv_usart_config_template.h
C
#define DRV_USART_INTERRUPT_SOURCE_TRANSMIT INT_SOURCE_USART_2_TRANSMIT
Description
Transmit Interrupt Source
This macro defines the TX interrupt source for the static driver. The interrupt source defined by this macro will override the txInterruptSource
member of the DRV_USB_INIT initialization data structure in the driver initialization routine. This value should be set to the USART module
transmit interrupt enumeration in the Interrupt PLIB for the microcontroller.
Remarks
None.
DRV_USART_INTERRUPT_SOURCE_TRANSMIT_DMA Macro
Defines the Transmit DMA Channel interrupt source for the static driver.
File
drv_usart_config_template.h
C
#define DRV_USART_INTERRUPT_SOURCE_TRANSMIT_DMA
Description
Transmit DMA Channel Interrupt Source
This macro defines the TX DMA Channel interrupt source for the static driver. The interrupt source defined by this macro will override the
dmaInterruptTransmit member of the DRV_USB_INIT initialization data structure in the driver initialization routine. This value should be set to the
DMA channel interrupt enumeration in the Interrupt PLIB for the microcontroller.
Remarks
None.
DRV_USART_QUEUE_DEPTH_COMBINED Macro
Defines the number of entries of all queues in all instances of the driver.
File
drv_usart_config_template.h
Volume V: MPLAB Harmony Framework Driver Libraries Help USART Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1311
C
#define DRV_USART_QUEUE_DEPTH_COMBINED 16
Description
USART Driver Instance combined queue depth.
This macro defines the number of entries of all queues in all instances of the driver.
Each hardware instance supports a buffer queue for transmit and receive operations. The size of queue is specified either in driver initialization (for
dynamic build) or by macros (for static build). The hardware instance transmit buffer queue will queue transmit buffers submitted by the
DRV_USART_BufferAddWrite function. The hardware instance receive buffer queue will queue receive buffers submitted by the
DRV_USART_BufferAddRead function.
A buffer queue will contain buffer queue entries, with each related to a BufferAdd request. This configuration macro defines the total number of
buffer entries that will be available for use between all USART driver hardware instances. The buffer queue entries are allocated to individual
hardware instances as requested by hardware instances. Once the request is processed, the buffer queue entry is free for use by other hardware
instances.
The total number of buffer entries in the system determines the ability of the driver to service non blocking read and write requests. If a free buffer
entry is not available, the driver will not add the request and will return an invalid buffer handle. The greater the number of buffer entries, the
greater the ability of the driver to service and add requests to its queue. A hardware instance additionally can queue up as many buffer entries as
specified by its transmit and receive buffer queue size.
For example, consider the case of static single client driver application where full duplex non blocking operation is desired without queuing, the
minimum transmit queue depth and minimum receive queue depth should be 1. Therefore, the total number of buffer entries should be 2.
As another example, consider the case of a dynamic driver (i.e., two instances) where instance 1 will queue up to three write requests and up to
two read requests, and instance 2 will queue up to two write requests and up to six read requests, the value of this macro should be: 13 (2 + 3 + 2
+ 6).
Remarks
None.
DRV_USART_READ_WRITE_MODEL_SUPPORT Macro
Specifies if Read/Write Model support should be enabled.
File
drv_usart_config_template.h
C
#define DRV_USART_READ_WRITE_MODEL_SUPPORT true
Description
USART Driver Read Write Model Support
This macro defines whether or not Read Write Model support should be enabled. Setting this macro to true will enable read write model support
and all read/write related driver functions. The driver should be built along with the drv_usart_read_write.c file, which contains the functional
implementation for byte model operation. If read/write model operation is enabled, the DRV_USART_BYTE_MODEL_SUPPORT macro should not
be true. The behavior of the Read Write Model API when this macro is set to false is not defined.
Remarks
None.
DRV_USART_RECEIVE_DMA Macro
Defines the USART Driver Receive DMA Channel for the static driver.
File
drv_usart_config_template.h
C
#define DRV_USART_RECEIVE_DMA
Description
USART Driver Receive DMA Channel
This macro defines the USART Receive DMA Channel for the static driver. The DMA channel defined by this macro will override the dmaReceive
member of the DRV_USB_INIT initialization data structure in the driver initialization routine. This value should be set to the DMA channel in the
Volume V: MPLAB Harmony Framework Driver Libraries Help USART Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1312
DMA PLIB for the microcontroller.
Remarks
None.
DRV_USART_TRANSMIT_DMA Macro
Defines the USART Driver Transmit DMA Channel in case of static driver.
File
drv_usart_config_template.h
C
#define DRV_USART_TRANSMIT_DMA
Description
USART Driver Transmit DMA Channel
This macro defines the USART Transmit DMA Channel for the static driver. The DMA channel defined by this macro will override the dmaTransmit
member of the DRV_USB_INIT initialization data structure in the driver initialization routine. This value should be set to the DMA channel in the
DMA PLIB for the microcontroller.
Remarks
None.
DRV_USART_BAUD_RATE_IDXn Macro
Specifies the USART Baud at which the USART driver is initialized.
File
drv_usart_config_template.h
C
#define DRV_USART_BAUD_RATE_IDXn
Description
USART Driver Baud Selection.
This configuration constant specifies the baud rate at which the USART Driver is initialized. This is the baud rate at which the USART module will
operate when the driver initialization has completed. The driver client can call the DRV_USART_BaudSet function after opening the driver to
change the USART baud rate after initialization has completed.
Remarks
This constant is automatically generated by MHC and its value is set to the value specified in USART Driver Baud Selection field.
DRV_USART_BYTE_MODEL_BLOCKING Macro
Enables or Disables DRV_USART_ByteWrite function blocking behavior.
File
drv_usart_config_template.h
C
#define DRV_USART_BYTE_MODEL_BLOCKING
Description
USART Driver Byte Write Blocking Behavior
This USART Driver MHC option controls the blocking behavior of the DRV_USART_ByteWrite function and is only applicable when the USART
Driver Byte Transfer model is selected. Selecting this option will cause the DRV_USART_ByteWrite function to block until the byte has been
written to the USART Transmit FIFO. Blocking behavior is enabled by default (to enable backward compatibility with previous versions of the
driver). This option can be used for simple applications where interoperability with other MPLAB Harmony modules is not a design concern.
If the application uses several other MPLAB Harmony modules (Middleware, File System, etc.), it is recommended to disable this option and use
the non-blocking DRV_USART_ByteWrite function. This requires the application to call the DRV_USART_TransmitBufferIsFull function to check if
the byte can be written to the USART, as shown in the following code example.
Volume V: MPLAB Harmony Framework Driver Libraries Help USART Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1313
if(!DRV_USART_TransmitBufferIsFull(usartHandle1))
{
byte = '1';
DRV_USART_WriteByte(usartHandle1,byte);
}
Using the non-blocking implementation results in improved application interoperability with other MPLAB Harmony modules.
Remarks
The DRV_USART_BYTE_MODEL_BLOCKING constant is specified for documentation purposes only. It does not affect the configuration of the
driver.
DRV_USART_BYTE_MODEL_CALLBACK Macro
Enables or Disables Callback Feature of the Byte Transfer Model.
File
drv_usart_config_template.h
C
#define DRV_USART_BYTE_MODEL_CALLBACK
Description
USART Driver Byte Model Callback Feature.
This USART Driver MHC option controls the Callback feature of the Byte Transfer model. Selecting this option allows an application to register
Byte Transfer Event Callback functions with the driver. These callback functions are invoked on the occurrence of Byte Transfer events. Callback
functions can be registered to Byte Transmit, Byte Receive, and USART Error events, as shown in the following code example.
// This code shows how a callback function is
// registered for the Byte Receive event.
DRV_USART_ByteReceiveCallbackSet(DRV_USART_INDEX_0, APP_USARTReceiveEventHandler);
// Event Processing Technique. Event is received when
// a byte is received.
void APP_USARTReceiveEventHandler(const SYS_MODULE_INDEX index)
{
// Byte has been Received. Handle the event.
// Read byte using DRV_USART_ReadByte.
}
When operating in Interrupt mode, the callback functions are invoked in an interrupt context. If this option is not selected, the application must use
the DRV_USART_TransmitBufferIsFull, DRV_USART_ReceiverBufferIsEmpty, and DRV_USART_ErrorGet functions to check the status of Byte
transmit or receive.
Remarks
The DRV_USART_BYTE_MODEL_CALLBACK constant is specified for documentation purposes only. It does not affect the configuration of the
driver.
DRV_USART_RCV_QUEUE_SIZE_IDXn Macro
Sets the USART Driver Receive Queue Size while using the Buffer Queue Data Transfer Model.
File
drv_usart_config_template.h
C
#define DRV_USART_RCV_QUEUE_SIZE_IDXn
Description
USART Driver Receive Queue Size Selection.
This constant sets the USART Driver Receive queue size when using the Buffer Queue Data Transfer Model. It affects the queuing capacity of the
DRV_USART_BufferAddRead function for the selected driver instance. For example, if this option is set to 5 for USART Driver 0, USART Driver 0
can then queue up to a maximum of five driver client receive buffer requests from any driver clients.
Therefore, if USART Driver 0 has two clients and if client 1 has queued up three buffers for receive, client 2 can only queue up to two buffers. If the
client attempts to queue up more buffers, DRV_USART_BufferAddRead will not accept the request and will generate an invalid buffer handle
(DRV_USART_BUFFER_HANDLE_INVALID).
Volume V: MPLAB Harmony Framework Driver Libraries Help USART Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1314
Remarks
This constant is automatically generated by MHC and its value is set to the value specified in USART Driver Receive Queue Size field.
DRV_USART_XMIT_QUEUE_SIZE_IDXn Macro
Sets the USART Driver Transmit Queue Size while using the Buffer Queue Data Transfer Model.
File
drv_usart_config_template.h
C
#define DRV_USART_XMIT_QUEUE_SIZE_IDXn
Description
USART Driver Transmit Queue Size Selection.
This constant sets the USART Driver Transmit queue size when using the Buffer Queue Data Transfer Model. It affects the queuing capacity of the
DRV_USART_BufferAddWrite function, for the selected driver instance. For example, if this option is set to 5 for USART Driver 0, USART Driver 0
can then queue up to a maximum of five driver client transmit buffer requests from any driver clients.
Therefore if USART Driver 0 has two clients and if client 1 has queued up three buffers for transmit, client 2 can only queue up to two buffers. If the
client attempts to queue up more buffers, DRV_USART_BufferAddWrite will not accept the request and will generate an invalid buffer handle
(DRV_USART_BUFFER_HANDLE_INVALID).
Remarks
This constant is automatically generated by MHC and its value is set to the value specified in USART Driver Transmit Queue Size field.
Building the Library
This section lists the files that are available in the USART Driver Library.
Description
This section list the files that are available in the \src folder of the USART Driver. It lists which files need to be included in the build based on either
a hardware feature present on the board or configuration option selected by the system.
The following three tables list and describe the header (.h) and source (.c) files that implement this library. The parent folder for these files is
/framework/driver/usart.
Interface File(s)
This table lists and describes the header files that must be included (i.e., using #include) by any code that uses this library.
Source File Name Description
/drv_usart.h This file should be included by any .c file which accesses the USART Driver API. This one file contains the
prototypes for all driver API.
Required File(s)
All of the required files listed in the following table are automatically added into the MPLAB X IDE project by the MHC
when the library is selected for use.
This table lists and describes the source and header files that must always be included in the MPLAB X IDE project to build this library.
Source File Name Description
/src/dynamic/drv_usart.c This file should always be included in the project when using the USART Driver.
/src/dynamic/drv_usart_dma.c This file should always be included in the project when using the USART driver with DMA.
Optional File(s)
This table lists and describes the source and header files that may optionally be included if required for the desired implementation.
Source File Name Description
/src/dynamic/drv_usart_byte_model.c This file should be included in the project if the USART Driver Byte Model API is
required.
/src/dynamic/drv_usart_buffer_queue.c This file should be included in the project if the USART Driver Buffer Queue Model API
(without DMA) is required.
Volume V: MPLAB Harmony Framework Driver Libraries Help USART Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1315
/src/dynamic/drv_usart_read_write.c This file should be included in the project if the USART Driver Read Write Model API is
required.
/src/dynamic/drv_usart_buffer_queue_dma.c This file should be included in the project if the USART Driver Buffer Queue Model API
with DMA is required.
Module Dependencies
The USART Driver Library depends on the following modules:
• Interrupt System Service Library
• DMA System Service Library (if USART Driver is configured to use DMA)
Library Interface
a) System Functions
Name Description
DRV_USART_Initialize Initializes the USART instance for the specified driver index.
Implementation: Static/Dynamic
DRV_USART_Deinitialize Deinitializes the specified instance of the USART driver module.
Implementation: Static/Dynamic
DRV_USART_Status Gets the current status of the USART driver module.
Implementation: Static/Dynamic
DRV_USART_TasksReceive Maintains the driver's receive state machine and implements its ISR.
Implementation: Static/Dynamic
DRV_USART_TasksTransmit Maintains the driver's transmit state machine and implements its ISR.
Implementation: Static/Dynamic
DRV_USART_TasksError Maintains the driver's error state machine and implements its ISR.
Implementation: Static/Dynamic
b) Core Client Functions
Name Description
DRV_USART_Open Opens the specified USART driver instance and returns a handle to it.
Implementation: Static/Dynamic
DRV_USART_Close Closes an opened-instance of the USART driver.
Implementation: Static/Dynamic
DRV_USART_ClientStatus Gets the current client-specific status the USART driver.
Implementation: Static/Dynamic
DRV_USART_ErrorGet This function returns the error(if any) associated with the last client request.
Implementation: Static/Dynamic
c) Communication Management Client Functions
Name Description
DRV_USART_BaudSet This function changes the USART module baud to the specified value.
Implementation: Static/Dynamic
DRV_USART_LineControlSet This function changes the USART module line control to the specified value.
Implementation: Static/Dynamic
d) Buffer Queue Read/Write Client Functions
Name Description
DRV_USART_BufferAddRead Schedule a non-blocking driver read operation.
Implementation: Static/Dynamic
DRV_USART_BufferAddWrite Schedule a non-blocking driver write operation.
Implementation: Static/Dynamic
DRV_USART_BufferEventHandlerSet Allows a client to identify a buffer event handling function for the driver to call back when
queued buffer transfers have finished.
Implementation: Static/Dynamic
DRV_USART_BufferProcessedSizeGet This API will be deprecated and not recommended to use. Use
DRV_USART_BufferCompletedBytesGet to get the number of bytes processed for the
specified buffer.
Volume V: MPLAB Harmony Framework Driver Libraries Help USART Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1316
DRV_USART_AddressedBufferAddWrite Schedule a non-blocking addressed driver write operation.
Implementation: Dynamic
DRV_USART_BufferCompletedBytesGet Returns the number of bytes that have been processed for the specified buffer.
Implementation: Static/Dynamic
DRV_USART_BufferRemove Removes a requested buffer from the queue.
Implementation: Static/Dynamic
e) File I/O Type Read/Write Functions
Name Description
DRV_USART_Read Reads data from the USART.
Implementation: Static/Dynamic
DRV_USART_Write Writes data to the USART.
Implementation: Static/Dynamic
f) Byte Transfer Functions
Name Description
DRV_USART_ReadByte Reads a byte of data from the USART.
Implementation: Static/Dynamic
DRV_USART_WriteByte Writes a byte of data to the USART.
Implementation: Static/Dynamic
DRV_USART_TransmitBufferSizeGet Returns the size of the transmit buffer.
Implementation: Static/Dynamic
DRV_USART_ReceiverBufferSizeGet Returns the size of the receive buffer.
Implementation: Static/Dynamic
DRV_USART_TransferStatus Returns the transmitter and receiver transfer status.
Implementation: Static/Dynamic
DRV_USART_TransmitBufferIsFull Provides the status of the driver's transmit buffer.
Implementation: Static/Dynamic
DRV_USART_ReceiverBufferIsEmpty Provides the status of the driver's receive buffer.
Implementation: Static/Dynamic
DRV_USART_ByteErrorCallbackSet Registers callback to handle for byte error events.
DRV_USART_ByteReceiveCallbackSet Registers receive callback function for byte receive event.
DRV_USART_ByteTransmitCallbackSet Registers a callback function for byte transmit event.
Description
This section describes the functions of the USART Driver Library.
Refer to each section for a detailed description.
a) System Functions
DRV_USART_Initialize Function
Initializes the USART instance for the specified driver index.
Implementation: Static/Dynamic
File
drv_usart.h
C
SYS_MODULE_OBJ DRV_USART_Initialize(const SYS_MODULE_INDEX index, const SYS_MODULE_INIT * const init);
Returns
If successful, returns a valid handle to a driver instance object. Otherwise, returns SYS_MODULE_OBJ_INVALID.
Description
This routine initializes the USART driver instance for the specified driver index, making it ready for clients to open and use it. The initialization data
is specified by the init parameter. The initialization may fail if the number of driver objects allocated are insufficient or if the specified driver instance
is already initialized. The driver instance index is independent of the USART module ID. For example, driver instance 0 can be assigned to
Volume V: MPLAB Harmony Framework Driver Libraries Help USART Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1317
USART2. If the driver is built statically, then some of the initialization parameters are overridden by configuration macros. Refer to the description
of the DRV_USART_INIT data structure for more details on which members on this data structure are overridden.
Remarks
This routine must be called before any other USART routine is called.
This routine should only be called once during system initialization unless DRV_USART_Deinitialize is called to deinitialize the driver instance.
This routine will NEVER block for hardware access.
Preconditions
None.
Example
// The following code snippet shows an example USART driver initialization.
// The driver is initialized for normal mode and a baud of 300. The
// receive queue size is set to 2 and transmit queue size is set to 3.
DRV_USART_INIT usartInit;
SYS_MODULE_OBJ objectHandle;
usartInit.baud = 300;
usartInit.mode = DRV_USART_OPERATION_MODE_NORMAL;
usartInit.flags = DRV_USART_INIT_FLAG_NONE;
usartInit.usartID = USART_ID_2;
usartInit.brgClock = 80000000;
usartInit.handshake = DRV_USART_HANDSHAKE_NONE;
usartInit.lineControl = DRV_USART_LINE_CONTROL_8NONE1;
usartInit.interruptError = INT_SOURCE_USART_2_ERROR;
usartInit.interruptReceive = INT_SOURCE_USART_2_RECEIVE;
usartInit.queueSizeReceive = 2;
usartInit.queueSizeTransmit = 3;
usartInit.interruptTransmit = INT_SOURCE_USART_2_TRANSMIT;
usartInit.moduleInit.value = SYS_MODULE_POWER_RUN_FULL;
objectHandle = DRV_USART_Initialize(DRV_USART_INDEX_1, (SYS_MODULE_INIT*)&usartInitData);
if (SYS_MODULE_OBJ_INVALID == objectHandle)
{
// Handle error
}
Parameters
Parameters Description
index Identifier for the instance to be initialized
init Pointer to a data structure containing any data necessary to initialize the driver.
Function
SYS_MODULE_OBJ DRV_USART_Initialize
(
const SYS_MODULE_INDEX index,
const SYS_MODULE_INIT * const init
)
DRV_USART_Deinitialize Function
Deinitializes the specified instance of the USART driver module.
Implementation: Static/Dynamic
File
drv_usart.h
C
void DRV_USART_Deinitialize(SYS_MODULE_OBJ object);
Volume V: MPLAB Harmony Framework Driver Libraries Help USART Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1318
Returns
None.
Description
Deinitializes the specified instance of the USART driver module, disabling its operation (and any hardware). Invalidates all the internal data.
Remarks
Once the Initialize operation has been called, the Deinitialize operation must be called before the Initialize operation can be called again. This
routine will NEVER block waiting for hardware.
Preconditions
Function DRV_USART_Initialize should have been called before calling this function.
Example
SYS_MODULE_OBJ object; // Returned from DRV_USART_Initialize
SYS_STATUS status;
DRV_USART_Deinitialize(object);
status = DRV_USART_Status(object);
if (SYS_MODULE_DEINITIALIZED != status)
{
// Check again later if you need to know
// when the driver is deinitialized.
}
Parameters
Parameters Description
object Driver object handle, returned from the DRV_USART_Initialize routine
Function
void DRV_USART_Deinitialize( SYS_MODULE_OBJ object )
DRV_USART_Status Function
Gets the current status of the USART driver module.
Implementation: Static/Dynamic
File
drv_usart.h
C
SYS_STATUS DRV_USART_Status(SYS_MODULE_OBJ object);
Returns
SYS_STATUS_READY - Indicates that the driver is busy with a previous system level operation and cannot start another
SYS_STATUS_DEINITIALIZED - Indicates that the driver has been deinitialized
Description
This routine provides the current status of the USART driver module.
Remarks
A driver can opened only when its status is SYS_STATUS_READY.
Preconditions
Function DRV_USART_Initialize should have been called before calling this function.
Example
SYS_MODULE_OBJ object; // Returned from DRV_USART_Initialize
SYS_STATUS usartStatus;
usartStatus = DRV_USART _Status(object);
Volume V: MPLAB Harmony Framework Driver Libraries Help USART Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1319
if (SYS_STATUS_READY == usartStatus)
{
// This means the driver can be opened using the
// DRV_USART_Open() function.
}
Parameters
Parameters Description
object Driver object handle, returned from the DRV_USART_Initialize routine
Function
SYS_STATUS DRV_USART_Status( SYS_MODULE_OBJ object )
DRV_USART_TasksReceive Function
Maintains the driver's receive state machine and implements its ISR.
Implementation: Static/Dynamic
File
drv_usart.h
C
void DRV_USART_TasksReceive(SYS_MODULE_OBJ object);
Returns
None.
Description
This routine is used to maintain the driver's internal receive state machine and implement its receive ISR for interrupt-driven implementations. In
polling mode, this function should be called from the SYS_Tasks function. In interrupt mode, this function should be called in the receive interrupt
service routine of the USART that is associated with this USART driver hardware instance.
Remarks
This routine is normally not called directly by an application. It is called by the system's Tasks routine (SYS_Tasks) or by the appropriate raw ISR.
This routine may execute in an ISR context and will never block or access any resources that may cause it to block.
Preconditions
The DRV_USART_Initialize routine must have been called for the specified USART driver instance.
Example
SYS_MODULE_OBJ object; // Returned from DRV_USART_Initialize
while (true)
{
DRV_USART_TasksReceive (object);
// Do other tasks
}
Parameters
Parameters Description
object Object handle for the specified driver instance (returned from DRV_USART_Initialize)
Function
void DRV_USART_TasksReceive (SYS_MODULE_OBJ object );
DRV_USART_TasksTransmit Function
Maintains the driver's transmit state machine and implements its ISR.
Implementation: Static/Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help USART Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1320
File
drv_usart.h
C
void DRV_USART_TasksTransmit(SYS_MODULE_OBJ object);
Returns
None.
Description
This routine is used to maintain the driver's internal transmit state machine and implement its transmit ISR for interrupt-driven implementations. In
polling mode, this function should be called from the SYS_Tasks function. In interrupt mode, this function should be called in the transmit interrupt
service routine of the USART that is associated with this USART driver hardware instance.
Remarks
This routine is normally not called directly by an application. It is called by the system's Tasks routine (SYS_Tasks) or by the appropriate raw ISR.
This routine may execute in an ISR context and will never block or access any resources that may cause it to block.
Preconditions
The DRV_USART_Initialize routine must have been called for the specified USART driver instance.
Example
SYS_MODULE_OBJ object; // Returned from DRV_USART_Initialize
while (true)
{
DRV_USART_TasksTransmit (object);
// Do other tasks
}
Parameters
Parameters Description
object Object handle for the specified driver instance (returned from DRV_USART_Initialize)
Function
void DRV_USART_TasksTransmit (SYS_MODULE_OBJ object );
DRV_USART_TasksError Function
Maintains the driver's error state machine and implements its ISR.
Implementation: Static/Dynamic
File
drv_usart.h
C
void DRV_USART_TasksError(SYS_MODULE_OBJ object);
Returns
None.
Description
This routine is used to maintain the driver's internal error state machine and implement its error ISR for interrupt-driven implementations. In polling
mode, this function should be called from the SYS_Tasks function. In interrupt mode, this function should be called in the error interrupt service
routine of the USART that is associated with this USART driver hardware instance.
Remarks
This routine is normally not called directly by an application. It is called by the system's Tasks routine (SYS_Tasks) or by the appropriate raw ISR.
This routine may execute in an ISR context and will never block or access any resources that may cause it to block.
Volume V: MPLAB Harmony Framework Driver Libraries Help USART Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1321
Preconditions
The DRV_USART_Initialize routine must have been called for the specified USART driver instance.
Example
SYS_MODULE_OBJ object; // Returned from DRV_USART_Initialize
while (true)
{
DRV_USART_TasksError (object);
// Do other tasks
}
Parameters
Parameters Description
object Object handle for the specified driver instance (returned from DRV_USART_Initialize)
Function
void DRV_USART_TasksError (SYS_MODULE_OBJ object );
b) Core Client Functions
DRV_USART_Open Function
Opens the specified USART driver instance and returns a handle to it.
Implementation: Static/Dynamic
File
drv_usart.h
C
DRV_HANDLE DRV_USART_Open(const SYS_MODULE_INDEX index, const DRV_IO_INTENT ioIntent);
Returns
If successful, the routine returns a valid open-instance handle (a number identifying both the caller and the module instance).
If an error occurs, the return value is DRV_HANDLE_INVALID. Error can occur
• if the number of client objects allocated via DRV_USART_CLIENTS_NUMBER is insufficient.
• if the client is trying to open the driver but driver has been opened exclusively by another client.
• if the driver hardware instance being opened is not initialized or is invalid.
• if the client is trying to open the driver exclusively, but has already been opened in a non exclusive mode by another client.
• if the driver is not ready to be opened, typically when the initialize routine has not completed execution.
Description
This routine opens the specified USART driver instance and provides a handle that must be provided to all other client-level operations to identify
the caller and the instance of the driver. The ioIntent parameter defines how the client interacts with this driver instance.
The DRV_IO_INTENT_BLOCKING and DRV_IO_INTENT_NONBLOCKING ioIntent options additionally affect the behavior of the
DRV_USART_Read and DRV_USART_Write functions. If the ioIntent is DRV_IO_INTENT_NONBLOCKING, then these function will not block
even if the required amount of data could not be processed. If the ioIntent is DRV_IO_INTENT_BLOCKING, these functions will block until the
required amount of data is processed. If the driver is configured for polling and bare-metal operation, it will not support
DRV_IO_INTENT_BLOCKING. The driver will operation will always be non-blocking.
If ioIntent is DRV_IO_INTENT_READ, the client will only be able to read from the driver. If ioIntent is DRV_IO_INTENT_WRITE, the client will only
be able to write to the driver. If the ioIntent is DRV_IO_INTENT_READWRITE, the client will be able to do both, read and write.
Specifying a DRV_IO_INTENT_EXCLUSIVE will cause the driver to provide exclusive access to this client. The driver cannot be opened by any
other client.
Remarks
The handle returned is valid until the DRV_USART_Close routine is called. This routine will NEVER block waiting for hardware.If the requested
intent flags are not supported, the routine will return DRV_HANDLE_INVALID. This function is thread safe in a RTOS application.
Volume V: MPLAB Harmony Framework Driver Libraries Help USART Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1322
Preconditions
Function DRV_USART_Initialize must have been called before calling this function.
Example
DRV_HANDLE handle;
handle = DRV_USART_Open(DRV_USART_INDEX_0, DRV_IO_INTENT_EXCLUSIVE);
if (DRV_HANDLE_INVALID == handle)
{
// Unable to open the driver
// May be the driver is not initialized or the initialization
// is not complete.
}
Parameters
Parameters Description
index Identifier for the object instance to be opened
intent Zero or more of the values from the enumeration DRV_IO_INTENT "ORed" together to
indicate the intended use of the driver. See function description for details.
Function
DRV_HANDLE DRV_USART_Open
(
const SYS_MODULE_INDEX index,
const DRV_IO_INTENT ioIntent
)
DRV_USART_Close Function
Closes an opened-instance of the USART driver.
Implementation: Static/Dynamic
File
drv_usart.h
C
void DRV_USART_Close(const DRV_HANDLE handle);
Returns
None.
Description
This routine closes an opened-instance of the USART driver, invalidating the handle. Any buffers in the driver queue that were submitted by this
client will be removed. After calling this routine, the handle passed in "handle" must not be used with any of the remaining driver routines (with one
possible exception described in the "Remarks" section). A new handle must be obtained by calling DRV_USART_Open before the caller may use
the driver again
Remarks
Usually there is no need for the client to verify that the Close operation has completed. The driver will abort any ongoing operations when this
routine is called. However, if it requires additional time to do so in a non-blocking environment, it will still return from the Close operation but the
handle is now a zombie handle. The client can only call the DRV_USART_ClientStatus on a zombie handle to track the completion of the Close
operation. The DRV_USART_ClientStatus routine will return DRV_CLIENT_STATUS_CLOSED when the close operation has completed.
Preconditions
The DRV_USART_Initialize routine must have been called for the specified USART driver instance.
DRV_USART_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE handle; // Returned from DRV_USART_Open
DRV_USART_Close(handle);
Volume V: MPLAB Harmony Framework Driver Libraries Help USART Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1323
// After this point, the handle cannot be used with any other function
// except the DRV_USART_ClientStatus function, which can be used to query
// the success status of the DRV_USART_Close function.
while(DRV_USART_CLIENT_STATUS_CLOSED != DRV_USART_ClientStatus(handle));
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
void DRV_USART_Close( DRV_Handle handle )
DRV_USART_ClientStatus Function
Gets the current client-specific status the USART driver.
Implementation: Static/Dynamic
File
drv_usart.h
C
DRV_USART_CLIENT_STATUS DRV_USART_ClientStatus(DRV_HANDLE handle);
Returns
A DRV_USART_CLIENT_STATUS value describing the current status of the driver.
Description
This function gets the client-specific status of the USART driver associated with the given handle. This function can be used to check the status of
client after the DRV_USART_Close() function has been called.
Remarks
This function will not block for hardware access and will immediately return the current status. This function is thread safe when called in a RTOS
application.
Preconditions
The DRV_USART_Initialize function must have been called.
DRV_USART_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE handle; // Returned from DRV_USART_Open
DRV_USART_CLIENT_STATUS status;
status = DRV_USART_ClientStatus(handle);
if( DRV_USART_CLIENT_STATUS_CLOSED != status )
{
// The client had not closed.
}
Parameters
Parameters Description
handle Handle returned from the driver's open function.
Function
DRV_USART_CLIENT_STATUS DRV_USART_ClientStatus( DRV_HANDLE handle )
DRV_USART_ErrorGet Function
This function returns the error(if any) associated with the last client request.
Implementation: Static/Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help USART Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1324
File
drv_usart.h
C
DRV_USART_ERROR DRV_USART_ErrorGet(const DRV_HANDLE client);
Returns
A DRV_USART_ERROR type indicating last known error status.
Description
This function returns the error(if any) associated with the last client request. DRV_USART_Read and DRV_USART_Write will update the client
error status when these functions return DRV_USART_TRANSFER_ERROR. If the driver send a DRV_USART_BUFFER_EVENT_ERROR to the
client, the client can call this function to know the error cause. The error status will be updated on every operation and should be read frequently
(ideally immediately after the driver operation has completed) to know the relevant error status.
Remarks
It is the client's responsibility to make sure that the error status is obtained frequently. The driver will update the client error status regardless of
whether this has been examined by the client. This function is thread safe when used in a RTOS application.
Preconditions
The DRV_USART_Initialize routine must have been called for the specified USART driver instance.
DRV_USART_Open must have been called to obtain a valid opened device handle.
Example
// myAppObj is an application specific object.
MY_APP_OBJ myAppObj;
uint8_t mybuffer[MY_BUFFER_SIZE];
DRV_USART_BUFFER_HANDLE bufferHandle;
// myUSARTHandle is the handle returned
// by the DRV_USART_Open function.
// Client registers an event handler with driver. This is done once.
DRV_USART_BufferEventHandlerSet( myUSARTHandle, APP_USARTBufferEventHandle,
(uintptr_t)&myAppObj );
bufferHandle = DRV_USART_BufferAddRead( myUSARThandle,
myBuffer, MY_BUFFER_SIZE );
if(DRV_USART_BUFFER_HANDLE_INVALID == bufferHandle)
{
// Error handling here
}
// Event Processing Technique. Event is received when
// the buffer is processed.
void APP_USARTBufferEventHandler( DRV_USART_BUFFER_EVENT event,
DRV_USART_BUFFER_HANDLE bufferHandle, uintptr_t contextHandle )
{
// The context handle was set to an application specific
// object. It is now retrievable easily in the event handler.
MY_APP_OBJ myAppObj = (MY_APP_OBJ *) contextHandle;
size_t processedBytes;
switch(event)
{
case DRV_USART_BUFFER_EVENT_COMPLETE:
// This means the data was transferred.
break;
case DRV_USART_BUFFER_EVENT_ERROR:
Volume V: MPLAB Harmony Framework Driver Libraries Help USART Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1325
// Error handling here.
// We can find out how many bytes were processed in this
// buffer before the error occurred. We can also find
// the error cause.
processedBytes = DRV_USART_BufferCompletedBytesGet(bufferHandle);
if(DRV_USART_ERROR_RECEIVE_OVERRUN == DRV_USART_ErrorGet(myUSARTHandle))
{
// There was an receive over flow error.
// Do error handling here.
}
break;
default:
break;
}
}
Parameters
Parameters Description
bufferhandle Handle of the buffer of which the processed number of bytes to be obtained.
Function
DRV_USART_ERROR DRV_USART_ErrorGet( DRV_HANDLE client);
c) Communication Management Client Functions
DRV_USART_BaudSet Function
This function changes the USART module baud to the specified value.
Implementation: Static/Dynamic
File
drv_usart.h
C
DRV_USART_BAUD_SET_RESULT DRV_USART_BaudSet(const DRV_HANDLE client, uint32_t baud);
Returns
None.
Description
This function changes the USART module baud to the specified value. Any queued buffer requests will be processed at the updated baud. The
USART driver operates at the baud specified in DRV_USART_Initialize function unless the DRV_USART_BaudSet function is called to change the
baud.
Remarks
The implementation of this function, in this release of the driver, changes the baud immediately. This may interrupt on-going data transfer. It is
recommended that the driver be opened exclusively if this function is to be called. This function is thread safe when used in a RTOS application.
Preconditions
The DRV_USART_Initialize routine must have been called for the specified USART driver instance.
DRV_USART_Open must have been called to obtain a valid opened device handle.
Example
// myUSARTHandle is the handle returned
// by the DRV_USART_Open function.
DRV_USART_BaudSet(myUSARTHandle, 9600);
Volume V: MPLAB Harmony Framework Driver Libraries Help USART Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1326
Parameters
Parameters Description
handle client handle returned by DRV_USART_Open function.
baud desired baud.
Function
void DRV_USART_BaudSet( DRV_HANDLE client, uint32_t baud);
DRV_USART_LineControlSet Function
This function changes the USART module line control to the specified value.
Implementation: Static/Dynamic
File
drv_usart.h
C
DRV_USART_LINE_CONTROL_SET_RESULT DRV_USART_LineControlSet(const DRV_HANDLE client, const
DRV_USART_LINE_CONTROL lineControl);
Returns
DRV_USART_LINE_CONTROL_SET_SUCCESS if the function was successful. Returns DRV_HANDLE_INVALID if the client handle is not valid.
Description
This function changes the USART module line control parameters to the specified value. Any queued buffer requests will be processed at the
updated line control parameters. The USART driver operates at the line control parameters specified in DRV_USART_Initialize function unless the
DRV_USART_LineControlSet function is called to change the line control parameters.
Remarks
The implementation of this function, in this release of the driver, changes the line control immediately. This may interrupt on-going data transfer. It
is recommended that the driver be opened exclusively if this function is to be called. This function is thread safe when called in a RTOS application.
Preconditions
The DRV_USART_Initialize routine must have been called for the specified USART driver instance.
DRV_USART_Open must have been called to obtain a valid opened device handle.
Example
// myUSARTHandle is the handle returned
// by the DRV_USART_Open function.
DRV_USART_LineControlSet(myUSARTHandle, DRV_USART_LINE_CONTROL_8NONE1);
Parameters
Parameters Description
handle client handle returned by DRV_USART_Open function.
lineControl line control parameters.
Function
void DRV_USART_LineControlSet
(
DRV_HANDLE client,
DRV_USART_LINE_CONTROL lineControl
);
d) Buffer Queue Read/Write Client Functions
Volume V: MPLAB Harmony Framework Driver Libraries Help USART Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1327
DRV_USART_BufferAddRead Function
Schedule a non-blocking driver read operation.
Implementation: Static/Dynamic
File
drv_usart.h
C
void DRV_USART_BufferAddRead(const DRV_HANDLE handle, DRV_USART_BUFFER_HANDLE * const bufferHandle, void *
buffer, const size_t size);
Returns
The buffer handle is returned in the bufferHandle argument. This is DRV_USART_BUFFER_HANDLE_INVALID if the request was not successful.
Description
This function schedules a non-blocking read operation. The function returns with a valid buffer handle in the bufferHandle argument if the read
request was scheduled successfully. The function adds the request to the hardware instance receive queue and returns immediately. While the
request is in the queue, the application buffer is owned by the driver and should not be modified. The function returns
DRV_USART_BUFFER_HANDLE_INVALID in the bufferHandle argument:
• if a buffer could not be allocated to the request
• if the input buffer pointer is NULL
• if the buffer size is 0
• if the read queue size is full or queue depth is insufficient.
• if the driver handle is invalid
If the requesting client registered an event callback with the driver, the driver will issue a DRV_USART_BUFFER_EVENT_COMPLETE event if the
buffer was processed successfully of DRV_USART_BUFFER_EVENT_ERROR event if the buffer was not processed successfully.
Remarks
This function is thread safe in a RTOS application. It can be called from within the USART Driver Buffer Event Handler that is registered by the
client. It should not be called in the event handler associated with another USART driver instance. It should not be called directly in an ISR.
Preconditions
The DRV_USART_Initialize routine must have been called for the specified USART device instance and the DRV_USART_Status must have
returned SYS_STATUS_READY.
DRV_USART_Open must have been called to obtain a valid opened device handle.
DRV_IO_INTENT_READ or DRV_IO_INTENT_READWRITE must have been specified in the DRV_USART_Open call.
Example
MY_APP_OBJ myAppObj;
uint8_t mybuffer[MY_BUFFER_SIZE];
DRV_USART_BUFFER_HANDLE bufferHandle;
// myUSARTHandle is the handle returned
// by the DRV_USART_Open function.
// Client registers an event handler with driver
DRV_USART_BufferEventHandlerSet(myUSARTHandle,
APP_USARTBufferEventHandler, (uintptr_t)&myAppObj);
DRV_USART_BufferAddRead(myUSARThandle, &bufferHandle,
myBuffer, MY_BUFFER_SIZE);
if(DRV_USART_BUFFER_HANDLE_INVALID == bufferHandle)
{
// Error handling here
}
// Event is received when
// the buffer is processed.
void APP_USARTBufferEventHandler(DRV_USART_BUFFER_EVENT event,
Volume V: MPLAB Harmony Framework Driver Libraries Help USART Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1328
DRV_USART_BUFFER_HANDLE bufferHandle, uintptr_t contextHandle)
{
// contextHandle points to myAppObj.
switch(event)
{
case DRV_USART_BUFFER_EVENT_COMPLETE:
// This means the data was transferred.
break;
case DRV_USART_BUFFER_EVENT_ERROR:
// Error handling here.
break;
default:
break;
}
}
Parameters
Parameters Description
handle Handle of the communication channel as returned by the DRV_USART_Open function.
buffer Buffer where the received data will be stored.
size Buffer size in bytes.
Function
void DRV_USART_BufferAddRead
(
const DRV_HANDLE handle,
DRV_USART_BUFFER_HANDLE * bufferHandle,
void * buffer,
const size_t size
)
DRV_USART_BufferAddWrite Function
Schedule a non-blocking driver write operation.
Implementation: Static/Dynamic
File
drv_usart.h
C
void DRV_USART_BufferAddWrite(const DRV_HANDLE handle, DRV_USART_BUFFER_HANDLE * bufferHandle, void *
buffer, const size_t size);
Returns
The bufferHandle parameter will contain the return buffer handle. This will be DRV_USART_BUFFER_HANDLE_INVALID if the function was not
successful.
Description
This function schedules a non-blocking write operation. The function returns with a valid buffer handle in the bufferHandle argument if the write
request was scheduled successfully. The function adds the request to the hardware instance transmit queue and returns immediately. While the
request is in the queue, the application buffer is owned by the driver and should not be modified. On returning, the bufferHandle parameter may be
DRV_USART_BUFFER_HANDLE_INVALID for the following reasons:
• if a buffer could not be allocated to the request
• if the input buffer pointer is NULL
• if the client opened the driver for read-only
• if the buffer size is 0
Volume V: MPLAB Harmony Framework Driver Libraries Help USART Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1329
• if the transmit queue is full or the queue depth is insufficient
If the requesting client registered an event callback with the driver, the driver will issue a DRV_USART_BUFFER_EVENT_COMPLETE event if the
buffer was processed successfully or a DRV_USART_BUFFER_EVENT_ERROR event if the buffer was not processed successfully.
Remarks
This function is thread safe in a RTOS application. It can be called from within the USART Driver Buffer Event Handler that is registered by this
client. It should not be called in the event handler associated with another USART driver instance. It should not otherwise be called directly in an
ISR.
Preconditions
The DRV_USART_Initialize routine must have been called for the specified USART device instance and the DRV_USART_Status must have
returned SYS_STATUS_READY.
DRV_USART_Open must have been called to obtain a valid opened device handle.
DRV_IO_INTENT_WRITE or DRV_IO_INTENT_READWRITE must have been specified in the DRV_USART_Open call.
Example
MY_APP_OBJ myAppObj;
uint8_t mybuffer[MY_BUFFER_SIZE];
DRV_USART_BUFFER_HANDLE bufferHandle;
// myUSARTHandle is the handle returned
// by the DRV_USART_Open function.
// Client registers an event handler with driver
DRV_USART_BufferEventHandlerSet(myUSARTHandle,
APP_USARTBufferEventHandler, (uintptr_t)&myAppObj);
DRV_USART_BufferAddWrite(myUSARThandle, &bufferHandle,
myBuffer, MY_BUFFER_SIZE);
if(DRV_USART_BUFFER_HANDLE_INVALID == bufferHandle)
{
// Error handling here
}
// Event is received when
// the buffer is processed.
void APP_USARTBufferEventHandler(DRV_USART_BUFFER_EVENT event,
DRV_USART_BUFFER_HANDLE bufferHandle, uintptr_t contextHandle)
{
// contextHandle points to myAppObj.
switch(event)
{
case DRV_USART_BUFFER_EVENT_COMPLETE:
// This means the data was transferred.
break;
case DRV_USART_BUFFER_EVENT_ERROR:
// Error handling here.
break;
default:
break;
}
}
Parameters
Parameters Description
handle Handle of the communication channel as return by the DRV_USART_Open function.
bufferHandle Pointer to an argument that will contain the return buffer handle.
Volume V: MPLAB Harmony Framework Driver Libraries Help USART Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1330
buffer Data to be transmitted.
size Buffer size in bytes.
Function
void DRV_USART_BufferAddWrite
(
const DRV_HANDLE handle,
DRV_USART_BUFFER_HANDLE * bufferHandle,
void * buffer,
size_t size
);
DRV_USART_BufferEventHandlerSet Function
Allows a client to identify a buffer event handling function for the driver to call back when queued buffer transfers have finished.
Implementation: Static/Dynamic
File
drv_usart.h
C
void DRV_USART_BufferEventHandlerSet(const DRV_HANDLE handle, const DRV_USART_BUFFER_EVENT_HANDLER
eventHandler, const uintptr_t context);
Returns
None.
Description
This function allows a client to identify a buffer event handling function for the driver to call back when queued buffer transfers have finished. When
a client calls either the DRV_USART_BufferAddRead or DRV_USART_BufferAddWrite function, it is provided with a handle identifying the buffer
that was added to the driver's buffer queue. The driver will pass this handle back to the client by calling "eventHandler" function when the buffer
transfer has completed.
The event handler should be set before the client performs any "buffer add" operations that could generate events. The event handler once set,
persists until the client closes the driver or sets another event handler (which could be a "NULL" pointer to indicate no callback).
Remarks
If the client does not want to be notified when the queued buffer transfer has completed, it does not need to register a callback. This function is
thread safe when called in a RTOS application.
Preconditions
The DRV_USART_Initialize routine must have been called for the specified USART driver instance.
DRV_USART_Open must have been called to obtain a valid opened device handle.
Example
// myAppObj is an application specific state data object.
MY_APP_OBJ myAppObj;
uint8_t mybuffer[MY_BUFFER_SIZE];
DRV_USART_BUFFER_HANDLE bufferHandle;
// myUSARTHandle is the handle returned
// by the DRV_USART_Open function.
// Client registers an event handler with driver. This is done once
DRV_USART_BufferEventHandlerSet( myUSARTHandle, APP_USARTBufferEventHandle,
(uintptr_t)&myAppObj );
DRV_USART_BufferAddRead(myUSARThandle, &bufferHandle
myBuffer, MY_BUFFER_SIZE);
if(DRV_USART_BUFFER_HANDLE_INVALID == bufferHandle)
{
Volume V: MPLAB Harmony Framework Driver Libraries Help USART Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1331
// Error handling here
}
// Event Processing Technique. Event is received when
// the buffer is processed.
void APP_USARTBufferEventHandler(DRV_USART_BUFFER_EVENT event,
DRV_USART_BUFFER_HANDLE handle, uintptr_t context)
{
// The context handle was set to an application specific
// object. It is now retrievable easily in the event handler.
MY_APP_OBJ myAppObj = (MY_APP_OBJ *) context;
switch(event)
{
case DRV_USART_BUFFER_EVENT_COMPLETE:
// This means the data was transferred.
break;
case DRV_USART_BUFFER_EVENT_ERROR:
// Error handling here.
break;
default:
break;
}
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
eventHandler Pointer to the event handler function.
context The value of parameter will be passed back to the client unchanged, when the eventHandler
function is called. It can be used to identify any client specific data object that identifies the
instance of the client module (for example, it may be a pointer to the client module's state
structure).
Function
void DRV_USART_BufferEventHandlerSet
(
const DRV_HANDLE handle,
const DRV_USART_BUFFER_EVENT_HANDLER eventHandler,
const uintptr_t context
)
DRV_USART_BufferProcessedSizeGet Function
This API will be deprecated and not recommended to use. Use DRV_USART_BufferCompletedBytesGet to get the number of bytes processed for
the specified buffer.
File
drv_usart.h
C
size_t DRV_USART_BufferProcessedSizeGet(DRV_USART_BUFFER_HANDLE bufferHandle);
Returns
None.
Description
None.
Volume V: MPLAB Harmony Framework Driver Libraries Help USART Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1332
Remarks
None.
Preconditions
None.
Example
None.
Function
size_t DRV_USART_BufferProcessedSizeGet
(
DRV_USART_BUFFER_HANDLE bufferHandle
);
DRV_USART_AddressedBufferAddWrite Function
Schedule a non-blocking addressed driver write operation.
Implementation: Dynamic
File
drv_usart.h
C
void DRV_USART_AddressedBufferAddWrite(const DRV_HANDLE hClient, DRV_USART_BUFFER_HANDLE * bufferHandle,
uint8_t address, void * source, size_t nWords);
Returns
The bufferHandle parameter will contain the return buffer handle. This will be DRV_USART_BUFFER_HANDLE_INVALID if the function was not
successful.
Description
This function schedules a non-blocking addressed write operation. The function returns with a valid buffer handle in the bufferHandle argument if
the addressed write request was scheduled successfully. The function adds the request to the hardware instance transmit queue and returns
immediately. While the request is in the queue, the application buffer is owned by the driver and should not be modified. On returning, the
bufferHandle parameter may be DRV_USART_BUFFER_HANDLE_INVALID for the following reasons:
• if a buffer could not be allocated to the request
• if the input buffer pointer is NULL
• if the client opened the driver for read-only
• if the buffer size is 0
• if the transmit queue is full or the queue depth is insufficient
If the requesting client registered an event callback with the driver, the driver will issue a DRV_USART_BUFFER_EVENT_COMPLETE event if the
buffer was processed successfully or a DRV_USART_BUFFER_EVENT_ERROR event if the buffer was not processed successfully.
Remarks
This function is thread safe in a RTOS application. It can be called from within the USART Driver Buffer Event Handler that is registered by this
client. It should not be called in the event handler associated with another USART driver instance. It should not otherwise be called directly in an
ISR.
The source buffer should be a 16-bit word aligned buffer. The 9th bit of the higher byte 16-bit buffer is used to indicate data/address.
Preconditions
The DRV_USART_Initialize routine must have been called for the specified USART device instance and the DRV_USART_Status must have
returned SYS_STATUS_READY.
DRV_USART_Open must have been called to obtain a valid opened device handle.
DRV_IO_INTENT_WRITE or DRV_IO_INTENT_READWRITE must have been specified in the DRV_USART_Open call.
The operation mode of the driver must be DRV_USART_OPERATION_MODE_ADDRESSED.
Example
MY_APP_OBJ myAppObj;
uint16_t mybuffer[MY_BUFFER_SIZE];
DRV_USART_BUFFER_HANDLE bufferHandle;
Volume V: MPLAB Harmony Framework Driver Libraries Help USART Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1333
uint8_t clientAddress;
// myUSARTHandle is the handle returned
// by the DRV_USART_Open function.
// Client registers an event handler with driver
clientAddress = 0x60;
DRV_USART_BufferEventHandlerSet(myUSARTHandle,
APP_USARTBufferEventHandler, (uintptr_t)&myAppObj);
DRV_USART_AddressedBufferAddWrite(myUSARThandle, &bufferHandle, clientAddress
myBuffer, MY_BUFFER_SIZE);
if(DRV_USART_BUFFER_HANDLE_INVALID == bufferHandle)
{
// Error handling here
}
// Event is received when
// the buffer is processed.
void APP_USARTBufferEventHandler(DRV_USART_BUFFER_EVENT event,
DRV_USART_BUFFER_HANDLE bufferHandle, uintptr_t contextHandle)
{
// contextHandle points to myAppObj.
switch(event)
{
case DRV_USART_BUFFER_EVENT_COMPLETE:
// This means the data was transferred.
break;
case DRV_USART_BUFFER_EVENT_ERROR:
// Error handling here.
break;
default:
break;
}
}
Parameters
Parameters Description
hClient Handle of the communication channel as return by the DRV_USART_Open function.
bufferHandle Pointer to an argument that will contain the return buffer handle.
address Address of the receiver client
source Data to be transmitted.
size Buffer size in 16-bit words.
Function
void DRV_USART_AddressedBufferAddWrite
(
const DRV_HANDLE hClient,
DRV_USART_BUFFER_HANDLE * bufferHandle,
uint8_t address,
void * source,
size_t nWords
);
Volume V: MPLAB Harmony Framework Driver Libraries Help USART Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1334
DRV_USART_BufferCompletedBytesGet Function
Returns the number of bytes that have been processed for the specified buffer.
Implementation: Static/Dynamic
File
drv_usart.h
C
size_t DRV_USART_BufferCompletedBytesGet(DRV_USART_BUFFER_HANDLE bufferHandle);
Returns
Returns the number of bytes that have been processed for this buffer.
Returns DRV_USART_BUFFER_HANDLE_INVALID for an invalid or an expired buffer handle.
Description
This function returns number of bytes that have been processed for the specified buffer. The client can use this function, in a case where the buffer
has terminated due to an error, to obtain the number of bytes that have been processed. Or in any other use case. This function can be used for
non-DMA buffer transfers only. It cannot be used when the USART driver is configured to use DMA.
Remarks
This function is thread safe when used in a RTOS application.
Preconditions
The DRV_USART_Initialize routine must have been called for the specified USART driver instance.
DRV_USART_Open must have been called to obtain a valid opened device handle.
Either the DRV_USART_BufferAddRead or DRV_USART_BufferAddWrite function must have been called and a valid buffer handle returned.
Example
// myAppObj is an application specific object.
MY_APP_OBJ myAppObj;
uint8_t mybuffer[MY_BUFFER_SIZE];
DRV_USART_BUFFER_HANDLE bufferHandle;
// myUSARTHandle is the handle returned
// by the DRV_USART_Open function.
// Client registers an event handler with driver. This is done once
DRV_USART_BufferEventHandlerSet( myUSARTHandle, APP_USARTBufferEventHandle,
(uintptr_t)&myAppObj );
bufferHandle = DRV_USART_BufferAddRead( myUSARThandle,
myBuffer, MY_BUFFER_SIZE );
if(DRV_USART_BUFFER_HANDLE_INVALID == bufferHandle)
{
// Error handling here
}
// Event Processing Technique. Event is received when
// the buffer is processed.
void APP_USARTBufferEventHandler( DRV_USART_BUFFER_EVENT event,
DRV_USART_BUFFER_HANDLE bufferHandle, uintptr_t contextHandle )
{
// The context handle was set to an application specific
// object. It is now retrievable easily in the event handler.
MY_APP_OBJ myAppObj = (MY_APP_OBJ *) contextHandle;
size_t processedBytes;
switch(event)
{
Volume V: MPLAB Harmony Framework Driver Libraries Help USART Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1335
case DRV_USART_BUFFER_EVENT_COMPLETE:
// This means the data was transferred.
break;
case DRV_USART_BUFFER_EVENT_ERROR:
// Error handling here.
// We can find out how many bytes were processed in this
// buffer before the error occurred.
processedBytes = DRV_USART_BufferCompletedBytesGet(bufferHandle);
break;
default:
break;
}
}
Parameters
Parameters Description
bufferhandle Handle for the buffer of which the processed number of bytes to be obtained.
Function
size_t DRV_USART_BufferCompletedBytesGet
(
DRV_USART_BUFFER_HANDLE bufferHandle
);
DRV_USART_BufferRemove Function
Removes a requested buffer from the queue.
Implementation: Static/Dynamic
File
drv_usart.h
C
DRV_USART_BUFFER_RESULT DRV_USART_BufferRemove(DRV_USART_BUFFER_HANDLE bufferHandle);
Returns
DRV_USART_BUFFER_RESULT_HANDLE_INVALID - Buffer handle is invalid.
DRV_USART_BUFFER_RESULT_HANDLE_EXPIRED - Buffer handle is expired.
DRV_USART_BUFFER_RESULT_REMOVED_SUCCESFULLY - Buffer is removed from the queue successfully.
DRV_USART_BUFFER_RESULT_REMOVAL_FAILED - Failed to remove buffer from the queue because of mutex timeout in RTOS environment.
Description
This function removes a specified buffer from the queue. The client can use this function to delete
1. An unwated stalled buffer.
2. Queued buffers on timeout.
or in any other use case.
Remarks
This function is thread safe when used in a RTOS application.
Preconditions
The DRV_USART_Initialize routine must have been called for the specified USART driver instance.
DRV_USART_Open must have been called to obtain a valid opened device handle.
Either the DRV_USART_BufferAddRead or DRV_USART_BufferAddWrite function must have been called and a valid buffer handle returned.
Volume V: MPLAB Harmony Framework Driver Libraries Help USART Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1336
Example
// myAppObj is an application specific object.
MY_APP_OBJ myAppObj;
uint8_t mybuffer[MY_BUFFER_SIZE];
DRV_USART_BUFFER_HANDLE bufferHandle;
// myUSARTHandle is the handle returned
// by the DRV_USART_Open function.
// Client registers an event handler with driver. This is done once
DRV_USART_BufferEventHandlerSet( myUSARTHandle, APP_USARTBufferEventHandle,
(uintptr_t)&myAppObj );
bufferHandle = DRV_USART_BufferAddRead( myUSARThandle,
myBuffer, MY_BUFFER_SIZE );
if(DRV_USART_BUFFER_HANDLE_INVALID == bufferHandle)
{
// Error handling here
}
// Event Processing Technique. Event is received when
// the buffer is processed.
void APP_USARTBufferEventHandler( DRV_USART_BUFFER_EVENT event,
DRV_USART_BUFFER_HANDLE bufferHandle, uintptr_t contextHandle )
{
switch(event)
{
case DRV_USART_BUFFER_EVENT_COMPLETE:
// This means the data was transferred.
break;
case DRV_USART_BUFFER_EVENT_ERROR:
// Error handling here.
break;
default:
break;
}
}
// Timeout function, where remove queued buffer if it still exists.
void APP_TimeOut(void)
{
DRV_USART_BUFFER_RESULT bufferResult;
bufferResult = DRV_USART_BufferRemove(bufferHandle);
if(DRV_USART_BUFFER_RESULT_REMOVED_SUCCESFULLY == bufferResult)
{
//Buffer removed succesfully from the queue
}
else
{
//Either buffer is invalid or expired.
//Or not able to acquire mutex in RTOS mode.
}
}
Parameters
Parameters Description
bufferhandle Handle of the buffer to delete.
Volume V: MPLAB Harmony Framework Driver Libraries Help USART Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1337
Function
DRV_USART_BUFFER_RESULT DRV_USART_BufferRemove( DRV_USART_BUFFER_HANDLE bufferHandle )
e) File I/O Type Read/Write Functions
DRV_USART_Read Function
Reads data from the USART.
Implementation: Static/Dynamic
File
drv_usart.h
C
size_t DRV_USART_Read(const DRV_HANDLE handle, void * buffer, const size_t numbytes);
Returns
Number of bytes actually copied into the caller's buffer. Returns DRV_USART_READ_ERROR in case of an error.
Description
This routine reads data from the USART. This function is blocking if the driver was opened by the client for blocking operation. This function will
not block if the driver was opened by the client for non blocking operation. If the ioIntent parameter at the time of opening the driver was
DRV_IO_INTENT_BLOCKING, this function will only return when (or will block until) numbytes of bytes have been received or if an error occurred.
If there are buffers queued for receiving data, these buffers will be serviced first. The function will not return until the requested number of bytes
have been read.
If the ioIntent parameter at the time of opening the driver was DRV_IO_INTENT_NON_BLOCKING, this function will return with the number of
bytes that were actually read. The function will not wait until numBytes of bytes have been read. If there are buffer queued for reading data, then
the function will not block and will return immediately with 0 bytes read.
Remarks
This function is thread safe in a RTOS application. If the driver is configured for polled operation, this it will not support blocking operation in a bare
metal (non-RTOS) application.
Preconditions
The DRV_USART_Initialize routine must have been called for the specified USART driver instance.
DRV_USART_Open must have been called to obtain a valid opened device handle.
DRV_IO_INTENT_READ or DRV_IO_INTENT_READWRITE must have been specified in the DRV_USART_Open call.
Example
DRV_HANDLE myUSARTHandle; // Returned from DRV_USART_Open
char myBuffer[MY_BUFFER_SIZE];
unsigned int count;
unsigned int total;
total = 0;
do
{
count = DRV_USART_Read(myUSARTHandle, &myBuffer[total], MY_BUFFER_SIZE - total);
if(count == DRV_USART_READ_ERROR)
{
// There was an error. The DRV_USART_ErrorGet() function
// can be called to find the exact error.
}
total += count;
// Do something else...
} while( total < MY_BUFFER_SIZE );
Volume V: MPLAB Harmony Framework Driver Libraries Help USART Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1338
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
buffer Buffer into which the data read from the USART instance will be placed.
numbytes Total number of bytes that need to be read from the module instance (must be equal to or
less than the size of the buffer)
Function
size_t DRV_USART_Read
(
const DRV_HANDLE handle,
void * buffer,
const size_t numbytes
)
DRV_USART_Write Function
Writes data to the USART.
Implementation: Static/Dynamic
File
drv_usart.h
C
size_t DRV_USART_Write(const DRV_HANDLE handle, void * buffer, const size_t numbytes);
Returns
Number of bytes actually written to the driver. Return DRV_USART_WRITE_ERROR in case of an error.
Description
This routine writes data to the USART. This function is blocking if the driver was opened by the client for blocking operation. This function will not
block if the driver was opened by the client for non blocking operation. If the ioIntent parameter at the time of opening the driver was
DRV_IO_INTENT_BLOCKING, this function will only return when (or will block until) numbytes of bytes have been transmitted or if an error
occurred. If there are buffers queued for writing, the function will wait until all the preceding buffers are completed. Ongoing buffer transmit
operations will not be affected.
If the ioIntent parameter at the time of opening the driver was DRV_IO_INTENT_NON_BLOCKING, this function will return with the number of
bytes that were actually accepted for transmission. The function will not wait until numBytes of bytes have been transmitted. If there a buffers
queued for transmit, the function will not wait and will return immediately with 0 bytes.
Remarks
This function is thread safe in a RTOS application. This function is thread safe in a RTOS application. If the driver is configured for polled
operation, this it will not support blocking operation in a bare metal (non-RTOS) application.
Preconditions
The DRV_USART_Initialize routine must have been called for the specified USART driver instance.
DRV_USART_Open must have been called to obtain a valid opened device handle.
DRV_IO_INTENT_WRITE or DRV_IO_INTENT_READWRITE must have been specified in the DRV_USART_Open call.
Example
DRV_HANDLE myUSARTHandle; // Returned from DRV_USART_Open
char myBuffer[MY_BUFFER_SIZE];
int count;
unsigned int total;
total = 0;
do
{
count = DRV_USART_Write(myUSARTHandle, &myBuffer[total],
MY_BUFFER_SIZE - total);
total += count;
Volume V: MPLAB Harmony Framework Driver Libraries Help USART Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1339
// Do something else...
} while( total < MY_BUFFER_SIZE );
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
buffer Buffer containing the data to written.
numbytes size of the buffer
Function
size_t DRV_USART_Write
(
const DRV_HANDLE handle,
void * buffer,
const size_t numbytes
)
f) Byte Transfer Functions
DRV_USART_ReadByte Function
Reads a byte of data from the USART.
Implementation: Static/Dynamic
File
drv_usart.h
C
uint8_t DRV_USART_ReadByte(const DRV_HANDLE handle);
Returns
A data byte received by the driver.
Description
This routine reads a byte of data from the USART.
Remarks
This function is thread safe when called in a RTOS application. Note that DRV_USART_WriteByte and DRV_USART_ReadByte function cannot
co-exist with DRV_USART_BufferAddRead, DRV_USART_BufferAddWrite, DRV_USART_Read and DRV_USART_Write functions in a
application. Calling the DRV_USART_ReadByte and DRV_USART_WriteByte functions will disrupt the processing of any queued buffers.
Preconditions
The DRV_USART_Initialize routine must have been called for the specified USART driver instance.
DRV_USART_Open must have been called to obtain a valid opened device handle.
The transfer status should be checked to see if the receiver is not empty before calling this function.
Example
DRV_HANDLE myUSARTHandle; // Returned from DRV_USART_Open
char myBuffer[MY_BUFFER_SIZE];
unsigned int numBytes;
numBytes = 0;
do
{
if( DRV_USART_TRANSFER_STATUS_RECEIVER_DATA_PRESENT & DRV_USART_TransferStatus(myUSARTHandle) )
{
myBuffer[numBytes++] = DRV_USART_ReadByte(myUSARTHandle);
}
// Do something else...
Volume V: MPLAB Harmony Framework Driver Libraries Help USART Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1340
} while( numBytes < MY_BUFFER_SIZE);
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
uint8_t DRV_USART_ReadByte( const DRV_HANDLE handle )
DRV_USART_WriteByte Function
Writes a byte of data to the USART.
Implementation: Static/Dynamic
File
drv_usart.h
C
void DRV_USART_WriteByte(const DRV_HANDLE handle, const uint8_t byte);
Returns
None.
Description
This routine writes a byte of data to the USART.
Remarks
This function is thread safe when called in a RTOS application. Note that DRV_USART_WriteByte and DRV_USART_ReadByte function cannot
co-exist with DRV_USART_BufferAddRead, DRV_USART_BufferAddWrite, DRV_USART_Read and DRV_USART_Write functions in a
application. Calling the DRV_USART_ReadByte and DRV_USART_WriteByte function will disrupt the processing of any queued buffers.
Preconditions
The DRV_USART_Initialize routine must have been called for the specified USART driver instance.
DRV_USART_Open must have been called to obtain a valid opened device handle.
The transfer status should be checked to see if transmitter is not full before calling this function.
Example
DRV_HANDLE myUSARTHandle; // Returned from DRV_USART_Open
char myBuffer[MY_BUFFER_SIZE];
unsigned int numBytes;
// Preinitialize myBuffer with MY_BUFFER_SIZE bytes of valid data.
numBytes = 0;
while( numBytes < MY_BUFFER_SIZE );
{
if( !(DRV_USART_TRANSFER_STATUS_TRANSMIT_FULL & DRV_USART_TransferStatus(myUSARTHandle)) )
{
DRV_USART_WriteByte(myUSARTHandle, myBuffer[numBytes++]);
}
// Do something else...
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
byte Data byte to write to the USART
Function
void DRV_USART_WriteByte( const DRV_HANDLE handle, const uint8_t byte)
Volume V: MPLAB Harmony Framework Driver Libraries Help USART Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1341
DRV_USART_TransmitBufferSizeGet Function
Returns the size of the transmit buffer.
Implementation: Static/Dynamic
File
drv_usart.h
C
unsigned int DRV_USART_TransmitBufferSizeGet(const DRV_HANDLE handle);
Returns
Size of the driver's transmit buffer, in bytes.
Description
This routine returns the size of the transmit buffer and can be used by the application to determine the number of bytes to write with the
DRV_USART_WriteByte function.
Remarks
Does not account for client queued buffers. This function is thread safe when used in a RTOS application.
Preconditions
The DRV_USART_Initialize routine must have been called for the specified USART driver instance.
DRV_USART_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE myUSARTHandle; // Returned from DRV_USART_Open
const uint8_t writeBuffer[5];
unsigned int size, numBytes = 0;
unsigned int writeBufferLen = sizeof(writeBuffer);
size = DRV_USART_TransmitBufferSizeGet (myUSARTHandle);
// Do something based on the transmitter buffer size
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
unsigned int DRV_USART_TransmitBufferSizeGet ( const DRV_HANDLE handle )
DRV_USART_ReceiverBufferSizeGet Function
Returns the size of the receive buffer.
Implementation: Static/Dynamic
File
drv_usart.h
C
unsigned int DRV_USART_ReceiverBufferSizeGet(const DRV_HANDLE handle);
Returns
Size of the driver's receive buffer, in bytes.
Description
This routine returns the size of the receive buffer.
Remarks
Does not account for client queued buffers. This function is thread safe when called in a RTOS application.
Volume V: MPLAB Harmony Framework Driver Libraries Help USART Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1342
Preconditions
The DRV_USART_Initialize routine must have been called for the specified USART driver instance.
DRV_USART_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE myUSARTHandle; // Returned from DRV_USART_Open
const uint8_t readBuffer[5];
unsigned int size, numBytes = 0;
unsigned int readbufferLen = sizeof(readBuffer);
size = DRV_USART_ReceiverBufferSizeGet(myUSARTHandle);
// Do something based on the receiver buffer size
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
unsigned int DRV_USART_ReceiverBufferSizeGet( const DRV_HANDLE handle )
DRV_USART_TransferStatus Function
Returns the transmitter and receiver transfer status.
Implementation: Static/Dynamic
File
drv_usart.h
C
DRV_USART_TRANSFER_STATUS DRV_USART_TransferStatus(const DRV_HANDLE handle);
Returns
A DRV_USART_TRANSFER_STATUS value describing the current status of the transfer.
Description
This returns the transmitter and receiver transfer status.
Remarks
The returned status may contain a value with more than one of the bits specified in the DRV_USART_TRANSFER_STATUS enumeration set. The
caller should perform an "AND" with the bit of interest and verify if the result is non-zero (as shown in the example) to verify the desired status bit.
This function is thread safe when called in a RTOS application.
Preconditions
The DRV_USART_Initialize routine must have been called for the specified USART driver instance.
DRV_USART_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE myUSARTHandle; // Returned from DRV_USART_Open
if (DRV_USART_TRANSFER_STATUS_RECEIVER_DATA_PRESENT & DRV_USART_TransferStatus(myUSARTHandle))
{
// Data has been received that can be read
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
DRV_USART_TRANSFER_STATUS DRV_USART_TransferStatus( const DRV_HANDLE handle )
Volume V: MPLAB Harmony Framework Driver Libraries Help USART Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1343
DRV_USART_TransmitBufferIsFull Function
Provides the status of the driver's transmit buffer.
Implementation: Static/Dynamic
File
drv_usart.h
C
bool DRV_USART_TransmitBufferIsFull(const DRV_HANDLE handle);
Returns
true - if the transmit buffer is full
false - if the transmit buffer is not full
Description
This routine identifies if the driver's transmit buffer is full or not. This function can be used in conjunction with the DRV_USART_Write and
DRV_USART_WriteByte functions.
Remarks
Does not account for client queued buffers. This function is thread safe when called in a RTOS application.
Preconditions
The DRV_USART_Initialize routine must have been called for the specified USART driver instance.
DRV_USART_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE myUSARTHandle; // Returned from DRV_USART_Open
unsigned int numBytes;
int bytesToWrite;
const uint8_t writeBuffer[35] = "1234567890ABCDEFGHIJKLMNOPn" ;
int writebufferLen = strlen((char *)writeBuffer);
numBytes = 0;
while( numBytes < writebufferLen )
{
if (DRV_USART_TransmitBufferisFull())
{
// Do something else until there is some room in the driver's Transmit buffer.
}
else
{
DRV_USART_WriteByte(myUSARTHandle, writeBuffer[numBytes++]);
}
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
bool DRV_USART_TransmitBufferIsFull( const DRV_HANDLE handle )
DRV_USART_ReceiverBufferIsEmpty Function
Provides the status of the driver's receive buffer.
Implementation: Static/Dynamic
File
drv_usart.h
Volume V: MPLAB Harmony Framework Driver Libraries Help USART Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1344
C
bool DRV_USART_ReceiverBufferIsEmpty(const DRV_HANDLE handle);
Returns
true - if the driver's receive buffer is empty
false - if the driver's receive buffer is not empty
Description
This routine indicates if the driver's receiver buffer is empty. This function can be used in conjunction with the DRV_USART_Read and
DRV_USART_ReadByte functions.
Remarks
Does not account for client queued buffers. This function is safe thread safe when used in a RTOS application.
Preconditions
The DRV_USART_Initialize routine must have been called for the specified USART driver instance.
DRV_USART_Open must have been called to obtain a valid opened device handle.
Example
DRV_HANDLE myUSARTHandle; // Returned from DRV_USART_Open
char myBuffer[MY_BUFFER_SIZE];
unsigned int numBytes;
numBytes = 0;
while( numBytes < MY_BUFFER_SIZE );
{
if ( !DRV_USART_ReceiverBufferIsEmpty(myUSARTHandle) )
{
if( numBytes < MY_BUFFER_SIZE )
{
myBuffer[numBytes++] = DRV_USART_ReadByte (myUSARTHandle);
}
else
{
break;
}
}
// Do something else while more data is received.
}
Parameters
Parameters Description
handle A valid open-instance handle, returned from the driver's open routine
Function
bool DRV_USART_ReceiverBufferIsEmpty( const DRV_HANDLE handle )
DRV_USART_ByteErrorCallbackSet Function
Registers callback to handle for byte error events.
File
drv_usart.h
C
void DRV_USART_ByteErrorCallbackSet(const SYS_MODULE_INDEX index, const DRV_USART_BYTE_EVENT_HANDLER
eventHandler);
Returns
None.
Volume V: MPLAB Harmony Framework Driver Libraries Help USART Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1345
Description
This function allows a callback function to be registered with the driver to handle the error events occurring in the transmit/receive path during byte
transfers.
The callback function should be registered as part of the initialization. The callback functionality is available only in the interrupt mode of operation.
The driver clears the interrupt after invoking the callback function.
Remarks
None
Preconditions
The DRV_USART_Initialize routine must have been called for the specified USART driver instance.
Example
// myAppObj is an application specific state data object.
MY_APP_OBJ myAppObj;
uint8_t mybuffer[MY_BUFFER_SIZE];
// myUSARTHandle is the handle returned by the DRV_USART_Open function.
myUSARTHandle = DRV_USART_Open(DRV_USART_INDEX_0, DRV_IO_INTENT_EXCLUSIVE);
(uintptr_t)&myAppObj );
// Register an event handler with driver. This is done once
DRV_USART_ByteErrorCallbackSet (DRV_USART_INDEX_0, APP_USARTErrorEventHandler);
// Event Processing Technique.
void APP_USARTErrorEventHandler(const SYS_MODULE_INDEX index)
{
// Error has occurred. Handle the event.
}
Parameters
Parameters Description
index Identifier for the object instance to be opened
eventHandler Pointer to the event handler function.
Function
void DRV_USART_ByteErrorCallbackSet
(
const SYS_MODULE_INDEX index,
const DRV_USART_BYTE_EVENT_HANDLER eventHandler
)
DRV_USART_ByteReceiveCallbackSet Function
Registers receive callback function for byte receive event.
File
drv_usart.h
C
void DRV_USART_ByteReceiveCallbackSet(const SYS_MODULE_INDEX index, const DRV_USART_BYTE_EVENT_HANDLER
eventHandler);
Returns
None.
Description
This function allows a receive callback function to be registered with the driver. The callback function is invoked when a byte has been received.
The received byte can then be read using DRV_USART_ReadByte() function.
The callback function should be registered with the driver as part of the initialization. The callback functionality is available only in the interrupt
mode of operation. The driver clears the interrupt after invoking the callback function.
Volume V: MPLAB Harmony Framework Driver Libraries Help USART Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1346
Remarks
None
Preconditions
The DRV_USART_Initialize routine must have been called for the specified USART driver instance.
Example
// myAppObj is an application specific state data object.
MY_APP_OBJ myAppObj;
uint8_t mybuffer[MY_BUFFER_SIZE];
// myUSARTHandle is the handle returned by the DRV_USART_Open function.
myUSARTHandle = DRV_USART_Open(DRV_USART_INDEX_0, DRV_IO_INTENT_EXCLUSIVE);
(uintptr_t)&myAppObj );
// Register an event handler with driver. This is done once
DRV_USART_ByteReceiveCallbackSet(DRV_USART_INDEX_0, APP_USARTReceiveEventHandler);
// Event Processing Technique. Event is received when
// a byte is received.
void APP_USARTReceiveEventHandler(const SYS_MODULE_INDEX index)
{
// Byte has been Received. Handle the event.
// Read byte using DRV_USART_ReadByte ()
// DRV_USART_ReceiverBufferIsEmpty() function can be used to
// check if the receiver buffer is empty.
}
Parameters
Parameters Description
index Identifier for the object instance to be opened
eventHandler Pointer to the event handler function.
Function
void DRV_USART_ByteReceiveCallbackSet
(
const SYS_MODULE_INDEX index,
const DRV_USART_BYTE_EVENT_HANDLER eventHandler
)
DRV_USART_ByteTransmitCallbackSet Function
Registers a callback function for byte transmit event.
File
drv_usart.h
C
void DRV_USART_ByteTransmitCallbackSet(const SYS_MODULE_INDEX index, const DRV_USART_BYTE_EVENT_HANDLER
eventHandler);
Returns
None.
Description
This function allows a transmit callback function to be registered with the driver. The callback function is invoked when a byte has been transmitted
using DRV_USART_WriteByte () function.
The callback function should be registered with the driver prior to any writes to the driver. The callback functionality is available only in the interrupt
mode of operation. The driver clears the interrupt after invoking the callback function.
Volume V: MPLAB Harmony Framework Driver Libraries Help USART Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1347
Remarks
None
Preconditions
The DRV_USART_Initialize routine must have been called for the specified USART driver instance.
Example
// myAppObj is an application specific state data object.
MY_APP_OBJ myAppObj;
uint8_t mybuffer[MY_BUFFER_SIZE];
// myUSARTHandle is the handle returned by the DRV_USART_Open function.
myUSARTHandle = DRV_USART_Open(DRV_USART_INDEX_0, DRV_IO_INTENT_EXCLUSIVE);
(uintptr_t)&myAppObj );
// Register an event handler with driver. This is done once
DRV_USART_ByteTransmitCallbackSet (DRV_USART_INDEX_0, APP_USARTTransmitEventHandler);
DRV_USART_WriteByte (myUSARThandle, myBuffer[0]);
// Event Processing Technique. Event is received when
// the byte is transmitted.
void APP_USARTTransmitEventHandler (const SYS_MODULE_INDEX index)
{
// Byte has been transmitted. Handle the event.
}
Parameters
Parameters Description
index Identifier for the object instance to be opened
eventHandler Pointer to the event handler function.
Function
void DRV_USART_ByteTransmitCallbackSet
(
const SYS_MODULE_INDEX index,
const DRV_USART_BYTE_EVENT_HANDLER eventHandler
)
Files
Files
Name Description
drv_usart.h USART Driver Interface Header File
drv_usart_config_template.h USART Driver Configuration Template.
Description
This section lists the source and header files used by the USART Driver Library.
drv_usart.h
USART Driver Interface Header File
Functions
Name Description
DRV_USART_AddressedBufferAddWrite Schedule a non-blocking addressed driver write operation.
Implementation: Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help USART Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1348
DRV_USART_BaudSet This function changes the USART module baud to the specified value.
Implementation: Static/Dynamic
DRV_USART_BufferAddRead Schedule a non-blocking driver read operation.
Implementation: Static/Dynamic
DRV_USART_BufferAddWrite Schedule a non-blocking driver write operation.
Implementation: Static/Dynamic
DRV_USART_BufferCompletedBytesGet Returns the number of bytes that have been processed for the specified buffer.
Implementation: Static/Dynamic
DRV_USART_BufferEventHandlerSet Allows a client to identify a buffer event handling function for the driver to call back when
queued buffer transfers have finished.
Implementation: Static/Dynamic
DRV_USART_BufferProcessedSizeGet This API will be deprecated and not recommended to use. Use
DRV_USART_BufferCompletedBytesGet to get the number of bytes processed for the
specified buffer.
DRV_USART_BufferRemove Removes a requested buffer from the queue.
Implementation: Static/Dynamic
DRV_USART_ByteErrorCallbackSet Registers callback to handle for byte error events.
DRV_USART_ByteReceiveCallbackSet Registers receive callback function for byte receive event.
DRV_USART_ByteTransmitCallbackSet Registers a callback function for byte transmit event.
DRV_USART_ClientStatus Gets the current client-specific status the USART driver.
Implementation: Static/Dynamic
DRV_USART_Close Closes an opened-instance of the USART driver.
Implementation: Static/Dynamic
DRV_USART_Deinitialize Deinitializes the specified instance of the USART driver module.
Implementation: Static/Dynamic
DRV_USART_ErrorGet This function returns the error(if any) associated with the last client request.
Implementation: Static/Dynamic
DRV_USART_Initialize Initializes the USART instance for the specified driver index.
Implementation: Static/Dynamic
DRV_USART_LineControlSet This function changes the USART module line control to the specified value.
Implementation: Static/Dynamic
DRV_USART_Open Opens the specified USART driver instance and returns a handle to it.
Implementation: Static/Dynamic
DRV_USART_Read Reads data from the USART.
Implementation: Static/Dynamic
DRV_USART_ReadByte Reads a byte of data from the USART.
Implementation: Static/Dynamic
DRV_USART_ReceiverBufferIsEmpty Provides the status of the driver's receive buffer.
Implementation: Static/Dynamic
DRV_USART_ReceiverBufferSizeGet Returns the size of the receive buffer.
Implementation: Static/Dynamic
DRV_USART_Status Gets the current status of the USART driver module.
Implementation: Static/Dynamic
DRV_USART_TasksError Maintains the driver's error state machine and implements its ISR.
Implementation: Static/Dynamic
DRV_USART_TasksReceive Maintains the driver's receive state machine and implements its ISR.
Implementation: Static/Dynamic
DRV_USART_TasksTransmit Maintains the driver's transmit state machine and implements its ISR.
Implementation: Static/Dynamic
DRV_USART_TransferStatus Returns the transmitter and receiver transfer status.
Implementation: Static/Dynamic
DRV_USART_TransmitBufferIsFull Provides the status of the driver's transmit buffer.
Implementation: Static/Dynamic
DRV_USART_TransmitBufferSizeGet Returns the size of the transmit buffer.
Implementation: Static/Dynamic
DRV_USART_Write Writes data to the USART.
Implementation: Static/Dynamic
DRV_USART_WriteByte Writes a byte of data to the USART.
Implementation: Static/Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help USART Driver Library
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1349
Description
USART Driver Interface Header File
The USART device driver provides a simple interface to manage the USART or UART modules on Microchip microcontrollers. This file provides
the interface definition for the USART driver.
File Name
drv_usart.h
Company
Microchip Technology Inc.
drv_usart_config_template.h
USART Driver Configuration Template.
Macros
Name Description
DRV_USART_BAUD_RATE_IDXn Specifies the USART Baud at which the USART driver is initialized.
DRV_USART_BUFFER_QUEUE_SUPPORT Specifies if the Buffer Queue support should be enabled.
DRV_USART_BYTE_MODEL_BLOCKING Enables or Disables DRV_USART_ByteWrite function blocking
behavior.
DRV_USART_BYTE_MODEL_CALLBACK Enables or Disables Callback Feature of the Byte Transfer Model.
DRV_USART_BYTE_MODEL_SUPPORT Specifies if the Byte Model support should be enabled.
DRV_USART_CLIENTS_NUMBER Sets up the maximum number of clients that can be connected to any
hardware instance.
DRV_USART_INDEX USART Static Index selection.
DRV_USART_INSTANCES_NUMBER Sets up the maximum number of hardware instances that can be
supported.
DRV_USART_INTERRUPT_MODE Macro controls interrupt based operation of the driver.
DRV_USART_INTERRUPT_SOURCE_ERROR Defines the error interrupt source for the static driver.
DRV_USART_INTERRUPT_SOURCE_RECEIVE Defines the Receive interrupt source for the static driver.
DRV_USART_INTERRUPT_SOURCE_RECEIVE_DMA Defines the Receive DMA Channel interrupt source for the static driver.
DRV_USART_INTERRUPT_SOURCE_TRANSMIT Defines the Transmit interrupt source for the static driver.
DRV_USART_INTERRUPT_SOURCE_TRANSMIT_DMA Defines the Transmit DMA Channel interrupt source for the static driver.
DRV_USART_PERIPHERAL_ID Configures the USART PLIB Module ID.
DRV_USART_QUEUE_DEPTH_COMBINED Defines the number of entries of all queues in all instances of the driver.
DRV_USART_RCV_QUEUE_SIZE_IDXn Sets the USART Driver Receive Queue Size while using the Buffer
Queue Data Transfer Model.
DRV_USART_READ_WRITE_MODEL_SUPPORT Specifies if Read/Write Model support should be enabled.
DRV_USART_RECEIVE_DMA Defines the USART Driver Receive DMA Channel for the static driver.
DRV_USART_TRANSMIT_DMA Defines the USART Driver Transmit DMA Channel in case of static
driver.
DRV_USART_XMIT_QUEUE_SIZE_IDXn Sets the USART Driver Transmit Queue Size while using the Buffer
Queue Data Transfer Model.
Description
USART Driver Configuration Template
These file provides the list of all the configurations that can be used with the driver. This file should not be included in the driver.
File Name
drv_usart_config_template.h
Company
Microchip Technology Inc.
Wi-Fi Driver Libraries
This section describes the Wi-Fi Driver Libraries available in MPLAB Harmony.
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1350
Description
MRF24WN0MA Wi-Fi PICtail/PICtail Plus Daughter Board: Part number - AC164153
http://www.microchip.com/Developmenttools/ProductDetails.aspx?PartNO=AC164153
The following table lists the library files available for the Wi-Fi Drivers.
Wi-Fi Library File Matrix
Wi-Fi Device PIC32MX795F512L PIC32MZ2048ECH144 PIC32MZ2048EFM144
MRF24WN wdrvext_mx.a wdrvext_mz_ec.a wdrvext_mz_ef.a
MRF24WN Wi-Fi Driver Library
This topic describes the MRF24WN Wi-Fi Driver Library.
Description
The following table lists the library files available for the MRF24WN Wi-Fi Driver.
Introduction
This library provides a low-level abstraction of the MRF24WN Wi-Fi Driver Library that is available on the Microchip family of microcontrollers with
a convenient C language interface. It can be used to simplify low-level access to the module without the necessity of interacting directly with the
module's registers, there by hiding differences from one microcontroller variant to another.
Description
The MRF24WN Wi-Fi Driver Library, in conjunction with the MRF24WN module, allows an application to:
• Join an existing 802.11 Wi-Fi Infrastructure network
• Create a 802.11 Wi-Fi Ad Hoc or Soft AP network
The following application services are provided by the Wi-Fi library:
• Configuring Wi-Fi connection (SSID, security mode, channel list, etc.)
• Join an existing Wi-Fi Infrastructure network
• Create a Wi-Fi Ad Hoc or Soft AP network
• Scan for Wi-Fi Access Point (AP) or Soft AP
• Getting Wi-Fi network status
• Wi-Fi power control
• Wi-Fi console commands
The MAC_layer services are not directly accessible to the application; this portion of the code resides under the TCP/IP Stack MAC module
software layers and is used by stack services to transmit and receive data over a Wi-Fi network. The following diagram shows the interaction of the
primary software blocks in a Wi-Fi application.
Wi-Fi Software Block Diagram
The following table provides information that includes network mode and security mode support by MRF24WN Wi-Fi Driver.
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1351
Using the Library
This topic describes the basic architecture of the MRF24WN Wi-Fi Driver Library and provides information and examples on its use.
Description
Interface Header Files: wdrv_mrf24wn_common.h and wdrv_mrf24wn_api.h
The interface to the MRF24WN Wi-Fi Driver Library is defined in the wdrv_mrf24wn_common.h and wdrv_mrf24wn_api.h header files.
Please refer to the Understanding MPLAB Harmony section for how the driver interacts with the framework.
Abstraction Model
This library provides a low-level abstraction of the MRF24WN Wi-Fi module with a convenient C language interface. This topic describes how that
abstraction is modeled in software and introduces the library's interface.
Description
The MRF24WN Wi-Fi Library provides the following functionality:
• Wi-Fi library initialization
• Wi-Fi network configuration
• Wi-Fi network connection
• Scanning for existing Wi-Fi networks
• Wi-Fi event processing
• Wi-Fi status
• Wi-FI console commands
Library Overview
Refer to the Driver Library Overview section for information on how the driver operates in a system.
The Library Interface functions are divided into various sub-sections, which address one of the blocks or the overall operation of the Wi-Fi module.
Library Interface Section Description
Wi-Fi Initialization
Functions
This section provides functions that initialize the Wi-Fi library and allow its API to be used.
Wi-Fi Status Functions This section provides functions that retrieve the Wi-Fi connection status.
Wi-Fi External Functions This section provides public functions accessible to TCP/IP applications.
Other Functions This section provides additional miscellaneous functions for configuring the Wi-Fi connection.
How the Library Works
This section describes how the MRF24WN Wi-Fi Driver Library operates.
Description
Before the driver is ready for use, its should be configured (compile time configuration).
There are few run-time configuration items that are done during initialization of the driver instance, and a few that are client-specific and are done
using dedicated functions.
To use the MRF24WN Wi-Fi Driver, initialization and client functions should be invoked in a specific sequence to ensure correct operation.
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1352
System Initialization
This section describes initialization and reinitialization features.
Description
Wi-Fi initialization configures the MRF24WN module and then directs it to join (or create) a Wi-Fi network. The MRF24WN module defaults to open
security and scans all channels in the domain. Therefore, to initialize and_connect_with the minimum function call overhead in an open security
network, the following functions can be used:
WDRV_EXT_CmdSSIDSet("MySsidName",strlen("MySsidName");
WDRV_EXT_CmdConnect(); // start the connection process
Alternatively, the following functions could be used to achieve the same effect:
WDRV_EXT_CmdNetModeBSSSet();
WDRV_EXT_CmdSecNoneSet();
WDRV_EXT_CmdSSIDSet("MySsidName",strlen("MySsidName");
WDRV_EXT_CmdConnect();
Client Functionality
This section describes core operation.
Description
From the client perspective, once Wi-Fi initialization is complete and the connection process has started, the client responds to Wi-Fi events. The
client is notified of events by the callback function WDRV_ProcessEvent. The parameters into that function are event and eventInfo, where
event is the event code and eventInfo is additional information about the event.
Wi-Fi Connection Events
/*No Wi-Fi connection exists*/
WDRV_CSTATE_NOT_CONNECTED = 1,
/*Wi-Fi connection in progress*/
WDRV_CSTATE_CONNECTION_IN_PROGRESS = 2,
/*Wi-Fi connected in infrastructure mode*/
WDRV_CSTATE_CONNECTED_INFRASTRUCTURE = 3,
/*Wi-Fi connected in adHoc mode*/
WDRV_CSTATE_CONNECTED_ADHOC = 4,
/*Wi-Fi in process of reconnecting*/
WDRV_CSTATE_RECONNECTION_IN_PROGRESS = 5,
/*Wi-Fi connection temporarily lost*/
WDRV_CSTATE_CONNECTION_TEMPORARY_LOST = 6,
/*Wi-Fi connection permanently lost*/
WDRV_CSTATE_CONNECTION_PERMANENTLY_LOST = 7
Scan Events
WDRV_SOFTAP_EVENT_CONNECTED = 0,
WDRV_SOFTAP_EVENT_DISCONNECTED = 1
Key Events
WDRV_SOFTAP_EVENT_LINK_LOST = 0,
WDRV_SOFTAP_EVENT_RECEIVED_DEAUTH = 1
Disconnect Events
WDRV_DISCONNECT_REASON_NO_NETWORK_AVAIL = 0x01,
WDRV_DISCONNECT_REASON_LOST_LINK = 0x02,
WDRV_DISCONNECT_REASON_DISCONNECT_CMD = 0x03,
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1353
WDRV_DISCONNECT_REASON_BSS_DISCONNECTED = 0x04,
WDRV_DISCONNECT_REASON_AUTH_FAILED = 0x05,
WDRV_DISCONNECT_REASON_ASSOC_FAILED = 0x06,
WDRV_DISCONNECT_REASON_NO_RESOURCES_AVAIL = 0x07,
WDRV_DISCONNECT_REASON_CONNECTION_DENIED = 0x08,
WDRV_DISCONNECT_REASON_INVALID_PROFILE = 0x0A,
WDRV_DISCONNECT_REASON_PROFILE_MISMATCH = 0x0C,
WDRV_DISCONNECT_REASON_CONNECTION_EVICTED = 0x0d
Configuring the Library
The configuration of the MRF24WN Wi-Fi Driver is based on the file system_config.h.
This header file contains the configuration selection for the Wi-Fi Driver. Based on the selections made, the MRF24WN Wi-Fi Driver may support
the selected features. These configuration settings will apply to all instances of the MRF24WN Wi-Fi Driver.
This header can be placed anywhere; however, the path of this header needs to be present in the include search path for a successful build. Refer
to the Applications Help section for more details.
Sample Functionality
The following code provides an example of Wi-Fi Driver configuration.
/*** Wi-Fi Driver Configuration ***/
#define WIFI_USE_RTOS
#define WDRV_EXT_INIT_TASK_STACK_SIZE 512u
#define WDRV_EXT_INIT_TASK_PRIO 6u
#define WDRV_EXT_MAIN_TASK_STACK_SIZE 2048u
#define WDRV_EXT_MAIN_TASK_PRIO 7u
#define WDRV_ASSERT(condition, msg) WDRV_Assert(condition, msg, __FILE__, __LINE__)
#define DRV_WIFI_SPI_INDEX 0
#define DRV_WIFI_SPI_INSTANCE sysObj.spiObjectIdx0
#define DRV_WIFI_NVM_SPACE_ENABLE
#define DRV_WIFI_NVM_SPACE_ADDR (48*1024)
#define MRF_INT_SOURCE INT_SOURCE_EXTERNAL_1
#define MRF_INT_VECTOR INT_VECTOR_INT1
// IO mapping for general control pins, including CS, RESET and HIBERNATE
// MRF24W in SPI 1 slot
#define WF_CS_PORT_CHANNEL PORT_CHANNEL_E
#define WF_CS_BIT_POS 9
#define WF_RESET_PORT_CHANNEL PORT_CHANNEL_F
#define WF_RESET_BIT_POS 0
#define WF_HIBERNATE_PORT_CHANNEL PORT_CHANNEL_F
#define WF_HIBERNATE_BIT_POS 1
#define WF_INT_PRIORITY 3
#define WF_INT_SUBPRIORITY 1
#define WF_INT_PORT_CHANNEL PORT_CHANNEL_E
#define WF_INT_BIT_POS 8
#define WDRV_DEFAULT_NETWORK_TYPE WDRV_NETWORK_TYPE_INFRASTRUCTURE
#define WDRV_DEFAULT_SSID_NAME "MicrochipDemoApp"
#define WDRV_DEFAULT_WIFI_SECURITY_MODE WDRV_SECURITY_OPEN
#define WDRV_DEFAULT_WEP_KEYS_40 "5AFB6C8E77" // default WEP40 key
#define WDRV_DEFAULT_WEP_KEYS_104 "90E96780C739409DA50034FCAA" // default WEP104 key
#define WDRV_DEFAULT_PSK_PHRASE "Microchip 802.11 Secret PSK Password" // default WPA-PSK or WPA2-PSK
passphrase
#define WDRV_DEFAULT_WPS_PIN "12390212" // default WPS PIN
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1354
#define WDRV_DEFAULT_CHANNEL 6
#define WDRV_DEFAULT_POWER_SAVE WDRV_FUNC_DISABLED
Building the Library
This section lists the files that are available in the MRF24WN Wi-Fi Driver Library.
Description
The following three tables list and describe the header (.h) and source (.c) files that implement this library. The parent folder for these files is
/framework/driver/wifi/mrf24wn.
Interface File(s)
This table lists and describes the header files that must be included (i.e., using #include) by any code that uses this library.
Source File Name Description
wdrv_mrf24wn_common.h Contains all data types, define constants for the MRF24WN Wi-Fi Driver.
wdrv_mrf24wn_api.h Contains function prototypes for interfacing to the MRF24WN Wi-Fi Driver.
Required File(s)
All of the required files listed in the following table are automatically added into the MPLAB X IDE project by the MHC
when the library is selected for use.
This table lists and describes the source and header files that must always be included in the MPLAB X IDE project to build this library.
Source File Name Description
wdrv_mrf24wn_cli.c Provides access to MRF24WN Wi-Fi Driver controller.
wdrv_mrf24wn_config_data.c Stores and retrieves MRF24WN Wi-Fi Driver configuration information in Non-volatile Memory (NVM).
wdrv_mrf24wn_connmgr.c Provides access to MRF24WN Wi-Fi Driver controller for connection manager.
wdrv_mrf24wn_events.c Provides access to MRF24WN Wi-Fi Driver controller for MAC events.
wdrv_mrf24wn_iwpriv.c Provides functions to configure optional (private) parameters of the MRF24WN Wi-Fi Driver.
wdrv_mrf24wn_main.c Module for Microchip TCP/IP Stack PIC32 implementation for multiple Wi-Fi MAC support.
wdrv_mrf24wn_misc.c Miscellaneous support functions and data types for the MRF24WN Wi-Fi Driver.
wdrv_mrf24wn_osal.c RTOS wrapper functions for the MRF24WN Wi-Fi Driver.
wdrv_mrf24wn_scan_helper.c Provides helper functions to access scan results.
Optional File(s)
This table lists and describes the source and header files that may optionally be included if required for the desired implementation.
Source File Name Description
N/A The MRF24WN Wi-Fi Driver controller has no optional files.
Module Dependencies
The MRF24WN Wi-Fi Driver Library depends on the following modules:
• SPI Driver Library
• NVM Driver Library
• UART Driver Library
• USB Driver Library
• Operating System Abstraction Layer (OSAL) Library Help
• Clock System Service Library
• System Service Library Introduction
• Console System Service Library
• File System Service Library
• Interrupt System Service Library
• Timer System Service Library
• Debug System Service Library
• Ports System Service Library
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1355
• FreeRTOS Library Help
• Crypto Library
• Peripheral Libraries
Console Commands
This section describes the console commands available for the MRF24WN Wi-Fi Driver.
Description
Both the Web Server and the EasyConfig demonstrations support the followings commands, which enable control over the Wi-Fi settings.
Command: deleteconf
Parameters Description
None. Wi-Fi console command to erase saved Wi-Fi configuration in memory.
Command: iwconfig
Parameters Description
[ ssid ] name: Specifies the name of the SSID (1-32 ASCII characters).
[ mode ]
idle: Disconnected from the current configuration.
managed: Connects in infrastructure mode to the currently set SSID.
[ power ]
enable: Enables all Power-Saving features (PS_POLL). Will wake up to check for all types of traffic (unicast, multicast, and
broadcast).
disable: Disables any Power-Saving features. Will always be in an active power state.
[ security ] mode: open/wep40/wep104/wpa/wpa2/pin/pbc. For example:
iwconfig security open
iwconfig security wep40
iwconfig security wep104
iwconfig security wpa
iwconfig security wpa2
iwconfig security pin
iwconfig security pbc
[ scan ] Starts a Wi-Fi scan.
[ scanget
]
scan_index: Retrieves the scan result after the scan completes (1 - n).
Command: mac
Parameters Description
None. Wi-Fi console command to retrieve the MAC address of the MRF24WN module.
Command: readconf
Parameters Description
None. Wi-Fi console command to read saved Wi-Fi configuration in memory.
Command: saveconf
Parameters Description
None. Wi-Fi console command to save Wi-Fi configuration to memory.
Library Interface
a) Wi-Fi Initialization Functions
Name Description
WDRV_SPI_In Receives data from the module through the SPI bus.
Implementation: Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1356
WDRV_SPI_Out Sends data out to the module through the SPI bus.
Implementation: Dynamic
WDRV_GPIO_Init Initializes the GPIO objects for the Wi-Fi driver.
Implementation: Dynamic
WDRV_GPIO_PowerOff Powers off the MRF24WN module.
Implementation: Dynamic
WDRV_GPIO_PowerOn Powers on the MRF24WN module.
Implementation: Dynamic
WDRV_IsPowerOff Checks if MRF24WN is turned off.
Implementation: Dynamic
WDRV_MRF24WN_ISR Wi-Fi driver (MRF24WN-specific) interrupt service routine.
Implementation: Dynamic
b) Wi-Fi Status Functions
Name Description
WDRV_EXT_CmdConnectContextChannelGet Gets the AP channel
Implementation: Dynamic
WDRV_EXT_CmdPowerSaveGet Retrieves current power save status.
Implementation: Dynamic
WDRV_EXT_ScanResultGet Reads the selected scan results back from the MRF24WN module.
Implementation: Dynamic
c) External Functions
Name Description
WDRV_EXT_CmdNetModeIBSSSet Sets the Wi-Fi network type to Adhoc.
Implementation: Dynamic
WDRV_EXT_CmdSecWPA2Set Sets Wi-Fi security to WPA2.
Implementation: Dynamic
WDRV_EXT_Initialize Initializes the MRF24WN Wi-Fi driver.
Implementation: Dynamic
WDRV_EXT_Initialize Initializes the WINC1500 Wi-Fi driver.
Implementation: Dynamic
WDRV_EXT_PrivConfig Configures g_wdrvext_priv parameter.
Implementation: Dynamic
e) Private Configuration Functions
Name Description
iwpriv_config_write Writes to the Wi-Fi context configuration which is currently used by Wi-Fi driver.
Implementation: Dynamic
iwpriv_connstatus_get Gets the Wi-Fi connection status.
Implementation: Dynamic
iwpriv_devinfo_get Gets the device information.
Implementation: Dynamic
iwpriv_initialconn_set Sets the initial connection status of Wi-Fi driver.
Implementation: Dynamic
iwpriv_initstatus_get Gets the initialization status of Wi-Fi driver.
Implementation: Dynamic
iwpriv_is_servermode Checks if the passed Wi-Fi context configuration is operating in server mode.
Implementation: Dynamic
iwpriv_leftclient_get Gets the left client's information.
Implementation: Dynamic
iwpriv_mcastfilter_set Adds a MAC address to the multi-cast filter.
Implementation: Dynamic
iwpriv_nettype_get Gets the current network type.
Implementation: Dynamic
iwpriv_nettype_set Sets the current network type.
Implementation: Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1357
iwpriv_numberofscanresults_get Gets the number of scan results.
Implementation: Dynamic
iwpriv_powersave_config Enables or disables Power Save mode in Wi-Fi driver.
Implementation: Dynamic
iwpriv_prescan_start Starts prescan.
Implementation: Dynamic
iwpriv_scan_start Starts scan.
Implementation: Dynamic
iwpriv_scanstatus_get Gets the prescan status.
Implementation: Dynamic
iwpriv_ssid_get Gets the current SSID.
Implementation: Dynamic
iwpriv_ssid_set Sets the current SSID.
Implementation: Dynamic
iwpriv_execute This is function iwpriv_execute.
iwpriv_get This is function iwpriv_get.
iwpriv_prescan_isfinished Checks if the prescan is complete.
Implementation: Dynamic
iwpriv_prescan_option_get To see if prescan will run before next connection.
Implementation: Dynamic
iwpriv_prescan_option_set To run prescan or not.
Implementation: Dynamic
iwpriv_set This is function iwpriv_set.
iwpriv_adhocctx_set Sets the Ad hoc network context information.
Implementation: Dynamic
iwpriv_config_read Reads the Wi-Fi context configuration.
Implementation: Dynamic
f) Data Types and Constants
Name Description
IWPRIV_CONN_STATUS This is type IWPRIV_CONN_STATUS.
IWPRIV_STATUS This is type IWPRIV_STATUS.
IWPRIV_CMD This is type IWPRIV_CMD.
IWPRIV_EXECUTE_PARAM This is type IWPRIV_EXECUTE_PARAM.
IWPRIV_GET_PARAM This is type IWPRIV_GET_PARAM.
IWPRIV_PARAM_CLIENTINFO This is type IWPRIV_PARAM_CLIENTINFO.
IWPRIV_PARAM_CONTEXT This is type IWPRIV_PARAM_CONTEXT.
IWPRIV_PARAM_DEVICEINFO This is type IWPRIV_PARAM_DEVICEINFO.
IWPRIV_SCAN_STATUS This is type IWPRIV_SCAN_STATUS.
IWPRIV_SET_PARAM This is type IWPRIV_SET_PARAM.
IWPRIV_PARAM_CONFIG This is type IWPRIV_PARAM_CONFIG.
IWPRIV_PARAM_CONNECT This is type IWPRIV_PARAM_CONNECT.
IWPRIV_PARAM_DRIVERSTATUS This is type IWPRIV_PARAM_DRIVERSTATUS.
IWPRIV_PARAM_FWUPGRADE This is type IWPRIV_PARAM_FWUPGRADE.
IWPRIV_PARAM_MULTICASTFILTER This is type IWPRIV_PARAM_MULTICASTFILTER.
IWPRIV_PARAM_NETWORKTYPE This is type IWPRIV_PARAM_NETWORKTYPE.
IWPRIV_PARAM_OPERATIONMODE This is type IWPRIV_PARAM_OPERATIONMODE.
IWPRIV_PARAM_POWERSAVE This is type IWPRIV_PARAM_POWERSAVE.
IWPRIV_PARAM_SCAN This is type IWPRIV_PARAM_SCAN.
IWPRIV_PARAM_SSID This is type IWPRIV_PARAM_SSID.
Description
This section describes the Application Programming Interface (API) functions of the MRF24WN Wi-Fi Driver.
Refer to each section for a detailed description.
a) Wi-Fi Initialization Functions
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1358
WDRV_SPI_In Function
Receives data from the module through the SPI bus.
Implementation: Dynamic
File
wdrv_mrf24wn_api.h
C
void WDRV_SPI_In(uint8_t *const OutBuf, uint16_t OutSize, uint8_t *const InBuf, uint16_t InSize);
Returns
None.
Description
This function receives data from the module through the SPI bus.
Remarks
None.
Preconditions
The TCP/IP stack should be initialized.
Parameters
Parameters Description
bufOut buffer pointer of output command
OutSize the command size
InBuf buffer pointer of input data
InSize the input data size
Function
void WDRV_SPI_In(uint8_t const *const OutBuf, uint16_t OutSize,
uint8_t *const InBuf, uint16_t InSize)
WDRV_SPI_Out Function
Sends data out to the module through the SPI bus.
Implementation: Dynamic
File
wdrv_mrf24wn_api.h
C
void WDRV_SPI_Out(uint8_t *const bufOut, uint16_t OutSize);
Returns
None.
Description
This function sends data out to the module through the SPI bus.
Remarks
None.
Preconditions
The TCP/IP stack should be initialized.
Parameters
Parameters Description
bufOut buffer pointer of output data
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1359
OutSize the data size
Function
void WDRV_SPI_Out(uint8_t const *const bufOut, uint16_t OutSize)
WDRV_GPIO_Init Function
Initializes the GPIO objects for the Wi-Fi driver.
Implementation: Dynamic
File
wdrv_mrf24wn_api.h
C
void WDRV_GPIO_Init();
Returns
None.
Description
This function initializes the GPIO objects for the Wi-Fi driver.
Remarks
None.
Preconditions
The TCP/IP stack should be initialized.
Function
void WDRV_GPIO_Init(void)
WDRV_GPIO_PowerOff Function
Powers off the MRF24WN module.
Implementation: Dynamic
File
wdrv_mrf24wn_api.h
C
void WDRV_GPIO_PowerOff();
Returns
None.
Description
This function powers off the MRF24WN module.
Remarks
None.
Preconditions
The TCP/IP stack should be initialized.
Function
void WDRV_GPIO_PowerOff(void)
WDRV_GPIO_PowerOn Function
Powers on the MRF24WN module.
Implementation: Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1360
File
wdrv_mrf24wn_api.h
C
void WDRV_GPIO_PowerOn();
Returns
None.
Description
This function powers on the MRF24WN module.
Remarks
None.
Preconditions
The TCP/IP stack should be initialized.
Function
void WDRV_GPIO_PowerOn(void)
WDRV_IsPowerOff Function
Checks if MRF24WN is turned off.
Implementation: Dynamic
File
wdrv_mrf24wn_api.h
C
bool WDRV_IsPowerOff();
Returns
• 0 - Indicates that MRF24WN is turned off
• Non-zero value - Indicates that MRF24WN is on
Description
This function checks if MRF24WN is turned off.
Remarks
None.
Function
bool WDRV_IsPowerOff(void)
WDRV_MRF24WN_ISR Function
Wi-Fi driver (MRF24WN-specific) interrupt service routine.
Implementation: Dynamic
File
wdrv_mrf24wn_api.h
C
void WDRV_MRF24WN_ISR();
Returns
None.
Description
This function is the Wi-Fi driver (MRF24WN-specific) interrupt service routine.
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1361
Remarks
None.
Preconditions
Wi-Fi initialization must be complete.
Function
void WDRV_MRF24WN_ISR(void)
b) Wi-Fi Status Functions
WDRV_EXT_CmdConnectContextChannelGet Function
Gets the AP channel
Implementation: Dynamic
File
wdrv_mrf24wn_api.h
C
uint32_t WDRV_EXT_CmdConnectContextChannelGet(uint16_t * bssChannel);
Returns
• 0 - Indicates success
• Non-zero value - Indicates failure
Description
This function gets the current AP channel.
Remarks
None.
Preconditions
Wi-Fi initialization must be complete.
Parameters
Parameters Description
bssChannel pointer where the current AP channel will be written
Function
uint32_t WDRV_EXT_CmdConnectContextChannelGet(uint16_t *bssChannel)
WDRV_EXT_CmdPowerSaveGet Function
Retrieves current power save status.
Implementation: Dynamic
File
wdrv_mrf24wn_api.h
C
uint32_t WDRV_EXT_CmdPowerSaveGet(bool * enabled);
Returns
• 0 - Indicates success
• Non-zero value - Indicates failure
Description
This function retrieves the current power save status.
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1362
Remarks
None.
Preconditions
Wi-Fi initialization must be complete.
Parameters
Parameters Description
enabled pointer where the current power save status will be written
Function
uint32_t WDRV_EXT_CmdPowerSaveGet(bool *enabled)
WDRV_EXT_ScanResultGet Function
Reads the selected scan results back from the MRF24WN module.
Implementation: Dynamic
File
wdrv_mrf24wn_api.h
C
void WDRV_EXT_ScanResultGet(uint16_t idx, WDRV_SCAN_RESULT * p_scanResult);
Returns
• 0 - Indicates success
• Non-zero value - Indicates failure
Description
After a scan has completed this function is used to read one scan result at a time from the MRF24WN module.
Remarks
None.
Preconditions
Wi-Fi initialization must be complete.
Parameters
Parameters Description
listIndex index (0 based list) of the scan entry to retrieve
p_scanResult pointer to where scan result is written
Function
void WDRV_EXT_ScanResultGet(uint8_t listIndex, WDRV_SCAN_RESULT *p_scanResult)
c) External Functions
WDRV_EXT_CmdNetModeIBSSSet Function
Sets the Wi-Fi network type to Adhoc.
Implementation: Dynamic
File
wdrv_mrf24wn_api.h
C
uint32_t WDRV_EXT_CmdNetModeIBSSSet();
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1363
Returns
• 0 - Indicates success
• Non-zero value - Indicates failure
Description
This function sets the Wi-Fi network type to Adhoc.
Remarks
None.
Preconditions
Wi-Fi initialization must be complete.
Function
uint32_t WDRV_EXT_CmdNetModeIBSSSet(void)
WDRV_EXT_CmdSecWPA2Set Function
Sets Wi-Fi security to WPA2.
Implementation: Dynamic
File
wdrv_mrf24wn_api.h
C
uint32_t WDRV_EXT_CmdSecWPA2Set(uint8_t * key, uint16_t len);
Returns
• 0 - Indicates success
• Non-zero value - Indicates failure
Description
This function sets the Wi-Fi security to WPA2. One can only connect to an AP that is running the same WPA2 mode.
Remarks
None.
Preconditions
Wi-Fi initialization must be complete and in an unconnected state.
Parameters
Parameters Description
key pointer to the WPA2 key buffer
len WPA2 key length
Function
uint32_t WDRV_EXT_CmdSecWPA2Set(uint8_t *key, uint16_t len)
WDRV_EXT_Initialize Function
Initializes the MRF24WN Wi-Fi driver.
Implementation: Dynamic
File
wdrv_mrf24wn_api.h
C
int32_t WDRV_EXT_Initialize(const WDRV_CALLBACKS *const CB);
Returns
• 0 - Indicates success
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1364
• non-zero value - Indicates failure
Description
This function initializes the MRF24WN Wi-Fi driver, making it ready for clients to use.
Remarks
None.
Preconditions
None.
Parameters
Parameters Description
CB pointer to callback functions
Function
int32_t WDRV_EXT_Initialize(const WDRV_CALLBACKS *const CB)
WDRV_EXT_Initialize Function
Initializes the WINC1500 Wi-Fi driver.
Implementation: Dynamic
File
wdrv_winc1500_api.h
C
void WDRV_EXT_Initialize(const WDRV_HOOKS *const ehooks, bool initWait);
Returns
None.
Description
This function initializes the WINC1500 Wi-Fi driver, making it ready for clients to use.
Remarks
None.
Preconditions
None.
Parameters
Parameters Description
ehooks pointer to WDRV layer hooks
initWait true will put WDRV in wait during initialization
Function
void WDRV_EXT_Initialize(const WDRV_HOOKS *const ehooks, bool initWait)
WDRV_EXT_PrivConfig Function
Configures g_wdrvext_priv parameter.
Implementation: Dynamic
File
wdrv_mrf24wn_api.h
C
void WDRV_EXT_PrivConfig(uint32_t * config);
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1365
Returns
None.
Description
This function configures g_wdrvext_priv parameter.
Remarks
None.
Preconditions
None.
Parameters
Parameters Description
config pointer to the parameter array
Function
void WDRV_EXT_PrivConfig(uint32_t *config)
d) GPIO Functions
e) Private Configuration Functions
iwpriv_config_write Function
Writes to the Wi-Fi context configuration which is currently used by Wi-Fi driver.
Implementation: Dynamic
File
wdrv_mrf24wn_iwpriv.h
C
void iwpriv_config_write(void * wifi_cfg);
Returns
None.
Description
This function reads from a passed pointer, copies everything from it, and writes to the Wi-Fi context configuration, which is currently used by the
Wi-Fi driver.
Remarks
None.
Preconditions
Wi-Fi initialization must be complete.
Parameters
Parameters Description
wifi_cfg pointer to where the context configuration is stored
Function
void iwpriv_config_write(void *wifi_cfg)
iwpriv_connstatus_get Function
Gets the Wi-Fi connection status.
Implementation: Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1366
File
wdrv_mrf24wn_iwpriv.h
C
IWPRIV_CONN_STATUS iwpriv_connstatus_get();
Returns
Status of current Wi-Fi connection. See the definition for the IWPRIV_CONN_STATUS structure.
Description
This function gets the Wi-Fi connection status.
Remarks
IWPRIV_CONNECTION_FAILED does not necessarily mean that the module fails to connect to the network. It stands on the application's
perspective, and actually can be customized. For example, in the Web Server demonstrations's use case,
WDRV_CSTATE_CONNECTION_PERMANENTLY_LOST is treated as a fail case and will trigger the application to restart.
Preconditions
Wi-Fi initialization must be complete.
Function
IWPRIV_CONN_STATUS iwpriv_connstatus_get(void)
iwpriv_devinfo_get Function
Gets the device information.
Implementation: Dynamic
File
wdrv_mrf24wn_iwpriv.h
C
void iwpriv_devinfo_get(void * info);
Returns
None.
Description
This function returns the device information.
Remarks
None.
Preconditions
Wi-Fi initialization must be complete.
Parameters
Parameters Description
info pointer to where the device information is written
Function
void iwpriv_devinfo_get(void *info)
iwpriv_initialconn_set Function
Sets the initial connection status of Wi-Fi driver.
Implementation: Dynamic
File
wdrv_mrf24wn_iwpriv.h
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1367
C
void iwpriv_initialconn_set(bool connect);
Returns
None.
Description
This function sets the initial connection status of Wi-Fi driver. After Wi-Fi initialization, it decides whether or not to start the Wi-Fi connection.
Remarks
This function is mainly used to implement prescan. It has to be called before Wi-Fi driver's initialization is finished to be effective.
Preconditions
Wi-Fi initialization must be complete.
Parameters
Parameters Description
connect boolean value which indicates whether or not to start an initial connect
Function
void iwpriv_initialconn_set(bool connect)
iwpriv_initstatus_get Function
Gets the initialization status of Wi-Fi driver.
Implementation: Dynamic
File
wdrv_mrf24wn_iwpriv.h
C
uint8_t iwpriv_initstatus_get();
Returns
Current initialization status of the Wi-Fi driver (IWPRIV_READY or IWPRIV_IN_PROGRESS).
Description
This function returns the initialization status of the Wi-Fi driver.
Remarks
None.
Preconditions
None.
Function
uint8_t iwpriv_initstatus_get(void)
iwpriv_is_servermode Function
Checks if the passed Wi-Fi context configuration is operating in server mode.
Implementation: Dynamic
File
wdrv_mrf24wn_iwpriv.h
C
bool iwpriv_is_servermode();
Returns
• true - Wi-Fi context configuration is operating in server mode
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1368
• false - Wi-Fi context configuration is not operating in server mode
Description
This function checks if the passed Wi-Fi context configuration is operating in server mode, which includes Ad hoc mode and SoftAP mode.
Remarks
None.
Preconditions
Wi-Fi initialization must be complete.
Function
bool iwpriv_is_servermode(void)
iwpriv_leftclient_get Function
Gets the left client's information.
Implementation: Dynamic
File
wdrv_mrf24wn_iwpriv.h
C
void iwpriv_leftclient_get(bool * updated, TCPIP_MAC_ADDR * addr);
Returns
None.
Description
This function returns the left client's information when the Wi-Fi module works in server mode and has the DHCP Server enabled.
Remarks
None.
Preconditions
Wi-Fi initialization must be complete.
Parameters
Parameters Description
updated if the left client's information needs to be updated
addr MAC address of the left client
Function
void iwpriv_leftclient_get(bool *updated, TCPIP_MAC_ADDR *addr)
iwpriv_mcastfilter_set Function
Adds a MAC address to the multi-cast filter.
Implementation: Dynamic
File
wdrv_mrf24wn_iwpriv.h
C
IWPRIV_STATUS iwpriv_mcastfilter_set(uint8_t * addr);
Returns
Status of the set operation, IWPRIV_READY or IWPRIV_ERROR. See definition for the IWPRIV_STATUS structure.
Description
This function adds a MAC address to the multi-cast filter.
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1369
Remarks
None.
Preconditions
Wi-Fi initialization must be complete.
Parameters
Parameters Description
addr pointer to where the MAC address is stored
Function
IWPRIV_STATUS iwpriv_mcastfilter_set(uint8_t *addr)
iwpriv_nettype_get Function
Gets the current network type.
Implementation: Dynamic
File
wdrv_mrf24wn_iwpriv.h
C
void iwpriv_nettype_get(uint8_t * netType);
Returns
None.
Description
This function returns the current network type.
Remarks
None.
Preconditions
Wi-Fi initialization must be complete.
Parameters
Parameters Description
netType pointer to where the network type is written
Function
void iwpriv_nettype_get(uint8_t *netType)
iwpriv_nettype_set Function
Sets the current network type.
Implementation: Dynamic
File
wdrv_mrf24wn_iwpriv.h
C
void iwpriv_nettype_set(uint8_t netType);
Returns
None.
Description
This function sets the current network type.
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1370
Remarks
None.
Preconditions
Wi-Fi initialization must be complete.
Parameters
Parameters Description
netType the network type to set
Function
void iwpriv_nettype_set(uint8_t netType)
iwpriv_numberofscanresults_get Function
Gets the number of scan results.
Implementation: Dynamic
File
wdrv_mrf24wn_iwpriv.h
C
uint16_t iwpriv_numberofscanresults_get();
Returns
Number of scan results.
Description
This function gets the number of scan results.
Remarks
None.
Preconditions
Wi-Fi initialization must be complete.
Function
uint16_t iwpriv_numberofscanresults_get(void)
iwpriv_powersave_config Function
Enables or disables Power Save mode in Wi-Fi driver.
Implementation: Dynamic
File
wdrv_mrf24wn_iwpriv.h
C
void iwpriv_powersave_config(bool enabled);
Returns
None.
Description
This function enables or disables Power Save mode in Wi-Fi driver, which depends on the passed boolean value.
Remarks
None.
Preconditions
Wi-Fi initialization must be complete.
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1371
Parameters
Parameters Description
enabled boolean value which indicates to enable or disable Power Save mode in Wi-Fi driver
Function
void iwpriv_powersave_config(bool enabled)
iwpriv_prescan_start Function
Starts prescan.
Implementation: Dynamic
File
wdrv_mrf24wn_iwpriv.h
C
void iwpriv_prescan_start();
Returns
None.
Description
This function directs the Wi-Fi driver to start a prescan.
Remarks
None.
Preconditions
Wi-Fi initialization must be complete.
Function
void iwpriv_prescan_start(void)
iwpriv_scan_start Function
Starts scan.
Implementation: Dynamic
File
wdrv_mrf24wn_iwpriv.h
C
void iwpriv_scan_start();
Returns
None.
Description
The function starts a Wi-Fi scan.
Remarks
None.
Preconditions
Wi-Fi initialization must be complete.
Function
void iwpriv_scan_start(void)
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1372
iwpriv_scanstatus_get Function
Gets the prescan status.
Implementation: Dynamic
File
wdrv_mrf24wn_iwpriv.h
C
IWPRIV_SCAN_STATUS iwpriv_scanstatus_get();
Returns
Prescan status: IWPRIV_SCAN_IDLE, IWPRIV_SCAN_IN_PROGRESS, IWPRIV_SCAN_NO_AP_FOUND or IWPRIV_SCAN_SUCCESSFUL.
See the definition for the IWPRIV_SCAN_STATUS structure.
Description
This function gets the prescan status.
Remarks
None.
Preconditions
Wi-Fi initialization must be complete.
Function
IWPRIV_SCAN_STATUS iwpriv_scanstatus_get(void)
iwpriv_ssid_get Function
Gets the current SSID.
Implementation: Dynamic
File
wdrv_mrf24wn_iwpriv.h
C
void iwpriv_ssid_get(uint8_t * ssid, uint8_t * ssidLen);
Returns
None.
Description
This function returns the current SSID.
Remarks
None.
Preconditions
Wi-Fi initialization must be complete.
Parameters
Parameters Description
ssid pointer to where the SSID is written
ssidLen pointer to where the SSID length is written
Function
void iwpriv_ssid_get(uint8_t *ssid, uint8_t *ssidLen)
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1373
iwpriv_ssid_set Function
Sets the current SSID.
Implementation: Dynamic
File
wdrv_mrf24wn_iwpriv.h
C
void iwpriv_ssid_set(uint8_t * ssid, uint8_t ssidLen);
Returns
None.
Description
This function sets the current SSID.
Remarks
None.
Preconditions
Wi-Fi initialization must be complete.
Parameters
Parameters Description
ssid pointer to where the SSID is stored
ssidLen pointer to where the SSID length is stored
Function
void iwpriv_ssid_set(uint8_t *ssid, uint8_t ssidLen)
iwpriv_execute Function
File
wdrv_mrf24wn_iwpriv.h
C
void iwpriv_execute(IWPRIV_CMD cmd, IWPRIV_EXECUTE_PARAM * params);
Description
This is function iwpriv_execute.
iwpriv_get Function
File
wdrv_mrf24wn_iwpriv.h
C
void iwpriv_get(IWPRIV_CMD cmd, IWPRIV_GET_PARAM * params);
Description
This is function iwpriv_get.
iwpriv_prescan_isfinished Function
Checks if the prescan is complete.
Implementation: Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1374
File
wdrv_mrf24wn_iwpriv.h
C
bool iwpriv_prescan_isfinished();
Returns
None.
Description
This function checks if the prescan is complete.
Remarks
None.
Preconditions
Wi-Fi initialization must be complete.
Function
bool iwpriv_prescan_isfinished(void)
iwpriv_prescan_option_get Function
To see if prescan will run before next connection.
Implementation: Dynamic
File
wdrv_mrf24wn_iwpriv.h
C
bool iwpriv_prescan_option_get();
Returns
None.
Description
This function checks whether or not the prescan will run before next connection.
Remarks
None.
Preconditions
Wi-Fi initialization must be complete.
Function
bool iwpriv_prescan_option_get(void)
iwpriv_prescan_option_set Function
To run prescan or not.
Implementation: Dynamic
File
wdrv_mrf24wn_iwpriv.h
C
void iwpriv_prescan_option_set(bool scan);
Returns
None.
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1375
Description
This function controls whether or not to run prescan.
Remarks
Prescan means the scan runs before the module is connected. It needs to use multiple functions in this file. Please refer to the Easy Configuration
demonstration to see the correct usage of prescan.
After the the module is connected, MRF24WN module can also do regular scans. But it cannot perform a scan when the connection is in progress.
Preconditions
Wi-Fi initialization must be complete.
Parameters
Parameters Description
scan true: run prescan before next connection
false do not run prescan before next connection
Function
void iwpriv_prescan_option_set(bool scan)
iwpriv_set Function
File
wdrv_mrf24wn_iwpriv.h
C
void iwpriv_set(IWPRIV_CMD cmd, IWPRIV_SET_PARAM * params);
Description
This is function iwpriv_set.
iwpriv_adhocctx_set Function
Sets the Ad hoc network context information.
Implementation: Dynamic
File
wdrv_mrf24wn_iwpriv.h
C
void iwpriv_adhocctx_set(void * p_cxt);
Returns
None.
Description
This function sets the current Ad hoc network context information by reading from a passed pointer.
Remarks
None.
Preconditions
Wi-Fi initialization must be complete.
Parameters
Parameters Description
p_cxt pointer to where the Ad hoc network context is stored
Function
void iwpriv_adhocctx_set(void *p_cxt)
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1376
iwpriv_config_read Function
Reads the Wi-Fi context configuration.
Implementation: Dynamic
File
wdrv_mrf24wn_iwpriv.h
C
void iwpriv_config_read(void * wifi_cfg);
Returns
None.
Description
This function reads the current Wi-Fi context configuration, copies and stores the whole structure to the pointer passed to the function.
Remarks
None.
Preconditions
Wi-Fi initialization must be complete.
Parameters
Parameters Description
wifi_cfg pointer to where the context configuration is written
Function
void iwpriv_config_read(void *wifi_cfg)
f) Data Types and Constants
IWPRIV_CONN_STATUS Enumeration
File
wdrv_mrf24wn_iwpriv.h
C
typedef enum {
IWPRIV_CONNECTION_FAILED = -1,
IWPRIV_CONNECTION_SUCCESSFUL,
IWPRIV_CONNECTION_IDLE,
IWPRIV_CONNECTION_IN_PROGRESS,
IWPRIV_CONNECTION_REESTABLISHED
} IWPRIV_CONN_STATUS;
Description
This is type IWPRIV_CONN_STATUS.
IWPRIV_STATUS Enumeration
File
wdrv_mrf24wn_iwpriv.h
C
typedef enum {
IWPRIV_ERROR = -1,
IWPRIV_READY,
IWPRIV_IN_PROGRESS
} IWPRIV_STATUS;
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1377
Description
This is type IWPRIV_STATUS.
IWPRIV_CMD Enumeration
File
wdrv_mrf24wn_iwpriv.h
C
typedef enum {
PRESCAN_OPTION_GET,
PRESCAN_OPTION_SET,
PRESCAN_START,
PRESCAN_ISFINISHED_GET,
SCAN_START,
SCANSTATUS_GET,
SCANRESULT_GET,
SCANRESULTS_COUNT_GET,
CONFIG_GET,
CONFIG_SET,
SSID_GET,
SSID_SET,
NETWORKTYPE_GET,
NETWORKTYPE_SET,
CONNSTATUS_GET,
CLIENTINFO_GET,
DEVICEINFO_GET,
DRVSTATUS_GET,
FWUPGRADEREQUEST_GET,
OPERATIONMODE_GET,
INITCONN_OPTION_SET,
ADHOCCTX_SET,
MULTICASTFILTER_SET,
POWERSAVE_SET
} IWPRIV_CMD;
Description
This is type IWPRIV_CMD.
IWPRIV_EXECUTE_PARAM Union
File
wdrv_mrf24wn_iwpriv.h
C
typedef union {
} IWPRIV_EXECUTE_PARAM;
Description
This is type IWPRIV_EXECUTE_PARAM.
IWPRIV_GET_PARAM Union
File
wdrv_mrf24wn_iwpriv.h
C
typedef union {
IWPRIV_PARAM_SCAN scan;
IWPRIV_PARAM_CONFIG cfg;
IWPRIV_PARAM_SSID ssid;
IWPRIV_PARAM_NETWORKTYPE netType;
IWPRIV_PARAM_CONNECT conn;
IWPRIV_PARAM_CLIENTINFO clientInfo;
IWPRIV_PARAM_DEVICEINFO devInfo;
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1378
IWPRIV_PARAM_DRIVERSTATUS driverStatus;
IWPRIV_PARAM_FWUPGRADE fwUpgrade;
IWPRIV_PARAM_OPERATIONMODE opMode;
} IWPRIV_GET_PARAM;
Description
This is type IWPRIV_GET_PARAM.
IWPRIV_PARAM_CLIENTINFO Structure
File
wdrv_mrf24wn_iwpriv.h
C
typedef struct {
uint8_t * addr;
bool updated;
} IWPRIV_PARAM_CLIENTINFO;
Members
Members Description
uint8_t * addr; it usually points to a MAC address, which is an array of 6 uint8_t elements
Description
This is type IWPRIV_PARAM_CLIENTINFO.
IWPRIV_PARAM_CONTEXT Structure
File
wdrv_mrf24wn_iwpriv.h
C
typedef struct {
void * context;
} IWPRIV_PARAM_CONTEXT;
Description
This is type IWPRIV_PARAM_CONTEXT.
IWPRIV_PARAM_DEVICEINFO Structure
File
wdrv_mrf24wn_iwpriv.h
C
typedef struct {
void * info;
} IWPRIV_PARAM_DEVICEINFO;
Description
This is type IWPRIV_PARAM_DEVICEINFO.
IWPRIV_SCAN_STATUS Enumeration
File
wdrv_mrf24wn_iwpriv.h
C
typedef enum {
IWPRIV_SCAN_SUCCESSFUL,
IWPRIV_SCAN_IDLE,
IWPRIV_SCAN_IN_PROGRESS,
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1379
IWPRIV_SCAN_NO_AP_FOUND
} IWPRIV_SCAN_STATUS;
Description
This is type IWPRIV_SCAN_STATUS.
IWPRIV_SET_PARAM Union
File
wdrv_mrf24wn_iwpriv.h
C
typedef union {
IWPRIV_PARAM_SCAN scan;
IWPRIV_PARAM_CONFIG cfg;
IWPRIV_PARAM_SSID ssid;
IWPRIV_PARAM_NETWORKTYPE netType;
IWPRIV_PARAM_CONNECT conn;
IWPRIV_PARAM_CONTEXT ctx;
IWPRIV_PARAM_MULTICASTFILTER multicast;
IWPRIV_PARAM_POWERSAVE powerSave;
} IWPRIV_SET_PARAM;
Description
This is type IWPRIV_SET_PARAM.
IWPRIV_PARAM_CONFIG Structure
File
wdrv_mrf24wn_iwpriv.h
C
typedef struct {
void * config;
} IWPRIV_PARAM_CONFIG;
Description
This is type IWPRIV_PARAM_CONFIG.
IWPRIV_PARAM_CONNECT Structure
File
wdrv_mrf24wn_iwpriv.h
C
typedef struct {
bool initConnAllowed;
IWPRIV_CONN_STATUS status;
} IWPRIV_PARAM_CONNECT;
Description
This is type IWPRIV_PARAM_CONNECT.
IWPRIV_PARAM_DRIVERSTATUS Structure
File
wdrv_mrf24wn_iwpriv.h
C
typedef struct {
bool isOpen;
} IWPRIV_PARAM_DRIVERSTATUS;
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1380
Description
This is type IWPRIV_PARAM_DRIVERSTATUS.
IWPRIV_PARAM_FWUPGRADE Structure
File
wdrv_mrf24wn_iwpriv.h
C
typedef struct {
bool requested;
} IWPRIV_PARAM_FWUPGRADE;
Description
This is type IWPRIV_PARAM_FWUPGRADE.
IWPRIV_PARAM_MULTICASTFILTER Structure
File
wdrv_mrf24wn_iwpriv.h
C
typedef struct {
uint8_t * addr;
IWPRIV_STATUS status;
} IWPRIV_PARAM_MULTICASTFILTER;
Members
Members Description
uint8_t * addr; it usually points to a MAC address, which is an array of 6 uint8_t elements
Description
This is type IWPRIV_PARAM_MULTICASTFILTER.
IWPRIV_PARAM_NETWORKTYPE Structure
File
wdrv_mrf24wn_iwpriv.h
C
typedef struct {
uint8_t type;
} IWPRIV_PARAM_NETWORKTYPE;
Description
This is type IWPRIV_PARAM_NETWORKTYPE.
IWPRIV_PARAM_OPERATIONMODE Structure
File
wdrv_mrf24wn_iwpriv.h
C
typedef struct {
bool isServer;
} IWPRIV_PARAM_OPERATIONMODE;
Description
This is type IWPRIV_PARAM_OPERATIONMODE.
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1381
IWPRIV_PARAM_POWERSAVE Structure
File
wdrv_mrf24wn_iwpriv.h
C
typedef struct {
bool enabled;
} IWPRIV_PARAM_POWERSAVE;
Description
This is type IWPRIV_PARAM_POWERSAVE.
IWPRIV_PARAM_SCAN Structure
File
wdrv_mrf24wn_iwpriv.h
C
typedef struct {
bool prescanAllowed;
bool prescanFinished;
IWPRIV_SCAN_STATUS scanStatus;
uint16_t numberOfResults;
uint16_t index;
WDRV_SCAN_RESULT * result;
} IWPRIV_PARAM_SCAN;
Description
This is type IWPRIV_PARAM_SCAN.
IWPRIV_PARAM_SSID Structure
File
wdrv_mrf24wn_iwpriv.h
C
typedef struct {
uint8_t * ssid;
uint8_t ssidLen;
} IWPRIV_PARAM_SSID;
Description
This is type IWPRIV_PARAM_SSID.
Files
Files
Name Description
wdrv_mrf24wn_api.h MRF24WN Interface Functions
wdrv_mrf24wn_iwpriv.h Configure optional (private) parameters of MRF24WN driver.
Description
This section lists the source and header files used by the MRF24WN Wi-Fi Driver Library.
wdrv_mrf24wn_api.h
MRF24WN Interface Functions
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1382
Functions
Name Description
WDRV_EXT_CmdConnectContextChannelGet Gets the AP channel
Implementation: Dynamic
WDRV_EXT_CmdNetModeIBSSSet Sets the Wi-Fi network type to Adhoc.
Implementation: Dynamic
WDRV_EXT_CmdPowerSaveGet Retrieves current power save status.
Implementation: Dynamic
WDRV_EXT_CmdSecWPA2Set Sets Wi-Fi security to WPA2.
Implementation: Dynamic
WDRV_EXT_Initialize Initializes the MRF24WN Wi-Fi driver.
Implementation: Dynamic
WDRV_EXT_PrivConfig Configures g_wdrvext_priv parameter.
Implementation: Dynamic
WDRV_EXT_ScanResultGet Reads the selected scan results back from the MRF24WN module.
Implementation: Dynamic
WDRV_GPIO_DeInit Deinitializes the GPIO objects for the Wi-Fi driver.
Implementation: Dynamic
WDRV_GPIO_Init Initializes the GPIO objects for the Wi-Fi driver.
Implementation: Dynamic
WDRV_GPIO_PowerOff Powers off the MRF24WN module.
Implementation: Dynamic
WDRV_GPIO_PowerOn Powers on the MRF24WN module.
Implementation: Dynamic
WDRV_INTR_Deinit Deinitializes interrupts for Wi-Fi driver.
Implementation: Dynamic
WDRV_INTR_Init Initializes interrupts for the Wi-Fi driver.
Implementation: Dynamic
WDRV_INTR_SourceDisable Disables interrupts from the module.
Implementation: Dynamic
WDRV_INTR_SourceEnable Enables interrupts from the module.
Implementation: Dynamic
WDRV_IsPowerOff Checks if MRF24WN is turned off.
Implementation: Dynamic
WDRV_MRF24WN_ISR Wi-Fi driver (MRF24WN-specific) interrupt service routine.
Implementation: Dynamic
WDRV_SPI_Deinit Deinitializes the SPI object for the Wi-Fi driver.
Implementation: Dynamic
WDRV_SPI_In Receives data from the module through the SPI bus.
Implementation: Dynamic
WDRV_SPI_Init Initializes the SPI object for the Wi-Fi driver.
Implementation: Dynamic
WDRV_SPI_Out Sends data out to the module through the SPI bus.
Implementation: Dynamic
Description
MRF24WN Interface Functions
File Name
wdrv_mrf24wn_api.h
Company
Microchip Technology Inc.
wdrv_mrf24wn_iwpriv.h
Configure optional (private) parameters of MRF24WN driver.
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1383
Enumerations
Name Description
IWPRIV_CMD This is type IWPRIV_CMD.
IWPRIV_CONN_STATUS This is type IWPRIV_CONN_STATUS.
IWPRIV_SCAN_STATUS This is type IWPRIV_SCAN_STATUS.
IWPRIV_STATUS This is type IWPRIV_STATUS.
Functions
Name Description
iwpriv_adhocctx_set Sets the Ad hoc network context information.
Implementation: Dynamic
iwpriv_config_read Reads the Wi-Fi context configuration.
Implementation: Dynamic
iwpriv_config_write Writes to the Wi-Fi context configuration which is currently used by Wi-Fi driver.
Implementation: Dynamic
iwpriv_connstatus_get Gets the Wi-Fi connection status.
Implementation: Dynamic
iwpriv_devinfo_get Gets the device information.
Implementation: Dynamic
iwpriv_execute This is function iwpriv_execute.
iwpriv_get This is function iwpriv_get.
iwpriv_initialconn_set Sets the initial connection status of Wi-Fi driver.
Implementation: Dynamic
iwpriv_initstatus_get Gets the initialization status of Wi-Fi driver.
Implementation: Dynamic
iwpriv_is_servermode Checks if the passed Wi-Fi context configuration is operating in server mode.
Implementation: Dynamic
iwpriv_leftclient_get Gets the left client's information.
Implementation: Dynamic
iwpriv_mcastfilter_set Adds a MAC address to the multi-cast filter.
Implementation: Dynamic
iwpriv_nettype_get Gets the current network type.
Implementation: Dynamic
iwpriv_nettype_set Sets the current network type.
Implementation: Dynamic
iwpriv_numberofscanresults_get Gets the number of scan results.
Implementation: Dynamic
iwpriv_powersave_config Enables or disables Power Save mode in Wi-Fi driver.
Implementation: Dynamic
iwpriv_prescan_isfinished Checks if the prescan is complete.
Implementation: Dynamic
iwpriv_prescan_option_get To see if prescan will run before next connection.
Implementation: Dynamic
iwpriv_prescan_option_set To run prescan or not.
Implementation: Dynamic
iwpriv_prescan_start Starts prescan.
Implementation: Dynamic
iwpriv_scan_start Starts scan.
Implementation: Dynamic
iwpriv_scanstatus_get Gets the prescan status.
Implementation: Dynamic
iwpriv_set This is function iwpriv_set.
iwpriv_ssid_get Gets the current SSID.
Implementation: Dynamic
iwpriv_ssid_set Sets the current SSID.
Implementation: Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1384
Structures
Name Description
IWPRIV_PARAM_CLIENTINFO This is type IWPRIV_PARAM_CLIENTINFO.
IWPRIV_PARAM_CONFIG This is type IWPRIV_PARAM_CONFIG.
IWPRIV_PARAM_CONNECT This is type IWPRIV_PARAM_CONNECT.
IWPRIV_PARAM_CONTEXT This is type IWPRIV_PARAM_CONTEXT.
IWPRIV_PARAM_DEVICEINFO This is type IWPRIV_PARAM_DEVICEINFO.
IWPRIV_PARAM_DRIVERSTATUS This is type IWPRIV_PARAM_DRIVERSTATUS.
IWPRIV_PARAM_FWUPGRADE This is type IWPRIV_PARAM_FWUPGRADE.
IWPRIV_PARAM_MULTICASTFILTER This is type IWPRIV_PARAM_MULTICASTFILTER.
IWPRIV_PARAM_NETWORKTYPE This is type IWPRIV_PARAM_NETWORKTYPE.
IWPRIV_PARAM_OPERATIONMODE This is type IWPRIV_PARAM_OPERATIONMODE.
IWPRIV_PARAM_POWERSAVE This is type IWPRIV_PARAM_POWERSAVE.
IWPRIV_PARAM_SCAN This is type IWPRIV_PARAM_SCAN.
IWPRIV_PARAM_SSID This is type IWPRIV_PARAM_SSID.
Unions
Name Description
IWPRIV_EXECUTE_PARAM This is type IWPRIV_EXECUTE_PARAM.
IWPRIV_GET_PARAM This is type IWPRIV_GET_PARAM.
IWPRIV_SET_PARAM This is type IWPRIV_SET_PARAM.
Description
MRF24WN Private Configuration Support
Functions in this module support the connection process for the MRF24WN.
File Name
wdrv_mrf24wn_iwpriv.h
Company
Microchip Technology Inc.
WILC1000 Wi-Fi Driver Ethernet Mode Library
This topic describes the WILC1000 Wi-Fi Driver Library.
Introduction
This library provides a low-level abstraction of the WILC1000 Wi-Fi Driver Library that is available on the Microchip family of microcontrollers with a
convenient C language interface. It can be used to simplify low-level access to the module without the necessity of interacting directly with the
module's registers, there by hiding differences from one microcontroller variant to another.
Note:
The WILC1000 Wi-Fi Driver is compatible with the WILC1000 PICtail/PICtail Plus Daughter Board with WILC1000 firmware
version 4.2.3 and later in "Ethernet mode".
Description
The Wi-Fi software library, in conjunction with the WILC1000 module, allows an application to:
• Join an existing 802.11 Wi-Fi network
• Create a 802.11 Wi-Fi network
The following application services are provided by the Wi-Fi library:
• Configure a Wi-Fi connection (SSID, security mode, and so on)
• Join an existing network or create a "Soft-AP" Wi-Fi network
• Scan for other Wi-Fi devices in the area
• Receive Wi-Fi network status
• Wi-Fi power control
The MAC_layer services are not directly accessible to the application. This portion of the code resides under the TCP/IP Stack MAC module
software layers and is used by stack services to transmit and receive data over a Wi-Fi network. The following diagram shows the interaction of the
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1385
primary software blocks in a Wi-Fi application.
Wi-Fi Software Block Diagram
The following table provides information that includes network mode and security mode support by the WILC1000 Wi-Fi Driver.
Using the Library
This topic describes the basic architecture of the WILC1000 Wi-Fi Driver Library and provides information and examples on its use.
Description
Interface Header Files: wdrv_wilc1000_api.h and wdrv_wilc1000_stub.h
The interface to the WILC1000 Wi-Fi Driver Library is defined in the wdrv_wilc1000_api.h and wdrv_wilc1000_stub.h header files.
Please refer to the Understanding MPLAB Harmony section for how the driver interacts with the framework.
Abstraction Model
This library provides a low-level abstraction of the WILC1000 Wi-Fi module with a convenient C language interface. This topic describes how that
abstraction is modeled in software and introduces the library's interface.
Description
The WILC1000 Wi-Fi Library provides the following functionality:
• Wi-Fi library initialization
• Wi-Fi network configuration
• Wi-Fi network connection
• Scanning for existing Wi-Fi networks
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1386
• Wi-Fi event processing
• Wi-Fi status
• Wi-FI console commands
Library Overview
Refer to the Driver Library Overview section for information on how the driver operates in a system.
TheLibrary Interface functions are divided into various sub-sections, which address one of the blocks or the overall operation of the Wi-Fi module.
Library Interface Section Description
Wi-Fi Initialization
Functions
This section provides functions that initialize the Wi-Fi library and allow its API to be used.
Wi-Fi Status Functions This section provides functions that retrieve the Wi-Fi connection status.
Wi-Fi External Functions This section provides public functions accessible to TCP/IP applications.
Other Functions This section provides additional miscellaneous functions for configuring the Wi-Fi connection.
Data Types and Constants This section provides data types and macros.
How the Library Works
This section describes how the WILC1000 Wi-Fi Driver Library operates.
Description
Before the driver is ready for use, it should be configured (compile time configuration).
There are a few run-time configuration items that are done during initialization of the driver instance, and a few that are client-specific and are done
using dedicated functions.
To use the WILC1000 Wi-Fi Driver, initialization and client functions should be invoked in a specific sequence to ensure correct operation.
Configuring the Library
This section describes how to configure the WILC1000 Wi-Fi driver.
Description
The configuration of the WILC1000 Wi-Fi Driver is based on the file system_config.h.
This header file contains the configuration selection for the Wi-Fi Driver. Based on the selections made, the WILC1000 Wi-Fi Driver may support
the selected features. These configuration settings will apply to all instances of the WILC1000 Wi-Fi Driver.
This header can be placed anywhere; however, the path of this header needs to be present in the include search path for a successful build. Refer
to the Applications Help section for more details.
Sample Functionality
The following code provides an example of Wi-Fi Driver configuration. (refer to system.config.h)
/*** SPI Driver Configuration ***/
#define DRV_SPI_NUMBER_OF_MODULES 4
/*** Driver Compilation and static configuration options. ***/
/*** Select SPI compilation units.***/
#define DRV_SPI_POLLED 0
#define DRV_SPI_ISR 1
#define DRV_SPI_MASTER 1
#define DRV_SPI_SLAVE 0
#define DRV_SPI_RM 1
#define DRV_SPI_EBM 0
#define DRV_SPI_8BIT 1
#define DRV_SPI_16BIT 0
#define DRV_SPI_32BIT 0
#define DRV_SPI_DMA 1
/*** SPI Driver Static Allocation Options ***/
#define DRV_SPI_INSTANCES_NUMBER 1
#define DRV_SPI_CLIENTS_NUMBER 1
#define DRV_SPI_ELEMENTS_PER_QUEUE 10
/*** SPI Driver DMA Options ***/
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1387
#define DRV_SPI_DMA_TXFER_SIZE 512
#define DRV_SPI_DMA_DUMMY_BUFFER_SIZE 512
/* SPI Driver Instance 0 Configuration */
#define DRV_SPI_SPI_ID_IDX0 SPI_ID_1
#define DRV_SPI_TASK_MODE_IDX0 DRV_SPI_TASK_MODE_ISR
#define DRV_SPI_SPI_MODE_IDX0 DRV_SPI_MODE_MASTER
#define DRV_SPI_ALLOW_IDLE_RUN_IDX0 false
#define DRV_SPI_SPI_PROTOCOL_TYPE_IDX0 DRV_SPI_PROTOCOL_TYPE_STANDARD
#define DRV_SPI_COMM_WIDTH_IDX0 SPI_COMMUNICATION_WIDTH_8BITS
#define DRV_SPI_SPI_CLOCK_IDX0 CLK_BUS_PERIPHERAL_2
#define DRV_SPI_BAUD_RATE_IDX0 2000000
#define DRV_SPI_BUFFER_TYPE_IDX0 DRV_SPI_BUFFER_TYPE_STANDARD
#define DRV_SPI_CLOCK_MODE_IDX0 DRV_SPI_CLOCK_MODE_IDLE_LOW_EDGE_FALL
#define DRV_SPI_INPUT_PHASE_IDX0 SPI_INPUT_SAMPLING_PHASE_AT_END
#define DRV_SPI_TRANSMIT_DUMMY_BYTE_VALUE_IDX0 0x00
#define DRV_SPI_TX_INT_SOURCE_IDX0 INT_SOURCE_SPI_1_TRANSMIT
#define DRV_SPI_RX_INT_SOURCE_IDX0 INT_SOURCE_SPI_1_RECEIVE
#define DRV_SPI_ERROR_INT_SOURCE_IDX0 INT_SOURCE_SPI_1_ERROR
#define DRV_SPI_INT_VECTOR_IDX0 INT_VECTOR_SPI1
#define DRV_SPI_INT_PRIORITY_IDX0 INT_PRIORITY_LEVEL1
#define DRV_SPI_INT_SUB_PRIORITY_IDX0 INT_SUBPRIORITY_LEVEL0
#define DRV_SPI_QUEUE_SIZE_IDX0 10
#define DRV_SPI_RESERVED_JOB_IDX0 1
#define DRV_SPI_TX_DMA_CHANNEL_IDX0 DMA_CHANNEL_1
#define DRV_SPI_TX_DMA_THRESHOLD_IDX0 16
#define DRV_SPI_RX_DMA_CHANNEL_IDX0 DMA_CHANNEL_0
#define DRV_SPI_RX_DMA_THRESHOLD_IDX0 16
/*** Timer Driver Configuration ***/
#define DRV_TMR_INTERRUPT_MODE true
#define DRV_TMR_INSTANCES_NUMBER 1
#define DRV_TMR_CLIENTS_NUMBER 1
/*** Timer Driver 0 Configuration ***/
#define DRV_TMR_PERIPHERAL_ID_IDX0 TMR_ID_2
#define DRV_TMR_INTERRUPT_SOURCE_IDX0 INT_SOURCE_TIMER_2
#define DRV_TMR_INTERRUPT_VECTOR_IDX0 INT_VECTOR_T2
#define DRV_TMR_ISR_VECTOR_IDX0 _TIMER_2_VECTOR
#define DRV_TMR_INTERRUPT_PRIORITY_IDX0 INT_PRIORITY_LEVEL4
#define DRV_TMR_INTERRUPT_SUB_PRIORITY_IDX0 INT_SUBPRIORITY_LEVEL0
#define DRV_TMR_CLOCK_SOURCE_IDX0 DRV_TMR_CLKSOURCE_INTERNAL
#define DRV_TMR_PRESCALE_IDX0 TMR_PRESCALE_VALUE_256
#define DRV_TMR_OPERATION_MODE_IDX0 DRV_TMR_OPERATION_MODE_16_BIT
#define DRV_TMR_ASYNC_WRITE_ENABLE_IDX0 false
#define DRV_TMR_POWER_STATE_IDX0 SYS_MODULE_POWER_RUN_FULL
/*** Wi-Fi Driver Configuration ***/
#define WILC1000_INT_SOURCE INT_SOURCE_CHANGE_NOTICE
#define WILC1000_INT_VECTOR INT_VECTOR_CN
#define WDRV_SPI_INDEX 0
#define WDRV_SPI_INSTANCE sysObj.spiObjectIdx0
#define WDRV_USE_SPI_DMA
#define WDRV_NVM_SPACE_ENABLE
#define WDRV_NVM_SPACE_ADDR (48 * 1024)
#define WDRV_BOARD_TYPE WDRV_BD_TYPE_MX_ESK
#define WDRV_EXT_RTOS_TASK_SIZE 2048u
#define WDRV_EXT_RTOS_TASK_PRIORITY 2u
// I/O mappings for general control pins, including CHIP_EN, IRQN, RESET_N and SPI_SSN.
#define WDRV_CHIP_EN_PORT_CHANNEL PORT_CHANNEL_F
#define WDRV_CHIP_EN_BIT_POS 1
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1388
#define WDRV_IRQN_PORT_CHANNEL PORT_CHANNEL_G
#define WDRV_IRQN_BIT_POS 7
#define WDRV_RESET_N_PORT_CHANNEL PORT_CHANNEL_F
#define WDRV_RESET_N_BIT_POS 0
#define WDRV_SPI_SSN_PORT_CHANNEL PORT_CHANNEL_B
#define WDRV_SPI_SSN_BIT_POS 2
#define WILC1000_ON_PIC32MX_ESK
// On PIC32MX ESK, when CN9 (Pin G7) is used as external interrupt,
// it is sometimes better to use another GPIO (Pin E0) to read CN9's value.
// In this case, a jumper wire is needed to connect Pin E0 and Pin G7.
//#define WDRV_VERIFY_IRQN_BY_ANOTHER_GPIO
#if defined(WDRV_VERIFY_IRQN_BY_ANOTHER_GPIO)
// Use Pin E0. Please also make sure that Pin E0 and Pin G7 are connected (by a jumper wire).
#define WDRV_IRQN_PORT_CHANNEL_READ PORT_CHANNEL_E
#define WDRV_IRQN_BIT_POS_READ 0
#else
// Still directly read Pin G7's value.
#define WDRV_IRQN_PORT_CHANNEL_READ PORT_CHANNEL_G
#define WDRV_IRQN_BIT_POS_READ 7
#endif
#define WDRV_DEFAULT_NETWORK_TYPE WDRV_NETWORK_TYPE_INFRASTRUCTURE
#define WDRV_DEFAULT_CHANNEL 6
#define WDRV_DEFAULT_SSID "MicrochipDemoApp"
#define WDRV_DEFAULT_SECURITY_MODE WDRV_SECURITY_OPEN
#define WDRV_DEFAULT_WEP_KEYS_40 "5AFB6C8E77" // default WEP40 key
#define WDRV_DEFAULT_WEP_KEYS_104 "90E96780C739409DA50034FCAA" // default WEP104 key
#define WDRV_DEFAULT_PSK_PHRASE "Microchip 802.11 Secret PSK Password" // default WPA-PSK
Building the Library
This section lists the files that are available in the WILC1000 Wi-Fi Driver Library.
Description
The following three tables list and describe the header (.h) and source (.c) files that implement this library. The parent folder for these files is
/framework/driver/wifi/wilc1000.
Interface File(s)
This table lists and describes the header files that must be included (i.e., using #include) by any code that uses this library.
Source File Name Description
wdrv_wilc1000_stub.h Contains Stub function prototypes for interfacing to the WILC1000 Wi-Fi Driver.
wdrv_wilc1000_api.h Contains API function prototypes for interfacing to the WILC1000 Wi-Fi Driver.
Required File(s)
All of the required files listed in the following table are automatically added into the MPLAB X IDE project by the MHC
when the library is selected for use.
This table lists and describes the source and header files that must always be included in the MPLAB X IDE project to build this library.
Source File Name Description
wdrv_wilc1000_console.c Console module for the WILC1000 wireless driver.
wdrv_wilc1000_fw_update.c WILC1000 firmware update support.
wdrv_wilc1000_eint.c External interrupt handler for the WILC1000 wireless driver.
wdrv_wilc1000_timer.c Timer functions for the WILC1000 wireless driver.
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1389
wdrv_wilc1000_gpio.c WILC1000 GPIO support for SPI communication.
wdrv_wilc1000_spi.c WILC1000 support for SPI communication.
wdrv_wilc1000_cli.c WILC1000 driver CLI implementation.
wdrv_wilc1000_config_data.c Stores and retrieves Wi-Fi configuration to/from non-volatile memory (NVM).
wdrv_wilc1000_connmgr.c WILC1000 driver connection manager.
wdrv_wilc1000_events.c WILC1000 driver MAC events.
wdrv_wilc1000_iwpriv.c WILC1000 driver connection process functions.
wdrv_wilc1000_main.c WILC1000 driver Microchip TCP/IP Stack PIC32 MAC support.
wdrv_wilc1000_osal.c WILC1000 driver OS abstraction layer.
wdrv_wilc1000_scan_helper.c WILC1000 driver scan helper functions.
wdrext_wilc1000.c WILC1000 driver extended functions.
wilc1000_task.c WILC1000 driver task handler.
Optional File(s)
This table lists and describes the source and header files that may optionally be included if required for the desired implementation.
Source File Name Description
N/A The WILC1000 Wi-Fi Driver controller has no optional files.
Module Dependencies
The WILC1000 Wi-Fi Driver Library depends on the following modules:
• SPI Driver Library
• NVM Driver Library
• UART Driver Library
• USB Driver Library
• Operating System Abstraction Layer (OSAL) Library Help
• Clock System Service Library
• System Service Library Introduction
• Console System Service Library
• File System Service Library
• Interrupt System Service Library
• Timer System Service Library
• Debug System Service Library
• Ports System Service Library
• FreeRTOS Library Help
• Crypto Library
• Peripheral Libraries
• Networking Presentation Layer Help
• TCP/IP Stack Library Help
• Command Processor System Service Library
• DMA System Service Library
• Random Number Generator System Service Library
• Common System Service Library
• TCP/IP Ethernet MAC Driver Library
Console Commands
This section describes the console commands available for the WILC1000 Wi-Fi Driver.
Description
Both the Web Server and the EasyConfig demonstrations support the followings commands, which enable control over the Wi-Fi settings.
Command: deleteconf
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1390
Parameters Description
None. Wi-Fi console command to erase saved Wi-Fi configuration in memory.
Command: iwconfig
Parameters Description
[ ssid ] name: Specifies the name of the SSID (1-32 ASCII characters).
[ mode ]
idle: Disconnected from the current configuration.
managed: Connects in infrastructure mode to the currently set SSID.
[ power ]
enable: Enables all Power-Saving features (PS_POLL). Will wake up to check for all types of traffic (unicast, multicast, and
broadcast).
disable: Disables any Power-Saving features. Will always be in an active power state.
[ security ] mode: open/wep40/wep104/wpa/wpa2/pin/pbc. For example:
iwconfig security open
iwconfig security wep40
iwconfig security wep104
iwconfig security wpa
iwconfig security wpa2
iwconfig security pin
iwconfig security pbc
[ scan ] Starts a Wi-Fi scan.
[ scanget
]
scan_index: Retrieves the scan result after the scan completes (1 - n).
Command: mac
Parameters Description
None. Wi-Fi console command to retrieve the MAC address of the MRF24WN module.
Command: ota
Parameters Description
[ http://ip-address/ ]
[ filename.bin ]
Upgrade the WILC1000 firmware over-the-air. For example:
http://192.168.0.4/winc1500_ota.bin
Command: readconf
Parameters Description
None. Wi-Fi console command to read saved Wi-Fi configuration in memory.
Command: saveconf
Parameters Description
None. Wi-Fi console command to save Wi-Fi configuration to memory.
Library Interface
This section describes the Application Programming Interface (API) functions of the WILC1000 Wi-Fi Driver.
Refer to each section for a detailed description.
a) Wi-Fi Initialization Functions
b) Wi-Fi Status Functions
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1391
c) Wi-Fi External Functions
d) Other Functions
e) Data Types and Constants
Files
Files
Name Description
wdrv_wilc1000_api.h WILC1000 wireless driver APIs.
wdrv_wilc1000_stub.h WILC1000 wireless driver stub APIs.
Description
This section lists the source and header files used by the MRF24WN Wi-Fi Driver Library.
wdrv_wilc1000_api.h
WILC1000 wireless driver APIs.
Functions
Name Description
WDRV_EXT_CmdScanOptionSet Sets scan options.
Implementation: Dynamic
WDRV_EXT_CmdSSIDSet Sets the SSID.
Implementation: Dynamic
WDRV_EXT_Initialize Initializes the WILC1000 Wi-Fi driver.
Implementation: Dynamic
WDRV_EXT_ScanDoneSet Indicates when a scan has completed.
Implementation: Dynamic
WDRV_EXT_ScanIsInProgress Check whether host scan is now in progress or not.
Implementation: Dynamic
Description
WILC1000 wireless driver APIs.
File Name
wdrv_wilc1000_api.h
Company
Microchip Technology Inc.
wdrv_wilc1000_stub.h
WILC1000 wireless driver stub APIs.
Description
WILC1000 wireless driver stub APIs.
File Name
wdrv_wilc1000_stub.h
Company
Microchip Technology Inc.
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1392
WINC1500 Wi-Fi Driver Ethernet Mode Library
This topic describes the WINC1500 Wi-Fi Driver Library.
Introduction
This library provides a low-level abstraction of the WINC1500 Wi-Fi Driver Library that is available on the Microchip family of microcontrollers with
a convenient C language interface. It can be used to simplify low-level access to the module without the necessity of interacting directly with the
module's registers, there by hiding differences from one microcontroller variant to another.
Note:
The WINC1500 Wi-Fi Driver is compatible with the WINC1500 PICtail/PICtail Plus Daughter board with WINC1500 firmware
version 19.5.2 and later in "Ethernet mode". The driver will also work with WINC1500 firmware version 19.4.4 with limited
backward compatibility.
Description
The Wi-Fi software library, in conjunction with the WINC1500 module, allows an application to:
• Join an existing 802.11 Wi-Fi network
• Create a 802.11 Wi-Fi network
The following application services are provided by the Wi-Fi library:
• Configure a Wi-Fi connection (SSID, security mode, and so on)
• Join an existing network or create a "Soft-AP" Wi-Fi network
• Scan for other Wi-Fi devices in the area
• Receive Wi-Fi network status
• Wi-Fi power control
The MAC_layer services are not directly accessible to the application. This portion of the code resides under the TCP/IP Stack MAC module
software layers and is used by stack services to transmit and receive data over a Wi-Fi network. The following diagram shows the interaction of the
primary software blocks in a Wi-Fi application.
Wi-Fi Software Block Diagram
The following table provides information that includes network mode and security mode support by the WINC1500 Wi-Fi Driver.
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1393
Using the Library
This topic describes the basic architecture of the WINC1500 Wi-Fi Driver Library and provides information and examples on its use.
Description
Interface Header Files: wdrv_winc1500_api.h and wdrv_winc1500_stub.h
The interface to the WINC1500 Wi-Fi Driver Library is defined in the wdrv_winc1500_api.h and wdrv_winc1500_stub.h header files.
Please refer to the Understanding MPLAB Harmony section for how the driver interacts with the framework.
Abstraction Model
This library provides a low-level abstraction of the WINC1500 Wi-Fi module with a convenient C language interface. This topic describes how that
abstraction is modeled in software and introduces the library's interface.
Description
The WINC1500 Wi-Fi Library provides the following functionality:
• Wi-Fi library initialization
• Wi-Fi network configuration
• Wi-Fi network connection
• Scanning for existing Wi-Fi networks
• Wi-Fi event processing
• Wi-Fi status
• Wi-FI console commands
Library Overview
Refer to the Driver Library Overview section for information on how the driver operates in a system.
TheLibrary Interface functions are divided into various sub-sections, which address one of the blocks or the overall operation of the Wi-Fi module.
Library Interface Section Description
Wi-Fi Initialization
Functions
This section provides functions that initialize the Wi-Fi library and allow its API to be used.
Wi-Fi Status Functions This section provides functions that retrieve the Wi-Fi connection status.
Wi-Fi External Functions This section provides public functions accessible to TCP/IP applications.
Other Functions This section provides additional miscellaneous functions for configuring the Wi-Fi connection.
Data Types and Constants This section provides data types and macros.
How the Library Works
This section describes how the WINC1500 Wi-Fi Driver Library operates.
Description
Before the driver is ready for use, it should be configured (compile time configuration).
There are a few run-time configuration items that are done during initialization of the driver instance, and a few that are client-specific and are done
using dedicated functions.
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1394
To use the WINC1500 Wi-Fi Driver, initialization and client functions should be invoked in a specific sequence to ensure correct operation.
Configuring the Library
This section describes how to configure the WINC1500 Wi-Fi driver.
Description
The configuration of the WINC1500 Wi-Fi Driver is based on the file system_config.h.
This header file contains the configuration selection for the Wi-Fi Driver. Based on the selections made, the WINC1500 Wi-Fi Driver may support
the selected features. These configuration settings will apply to all instances of the WINC1500 Wi-Fi Driver.
This header can be placed anywhere; however, the path of this header needs to be present in the include search path for a successful build. Refer
to the Applications Help section for more details.
Sample Functionality
The following code provides an example of Wi-Fi Driver configuration. (refer to system.config.h)
/*** SPI Driver Configuration ***/
#define DRV_SPI_NUMBER_OF_MODULES 4
/*** Driver Compilation and static configuration options. ***/
/*** Select SPI compilation units.***/
#define DRV_SPI_POLLED 0
#define DRV_SPI_ISR 1
#define DRV_SPI_MASTER 1
#define DRV_SPI_SLAVE 0
#define DRV_SPI_RM 1
#define DRV_SPI_EBM 0
#define DRV_SPI_8BIT 1
#define DRV_SPI_16BIT 0
#define DRV_SPI_32BIT 0
#define DRV_SPI_DMA 1
/*** SPI Driver Static Allocation Options ***/
#define DRV_SPI_INSTANCES_NUMBER 1
#define DRV_SPI_CLIENTS_NUMBER 1
#define DRV_SPI_ELEMENTS_PER_QUEUE 10
/*** SPI Driver DMA Options ***/
#define DRV_SPI_DMA_TXFER_SIZE 512
#define DRV_SPI_DMA_DUMMY_BUFFER_SIZE 512
/* SPI Driver Instance 0 Configuration */
#define DRV_SPI_SPI_ID_IDX0 SPI_ID_1
#define DRV_SPI_TASK_MODE_IDX0 DRV_SPI_TASK_MODE_ISR
#define DRV_SPI_SPI_MODE_IDX0 DRV_SPI_MODE_MASTER
#define DRV_SPI_ALLOW_IDLE_RUN_IDX0 false
#define DRV_SPI_SPI_PROTOCOL_TYPE_IDX0 DRV_SPI_PROTOCOL_TYPE_STANDARD
#define DRV_SPI_COMM_WIDTH_IDX0 SPI_COMMUNICATION_WIDTH_8BITS
#define DRV_SPI_SPI_CLOCK_IDX0 CLK_BUS_PERIPHERAL_2
#define DRV_SPI_BAUD_RATE_IDX0 2000000
#define DRV_SPI_BUFFER_TYPE_IDX0 DRV_SPI_BUFFER_TYPE_STANDARD
#define DRV_SPI_CLOCK_MODE_IDX0 DRV_SPI_CLOCK_MODE_IDLE_LOW_EDGE_FALL
#define DRV_SPI_INPUT_PHASE_IDX0 SPI_INPUT_SAMPLING_PHASE_AT_END
#define DRV_SPI_TRANSMIT_DUMMY_BYTE_VALUE_IDX0 0x00
#define DRV_SPI_TX_INT_SOURCE_IDX0 INT_SOURCE_SPI_1_TRANSMIT
#define DRV_SPI_RX_INT_SOURCE_IDX0 INT_SOURCE_SPI_1_RECEIVE
#define DRV_SPI_ERROR_INT_SOURCE_IDX0 INT_SOURCE_SPI_1_ERROR
#define DRV_SPI_INT_VECTOR_IDX0 INT_VECTOR_SPI1
#define DRV_SPI_INT_PRIORITY_IDX0 INT_PRIORITY_LEVEL1
#define DRV_SPI_INT_SUB_PRIORITY_IDX0 INT_SUBPRIORITY_LEVEL0
#define DRV_SPI_QUEUE_SIZE_IDX0 10
#define DRV_SPI_RESERVED_JOB_IDX0 1
#define DRV_SPI_TX_DMA_CHANNEL_IDX0 DMA_CHANNEL_1
#define DRV_SPI_TX_DMA_THRESHOLD_IDX0 16
#define DRV_SPI_RX_DMA_CHANNEL_IDX0 DMA_CHANNEL_0
#define DRV_SPI_RX_DMA_THRESHOLD_IDX0 16
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1395
/*** Timer Driver Configuration ***/
#define DRV_TMR_INTERRUPT_MODE true
#define DRV_TMR_INSTANCES_NUMBER 1
#define DRV_TMR_CLIENTS_NUMBER 1
/*** Timer Driver 0 Configuration ***/
#define DRV_TMR_PERIPHERAL_ID_IDX0 TMR_ID_2
#define DRV_TMR_INTERRUPT_SOURCE_IDX0 INT_SOURCE_TIMER_2
#define DRV_TMR_INTERRUPT_VECTOR_IDX0 INT_VECTOR_T2
#define DRV_TMR_ISR_VECTOR_IDX0 _TIMER_2_VECTOR
#define DRV_TMR_INTERRUPT_PRIORITY_IDX0 INT_PRIORITY_LEVEL4
#define DRV_TMR_INTERRUPT_SUB_PRIORITY_IDX0 INT_SUBPRIORITY_LEVEL0
#define DRV_TMR_CLOCK_SOURCE_IDX0 DRV_TMR_CLKSOURCE_INTERNAL
#define DRV_TMR_PRESCALE_IDX0 TMR_PRESCALE_VALUE_256
#define DRV_TMR_OPERATION_MODE_IDX0 DRV_TMR_OPERATION_MODE_16_BIT
#define DRV_TMR_ASYNC_WRITE_ENABLE_IDX0 false
#define DRV_TMR_POWER_STATE_IDX0 SYS_MODULE_POWER_RUN_FULL
/*** Wi-Fi Driver Configuration ***/
#define WINC1500_INT_SOURCE INT_SOURCE_CHANGE_NOTICE
#define WINC1500_INT_VECTOR INT_VECTOR_CN
#define WDRV_SPI_INDEX 0
#define WDRV_SPI_INSTANCE sysObj.spiObjectIdx0
#define WDRV_USE_SPI_DMA
#define WDRV_NVM_SPACE_ENABLE
#define WDRV_NVM_SPACE_ADDR (48 * 1024)
#define WDRV_BOARD_TYPE WDRV_BD_TYPE_MX_ESK
#define WDRV_EXT_RTOS_TASK_SIZE 2048u
#define WDRV_EXT_RTOS_TASK_PRIORITY 2u
// I/O mappings for general control pins, including CHIP_EN, IRQN, RESET_N and SPI_SSN.
#define WDRV_CHIP_EN_PORT_CHANNEL PORT_CHANNEL_F
#define WDRV_CHIP_EN_BIT_POS 1
#define WDRV_IRQN_PORT_CHANNEL PORT_CHANNEL_G
#define WDRV_IRQN_BIT_POS 7
#define WDRV_RESET_N_PORT_CHANNEL PORT_CHANNEL_F
#define WDRV_RESET_N_BIT_POS 0
#define WDRV_SPI_SSN_PORT_CHANNEL PORT_CHANNEL_B
#define WDRV_SPI_SSN_BIT_POS 2
#define WINC1500_ON_PIC32MX_ESK
// On PIC32MX ESK, when CN9 (Pin G7) is used as external interrupt,
// it is sometimes better to use another GPIO (Pin E0) to read CN9's value.
// In this case, a jumper wire is needed to connect Pin E0 and Pin G7.
//#define WDRV_VERIFY_IRQN_BY_ANOTHER_GPIO
#if defined(WDRV_VERIFY_IRQN_BY_ANOTHER_GPIO)
// Use Pin E0. Please also make sure that Pin E0 and Pin G7 are connected (by a jumper wire).
#define WDRV_IRQN_PORT_CHANNEL_READ PORT_CHANNEL_E
#define WDRV_IRQN_BIT_POS_READ 0
#else
// Still directly read Pin G7's value.
#define WDRV_IRQN_PORT_CHANNEL_READ PORT_CHANNEL_G
#define WDRV_IRQN_BIT_POS_READ 7
#endif
#define WDRV_DEFAULT_NETWORK_TYPE WDRV_NETWORK_TYPE_INFRASTRUCTURE
#define WDRV_DEFAULT_CHANNEL 6
#define WDRV_DEFAULT_SSID "MicrochipDemoApp"
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1396
#define WDRV_DEFAULT_SECURITY_MODE WDRV_SECURITY_OPEN
#define WDRV_DEFAULT_WEP_KEYS_40 "5AFB6C8E77" // default WEP40 key
#define WDRV_DEFAULT_WEP_KEYS_104 "90E96780C739409DA50034FCAA" // default WEP104 key
#define WDRV_DEFAULT_PSK_PHRASE "Microchip 802.11 Secret PSK Password" // default WPA-PSK
Building the Library
This section lists the files that are available in the WINC1500 Wi-Fi Driver Library.
Description
The following three tables list and describe the header (.h) and source (.c) files that implement this library. The parent folder for these files is
/framework/driver/wifi/winc1500.
Interface File(s)
This table lists and describes the header files that must be included (i.e., using #include) by any code that uses this library.
Source File Name Description
wdrv_winc1500_stub.h Contains Stub function prototypes for interfacing to the WINC1500 Wi-Fi Driver.
wdrv_winc1500_api.h Contains API function prototypes for interfacing to the WINC1500 Wi-Fi Driver.
Required File(s)
All of the required files listed in the following table are automatically added into the MPLAB X IDE project by the MHC
when the library is selected for use.
This table lists and describes the source and header files that must always be included in the MPLAB X IDE project to build this library.
Source File Name Description
wdrv_winc1500_console.c Console module for the WINC1500 wireless driver.
wdrv_winc1500_fw_update.c WINC1500 firmware update support.
wdrv_winc1500_eint.c External interrupt handler for the WINC1500 wireless driver.
wdrv_winc1500_timer.c Timer functions for the WINC1500 wireless driver.
wdrv_winc1500_gpio.c WINC1500 GPIO support for SPI communication.
wdrv_winc1500_spi.c WINC1500 support for SPI communication.
wdrv_winc1500_cli.c WINC1500 driver CLI implementation.
wdrv_winc1500_config_data.c Stores and retrieves Wi-Fi configuration to/from non-volatile memory (NVM).
wdrv_winc1500_connmgr.c WINC1500 driver connection manager.
wdrv_winc1500_events.c WINC1500 driver MAC events.
wdrv_winc1500_iwpriv.c WINC1500 driver connection process functions.
wdrv_winc1500_main.c WINC1500 driver Microchip TCP/IP Stack PIC32 MAC support.
wdrv_winc1500_osal.c WINC1500 driver OS abstraction layer.
wdrv_winc1500_scan_helper.c WINC1500 driver scan helper functions.
wdrext_winc1500.c WINC1500 driver extended functions.
winc1500_task.c WINC1500 driver task handler.
Optional File(s)
This table lists and describes the source and header files that may optionally be included if required for the desired implementation.
Source File Name Description
N/A The WINC1500 Wi-Fi Driver controller has no optional files.
Module Dependencies
The WINC1500 Wi-Fi Driver Library depends on the following modules:
• SPI Driver Library
• NVM Driver Library
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1397
• UART Driver Library
• USB Driver Library
• Operating System Abstraction Layer (OSAL) Library Help
• Clock System Service Library
• System Service Library Introduction
• Console System Service Library
• File System Service Library
• Interrupt System Service Library
• Timer System Service Library
• Debug System Service Library
• Ports System Service Library
• FreeRTOS Library Help
• Crypto Library
• Peripheral Libraries
• Networking Presentation Layer Help
• TCP/IP Stack Library Help
• Command Processor System Service Library
• DMA System Service Library
• Random Number Generator System Service Library
• Common System Service Library
• TCP/IP Ethernet MAC Driver Library
Console Commands
This section describes the console commands available for the WINC1500 Wi-Fi Driver.
Description
Both the Web Server and the EasyConfig demonstrations support the followings commands, which enable control over the Wi-Fi settings.
Command: deleteconf
Parameters Description
None. Wi-Fi console command to erase saved Wi-Fi configuration in memory.
Command: iwconfig
Parameters Description
[ ssid ] name: Specifies the name of the SSID (1-32 ASCII characters).
[ mode ]
idle: Disconnected from the current configuration.
managed: Connects in infrastructure mode to the currently set SSID.
[ power ]
enable: Enables all Power-Saving features (PS_POLL). Will wake up to check for all types of traffic (unicast, multicast, and
broadcast).
disable: Disables any Power-Saving features. Will always be in an active power state.
[ security ] mode: open/wep40/wep104/wpa/wpa2/pin/pbc. For example:
iwconfig security open
iwconfig security wep40
iwconfig security wep104
iwconfig security wpa
iwconfig security wpa2
iwconfig security pin
iwconfig security pbc
[ scan ] Starts a Wi-Fi scan.
[ scanget
]
scan_index: Retrieves the scan result after the scan completes (1 - n).
Command: mac
Parameters Description
None. Wi-Fi console command to retrieve the MAC address of the MRF24WN module.
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1398
Command: ota
Parameters Description
[ http://ip-address/ ]
[ filename.bin ]
Upgrade the WINC1500 firmware over-the-air. For example:
http://192.168.0.4/winc1500_ota.bin
Command: readconf
Parameters Description
None. Wi-Fi console command to read saved Wi-Fi configuration in memory.
Command: saveconf
Parameters Description
None. Wi-Fi console command to save Wi-Fi configuration to memory.
Library Interface
a) Wi-Fi Initialization Functions
Name Description
WDRV_CLI_Init Initializes the console CLI interface.
Implementation: Dynamic
WDRV_INTR_Deinit Deinitializes interrupts for Wi-Fi driver.
Implementation: Dynamic
WDRV_INTR_Init Initializes interrupts for the Wi-Fi driver.
Implementation: Dynamic
WDRV_SPI_Deinit Deinitializes the SPI object for the Wi-Fi driver.
Implementation: Dynamic
WDRV_SPI_Init Initializes the SPI object for the Wi-Fi driver.
Implementation: Dynamic
WDRV_GPIO_DeInit Deinitializes the GPIO objects for the Wi-Fi driver.
Implementation: Dynamic
WDRV_EXT_Deinitialize Deinitializes the WINC1500 Wi-Fi driver.
Implementation: Dynamic
WDRV_WINC1500_ISR Wi-Fi driver (WINC1500-specific) interrupt service routine.
Implementation: Dynamic
b) Wi-Fi Status Functions
Name Description
WDRV_EXT_CmdFWVersionGet Retrieves FW version information.
Implementation: Dynamic
WDRV_EXT_ScanResultGet Reads the selected scan results back from the WINC1500 module.
Implementation: Dynamic
WDRV_EXT_CmdMacAddressGet Retrieves the WINC1500 MAC address.
Implementation: Dynamic
WDRV_EXT_CmdScanGet Reads the number of scan results from the WINC1500 module.
Implementation: Dynamic
WDRV_EXT_CmdSSIDGet Gets the SSID.
Implementation: Dynamic
c) Wi-Fi External Functions
Name Description
WDRV_EXT_CmdPowerSavePut Puts the module in power save mode.
Implementation: Dynamic
WDRV_EXT_HWInterruptHandler Wi-Fi driver (WINC1500-specific) interrupt service routine.
Implementation: Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1399
WDRV_EXT_CmdScanOptionSet Sets scan options.
Implementation: Dynamic
WDRV_EXT_ModuleUpDown Enables or disables WINC1500 module.
Implementation: Dynamic
WDRV_EXT_MulticastFilterSet Sets a multicast address filter.
Implementation: Dynamic
WDRV_EXT_CmdConnect Directs the WINC1500 to connect to a Wi-Fi network.
Implementation: Dynamic
WDRV_EXT_CmdDisconnect Directs the WINC1500 to disconnect from a Wi-Fi network.
Implementation: Dynamic
WDRV_EXT_CmdNetModeAPSet Sets the Wi-Fi network type to SoftAP.
Implementation: Dynamic
WDRV_EXT_CmdNetModeBSSSet Sets the Wi-Fi network type to Infrastructure.
Implementation: Dynamic
WDRV_EXT_CmdScanStart Directs the WINC1500 module to start a scan.
Implementation: Dynamic
WDRV_EXT_CmdSecNoneSet Sets Wi-Fi security to open (no security).
Implementation: Dynamic
WDRV_EXT_CmdSecWEPSet Sets Wi-Fi security to use WEP.
Implementation: Dynamic
WDRV_EXT_CmdSecWPASet Sets Wi-Fi security to use WPA/WPA2.
Implementation: Dynamic
WDRV_EXT_DataSend Sends data packets to WINC1500 module.
Implementation: Dynamic
WDRV_EXT_ScanDoneSet Indicates when a scan has completed.
Implementation: Dynamic
WDRV_EXT_CmdChannelSet Sets the channel on which to operate.
Implementation: Dynamic
WDRV_EXT_CmdSSIDSet Sets the SSID.
Implementation: Dynamic
WDRV_EXT_CmdFWUpdate Directs the module to start firmware download and upgrade.
Implementation: Dynamic
WDRV_EXT_CmdSecWpsSet Sets Wi-Fi security to use WPS.
Implementation: Dynamic
WDRV_EXT_CmdTxPowerSet Sets the Tx Power at 3 levels, high, medium and low.
Implementation: Dynamic
WDRV_EXT_CmdConnectContextBssidGet Gets the BSSID
Implementation: Dynamic
WDRV_EXT_CmdScanOptionsSet Sets scan options.
Implementation: Dynamic
WDRV_EXT_CmdSSIDSet Sets the SSID.
Implementation: Dynamic
WDRV_EXT_ScanIsInProgress Check whether host scan is now in progress or not.
Implementation: Dynamic
d) Other Functions
Name Description
WDRV_INTR_SourceDisable Disables interrupts from the module.
Implementation: Dynamic
WDRV_INTR_SourceEnable Enables interrupts from the module.
Implementation: Dynamic
WDRV_EXT_Initialize Initializes the WILC1000 Wi-Fi driver.
Implementation: Dynamic
WDRV_EXT_RssiRead Requests RSSI for the connected AP.
Implementation: Dynamic
WDRV_EXT_WPSResultsRead Reads the WPS process results back from the WINC1500 module and updates the
configuration data.
Implementation: Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1400
WDRV_STUB_Assert Dumps out an error message on serial console and resets itself when the driver asserts.
Implementation: Dynamic
WDRV_STUB_GPIO_ChipDisable Disables the WINC1500 chip.
Implementation: Dynamic
WDRV_STUB_GPIO_ChipEnable Enables the WINC1500 chip.
Implementation: Dynamic
WDRV_STUB_GPIO_DeInitialize Deinitializes the GPIO object for the Wi-Fi driver.
Implementation: Dynamic
WDRV_STUB_GPIO_Initialize Initializes the GPIO object for the Wi-Fi driver.
Implementation: Dynamic
WDRV_STUB_GPIO_ModuleReset Resets the WINC1500 module.
Implementation: Dynamic
WDRV_STUB_GPIO_ModuleUnreset Unresets the WINC1500 module.
Implementation: Dynamic
WDRV_STUB_HardDelay Waits spinning for the delay milliseconds.
Implementation: Dynamic
WDRV_STUB_INTR_Deinit Deinitializes interrupts for Wi-Fi driver.
Implementation: Dynamic
WDRV_STUB_INTR_Init Initializes interrupts for the Wi-Fi driver.
Implementation: Dynamic
WDRV_STUB_INTR_SourceDisable Disables interrupts from the module.
Implementation: Dynamic
WDRV_STUB_INTR_SourceEnable Enables interrupts from the module.
Implementation: Dynamic
WDRV_STUB_SPI_Deinitialize Deinitializes the SPI object for the Wi-Fi driver.
Implementation: Dynamic
WDRV_STUB_SPI_In Receives data from the module through the SPI bus.
Implementation: Dynamic
WDRV_STUB_SPI_Initialize Initializes the SPI object for the Wi-Fi driver.
Implementation: Dynamic
WDRV_STUB_SPI_Out Sends data out to the module through the SPI bus.
Implementation: Dynamic
e) Data Types and Constants
Name Description
_WDRV_WINC1500_API_H This is macro _WDRV_WINC1500_API_H.
WDRV_STUB_Print This is macro WDRV_STUB_Print.
Description
This section describes the Application Programming Interface (API) functions of the WINC1500 Wi-Fi Driver.
Refer to each section for a detailed description.
a) Wi-Fi Initialization Functions
WDRV_CLI_Init Function
Initializes the console CLI interface.
Implementation: Dynamic
File
wdrv_winc1500_api.h
C
bool WDRV_CLI_Init();
Returns
• 0 - Indicates success
• Non-zero value - Indicates failure
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1401
Description
This function initializes the console CLI interface.
Remarks
None.
Preconditions
The TCP/IP stack should be initialized.
Function
bool WDRV_CLI_Init(void)
WDRV_INTR_Deinit Function
Deinitializes interrupts for Wi-Fi driver.
Implementation: Dynamic
File
wdrv_mrf24wn_api.h
C
void WDRV_INTR_Deinit();
Returns
None.
Description
This function deinitializes interrupts for the Wi-Fi driver.
Remarks
None.
Preconditions
The TCP/IP stack should be initialized.
Function
void WDRV_INTR_Deinit(void)
WDRV_INTR_Init Function
Initializes interrupts for the Wi-Fi driver.
Implementation: Dynamic
File
wdrv_mrf24wn_api.h
C
void WDRV_INTR_Init();
Returns
None.
Description
This function initializes interrupts for the Wi-Fi driver.
Remarks
None.
Preconditions
The TCP/IP stack should be initialized.
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1402
Function
void WDRV_INTR_Init(void)
WDRV_SPI_Deinit Function
Deinitializes the SPI object for the Wi-Fi driver.
Implementation: Dynamic
File
wdrv_mrf24wn_api.h
C
void WDRV_SPI_Deinit();
Returns
None.
Description
This function deinitializes the SPI object for the Wi-Fi driver.
Remarks
None.
Preconditions
The TCP/IP stack should be initialized.
Function
void WDRV_SPI_Deinit(void)
WDRV_SPI_Init Function
Initializes the SPI object for the Wi-Fi driver.
Implementation: Dynamic
File
wdrv_mrf24wn_api.h
C
void WDRV_SPI_Init();
Returns
None.
Description
This function initializes the SPI object for the Wi-Fi driver.
Remarks
None.
Preconditions
The TCP/IP stack should be initialized.
Function
void WDRV_SPI_Init(void)
WDRV_GPIO_DeInit Function
Deinitializes the GPIO objects for the Wi-Fi driver.
Implementation: Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1403
File
wdrv_mrf24wn_api.h
C
void WDRV_GPIO_DeInit();
Returns
None.
Description
This function deinitializes the GPIO objects for the Wi-Fi driver.
Remarks
None.
Preconditions
The TCP/IP stack should be initialized.
Function
void WDRV_GPIO_DeInit(void)
WDRV_EXT_Deinitialize Function
Deinitializes the WINC1500 Wi-Fi driver.
Implementation: Dynamic
File
wdrv_winc1500_api.h
C
void WDRV_EXT_Deinitialize();
Returns
None.
Description
This function deinitializes the WINC1500 driver.
Remarks
None
Preconditions
None.
Function
void WDRV_EXT_Deinitialize(void)
WDRV_WINC1500_ISR Function
Wi-Fi driver (WINC1500-specific) interrupt service routine.
Implementation: Dynamic
File
wdrv_winc1500_api.h
C
void WDRV_WINC1500_ISR();
Returns
None.
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1404
Description
This function is the Wi-Fi driver (WINC1500-specific) interrupt service routine.
Remarks
None.
Preconditions
Wi-Fi initialization must be complete.
Function
void WDRV_WINC1500_ISR(void)
b) Wi-Fi Status Functions
WDRV_EXT_CmdFWVersionGet Function
Retrieves FW version information.
Implementation: Dynamic
File
wdrv_winc1500_api.h
C
uint32_t WDRV_EXT_CmdFWVersionGet(uint32_t * major, uint32_t * minor, uint32_t * patch);
Returns
• 0 - Indicates success
• Non-zero value - Indicates failure
Description
This function retrieves the module FW version information.
Remarks
None.
Preconditions
Wi-Fi initialization must be complete.
Parameters
Parameters Description
major pointer where the major number will be written
minor pointer where the minor number will be written
patch pointer where the patch number will be written
Function
uint32_t WDRV_EXT_CmdFWVersionGet(uint32_t *major, uint32_t *minor, uint32_t *patch);
WDRV_EXT_ScanResultGet Function
Reads the selected scan results back from the WINC1500 module.
Implementation: Dynamic
File
wdrv_winc1500_api.h
C
void WDRV_EXT_ScanResultGet(uint8_t listIndex, WDRV_SCAN_RESULT * p_scanResult);
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1405
Returns
• 0 - Indicates success
• Non-zero value - Indicates failure
Description
After a scan has completed this function is used to read one scan result at a time from the WINC1500 module.
Remarks
None.
Preconditions
Wi-Fi initialization must be complete.
Parameters
Parameters Description
listIndex index (0 based list) of the scan entry to retrieve
p_scanResult pointer to where scan result is written
Function
void WDRV_EXT_ScanResultGet(uint8_t listIndex, WDRV_SCAN_RESULT *p_scanResult)
WDRV_EXT_CmdMacAddressGet Function
Retrieves the WINC1500 MAC address.
Implementation: Dynamic
File
wdrv_winc1500_api.h
C
uint32_t WDRV_EXT_CmdMacAddressGet(uint8_t * MacAddr);
Returns
• 0 - Indicates success
• Non-zero value - Indicates failure
Description
This function retrieves the WINC1500 MAC address.
Remarks
None.
Preconditions
Wi-Fi initialization must be complete.
Parameters
Parameters Description
MacAddr Pointer where MAC address will be written (must point to a 6 bytes buffer)
Function
uint32_t WDRV_EXT_CmdMacAddressGet(uint8_t *MacAddr)
WDRV_EXT_CmdScanGet Function
Reads the number of scan results from the WINC1500 module.
Implementation: Dynamic
File
wdrv_winc1500_api.h
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1406
C
void WDRV_EXT_CmdScanGet(uint16_t * numOfResults);
Returns
None.
Description
This function reads the number of scan results from the WINC1500 module.
Remarks
None.
Preconditions
Wi-Fi initialization must be complete.
Parameters
Parameters Description
numOfResults pointer where the number of scan results will be written
Function
void WDRV_EXT_CmdScanGet(uint16_t *numOfResults)
WDRV_EXT_CmdSSIDGet Function
Gets the SSID.
Implementation: Dynamic
File
wdrv_winc1500_api.h
C
void WDRV_EXT_CmdSSIDGet(uint8_t * ssid, uint8_t * length);
Returns
None.
Description
This function returns the SSID and SSID Length.
Remarks
None.
Preconditions
Wi-Fi initialization must be complete.
Parameters
Parameters Description
ssid pointer to buffer where SSID will be written
length number of bytes in SSID
Function
void WDRV_EXT_CmdSSIDGet(uint8_t *ssid, uint8_t *length)
c) Wi-Fi External Functions
WDRV_EXT_CmdPowerSavePut Function
Puts the module in power save mode.
Implementation: Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1407
File
wdrv_winc1500_api.h
C
uint32_t WDRV_EXT_CmdPowerSavePut(bool enable, uint8_t mode, uint16_t listenInterval);
Returns
• 0 - Indicates success
• Non-zero value - Indicates failure
Description
The function places the module in power save mode.
Remarks
This works only with Infrastructure mode. Do not call this in other modes.
Preconditions
Wi-Fi initialization must be complete.
Parameters
Parameters Description
enable true will put the module in power save mode.
mode 0 : manual mode - not synchronized to AP beacon ; 1. deep automatic mode - ieee802.11
power save mode.
listenInterval STA wakes up per this beacon interval.
Function
uint32_t WDRV_EXT_CmdPowerSavePut(bool enable, uint8_t mode, uint16_t listenInterval)
WDRV_EXT_HWInterruptHandler Function
Wi-Fi driver (WINC1500-specific) interrupt service routine.
Implementation: Dynamic
File
wdrv_winc1500_api.h
C
void WDRV_EXT_HWInterruptHandler();
Returns
None.
Description
This function is the Wi-Fi driver (WINC1500-specific) interrupt service routine.
Remarks
None.
Preconditions
Wi-Fi initialization must be complete.
Function
void WDRV_EXT_HWInterruptHandler(void)
WDRV_EXT_CmdScanOptionSet Function
Sets scan options.
Implementation: Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1408
File
wdrv_wilc1000_api.h
C
uint32_t WDRV_EXT_CmdScanOptionSet(uint8_t numOfSlots, uint8_t slotTime, uint8_t probesPerSlot, uint8_t
rssiThreshold);
Returns
• 0 - Indicates success
• Non-zero value - Indicates failure
Description
The function sets scan options.
Remarks
None.
Preconditions
Wi-Fi initialization must be complete.
Parameters
Parameters Description
numOfSlots The min number of slots is 2 for every channel, every slot the module will send Probe
Request on air, and wait/listen for PROBE RESP/BEACONS for the slotTime.
slotTime The time that the module will wait on every channel listening to the frames on air.
probesPerSlot Number of probe requests to be sent per channel scan slot.
rssiThreshold The RSSI threshold of the AP which will be connected to directly.
Function
uint32_t WDRV_EXT_CmdScanOptionSet(uint8_t numOfSlots, uint8_t slotTime, uint8_t probesPerSlot, uint8_t rssiThreshold);
WDRV_EXT_ModuleUpDown Function
Enables or disables WINC1500 module.
Implementation: Dynamic
File
wdrv_winc1500_api.h
C
void WDRV_EXT_ModuleUpDown(uint32_t up);
Returns
None.
Description
This function enables or disables WINC1500 module.
Remarks
None.
Preconditions
Wi-Fi initialization must be complete.
Parameters
Parameters Description
up 1: enable; 0: disable.
Function
void WDRV_EXT_ModuleUpDown(uint32_t up)
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1409
WDRV_EXT_MulticastFilterSet Function
Sets a multicast address filter.
Implementation: Dynamic
File
wdrv_winc1500_api.h
C
uint32_t WDRV_EXT_MulticastFilterSet(uint8_t * addr);
Returns
• 0 - Indicates success
• Non-zero value - Indicates failure
Description
This function allows the application to configure up to 8 Multicast address filters on the WINC1500 module.
Remarks
None.
Preconditions
Wi-Fi initialization must be complete.
Parameters
Parameters Description
addr the pointer of the multicast mac address.
Function
uint32_t WDRV_EXT_MulticastFilterSet(uint8_t *addr)
WDRV_EXT_CmdConnect Function
Directs the WINC1500 to connect to a Wi-Fi network.
Implementation: Dynamic
File
wdrv_winc1500_api.h
C
uint32_t WDRV_EXT_CmdConnect();
Returns
• 0 - Indicates success
• Non-zero value - Indicates failure
Description
This function causes the WINC1500 to connect to a Wi-Fi network. Upon connection, or a failure to connect, an event will be generated.
Remarks
None.
Preconditions
Wi-Fi initialization must be complete and relevant connection parameters must have been set.
Function
uint32_t WDRV_EXT_CmdConnect(void)
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1410
WDRV_EXT_CmdDisconnect Function
Directs the WINC1500 to disconnect from a Wi-Fi network.
Implementation: Dynamic
File
wdrv_winc1500_api.h
C
uint32_t WDRV_EXT_CmdDisconnect();
Returns
• 0 - Indicates success
• Non-zero value - Indicates failure
Description
This function causes the WINC1500 to disconnect from a Wi-Fi network.
Remarks
None.
Preconditions
Wi-Fi initialization must be complete and a connection must be in progress.
Function
uint32_t WDRV_EXT_CmdDisconnect(void)
WDRV_EXT_CmdNetModeAPSet Function
Sets the Wi-Fi network type to SoftAP.
Implementation: Dynamic
File
wdrv_winc1500_api.h
C
void WDRV_EXT_CmdNetModeAPSet();
Returns
None.
Description
This function sets the Wi-Fi network type to SoftAP.
Remarks
None.
Preconditions
Wi-Fi initialization must be complete.
Function
void WDRV_EXT_CmdNetModeAPSet(void)
WDRV_EXT_CmdNetModeBSSSet Function
Sets the Wi-Fi network type to Infrastructure.
Implementation: Dynamic
File
wdrv_winc1500_api.h
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1411
C
void WDRV_EXT_CmdNetModeBSSSet();
Returns
None.
Description
This function sets the Wi-Fi network type to Infrastructure.
Remarks
None.
Preconditions
Wi-Fi initialization must be complete.
Function
void WDRV_EXT_CmdNetModeBSSSet(void)
WDRV_EXT_CmdScanStart Function
Directs the WINC1500 module to start a scan.
Implementation: Dynamic
File
wdrv_winc1500_api.h
C
uint32_t WDRV_EXT_CmdScanStart();
Returns
• 0 - Indicates success
• Non-zero value - Indicates failure
Description
This function directs the WINC1500 module to start a scan.
Remarks
None.
Preconditions
Wi-Fi initialization must be complete.
Function
uint32_t WDRV_EXT_CmdScanStart(void)
WDRV_EXT_CmdSecNoneSet Function
Sets Wi-Fi security to open (no security).
Implementation: Dynamic
File
wdrv_winc1500_api.h
C
void WDRV_EXT_CmdSecNoneSet();
Returns
None.
Description
This function sets the Wi-Fi security to open. One can only connect to an AP that is running in open mode.
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1412
Remarks
None.
Preconditions
Wi-Fi initialization must be complete and in an unconnected state.
Function
void WDRV_EXT_CmdSecNoneSet(void)
WDRV_EXT_CmdSecWEPSet Function
Sets Wi-Fi security to use WEP.
Implementation: Dynamic
File
wdrv_winc1500_api.h
C
void WDRV_EXT_CmdSecWEPSet(uint8_t * key, uint16_t len);
Returns
None.
Description
This function sets the Wi-Fi security to WEP. One can only connect to an AP that is running the same WEP mode.
Remarks
None.
Preconditions
Wi-Fi initialization must be complete and in an unconnected state.
Parameters
Parameters Description
key pointer to the WEP key buffer
len WEP key length
Function
void WDRV_EXT_CmdSecWEPSet(uint8_t *key, uint16_t len)
WDRV_EXT_CmdSecWPASet Function
Sets Wi-Fi security to use WPA/WPA2.
Implementation: Dynamic
File
wdrv_winc1500_api.h
C
void WDRV_EXT_CmdSecWPASet(uint8_t * key, uint16_t len);
Returns
None.
Description
This function sets the Wi-Fi security to WPA/WPA2. One can only connect to an AP that is running the same WPA/WPA2 mode.
Remarks
None.
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1413
Preconditions
Wi-Fi initialization must be complete and in an unconnected state.
Parameters
Parameters Description
key pointer to the WPA key buffer
len WPA key length
Function
void WDRV_EXT_CmdSecWPASet(uint8_t *key, uint16_t len)
WDRV_EXT_DataSend Function
Sends data packets to WINC1500 module.
Implementation: Dynamic
File
wdrv_winc1500_api.h
C
uint32_t WDRV_EXT_DataSend(uint16_t segSize, uint8_t * p_segData);
Returns
• 0 - Indicates success
• Non-zero value - Indicates failure
Description
This function sends data packets to the WINC1500 module.
Remarks
None.
Preconditions
Wi-Fi initialization must be complete.
Parameters
Parameters Description
seqSize data size
p_seqData pointer to the data buffer
Function
uint32_t WDRV_EXT_DataSend(uint16_t segSize, uint8_t *p_segData)
WDRV_EXT_ScanDoneSet Function
Indicates when a scan has completed.
Implementation: Dynamic
File
wdrv_wilc1000_api.h
C
void WDRV_EXT_ScanDoneSet();
Returns
None.
Description
This function indicates when a scan has completed.
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1414
Remarks
None.
Preconditions
Wi-Fi initialization must be complete.
Function
void WDRV_EXT_ScanDoneSet(void)
WDRV_EXT_CmdChannelSet Function
Sets the channel on which to operate.
Implementation: Dynamic
File
wdrv_winc1500_api.h
C
void WDRV_EXT_CmdChannelSet(uint16_t channel);
Returns
None.
Description
This function sets the channel on which to operate.
Remarks
This works only with SoftAP mode. Do not call this in other modes.
Preconditions
Wi-Fi initialization must be complete.
Parameters
Parameters Description
channel target channel
Function
void WDRV_EXT_CmdChannelSet(uint16_t channel)
WDRV_EXT_CmdSSIDSet Function
Sets the SSID.
Implementation: Dynamic
File
wdrv_wilc1000_api.h
C
void WDRV_EXT_CmdSSIDSet(uint8_t * ssid, uint16_t len);
Returns
None.
Description
This function sets the SSID and SSID length.
Remarks
Do not include a string terminator in the SSID length. SSIDs are case-sensitive. SSID length must be less than or equal to 32.
Preconditions
Wi-Fi initialization must be complete.
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1415
Parameters
Parameters Description
ssid pointer to SSID buffer
len number of bytes in SSID
Function
void WDRV_EXT_CmdSSIDSet(uint8_t *ssid, uint16_t len)
WDRV_EXT_CmdFWUpdate Function
Directs the module to start firmware download and upgrade.
Implementation: Dynamic
File
wdrv_winc1500_api.h
C
void WDRV_EXT_CmdFWUpdate();
Returns
None.
Description
This function directs the module to start the firmware download and upgrade.
Remarks
None.
Preconditions
Wi-Fi initialization must be complete.
Function
void WDRV_EXT_CmdFWUpdate(void)
WDRV_EXT_CmdSecWpsSet Function
Sets Wi-Fi security to use WPS.
Implementation: Dynamic
File
wdrv_winc1500_api.h
C
uint32_t WDRV_EXT_CmdSecWpsSet(bool pinMode, uint8_t * key, uint16_t keyLen);
Returns
• 0 - Indicates success
• Non-zero value - Indicates failure
Description
This function sets the Wi-Fi security to WPS. One can only connect to an AP that supports WPS.
Remarks
None
Preconditions
Wi-Fi initialization must be complete and in an unconnected state.
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1416
Parameters
Parameters Description
pinMode 0: PBC mode; 1: PIN mode
key pointer of the PIN buffer
keyLen PIN length
Function
int32_t WDRV_EXT_CmdSecWpsSet(bool pinMode, uint8_t *key, uint16_t keyLen)
WDRV_EXT_CmdTxPowerSet Function
Sets the Tx Power at 3 levels, high, medium and low.
Implementation: Dynamic
File
wdrv_winc1500_api.h
C
uint32_t WDRV_EXT_CmdTxPowerSet(uint32_t level);
Returns
• 0 - Indicates success
• Non-zero value - Indicates failure
Description
The function sets the module's Tx power.
Remarks
None.
Preconditions
Wi-Fi initialization must be complete.
Parameters
Parameters Description
level 1 : high - 18 dBm PA gain , 2 : medium - 12 dBm PA gain, 3 : low - 6 dBm PA gain.
Function
uint32_t WDRV_EXT_CmdTxPowerSet(uint32_t level)
WDRV_EXT_CmdConnectContextBssidGet Function
Gets the BSSID
Implementation: Dynamic
File
wdrv_winc1500_api.h
C
uint32_t WDRV_EXT_CmdConnectContextBssidGet(uint8_t * bssId);
Returns
• 0 - Indicates success
• Non-zero value - Indicates failure
Description
This function gets the current AP's BSSID.
Remarks
None.
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1417
Preconditions
Wi-Fi initialization must be complete.
Parameters
Parameters Description
bssId pointer where the current AP's BSSID will be written
Function
uint32_t WDRV_EXT_CmdConnectContextBssidGet(uint8_t *bssId)
WDRV_EXT_CmdScanOptionsSet Function
Sets scan options.
Implementation: Dynamic
File
wdrv_winc1500_api.h
C
uint32_t WDRV_EXT_CmdScanOptionsSet(uint8_t numOfSlots, uint8_t slotTime, uint8_t probesPerSlot, uint8_t
rssiThreshold);
Returns
• 0 - Indicates success
• Non-zero value - Indicates failure
Description
The function sets scan options.
Remarks
None.
Preconditions
Wi-Fi initialization must be complete.
Parameters
Parameters Description
numOfSlots The min number of slots is 2 for every channel, every slot the module will send Probe
Request on air, and wait/listen for PROBE RESP/BEACONS for the slotTime.
slotTime The time that the module will wait on every channel listening to the frames on air.
probesPerSlot Number of probe requests to be sent per channel scan slot.
rssiThreshold The RSSI threshold of the AP which will be connected to directly.
Function
uint32_t WDRV_EXT_CmdScanOptionsSet(uint8_t numOfSlots, uint8_t slotTime, uint8_t probesPerSlot, uint8_t rssiThreshold);
WDRV_EXT_CmdSSIDSet Function
Sets the SSID.
Implementation: Dynamic
File
wdrv_winc1500_api.h
C
void WDRV_EXT_CmdSSIDSet(uint8_t * ssid, uint8_t len);
Returns
None.
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1418
Description
This function sets the SSID and SSID length.
Remarks
SSIDs are case-sensitive. SSID length must be less than or equal to 32.
Preconditions
Wi-Fi initialization must be complete.
Parameters
Parameters Description
ssid pointer to SSID buffer
len number of bytes in SSID
Function
void WDRV_EXT_CmdSSIDSet(uint8_t *ssid, uint16_t len)
WDRV_EXT_ScanIsInProgress Function
Check whether host scan is now in progress or not.
Implementation: Dynamic
File
wdrv_wilc1000_api.h
C
bool WDRV_EXT_ScanIsInProgress();
Returns
• true - Host scan is in progress
• false - Host scan is not in progress
Description
Check whether host scan is now in progress or not.
Remarks
None.
Preconditions
Wi-Fi initialization must be complete.
Function
void WDRV_EXT_ScanIsInProgress(void)
d) Other Functions
WDRV_INTR_SourceDisable Function
Disables interrupts from the module.
Implementation: Dynamic
File
wdrv_mrf24wn_api.h
C
void WDRV_INTR_SourceDisable();
Returns
None.
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1419
Description
This function disables interrupts from the module.
Remarks
None.
Preconditions
Wi-Fi initialization must be complete.
Function
void WDRV_INTR_SourceDisable(void)
WDRV_INTR_SourceEnable Function
Enables interrupts from the module.
Implementation: Dynamic
File
wdrv_mrf24wn_api.h
C
void WDRV_INTR_SourceEnable();
Returns
None.
Description
This function enables interrupts from the module.
Remarks
None.
Preconditions
Wi-Fi initialization must be complete.
Function
void WDRV_INTR_SourceEnable(void)
WDRV_EXT_Initialize Function
Initializes the WILC1000 Wi-Fi driver.
Implementation: Dynamic
File
wdrv_wilc1000_api.h
C
void WDRV_EXT_Initialize(WDRV_HOOKS const *const ehooks, bool initWait);
Returns
None.
Description
This function initializes the WILC1000 Wi-Fi driver, making it ready for clients to use.
Remarks
None.
Preconditions
None.
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1420
Parameters
Parameters Description
ehooks pointer to WDRV layer hooks
initWait true will put WDRV in wait during initialization
Function
void WDRV_EXT_Initialize(WDRV_HOOKS const *const ehooks, bool initWait)
WDRV_EXT_RssiRead Function
Requests RSSI for the connected AP.
Implementation: Dynamic
File
wdrv_winc1500_api.h
C
uint32_t WDRV_EXT_RssiRead();
Returns
• 0 - Indicates success
• Non-zero value - Indicates failure
Description
This function requests RSSI for the connected AP.
Remarks
None.
Preconditions
Wi-Fi initialization must be complete.
Function
void WDRV_EXT_RssiRead(void)
WDRV_EXT_WPSResultsRead Function
Reads the WPS process results back from the WINC1500 module and updates the configuration data.
Implementation: Dynamic
File
wdrv_winc1500_api.h
C
void WDRV_EXT_WPSResultsRead(WDRV_CONFIG * config, uint32_t * status);
Returns
None.
Description
After the WPS process has completed, this function is used to read the WPS process results from the WINC1500 module and update the
configuration data.
Remarks
None.
Preconditions
Wi-Fi initialization must be complete.
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1421
Parameters
Parameters Description
config pointer to where configuration data will be updated
status pointer to where WPS process status will be written
Function
void WDRV_EXT_WPSResultsRead(WDRV_CONFIG *config, uint32_t *status)
WDRV_STUB_Assert Function
Dumps out an error message on serial console and resets itself when the driver asserts.
Implementation: Dynamic
File
wdrv_winc1500_stub.h
C
void WDRV_STUB_Assert(int condition, const char * msg, const char * file, int line);
Returns
None.
Description
Dumps out an error message on serial console and resets itself when the driver asserts.
Remarks
None.
Preconditions
The TCP/IP stack should be initialized.
Parameters
Parameters Description
condition asserts if false
msg error message
file file name
line line number where driver asserts.
Function
WDRV_STUB_Assert(int condition, const char *msg, const char *file, int line)
WDRV_STUB_GPIO_ChipDisable Function
Disables the WINC1500 chip.
Implementation: Dynamic
File
wdrv_winc1500_stub.h
C
void WDRV_STUB_GPIO_ChipDisable();
Returns
None.
Description
This function disables the WINC1500 chip.
Remarks
None.
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1422
Preconditions
The TCP/IP stack should be initialized.
Function
void WDRV_STUB_GPIO_ChipDisable(void)
WDRV_STUB_GPIO_ChipEnable Function
Enables the WINC1500 chip.
Implementation: Dynamic
File
wdrv_winc1500_stub.h
C
void WDRV_STUB_GPIO_ChipEnable();
Returns
None.
Description
This function enables the WINC1500 chip.
Remarks
None.
Preconditions
The TCP/IP stack should be initialized.
Function
void WDRV_STUB_GPIO_ChipEnable(void)
WDRV_STUB_GPIO_DeInitialize Function
Deinitializes the GPIO object for the Wi-Fi driver.
Implementation: Dynamic
File
wdrv_winc1500_stub.h
C
void WDRV_STUB_GPIO_DeInitialize();
Returns
None.
Description
This function deinitializes the GPIO object for the Wi-Fi driver.
Remarks
None.
Preconditions
The TCP/IP stack should be initialized.
Function
void WDRV_STUB_GPIO_DeInitialize(void)
WDRV_STUB_GPIO_Initialize Function
Initializes the GPIO object for the Wi-Fi driver.
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1423
Implementation: Dynamic
File
wdrv_winc1500_stub.h
C
void WDRV_STUB_GPIO_Initialize();
Returns
None.
Description
This function initializes the GPIO object for the Wi-Fi driver.
Remarks
None.
Preconditions
The TCP/IP stack should be initialized.
Function
void WDRV_STUB_GPIO_Initialize(void)
WDRV_STUB_GPIO_ModuleReset Function
Resets the WINC1500 module.
Implementation: Dynamic
File
wdrv_winc1500_stub.h
C
void WDRV_STUB_GPIO_ModuleReset();
Returns
None.
Description
This function resets the WINC1500 module.
Remarks
None.
Preconditions
The TCP/IP stack should be initialized.
Function
void WDRV_STUB_GPIO_ModuleReset(void)
WDRV_STUB_GPIO_ModuleUnreset Function
Unresets the WINC1500 module.
Implementation: Dynamic
File
wdrv_winc1500_stub.h
C
void WDRV_STUB_GPIO_ModuleUnreset();
Returns
None.
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1424
Description
This function unresets the WINC1500 module.
Remarks
None.
Preconditions
The TCP/IP stack should be initialized.
Parameters
Parameters Description
board Microchip development kit type (i.e., PIC32MZ EC Starter Kit, PIC32 Ethernet Starter Kit, etc.)
Function
void WDRV_STUB_GPIO_ModuleUnreset(void)
WDRV_STUB_HardDelay Function
Waits spinning for the delay milliseconds.
Implementation: Dynamic
File
wdrv_winc1500_stub.h
C
void WDRV_STUB_HardDelay(uint16_t delay);
Returns
None.
Description
This function has driver wait spinining for the delay milliseconds.
Remarks
None.
Preconditions
The TCP/IP stack should be initialized.
Parameters
Parameters Description
board duration to spin.
Function
WDRV_STUB_HardDelay(uint16_t delay)
WDRV_STUB_INTR_Deinit Function
Deinitializes interrupts for Wi-Fi driver.
Implementation: Dynamic
File
wdrv_winc1500_stub.h
C
void WDRV_STUB_INTR_Deinit();
Returns
None.
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1425
Description
This function deinitializes interrupts for the Wi-Fi driver.
Remarks
None.
Preconditions
The TCP/IP stack should be initialized.
Function
void WDRV_STUB_INTR_Deinit(void)
WDRV_STUB_INTR_Init Function
Initializes interrupts for the Wi-Fi driver.
Implementation: Dynamic
File
wdrv_winc1500_stub.h
C
void WDRV_STUB_INTR_Init(void (*isr)(void));
Returns
None.
Description
This function initializes interrupts for the Wi-Fi driver.
Remarks
None.
Preconditions
The TCP/IP stack should be initialized.
Parameters
Parameters Description
isr function pointer to the interrupt service handler.
Function
void WDRV_STUB_INTR_Init(void (*isr)(void))
WDRV_STUB_INTR_SourceDisable Function
Disables interrupts from the module.
Implementation: Dynamic
File
wdrv_winc1500_stub.h
C
void WDRV_STUB_INTR_SourceDisable();
Returns
None.
Description
This function disables interrupts from the module.
Remarks
None.
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1426
Preconditions
Wi-Fi initialization must be complete.
Function
void WDRV_STUB_INTR_SourceDisable(void)
WDRV_STUB_INTR_SourceEnable Function
Enables interrupts from the module.
Implementation: Dynamic
File
wdrv_winc1500_stub.h
C
void WDRV_STUB_INTR_SourceEnable();
Returns
None.
Description
This function enables interrupts from the module.
Remarks
None.
Preconditions
Wi-Fi initialization must be complete.
Function
void WDRV_STUB_INTR_SourceEnable(void)
WDRV_STUB_SPI_Deinitialize Function
Deinitializes the SPI object for the Wi-Fi driver.
Implementation: Dynamic
File
wdrv_winc1500_stub.h
C
void WDRV_STUB_SPI_Deinitialize();
Returns
None.
Description
This function deinitializes the SPI object for the Wi-Fi driver.
Remarks
None.
Preconditions
None.
Function
void WDRV_STUB_SPI_Deinitialize(void)
WDRV_STUB_SPI_In Function
Receives data from the module through the SPI bus.
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1427
Implementation: Dynamic
File
wdrv_winc1500_stub.h
C
bool WDRV_STUB_SPI_In(unsigned char *const buf, uint32_t size);
Returns
None.
Description
This function receives data from the module through the SPI bus.
Remarks
None.
Preconditions
SPI driver should be initialized.
Parameters
Parameters Description
buf buffer pointer of input data
size the input data size
Function
bool WDRV_STUB_SPI_In(unsigned char *const buf, uint32_t size)
WDRV_STUB_SPI_Initialize Function
Initializes the SPI object for the Wi-Fi driver.
Implementation: Dynamic
File
wdrv_winc1500_stub.h
C
void WDRV_STUB_SPI_Initialize();
Returns
None.
Description
This function initializes the SPI object for the Wi-Fi driver.
Remarks
None.
Preconditions
None.
Function
void WDRV_STUB_SPI_Initialize(void)
WDRV_STUB_SPI_Out Function
Sends data out to the module through the SPI bus.
Implementation: Dynamic
File
wdrv_winc1500_stub.h
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1428
C
bool WDRV_STUB_SPI_Out(unsigned char *const buf, uint32_t size);
Returns
True - Indicates success False - Indicates failure
Description
This function sends data out to the module through the SPI bus.
Remarks
None.
Preconditions
SPI driver should be initialized.
Parameters
Parameters Description
buf buffer pointer of output data
size the output data size
Function
bool WDRV_STUB_SPI_Out(unsigned char const *buf, uint32_t size)
e) Data Types and Constants
_WDRV_WINC1500_API_H Macro
File
wdrv_winc1500_api.h
C
#define _WDRV_WINC1500_API_H
Description
This is macro _WDRV_WINC1500_API_H.
WDRV_STUB_Print Macro
File
wdrv_winc1500_stub.h
C
#define WDRV_STUB_Print(x) SYS_CONSOLE_PRINT x
Description
This is macro WDRV_STUB_Print.
Files
Files
Name Description
wdrv_winc1500_api.h WINC1500 wireless driver APIs.
wdrv_winc1500_stub.h WINC1500 wireless driver stub APIs.
Description
This section lists the source and header files used by the MRF24WN Wi-Fi Driver Library.
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1429
wdrv_winc1500_api.h
WINC1500 wireless driver APIs.
Functions
Name Description
WDRV_CLI_Init Initializes the console CLI interface.
Implementation: Dynamic
WDRV_EXT_CmdChannelSet Sets the channel on which to operate.
Implementation: Dynamic
WDRV_EXT_CmdConnect Directs the WINC1500 to connect to a Wi-Fi network.
Implementation: Dynamic
WDRV_EXT_CmdConnectContextBssidGet Gets the BSSID
Implementation: Dynamic
WDRV_EXT_CmdDisconnect Directs the WINC1500 to disconnect from a Wi-Fi network.
Implementation: Dynamic
WDRV_EXT_CmdFWUpdate Directs the module to start firmware download and upgrade.
Implementation: Dynamic
WDRV_EXT_CmdFWVersionGet Retrieves FW version information.
Implementation: Dynamic
WDRV_EXT_CmdMacAddressGet Retrieves the WINC1500 MAC address.
Implementation: Dynamic
WDRV_EXT_CmdNetModeAPSet Sets the Wi-Fi network type to SoftAP.
Implementation: Dynamic
WDRV_EXT_CmdNetModeBSSSet Sets the Wi-Fi network type to Infrastructure.
Implementation: Dynamic
WDRV_EXT_CmdPowerSavePut Puts the module in power save mode.
Implementation: Dynamic
WDRV_EXT_CmdScanGet Reads the number of scan results from the WINC1500 module.
Implementation: Dynamic
WDRV_EXT_CmdScanOptionsSet Sets scan options.
Implementation: Dynamic
WDRV_EXT_CmdScanStart Directs the WINC1500 module to start a scan.
Implementation: Dynamic
WDRV_EXT_CmdSecNoneSet Sets Wi-Fi security to open (no security).
Implementation: Dynamic
WDRV_EXT_CmdSecWEPSet Sets Wi-Fi security to use WEP.
Implementation: Dynamic
WDRV_EXT_CmdSecWPASet Sets Wi-Fi security to use WPA/WPA2.
Implementation: Dynamic
WDRV_EXT_CmdSecWpsSet Sets Wi-Fi security to use WPS.
Implementation: Dynamic
WDRV_EXT_CmdSSIDGet Gets the SSID.
Implementation: Dynamic
WDRV_EXT_CmdSSIDSet Sets the SSID.
Implementation: Dynamic
WDRV_EXT_CmdTxPowerSet Sets the Tx Power at 3 levels, high, medium and low.
Implementation: Dynamic
WDRV_EXT_DataSend Sends data packets to WINC1500 module.
Implementation: Dynamic
WDRV_EXT_Deinitialize Deinitializes the WINC1500 Wi-Fi driver.
Implementation: Dynamic
WDRV_EXT_HWInterruptHandler Wi-Fi driver (WINC1500-specific) interrupt service routine.
Implementation: Dynamic
WDRV_EXT_Initialize Initializes the WINC1500 Wi-Fi driver.
Implementation: Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1430
WDRV_EXT_ModuleUpDown Enables or disables WINC1500 module.
Implementation: Dynamic
WDRV_EXT_MulticastFilterSet Sets a multicast address filter.
Implementation: Dynamic
WDRV_EXT_RssiRead Requests RSSI for the connected AP.
Implementation: Dynamic
WDRV_EXT_ScanResultGet Reads the selected scan results back from the WINC1500 module.
Implementation: Dynamic
WDRV_EXT_WPSResultsRead Reads the WPS process results back from the WINC1500 module and updates the
configuration data.
Implementation: Dynamic
WDRV_WINC1500_ISR Wi-Fi driver (WINC1500-specific) interrupt service routine.
Implementation: Dynamic
Macros
Name Description
_WDRV_WINC1500_API_H This is macro _WDRV_WINC1500_API_H.
Description
WINC1500 wireless driver APIs.
File Name
wdrv_winc1500_api.h
Company
Microchip Technology Inc.
wdrv_winc1500_stub.h
WINC1500 wireless driver stub APIs.
Functions
Name Description
WDRV_STUB_Assert Dumps out an error message on serial console and resets itself when the driver asserts.
Implementation: Dynamic
WDRV_STUB_GPIO_ChipDisable Disables the WINC1500 chip.
Implementation: Dynamic
WDRV_STUB_GPIO_ChipEnable Enables the WINC1500 chip.
Implementation: Dynamic
WDRV_STUB_GPIO_DeInitialize Deinitializes the GPIO object for the Wi-Fi driver.
Implementation: Dynamic
WDRV_STUB_GPIO_Initialize Initializes the GPIO object for the Wi-Fi driver.
Implementation: Dynamic
WDRV_STUB_GPIO_ModuleReset Resets the WINC1500 module.
Implementation: Dynamic
WDRV_STUB_GPIO_ModuleUnreset Unresets the WINC1500 module.
Implementation: Dynamic
WDRV_STUB_HardDelay Waits spinning for the delay milliseconds.
Implementation: Dynamic
WDRV_STUB_INTR_Deinit Deinitializes interrupts for Wi-Fi driver.
Implementation: Dynamic
WDRV_STUB_INTR_Init Initializes interrupts for the Wi-Fi driver.
Implementation: Dynamic
WDRV_STUB_INTR_SourceDisable Disables interrupts from the module.
Implementation: Dynamic
WDRV_STUB_INTR_SourceEnable Enables interrupts from the module.
Implementation: Dynamic
WDRV_STUB_SPI_Deinitialize Deinitializes the SPI object for the Wi-Fi driver.
Implementation: Dynamic
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1431
WDRV_STUB_SPI_In Receives data from the module through the SPI bus.
Implementation: Dynamic
WDRV_STUB_SPI_Initialize Initializes the SPI object for the Wi-Fi driver.
Implementation: Dynamic
WDRV_STUB_SPI_Out Sends data out to the module through the SPI bus.
Implementation: Dynamic
Macros
Name Description
WDRV_STUB_Print This is macro WDRV_STUB_Print.
Description
WINC1500 wireless driver stub APIs.
File Name
wdrv_winc1500_stub.h
Company
Microchip Technology Inc.
WINC1500 Socket Mode Driver Library
This section provides documentation for the WINC1500 Socket Mode Driver Library.
Introduction
This library provides a low-level abstraction of the WINC1500 Socket Mode Driver Library that is available on the Microchip family of
microcontrollers with a convenient C language interface. It can be used to simplify low-level access to the module without the necessity of
interacting directly with the module's registers, there by hiding differences from one microcontroller variant to another.
Description
The WINC1500 Socket Mode Driver library is a C library provides the host MCU application with APIs for WLAN and socket operations, off-loading
the host MCU TCP/IP networking and transport layer operations to the WINC1500 module firmware.
The MPLAB Harmony Integrated Software Framework blocks for the WINC1500 Wi-Fi Application are shown in the following diagram.
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1432
The following diagram shows the partitioning of the MPLAB Harmony WINC1500 Socket Mode Driver software on a MCU. Further discussions
reference this diagram.
In the previous diagram, the WINC1500 module requires only a SPI interface, a timer, 2 GPIOs for CE and INT, and an interrupt line to connect to
the host PIC32 MCU, as shown in the following figure. The figure also shows the I2C interface between the ECC508 device and the Host MCU;
however, this feature is not available in the current release and will be available in a future release MPLAB Harmony.
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1433
Using the Library
This topic describes the basic architecture of the WINC1500 Wi-Fi Driver Library and provides information and examples on its use.
Description
The WINC1500 Socket Mode Driver Library implements the MPLAB Harmony device driver and communicates with the WINC1500 Host Driver
Software to access and control the external WINC1500 module which firmware consists of the following key features:
• Wi-Fi IEEE 802.11 b/g/n STA, AP, and Wi-Fi Direct® modes
• Wi-Fi Protected Setup (WPS)
• Support of WEP, WPA/WPA2 personal, and WPA/WPA2 Enterprise security
• Embedded network stack protocols
• Embedded TCP/IP stack with BSD-style socket API
• Embedded network protocols – DHCP client/server – DNS resolver client – SNTP client for UTC time synchronization
• Embedded TLS security abstracted behind BSD-style socket API
• HTTP Server for provisioning over AP mode
• 8 MB internal Flash memory with OTA firmware upgrade
• Low power consumption with different power saving modes
• SPI, I2C, and UART support
The WINC1500 Host Driver Software is a C library which provides the host MCU application with necessary APIs to perform necessary WLAN and
socket operations. The architecture of the WINC1500 Host Driver Software which runs on the host MCU is shown below, and the components of
the host driver are described in the following diagram.
WLAN Application Interface API
This module provides an interface to the application for all Wi-Fi operations and any non-IP related operations. This includes the following services:
• Wi-Fi STA management operations
• Wi-Fi Scan
• Wi-Fi Connection management (Connect, Disconnect, Connection status, etc.) – WPS activation/deactivation
• Wi-Fi AP enable/disable
• Wi-Fi Direct enable/disable
• Wi-Fi power save control API
• Wi-Fi monitoring (Sniffer) mode
This interface is defined in the file: m2m_wifi.h.
Socket API
This module provides the socket communication APIs that are mostly compliant with the well-known BSD sockets. To comply with the nature of
MCU application environment, there are differences in API prototypes and in usage of some APIs between WINC1500 sockets and BSD sockets.
This interface is defined in the file: socket.h.
Host Interface (HIF)
The Host Interface is responsible for handling the communication between the host driver and the WINC1500 firmware. This includes interrupt
handling, DMA and HIF command/response management. The host driver communicates with the firmware in a form of commands and responses
formatted by the HIF layer.
The interface is defined in the file: m2m_hif.h.
Board Support Package (BSP)
The Board Support Package abstracts the functionality of a specific host MCU platform. This allows the driver to be portable to a wide range of
hardware and hosts. Abstraction includes: pin assignment, power on/off sequence, reset sequence and peripheral definitions (Push buttons,
LEDs…etc.).
The minimum required BSP functionality is defined in the file: nm_bsp.h.
Serial Bus Interface
The Serial Bus Interface module abstracts the hardware associated with implementing the bus between the Host and the WINC1500. The serial
bus interface abstracts I2C, SPI, or UART bus interface. The basic bus access operations (Read and Write) are implemented in this module as
appropriate for the interface type and the specific hardware.
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1434
The bus interface APIs are defined in the file: nm_bus_wrapper.h.
Using the WINC1500 Socket Mode Driver Library
The interface to the WINC1500 Socket Driver Library is defined in these header files:
• wdrv_winc1500_api.h
• wdrv_winc1500_stub.h
Any C language source (.c) file that uses the WINC1500 Socket Mode Driver library should include both wdrv_winc1500_api.h and
wdrv_winc1500_stub.h.
Abstraction of the WINC1500 Wi-Fi Application
The major blocks of software comprise of a WINC1500 Wi-Fi application are listed and described in the following table.
Software
Block
Description
Application
Software
This is the application code. Note that three event handlers (OTA, Socket, and Wi-Fi) are part of this block. The event handlers
contain callback functions that the driver calls and the application processes.
WINC1500
Socket Mode
Driver
This is the WINC1500 Socket Mode driver. The driver API and Stub functions provide application software with setup for the SPI
interface between the host MCU and the external WINC1500 module, and provide application software with control and socket
data services to the external WINC1500 module via the WINC1500 Host Software Driver.
WINC1500
Socket Mode
Driver Stub
Functions
The driver Stub functions provide application software with control to the PIC32 MCU hardware blocks (SPI, EXT_INT, Timer,
GPIO, I2C) for configuration of Host PIC32 MCU specific hardware and event handling:
• SPI Interface
• GPIO control
• Timer
• Interrupt from WINC1500
• Wi-Fi, TPC/IP socket, and OTA event handling
WINC1500
Socket Mode
Driver API
Functions
The driver Ext functions provide application software access to the driver’s system interface for initialize and de-initialize of the
driver, as well as setting up the driver hardware interrupt handler and the WINC1500 interrupt service routine.
Note: Not all API functions are used in the socket mode driver library. Only these four API functions are used:
• WDRV_EXT_Initialize
• WDRV_EXT_Deinitialize
• WDRV_EXT_HWInterruptHandler
• WDRV_WINC1500_ISR
WINC1500
Host
Software
Driver APIs
The WINC1500 Host Software Driver provides the host MCU application with necessary APIs to perform necessary WLAN and
BSD socket operations by offloading these operations to the WINC1500 module firmware. See Section 3 for details of these
APIs.
Abstraction Model
This library provides a low-level abstraction of the WINC1500 Wi-Fi module with a convenient C language interface. This topic describes how that
abstraction is modeled in software and introduces the library's interface.
Description
The WINC1500 Wi-Fi Library provides the following functionality:
• Wi-Fi library initialization
• Wi-Fi network configuration
• Wi-Fi network connection
• Scanning for existing Wi-Fi networks
• Wi-Fi event processing
• Wi-Fi status
• Wi-FI console commands
Library Overview
Refer to the Driver Library Overview section for information on how the driver operates in a system.
The Library Interface functions are divided into various sub-sections, which address one of the blocks or the overall operation of the WINC1500
Socket Mode Driver Library.
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1435
Library Interface Section Description
System Interaction
Functions
Provides system module interfaces, device initialization, deinitialization, hard interrupt handler, and interrupt service
routine. See wdrv_winc1500_api.h, and wdrv_winc1500_stub.h.
Data Transfer Functions Provides data transfer functions available in the configuration. See wdrv_winc1500_api.h.
Status Functions Provides status functions. See m2m_wifi.h
Miscellaneous Functions Provides miscellaneous driver functions.
How the Library Works
This section describes how the WINC1500 Socket Mode Driver Library operates.
Description
The library provides host PIC32 MCU Wi-Fi application with interface support for the external WINC1500 module and offloads Wi-Fi and BSD
socket operations to the WINC1500 module firmware.
Configuring the SPI Driver
This section describes the configuration settings for the WINC1500 Socket Mode Driver Library.
Description
Configuration
The WINC1500 hardware requires a specific configuration of the SPI driver to work correctly. Inside the MHC SPI driver configuration make sure to
select:
• SPI clock rate of 8000000 or less
• Input phrase of SPI_INPUT_SAMPLING_PHASE_AT_END
• Clock mode of DRV_SPI_CLOCK_MODE_IDLE_LOW_EDGE_FALL
Recommended Settings
• Interrupt Driver mode
• Enhanced Buffer mode
• DMA mode enabled
• DMA Block Transfer Size to 512
• Size of DMA Buffer for dummy data to 512
• Ensure when setting up DMA in interrupt mode that the DMA interrupts are a higher priority than the SPI Driver interrupt
Examples
/*** SPI Driver Configuration ***/
#define DRV_SPI_NUMBER_OF_MODULES 6
/*** Driver Compilation and static configuration options. ***/
/*** Select SPI compilation units.***/
#define DRV_SPI_POLLED 0
#define DRV_SPI_ISR 1
#define DRV_SPI_MASTER 1
#define DRV_SPI_SLAVE 0
#define DRV_SPI_RM 1
#define DRV_SPI_EBM 0
#define DRV_SPI_8BIT 1
#define DRV_SPI_16BIT 0
#define DRV_SPI_32BIT 0
#define DRV_SPI_DMA 1
/*** SPI Driver Static Allocation Options ***/
#define DRV_SPI_INSTANCES_NUMBER 1
#define DRV_SPI_CLIENTS_NUMBER 1
#define DRV_SPI_ELEMENTS_PER_QUEUE 10
/*** SPI Driver DMA Options ***/
#define DRV_SPI_DMA_TXFER_SIZE 512
#define DRV_SPI_DMA_DUMMY_BUFFER_SIZE 512
/* SPI Driver Instance 0 Configuration */
#define DRV_SPI_SPI_ID_IDX0 SPI_ID_1
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1436
#define DRV_SPI_TASK_MODE_IDX0 DRV_SPI_TASK_MODE_ISR
#define DRV_SPI_SPI_MODE_IDX0 DRV_SPI_MODE_MASTER
#define DRV_SPI_ALLOW_IDLE_RUN_IDX0 false
#define DRV_SPI_SPI_PROTOCOL_TYPE_IDX0 DRV_SPI_PROTOCOL_TYPE_STANDARD
#define DRV_SPI_COMM_WIDTH_IDX0 SPI_COMMUNICATION_WIDTH_8BITS
#define DRV_SPI_CLOCK_SOURCE_IDX0 SPI_BAUD_RATE_PBCLK_CLOCK
#define DRV_SPI_SPI_CLOCK_IDX0 CLK_BUS_PERIPHERAL_2
#define DRV_SPI_BAUD_RATE_IDX0 8000000
#define DRV_SPI_BUFFER_TYPE_IDX0 DRV_SPI_BUFFER_TYPE_STANDARD
#define DRV_SPI_CLOCK_MODE_IDX0 DRV_SPI_CLOCK_MODE_IDLE_LOW_EDGE_FALL
#define DRV_SPI_INPUT_PHASE_IDX0 SPI_INPUT_SAMPLING_PHASE_AT_END
#define DRV_SPI_TRANSMIT_DUMMY_BYTE_VALUE_IDX0 0x00
#define DRV_SPI_TX_INT_SOURCE_IDX0 INT_SOURCE_SPI_1_TRANSMIT
#define DRV_SPI_RX_INT_SOURCE_IDX0 INT_SOURCE_SPI_1_RECEIVE
#define DRV_SPI_ERROR_INT_SOURCE_IDX0 INT_SOURCE_SPI_1_ERROR
#define DRV_SPI_TX_INT_VECTOR_IDX0 INT_VECTOR_SPI1_TX
#define DRV_SPI_RX_INT_VECTOR_IDX0 INT_VECTOR_SPI1_RX
#define DRV_DRV_SPI_ERROR_INT_VECTOR_IDX0 INT_VECTOR_SPI1_FAULT
#define DRV_SPI_TX_INT_PRIORITY_IDX0 INT_PRIORITY_LEVEL1
#define DRV_SPI_TX_INT_SUB_PRIORITY_IDX0 INT_SUBPRIORITY_LEVEL0
#define DRV_SPI_RX_INT_PRIORITY_IDX0 INT_PRIORITY_LEVEL1
#define DRV_SPI_RX_INT_SUB_PRIORITY_IDX0 INT_SUBPRIORITY_LEVEL0
#define DRV_SPI_ERROR_INT_PRIORITY_IDX0 INT_PRIORITY_LEVEL1
#define DRV_SPI_ERROR_INT_SUB_PRIORITY_IDX0 INT_SUBPRIORITY_LEVEL0
#define DRV_SPI_QUEUE_SIZE_IDX0 10
#define DRV_SPI_RESERVED_JOB_IDX0 1
#define DRV_SPI_TX_DMA_CHANNEL_IDX0 DMA_CHANNEL_1
#define DRV_SPI_TX_DMA_THRESHOLD_IDX0 16
#define DRV_SPI_RX_DMA_CHANNEL_IDX0 DMA_CHANNEL_0
#define DRV_SPI_RX_DMA_THRESHOLD_IDX0 16
WINC1500 Module Firmware Overview
Provides an overview of the firmware for the WINC1500 Module.
Description
The firmware comprises the Wi-Fi IEEE-802.11 MAC layer and embedded protocol stacks which offload the host MCU. The components of the
system are described in the following sub-sections.
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1437
WLAN APIs
This WLAN APIs provide an interface to the application for all Wi-Fi operations and any non-IP related operations. This includes the following
services:
• Wi-Fi STA management operations
• Wi-Fi Scan
• Wi-Fi Connection management (Connect, Disconnect, Connection status, etc.)
• WPS activation/deactivation
• Wi-Fi AP enable/disable
• Wi-Fi Direct enable/disable
• Wi-Fi power save control API
• Wi-Fi monitoring (Sniffer) mode
This interface is defined in the file: m2m_wifi.h.
Socket API
The socket APIs are mostly compliant with the BSD sockets and to comply with the nature of MCU application environment, there are differences
in API prototypes and in usage of some APIs between WINC1500 sockets and BSD sockets.
This interface is defined in the file: socket.h.
IoT Library
The IoT library provides a set of networking protocols in WINC1500 firmware. It offloads the host MCU from networking and transport layer
protocols. The following sections describe the components of WINC1500 IoT library.
• WINC1500 TCP/IP STACK - The WINC TCP/IP is an IPv4.0 stack based on the uIP TCP/IP stack (pronounced micro IP).
• DHCP CLIENT/SERVER - A DHCP client is embedded in WINC1500 firmware that can obtain an IP configuration automatically after
connecting to a Wi-Fi network. WINC1500 firmware provides an instance of a DHCP server that starts automatically when WINC AP mode is
enabled. When the host MCU application activates the AP mode, it is allowed to configure the DHCP Server IP address pool range within the
AP configuration parameters.
• DNS RESOLVER – WINC1500 firmware contains an instance of an embedded DNS resolver. This module can return an IP address by
resolving the host domain names supplied with the socket API call gethostbyname.
• SNTP - The SNTP (Simple Network Time Protocol) module implements an SNTP client used to synchronize the WINC1500 internal clock to the
UTC clock.
• EAP-TTLS/MSCHAPV2.0 - This module implements the authentication protocol EAP-TTLS/MsChapv2.0 used for establishing a Wi-Fi
connection with an AP by with WPA-Enterprise security.
• TRANSPORT LAYER SECURITY - For TLS implementation.
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1438
• WI-FI PROTECTED SETUP - For WPS protocol implementation.
• WI-FI DIRECT - For Wi-Fi Direct protocol implementation.
• CRYPTO LIBRARY - The Crypto Library contains a set of cryptographic algorithms used by common security protocols. This library has an
implementation of the following algorithms:
• MD4 - Hash algorithm (Used only for MsChapv2.0 digest calculation)
• MD5 - Hash algorithm
• SHA-1 - Hash algorithm
• SHA-256 - Hash algorithm
• DES Encryption (Used only for MsChapv2.0 digest calculation)
• MS-CHAPv2.0 (Used as the EAP-TTLS inner authentication algorithm)
• AES-128, AES-256 Encryption (Used for securing WPS and TLS traffic)
• BigInt module for large integer arithmetic (for Public Key Cryptographic computations)
• RSA Public Key cryptography algorithms (includes RSA Signature and RSA Encryption algorithms)
Host Interface Driver Wi-Fi Events
Provides information on the Host Interface Driver Wi-Fi events.
Description
There are four categories of events:
• Wi-Fi events
• Socket events
• OTA (Over-The-Air) update events
• Error Events
Wi-Fi Events
Wi-Fi events must be customized to suit the application. The WINC1500 socket driver calls the event callback function to notify the application of
Wi-Fi events. The p_eventData parameter points to a ‘C’ union of containing all possible Wi-Fi event data. Not all events have data associated with
them – in this case the pointer will be NULL. When an event occurs, the event data should be read as soon as possible before another event
occurs which will overwrite data from the previous event.
If the event data is to be retrieved outside the event handler function, the utility function m2m_wifi_get_wifi_event_data() returns a pointer to the
t_wifiEventData union.
Socket Events
Socket events are handled, but must be customized to suit the application. The WINC1500 driver calls the socket event callback function to notify
the application of socket events. The p_eventData parameter points to a ‘C’ union of containing all possible socket event data. Not all events have
data associated with them – in this case the pointer will be NULL. When an event occurs, the event data should be read as soon as possible
before another event occurs which will overwrite data from the previous event.
If the event data is to be retrieved outside the event handler function, the utility function m2m_wifi_get_socket_event_data() returns a pointer to the
t_socketEventData union.
OTA Events
OTA events are associated with downloading and switching to a new WINC1500 firmware image downloaded via the Wi-Fi network. The
WINC1500 driver calls the OTA event callback function to notify the application of OTA events. The p_eventData parameter points to a ‘C’
structure containing the OTA event data.
If the event data is to be retrieved outside the event handler function, the utility function m2m_wifi_get_ota_event_data() returns a pointer to the
t_otaEventData structure.
Error Events
The application is notified of error events via the callback. Error codes are defined in: wf_errors.h.
Configuring the Library
This section describes how to configure the WINC1500 Wi-Fi driver.
Description
The configuration of the WINC1500 Wi-Fi Driver is based on the file system_config.h.
This header file contains the configuration selection for the WINC1500 Socket Mode Driver Library. Based on the selection, the WINC1500 Socket
Mode Driver Library may support the selected features. These configuration settings will apply to all instances of the WINC1500 Socket Mode
Driver Library.
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1439
This header can be placed anywhere; however, the path of this header needs to be present in the include search path for a successful build. Refer
to the Applications Help section for more details.
Building the Library
This section lists the files that are available in the WINC1500 Wi-Fi Driver Library.
Description
The following three tables list and describe the header (.h) and source (.c) files that implement this library. The parent folder for these files is
/framework/driver/wifi/winc1500.
Interface File(s)
This table lists and describes the header files that must be included (i.e., using #include) by any code that uses this library.
Source File Name Description
wdrv_winc1500_stub.h Contains Stub function prototypes for interfacing to the WINC1500 Wi-Fi Driver.
wdrv_winc1500_api.h Contains API function prototypes for interfacing to the WINC1500 Wi-Fi Driver.
Required File(s)
All of the required files listed in the following table are automatically added into the MPLAB X IDE project by the MHC
when the library is selected for use.
This table lists and describes the source and header files that must always be included in the MPLAB X IDE project to build this library.
Source Folder Name Description
/driver/wifi/winc1500/dev/console/wdrv_winc1500_console.c Console module for WINC1500 wireless
driver.
/driver/wifi/winc1500/dev/gpio/wdrv_winc1500_eint.c External interrupt handler for WINC1500
wireless driver.
/driver/wifi/winc1500/dev/gpio/wdrv_winc1500_gpio.c GPIO interface for WINC1500 wireless
driver.
/driver/wifi/winc1500/dev/spi/wdrv_winc1500_spi.c Support SPI communications to the
WINC1500 module.
/driver/wifi/winc1500/dev/timer/wdrv_winc1500_timer.c Timer functions for WINC1500 wireless
driver.
/driver/wifi/winc1500/osal/wdrv_winc1500_osal.c OS abstraction layer for WINC1500
wireless driver.
/driver/wifi/winc1500/wireless_driver_extension/common/source/nm_common.c This module contains common APIs
implementations.
/driver/wifi/winc1500/wireless_driver_extension/driver/source/m2m_hif.c This module contains M2M host
interface API implementations.
/driver/wifi/winc1500/wireless_driver_extension/driver/source/m2m_ota.c WINC1500 IoT OTA Interface.
/driver/wifi/winc1500/wireless_driver_extension/driver/source/m2m_periph.c WINC1500 Peripherals Application
Interface.
/driver/wifi/winc1500/wireless_driver_extension/driver/source/m2m_wifi.c This module contains M2M Wi-Fi APIs
implementation.
/driver/wifi/winc1500/wireless_driver_extension/driver/source/nmasic.c This module contains WINC1500 ASIC
specific internal APIs.
/driver/wifi/winc1500/wireless_driver_extension/driver/source/nmbus.c This module contains WINC1500 bus
APIs implementation.
/driver/wifi/winc1500/wireless_driver_extension/driver/source/nmdrv.c This module contains WINC1500 M2M
driver APIs implementation.
/driver/wifi/winc1500/wireless_driver_extension/driver/source/nmspi.c This module contains WINC1500 SPI
protocol bus APIs implementation.
/driver/wifi/winc1500/wireless_driver_extension/socket/source/socket.c WINC1500 BSD Compatible Socket
Interface.
/driver/wifi/winc1500/wireless_driver_extension/spi_flash/source/spi_flash.c WINC1500 SPI flash interface.
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1440
/driver/wifi/winc1500/wireless_driver_extension/wdrvext_winc1500.c WINC1500 wireless driver extension.
/driver/wifi/winc1500/wireless_driver_extension/winc1500_fw_update.c WINC1500 firmware update support.
/driver/wifi/winc1500/wireless_driver_extension/winc1500_task.c Entry point of WINC1500 core driver.
Optional File(s)
This table lists and describes the source and header files that may optionally be included if required for the desired implementation.
Source File Name Description
N/A The WINC1500 Wi-Fi Driver controller has no optional files.
Module Dependencies
The WINC1500 Socket Mode Driver Library depends on the following modules:
• SPI Driver Library
• SPI Flash Driver Library
• WINC1500 Wi-Fi Driver Ethernet Mode Library
• Timer Driver Library
• USART Driver Library
Library Interface
This section describes the Application Programming Interface (API) functions of the WINC1500 Socket Mode Driver. Refer to the WINC1500 Wi-Fi
Driver Library > Library Interface section for information on the APIs in that library that are also used by the WINC1500 Socket Mode Driver.
Refer to each section for a detailed description.
WINC1500 Firmware Update Utility
Refer to WINC1500 Firmware Update Guide for detailed information on using the firmware update utility.
Volume V: MPLAB Harmony Framework Driver Libraries Help Wi-Fi Driver Libraries
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1441
Index
_
_DRV_AK4642_H macro 189
_DRV_AK4953_H macro 232
_DRV_AK7755_H macro 305
_DRV_CAMERA_OVM7690_delayMS function 95
_DRV_CAMERA_OVM7690_DMAEventHandler function 95
_DRV_CAMERA_OVM7690_HardwareSetup function 95
_DRV_COMMON_H macro 18
_DRV_ENC28J60_Configuration structure 424
_DRV_ENCX24J600_Configuration structure 444
_DRV_IPF_CONFIG_TEMPLATE_H macro 879
_DRV_IPF_H macro 878
_DRV_MIIM_CONFIG_H macro 620
_DRV_MTCH6301_CLIENT_OBJECT structure 1072
_DRV_MXT_CLIENT_OBJECT structure 1132
_DRV_MXT336T_H macro 1139
_DRV_PMP_QUEUE_ELEMENT_OBJ structure 706
_DRV_SDCARD_INIT structure 737
_DRV_SRAM_H macro 968
_DRV_TOUCH_ADC10BIT_CLIENT_DATA structure 1030
_DRV_TOUCH_ADC10BIT_INIT structure 1031
_DRV_WM8904_CONFIG_TEMPLATE_H macro 320
_DRV_WM8904_H macro 342
_PLIB_UNSUPPORTED macro 19
_WDRV_WINC1500_API_H macro 1429
1
10-bit ADC Touch Driver Library 1017
A
a) System Interaction Functions 362
Abstraction Model 27, 81, 106, 157, 199, 238, 278, 317, 360, 378, 408,
428, 447, 469, 516, 520, 553, 611, 614, 618, 645, 682, 715, 744, 772,
848, 882, 918, 946, 970, 1034, 1038, 1056, 1078, 1108, 1177, 1236,
1295, 1352, 1386, 1394, 1435
ADC Touch Driver Library 1034
AK4384 Codec Driver Library 106
AK4642 Codec Driver Library 157
AK4953 Codec Driver Library 199
AK4954 Codec Driver Library 238
AK7755 Codec Driver Library 278
AR1021 Touch Driver Library 1038
BM64 Bluetooth Driver Library 27
CTR Driver Library 360
Data EEPROM Driver Library 378
Ethernet MAC Driver Library 447, 516
Ethernet PHY Driver Library 469
MIIM Driver Library 618
MRF24WN Wi-Fi Driver Library 1352
MTCH6301 Touch Driver Library 1056
MTCH6303 Touch Driver Library 1078
NVM Driver Library 645
PMP Driver Library 682
SD Card Driver Library 715
SPI Driver Library 744
SPI Flash Driver Library 772
SPI PIC32WK IPF Flash Driver Library 848
SQI Driver Library 882
SQI Flash Driver Library 918
Timer Driver Library 970
USART Driver Library 1295
WILC1000 Wi-Fi Driver Library 1386
WINC1500 Socket Mode Driver Library 1435
WINC1500 Wi-Fi Driver Library 1394
WM8904 Codec Driver Library 317
ADC Driver Library 20
ADC Touch Driver Library 1034
AK4384 Codec Driver Library 105
AK4642 Codec Driver Library 156
AK4953 Codec Driver Library 198
AK4954 Codec Driver Library 237
AK7755 Codec Driver Library 277
Alarm Functionality 974
AR1021 Touch Driver Library 1038
AVRCP Functions 32
B
b) Other Functions 365
BLE Functions 32
Block Operations 774, 850
Bluetooth Driver Libraries 25
BM64 Bluetooth Driver Library 25
Buffer Queue Transfer Model 1304
Building the Library 36, 83, 119, 168, 206, 246, 286, 323, 351, 361, 384,
411, 430, 452, 473, 518, 533, 570, 613, 621, 654, 689, 721, 754, 782,
851, 889, 923, 951, 979, 1020, 1037, 1043, 1062, 1079, 1114, 1188,
1246, 1315, 1355, 1389, 1397, 1440
10-bit ADC Touch Driver Library 1020
ADC Touch Driver Library 1037
AK4384 Driver Library 119
AK4642 Driver Library 168
AK4953 Driver Library 206
AK4954 Driver Library 246
AK7755 Driver Library 286
AR1021 Touch Driver Library 1043
BM64 Bluetooth Driver Library 36
CPLD XC2C64A Driver Library 351
CTR Driver Library 361
Data EEPROM Driver Library 384
ENC28J60 Driver Library 411
ENCX24J600 Driver Library 430
Ethernet MAC Driver Library 452, 518
Ethernet PHY Driver Library 473
I2C Driver Library 533
I2S Driver Library 570
MRF24WN Wi-Fi Driver Library 1355, 1389, 1397, 1440
MTCH6301 Touch Driver Library 1062
MTCH6303 Touch Driver Library 1079
NVM Driver Library 654
PMP Driver Library 689
SD Card Driver Library 721
SPI Driver Library 754
SPI Flash Driver Library 782
SPI PIC32WK IPF Flash Driver Library 851
SQI Driver Library 889
SQI Flash Driver Library 923
Index
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1442
Timer Driver Library 979
USART Driver Library 1315
WM8904 Driver Library 323
Byte Transfer Model 1302
C
c) Data Types and Constants 371
Camera Driver Libraries 72
CAMERA_MODULE_ID enumeration 79
CAN Driver Library 102
Client Access 109, 159, 201, 240, 280, 319, 523, 555, 746
Client Access Operation 647, 717
Client Block Data Operation 648, 718
Client Block Operation Functions 949
Client Core Functions 884, 949
Client Data Transfer Functions 885
Client Functionality 1353
Client Functions 30
Client Interaction 972
Client Operation 686
Client Operations 109, 160, 201, 240, 280, 319
Client Operations - Buffered 556
Client Operations - Non-buffered 561
Client Transfer 523
Client Transfer - Core 747
Codec Driver Libraries 105
Common Interface 1147
Comparator Driver Library 349
Configuring in MPLAB Harmony Configurator 617
Configuring the Library 33, 82, 115, 165, 203, 243, 283, 320, 351, 361,
382, 410, 430, 449, 471, 518, 528, 565, 613, 619, 650, 688, 719, 749,
775, 851, 887, 922, 951, 976, 1018, 1037, 1040, 1059, 1079, 1111,
1185, 1243, 1306, 1354, 1387, 1395, 1439
10-bit ADC Touch Driver Library 1018
ADC Touch Driver Library 1037
AK4384 Driver Library 115
AK4642 Driver Library 165
AK4953 Driver Library 203
AK4954 Driver Library 243
AK7755 Driver Library 283
AR1021 Touch Driver Library 1040
BM64 Bluetooth Driver Library 33
CPLD XC2C64A Driver Library 351
CTR Driver Library 361
Data EEPROM Driver Library 382
Ethernet MAC Driver Library 449, 518
Ethernet PHY Driver Library 471
MRF24WN Wi-Fi Driver Library 1354, 1387, 1395, 1439
MTCH6301 Touch Driver Library 1059
MTCH6303 Touch Driver Library 1079
NVM Driver Library 619, 650
PMP Driver Library 688
SD Card Driver Library 719
SPI Driver Library 749
SPI Flash Driver Library 775
SPI PIC32WK IPF Flash Driver Library 851
SQI Driver Library 887
SQI Flash Driver Library 922
Timer Driver Library 976
USART Driver Library 1306
WM8904 Driver Library 320
Configuring the MHC 35, 118, 167, 205, 245, 285, 322, 1114
BM64 Bluetooth Driver Library 35
Configuring the SPI Driver 409, 429, 1436
Console Commands 1356, 1390, 1398
Core Functionality 974
Counter Modification 973
CPLD XC2C64A Driver Library 350
CPLD_DEVICE_CONFIGURATION enumeration 358
CPLD_GFX_CONFIGURATION enumeration 358
CPLD_SPI_CONFIGURATION enumeration 359
CPLDGetDeviceConfiguration function 352
CPLDGetGraphicsConfiguration function 353
CPLDGetSPIConfiguration function 353
CPLDInitialize function 354
CPLDSetGraphicsConfiguration function 354
CPLDSetSPIFlashConfiguration function 355
CPLDSetWiFiConfiguration function 356
CPLDSetZigBeeConfiguration function 357
CTR Driver Library 360
D
Data EEPROM Driver Library 377
Data Transfer Function 30
DATA_LENGTH enumeration 313
Device Endpoint Operations 1170
Driver Device Mode Client Functions 1156
Driver General Client Functions 1151
Driver Host Mode Client Functions 1152
Driver Host Root Hub Interface 1155
Driver Host USB Root Hub Port Interface 1154
Driver Libraries Help 3
Driver Library Overview 3
Driver Tasks Routine 1305
driver.h 19
driver_common.h 20
DRV_ADC_Deinitialize function 21
DRV_ADC_Initialize function 21
DRV_ADC_SamplesAvailable function 22
DRV_ADC_SamplesRead function 22
DRV_ADC_Start function 23
DRV_ADC_Stop function 23
drv_adc10bit.h 1032
DRV_ADC10BIT_CALIBRATION_DELAY macro 1018
DRV_ADC10BIT_CALIBRATION_INSET macro 1018
DRV_ADC10BIT_CLIENTS_NUMBER macro 1018
drv_adc10bit_config_template.h 1034
DRV_ADC10BIT_INDEX macro 1019
DRV_ADC10BIT_INSTANCES_NUMBER macro 1019
DRV_ADC10BIT_INTERRUPT_MODE macro 1019
DRV_ADC10BIT_MODULE_ID enumeration 1030
DRV_ADC10BIT_SAMPLE_POINTS macro 1020
DRV_ADC10BIT_TOUCH_DIAMETER macro 1020
DRV_ADCx_Close function 24
DRV_ADCx_Open function 24
drv_ak4384.h 154
DRV_AK4384_AUDIO_DATA_FORMAT enumeration 146
Index
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1443
DRV_AK4384_BCLK_BIT_CLK_DIVISOR macro 117
DRV_AK4384_BUFFER_EVENT enumeration 147
DRV_AK4384_BUFFER_EVENT_HANDLER type 147
DRV_AK4384_BUFFER_HANDLE type 148
DRV_AK4384_BUFFER_HANDLE_INVALID macro 152
DRV_AK4384_BufferAddWrite function 138
DRV_AK4384_BufferCombinedQueueSizeGet function 141
DRV_AK4384_BufferEventHandlerSet function 139
DRV_AK4384_BufferProcessedSizeGet function 143
DRV_AK4384_BufferQueueFlush function 142
DRV_AK4384_CHANNEL enumeration 149
DRV_AK4384_ChannelOutputInvertDisable function 127
DRV_AK4384_ChannelOutputInvertEnable function 128
DRV_AK4384_CLIENTS_NUMBER macro 115
DRV_AK4384_Close function 126
DRV_AK4384_COMMAND_EVENT_HANDLER type 149
DRV_AK4384_CommandEventHandlerSet function 144
drv_ak4384_config_template.h 156
DRV_AK4384_CONTROL_CLOCK macro 115
DRV_AK4384_COUNT macro 152
DRV_AK4384_DEEMPHASIS_FILTER enumeration 150
DRV_AK4384_DeEmphasisFilterSet function 128
DRV_AK4384_Deinitialize function 122
DRV_AK4384_INDEX_0 macro 152
DRV_AK4384_INDEX_1 macro 153
DRV_AK4384_INDEX_2 macro 153
DRV_AK4384_INDEX_3 macro 153
DRV_AK4384_INDEX_4 macro 153
DRV_AK4384_INDEX_5 macro 153
DRV_AK4384_INIT structure 150
DRV_AK4384_Initialize function 121
DRV_AK4384_INPUT_REFCLOCK macro 116
DRV_AK4384_INSTANCES_NUMBER macro 116
DRV_AK4384_MCLK_MODE enumeration 151
DRV_AK4384_MCLK_SAMPLE_FREQ_MULTPLIER macro 117
DRV_AK4384_MuteOff function 129
DRV_AK4384_MuteOn function 130
DRV_AK4384_Open function 125
DRV_AK4384_SamplingRateGet function 130
DRV_AK4384_SamplingRateSet function 131
DRV_AK4384_SetAudioCommunicationMode function 125
DRV_AK4384_SlowRollOffFilterDisable function 132
DRV_AK4384_SlowRollOffFilterEnable function 132
DRV_AK4384_Status function 123
DRV_AK4384_Tasks function 124
DRV_AK4384_TIMER_DRIVER_MODULE_INDEX macro 116
DRV_AK4384_TIMER_PERIOD macro 117
DRV_AK4384_VersionGet function 145
DRV_AK4384_VersionStrGet function 146
DRV_AK4384_VolumeGet function 133
DRV_AK4384_VolumeSet function 134
DRV_AK4384_ZERO_DETECT_MODE enumeration 151
DRV_AK4384_ZeroDetectDisable function 134
DRV_AK4384_ZeroDetectEnable function 135
DRV_AK4384_ZeroDetectInvertDisable function 136
DRV_AK4384_ZeroDetectInvertEnable function 136
DRV_AK4384_ZeroDetectModeSet function 137
drv_ak4642.h 196
DRV_AK4642_AUDIO_DATA_FORMAT enumeration 191
DRV_AK4642_BCLK_BIT_CLK_DIVISOR macro 165
DRV_AK4642_BUFFER_EVENT enumeration 192
DRV_AK4642_BUFFER_EVENT_HANDLER type 192
DRV_AK4642_BUFFER_HANDLE type 193
DRV_AK4642_BUFFER_HANDLE_INVALID macro 189
DRV_AK4642_BufferAddRead function 183
DRV_AK4642_BufferAddWrite function 181
DRV_AK4642_BufferAddWriteRead function 184
DRV_AK4642_BufferEventHandlerSet function 185
DRV_AK4642_CHANNEL enumeration 193
DRV_AK4642_CLIENTS_NUMBER macro 166
DRV_AK4642_Close function 174
DRV_AK4642_COMMAND_EVENT_HANDLER type 194
DRV_AK4642_CommandEventHandlerSet function 187
drv_ak4642_config_template.h 198
DRV_AK4642_COUNT macro 190
DRV_AK4642_Deinitialize function 171
DRV_AK4642_INDEX_0 macro 190
DRV_AK4642_INDEX_1 macro 190
DRV_AK4642_INDEX_2 macro 191
DRV_AK4642_INDEX_3 macro 191
DRV_AK4642_INDEX_4 macro 191
DRV_AK4642_INDEX_5 macro 191
DRV_AK4642_INIT structure 195
DRV_AK4642_Initialize function 170
DRV_AK4642_INPUT_REFCLOCK macro 166
DRV_AK4642_INSTANCES_NUMBER macro 166
DRV_AK4642_INT_EXT_MIC enumeration 195
DRV_AK4642_IntExtMicSet function 179
DRV_AK4642_MCLK_SAMPLE_FREQ_MULTPLIER macro 166
DRV_AK4642_MCLK_SOURCE macro 167
DRV_AK4642_MIC enumeration 196
DRV_AK4642_MicSet function 181
DRV_AK4642_MONO_STEREO_MIC enumeration 195
DRV_AK4642_MonoStereoMicSet function 180
DRV_AK4642_MuteOff function 175
DRV_AK4642_MuteOn function 176
DRV_AK4642_Open function 173
DRV_AK4642_SamplingRateGet function 177
DRV_AK4642_SamplingRateSet function 177
DRV_AK4642_SetAudioCommunicationMode function 180
DRV_AK4642_Status function 172
DRV_AK4642_Tasks function 173
DRV_AK4642_VersionGet function 188
DRV_AK4642_VersionStrGet function 189
DRV_AK4642_VolumeGet function 178
DRV_AK4642_VolumeSet function 178
drv_ak4953.h 235
DRV_AK4953_AUDIO_DATA_FORMAT enumeration 228
DRV_AK4953_BCLK_BIT_CLK_DIVISOR macro 203
DRV_AK4953_BUFFER_EVENT enumeration 228
DRV_AK4953_BUFFER_EVENT_HANDLER type 229
DRV_AK4953_BUFFER_HANDLE type 230
DRV_AK4953_BUFFER_HANDLE_INVALID macro 232
DRV_AK4953_BufferAddRead function 225
DRV_AK4953_BufferAddWrite function 220
DRV_AK4953_BufferAddWriteRead function 221
Index
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1444
DRV_AK4953_BufferEventHandlerSet function 214
DRV_AK4953_CHANNEL enumeration 234
DRV_AK4953_CLIENTS_NUMBER macro 203
DRV_AK4953_Close function 211
DRV_AK4953_COMMAND_EVENT_HANDLER type 230
DRV_AK4953_CommandEventHandlerSet function 213
drv_ak4953_config_template.h 237
DRV_AK4953_COUNT macro 232
DRV_AK4953_Deinitialize function 210
DRV_AK4953_DIGITAL_BLOCK_CONTROL enumeration 231
DRV_AK4953_INDEX_0 macro 232
DRV_AK4953_INDEX_1 macro 233
DRV_AK4953_INDEX_2 macro 233
DRV_AK4953_INDEX_3 macro 233
DRV_AK4953_INDEX_4 macro 233
DRV_AK4953_INDEX_5 macro 234
DRV_AK4953_INIT structure 231
DRV_AK4953_Initialize function 209
DRV_AK4953_INPUT_REFCLOCK macro 204
DRV_AK4953_INSTANCES_NUMBER macro 204
DRV_AK4953_INT_EXT_MIC enumeration 234
DRV_AK4953_IntExtMicSet function 226
DRV_AK4953_MCLK_SAMPLE_FREQ_MULTPLIER macro 204
DRV_AK4953_MCLK_SOURCE macro 204
DRV_AK4953_MIC enumeration 235
DRV_AK4953_MicSet function 227
DRV_AK4953_MONO_STEREO_MIC enumeration 234
DRV_AK4953_MonoStereoMicSet function 227
DRV_AK4953_MuteOff function 223
DRV_AK4953_MuteOn function 224
DRV_AK4953_Open function 210
DRV_AK4953_QUEUE_DEPTH_COMBINED macro 205
DRV_AK4953_SamplingRateGet function 217
DRV_AK4953_SamplingRateSet function 215
DRV_AK4953_SetAudioCommunicationMode function 216
DRV_AK4953_Status function 217
DRV_AK4953_Tasks function 212
DRV_AK4953_VersionGet function 218
DRV_AK4953_VersionStrGet function 219
DRV_AK4953_VolumeGet function 219
DRV_AK4953_VolumeSet function 225
drv_ak4954.h 275
DRV_AK4954_AUDIO_DATA_FORMAT enumeration 268
DRV_AK4954_BCLK_BIT_CLK_DIVISOR macro 243
DRV_AK4954_BUFFER_EVENT enumeration 268
DRV_AK4954_BUFFER_EVENT_HANDLER type 269
DRV_AK4954_BUFFER_HANDLE type 270
DRV_AK4954_BUFFER_HANDLE_INVALID macro 273
DRV_AK4954_BufferAddRead function 261
DRV_AK4954_BufferAddWrite function 262
DRV_AK4954_BufferAddWriteRead function 263
DRV_AK4954_BufferEventHandlerSet function 254
DRV_AK4954_CHANNEL enumeration 270
DRV_AK4954_CLIENTS_NUMBER macro 243
DRV_AK4954_Close function 251
DRV_AK4954_COMMAND_EVENT_HANDLER type 270
DRV_AK4954_CommandEventHandlerSet function 253
drv_ak4954_config_template.h 277
DRV_AK4954_COUNT macro 273
DRV_AK4954_Deinitialize function 250
DRV_AK4954_DIGITAL_BLOCK_CONTROL enumeration 271
DRV_AK4954_INDEX_0 macro 274
DRV_AK4954_INDEX_1 macro 274
DRV_AK4954_INDEX_2 macro 274
DRV_AK4954_INDEX_3 macro 274
DRV_AK4954_INDEX_4 macro 275
DRV_AK4954_INDEX_5 macro 275
DRV_AK4954_INIT structure 272
DRV_AK4954_Initialize function 249
DRV_AK4954_INPUT_REFCLOCK macro 244
DRV_AK4954_INSTANCES_NUMBER macro 244
DRV_AK4954_INT_EXT_MIC enumeration 272
DRV_AK4954_IntExtMicSet function 265
DRV_AK4954_MCLK_SAMPLE_FREQ_MULTPLIER macro 244
DRV_AK4954_MCLK_SOURCE macro 244
DRV_AK4954_MIC enumeration 272
DRV_AK4954_MicSet function 265
DRV_AK4954_MONO_STEREO_MIC enumeration 273
DRV_AK4954_MonoStereoMicSet function 266
DRV_AK4954_MuteOff function 266
DRV_AK4954_MuteOn function 267
DRV_AK4954_Open function 250
DRV_AK4954_QUEUE_DEPTH_COMBINED macro 245
DRV_AK4954_SamplingRateGet function 257
DRV_AK4954_SamplingRateSet function 255
DRV_AK4954_SetAudioCommunicationMode function 256
DRV_AK4954_Status function 257
DRV_AK4954_Tasks function 252
DRV_AK4954_VersionGet function 258
DRV_AK4954_VersionStrGet function 259
DRV_AK4954_VolumeGet function 259
DRV_AK4954_VolumeSet function 260
drv_ak7755.h 314
DRV_AK7755_BCLK_BIT_CLK_DIVISOR macro 283
DRV_AK7755_BICK_FS_FORMAT enumeration 307
DRV_AK7755_BUFFER_EVENT enumeration 307
DRV_AK7755_BUFFER_EVENT_HANDLER type 308
DRV_AK7755_BUFFER_HANDLE type 309
DRV_AK7755_BUFFER_HANDLE_INVALID macro 305
DRV_AK7755_BufferAddRead function 300
DRV_AK7755_BufferAddWrite function 301
DRV_AK7755_BufferAddWriteRead function 303
DRV_AK7755_BufferEventHandlerSet function 292
DRV_AK7755_CHANNEL enumeration 309
DRV_AK7755_CLIENTS_NUMBER macro 283
DRV_AK7755_Close function 288
DRV_AK7755_COMMAND_EVENT_HANDLER type 310
DRV_AK7755_CommandEventHandlerSet function 294
drv_ak7755_config_template.h 315
DRV_AK7755_COUNT macro 306
DRV_AK7755_DAC_INPUT_FORMAT enumeration 310
DRV_AK7755_Deinitialize function 289
DRV_AK7755_DSP_DIN1_INPUT_FORMAT enumeration 311
DRV_AK7755_DSP_DOUT1_OUTPUT_FORMAT enumeration 311
DRV_AK7755_DSP_DOUT4_OUTPUT_FORMAT enumeration 311
DRV_AK7755_DSP_PROGRAM enumeration 312
Index
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1445
DRV_AK7755_INDEX_0 macro 306
DRV_AK7755_INDEX_1 macro 306
DRV_AK7755_INDEX_2 macro 306
DRV_AK7755_INDEX_3 macro 307
DRV_AK7755_INDEX_4 macro 307
DRV_AK7755_INDEX_5 macro 307
DRV_AK7755_INIT structure 312
DRV_AK7755_Initialize function 290
DRV_AK7755_INPUT_REFCLOCK macro 284
DRV_AK7755_INSTANCES_NUMBER macro 284
DRV_AK7755_INT_EXT_MIC enumeration 312
DRV_AK7755_IntExtMicSet function 303
DRV_AK7755_LRCK_IF_FORMAT enumeration 313
DRV_AK7755_MCLK_SAMPLE_FREQ_MULTPLIER macro 284
DRV_AK7755_MCLK_SOURCE macro 285
DRV_AK7755_MONO_STEREO_MIC enumeration 313
DRV_AK7755_MonoStereoMicSet function 303
DRV_AK7755_MuteOff function 304
DRV_AK7755_MuteOn function 304
DRV_AK7755_Open function 291
DRV_AK7755_SamplingRateGet function 296
DRV_AK7755_SamplingRateSet function 295
DRV_AK7755_SetAudioCommunicationMode function 296
DRV_AK7755_Status function 297
DRV_AK7755_Tasks function 292
DRV_AK7755_VersionGet function 297
DRV_AK7755_VersionStrGet function 298
DRV_AK7755_VolumeGet function 299
DRV_AK7755_VolumeSet function 299
drv_ar1021.h 1055
DRV_AR1021_CALIBRATION_DELAY macro 1040
DRV_AR1021_CALIBRATION_INSET macro 1041
DRV_AR1021_CLIENTS_NUMBER macro 1041
DRV_AR1021_INDEX macro 1041
DRV_AR1021_INSTANCES_NUMBER macro 1042
DRV_AR1021_INTERRUPT_MODE macro 1042
DRV_AR1021_SAMPLE_POINTS macro 1042
DRV_AR1021_TOUCH_DIAMETER macro 1042
drv_bm64.h 70
DRV_BM64_BLE_EnableAdvertising function 65
DRV_BM64_BLE_QueryStatus function 64
DRV_BM64_BLE_STATUS enumeration 70
DRV_BM64_BUFFER_EVENT macro 66
DRV_BM64_BUFFER_EVENT_COMPLETE macro 66
DRV_BM64_BUFFER_EVENT_HANDLER type 67
DRV_BM64_BUFFER_HANDLE macro 66
DRV_BM64_BUFFER_HANDLE_INVALID macro 66
DRV_BM64_BufferAddRead function 44
DRV_BM64_BufferEventHandlerSet function 41
DRV_BM64_CancelForwardOrRewind function 52
DRV_BM64_ClearBLEData function 61
DRV_BM64_Close function 42
drv_bm64_config_template.h 72
DRV_BM64_DATA32 macro 66
DRV_BM64_DisconnectAllLinks function 49
DRV_BM64_DRVR_STATUS enumeration 67
DRV_BM64_EnterBTPairingMode function 50
DRV_BM64_EVENT enumeration 67
DRV_BM64_EVENT_HANDLER type 68
DRV_BM64_EventHandlerSet function 43
DRV_BM64_FastForward function 53
DRV_BM64_ForgetAllLinks function 50
DRV_BM64_GetBDAddress function 59
DRV_BM64_GetBDName function 60
DRV_BM64_GetLinkStatus function 51
DRV_BM64_GetPlayingStatus function 54
DRV_BM64_GetPowerStatus function 38
DRV_BM64_Initialize function 39
DRV_BM64_LinkLastDevice function 52
DRV_BM64_LINKSTATUS enumeration 68
DRV_BM64_MAXBDNAMESIZE macro 67
DRV_BM64_Open function 43
DRV_BM64_Pause function 55
DRV_BM64_Play function 55
DRV_BM64_PLAYINGSTATUS enumeration 69
DRV_BM64_PlayNextSong function 56
DRV_BM64_PlayPause function 57
DRV_BM64_PlayPreviousSong function 57
DRV_BM64_PROTOCOL enumeration 69
DRV_BM64_ReadByteFromBLE function 62
DRV_BM64_ReadDataFromBLE function 62
DRV_BM64_REQUEST enumeration 69
DRV_BM64_Rewind function 58
DRV_BM64_SAMPLE_FREQUENCY enumeration 70
DRV_BM64_SamplingRateGet function 46
DRV_BM64_SamplingRateSet function 46
DRV_BM64_SendByteOverBLE function 63
DRV_BM64_SendDataOverBLE function 64
DRV_BM64_SetBDName function 61
DRV_BM64_Status function 39
DRV_BM64_Stop function 59
DRV_BM64_TaskReq function 40
DRV_BM64_Tasks function 40
DRV_BM64_volumeDown function 47
DRV_BM64_VolumeGet function 48
DRV_BM64_VolumeSet function 48
DRV_BM64_volumeUp function 48
drv_camera.h 79
DRV_CAMERA_Close function 73
DRV_CAMERA_Deinitialize function 73
DRV_CAMERA_INDEX_0 macro 78
DRV_CAMERA_INDEX_1 macro 78
DRV_CAMERA_INDEX_COUNT macro 78
DRV_CAMERA_INIT structure 77
DRV_CAMERA_Initialize function 74
DRV_CAMERA_INTERRUPT_PORT_REMAP structure 77
DRV_CAMERA_Open function 75
drv_camera_ovm7690.h 101
DRV_CAMERA_OVM7690_CLIENT_OBJ structure 95
DRV_CAMERA_OVM7690_CLIENT_STATUS enumeration 96
DRV_CAMERA_OVM7690_Close function 88
DRV_CAMERA_OVM7690_Deinitialize function 85
DRV_CAMERA_OVM7690_ERROR enumeration 96
DRV_CAMERA_OVM7690_FrameBufferAddressSet function 89
DRV_CAMERA_OVM7690_FrameRectSet function 89
DRV_CAMERA_OVM7690_HsyncEventHandler function 92
Index
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1446
DRV_CAMERA_OVM7690_INDEX_0 macro 99
DRV_CAMERA_OVM7690_INDEX_1 macro 100
DRV_CAMERA_OVM7690_INIT structure 97
DRV_CAMERA_OVM7690_Initialize function 84
DRV_CAMERA_OVM7690_OBJ structure 97
DRV_CAMERA_OVM7690_Open function 87
DRV_CAMERA_OVM7690_RECT structure 98
DRV_CAMERA_OVM7690_REG12_OP_FORMAT enumeration 99
DRV_CAMERA_OVM7690_REG12_SOFT_RESET macro 100
DRV_CAMERA_OVM7690_RegisterSet function 86
DRV_CAMERA_OVM7690_SCCB_READ_ID macro 100
DRV_CAMERA_OVM7690_SCCB_WRITE_ID macro 100
DRV_CAMERA_OVM7690_Start function 91
DRV_CAMERA_OVM7690_Stop function 92
DRV_CAMERA_OVM7690_Tasks function 87
DRV_CAMERA_OVM7690_VsyncEventHandler function 93
DRV_CAMERA_Reinitialize function 76
DRV_CAMERA_Status function 76
DRV_CAMERA_Tasks function 77
DRV_CAN_ChannelMessageReceive function 103
DRV_CAN_ChannelMessageTransmit function 103
DRV_CAN_Close function 104
DRV_CAN_Deinitialize function 104
DRV_CAN_Initialize function 105
DRV_CAN_Open function 105
DRV_CLIENT_STATUS enumeration 15
DRV_CMP_Initialize function 350
DRV_CODEC_WM8904_MODE macro 320
DRV_CONFIG_NOT_SUPPORTED macro 17
drv_ctr.h 376
DRV_CTR_Adjust function 366
DRV_CTR_CALLBACK type 372
DRV_CTR_CLIENT_STATUS enumeration 372
DRV_CTR_ClientStatus function 366
DRV_CTR_Close function 367
DRV_CTR_COUNTER structure 373
DRV_CTR_COUNTER_NUM macro 375
DRV_CTR_Deinitialize function 362
DRV_CTR_Drift function 368
DRV_CTR_EventISR function 368
DRV_CTR_INDEX_0 macro 375
DRV_CTR_INIT structure 373
DRV_CTR_Initialize function 363
DRV_CTR_LATCH structure 374
DRV_CTR_LATCH_FIFO_CNT macro 376
DRV_CTR_LATCH_NUM macro 376
DRV_CTR_Open function 369
DRV_CTR_RegisterCallBack function 370
DRV_CTR_Status function 365
DRV_CTR_TRIGGER structure 374
DRV_CTR_TriggerISR function 371
DRV_DYNAMIC_BUILD macro 528
drv_eeprom.h 406
DRV_EEPROM_AddressGet function 397
DRV_EEPROM_BUFFER_OBJECT_NUMBER macro 383
DRV_EEPROM_BulkErase function 391
DRV_EEPROM_CLIENTS_NUMBER macro 383
DRV_EEPROM_Close function 389
DRV_EEPROM_COMMAND_HANDLE type 403
DRV_EEPROM_COMMAND_HANDLE_INVALID macro 402
DRV_EEPROM_COMMAND_STATUS enumeration 403
DRV_EEPROM_CommandStatus function 397
drv_eeprom_config_template.h 407
DRV_EEPROM_Deinitialize function 387
DRV_EEPROM_Erase function 392
DRV_EEPROM_EVENT enumeration 404
DRV_EEPROM_EVENT_HANDLER type 404
DRV_EEPROM_EventHandlerSet function 398
DRV_EEPROM_GeometryGet function 400
DRV_EEPROM_INDEX_0 macro 402
DRV_EEPROM_INIT structure 405
DRV_EEPROM_Initialize function 386
DRV_EEPROM_INSTANCES_NUMBER macro 383
DRV_EEPROM_IsAttached function 401
DRV_EEPROM_IsWriteProtected function 401
DRV_EEPROM_MEDIA_SIZE macro 384
DRV_EEPROM_Open function 390
DRV_EEPROM_Read function 394
DRV_EEPROM_Status function 388
DRV_EEPROM_SYS_FS_REGISTER macro 384
DRV_EEPROM_Tasks function 388
DRV_EEPROM_Write function 395
drv_enc28j60.h 426
DRV_ENC28J60_CLIENT_INSTANCES macro 410
DRV_ENC28J60_Close function 416
drv_enc28j60_config_template.h 427
DRV_ENC28J60_ConfigGet function 417
DRV_ENC28J60_Configuration structure 424
DRV_ENC28J60_Deinitialize function 413
DRV_ENC28J60_EventAcknowledge function 422
DRV_ENC28J60_EventMaskSet function 423
DRV_ENC28J60_EventPendingGet function 423
DRV_ENC28J60_Initialize function 414
DRV_ENC28J60_INSTANCES_NUMBER macro 410
DRV_ENC28J60_LinkCheck function 417
DRV_ENC28J60_MACObject variable 425
DRV_ENC28J60_MDIX_TYPE enumeration 425
DRV_ENC28J60_Open function 418
DRV_ENC28J60_PacketRx function 421
DRV_ENC28J60_PacketTx function 422
DRV_ENC28J60_ParametersGet function 418
DRV_ENC28J60_PowerMode function 419
DRV_ENC28J60_Process function 414
DRV_ENC28J60_RegisterStatisticsGet function 419
DRV_ENC28J60_Reinitialize function 415
DRV_ENC28J60_RxFilterHashTableEntrySet function 421
DRV_ENC28J60_SetMacCtrlInfo function 415
DRV_ENC28J60_StackInitialize function 415
DRV_ENC28J60_StatisticsGet function 420
DRV_ENC28J60_Status function 420
DRV_ENC28J60_Tasks function 416
drv_encx24j600.h 445
DRV_ENCX24J600_Close function 436
DRV_ENCX24J600_ConfigGet function 436
DRV_ENCX24J600_Configuration structure 444
DRV_ENCX24J600_Deinitialize function 433
Index
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1447
DRV_ENCX24J600_EventAcknowledge function 442
DRV_ENCX24J600_EventMaskSet function 443
DRV_ENCX24J600_EventPendingGet function 443
DRV_ENCX24J600_Initialize function 433
DRV_ENCX24J600_LinkCheck function 437
DRV_ENCX24J600_MDIX_TYPE enumeration 445
DRV_ENCX24J600_Open function 437
DRV_ENCX24J600_PacketRx function 440
DRV_ENCX24J600_PacketTx function 442
DRV_ENCX24J600_ParametersGet function 438
DRV_ENCX24J600_PowerMode function 438
DRV_ENCX24J600_Process function 435
DRV_ENCX24J600_RegisterStatisticsGet function 439
DRV_ENCX24J600_Reinitialize function 434
DRV_ENCX24J600_RxFilterHashTableEntrySet function 441
DRV_ENCX24J600_SetMacCtrlInfo function 435
DRV_ENCX24J600_StackInitialize function 435
DRV_ENCX24J600_StatisticsGet function 439
DRV_ENCX24J600_Status function 440
DRV_ENCX24J600_Tasks function 434
drv_ethmac.h 467
DRV_ETHMAC_CLIENTS_NUMBER macro 450
drv_ethmac_config.h 468
DRV_ETHMAC_INDEX macro 450
DRV_ETHMAC_INDEX_0 macro 466
DRV_ETHMAC_INDEX_1 macro 466
DRV_ETHMAC_INDEX_COUNT macro 467
DRV_ETHMAC_INSTANCES_NUMBER macro 450
DRV_ETHMAC_INTERRUPT_MODE macro 451
DRV_ETHMAC_INTERRUPT_SOURCE macro 451
DRV_ETHMAC_PERIPHERAL_ID macro 451
DRV_ETHMAC_PIC32MACClose function 454
DRV_ETHMAC_PIC32MACConfigGet function 459
DRV_ETHMAC_PIC32MACDeinitialize function 454
DRV_ETHMAC_PIC32MACEventAcknowledge function 463
DRV_ETHMAC_PIC32MACEventMaskSet function 464
DRV_ETHMAC_PIC32MACEventPendingGet function 464
DRV_ETHMAC_PIC32MACInitialize function 455
DRV_ETHMAC_PIC32MACLinkCheck function 455
DRV_ETHMAC_PIC32MACOpen function 456
DRV_ETHMAC_PIC32MACPacketRx function 461
DRV_ETHMAC_PIC32MACPacketTx function 462
DRV_ETHMAC_PIC32MACParametersGet function 456
DRV_ETHMAC_PIC32MACPowerMode function 457
DRV_ETHMAC_PIC32MACProcess function 457
DRV_ETHMAC_PIC32MACRegisterStatisticsGet function 460
DRV_ETHMAC_PIC32MACReinitialize function 460
DRV_ETHMAC_PIC32MACRxFilterHashTableEntrySet function 461
DRV_ETHMAC_PIC32MACStatisticsGet function 458
DRV_ETHMAC_PIC32MACStatus function 458
DRV_ETHMAC_PIC32MACTasks function 466
DRV_ETHMAC_POWER_STATE macro 452
DRV_ETHMAC_Tasks_ISR function 465
drv_ethphy.h 505
DRV_ETHPHY_CLIENT_STATUS enumeration 495
DRV_ETHPHY_ClientOperationAbort function 483
DRV_ETHPHY_ClientOperationResult function 484
DRV_ETHPHY_CLIENTS_NUMBER macro 471
DRV_ETHPHY_ClientStatus function 481
DRV_ETHPHY_Close function 482
drv_ethphy_config.h 507
DRV_ETHPHY_CONFIG_FLAGS enumeration 500
DRV_ETHPHY_Deinitialize function 477
DRV_ETHPHY_HWConfigFlagsGet function 480
DRV_ETHPHY_INDEX macro 472
DRV_ETHPHY_INDEX_0 macro 499
DRV_ETHPHY_INDEX_1 macro 499
DRV_ETHPHY_INDEX_COUNT macro 499
DRV_ETHPHY_INIT structure 496
DRV_ETHPHY_Initialize function 476
DRV_ETHPHY_INSTANCES_NUMBER macro 472
DRV_ETHPHY_INTERFACE_INDEX enumeration 504
DRV_ETHPHY_INTERFACE_TYPE enumeration 505
DRV_ETHPHY_LINK_STATUS enumeration 500
DRV_ETHPHY_LinkStatusGet function 492
DRV_ETHPHY_NEG_DONE_TMO macro 472
DRV_ETHPHY_NEG_INIT_TMO macro 473
DRV_ETHPHY_NEGOTIATION_RESULT structure 496
DRV_ETHPHY_NegotiationIsComplete function 493
DRV_ETHPHY_NegotiationResultGet function 493
DRV_ETHPHY_OBJECT structure 501
DRV_ETHPHY_OBJECT_BASE structure 502
DRV_ETHPHY_OBJECT_BASE_TYPE structure 502
DRV_ETHPHY_Open function 482
DRV_ETHPHY_PERIPHERAL_ID macro 472
DRV_ETHPHY_PhyAddressGet function 494
DRV_ETHPHY_Reinitialize function 478
DRV_ETHPHY_Reset function 483
DRV_ETHPHY_RESET_CLR_TMO macro 473
DRV_ETHPHY_RESET_FUNCTION type 503
DRV_ETHPHY_RestartNegotiation function 495
DRV_ETHPHY_RESULT enumeration 503
DRV_ETHPHY_Setup function 480
DRV_ETHPHY_SETUP structure 497
DRV_ETHPHY_SMIClockSet function 486
DRV_ETHPHY_SMIRead function 487
DRV_ETHPHY_SMIScanDataGet function 487
DRV_ETHPHY_SMIScanStart function 486
DRV_ETHPHY_SMIScanStatusGet function 484
DRV_ETHPHY_SMIScanStop function 485
DRV_ETHPHY_SMIStatus function 488
DRV_ETHPHY_SMIWrite function 488
DRV_ETHPHY_Status function 478
DRV_ETHPHY_Tasks function 479
DRV_ETHPHY_USE_DRV_MIIM macro 504
DRV_ETHPHY_VENDOR_MDIX_CONFIGURE type 497
DRV_ETHPHY_VENDOR_MII_CONFIGURE type 498
DRV_ETHPHY_VENDOR_SMI_CLOCK_GET type 498
DRV_ETHPHY_VENDOR_WOL_CONFIGURE type 501
DRV_ETHPHY_VendorDataGet function 489
DRV_ETHPHY_VendorDataSet function 490
DRV_ETHPHY_VendorSMIReadResultGet function 490
DRV_ETHPHY_VendorSMIReadStart function 491
DRV_ETHPHY_VendorSMIWriteStart function 491
drv_flash.h 514
DRV_FLASH_ErasePage function 509
Index
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1448
DRV_FLASH_GetPageSize function 509
DRV_FLASH_GetRowSize function 510
DRV_FLASH_INDEX_0 macro 513
DRV_FLASH_Initialize function 510
DRV_FLASH_IsBusy function 511
DRV_FLASH_Open function 511
DRV_FLASH_PAGE_SIZE macro 514
DRV_FLASH_ROW_SIZE macro 514
DRV_FLASH_WriteQuadWord function 511
DRV_FLASH_WriteRow function 512
DRV_FLASH_WriteWord function 513
drv_gmac.h 520
DRV_HANDLE type 15
DRV_HANDLE_INVALID macro 17
drv_i2c.h 550
drv_i2c_bb.h 551
DRV_I2C_BB_H macro 550
DRV_I2C_BUFFER_QUEUE_SUPPORT macro 548
DRV_I2C_BufferEventHandlerSet function 539
DRV_I2C_BytesTransferred function 540
DRV_I2C_Close function 537
DRV_I2C_CONFIG_BUILD_TYPE macro 529
DRV_I2C_CONFIG_SUPPORT_OPERATION_MODE_BASIC macro
529
DRV_I2C_CONFIG_SUPPORT_OPERATION_MODE_BLOCKING
macro 529
DRV_I2C_CONFIG_SUPPORT_OPERATION_MODE_EXCLUSIVE
macro 530
DRV_I2C_CONFIG_SUPPORT_OPERATION_MODE_MASTER macro
530
DRV_I2C_CONFIG_SUPPORT_OPERATION_MODE_NON_BLOCKING
macro 530
DRV_I2C_CONFIG_SUPPORT_OPERATION_MODE_READ macro 531
DRV_I2C_CONFIG_SUPPORT_OPERATION_MODE_SLAVE macro
531
DRV_I2C_CONFIG_SUPPORT_OPERATION_MODE_WRITE macro
531
DRV_I2C_CONFIG_SUPPORT_OPERATION_MODE_WRITE_READ
macro 532
drv_i2c_config_template.h 551
DRV_I2C_Deinitialize function 535
DRV_I2C_FORCED_WRITE macro 532
DRV_I2C_INDEX macro 313
DRV_I2C_Initialize function 535
DRV_I2C_INSTANCES_NUMBER macro 549
DRV_I2C_INTERRUPT_MODE macro 549
DRV_I2C_Open function 538
DRV_I2C_QUEUE_DEPTH_COMBINED macro 549
DRV_I2C_QueueFlush function 546
DRV_I2C_Receive function 541
DRV_I2C_SlaveCallbackSet function 547
DRV_I2C_Status function 546
DRV_I2C_Tasks function 537
DRV_I2C_TransferStatusGet function 545
DRV_I2C_Transmit function 542
DRV_I2C_TransmitForced function 544
DRV_I2C_TransmitThenReceive function 543
drv_i2s.h 605
DRV_I2S_AUDIO_PROTOCOL_MODE enumeration 596
DRV_I2S_BaudSet function 590
DRV_I2S_BUFFER_EVENT enumeration 596
DRV_I2S_BUFFER_EVENT_HANDLER type 597
DRV_I2S_BUFFER_HANDLE type 598
DRV_I2S_BUFFER_HANDLE_INVALID macro 601
DRV_I2S_BufferAddRead function 578
DRV_I2S_BufferAddWrite function 579
DRV_I2S_BufferAddWriteRead function 581
DRV_I2S_BufferCombinedQueueSizeGet function 584
DRV_I2S_BufferEventHandlerSet function 583
DRV_I2S_BufferProcessedSizeGet function 588
DRV_I2S_BufferQueueFlush function 585
DRV_I2S_CLIENTS_NUMBER macro 569
DRV_I2S_CLOCK_MODE enumeration 598
DRV_I2S_Close function 576
drv_i2s_config_template.h 607
DRV_I2S_COUNT macro 601
DRV_I2S_DATA16 structure 599
DRV_I2S_DATA24 structure 599
DRV_I2S_DATA32 structure 599
DRV_I2S_Deinitialize function 572
DRV_I2S_ERROR enumeration 600
DRV_I2S_ErrorGet function 591
DRV_I2S_INDEX macro 566
DRV_I2S_INDEX_0 macro 602
DRV_I2S_INDEX_1 macro 602
DRV_I2S_INDEX_2 macro 603
DRV_I2S_INDEX_3 macro 603
DRV_I2S_INDEX_4 macro 603
DRV_I2S_INDEX_5 macro 603
DRV_I2S_Initialize function 573
DRV_I2S_INSTANCES_NUMBER macro 566
DRV_I2S_INTERFACE structure 603
DRV_I2S_INTERRUPT_MODE macro 566
DRV_I2S_INTERRUPT_SOURCE_ERROR macro 566
DRV_I2S_INTERRUPT_SOURCE_RECEIVE macro 567
DRV_I2S_INTERRUPT_SOURCE_TRANSMIT macro 567
DRV_I2S_MODE enumeration 600
DRV_I2S_Open function 577
DRV_I2S_PERIPHERAL_ID macro 567
DRV_I2S_QUEUE_DEPTH_COMBINED macro 569
DRV_I2S_Read function 586
DRV_I2S_READ_ERROR macro 601
DRV_I2S_RECEIVE_DMA_CHAINING_CHANNEL macro 569
DRV_I2S_RECEIVE_DMA_CHANNEL macro 568
DRV_I2S_ReceiveErrorIgnore function 593
DRV_I2S_Status function 574
DRV_I2S_STOP_IN_IDLE macro 568
DRV_I2S_Tasks function 575
DRV_I2S_TasksError function 575
DRV_I2S_TRANSMIT_DMA_CHANNEL macro 568
DRV_I2S_TransmitErrorIgnore function 594
DRV_I2S_Write function 587
DRV_I2S_WRITE_ERROR macro 602
DRV_IC_BufferIsEmpty function 608
DRV_IC_Capture16BitDataRead function 609
DRV_IC_Capture32BitDataRead function 609
DRV_IC_Initialize function 608
Index
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1449
DRV_IC_Start function 610
DRV_IC_Stop function 610
drv_input_mxt336t.h 617
DRV_IO_BUFFER_TYPES enumeration 16
DRV_IO_INTENT enumeration 16
DRV_IO_ISBLOCKING macro 18
DRV_IO_ISEXCLUSIVE macro 18
DRV_IO_ISNONBLOCKING macro 18
drv_ipf.h 880
DRV_IPF_BLOCK_COMMAND_HANDLE type 873
DRV_IPF_BLOCK_COMMAND_HANDLE_INVALID macro 878
DRV_IPF_BLOCK_EVENT enumeration 874
DRV_IPF_BLOCK_OPERATION enumeration 874
DRV_IPF_BlockErase function 859
DRV_IPF_BlockEventHandlerSet function 861
DRV_IPF_BlockRead function 862
DRV_IPF_BlockWrite function 864
DRV_IPF_CLIENT_STATUS enumeration 875
DRV_IPF_CLIENTS_NUMBER macro 879
DRV_IPF_ClientStatus function 857
DRV_IPF_Close function 857
DRV_IPF_COMMAND_STATUS enumeration 875
drv_ipf_config_template.h 881
DRV_IPF_Deinitialize function 853
DRV_IPF_EVENT_HANDLER type 876
DRV_IPF_GeometryGet function 866
DRV_IPF_HoldAssert function 866
DRV_IPF_HoldDeAssert function 867
DRV_IPF_INDEX_0 macro 878
DRV_IPF_INIT structure 877
DRV_IPF_Initialize function 854
DRV_IPF_INSTANCES_NUMBER macro 879
DRV_IPF_MediaIsAttached function 867
DRV_IPF_MODE macro 879
DRV_IPF_Open function 858
DRV_IPF_PROT_MODE enumeration 877
DRV_IPF_ProtectMemoryVolatile function 868
DRV_IPF_ReadBlockProtectionStatus function 869
DRV_IPF_Status function 855
DRV_IPF_Tasks function 856
DRV_IPF_UnProtectMemoryVolatile function 871
DRV_IPF_WPAssert function 872
DRV_IPF_WPDeAssert function 873
drv_mcpwm.h 640
DRV_MCPWM_Disable function 638
DRV_MCPWM_Enable function 639
DRV_MCPWM_Initialize function 639
drv_miim.h 636
DRV_MIIM_CALLBACK_HANDLE type 633
DRV_MIIM_CLIENT_OP_PROTECTION macro 620
DRV_MIIM_CLIENT_STATUS enumeration 633
DRV_MIIM_ClientStatus function 623
DRV_MIIM_Close function 623
DRV_MIIM_COMMANDS macro 620
drv_miim_config.h 637
DRV_MIIM_Deinitialize function 624
DRV_MIIM_DeregisterCallback function 624
DRV_MIIM_INDEX_0 macro 619
DRV_MIIM_INDEX_COUNT macro 619
DRV_MIIM_INIT structure 632
DRV_MIIM_Initialize function 625
DRV_MIIM_INSTANCE_CLIENTS macro 620
DRV_MIIM_INSTANCE_OPERATIONS macro 621
DRV_MIIM_INSTANCES_NUMBER macro 621
DRV_MIIM_OBJECT_BASE structure 632
DRV_MIIM_OBJECT_BASE_Default variable 636
DRV_MIIM_Open function 625
DRV_MIIM_OPERATION_CALLBACK type 634
DRV_MIIM_OPERATION_FLAGS enumeration 634
DRV_MIIM_OPERATION_HANDLE type 634
DRV_MIIM_OperationAbort function 626
DRV_MIIM_OperationResult function 626
DRV_MIIM_Read function 627
DRV_MIIM_RegisterCallback function 627
DRV_MIIM_Reinitialize function 628
DRV_MIIM_Scan function 628
DRV_MIIM_Setup function 629
DRV_MIIM_SETUP structure 635
DRV_MIIM_SETUP_FLAGS enumeration 635
DRV_MIIM_Status function 630
DRV_MIIM_Tasks function 631
DRV_MIIM_Write function 631
DRV_MODE enumeration 375
drv_mtch6301.h 1076
DRV_MTCH6301_CALIBRATION_DELAY macro 1059
DRV_MTCH6301_CALIBRATION_INSET macro 1060
DRV_MTCH6301_CLIENTS_NUMBER macro 1060
drv_mtch6301_config_template.h 1077
DRV_MTCH6301_INDEX macro 1060
DRV_MTCH6301_INSTANCES_NUMBER macro 1061
DRV_MTCH6301_INTERRUPT_MODE macro 1061
DRV_MTCH6301_SAMPLE_POINTS macro 1061
DRV_MTCH6301_TOUCH_DIAMETER macro 1061
drv_mtch6303.h 1106
DRV_MTCH6303_AddRegisterRead function 1085
DRV_MTCH6303_AddRegisterWrite function 1086
DRV_MTCH6303_BUFFER_EVENT enumeration 1099
DRV_MTCH6303_BUFFER_EVENT_HANDLER type 1099
DRV_MTCH6303_BUFFER_HANDLE type 1100
DRV_MTCH6303_BUFFER_HANDLE_INVALID macro 1098
DRV_MTCH6303_BufferEventHandlerSet function 1096
DRV_MTCH6303_CLIENT_STATUS enumeration 1100
DRV_MTCH6303_Close function 1083
DRV_MTCH6303_Deinitialize function 1081
DRV_MTCH6303_ERROR enumeration 1101
DRV_MTCH6303_ErrorGet function 1084
DRV_MTCH6303_Initialize function 1082
DRV_MTCH6303_Open function 1084
DRV_MTCH6303_Status function 1082
DRV_MTCH6303_Tasks function 1083
DRV_MTCH6303_TOUCH_AddMessageCommandWrite function 1088
DRV_MTCH6303_TOUCH_AddMessageReportRead function 1089
DRV_MTCH6303_TOUCH_AddTouchInputRead function 1091
DRV_MTCH6303_TOUCH_BUFFER_EVENT enumeration 1101
DRV_MTCH6303_TOUCH_BUFFER_EVENT_HANDLER type 1101
DRV_MTCH6303_TOUCH_BUFFER_HANDLE type 1102
Index
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1450
DRV_MTCH6303_TOUCH_BUFFER_HANDLE_INVALID macro 1098
DRV_MTCH6303_TOUCH_BufferEventHandlerSet function 1092
DRV_MTCH6303_TOUCH_DATA structure 1102
DRV_MTCH6303_TOUCH_INPUT structure 1103
DRV_MTCH6303_TOUCH_MESSAGE structure 1103
DRV_MTCH6303_TOUCH_MESSAGE_HEADER structure 1104
DRV_MTCH6303_TOUCH_NIBBLE_0 structure 1104
DRV_MTCH6303_TOUCH_NUM_INPUTS macro 1098
DRV_MTCH6303_TOUCH_STATUS structure 1105
DRV_MTCH6303_TOUCH_Tasks function 1094
DRV_MTCH6303_TouchInputMap function 1094
DRV_MTCH6303_TouchInputRead function 1095
drv_mxt.h 1145
DRV_MXT_CLIENT_OBJECT structure 1132
DRV_MXT_Close function 1124
DRV_MXT_Deinitialize function 1125
DRV_MXT_HANDLE type 1132
DRV_MXT_HANDLE_INVALID macro 1139
DRV_MXT_I2C_MASTER_READ_ID macro 1139
DRV_MXT_I2C_MASTER_WRITE_ID macro 1140
DRV_MXT_I2C_READ_FRAME_SIZE macro 1140
DRV_MXT_INDEX_0 macro 1140
DRV_MXT_INDEX_1 macro 1140
DRV_MXT_INDEX_COUNT macro 1141
DRV_MXT_INIT structure 1132
DRV_MXT_Initialize function 1127
DRV_MXT_MaxtouchEventCallback function 1125
DRV_MXT_MODULE_ID enumeration 1133
DRV_MXT_OBJECT structure 1133
DRV_MXT_Open function 1126
DRV_MXT_ReadRequest function 1128
DRV_MXT_Status function 1130
DRV_MXT_TASK_QUEUE structure 1134
DRV_MXT_TASK_STATE enumeration 1135
DRV_MXT_Tasks function 1131
DRV_MXT_TouchDataRead function 1127
DRV_MXT_TouchGetX function 1129
DRV_MXT_TouchGetY function 1129
DRV_MXT_TouchStatus function 1131
drv_mxt336t.h 1146
DRV_MXT336T_CALIBRATION_DELAY macro 1111
DRV_MXT336T_CALIBRATION_INSET macro 1112
DRV_MXT336T_CLIENT_CALLBACK type 1135
DRV_MXT336T_CLIENTS_NUMBER macro 1112
DRV_MXT336T_Close function 1117
DRV_MXT336T_CloseObject function 1119
DRV_MXT336T_Deinitialize function 1121
DRV_MXT336T_DEVICE_ClientObjectEventHandlerSet function 1120
DRV_MXT336T_HANDLE type 1136
DRV_MXT336T_HANDLE_INVALID macro 1141
DRV_MXT336T_I2C_FRAME_SIZE macro 1141
DRV_MXT336T_I2C_MASTER_READ_ID macro 1142
DRV_MXT336T_I2C_MASTER_WRITE_ID macro 1142
DRV_MXT336T_I2C_READ_ID_FRAME_SIZE macro 1142
DRV_MXT336T_INDEX macro 1112
DRV_MXT336T_INDEX_0 macro 1142
DRV_MXT336T_INDEX_1 macro 1143
DRV_MXT336T_INDEX_COUNT macro 1143
DRV_MXT336T_INIT type 1136
DRV_MXT336T_Initialize function 1122
DRV_MXT336T_INSTANCES_NUMBER macro 1113
DRV_MXT336T_INTERRUPT_MODE macro 1113
DRV_MXT336T_OBJECT_CLIENT_EVENT_DATA structure 1136
DRV_MXT336T_OBJECT_TYPE enumeration 1137
DRV_MXT336T_Open function 1118
DRV_MXT336T_OpenObject function 1120
DRV_MXT336T_ReadRequest function 1117
DRV_MXT336T_SAMPLE_POINTS macro 1113
DRV_MXT336T_Status function 1123
DRV_MXT336T_T100_XRANGE macro 1144
DRV_MXT336T_T100_YRANGE macro 1144
DRV_MXT336T_Tasks function 1123
DRV_MXT336T_TOUCH_DIAMETER macro 1113
drv_nvm.h 676
DRV_NVM_AddressGet function 669
DRV_NVM_BUFFER_OBJECT_NUMBER macro 650
DRV_NVM_CLIENTS_NUMBER macro 651
DRV_NVM_Close function 659
DRV_NVM_COMMAND_HANDLE type 675
DRV_NVM_COMMAND_HANDLE_INVALID macro 676
DRV_NVM_COMMAND_STATUS enumeration 675
DRV_NVM_CommandStatus function 669
drv_nvm_config_template.h 678
DRV_NVM_Deinitialize function 657
DRV_NVM_DISABLE_ERROR_CHECK macro 652
DRV_NVM_Erase function 663
DRV_NVM_ERASE_WRITE_ENABLE macro 652
DRV_NVM_EraseWrite function 665
DRV_NVM_EVENT enumeration 673
DRV_NVM_EVENT_HANDLER type 674
DRV_NVM_EventHandlerSet function 666
DRV_NVM_GeometryGet function 670
DRV_NVM_INDEX_0 macro 672
DRV_NVM_INDEX_1 macro 673
DRV_NVM_INIT structure 673
DRV_NVM_Initialize function 655
DRV_NVM_INSTANCES_NUMBER macro 651
DRV_NVM_INTERRUPT_MODE macro 651
DRV_NVM_IsAttached function 671
DRV_NVM_IsWriteProtected function 672
DRV_NVM_MEDIA_SIZE macro 653
DRV_NVM_MEDIA_START_ADDRESS macro 653
DRV_NVM_Open function 658
DRV_NVM_PAGE_SIZE macro 652
DRV_NVM_Read function 660
DRV_NVM_ROW_SIZE macro 651
DRV_NVM_Status function 658
DRV_NVM_SYS_FS_REGISTER macro 653
DRV_NVM_Tasks function 668
DRV_NVM_Write function 661
DRV_OC_Disable function 679
DRV_OC_Enable function 679
DRV_OC_FaultHasOccurred function 680
DRV_OC_Initialize function 680
DRV_OC_Start function 681
DRV_OC_Stop function 681
Index
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1451
drv_ovm7690_config_template.h 102
DRV_OVM7690_INTERRUPT_MODE macro 82
drv_pmp.h 708
DRV_PMP_CHIPX_STROBE_MODE enumeration 702
DRV_PMP_CLIENT_STATUS enumeration 702
DRV_PMP_CLIENTS_NUMBER macro 689
DRV_PMP_ClientStatus function 696
DRV_PMP_Close function 697
drv_pmp_config.h 710
DRV_PMP_Deinitialize function 691
DRV_PMP_ENDIAN_MODE enumeration 703
DRV_PMP_INDEX enumeration 703
DRV_PMP_INDEX_COUNT macro 702
DRV_PMP_INIT structure 703
DRV_PMP_Initialize function 692
DRV_PMP_INSTANCES_NUMBER macro 689
DRV_PMP_MODE_CONFIG structure 704
DRV_PMP_ModeConfig function 698
DRV_PMP_Open function 699
DRV_PMP_POLARITY_OBJECT structure 705
DRV_PMP_PORT_CONTROL enumeration 705
DRV_PMP_PORTS structure 705
DRV_PMP_QUEUE_ELEMENT_OBJ structure 706
DRV_PMP_QUEUE_SIZE macro 689
DRV_PMP_Read function 699
DRV_PMP_Reinitialize function 693
DRV_PMP_Status function 694
DRV_PMP_Tasks function 695
DRV_PMP_TimingSet function 696
DRV_PMP_TRANSFER_STATUS enumeration 706
DRV_PMP_TRANSFER_TYPE enumeration 707
DRV_PMP_TransferStatus function 701
DRV_PMP_WAIT_STATES structure 707
DRV_PMP_Write function 700
DRV_RTCC_AlarmDateGet function 711
DRV_RTCC_AlarmTimeGet function 711
DRV_RTCC_ClockOutput function 712
DRV_RTCC_DateGet function 712
DRV_RTCC_Initialize function 713
DRV_RTCC_Start function 713
DRV_RTCC_Stop function 713
DRV_RTCC_TimeGet function 714
drv_sdcard.h 741
DRV_SDCARD_CLIENTS_NUMBER macro 719
DRV_SDCARD_Close function 727
DRV_SDCARD_COMMAND_HANDLE type 739
DRV_SDCARD_COMMAND_HANDLE_INVALID macro 739
DRV_SDCARD_COMMAND_STATUS enumeration 739
DRV_SDCARD_CommandStatus function 734
drv_sdcard_config_template.h 743
DRV_SDCARD_Deinitialize function 724
DRV_SDCARD_ENABLE_WRITE_PROTECT_CHECK macro 721
DRV_SDCARD_EVENT enumeration 740
DRV_SDCARD_EVENT_HANDLER type 740
DRV_SDCARD_EventHandlerSet function 731
DRV_SDCARD_GeometryGet function 735
DRV_SDCARD_INDEX_0 macro 736
DRV_SDCARD_INDEX_1 macro 738
DRV_SDCARD_INDEX_2 macro 738
DRV_SDCARD_INDEX_3 macro 738
DRV_SDCARD_INDEX_COUNT macro 736
DRV_SDCARD_INDEX_MAX macro 720
DRV_SDCARD_INIT structure 737
DRV_SDCARD_Initialize function 723
DRV_SDCARD_INSTANCES_NUMBER macro 720
DRV_SDCARD_IsAttached function 733
DRV_SDCARD_IsWriteProtected function 734
DRV_SDCARD_Open function 728
DRV_SDCARD_POWER_STATE macro 720
DRV_SDCARD_Read function 729
DRV_SDCARD_Reinitialize function 724
DRV_SDCARD_Status function 725
DRV_SDCARD_SYS_FS_REGISTER macro 721
DRV_SDCARD_Tasks function 726
DRV_SDCARD_Write function 730
drv_spi.h 769
DRV_SPI_16BIT macro 749
DRV_SPI_32BIT macro 749
DRV_SPI_8BIT macro 750
DRV_SPI_BufferAddRead function 762
DRV_SPI_BufferAddRead2 function 765
DRV_SPI_BufferAddWrite function 763
DRV_SPI_BufferAddWrite2 function 766
DRV_SPI_BufferAddWriteRead function 764
DRV_SPI_BufferAddWriteRead2 function 767
DRV_SPI_BufferStatus function 761
DRV_SPI_ClientConfigure function 760
DRV_SPI_CLIENTS_NUMBER macro 753
DRV_SPI_Close function 759
drv_spi_config_template.h 770
DRV_SPI_Deinitialize function 756
DRV_SPI_DMA macro 750
DRV_SPI_DMA_DUMMY_BUFFER_SIZE macro 750
DRV_SPI_DMA_TXFER_SIZE macro 751
DRV_SPI_EBM macro 751
DRV_SPI_ELEMENTS_PER_QUEUE macro 751
DRV_SPI_Initialize function 755
DRV_SPI_INSTANCES_NUMBER macro 753
DRV_SPI_ISR macro 752
DRV_SPI_MASTER macro 752
DRV_SPI_Open function 759
DRV_SPI_POLLED macro 752
DRV_SPI_RM macro 752
DRV_SPI_SLAVE macro 753
DRV_SPI_Status function 757
DRV_SPI_Tasks function 758
DRV_SPIn_ReceiverBufferIsFull function 768
DRV_SPIn_TransmitterBufferIsFull function 768
drv_sqi.h 915
DRV_SQI_BUFFER_OBJECT_NUMBER macro 887
DRV_SQI_CLIENTS_NUMBER macro 887
DRV_SQI_Close function 895
DRV_SQI_COMMAND_HANDLE type 900
DRV_SQI_COMMAND_HANDLE_INVALID macro 904
DRV_SQI_COMMAND_STATUS enumeration 901
DRV_SQI_CommandStatus function 895
Index
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1452
drv_sqi_config_template.h 917
DRV_SQI_Deinitialize function 892
DRV_SQI_DMA_BUFFER_DESCRIPTORS_NUMBER macro 888
DRV_SQI_EVENT enumeration 901
DRV_SQI_EVENT_HANDLER type 902
DRV_SQI_EventHandlerSet function 896
DRV_SQI_FLAG_32_BIT_ADDR_ENABLE macro 905
DRV_SQI_FLAG_32_BIT_ADDR_ENABLE_MASK macro 905
DRV_SQI_FLAG_32_BIT_ADDR_ENABLE_POS macro 905
DRV_SQI_FLAG_ADDR_ENABLE macro 905
DRV_SQI_FLAG_ADDR_ENABLE_MASK macro 906
DRV_SQI_FLAG_ADDR_ENABLE_POS macro 906
DRV_SQI_FLAG_CRM_ENABLE macro 906
DRV_SQI_FLAG_CRM_ENABLE_MASK macro 906
DRV_SQI_FLAG_CRM_ENABLE_POS macro 906
DRV_SQI_FLAG_DATA_DIRECTION_MASK macro 907
DRV_SQI_FLAG_DATA_DIRECTION_POS macro 907
DRV_SQI_FLAG_DATA_DIRECTION_READ macro 907
DRV_SQI_FLAG_DATA_DIRECTION_WRITE macro 907
DRV_SQI_FLAG_DATA_ENABLE macro 907
DRV_SQI_FLAG_DATA_ENABLE_MASK macro 908
DRV_SQI_FLAG_DATA_ENABLE_POS macro 908
DRV_SQI_FLAG_DATA_TARGET_MASK macro 908
DRV_SQI_FLAG_DATA_TARGET_MEMORY macro 908
DRV_SQI_FLAG_DATA_TARGET_POS macro 908
DRV_SQI_FLAG_DATA_TARGET_REGISTER macro 909
DRV_SQI_FLAG_DDR_ENABLE macro 909
DRV_SQI_FLAG_DDR_ENABLE_MASK macro 909
DRV_SQI_FLAG_DDR_ENABLE_POS macro 909
DRV_SQI_FLAG_INSTR_ENABLE macro 909
DRV_SQI_FLAG_INSTR_ENABLE_MASK macro 910
DRV_SQI_FLAG_INSTR_ENABLE_POS macro 910
DRV_SQI_FLAG_OPT_ENABLE macro 910
DRV_SQI_FLAG_OPT_ENABLE_MASK macro 910
DRV_SQI_FLAG_OPT_ENABLE_POS macro 910
DRV_SQI_FLAG_OPT_LENGTH macro 911
DRV_SQI_FLAG_OPT_LENGTH_1BIT macro 911
DRV_SQI_FLAG_OPT_LENGTH_2BIT macro 911
DRV_SQI_FLAG_OPT_LENGTH_4BIT macro 911
DRV_SQI_FLAG_OPT_LENGTH_8BIT macro 911
DRV_SQI_FLAG_OPT_LENGTH_MASK macro 912
DRV_SQI_FLAG_OPT_LENGTH_POS macro 912
DRV_SQI_FLAG_SQI_CS_NUMBER macro 912
DRV_SQI_FLAG_SQI_CS_NUMBER_0 macro 912
DRV_SQI_FLAG_SQI_CS_NUMBER_1 macro 912
DRV_SQI_FLAG_SQI_CS_NUMBER_2 macro 913
DRV_SQI_FLAG_SQI_CS_NUMBER_3 macro 913
DRV_SQI_FLAG_SQI_CS_NUMBER_MASK macro 913
DRV_SQI_FLAG_SQI_CS_NUMBER_POS macro 913
DRV_SQI_INDEX_0 macro 904
DRV_SQI_Initialize function 891
DRV_SQI_INSTANCES_NUMBER macro 888
DRV_SQI_INTERRUPT_MODE macro 888
DRV_SQI_LANE_CONFIG enumeration 913
DRV_SQI_Open function 894
DRV_SQI_SPI_OPERATION_MODE enumeration 903
DRV_SQI_Status function 892
DRV_SQI_Tasks function 893
DRV_SQI_TRANSFER_FLAGS enumeration 903
DRV_SQI_TransferData function 898
DRV_SQI_TransferElement structure 904
DRV_SQI_TransferFrame structure 914
DRV_SQI_TransferFrames function 899
drv_sram.h 969
DRV_SRAM_AddressGet function 952
DRV_SRAM_Close function 953
DRV_SRAM_COMMAND_HANDLE type 965
DRV_SRAM_COMMAND_HANDLE_INVALID macro 968
DRV_SRAM_COMMAND_STATUS enumeration 965
DRV_SRAM_CommandStatus function 954
DRV_SRAM_Deinitialize function 954
DRV_SRAM_EVENT enumeration 966
DRV_SRAM_EVENT_HANDLER type 966
DRV_SRAM_EventHandlerSet function 955
DRV_SRAM_GeometryGet function 957
DRV_SRAM_INDEX_0 macro 968
DRV_SRAM_INDEX_1 macro 968
DRV_SRAM_INIT structure 967
DRV_SRAM_Initialize function 957
DRV_SRAM_IsAttached function 959
DRV_SRAM_IsWriteProtected function 959
DRV_SRAM_Open function 960
DRV_SRAM_Read function 961
DRV_SRAM_Status function 962
DRV_SRAM_Write function 963
drv_sst25vf016b.h 842
DRV_SST25VF016B_BLOCK_COMMAND_HANDLE type 798
DRV_SST25VF016B_BLOCK_COMMAND_HANDLE_INVALID macro
801
DRV_SST25VF016B_BLOCK_EVENT enumeration 798
DRV_SST25VF016B_BlockErase function 790
DRV_SST25VF016B_BlockEventHandlerSet function 791
DRV_SST25VF016B_BlockRead function 793
DRV_SST25VF016B_BlockWrite function 794
DRV_SST25VF016B_CLIENT_STATUS enumeration 798
DRV_SST25VF016B_CLIENTS_NUMBER macro 776
DRV_SST25VF016B_ClientStatus function 789
DRV_SST25VF016B_Close function 787
drv_sst25vf016b_config_template.h 843
DRV_SST25VF016B_Deinitialize function 785
DRV_SST25VF016B_EVENT_HANDLER type 799
DRV_SST25VF016B_GeometryGet function 796
DRV_SST25VF016B_HARDWARE_HOLD_ENABLE macro 777
DRV_SST25VF016B_HARDWARE_WRITE_PROTECTION_ENABLE
macro 777
DRV_SST25VF016B_INDEX_0 macro 801
DRV_SST25VF016B_INDEX_1 macro 801
DRV_SST25VF016B_INIT structure 800
DRV_SST25VF016B_Initialize function 784
DRV_SST25VF016B_INSTANCES_NUMBER macro 777
DRV_SST25VF016B_MediaIsAttached function 797
DRV_SST25VF016B_MODE macro 777
DRV_SST25VF016B_Open function 788
DRV_SST25VF016B_QUEUE_DEPTH_COMBINED macro 778
DRV_SST25VF016B_Status function 786
DRV_SST25VF016B_Tasks function 787
Index
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1453
drv_sst25vf020b.h 844
DRV_SST25VF020B_BLOCK_COMMAND_HANDLE type 818
DRV_SST25VF020B_BLOCK_COMMAND_HANDLE_INVALID macro
821
DRV_SST25VF020B_BLOCK_EVENT enumeration 818
DRV_SST25VF020B_BlockErase function 809
DRV_SST25VF020B_BlockEraseWrite function 816
DRV_SST25VF020B_BlockEventHandlerSet function 811
DRV_SST25VF020B_BlockRead function 812
DRV_SST25VF020B_BlockWrite function 814
DRV_SST25VF020B_CLIENT_STATUS enumeration 819
DRV_SST25VF020B_CLIENTS_NUMBER macro 778
DRV_SST25VF020B_ClientStatus function 806
DRV_SST25VF020B_Close function 808
DRV_SST25VF020B_COMMAND_STATUS enumeration 821
DRV_SST25VF020B_CommandStatus function 807
drv_sst25vf020b_config_template.h 845
DRV_SST25VF020B_Deinitialize function 804
DRV_SST25VF020B_EVENT_HANDLER type 819
DRV_SST25VF020B_GeometryGet function 817
DRV_SST25VF020B_HARDWARE_HOLD_ENABLE macro 779
DRV_SST25VF020B_HARDWARE_WRITE_PROTECTION_ENABLE
macro 779
DRV_SST25VF020B_INDEX_0 macro 822
DRV_SST25VF020B_INDEX_1 macro 822
DRV_SST25VF020B_INIT structure 820
DRV_SST25VF020B_Initialize function 803
DRV_SST25VF020B_INSTANCES_NUMBER macro 779
DRV_SST25VF020B_MediaIsAttached function 817
DRV_SST25VF020B_MODE macro 779
DRV_SST25VF020B_Open function 808
DRV_SST25VF020B_QUEUE_DEPTH_COMBINED macro 780
DRV_SST25VF020B_Status function 805
DRV_SST25VF020B_Tasks function 805
drv_sst25vf064c.h 845
DRV_SST25VF064C_BLOCK_COMMAND_HANDLE type 837
DRV_SST25VF064C_BLOCK_COMMAND_HANDLE_INVALID macro
841
DRV_SST25VF064C_BLOCK_EVENT enumeration 838
DRV_SST25VF064C_BlockErase function 829
DRV_SST25VF064C_BlockEventHandlerSet function 831
DRV_SST25VF064C_BlockRead function 833
DRV_SST25VF064C_BlockWrite function 834
DRV_SST25VF064C_CLIENT_STATUS enumeration 838
DRV_SST25VF064C_CLIENTS_NUMBER macro 780
DRV_SST25VF064C_ClientStatus function 826
DRV_SST25VF064C_Close function 827
DRV_SST25VF064C_COMMAND_STATUS enumeration 839
DRV_SST25VF064C_CommandStatus function 828
drv_sst25vf064c_config_template.h 846
DRV_SST25VF064C_Deinitialize function 824
DRV_SST25VF064C_EVENT_HANDLER type 839
DRV_SST25VF064C_GeometryGet function 836
DRV_SST25VF064C_HARDWARE_HOLD_ENABLE macro 781
DRV_SST25VF064C_HARDWARE_WRITE_PROTECTION_ENABLE
macro 781
DRV_SST25VF064C_INDEX_0 macro 841
DRV_SST25VF064C_INDEX_1 macro 841
DRV_SST25VF064C_INIT structure 840
DRV_SST25VF064C_Initialize function 823
DRV_SST25VF064C_INSTANCES_NUMBER macro 781
DRV_SST25VF064C_MediaIsAttached function 837
DRV_SST25VF064C_MODE macro 781
DRV_SST25VF064C_Open function 829
DRV_SST25VF064C_QUEUE_DEPTH_COMBINED macro 782
DRV_SST25VF064C_Status function 825
DRV_SST25VF064C_Tasks function 826
drv_sst26.h 944
DRV_SST26_AddressGet function 938
DRV_SST26_BUFFER_OBJECT_NUMBER macro 922
DRV_SST26_CLIENTS_NUMBER macro 922
DRV_SST26_Close function 929
DRV_SST26_COMMAND_HANDLE type 941
DRV_SST26_COMMAND_HANDLE_INVALID macro 943
DRV_SST26_COMMAND_STATUS enumeration 941
DRV_SST26_CommandStatus function 936
drv_sst26_config_template.h 945
DRV_SST26_Deinitialize function 926
DRV_SST26_Erase function 929
DRV_SST26_EraseWrite function 931
DRV_SST26_EVENT enumeration 942
DRV_SST26_EVENT_HANDLER type 942
DRV_SST26_EventHandlerSet function 937
DRV_SST26_GeometryGet function 939
DRV_SST26_INDEX_0 macro 944
DRV_SST26_INDEX_1 macro 944
DRV_SST26_INIT structure 943
DRV_SST26_Initialize function 925
DRV_SST26_INSTANCES_NUMBER macro 923
DRV_SST26_IsAttached function 940
DRV_SST26_IsWriteProtected function 940
DRV_SST26_Open function 928
DRV_SST26_Read function 933
DRV_SST26_Status function 926
DRV_SST26_SYS_FS_REGISTER macro 923
DRV_SST26_Tasks function 927
DRV_SST26_Write function 934
DRV_STATIC_BUILD macro 532
drv_tmr.h 1006
DRV_TMR_AlarmDeregister function 992
DRV_TMR_AlarmDisable function 991
DRV_TMR_AlarmEnable function 991
DRV_TMR_AlarmHasElapsed function 990
DRV_TMR_AlarmPeriodGet function 993
DRV_TMR_AlarmPeriodSet function 993
DRV_TMR_AlarmRegister function 994
DRV_TMR_ASYNC_WRITE_ENABLE macro 978
DRV_TMR_CALLBACK type 1001
DRV_TMR_CLIENT_STATUS enumeration 1002
DRV_TMR_CLIENTS_NUMBER macro 979
DRV_TMR_ClientStatus function 986
DRV_TMR_CLOCK_PRESCALER macro 977
DRV_TMR_CLOCK_SOURCE macro 979
DRV_TMR_ClockSet function 985
DRV_TMR_Close function 987
drv_tmr_config_template.h 1008
DRV_TMR_CounterClear function 996
Index
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1454
DRV_TMR_CounterFrequencyGet function 995
DRV_TMR_CounterValueGet function 996
DRV_TMR_CounterValueSet function 998
DRV_TMR_Deinitialize function 982
DRV_TMR_DIVIDER_RANGE structure 1002
DRV_TMR_DividerRangeGet function 1000
DRV_TMR_GateModeClear function 998
DRV_TMR_GateModeSet function 986
DRV_TMR_INDEX_0 macro 1003
DRV_TMR_INDEX_1 macro 1004
DRV_TMR_INDEX_10 macro 1006
DRV_TMR_INDEX_11 macro 1006
DRV_TMR_INDEX_2 macro 1004
DRV_TMR_INDEX_3 macro 1004
DRV_TMR_INDEX_4 macro 1004
DRV_TMR_INDEX_5 macro 1005
DRV_TMR_INDEX_6 macro 1005
DRV_TMR_INDEX_7 macro 1005
DRV_TMR_INDEX_8 macro 1005
DRV_TMR_INDEX_9 macro 1005
DRV_TMR_INDEX_COUNT macro 1003
DRV_TMR_INIT structure 1001
DRV_TMR_Initialize function 982
DRV_TMR_INSTANCES_NUMBER macro 976
DRV_TMR_INTERRUPT_MODE macro 977
DRV_TMR_INTERRUPT_SOURCE macro 978
DRV_TMR_MODE macro 977
DRV_TMR_MODULE_ID macro 978
DRV_TMR_MODULE_INIT macro 978
DRV_TMR_Open function 988
DRV_TMR_OPERATION_MODE enumeration 1003
DRV_TMR_OperationModeGet function 999
DRV_TMR_PrescalerGet function 999
DRV_TMR_Start function 988
DRV_TMR_Status function 983
DRV_TMR_Stop function 989
DRV_TMR_Tasks function 984
drv_touch.h 1016
drv_touch_adc.h 614
DRV_TOUCH_ADC10BIT_CalibrationSet function 1022
DRV_TOUCH_ADC10BIT_CLIENT_DATA structure 1030
DRV_TOUCH_ADC10BIT_Close function 1022
DRV_TOUCH_ADC10BIT_Deinitialize function 1023
DRV_TOUCH_ADC10BIT_HANDLE type 1030
DRV_TOUCH_ADC10BIT_HANDLE_INVALID macro 1031
DRV_TOUCH_ADC10BIT_INDEX_0 macro 1031
DRV_TOUCH_ADC10BIT_INDEX_1 macro 1032
DRV_TOUCH_ADC10BIT_INDEX_COUNT macro 1032
DRV_TOUCH_ADC10BIT_INIT structure 1031
DRV_TOUCH_ADC10BIT_Initialize function 1023
DRV_TOUCH_ADC10BIT_Open function 1024
DRV_TOUCH_ADC10BIT_PositionDetect function 1028
DRV_TOUCH_ADC10BIT_Status function 1025
DRV_TOUCH_ADC10BIT_Tasks function 1026
DRV_TOUCH_ADC10BIT_TouchDataRead function 1029
DRV_TOUCH_ADC10BIT_TouchGetRawX function 1027
DRV_TOUCH_ADC10BIT_TouchGetRawY function 1027
DRV_TOUCH_ADC10BIT_TouchGetX function 1027
DRV_TOUCH_ADC10BIT_TouchGetY function 1029
DRV_TOUCH_ADC10BIT_TouchStatus function 1030
DRV_TOUCH_ADC10BIT_TouchStoreCalibration function 1028
DRV_TOUCH_AR1021_Calibrate function 1050
DRV_TOUCH_AR1021_CALIBRATION_PROMPT_CALLBACK
structure 1052
DRV_TOUCH_AR1021_CalibrationSet function 1050
DRV_TOUCH_AR1021_Close function 1051
DRV_TOUCH_AR1021_Deinitialize function 1044
DRV_TOUCH_AR1021_FactoryDefaultSet function 1045
DRV_TOUCH_AR1021_HANDLE type 1053
DRV_TOUCH_AR1021_HANDLE_INVALID macro 1054
DRV_TOUCH_AR1021_INDEX_0 macro 1054
DRV_TOUCH_AR1021_INDEX_COUNT macro 1055
DRV_TOUCH_AR1021_Initialize function 1045
DRV_TOUCH_AR1021_MODULE_ID enumeration 1053
DRV_TOUCH_AR1021_Open function 1052
DRV_TOUCH_AR1021_RegisterConfigWrite function 1046
DRV_TOUCH_AR1021_Status function 1047
DRV_TOUCH_AR1021_TASK_STATE enumeration 1054
DRV_TOUCH_AR1021_Tasks function 1047
DRV_TOUCH_AR1021_TouchDataRead function 1048
DRV_TOUCH_AR1021_TouchGetX function 1048
DRV_TOUCH_AR1021_TouchGetY function 1049
DRV_TOUCH_AR1021_TouchPenGet function 1049
DRV_TOUCH_AR1021_TouchStatus function 1050
DRV_TOUCH_Close function 1009
DRV_TOUCH_Deinitialize function 1010
DRV_TOUCH_INDEX_0 macro 1015
DRV_TOUCH_INDEX_1 macro 1015
DRV_TOUCH_INDEX_COUNT macro 1016
DRV_TOUCH_INIT structure 1014
DRV_TOUCH_Initialize function 1010
DRV_TOUCH_MTCH6301_CLIENT_OBJECT structure 1072
DRV_TOUCH_MTCH6301_Close function 1063
DRV_TOUCH_MTCH6301_Deinitialize function 1064
DRV_TOUCH_MTCH6301_HANDLE type 1071
DRV_TOUCH_MTCH6301_HANDLE_INVALID macro 1071
DRV_TOUCH_MTCH6301_I2C_MASTER_READ_ID macro 1075
DRV_TOUCH_MTCH6301_I2C_MASTER_WRITE_ID macro 1075
DRV_TOUCH_MTCH6301_I2C_READ_FRAME_SIZE macro 1071
DRV_TOUCH_MTCH6301_INDEX_0 macro 1072
DRV_TOUCH_MTCH6301_INDEX_1 macro 1073
DRV_TOUCH_MTCH6301_INDEX_COUNT macro 1073
DRV_TOUCH_MTCH6301_Initialize function 1065
DRV_TOUCH_MTCH6301_MODULE_ID enumeration 1071
DRV_TOUCH_MTCH6301_OBJECT structure 1073
DRV_TOUCH_MTCH6301_Open function 1066
DRV_TOUCH_MTCH6301_ReadRequest function 1068
DRV_TOUCH_MTCH6301_Status function 1067
DRV_TOUCH_MTCH6301_TASK_QUEUE structure 1074
DRV_TOUCH_MTCH6301_TASK_STATE enumeration 1075
DRV_TOUCH_MTCH6301_Tasks function 1068
DRV_TOUCH_MTCH6301_TouchDataRead function 1070
DRV_TOUCH_MTCH6301_TouchGetX function 1069
DRV_TOUCH_MTCH6301_TouchGetY function 1069
DRV_TOUCH_MTCH6301_TouchStatus function 1070
DRV_TOUCH_MTCH6303_I2C_REGISTER_MAP enumeration 1106
Index
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1455
DRV_TOUCH_MTCH6303_MSG_ID enumeration 1105
DRV_TOUCH_Open function 1011
DRV_TOUCH_PEN_STATE type 1014
DRV_TOUCH_POSITION_STATUS type 1015
DRV_TOUCH_Read function 1012
DRV_TOUCH_Reinitialize function 1012
DRV_TOUCH_SAMPLE_POINTS type 1015
DRV_TOUCH_Status function 1013
DRV_TOUCH_Tasks function 1013
drv_usart.h 1348
DRV_USART_AddressedBufferAddWrite function 1333
DRV_USART_BAUD_RATE_IDXn macro 1313
DRV_USART_BaudSet function 1326
DRV_USART_BUFFER_QUEUE_SUPPORT macro 1309
DRV_USART_BufferAddRead function 1328
DRV_USART_BufferAddWrite function 1329
DRV_USART_BufferCompletedBytesGet function 1335
DRV_USART_BufferEventHandlerSet function 1331
DRV_USART_BufferProcessedSizeGet function 1332
DRV_USART_BufferRemove function 1336
DRV_USART_BYTE_MODEL_BLOCKING macro 1313
DRV_USART_BYTE_MODEL_CALLBACK macro 1314
DRV_USART_BYTE_MODEL_SUPPORT macro 1310
DRV_USART_ByteErrorCallbackSet function 1345
DRV_USART_ByteReceiveCallbackSet function 1346
DRV_USART_ByteTransmitCallbackSet function 1347
DRV_USART_CLIENTS_NUMBER macro 1308
DRV_USART_ClientStatus function 1324
DRV_USART_Close function 1323
drv_usart_config_template.h 1350
DRV_USART_Deinitialize function 1318
DRV_USART_ErrorGet function 1324
DRV_USART_INDEX macro 1308
DRV_USART_Initialize function 1317
DRV_USART_INSTANCES_NUMBER macro 1309
DRV_USART_INTERRUPT_MODE macro 1308
DRV_USART_INTERRUPT_SOURCE_ERROR macro 1309
DRV_USART_INTERRUPT_SOURCE_RECEIVE macro 1310
DRV_USART_INTERRUPT_SOURCE_RECEIVE_DMA macro 1310
DRV_USART_INTERRUPT_SOURCE_TRANSMIT macro 1311
DRV_USART_INTERRUPT_SOURCE_TRANSMIT_DMA macro 1311
DRV_USART_LineControlSet function 1327
DRV_USART_Open function 1322
DRV_USART_PERIPHERAL_ID macro 1309
DRV_USART_QUEUE_DEPTH_COMBINED macro 1311
DRV_USART_RCV_QUEUE_SIZE_IDXn macro 1314
DRV_USART_Read function 1338
DRV_USART_READ_WRITE_MODEL_SUPPORT macro 1312
DRV_USART_ReadByte function 1340
DRV_USART_RECEIVE_DMA macro 1312
DRV_USART_ReceiverBufferIsEmpty function 1344
DRV_USART_ReceiverBufferSizeGet function 1342
DRV_USART_Status function 1319
DRV_USART_TasksError function 1321
DRV_USART_TasksReceive function 1320
DRV_USART_TasksTransmit function 1320
DRV_USART_TransferStatus function 1343
DRV_USART_TRANSMIT_DMA macro 1313
DRV_USART_TransmitBufferIsFull function 1344
DRV_USART_TransmitBufferSizeGet function 1342
DRV_USART_Write function 1339
DRV_USART_WriteByte function 1341
DRV_USART_XMIT_QUEUE_SIZE_IDXn macro 1315
drv_usbfs.h 1232
DRV_USBFS_ClientEventCallBackSet function 1192
DRV_USBFS_Close function 1193
drv_usbfs_config_template.h 1234
DRV_USBFS_DEVICE_AddressSet function 1196
DRV_USBFS_DEVICE_Attach function 1196
DRV_USBFS_DEVICE_CurrentSpeedGet function 1197
DRV_USBFS_DEVICE_Detach function 1198
DRV_USBFS_DEVICE_EndpointDisable function 1199
DRV_USBFS_DEVICE_EndpointDisableAll function 1200
DRV_USBFS_DEVICE_EndpointEnable function 1201
DRV_USBFS_DEVICE_EndpointIsEnabled function 1202
DRV_USBFS_DEVICE_EndpointIsStalled function 1203
DRV_USBFS_DEVICE_EndpointStall function 1204
DRV_USBFS_DEVICE_EndpointStallClear function 1204
DRV_USBFS_DEVICE_INTERFACE macro 1230
DRV_USBFS_DEVICE_IRPCancel function 1205
DRV_USBFS_DEVICE_IRPCancelAll function 1207
DRV_USBFS_DEVICE_IRPSubmit function 1208
DRV_USBFS_DEVICE_RemoteWakeupStart function 1210
DRV_USBFS_DEVICE_RemoteWakeupStop function 1210
DRV_USBFS_DEVICE_SOFNumberGet function 1211
DRV_USBFS_DEVICE_SUPPORT macro 1185
DRV_USBFS_ENDPOINT_TABLE_ENTRY_SIZE macro 1230
DRV_USBFS_ENDPOINTS_NUMBER macro 1185
DRV_USBFS_EVENT enumeration 1226
DRV_USBFS_EVENT_CALLBACK type 1227
DRV_USBFS_HOST_ATTACH_DEBOUNCE_DURATION macro 1186
DRV_USBFS_HOST_EventsDisable function 1212
DRV_USBFS_HOST_EventsEnable function 1212
DRV_USBFS_HOST_INTERFACE macro 1231
DRV_USBFS_HOST_IRPCancel function 1213
DRV_USBFS_HOST_IRPSubmit function 1214
DRV_USBFS_HOST_NAK_LIMIT macro 1186
DRV_USBFS_HOST_PIPE_HANDLE type 1227
DRV_USBFS_HOST_PIPE_HANDLE_INVALID macro 1231
DRV_USBFS_HOST_PipeClose function 1216
DRV_USBFS_HOST_PIPES_NUMBER macro 1186
DRV_USBFS_HOST_PipeSetup function 1217
DRV_USBFS_HOST_RESET_DURATION macro 1187
DRV_USBFS_HOST_ROOT_HUB_BusSpeedGet function 1218
DRV_USBFS_HOST_ROOT_HUB_Initialize function 1219
DRV_USBFS_HOST_ROOT_HUB_MaximumCurrentGet function 1219
DRV_USBFS_HOST_ROOT_HUB_OperationEnable function 1220
DRV_USBFS_HOST_ROOT_HUB_OperationIsEnabled function 1221
DRV_USBFS_HOST_ROOT_HUB_PortNumbersGet function 1222
DRV_USBFS_HOST_ROOT_HUB_PortReset function 1222
DRV_USBFS_HOST_ROOT_HUB_PortResetIsComplete function 1223
DRV_USBFS_HOST_ROOT_HUB_PortResume function 1224
DRV_USBFS_HOST_ROOT_HUB_PortSpeedGet function 1225
DRV_USBFS_HOST_ROOT_HUB_PortSuspend function 1226
DRV_USBFS_HOST_SUPPORT macro 1187
DRV_USBFS_INDEX_0 macro 1231
Index
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1456
DRV_USBFS_INDEX_1 macro 1232
DRV_USBFS_INIT structure 1228
DRV_USBFS_Initialize function 1194
DRV_USBFS_INSTANCES_NUMBER macro 1187
DRV_USBFS_INTERRUPT_MODE macro 1188
DRV_USBFS_Open function 1195
DRV_USBFS_OPMODES enumeration 1229
DRV_USBFS_ROOT_HUB_PORT_INDICATION type 1229
DRV_USBFS_ROOT_HUB_PORT_OVER_CURRENT_DETECT type
1230
DRV_USBFS_ROOT_HUB_PORT_POWER_ENABLE type 1230
DRV_USBFS_Status function 1190
DRV_USBFS_Tasks function 1191
DRV_USBFS_Tasks_ISR function 1192
drv_usbhs.h 1292
DRV_USBHS_ClientEventCallBackSet function 1253
DRV_USBHS_Close function 1253
drv_usbhs_config_template.h 1294
DRV_USBHS_DEVICE_AddressSet function 1255
DRV_USBHS_DEVICE_Attach function 1256
DRV_USBHS_DEVICE_CurrentSpeedGet function 1256
DRV_USBHS_DEVICE_Detach function 1257
DRV_USBHS_DEVICE_EndpointDisable function 1258
DRV_USBHS_DEVICE_EndpointDisableAll function 1259
DRV_USBHS_DEVICE_EndpointEnable function 1260
DRV_USBHS_DEVICE_EndpointIsEnabled function 1261
DRV_USBHS_DEVICE_EndpointIsStalled function 1262
DRV_USBHS_DEVICE_EndpointStall function 1263
DRV_USBHS_DEVICE_EndpointStallClear function 1263
DRV_USBHS_DEVICE_INTERFACE macro 1291
DRV_USBHS_DEVICE_IRPCancel function 1264
DRV_USBHS_DEVICE_IRPCancelAll function 1266
DRV_USBHS_DEVICE_IRPSubmit function 1267
DRV_USBHS_DEVICE_RemoteWakeupStart function 1269
DRV_USBHS_DEVICE_RemoteWakeupStop function 1269
DRV_USBHS_DEVICE_SOFNumberGet function 1270
DRV_USBHS_DEVICE_SUPPORT macro 1243
DRV_USBHS_DEVICE_TestModeEnter function 1271
DRV_USBHS_DEVICE_TestModeExit function 1271
DRV_USBHS_ENDPOINTS_NUMBER macro 1244
DRV_USBHS_EVENT enumeration 1287
DRV_USBHS_EVENT_CALLBACK type 1288
DRV_USBHS_HOST_ATTACH_DEBOUNCE_DURATION macro 1244
DRV_USBHS_HOST_EventsDisable function 1272
DRV_USBHS_HOST_EventsEnable function 1273
DRV_USBHS_HOST_INTERFACE macro 1291
DRV_USBHS_HOST_IRPCancel function 1274
DRV_USBHS_HOST_IRPSubmit function 1275
DRV_USBHS_HOST_NAK_LIMIT macro 1244
DRV_USBHS_HOST_PIPE_HANDLE type 1288
DRV_USBHS_HOST_PIPE_HANDLE_INVALID macro 1291
DRV_USBHS_HOST_PipeClose function 1276
DRV_USBHS_HOST_PIPES_NUMBER macro 1245
DRV_USBHS_HOST_PipeSetup function 1277
DRV_USBHS_HOST_RESET_DURATION macro 1245
DRV_USBHS_HOST_ROOT_HUB_BusSpeedGet function 1279
DRV_USBHS_HOST_ROOT_HUB_Initialize function 1279
DRV_USBHS_HOST_ROOT_HUB_MaximumCurrentGet function 1280
DRV_USBHS_HOST_ROOT_HUB_OperationEnable function 1281
DRV_USBHS_HOST_ROOT_HUB_OperationIsEnabled function 1282
DRV_USBHS_HOST_ROOT_HUB_PortNumbersGet function 1282
DRV_USBHS_HOST_ROOT_HUB_PortReset function 1283
DRV_USBHS_HOST_ROOT_HUB_PortResetIsComplete function 1284
DRV_USBHS_HOST_ROOT_HUB_PortResume function 1285
DRV_USBHS_HOST_ROOT_HUB_PortSpeedGet function 1285
DRV_USBHS_HOST_ROOT_HUB_PortSuspend function 1286
DRV_USBHS_HOST_SUPPORT macro 1245
DRV_USBHS_INDEX_0 macro 1292
DRV_USBHS_INIT structure 1288
DRV_USBHS_Initialize function 1249
DRV_USBHS_INSTANCES_NUMBER macro 1246
DRV_USBHS_INTERRUPT_MODE macro 1246
DRV_USBHS_Open function 1254
DRV_USBHS_OPMODES enumeration 1289
DRV_USBHS_ROOT_HUB_PORT_INDICATION type 1290
DRV_USBHS_ROOT_HUB_PORT_OVER_CURRENT_DETECT type
1290
DRV_USBHS_ROOT_HUB_PORT_POWER_ENABLE type 1290
DRV_USBHS_Status function 1250
DRV_USBHS_Tasks function 1251
DRV_USBHS_Tasks_ISR function 1251
DRV_USBHS_Tasks_ISR_USBDMA function 1252
drv_wm8904.h 348
DRV_WM8904_AUDIO_DATA_FORMAT enumeration 321
DRV_WM8904_BAUD_RATE macro 321
DRV_WM8904_BUFFER_EVENT enumeration 344
DRV_WM8904_BUFFER_EVENT_HANDLER type 344
DRV_WM8904_BUFFER_HANDLE type 345
DRV_WM8904_BUFFER_HANDLE_INVALID macro 342
DRV_WM8904_BufferAddRead function 332
DRV_WM8904_BufferAddWrite function 333
DRV_WM8904_BufferAddWriteRead function 334
DRV_WM8904_BufferEventHandlerSet function 329
DRV_WM8904_CHANNEL enumeration 346
DRV_WM8904_CLIENTS_NUMBER macro 321
DRV_WM8904_Close function 329
DRV_WM8904_COMMAND_EVENT_HANDLER type 346
DRV_WM8904_CommandEventHandlerSet function 331
drv_wm8904_config_template.h 348
DRV_WM8904_COUNT macro 342
DRV_WM8904_Deinitialize function 326
DRV_WM8904_ENABLE_MIC_INPUT macro 322
DRV_WM8904_INDEX_0 macro 343
DRV_WM8904_INDEX_1 macro 343
DRV_WM8904_INDEX_2 macro 343
DRV_WM8904_INDEX_3 macro 343
DRV_WM8904_INDEX_4 macro 344
DRV_WM8904_INDEX_5 macro 344
DRV_WM8904_INIT structure 347
DRV_WM8904_Initialize function 325
DRV_WM8904_INSTANCES_NUMBER macro 322
DRV_WM8904_MuteOff function 336
DRV_WM8904_MuteOn function 337
DRV_WM8904_Open function 328
DRV_WM8904_SamplingRateGet function 338
DRV_WM8904_SamplingRateSet function 338
Index
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1457
DRV_WM8904_SetAudioCommunicationMode function 339
DRV_WM8904_Status function 326
DRV_WM8904_Tasks function 327
DRV_WM8904_VersionGet function 341
DRV_WM8904_VersionStrGet function 341
DRV_WM8904_VOLUME macro 322
DRV_WM8904_VolumeGet function 339
DRV_WM8904_VolumeSet function 340
drv_xc2c64a.h 359
E
ENC28J60 Driver Library Help 407
ENCx24J600 Driver Library Help 427
Ethernet GMAC Driver Library 515
Ethernet MAC Driver Library 446
Ethernet PHY Driver Library 469
Example Code for Complete Operation 687
Example Usage of the Timer Driver 975
F
File I/O Type Read/Write Data Transfer Model 1303
Files 19, 70, 79, 101, 154, 196, 235, 275, 314, 347, 359, 376, 406, 425,
445, 467, 505, 514, 520, 550, 605, 613, 617, 636, 639, 676, 708, 741,
769, 842, 880, 915, 944, 969, 1006, 1016, 1032, 1038, 1055, 1076,
1106, 1144, 1232, 1292, 1348, 1382, 1392, 1429
10-bit ADC Touch Driver Library 1032
ADC Touch Driver Library 1038
AK4384 Codec Driver Library 154
AK4642 Codec Driver Library 196
AK4953 Codec Driver Library 235
AK4954 Codec Driver Library 275
AK7755 Codec Driver Library 314
AR1021 Touch Driver Library 1055
BM64 Bluetooth Driver Library 70
CPLD XC2C64A Driver Library 359
CTR Driver Library 376
EEPROM Driver Library 406
Ethernet MAC Driver Library 467, 520
Ethernet PHY Driver Library 505
MRF24WN Wi-Fi Driver Library 1382, 1392, 1429
MTCH6301 Touch Driver Library 1076
MTCH6303 Touch Driver Library 1106
NVM Driver Library 636, 676
PMP Driver Library 708
SD Card Driver Library 741
SPI Driver Library 769
SPI Flash Driver Library 842
SPI PIC32WK IPF Flash Driver Library 880
SQI Driver Library 915
SQI Flash Driver Library 944
Timer Driver Library 1006
USART Driver Library 1348
WM8904 Codec Driver Library 347
Flash Driver Library 508
G
General Device Mode Operations 1169
Generic Touch Driver API 1008
H
Host Interface Driver Wi-Fi Events 1439
How the Library Works 28, 81, 107, 158, 200, 239, 279, 318, 361, 379,
409, 429, 521, 554, 612, 615, 646, 683, 716, 745, 773, 849, 883, 919,
947, 971, 1035, 1039, 1057, 1079, 1109, 1178, 1236, 1298, 1352, 1387,
1394, 1436
ADC Touch Driver Library 1035
AK4384 Driver Library 107
AK4642 Driver Library 158
AK4953 Driver Library 200
AK4954 Driver Library 239
AK7755 Driver Library 279
AR1021 Touch Driver Library 1039
BM64 Bluetooth Driver Library 28
CTR Driver Library 361
Data EEPROM Driver Library 379
ENC28J60 Driver 409
ENCx24J600 Driver 429
MRF24WN Wi-Fi Driver Library 1352, 1387, 1394, 1436
MTCH6301 Touch Driver Library 1057
MTCH6303 Touch Driver Library 1079
NVM Driver Library 646
PMP Driver Library 683
SD Card Driver Library 716
SPI Driver Library 745
SPI Flash Driver Library 773
SPI PIC32WK IPF Flash Driver Library 849
SQI Driver Library 883
SQI Flash Driver Library 919
Timer Driver Library 971
USART Driver Library 1298
WM8904 Driver Library 318
I
I2C Driver Library Help 520
I2C_STATIC_DRIVER_MODE macro 532
I2S Driver Library Help 552
INCLUDE_BM64_BLE macro 34
INCLUDE_BM64_I2S macro 34
INCLUDE_DEPRECATED_MMI_COMMANDS macro 34
Initializing the Driver 1035, 1039, 1057, 1109
Initializing the USART Driver 1298
Input Capture Driver Library 607
Input System Service mXT336T Touch Driver Library 614
Input System Service Touch ADC Driver Library 611
Input System Service Touch Driver Library 610
Introduction 3, 20, 25, 72, 80, 102, 106, 156, 198, 237, 277, 316, 349,
350, 360, 378, 407, 427, 447, 469, 508, 515, 520, 552, 607, 617, 638,
645, 678, 681, 710, 714, 743, 771, 847, 882, 917, 946, 970, 1017, 1034,
1038, 1056, 1077, 1108, 1295, 1351, 1385, 1393, 1432
AK7755 Codec Driver Library 277
OVM7690 Camera Driver Library 80
iwpriv_adhocctx_set function 1376
IWPRIV_CMD enumeration 1378
iwpriv_config_read function 1377
iwpriv_config_write function 1366
IWPRIV_CONN_STATUS enumeration 1377
iwpriv_connstatus_get function 1366
iwpriv_devinfo_get function 1367
Index
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1458
iwpriv_execute function 1374
IWPRIV_EXECUTE_PARAM union 1378
iwpriv_get function 1374
IWPRIV_GET_PARAM union 1378
iwpriv_initialconn_set function 1367
iwpriv_initstatus_get function 1368
iwpriv_is_servermode function 1368
iwpriv_leftclient_get function 1369
iwpriv_mcastfilter_set function 1369
iwpriv_nettype_get function 1370
iwpriv_nettype_set function 1370
iwpriv_numberofscanresults_get function 1371
IWPRIV_PARAM_CLIENTINFO structure 1379
IWPRIV_PARAM_CONFIG structure 1380
IWPRIV_PARAM_CONNECT structure 1380
IWPRIV_PARAM_CONTEXT structure 1379
IWPRIV_PARAM_DEVICEINFO structure 1379
IWPRIV_PARAM_DRIVERSTATUS structure 1380
IWPRIV_PARAM_FWUPGRADE structure 1381
IWPRIV_PARAM_MULTICASTFILTER structure 1381
IWPRIV_PARAM_NETWORKTYPE structure 1381
IWPRIV_PARAM_OPERATIONMODE structure 1381
IWPRIV_PARAM_POWERSAVE structure 1382
IWPRIV_PARAM_SCAN structure 1382
IWPRIV_PARAM_SSID structure 1382
iwpriv_powersave_config function 1371
iwpriv_prescan_isfinished function 1374
iwpriv_prescan_option_get function 1375
iwpriv_prescan_option_set function 1375
iwpriv_prescan_start function 1372
iwpriv_scan_start function 1372
IWPRIV_SCAN_STATUS enumeration 1379
iwpriv_scanstatus_get function 1373
iwpriv_set function 1376
IWPRIV_SET_PARAM union 1380
iwpriv_ssid_get function 1373
iwpriv_ssid_set function 1374
IWPRIV_STATUS enumeration 1377
L
Library Interface 14, 21, 37, 72, 83, 102, 120, 169, 207, 247, 287, 323,
349, 351, 362, 385, 412, 432, 453, 474, 508, 519, 533, 570, 607, 613,
617, 622, 638, 654, 678, 690, 710, 722, 754, 783, 852, 889, 924, 952,
980, 1009, 1021, 1037, 1043, 1062, 1080, 1115, 1189, 1247, 1316,
1356, 1391, 1399, 1441
10-bit ADC Touch Driver Library 1021
ADC Driver Library 21
ADC Touch Driver Library 1037
AK4384 Codec Driver Library 120
AK4642 Codec Driver Library 169
AK4953 Codec Driver Library 207
AK4954 Codec Driver Library 247
AK7755 Codec Driver Library 287
AR1021 Touch Driver Library 1043
BM64 Bluetooth Driver Library 37
Camera Driver Library 83
CAN Driver Library 102
Comparator Driver Library 349
CPLD XC2C64A Driver Library 351
CTR Driver Library 362
Data EEPROM Driver Library 385
Ethernet MAC Driver Library 453, 519
Ethernet PHY Driver Library 474
Flash Driver Library 508
Input Capture Driver Library 607
MCPWM Driver Library 638
MRF24WN Wi-Fi Library 1356, 1391, 1399, 1441
MTCH6301 Touch Driver Library 1062
MTCH6303 Touch Driver Library 1080
NVM Driver Library 622, 654
Output Compare Driver Library 678
PMP Driver Library 690
RTCC Driver Library 710
SD Card Driver Library 722
SPI Driver Library 754
SPI Flash Driver Library 783
SPI PIC32WK IPF Flash Driver Library 852
SQI Driver Library 889
SQI Flash Driver Library 924
Timer Driver Library 980
USART Driver Library 1316
WM8904 Codec Driver Library 323
Library Overview 28, 80, 107, 158, 199, 239, 279, 317, 351, 361, 379,
409, 429, 449, 471, 518, 521, 554, 611, 615, 618, 646, 683, 716, 745,
772, 848, 883, 919, 947, 970, 1017, 1035, 1039, 1057, 1079, 1109,
1177, 1235, 1297, 1352, 1387, 1394, 1435
10-bit ADC Touch Driver Library 1017
ADC Touch Driver Library 1035
AK4384 Driver Library 107
AK4642 Driver Library 158
AK4953 Driver Library 199
AK4954 Driver Library 239
AK7755 Driver Library 279
AR1021 Touch Driver Library 1039
BM64 Bluetooth Driver Library 28
CPLD XC2C64A Driver Library 351
CTR Driver Library 361
Data EEPROM Driver Library 379
Ethernet MAC Driver Library 449, 518
Ethernet PHY Driver Library 471
MRF24WN Wi-Fi Driver Library 1352, 1387, 1394, 1435
MTCH6301 Touch Driver Library 1057
MTCH6303 Touch Driver Library 1079
NVM Driver Library 618, 646
PMP Driver Library 683
SD Card Driver Library 716
SPI Driver Library 745
SPI Flash Driver Library 772
SPI PIC32WK IPF Flash Driver Library 848
SQI Driver Library 883
SQI Flash Driver Library 919
Timer Driver Library 970
USART Driver Library 1297
WM8904 Driver Library 317
M
MAX_NONBUFFERED_BYTE_COUNT macro 707
Media Interface Functions 950
Index
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1459
Migrating Applications from v1.03.01 and Earlier Releases of MPLAB
Harmony 640
MIIM Driver Library 617
Modification 973
Motor Control PWM (MCPWM) Driver Library 638
MRF24WN Wi-Fi Driver Library 1351
MTCH6301 Touch Driver Library 1056
MTCH6303 Touch Driver Library 1077
MXT_T100_EVENT_DOWN enumeration member 1143
MXT_T100_EVENT_DOWNSUP enumeration member 1143
MXT_T100_EVENT_DOWNUP enumeration member 1143
MXT_T100_EVENT_MOVE enumeration member 1143
MXT_T100_EVENT_NO_EVENT enumeration member 1143
MXT_T100_EVENT_SUP enumeration member 1143
MXT_T100_EVENT_UNSUP enumeration member 1143
MXT_T100_EVENT_UNSUPSUP enumeration member 1143
MXT_T100_EVENT_UNSUPUP enumeration member 1143
MXT_T100_EVENT_UP enumeration member 1143
MXT_T100_TYPE_ACTIVE_STYLUS enumeration member 1144
MXT_T100_TYPE_FINGER enumeration member 1144
MXT_T100_TYPE_GLOVE enumeration member 1144
MXT_T100_TYPE_HOVERING_FINGER enumeration member 1144
MXT_T100_TYPE_LARGE_TOUCH enumeration member 1144
MXT_T100_TYPE_PASSIVE_STYLUS enumeration member 1144
mXT336T Touch Driver Library 1107
N
NVM Driver Library 640
NVM System Initialization 647
O
Opening a Driver 9
Opening the Driver 773, 849, 1036, 1040, 1058, 1110, 1160
Opening the USART Driver 1302
Optional Interfaces 975
Output Compare Driver Library 678
OVM7690 Camera Driver Library 80
P
Parallel Master Port (PMP) Driver Library 681
PIC32MX USB Driver 1176
PIC32MZ USB Driver 1234
PMP_QUEUE_ELEMENT_OBJECT structure 708
R
RTCC Driver Library 710
S
Sample Functionality 1354, 1387, 1395
Sample Rate 32
SAMPLE_LENGTH enumeration 314
SD Card Driver Initialization 717
SDCARD_DETECTION_LOGIC enumeration 737
SDCARD_MAX_LIMIT macro 738
Secure Digital (SD) Card Driver Library 714
Settings Functions 31
SPI Driver Library 743
SPI Flash Driver Library 771
SPI PIC32WK IPF Flash Driver Library 847
SQI Driver Library 882
SQI Flash Driver Library 917
SRAM Driver Library 946
SST25FV016B API 783
SST25VF020B API 802
SST25VF064C API 822
System Access 108, 159, 200, 239, 279, 318, 522, 554, 745
System Functions 29, 883
System Initialization 683, 1353
System Initialization and Deinitialization 773
System Initialization/Deinitialization 849
System Initialization/Status Functions 947
System Interaction 971
T
t100_event enumeration 1143
t100_type enumeration 1144
Tasks Routine 1036, 1040, 1059, 1111
Timer Driver Library 970
Touch Driver Libraries Help 1008
Touch Input Read Request 1059, 1111
Transfer Operation 685
Transferring Data to the Host 1172
U
USART Driver Library 1294
USB Driver Device Mode Operation 1168
USB Driver Host Mode Operation 1161
USB Driver Libraries 1147
Using a Driver in an Application 7
Using a Driver's Client Interface 6
Using a Driver's System Interface 4
Using Asynchronous and Callback Functions 11
Using Driver Interface Functions 10
Using the Library 27, 80, 106, 157, 199, 238, 278, 317, 350, 360, 378,
408, 428, 447, 469, 516, 520, 553, 614, 618, 645, 682, 715, 744, 771,
847, 882, 918, 946, 970, 1017, 1034, 1038, 1056, 1078, 1108, 1177,
1235, 1295, 1352, 1386, 1394, 1434
10-bit ADC Touch Driver Library 1017
ADC Touch Driver Library 1034
AK4384 Codec Driver Library 106
AK4642 Codec Driver Library 157
AK4953 Codec Driver Library 199
AK4954 Codec Driver Library 238
AK7755 Codec Driver Library 278
AR1021 Touch Driver Library 1038
BM64 Bluetooth Driver Library 27
CPLD XC2C64A Driver Library 350
CTR Driver Library 360
Data EEPROM Driver Library 378
Ethernet MAC Driver Library 447, 516
Ethernet PHY Driver Library 469
MIIM Driver Library 618
MRF24WN Wi-Fi Driver Library 1352
MTCH6301 Touch Driver Library 1056
MTCH6303 Touch Driver Library 1078
NVM Driver Library 645
PMP Driver Library 682
SD Card Driver Library 715
SPI Driver Library 744
Index
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1460
SPI Flash Driver Library 771
SPI PIC32WK IPF Flash Driver Library 847
SQI Driver Library 882
SQI Flash Driver Library 918
Timer Driver Library 970
USART Driver Library 1295
WILC1000 Wi-Fi Driver Library 1386
WINC1500 Socket Mode Driver Library 1434
WINC1500 Wi-Fi Driver Library 1394
WM8904 Codec Driver Library 317
Using the USART Driver with DMA 1306
V
Volume V: MPLAB Harmony Framework Reference 2
W
WDRV_CLI_Init function 1401
WDRV_EXT_CmdChannelSet function 1415
WDRV_EXT_CmdConnect function 1410
WDRV_EXT_CmdConnectContextBssidGet function 1417
WDRV_EXT_CmdConnectContextChannelGet function 1362
WDRV_EXT_CmdDisconnect function 1411
WDRV_EXT_CmdFWUpdate function 1416
WDRV_EXT_CmdFWVersionGet function 1405
WDRV_EXT_CmdMacAddressGet function 1406
WDRV_EXT_CmdNetModeAPSet function 1411
WDRV_EXT_CmdNetModeBSSSet function 1411
WDRV_EXT_CmdNetModeIBSSSet function 1363
WDRV_EXT_CmdPowerSaveGet function 1362
WDRV_EXT_CmdPowerSavePut function 1407
WDRV_EXT_CmdScanGet function 1406
WDRV_EXT_CmdScanOptionSet function 1408
WDRV_EXT_CmdScanOptionsSet function 1418
WDRV_EXT_CmdScanStart function 1412
WDRV_EXT_CmdSecNoneSet function 1412
WDRV_EXT_CmdSecWEPSet function 1413
WDRV_EXT_CmdSecWPA2Set function 1364
WDRV_EXT_CmdSecWPASet function 1413
WDRV_EXT_CmdSecWpsSet function 1416
WDRV_EXT_CmdSSIDGet function 1407
WDRV_EXT_CmdSSIDSet function 1415, 1418
WDRV_EXT_CmdTxPowerSet function 1417
WDRV_EXT_DataSend function 1414
WDRV_EXT_Deinitialize function 1404
WDRV_EXT_HWInterruptHandler function 1408
WDRV_EXT_Initialize function 1364, 1365, 1420
WDRV_EXT_ModuleUpDown function 1409
WDRV_EXT_MulticastFilterSet function 1410
WDRV_EXT_PrivConfig function 1365
WDRV_EXT_RssiRead function 1421
WDRV_EXT_ScanDoneSet function 1414
WDRV_EXT_ScanIsInProgress function 1419
WDRV_EXT_ScanResultGet function 1363, 1405
WDRV_EXT_WPSResultsRead function 1421
WDRV_GPIO_DeInit function 1403
WDRV_GPIO_Init function 1360
WDRV_GPIO_PowerOff function 1360
WDRV_GPIO_PowerOn function 1360
WDRV_INTR_Deinit function 1402
WDRV_INTR_Init function 1402
WDRV_INTR_SourceDisable function 1419
WDRV_INTR_SourceEnable function 1420
WDRV_IsPowerOff function 1361
wdrv_mrf24wn_api.h 1382
WDRV_MRF24WN_ISR function 1361
wdrv_mrf24wn_iwpriv.h 1383
WDRV_SPI_Deinit function 1403
WDRV_SPI_In function 1359
WDRV_SPI_Init function 1403
WDRV_SPI_Out function 1359
WDRV_STUB_Assert function 1422
WDRV_STUB_GPIO_ChipDisable function 1422
WDRV_STUB_GPIO_ChipEnable function 1423
WDRV_STUB_GPIO_DeInitialize function 1423
WDRV_STUB_GPIO_Initialize function 1423
WDRV_STUB_GPIO_ModuleReset function 1424
WDRV_STUB_GPIO_ModuleUnreset function 1424
WDRV_STUB_HardDelay function 1425
WDRV_STUB_INTR_Deinit function 1425
WDRV_STUB_INTR_Init function 1426
WDRV_STUB_INTR_SourceDisable function 1426
WDRV_STUB_INTR_SourceEnable function 1427
WDRV_STUB_Print macro 1429
WDRV_STUB_SPI_Deinitialize function 1427
WDRV_STUB_SPI_In function 1427
WDRV_STUB_SPI_Initialize function 1428
WDRV_STUB_SPI_Out function 1428
wdrv_wilc1000_api.h 1392
wdrv_wilc1000_stub.h 1392
wdrv_winc1500_api.h 1430
WDRV_WINC1500_ISR function 1404
wdrv_winc1500_stub.h 1431
Wi-Fi Driver Libraries 1350
WILC1000 Wi-Fi Driver Ethernet Mode Library 1385
WINC1500 Firmware Update Utility 1441
WINC1500 Module Firmware Overview 1437
WINC1500 Socket Mode Driver Library 1432
WINC1500 Wi-Fi Driver Ethernet Mode Library 1393
WM8904 Codec Driver Library 316
Index
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 1461
Features
• High performance, low power Atmel® AVR® 8-bit Microcontroller
• Advanced RISC architecture
– 131 powerful instructions - most single clock cycle execution
– 32 × 8 general purpose working registers
– Fully static operation
– Up to eight MIPS throughput at 8MHz
• High endurance non-volatile memory segments
– 16K/32Kbytes of in-system self-programmable flash (Atmel ATmega16HVB/32HVB)
– 512/1Kbytes EEPROM
– 1K/2Kbytes internal SRAM
– Write/erase cycles 10,000 flash/100,000 EEPROM
– Data retention: 20 years at 85°C/100 years at 25°C (1)
– Optional boot code section with independent lock bits
In-system programming by on-chip boot program
True read-while-write operation
– Programming lock for software security
• Battery management features
– Two, three or four cells in series
– High-current protection (charge and discharge)
– Over-current protection (charge and discharge)
– Short-circuit protection (discharge)
– High-voltage outputs to drive N-channel charge/discharge FETs
– Optional deep under voltage recovery mode - allowing 0-volt charging without
external precharge FET
– Optional high-voltage open drain output - allowing 0-volt charging with external
precharge FET
– Integrated cell balancing FETs
• Peripheral features
– Two configurable 8-bit or 16-bit timers with separate prescaler, optional input
capture (IC), compare mode and CTC
– SPI - serial peripheral interface
– 12-bit voltage ADC, six external and one internal ADC input
– High resolution coulomb counter ADC for current measurements
– TWI serial interface supporting SMBus implementation
– Programmable watchdog timer
• Special microcontroller features
– debugWIRE on-chip debug system
– In-system programmable via SPI ports
– Power-on reset
– On-chip voltage regulator with short-circuit monitoring interface
– External and Internal interrupt sources
– Sleep modes: idle, ADC noise reduction, power-save, and power-off
• Additional secure authentication features available only under NDA
• Packages
– 44-pin TSSOP
• Operating voltage: 4V -18V
• Maximum withstand voltage (high-voltage pins): 35V
• Temperature range: -40°C to 85°C
• Speed grade: 1MHz - 8MHz
Note: 1. See ”Data retention” on page 8 for details.
8-bit
Microcontroller
with
16K/32Kbytes
In-System
Programmable
Flash
ATmega16HVB
ATmega32HVB
8042E–AVR–09/2013
2
8042E–AVR–09/2013
ATmega16HVB/32HVB
1. Pin configurations
1.1 TSSOP
Figure 1-1. TSSOP - pinout the Atmel ATmega16HVB/32HVB.
1 44
3
PI
PPI
NV
PV1
PV2
PV3
PV4
PVT
VCC
GND
PC5
PC4(SCL)
PC3(INT3/SDA)
PC2(INT2)
PC1(INT1)
PC0(INT0/EXTPROT)
PB7(MISO/PCINT11)
NC
PB6(MOSI/PCINT10)
PB5(SCK/PCINT9)
PB4(SS/PCINT8)
PB3(PCINT7)
2
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
43
42
41
40
39
38
37
36
35
34
33
32
31
30
29
28
27
26
25
24
23
NI
NNI
VREFGND
VREF
GND
VREG
PA0(ADC0/SGND/PCINT0)
PA1(ADC1/SGND/PCINT1)
PA2(PCINT2/T0)
PA3(PCINT3/T1)
VCLMP10
VFET
BATT
VCC
GND
OD
NC
OC
RESET/dw
PB0(PCINT4/ICP00)
PB1(PCINT5/CKOUT)
PB2(PCINT6)
3
8042E–AVR–09/2013
ATmega16HVB/32HVB
1.2 Pin descriptions
1.2.1 VFET
High voltage supply pin. This pin is used as supply for the internal voltage regulator, described in
”Voltage regulator” on page 129.
1.2.2 VCLMP10
Internal 10V clamping of VFET voltage for external decoupling.
1.2.3 VCC
Digital supply voltage. Normally connected to VREG.
1.2.4 VREG
Output from the internal voltage regulator. Used for external decoupling to ensure stable regulator
operation. For details, see ”Voltage regulator” on page 129.
1.2.5 VREF
Internal voltage reference for external decoupling. For details, see ”Voltage reference and temperature
sensor” on page 122.
1.2.6 VREFGND
Ground for decoupling of internal voltage reference. For details, see ”Voltage reference and
temperature sensor” on page 122. Do not connect to GND or SGND on PCB.
1.2.7 GND
Ground.
1.2.8 Port A (PA3..PA0)
Port A serves as a low-voltage 4-bit bi-directional I/O port with internal pull-up resistors (selected
for each bit). As inputs, Port A pins that are externally pulled low will source current if the pull-up
resistors are activated. The Port A pins are tri-stated when a reset condition becomes active,
even if the clock is not running.
Port A also serves the functions of various special features of the Atmel ATmega16HVB/32HVB
as listed in ”Alternate functions of Port A” on page 74.
1.2.9 Port B (PB7..PB0)
Port B is a low-voltage 8-bit bi-directional I/O port with internal pull-up resistors (selected for
each bit). As inputs, Port B pins that are externally pulled low will source current if the pull-up
resistors are activated. The Port B pins are tri-stated when a reset condition becomes active,
even if the clock is not running.
Port B also serves the functions of various special features of the ATmega16HVB/32HVB as
listed in ”Alternate functions of Port B” on page 75.
1.2.10 Port C (PC5)
Port C (PC5) is a high voltage Open Drain output port.
4
8042E–AVR–09/2013
ATmega16HVB/32HVB
1.2.11 Port C (PC4..PC0)
Port C is a 5-bit high voltage Open Drain bi-directional I/O port.
1.2.12 OC/OD
High voltage output to drive Charge/Discharge FET. For details, see ”FET driver” on page 145.
1.2.13 PI/NI
Filtered positive/negative input from external current sense resistor, used to by the Coulomb
Counter ADC to measure charge/discharge currents flowing in the battery pack. For details, see
”Coulomb counter – Dedicated fuel gauging Sigma-Delta ADC” on page 108.
1.2.14 PPI/NNI
Unfiltered positive/negative input from external current sense resistor, used by the battery protection
circuit, for over-current and short-circuit detection. For details, see ”Battery protection” on
page 132.
1.2.15 NV/PV1/PV2/PV3/PV4
NV, PV1, PV2, PV3, and PV4 are the inputs for battery cells one, two, three and four, used by
the Voltage ADC to measure each cell voltage. For details, see ”Voltage ADC – 7-channel general
purpose 12-bit Sigma-Delta ADC” on page 116.
1.2.16 PVT
Defines the source voltage level for the Charge FET driver. For details, see ”FET driver” on page
145.
1.2.17 BATT
Input for detecting when a charger is connected. Defines the source voltage level for the Discharge
FET driver. For details, see ”FET driver” on page 145.
1.2.18 RESET/dw
Reset input. A low level on this pin for longer than the minimum pulse length will generate a
reset, even if the clock is not running. The minimum pulse length is given in Table 32-3 on page
227. Shorter pulses are not guaranteed to generate a reset. This pin is also used as debugWIRE
communication pin.
5
8042E–AVR–09/2013
ATmega16HVB/32HVB
2. Overview
The Atmel ATmega16HVB/32HVB is a monitoring and protection circuit for 3- and 4-cell Li-ion
applications with focus on highest safety including safe authentication, low cost and high utilization
of the cell energy. The device contains secure authentication features as well as
autonomous battery protection during charging and discharging. The External Protection Input
can be used to implement other battery protection mechanisms using external components, for
example, protection against chargers with too high charge voltage can be easily implemented
with a few low cost passive components. The feature set makes the ATmega16HVB/32HVB a
key component in any system focusing on high security, battery protection, high system utilization
and low cost.
Figure 2-1. Block diagram.
ATmega16HVB/32HVB provides the necessary redundancy on-chip to make sure that the battery
is protected in critical failure modes. The chip is specifically designed to provide safety for
the battery cells in case of pin shorting, loss of power (either caused by battery pack short or
VCC short), illegal charger connection or software runaway. This makes ATmega16HVB/32HVB
the ideal one-chip solution for applications with focus on high safety.
The ATmega16HVB/32HVB features an integrated voltage regulator that operates at a wide
range of input voltages, 4 - 18 volts. This voltage is regulated to a constant supply voltage of
PORTA (4)
Flash SRAM
CPU EEPROM
PV2
NV
OC FET
Control
Voltage
ADC
Voltage
Reference
Coulomb
Counter ADC
GND
VCC
RESET/dW
Power
Supervision
POR &
RESET
Watchdog
Oscillator
Watchdog
Timer
Oscillator
Circuits /
Clock
Generation
VREF
VREFGND
PI
NI
PA3..0
PA1..0
8/16-bit T/C1
8/16-bit T/C0
PORTB (8)
PB7..0
SPI
Voltage
Regulator
Charger
Detect
VFET
VREG
BATT
PV1
DATA BUS
VPTAT
Current
Protection
Security
Module
PORTC (6)
PC5..0
Voltage Regulator
Monitor Interface
PB0
Oscillator
Sampling
Interface
Program
Logic
debugWIRE
Cell
Balancing PV3
TWI PV4
PPI
NNI
OD
PORTA (4)
Flash SRAM
CPU EEPROM
PV2
NV
OC FET
Control
Voltage
ADC
Voltage
Reference
Coulomb
Counter ADC
GND
VCC
RESET/dW
Power
Supervision
POR &
RESET
Watchdog
Oscillator
Watchdog
Timer
Oscillator
Circuits /
Clock
Generation
VREF
VREFGND
PI
NI
PA3..0
PA1..0
8/16-bit T/C1
8/16-bit T/C0
PORTB (8)
PB7..0
SPI
Voltage
Regulator
Charger
Detect
VFET
VREG
BATT
PV1
DATA BUS
VPTAT
Current
Protection
Security
Module
PORTC (6)
PC5..0
Voltage Regulator
Monitor Interface
PB0
Oscillator
Sampling
Interface
Program
Logic
debugWIRE
Cell
Balancing PV3
TWI PV4
PPI
NNI
OD
6
8042E–AVR–09/2013
ATmega16HVB/32HVB
nominally 3.3 volts for the integrated logic and analog functions. The regulator capabilities, combined
with an extremely low power consumption in the power saving modes, greatly enhances
the cell energy utilization compared to existing solutions.
The chip utilizes the Atmel patented Deep Under-voltage Recovery (DUVR) mode that supports
pre-charging of deeply discharged battery cells without using a separate Pre-charge FET. DUVR
mode cannot be used in 2-cell applications. Optionally, Pre-charge FETs are supported for integration
into many existing battery charging schemes.
The battery protection monitors the charge and discharge current to detect illegal conditions and
protect the battery from these when required. A 12-bit Voltage ADC allows software to monitor
each cell voltage individually with high accuracy. The ADC also provides one internal input channel
to measure on-chip temperature and two input channels intended for external thermistors.
An 18-bit ADC optimized for Coulomb Counting accumulates charge and discharge currents and
reports accumulated current with high resolution and accuracy. It can also be used to provide
instantaneous current measurements with 13-bit resolution. Integrated Cell Balancing FETs
allow cell balancing algorithms to be implemented in software.
The MCU provides the following features: 16K/32Kbytes of In-System Programmable Flash with
Read-While-Write capabilities, 512/1Kbytes EEPROM, 1K/2Kbytes SRAM. 32 general purpose
working registers, 12 general purpose I/O lines, five general purpose high voltage open drain I/O
lines, one general purpose super high voltage open drain output, debugWIRE for on-chip debugging
and SPI for In-system Programming, a SM-Bus compliant TWI module, two flexible
Timer/Counters with Input Capture and compare modes.
Internal and external interrupts, a 12-bit Sigma Delta ADC for voltage and temperature measurements,
a high resolution Sigma Delta ADC for Coulomb Counting and instantaneous current
measurements, integrated cell balancing FETs, Additional Secure Authentication Features, an
autonomous Battery Protection module, a programmable Watchdog Timer with internal Oscillator,
and software selectable power saving modes.
The AVR core combines a rich instruction set with 32 general purpose working registers. All the
32 registers are directly connected to the Arithmetic Logic Unit (ALU), allowing two independent
registers to be accessed in one single instruction executed in one clock cycle. The resulting
architecture is more code efficient while achieving throughputs up to ten times faster than conventional
CISC microcontrollers.
The device is manufactured using the Atmel high voltage high density non-volatile memory technology.
The On-chip ISP Flash allows the program memory to be reprogrammed In-System,
through an SPI serial interface, by a conventional non-volatile memory programmer or by an Onchip
Boot program running on the AVR core. The Boot program can use any interface to download
the application program in the Application Flash memory. Software in the Boot Flash
section will continue to run while the Application Flash section is updated, providing true ReadWhile-Write
operation. By combining an 8-bit RISC CPU with In-System Self-ProgrammableFlash
and highly accurate analog front-end in a monolithic chip.
The Atmel ATmega16HVB/32HVB is a powerful microcontroller that provides a highly flexible
and cost effective solution. It is part of the AVR Battery Management family that provides secure
authentication, highly accurate monitoring and autonomous protection for Lithium-ion battery
cells.
The ATmega16HVB/32HVB AVR is supported with a full suite of program and system development
tools including: C Compilers, Macro Assemblers, Program Debugger/Simulators, and Onchip
Debugger.
7
8042E–AVR–09/2013
ATmega16HVB/32HVB
2.1 Comparison between the Atmel ATmega16HVB and the Atmel ATmega32HVB
The ATmega16HVB and the ATmega32HVB differ only in memory size for flash, EEPROM and
internal SRAM. Table 2-1 summarizes the different configuration for the two devices.
Table 2-1. Configuration summary.
Device Flash EEPROM SRAM
ATmega16HVB 16K 512 1K
ATmega32HVB 32K 1K 2K
8
8042E–AVR–09/2013
ATmega16HVB/32HVB
3. Disclaimer
All parameters contained in this datasheet are preliminary and based on characterization of the
Atmel ATmega16/32HVB.
4. Resources
A comprehensive set of development tools, application notes and datasheets are available for
download on http://www.atmel.com/avr.
Note: 1.
5. About code examples
This documentation contains simple code examples that briefly show how to use various parts of
the device. These code examples assume that the part specific header file is included before
compilation. Be aware that not all C compiler vendors include bit definitions in the header files
and interrupt handling in C is compiler dependent. Please confirm with the C compiler documentation
for more details.
For I/O registers located in extended I/O map, “IN”, “OUT”, “SBIS”, “SBIC”, “CBI”, and “SBI”
instructions must be replaced with instructions that allow access to extended I/O. Typically
“LDS” and “STS” combined with “SBRS”, “SBRC”, “SBR”, and “CBR”.
6. Data retention
Reliability Qualification results show that the projected data retention failure rate is much less
than one PPM over 20 years at 85°C or 100 years at 25°C.
9
8042E–AVR–09/2013
ATmega16HVB/32HVB
7. AVR CPU core
7.1 Overview
This section discusses the Atmel AVR core architecture in general. The main function of the
CPU core is to ensure correct program execution. The CPU must therefore be able to access
memories, perform calculations, control peripherals, and handle interrupts.
Figure 7-1. Block diagram of the AVR architecture.
In order to maximize performance and parallelism, the AVR uses a Harvard architecture – with
separate memories and buses for program and data. Instructions in the program memory are
executed with a single level pipelining. While one instruction is being executed, the next instruction
is pre-fetched from the program memory. This concept enables instructions to be executed
in every clock cycle. The program memory is In-System Reprogrammable Flash memory.
The fast-access Register File contains 32 × 8-bit general purpose working registers with a single
clock cycle access time. This allows single-cycle Arithmetic Logic Unit (ALU) operation. In a typFlash
Program
Memory
Instruction
Register
Instruction
Decoder
Program
Counter
Control Lines
32 x 8
General
Purpose
Registrers
ALU
Status
and Control
I/O Lines
EEPROM
Data Bus 8-bit
Data
SRAM
Direct Addressing
Indirect Addressing
Interrupt
Unit
Watchdog
Timer
I/O Module 2
I/O Module1
I/O Module n
10
8042E–AVR–09/2013
ATmega16HVB/32HVB
ical ALU operation, two operands are output from the Register File, the operation is executed,
and the result is stored back in the Register File – in one clock cycle.
Six of the 32 registers can be used as three 16-bit indirect address register pointers for Data
Space addressing – enabling efficient address calculations. One of the these address pointers
can also be used as an address pointer for look up tables in Flash program memory. These
added function registers are the 16-bit X-register, Y-register, and Z-register, described later in
this section.
The ALU supports arithmetic and logic operations between registers or between a constant and
a register. Single register operations can also be executed in the ALU. After an arithmetic operation,
the Status Register is updated to reflect information about the result of the operation.
Program flow is provided by conditional and unconditional jump and call instructions, able to
directly address the whole address space. Most AVR instructions have a single 16-bit word format.
Every program memory address contains a 16-bit or 32-bit instruction.
During interrupts and subroutine calls, the return address Program Counter (PC) is stored on the
Stack. The Stack is effectively allocated in the general data SRAM, and consequently the Stack
size is only limited by the total SRAM size and the usage of the SRAM. All user programs must
initialize the SP in the Reset routine (before subroutines or interrupts are executed). The Stack
Pointer (SP) is read/write accessible in the I/O space. The data SRAM can easily be accessed
through the five different addressing modes supported in the AVR architecture.
The memory spaces in the AVR architecture are all linear and regular memory maps.
A flexible interrupt module has its control registers in the I/O space with an additional Global
Interrupt Enable bit in the Status Register. All interrupts have a separate Interrupt Vector in the
Interrupt Vector table. The interrupts have priority in accordance with their Interrupt Vector position.
The lower the Interrupt Vector address, the higher the priority.
The I/O memory space contains 64 addresses for CPU peripheral functions as Control Registers,
SPI, and other I/O functions. The I/O Memory can be accessed directly, or as the Data
Space locations following those of the Register File, 0x20 - 0x5F. In addition, the Atmel
ATmega16HVB/32HVB has Extended I/O space from 0x60 - 0xFF in SRAM where only the
ST/STS/STD and LD/LDS/LDD instructions can be used.
7.2 ALU – Arithmetic Logic Unit
The high-performance AVR ALU operates in direct connection with all the 32 general purpose
working registers. Within a single clock cycle, arithmetic operations between general purpose
registers or between a register and an immediate are executed. The ALU operations are divided
into three main categories – arithmetic, logical, and bit-functions. Some implementations of the
architecture also provide a powerful multiplier supporting both signed/unsigned multiplication
and fractional format. See ”Instruction set summary” on page 259 for a detailed description.
7.3 Status Register
The Status Register contains information about the result of the most recently executed arithmetic
instruction. This information can be used for altering program flow in order to perform
conditional operations. Note that the Status Register is updated after all ALU operations, as
specified in the Instruction Set Reference. This will in many cases remove the need for using the
dedicated compare instructions, resulting in faster and more compact code.
11
8042E–AVR–09/2013
ATmega16HVB/32HVB
The Status Register is not automatically stored when entering an interrupt routine and restored
when returning from an interrupt. This must be handled by software.
7.3.1 SREG – AVR Status Register
• Bit 7 – I: Global Interrupt Enable
The Global Interrupt Enable bit must be set for the interrupts to be enabled. The individual interrupt
enable control is then performed in separate control registers. If the Global Interrupt Enable
Register is cleared, none of the interrupts are enabled independent of the individual interrupt
enable settings. The I-bit is cleared by hardware after an interrupt has occurred, and is set by
the RETI instruction to enable subsequent interrupts. The I-bit can also be set and cleared by
the application with the SEI and CLI instructions, as described in the Instruction Set Reference.
• Bit 6 – T: Bit Copy Storage
The Bit Copy instructions BLD (Bit LoaD) and BST (Bit STore) use the T-bit as source or destination
for the operated bit. A bit from a register in the Register File can be copied into T by the
BST instruction, and a bit in T can be copied into a bit in a register in the Register File by the
BLD instruction.
• Bit 5 – H: Half Carry Flag
The Half Carry Flag H indicates a Half Carry in some arithmetic operations. Half Carry is useful
in BCD arithmetic. See the “Instruction Set Description” for detailed information.
• Bit 4 – S: Sign Bit, S = N V
The S-bit is always an exclusive or between the negative flag N and the Two’s Complement
Overflow Flag V. See the “Instruction Set Description” for detailed information.
• Bit 3 – V: Two’s Complement Overflow Flag
The Two’s Complement Overflow Flag V supports two’s complement arithmetics. See the
“Instruction Set Description” for detailed information.
• Bit 2 – N: Negative Flag
The Negative Flag N indicates a negative result in an arithmetic or logic operation. See the
“Instruction Set Description” for detailed information.
• Bit 1 – Z: Zero Flag
The Zero Flag Z indicates a zero result in an arithmetic or logic operation. See the “Instruction
Set Description” for detailed information.
• Bit 0 – C: Carry Flag
The Carry Flag C indicates a carry in an arithmetic or logic operation. See the “Instruction Set
Description” for detailed information.
Bit 7 6 5 4 3 2 1 0
0x3F (0x5F) I T H S V N Z C SREG
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
12
8042E–AVR–09/2013
ATmega16HVB/32HVB
7.4 General purpose Register File
The Register File is optimized for the AVR Enhanced RISC instruction set. In order to achieve
the required performance and flexibility, the following input/output schemes are supported by the
Register File:
• One 8-bit output operand and one 8-bit result input
• Two 8-bit output operands and one 8-bit result input
• Two 8-bit output operands and one 16-bit result input
• One 16-bit output operand and one 16-bit result input
Figure 7-2 shows the structure of the 32 general purpose working registers in the CPU.
Figure 7-2. AVR CPU General Purpose Working Registers.
Most of the instructions operating on the Register File have direct access to all registers, and
most of them are single cycle instructions.
As shown in Figure 7-2, each register is also assigned a data memory address, mapping them
directly into the first 32 locations of the user Data Space. Although not being physically implemented
as SRAM locations, this memory organization provides great flexibility in access of the
registers, as the X-pointer, Y-pointer and Z-pointer registers can be set to index any register in
the file.
7.4.1 The X-register, Y-register, and Z-register
The registers R26..R31 have some added functions to their general purpose usage. These registers
are 16-bit address pointers for indirect addressing of the data space. The three indirect
address registers X, Y, and Z are defined as described in Figure 7-3 on page 13.
7 0 Addr.
R0 0x00
R1 0x01
R2 0x02
…
R13 0x0D
General R14 0x0E
Purpose R15 0x0F
Working R16 0x10
Registers R17 0x11
…
R26 0x1A X-register Low Byte
R27 0x1B X-register High Byte
R28 0x1C Y-register Low Byte
R29 0x1D Y-register High Byte
R30 0x1E Z-register Low Byte
R31 0x1F Z-register High Byte
13
8042E–AVR–09/2013
ATmega16HVB/32HVB
Figure 7-3. The X-register, Y-register, and Z-registers.
In the different addressing modes these address registers have functions as fixed displacement,
automatic increment, and automatic decrement (see the Instruction Set Reference for details).
7.5 Stack Pointer
The Stack is mainly used for storing temporary data, for storing local variables and for storing
return addresses after interrupts and subroutine calls. The Stack Pointer Register always points
to the top of the Stack. Note that the Stack is implemented as growing from higher memory locations
to lower memory locations. This implies that a Stack PUSH command decreases the Stack
Pointer.
The Stack Pointer points to the data SRAM Stack area where the Subroutine and Interrupt
Stacks are located. This Stack space in the data SRAM must be defined by the program before
any subroutine calls are executed or interrupts are enabled. The Stack Pointer must be set to
point above 0x100. The Stack Pointer is decremented by one when data is pushed onto the
Stack with the PUSH instruction, and it is decremented by two when the return address is
pushed onto the Stack with subroutine call or interrupt. The Stack Pointer is incremented by one
when data is popped from the Stack with the POP instruction, and it is incremented by two when
data is popped from the Stack with return from subroutine RET or return from interrupt RETI.
The AVR Stack Pointer is implemented as two 8-bit registers in the I/O space. The number of
bits actually used is implementation dependent. Note that the data space in some implementations
of the AVR architecture is so small that only SPL is needed. In this case, the SPH Register
will not be present.
7.5.1 SPH and SPL – Stack Pointer High and Stack Pointer Low
15 XH XL 0
X-register 7 0 7 0
R27 (0x1B) R26 (0x1A)
15 YH YL 0
Y-register 7 0 7 0
R29 (0x1D) R28 (0x1C)
15 ZH ZL 0
Z-register 7 0 7 0
R31 (0x1F) R30 (0x1E)
Bit 15 14 13 12 11 10 9 8
0x3E (0x5E) SP15 SP14 SP13 SP12 SP11 SP10 SP9 SP8 SPH
0x3D (0x5D) SP7 SP6 SP5 SP4 SP3 SP2 SP1 SP0 SPL
76543210
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value RAMEND
RAMEND
RAMEND
RAMEND
RAMEND
RAMEND
RAMEND
RAMEND
RAMEND
RAMEND
RAMEND
RAMEND
RAMEND
RAMEND
RAMEND
RAMEND
14
8042E–AVR–09/2013
ATmega16HVB/32HVB
7.6 Instruction execution timing
This section describes the general access timing concepts for instruction execution. The Atmel
AVR CPU is driven by the CPU clock clkCPU, directly generated from the selected clock source
for the chip. No internal clock division is used.
Figure 7-4 shows the parallel instruction fetches and instruction executions enabled by the Harvard
architecture and the fast-access Register File concept. This is the basic pipelining concept
to obtain up to one MIPS per MHz with the corresponding unique results for functions per cost,
functions per clocks, and functions per power-unit.
Figure 7-4. The parallel instruction fetches and instruction executions.
Figure 7-5 shows the internal timing concept for the Register File. In a single clock cycle an ALU
operation using two register operands is executed, and the result is stored back to the destination
register.
Figure 7-5. Single cycle ALU pperation.
7.7 Reset and interrupt handling
The AVR provides several different interrupt sources. These interrupts and the separate Reset
Vector each have a separate program vector in the program memory space. All interrupts are
assigned individual enable bits which must be written logic one together with the Global Interrupt
Enable bit in the Status Register in order to enable the interrupt.
The lowest addresses in the program memory space are by default defined as the Reset and
Interrupt Vectors. The complete list of vectors is shown in ”Interrupts” on page 52. The list also
determines the priority levels of the different interrupts. The lower the address the higher is the
priority level. RESET has the highest priority.
clk
1st Instruction Fetch
1st Instruction Execute
2nd Instruction Fetch
2nd Instruction Execute
3rd Instruction Fetch
3rd Instruction Execute
4th Instruction Fetch
T1 T2 T3 T4
CPU
Total Execution Time
Register Operands Fetch
ALU Operation Execute
Result Write Back
T1 T2 T3 T4
clkCPU
15
8042E–AVR–09/2013
ATmega16HVB/32HVB
When an interrupt occurs, the Global Interrupt Enable I-bit is cleared and all interrupts are disabled.
The user software can write logic one to the I-bit to enable nested interrupts. All enabled
interrupts can then interrupt the current interrupt routine. The I-bit is automatically set when a
Return from Interrupt instruction – RETI – is executed.
There are basically two types of interrupts. The first type is triggered by an event that sets the
interrupt flag. For these interrupts, the Program Counter is vectored to the actual Interrupt Vector
in order to execute the interrupt handling routine, and hardware clears the corresponding interrupt
flag. Interrupt flags can also be cleared by writing a logic one to the flag bit position(s) to be
cleared. If an interrupt condition occurs while the corresponding interrupt enable bit is cleared,
the interrupt flag will be set and remembered until the interrupt is enabled, or the flag is cleared
by software. Similarly, if one or more interrupt conditions occur while the Global Interrupt Enable
bit is cleared, the corresponding interrupt flag(s) will be set and remembered until the Global
Interrupt Enable bit is set, and will then be executed by order of priority.
The second type of interrupts will trigger as long as the interrupt condition is present. These
interrupts do not necessarily have interrupt flags. If the interrupt condition disappears before the
interrupt is enabled, the interrupt will not be triggered.
When the AVR exits from an interrupt, it will always return to the main program and execute one
more instruction before any pending interrupt is served.
Note that the Status Register is not automatically stored when entering an interrupt routine, nor
restored when returning from an interrupt routine. This must be handled by software.
When using the CLI instruction to disable interrupts, the interrupts will be immediately disabled.
No interrupt will be executed after the CLI instruction, even if it occurs simultaneously with the
CLI instruction. The following example shows how this can be used to avoid interrupts during the
timed EEPROM write sequence.
Assembly code example
in r16, SREG ; store SREG value
cli ; disable interrupts during timed sequence
sbi EECR, EEMPE ; start EEPROM write
sbi EECR, EEPE
out SREG, r16 ; restore SREG value (I-bit)
C code example
char cSREG;
cSREG = SREG; /* store SREG value */
/* disable interrupts during timed sequence */
_CLI();
EECR |= (1< xxx
;
.org 0x4C02
0x4C02 jmp BPINT ; Battery Protection Interrupt Handler
0x4C04 jmp EXT_INT0 ; External Interrupt Request 0 Handler
... ... ... ;
0x4C2C jmp SPM_RDY ; Store Program Memory Ready Handler
When the BOOTRST Fuse is programmed and the Boot section size set to 4Kbytes, the most typical and general program
setup for the Reset and Interrupt Vector Addresses is:
Address Labels Code Comments
.org 0x0002
0x0002 jmp BPINT ; Battery Protection Interrupt Handler
0x0004 jmp EXT_INT0 ; External Interrupt Request 0 Handler
0x001C jmp TIM1_COMPB ; Timer1 Compare B Handler
0x001E jmp TIM1_OVF ; Timer1 Overflow Handler
0X0020 jmp TIM0_IC ; Timer0 Input Capture Handler
0x0022 jmp TIM0_COMPA ; Timer0 CompareA Handler
0x0024 jmp TIM0_COMPB ; Timer0 CompareB Handler
0x0026 jmp TIM0_OVF ; Timer0 Overflow Handler
0x0028 jmp TWI_BUS_CD ; Two-wire Bus Connect/Disconnect Handler
0x002A jmp TWI ; Two-wire Serial Interface Handler
0x002C jmp SPI, STC ; SPI, Serial Transfer Complete
0x002E jmp VADC ; Voltage ADC Conversion Complete Handler
0x0030 jmp CCADC_CONV ; CC-ADC Instantaneous Current Conversion Complete Handler
0x0032 jmp CCADC_REC_CUR ; CC-ADC Regular Current Handler
0x0034 jmp CCADC_ACC ; CC-ADC Accumulate Current Conversion Complete Handler
0x0036 jmp EE_RDY ; EEPROM Ready Handler
0x0038 jmp SPM ; Store Program Memory Ready Handler
;
0x003A RESET: ldi r16, high(RAMEND) ; Main program start
0x003B out SPH,r16 ; Set Stack Pointer to top of RAM
0x003C ldi r16, low(RAMEND)
0x003D out SPL,r16
0x003E sei ; Enable interrupts
0x003F xxx
0x0040 ... ... ...
;
55
8042E–AVR–09/2013
ATmega16HVB/32HVB
... ... ... ;
0x002C jmp SPM_RDY ; Store Program Memory Ready Handler
;
.org 0x4C00
0x4C00 RESET: ldi r16,high(RAMEND); Main program start
0x4C01 out SPH,r16 ; Set Stack Pointer to top of RAM
0x4C02 ldi r16,low(RAMEND)
0x4C03 out SPL,r16
0x4C04 sei ; Enable interrupts
0x4C05 xxx
When the BOOTRST Fuse is programmed, the Boot section size set to 4Kbytes and the IVSEL bit in the MCUCR Register
is set before any interrupts are enabled, the most typical and general program setup for the Reset and Interrupt Vector
Addresses is:
Address Labels Code Comments
;
.org 0x4C00
0x4C00 jmp RESET ; Reset handler
0x4C02 jmp BPINT ; Battery Protection Interrupt Handler
0x4C04 jmp EXT_INT0 ; External Interrupt Request 0 Handler
... ... ... ;
0x4C2C jmp SPM_RDY ; Store Program Memory Ready Handler
;
0x4C2E RESET: ldi r16,high(RAMEND); Main program start
0x4C2F out SPH,r16 ; Set Stack Pointer to top of RAM
0x4C30 ldi r16,low(RAMEND)
0x4C31 out SPL,r16
0x4C32 sei ; Enable interrupts
0x4C33 xxx
56
8042E–AVR–09/2013
ATmega16HVB/32HVB
12.3 Moving interrupts between application and boot space
The General Interrupt Control Register controls the placement of the Interrupt Vector table.
12.4 Register description
12.4.1 MCUCR – MCU Control Register
• Bit 1 – IVSEL: Interrupt Vector Select
When the IVSEL bit is cleared (zero), the Interrupt Vectors are placed at the start of the Flash
memory. When this bit is set (one), the Interrupt Vectors are moved to the beginning of the Boot
Loader section of the Flash. The actual address of the start of the Boot Flash Section is determined
by the BOOTSZ Fuses. Refer to the section ”Boot loader support – Read-while-write selfprogramming”
on page 188 for details. To avoid unintentional changes of Interrupt Vector tables,
a special write procedure must be followed to change the IVSEL bit:
a. Write the Interrupt Vector Change Enable (IVCE) bit to one.
b. Within four cycles, write the desired value to IVSEL while writing a zero to IVCE.
Interrupts will automatically be disabled while this sequence is executed. Interrupts are disabled
in the cycle IVCE is set, and they remain disabled until after the instruction following the write to
IVSEL. If IVSEL is not written, interrupts remain disabled for four cycles. The I-bit in the Status
Register is unaffected by the automatic disabling.
Note: If Interrupt Vectors are placed in the Boot Loader section and Boot Lock bit BLB02 is programmed,
interrupts are disabled while executing from the Application section. If Interrupt Vectors
are placed in the Application section and Boot Lock bit BLB12 is programed, interrupts are disAssembly
code example
Move_interrupts:
; Enable change of Interrupt Vectors
ldi r16, (1< CSn2:0 > 1). The number of system clock
cycles from when the timer is enabled to the first count occurs can be from 1 to N+1 system
clock cycles, where N equals the prescaler divisor (8, 64, 256, or 1024).
It is possible to use the prescaler reset for synchronizing the Timer/Counter to program execution.
However, care must be taken if the other Timer/Counter that shares the same prescaler
also uses prescaling. A prescaler reset will affect the prescaler period for all Timer/Counters it is
connected to.
Figure 16-1. Prescaler for timer/counter.
PSRSYNC
Clear
clkTn
Tn
clkI/O
Synchronization
CSn0
CSn1
CSn2
n
80
8042E–AVR–09/2013
ATmega16HVB/32HVB
16.2 External clock source
An external clock source applied to the Tn pin can be used as Timer/Counter clock (clkTn). The
Tn pin is sampled once every system clock cycle by the pin synchronization logic. The synchronized
(sampled) signal is then passed through the edge detector. Figure 16-2 shows a functional
equivalent block diagram of the Tn synchronization and edge detector logic. The registers are
clocked at the positive edge of the internal system clock (clkI/O). The latch is transparent in the
high period of the internal system clock.
The edge detector generates one clkTn pulse for each positive (CSn2:0 = 7) or negative (CSn2:0
= 6) edge it detects. See Table 16-1 on page 81 for details.
Figure 16-2. Tn pin sampling.
The synchronization and edge detector logic introduces a delay of 2.5 to 3.5 system clock cycles
from an edge has been applied to the Tn pin to the counter is updated.
Enabling and disabling of the clock input must be done when Tn has been stable for at least one
system clock cycle, otherwise it is a risk that a false Timer/Counter clock pulse is generated.
Each half period of the external clock applied must be longer than one system clock cycle to
ensure correct sampling. The external clock must be guaranteed to have less than half the system
clock frequency (fExtClk < fclk_I/O/2) given a 50/50% duty cycle. Since the edge detector uses
sampling, the maximum frequency of an external clock it can detect is half the sampling frequency
(Nyquist sampling theorem). However, due to variation of the system clock frequency
and duty cycle caused by Oscillator source (crystal, resonator, and capacitors) tolerances, it is
recommended that maximum frequency of an external clock source is less than fclk_I/O/2.5.
An external clock source can not be prescaled.
Note: The synchronization logic on the input pins (Tn) is shown in Figure 16-2.
Tn_sync
(To Clock
Select Logic)
Synchronization Edge Detector
D Q D Q
LE
Tn D Q
clkI/O
81
8042E–AVR–09/2013
ATmega16HVB/32HVB
16.3 Register description
16.3.1 TCCRnB – Timer/Counter n Control Register B
• Bits 2, 1, 0 – CSn2, CSn1, CSn0: Clock Select0, Bit 2, 1, and 0
The Clock Select n bits 2, 1, and 0 define the prescaling source of Timer n.
If external pin modes are used for the Timer/Counter n, transitions on the Tn pin will clock the
counter even if the pin is configured as an output. This feature allows software control of the
counting.
16.3.2 General Timer/Counter Control Register – GTCCR
• Bit 7 – TSM: Timer/Counter Synchronization Mode
Writing the TSM bit to one activates the Timer/Counter Synchronization mode. In this mode, the
value that is written to the PSRSYNC bit is kept, hence keeping the corresponding prescaler
reset signals asserted. This ensures that the corresponding Timer/Counters are halted and can
be configured to the same value without the risk of one of them advancing during configuration.
When the TSM bit is written to zero the PSRSYNC bit is cleared by hardware, and the
Timer/Counters start counting simultaneously.
• Bit 0 – PSRSYNC: Prescaler Reset
When this bit is one, Timer/Counter1 and Timer/Counter0 prescaler will be Reset. This bit is normally
cleared immediately by hardware, except if the TSM bit is set. Note that Timer/Counter1
and Timer/Counter0 share the same prescaler and a reset of this prescaler will affect both
timers.
Bit 7 6 5 4 3 2 1 0
(0x80)(0x81) – – – – – CSn2 CSn1 CSn0 TCCRnB
Read/Write R R R R R R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
Table 16-1. Clock Select Bit description.
CSn2 CSn1 CSn0 Description
0 0 0 No clock source (Timer/Counter stopped)
0 0 1 clkI/O/(No prescaling)
0 1 0 clkI/O/8 (From prescaler)
0 1 1 clkI/O/64 (From prescaler)
1 0 0 clkI/O/256 (From prescaler)
1 0 1 clkI/O/1024 (From prescaler)
1 1 0 External clock source on Tn pin. Clock on falling edge
1 1 1 External clock source on Tn pin. Clock on rising edge
Bit 7 6 5 4 3 2 1 0
0x23 (0x43) TSM – – – – – – PSRSYNC GTCCR
Read/Write R/W R R R R R R R/W
Initial Value 0 0 0 0 0 0 0 0
82
8042E–AVR–09/2013
ATmega16HVB/32HVB
17. Timer/Counter (T/C0,T/C1)
17.1 Features
• Clear timer on compare match (auto reload)
• Input capture unit
• Four independent interrupt sources (TOVn, OCFnA, OCFnB, ICFn)
• 8-bit mode with two independent output compare units
• 16-bit mode with one independent output compare unit
17.2 Overview
Timer/Counter n is a general purpose 8-bit/16-bit Timer/Counter module, with two/one Output
Compare units and Input Capture feature.
The Atmel ATmega16HVB/32HVB has two Timer/Counters, Timer/Counter0 and
Timer/Counter1. The functionality for both Timer/Counters is described below. Timer/Counter0
and Timer/Counter1 have different Timer/Counter registers, as shown in ”Register summary” on
page 255.
The Timer/Counter general operation is described in 8-bit/16-bit mode. A simplified block diagram
of the 8-bit/16-bit Timer/Counter is shown in Figure 17-1. CPU accessible I/O Registers,
including I/O bits and I/O pins, are shown in bold. The device-specific I/O Register and bit locations
are listed in the ”Register description” on page 94.
Figure 17-1. 8-bit/16-bit timer/counter block diagram.
17.2.1 Registers
The Timer/Counter Low Byte Register (TCNTnL) and Output Compare Registers (OCRnA and
OCRnB) are 8-bit registers. Interrupt request (abbreviated to Int.Req. in Figure 17-1) signals are
all visible in the Timer Interrupt Flag Register (TIFR). All interrupts are individually masked with
the Timer Interrupt Mask Register (TIMSK). TIFR and TIMSK are not shown in the figure.
In 16-bit mode the Timer/Counter consists one more 8-bit register, the Timer/Counter High Byte
Register (TCNTnH). Furthermore, there is only one Output Compare Unit in 16-bit mode as the
two Output Compare Registers, OCRnA and OCRnB, are combined to one 16-bit Output ComClock
Select
Timer/Counter
DATA BUS
OCRnB
=
TCNTnL
Noise
Canceler
ICPn0
=
Edge
Detector
Control Logic
TOP
Count
Clear
TOVn (Int. Req.)
OCnA (Int. Req.)
OCnB (Int. Req.)
ICFn (Int. Req.)
TCCRnA TCCRnB
Tn Edge
Detector
( From Prescaler )
clkTn
=
OCRnA
TCNTnH
Fixed TOP value
ICPn1
83
8042E–AVR–09/2013
ATmega16HVB/32HVB
pare Register. OCRnA contains the low byte of the word and OCRnB contains the higher byte of
the word. When accessing 16-bit registers, special procedures described in section ”Accessing
registers in 16-bit mode” on page 90 must be followed.
The Timer/Counter can be clocked internally, via the prescaler, or by an external clock source on
the Tn pin. The Clock Select logic block controls which clock source and edge the Timer/Counter
uses to increment its value. The Timer/Counter is inactive when no clock source is selected. The
output from the Clock Select logic is referred to as the timer clock (clkTn).
17.2.2 Definitions
Many register and bit references in this section are written in general form. A lower case “n”
replaces the module number, for example Timer/Counter number. A lower case “x” replaces the
unit, for example OCRnx and ICPnx describes OCRnA/B and ICP1/0x . However, when using
the register or bit defines in a program, the precise form must be used, that is, TCNT0L for
accessing Timer/Counter0 counter value and so on.
The definitions in Table 17-1 are also used extensively throughout the document.
17.3 Timer/Counter clock sources
The Timer/Counter can be clocked internally, via the prescaler, or by an external clock source.
The Clock Select logic is controlled by the Clock Select (CSn2:0) bits located in the Timer/Counter
Control Register n B (TCCRnB), and controls which clock source and edge the
Timer/Counter uses to increment its value. The Timer/Counter is inactive when no clock source
is selected. The output from the Clock Select logic is referred to as the timer clock (clkTn). For
details on clock sources and prescaler, see ”Timer/Counter0 and Timer/Counter1 prescalers” on
page 79.
17.4 Counter unit
The main part of the 8-bit Timer/Counter is the counter unit. Figure 17-2 shows a block diagram
of the counter and its surroundings.
Figure 17-2. Counter unit block diagram.
Table 17-1. Definitions.
BOTTOM The counter reaches the BOTTOM when it becomes 0
MAX The counter reaches its MAXimum when it becomes 0xFF (decimal 255) in 8-bit mode or
0xFFFF (decimal 65535) in 16-bit mode
TOP
The counter reaches the TOP when it becomes equal to the highest value in the count
sequence. The TOP value can be assigned to be the fixed value 0xFF/0xFFFF (MAX) or
the value stored in the OCRnA Register
DATA BUS
TCNTn Control Logic count
TOVn
(Int.Req.)
Clock Select
top
Tn Edge
Detector
( From Prescaler )
clkTn
84
8042E–AVR–09/2013
ATmega16HVB/32HVB
Signal description (internal signals):
count Increment or decrement TCNTn by one
clkTn Timer/Counter clock, referred to as clkTn in the following
top Signalize that TCNTn has reached maximum value
The counter is incremented at each timer clock (clkTn) until it passes its TOP value and then
restarts from BOTTOM. The counting sequence is determined by the setting of the WGMn0 bits
located in the Timer/Counter Control Register (TCCRnA). For more details about counting
sequences, see ”Timer/counter timing diagrams” on page 89. clkTn can be generated from an
external or internal clock source, selected by the Clock Select bits (CSn2:0). When no clock
source is selected (CSn2:0 = 0) the timer is stopped. However, the TCNTn value can be
accessed by the CPU, regardless of whether clkTn is present or not. A CPU write overrides (has
priority over) all counter clear or count operations. The Timer/Counter Overflow Flag (TOVn) is
set when the counter reaches the maximum value and it can be used for generating a CPU
interrupt.
17.5 Modes of operation
The mode of operation is defined by the Timer/Counter Width (TCWn), Input Capture Enable
(ICENn) and the Waveform Generation Mode (WGMn0) bits in ”TCCRnA – Timer/Counter n
Control Register A” on page 94. Table 17-2 shows the different Modes of Operation.
17.5.1 Normal 8-bit mode
In the normal mode, the counter (TCNTnL) is incrementing until it overruns when it passes its
maximum 8-bit value (MAX = 0xFF) and then restarts from the bottom (0x00), see Table 17-2 for
bit settings. The Overflow Flag (TOVn) will be set in the same timer clock cycle as the TCNTnL
becomes zero. The TOVn Flag in this case behaves like a ninth bit, except that it is only set, not
cleared. However, combined with the timer overflow interrupt that automatically clears the TOVn
Flag, the timer resolution can be increased by software. There are no special cases to consider
in the Normal 8-bit mode, a new counter value can be written anytime. The Output Compare Unit
can be used to generate interrupts at some given time.
17.5.2 Clear timer on Compare Match (CTC) 8-bit mode
In Clear Timer on Compare or CTC mode, the OCRnA Register is used to manipulate the counter
resolution, see Table 17-2 for bit settings. In CTC mode the counter is cleared to zero when
Table 17-2. Modes of operation.
Mode ICENn TCWn WGMn0
Timer/counter mode
of operation TOP
Update of
OCRx at TOV flag set on
0 0 0 0 Normal 8-bit Mode 0xFF Immediate MAX (0xFF)
1 0 0 1 8-bit CTC OCRnA Immediate MAX (0xFF)
2 0 1 0 16-bit Mode 0xFFFF Immediate MAX (0xFFFF)
3 0 1 1 16-bit CTC OCRnB,
OCRnA Immediate MAX (0xFFFF)
410 0 8-bit Input Capture
mode 0xFF – MAX (0xFF)
511 0 16-bit Input Capture
mode 0xFFFF – MAX (0xFFFF)
85
8042E–AVR–09/2013
ATmega16HVB/32HVB
the counter value (TCNTn) matches the OCRnA. The OCRnA defines the top value for the counter,
hence also its resolution. This mode allows greater control of the Compare Match output
frequency. It also simplifies the operation of counting external events.
The timing diagram for the CTC mode is shown in Figure 17-3. The counter value (TCNTn)
increases until a Compare Match occurs between TCNTn and OCRnA, and then counter
(TCNTn) is cleared.
Figure 17-3. CTC Mode, timing diagram.
An interrupt can be generated each time the counter value reaches the TOP value by using the
OCFnA Flag. If the interrupt is enabled, the interrupt handler routine can be used for updating
the TOP value. However, changing TOP to a value close to BOTTOM when the counter is running
with none or a low prescaler value must be done with care since the CTC mode does not
have the double buffering feature. If the new value written to OCRnA is lower than the current
value of TCNTn, the counter will miss the Compare Match. The counter will then have to count to
its maximum value (0xFF) and wrap around starting at 0x00 before the Compare Match can
occur. As for the Normal mode of operation, the TOVn Flag is set in the same timer clock cycle
that the counter counts from MAX to 0x00.
17.5.3 16-bit mode
In 16-bit mode, the counter (TCNTnH/L) is a incrementing until it overruns when it passes its
maximum 16-bit value (MAX = 0xFFFF) and then restarts from the bottom (0x0000), see Table
17-2 on page 84 for bit settings. The Overflow Flag (TOVn) will be set in the same timer clock
cycle as the TCNTnH/L becomes zero. The TOVn Flag in this case behaves like a 17th bit,
except that it is only set, not cleared. However, combined with the timer overflow interrupt that
automatically clears the TOVn Flag, the timer resolution can be increased by software. There
are no special cases to consider in the Normal mode, a new counter value can be written anytime.
The Output Compare Unit can be used to generate interrupts at some given time.
17.5.4 Clear timer on Compare Match (CTC) 16-bit mode
In Clear Timer on Compare 16-bit mode, OCRAnA/B Registers are used to manipulate the counter
resolution, see Table 17-2 on page 84 for bit settings. In CTC mode the counter is cleared to
zero when the counter value (TCNTn) matches OCRnA/B, where OCRnB represents the eight
most significant bits and OCRnA represents the eight least significant bits. OCRnA/B defines the
top value of the counter, hence also its resolution. This mode allows greater control of the Compare
Match output frequency. It also simplifies the operation of counting external events.
An interrupt can be generated each time the counter reaches the TOP value by using the
OCFnA flag. If the interrupt is enabled, the interrupt handler routine can be used for updating the
TOP value. However, changing the TOP to a value close the BOTTOM when the counter is running
with none or a low prescaler value must be done with care since the CTC mode does not
have the double buffering feature. If the new value written to OCRnA/B is lower than the current
TCNTn
OCnx Interrupt Flag Set
Period 1 2 3 4
86
8042E–AVR–09/2013
ATmega16HVB/32HVB
value of TCNTn, the counter will miss the Compare Match. The counter will then have to count to
its maximum value (0xFFFF) and wrap around starting at 0x0000 before Compare Match can
occur. As for the 16-bit Mode, the TOVn Flag is set in the same timer clock cycle that the counter
counts from MAX to 0x0000.
17.5.5 8-bit Input capture mode
The Timer/Counter can be used in a 8-bit Input Capture mode, see Table 17-2 on page 84 for bit
settings. For full description, see “Input capture unit” .
17.5.6 16-bit input capture mode
The Timer/Counter can also be used in a 16-bit Input Capture mode, see Table 17-2 on page 84
for bit settings. For full description, see “Input capture unit” .
17.6 Input capture unit
The Timer/Counter incorporates an Input Capture unit that can capture external events and give
them a time-stamp indicating time of occurrence. The external signal indicates an event, or multiple
events. For Timer/Counter0, the events can be applied via the PB0 pin (ICP00), or
alternatively via the osi_posedge pin on the Oscillator Sampling Interface (ICP01). For
Timer/Counter1, the events can be applied by the Battery Protection Interrupt (ICP10) or alternatively
by the Voltage Regulator Interrupt (ICP11). The time-stamps can then be used to
calculate frequency, duty-cycle, and other features of the signal applied. Alternatively the timestamps
can be used for creating a log of the events.
The Input Capture unit is illustrated by the block diagram shown in Figure 17-4. The elements of
the block diagram that are not directly a part of the Input Capture unit are gray shaded.
Figure 17-4. Input Capture Unit block diagram.
The Output Compare Register OCRnA is a dual-purpose register that is also used as an 8-bit
Input Capture Register ICRn. In 16-bit Input Capture mode the Output Compare Register
OCRnB serves as the high byte of the Input Capture Register ICRn. In 8-bit Input Capture mode
the Output Compare Register OCRnB is free to be used as a normal Output Compare Register,
but in 16-bit Input Capture mode the Output Compare Unit cannot be used as there are no free
Output Compare Register(s). Even though the Input Capture register is called ICRn in this secICFn
(Int.Req.)
WRITE ICRn (16-bit Register)
OCRnB (8-bit)
Noise
Canceler
ICPn0
Edge
Detector
TEMP (8-bit)
DATA BUS (8-bit)
OCRnA (8-bit)
TCNTn (16-bit Counter)
TCNTnH (8-bit) TCNTnL (8-bit)
ICNCn ICESn
ICPn1
ICSn
87
8042E–AVR–09/2013
ATmega16HVB/32HVB
tion, it is referring to the Output Compare Register(s). For more information on how to access
the 16-bit registers refer to ”Accessing registers in 16-bit mode” on page 90.
When a change of the logic level (an event) occurs on the Input Capture pin (ICPx), and this
change confirms to the setting of the edge detector, a capture will be triggered. When a capture
is triggered, the value of the counter (TCNTn) is written to the Input Capture Register (ICRn).
The Input Capture Flag (ICFn) is set at the same system clock as the TCNTn value is copied into
Input Capture Register. If enabled (TICIEn=1), the Input Capture Flag generates an Input Capture
interrupt. The ICFn flag is automatically cleared when the interrupt is executed. Alternatively
the ICFn flag can be cleared by software by writing a logical one to its I/O bit location.
17.6.1 Input Capture trigger source
The default trigger source for the Input Capture unit is the I/O port PB0 in Timer/Counter0 and
the Battery Protection Interrupt in Timer/Counter1. Alternatively can the osi_posedge pin on the
Oscillator Sampling Interface in Timer/Counter0 and Voltage Regulator Interrupt in
Timer/Counter1 be used as trigger sources. The osi_posedge pin in Timer/Counter0 Control
Register A (TCCR0A) and the Voltage Regulator Interrupt bit in the Timer/Counter1 Control
Register A (TCCR1A) is selected as trigger sources by setting the Input Capture Select (ICS0/1)
bit. Be aware that changing trigger source can trigger a capture. The Input Capture Flag must
therefore be cleared after the change.
Both Input Capture inputs are sampled using the same technique. The edge detector is also
identical. However, when the noise canceler is enabled, additional logic is inserted before the
edge detector, which increases the delay by four system clock cycles. An Input Capture on
Timer/Counter0 can also be triggered by software by controlling the port of the PB0 pin.
17.6.2 Noise canceler
The noise canceler improves noise immunity by using a simple digital filtering scheme. The
noise canceler input is monitored over four samples, and all four must be equal for changing the
output that in turn is used by the edge detector.
The noise canceler is enabled by setting the Input Capture Noise Canceler (ICNCn) bit in
Timer/Counter Control Register n B (TCCRnB). When enabled the noise canceler introduces
additional four system clock cycles of delay from a change applied to the input, to the update of
the ICRn Register. The noise canceler uses the system clock and is therefore not affected by the
prescaler.
17.6.3 Using the Input Capture unit
The main challenge when using the Input Capture unit is to assign enough processor capacity
for handling the incoming events. The time between two events is critical. If the processor has
not read the captured value in the ICRn Register before the next event occurs, the ICRn will be
overwritten with a new value. In this case the result of the capture will be incorrect.
When using the Input Capture interrupt, the ICRn Register should be read as early in the interrupt
handler routine as possible. The maximum interrupt response time is dependent on the
maximum number of clock cycles it takes to handle any of the other interrupt requests.
Measurement of an external signal duty cycle requires that the trigger edge is changed after
each capture. Changing the edge sensing must be done as early as possible after the ICRn
Register has been read. After a change of the edge, the Input Capture Flag (ICFn) must be
cleared by software (writing a logical one to the I/O bit location). For measuring frequency only,
the trigger edge change is not required.
88
8042E–AVR–09/2013
ATmega16HVB/32HVB
Note: 1. See ”OSI – Oscillator sampling interface” on page 29 for details.
2. The noise canceler cannot be used with this source.
Note: 1. The noise canceller will filter out the input capture and it is therefore not recommended to use
noise canceler with these sources.
17.7 Output compare unit
The comparator continuously compares the Timer/Counter (TCNTn) with the Output Compare
Registers (OCRnA and OCRnB), and whenever the Timer/Counter equals to the Output Compare
Registers, the comparator signals a match. A match will set the Output Compare Flag at
the next timer clock cycle. In 8-bit mode the match can set either the Output Compare Flag
OCFnA or OCFnB, but in 16-bit mode the match can set only the Output Compare Flag OCFnA
as there is only one Output Compare Unit. If the corresponding interrupt is enabled, the Output
Compare Flag generates an Output Compare interrupt. The Output Compare Flag is automatically
cleared when the interrupt is executed. Alternatively, the flag can be cleared by software by
writing a logical one to its I/O bit location. Figure 17-5 shows a block diagram of the Output Compare
unit.
Figure 17-5. Output Compare Unit, block diagram.
17.7.1 Compare Match Blocking by TCNT0 write
All CPU write operations to the TCNTnH/L Register will block any Compare Match that occur in
the next timer clock cycle, even when the timer is stopped. This feature allows OCRnA/B to be
initialized to the same value as TCNTn without triggering an interrupt when the Timer/Counter
clock is enabled.
Table 17-3. Timer/Counter0 Input Capture Source (ICS).
ICS0 Source
0 ICP00: Port PB0
1 ICP01: osi_posedge pin from OSI module (1)(2)
Table 17-4. Timer/Counter1 Input Capture Source (ICS).
ICS1 Source
0 ICP10: Battery Protection Interrupt (1)
1 ICP11: Voltage Regulator Interrupt (1)
OCFnx (Int.Req.)
= (8/16-bit Comparator )
OCRnx
DATA BUS
TCNTn
89
8042E–AVR–09/2013
ATmega16HVB/32HVB
17.7.2 Using the Output Compare Unit
Since writing TCNTnH/L will block all Compare Matches for one timer clock cycle, there are risks
involved when changing TCNTnH/L when using the Output Compare Unit, independently of
whether the Timer/Counter is running or not. If the value written to TCNTnH/L equals the
OCRnA/B value, the Compare Match will be missed.
17.8 Timer/counter timing diagrams
The Timer/Counter is a synchronous design and the timer clock (clkTn) is therefore shown as a
clock enable signal in the following figures. The figures include information on when Interrupt
Flags are set. Figure 17-6 contains timing data for basic Timer/Counter operation. The figure
shows the count sequence close to the MAX value.
Figure 17-6. Timer/counter timing diagram, no prescaling.
Figure 17-7 shows the same timing data, but with the prescaler enabled.
Figure 17-7. Timer/counter timing diagram, with prescaler (fclk_I/O/8).
Figure 17-8 shows the setting of OCFnA and OCFnB in Normal mode.
Figure 17-8. Timer/counter timing diagram, setting of OCFnx, with prescaler (fclk_I/O/8).
clkTn
(clkI/O/1)
TOVn
clkI/O
TCNTn MAX - 1 MAX BOTTOM BOTTOM + 1
TOVn
TCNTn MAX - 1 MAX BOTTOM BOTTOM + 1
clkI/O
clkTn
(clkI/O/8)
OCFnx
OCRnx
TCNTn
OCRnx Value
OCRnx - 1 OCRnx OCRnx + 1 OCRnx + 2
clkI/O
clkTn
(clkI/O/8)
90
8042E–AVR–09/2013
ATmega16HVB/32HVB
Figure 17-9 shows the setting of OCFnA and the clearing of TCNTn in CTC mode.
Figure 17-9. Timer/counter timing diagram, CTC mode, with prescaler (fclk_I/O/8).
17.9 Accessing registers in 16-bit mode
In 16-bit mode (the TCWn bit is set to one) the TCNTnH/L and OCRnA/B or TCNTnL/H and
OCRnB/A are 16-bit registers that can be accessed by the AVR CPU via the 8-bit data bus. The
16-bit register must be byte accessed using two read or write operations. The 16-bit
Timer/Counter has a single 8-bit register for temporary storing of the high byte of the 16-bit
access. The same temporary register is shared between all 16-bit registers. Accessing the low
byte triggers the 16-bit read or write operation. When the low byte of a 16-bit register is written
by the CPU, the high byte stored in the temporary register, and the low byte written are both copied
into the 16-bit register in the same clock cycle. When the low byte of a 16-bit register is read
by the CPU, the high byte of the 16-bit register is copied into the temporary register in the same
clock cycle as the low byte is read.
There is one exception in the temporary register usage. In the Output Compare mode the 16-bit
Output Compare Register OCRnA/B is read without the temporary register, because the Output
Compare Register contains a fixed value that is only changed by CPU access. However, in 16-
bit Input Capture mode the ICRn register formed by the OCRnA and OCRnB registers must be
accessed with the temporary register.
To do a 16-bit write, the high byte must be written before the low byte. For a 16-bit read, the low
byte must be read before the high byte.
OCFnx
OCRnx
TCNTn
(CTC)
TOP
TOP - 1 TOP BOTTOM BOTTOM + 1
clkPCK
clkTn
(clkPCK /8)
91
8042E–AVR–09/2013
ATmega16HVB/32HVB
The following code examples show how to access the 16-bit timer registers assuming that no
interrupts updates the temporary register. The same principle can be used directly for accessing
the OCRnA/B registers.
Note: 1. See ”About code examples” on page 8.
The assembly code example returns the TCNTnH/L value in the r17:r16 register pair.
It is important to notice that accessing 16-bit registers are atomic operations. If an interrupt
occurs between the two instructions accessing the 16-bit register, and the interrupt code
updates the temporary register by accessing the same or any other of the 16-bit timer registers,
then the result of the access outside the interrupt will be corrupted. Therefore, when both the
main code and the interrupt code update the temporary register, the main code must disable the
interrupts during the 16-bit access.
Assembly code example
...
; Set TCNTn to 0x01FF
ldi r17,0x01
ldi r16,0xFF
out TCNTnH,r17
out TCNTnL,r16
; Read TCNTn into r17:r16
in r16,TCNTnL
in r17,TCNTnH
...
C code example
unsigned int i;
...
/* Set TCNTn to 0x01FF */
TCNTn = 0x1FF;
/* Read TCNTn into i */
i = TCNTn;
...
92
8042E–AVR–09/2013
ATmega16HVB/32HVB
The following code examples show how to do an atomic read of the TCNTn register contents.
Reading any of the OCRn register can be done by using the same principle.
Note: 1. See ”About code examples” on page 8.
The assembly code example returns the TCNTnH/L value in the r17:r16 register pair.
Assembly code example
TIMn_ReadTCNTn:
; Save global interrupt flag
in r18,SREG
; Disable interrupts
cli
; Read TCNTn into r17:r16
in r16,TCNTnL
in r17,TCNTnH
; Restore global interrupt flag
out SREG,r18
ret
C code example
unsigned int TIMn_ReadTCNTn( void )
{
unsigned char sreg;
unsigned int i;
/* Save global interrupt flag */
sreg = SREG;
/* Disable interrupts */
_CLI();
/* Read TCNTn into i */
i = TCNTn;
/* Restore global interrupt flag */
SREG = sreg;
return i;
}
93
8042E–AVR–09/2013
ATmega16HVB/32HVB
The following code examples show how to do an atomic write of the TCNTnH/L register contents.
Writing any of the OCRnA/B registers can be done by using the same principle.
Note: 1. See ”About code examples” on page 8.
The assembly code example requires that the r17:r16 register pair contains the value to be written
to TCNTnH/L.
17.9.1 Reusing the temporary high byte register
If writing to more than one 16-bit register where the high byte is the same for all registers written,
then the high byte only needs to be written once. However, note that the same rule of atomic
operation described previously also applies in this case.
Assembly code example
TIMn_WriteTCNTn:
; Save global interrupt flag
in r18,SREG
; Disable interrupts
cli
; Set TCNTn to r17:r16
out TCNTnH,r17
out TCNTnL,r16
; Restore global interrupt flag
out SREG,r18
ret
C code example
void TIMn_WriteTCNTn( unsigned int i )
{
unsigned char sreg;
unsigned int i;
/* Save global interrupt flag */
sreg = SREG;
/* Disable interrupts */
_CLI();
/* Set TCNTn to i */
TCNTn = i;
/* Restore global interrupt flag */
SREG = sreg;
}
94
8042E–AVR–09/2013
ATmega16HVB/32HVB
17.10 Register description
17.10.1 TCCRnA – Timer/Counter n Control Register A
• Bit 7 – TCWn: Timer/Counter Width
When this bit is written to one 16-bit mode is selected. Timer/Counter n width is set to 16-bits
and the Output Compare Registers OCRnA and OCRnB are combined to form one 16-bit Output
Compare Register. Because the 16-bit registers TCNTnH/L and OCRnB/A are accessed by the
AVR CPU via the 8-bit data bus, special procedures must be followed. These procedures are
described in section ”Accessing registers in 16-bit mode” on page 90.
• Bit 6 – ICENn: Input Capture Mode Enable
The Input Capture Mode is enabled when this bit is written to one.
• Bit 5 – ICNCn: Input Capture Noise Canceler
Setting this bit activates the Input Capture Noise Canceler. When the noise canceler is activated,
the input from the Input Capture Source is filtered. The filter function requires four
successive equal valued samples of the Input Capture Source for changing its output. The Input
Capture is therefore delayed by four System Clock cycles when the noise canceler is enabled.
• Bit 4 – ICESn: Input Capture Edge Select
This bit selects which edge on the Input Capture Source that is used to trigger a capture event.
When the ICESn bit is written to zero, a falling (negative) edge is used as trigger, and when the
ICESn bit is written to one, a rising (positive) edge will trigger the capture. When a capture is triggered
according to the ICESn setting, the counter value is copied into the Input Capture
Register. The event will also set the Input Capture Flag (ICFn), and this can be used to cause an
Input Capture Interrupt, if this interrupt is enabled.
• Bit 3 – ICSn: Input Capture Select
When written logic one, this bit enables the input capture function in Timer/Counter n to be triggered
by the alternative Input Capture Source. To make the comparator trigger the
Timer/Counter n Input Capture interrupt, the TICIEn bit in the Timer Interrupt Mask Register
(TIMSK) must be set. See Table 17-3 on page 88 and Table 17-4 on page 88.
• Bits 2:1 – Reserved
These bits are reserved in the Atmel ATmega16HVB/32HVB and will always read as zero.
• Bit 0 – WGMn0: Waveform Generation Mode
This bit controls the counting sequence of the counter, the source for maximum (TOP) counter
value, see Figure 17-6 on page 89. Modes of operation supported by the Timer/Counter unit are:
Normal mode (counter) and Clear Timer on Compare Match (CTC) mode (see ”Timer/counter
timing diagrams” on page 89).
Bit 7 6 5 4 3 2 1 0
0x24 (0x44) TCWn ICENn ICNCn ICESn ICSn – – WGMn0 TCCRnA
Read/Write R/W R/W R/W R/W R/W R R R/W
Initial Value 0 0 0 0 0 0 0 0
95
8042E–AVR–09/2013
ATmega16HVB/32HVB
17.10.2 TCNTnL – Timer/Counter n Register Low Byte
The Timer/Counter Register TCNTnL gives direct access, both for read and write operations, to
the Timer/Counter unit 8-bit counter. Writing to the TCNTnL Register blocks (disables) the Compare
Match on the following timer clock. Modifying the counter (TCNTnL) while the counter is
running, introduces a risk of missing a Compare Match between TCNTnL and the OCRnx Registers.
In 16-bit mode the TCNTnL register contains the lower part of the 16-bit Timer/Counter n
Register.
17.10.3 TCNTnH – Timer/Counter n Register High Byte
When 16-bit mode is selected (the TCWn bit is set to one) the Timer/Counter Register TCNTnH
combined to the Timer/Counter Register TCNTnL gives direct access, both for read and write
operations, to the Timer/Counter unit 16-bit counter. To ensure that both the high and low bytes
are read and written simultaneously when the CPU accesses these registers, the access is performed
using an 8-bit temporary high byte register (TEMP). This temporary register is shared by
all the other 16-bit registers. See ”Accessing registers in 16-bit mode” on page 90.
17.10.4 OCRnA – Timer/Counter n Output Compare Register A
The Output Compare Register A contains an 8-bit value that is continuously compared with the
counter value (TCNTnL). A match can be used to generate an Output Compare interrupt.
In 16-bit mode the OCRnA register contains the low byte of the 16-bit Output Compare Register.
To ensure that both the high and the low bytes are written simultaneously when the CPU writes
to these registers, the access is performed using an 8-bit temporary high byte register (TEMP).
This temporary register is shared by all the other 16-bit registers. See ”Accessing registers in 16-
bit mode” on page 90.
17.10.5 OCRnB – Timer/Counter n Output Compare Register B
The Output Compare Register B contains an 8-bit value that is continuously compared with the
counter value (TCNTnL in 8-bit mode and TCNTnH in 16-bit mode). A match can be used to
generate an Output Compare interrupt.
Bit 7 6 5 4 3 2 1 0
0x26 (0x46) TCNTnL[7:0] TCNTnL
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
Bit 7 6 5 4 3 2 1 0
0x27 (0x47) TCNTnH[7:0] TCNTnH
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
Bit 7 6 5 4 3 2 1 0
0x28 (0x48) OCRnA[7:0] OCRnA
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
Bit 7 6 5 4 3 2 1 0
0x29 (0x49) OCRnB[7:0] OCRnB
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
96
8042E–AVR–09/2013
ATmega16HVB/32HVB
In 16-bit mode the OCRnB register contains the high byte of the 16-bit Output Compare Register.
To ensure that both the high and the low bytes are written simultaneously when the CPU
writes to these registers, the access is performed using an 8-bit temporary high byte register
(TEMP). This temporary register is shared by all the other 16-bit registers. See ”Accessing registers
in 16-bit mode” on page 90.
17.10.6 TIMSKn – Timer/Counter n Interrupt Mask Register
• Bit 3 – ICIEn: Timer/Counter n Input Capture Interrupt Enable
When this bit is written to one, and the I-flag in the Status Register is set (interrupts globally
enabled), the Timer/Counter n Input Capture interrupt is enabled. The corresponding Interrupt
Vector (see ”Interrupts” on page 52) is executed when the ICFn flag, located in TIFRn, is set.
• Bit 2 – OCIEnB: Timer/Counter n Output Compare Match B Interrupt Enable
When the OCIEnB bit is written to one, and the I-bit in the Status Register is set, the
Timer/Counter Compare Match B interrupt is enabled. The corresponding interrupt is executed if
a Compare Match in Timer/Counter occurs, that is, when the OCFnB bit is set in the
Timer/Counter Interrupt Flag Register – TIFRn.
• Bit 1 – OCIEnA: Timer/Counter n Output Compare Match A Interrupt Enable
When the OCIEnA bit is written to one, and the I-bit in the Status Register is set, the
Timer/Counter n Compare Match A interrupt is enabled. The corresponding interrupt is executed
if a Compare Match in Timer/Counter n occurs, that is, when the OCFnA bit is set in the
Timer/Counter n Interrupt Flag Register – TIFRn.
• Bit 0 – TOIEn: Timer/Counter n Overflow Interrupt Enable
When the TOIEn bit is written to one, and the I-bit in the Status Register is set, the Timer/Counter
n Overflow interrupt is enabled. The corresponding interrupt is executed if an overflow in
Timer/Counter n occurs, that is, when the TOVn bit is set in the Timer/Counter n Interrupt Flag
Register – TIFRn.
17.10.7 TIFRn – Timer/Counter n Interrupt Flag Register
• Bits 3 – ICFn: Timer/Counter n Input Capture Flag
This flag is set when a capture event occurs, according to the setting of ICENn, ICESn and ICSn
bits in the TCCRnA Register.
ICFn is automatically cleared when the Input Capture Interrupt Vector is executed. Alternatively,
ICFn can be cleared by writing a logic one to its bit location.
Bit 7 6 5 4 3 2 1 0
(0x6E)(0x6F) – – – – ICIEn OCIEnB OCIEnA TOIEn TIMSKn
Read/Write R R R R R/W R/W R/W R
Initial Value 0 0 0 0 0 0 0 0
Bit 7 6 5 4 3 2 1 0
0x15 (0x35) – – – – ICFn OCFnB OCFnA TOVn TIFRn
Read/Write R R R R R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
97
8042E–AVR–09/2013
ATmega16HVB/32HVB
• Bit 2 – OCFnB: Output Compare Flag n B
The OCFnB bit is set when a Compare Match occurs between the Timer/Counter and the data in
OCRnB – Output Compare Register n B. OCFnB is cleared by hardware when executing the
corresponding interrupt handling vector. Alternatively, OCFnB is cleared by writing a logic one to
the flag. When the I-bit in SREG, OCIEnB (Timer/Counter Compare B Match Interrupt Enable),
and OCFnB are set, the Timer/Counter Compare Match Interrupt is executed.
The OCFnB is not set in 16-bit Output Compare mode when the Output Compare Register
OCRnB is used as the high byte of the 16-bit Output Compare Register or in 16-bit Input Capture
mode when the Output Compare Register OCRnB is used as the high byte of the Input
Capture Register.
• Bit 1 – OCFnA: Output Compare Flag n A
The OCFnA bit is set when a Compare Match occurs between the Timer/Counter n and the data
in OCRnA – Output Compare Register n. OCFnA is cleared by hardware when executing the
corresponding interrupt handling vector. Alternatively, OCFnA is cleared by writing a logic one to
the flag. When the I-bit in SREG, OCIEnA (Timer/Counter n Compare Match Interrupt Enable),
and OCFnA are set, the Timer/Counter n Compare Match Interrupt is executed.
The OCFnA is also set in 16-bit mode when a Compare Match occurs between the Timer/Counter
n and 16-bit data in OCRnB/A. The OCFnA is not set in Input Capture mode when the Output
Compare Register OCRnA is used as an Input Capture Register.
• Bit 0 – TOVn: Timer/Counter n Overflow Flag
The bit TOVn is set when an overflow occurs in Timer/Counter n. TOVn is cleared by hardware
when executing the corresponding interrupt handling vector. Alternatively, TOVn is cleared by
writing a logic one to the flag. When the SREG I-bit, TOIEn (Timer/Counter n Overflow Interrupt
Enable), and TOVn are set, the Timer/Counter n Overflow interrupt is executed.
98
8042E–AVR–09/2013
ATmega16HVB/32HVB
18. SPI – Serial Peripheral Interface
18.1 Features
• Full-duplex, three-wire synchronous data transfer
• Master or slave operation
• LSB first or MSB first data transfer
• Seven programmable bit rates
• End of transmission interrupt flag
• Write collision protection flag
• Wake-up from idle mode
• Double speed (CK/2) master SPI mode
18.2 Overview
The Serial Peripheral Interface (SPI) allows high-speed synchronous data transfer between the
Atmel ATmega16HVB/32HVB and peripheral devices or between several AVR devices.
When the SPI is not used, power consumption can be minimized by writing the PRSPI bit in
PRR0 to one. See ”PRR0 – Power Reduction Register 0” on page 40 for details on how to use
the PRSPI bit.
Figure 18-1. SPI block diagram (1).
Note: 1. Refer to ”Alternate port functions” on page 72 for SPI pin placement. SPI2X SPI2X
DIVIDER
/2/4/8/16/32/64/128
99
8042E–AVR–09/2013
ATmega16HVB/32HVB
The interconnection between Master and Slave CPUs with SPI is shown in Figure 18-2. The system
consists of two shift Registers, and a Master clock generator. The SPI Master initiates the
communication cycle when pulling low the Slave Select SS pin of the desired Slave. Master and
Slave prepare the data to be sent in their respective shift Registers, and the Master generates
the required clock pulses on the SCK line to interchange data. Data is always shifted from Master
to Slave on the Master Out – Slave In, MOSI, line, and from Slave to Master on the Master In
– Slave Out, MISO, line. After each data packet, the Master will synchronize the Slave by pulling
high the Slave Select, SS, line.
When configured as a Master, the SPI interface has no automatic control of the SS line. This
must be handled by user software before communication can start. When this is done, writing a
byte to the SPI Data Register starts the SPI clock generator, and the hardware shifts the eight
bits into the Slave. After shifting one byte, the SPI clock generator stops, setting the end of
Transmission Flag (SPIF). If the SPI Interrupt Enable bit (SPIE) in the SPCR Register is set, an
interrupt is requested. The Master may continue to shift the next byte by writing it into SPDR, or
signal the end of packet by pulling high the Slave Select, SS line. The last incoming byte will be
kept in the Buffer Register for later use.
When configured as a Slave, the SPI interface will remain sleeping with MISO tri-stated as long
as the SS pin is driven high. In this state, software may update the contents of the SPI Data
Register, SPDR, but the data will not be shifted out by incoming clock pulses on the SCK pin
until the SS pin is driven low. As one byte has been completely shifted, the end of Transmission
Flag, SPIF is set. If the SPI Interrupt Enable bit, SPIE, in the SPCR Register is set, an interrupt
is requested. The Slave may continue to place new data to be sent into SPDR before reading
the incoming data. The last incoming byte will be kept in the Buffer Register for later use.
Figure 18-2. SPI Master-slave interconnection.
The system is single buffered in the transmit direction and double buffered in the receive direction.
This means that bytes to be transmitted cannot be written to the SPI Data Register before
the entire shift cycle is completed. When receiving data, however, a received character must be
read from the SPI Data Register before the next character has been completely shifted in. Otherwise,
the first byte is lost.
In SPI Slave mode, the control logic will sample the incoming signal of the SCK pin. To ensure
correct sampling of the clock signal, the frequency of the SPI clock should never exceed fosc/4.
When the SPI is enabled, the data direction of the MOSI, MISO, SCK, and SS pins is overridden
according to Table 18-1 on page 100. For more details on automatic port overrides, refer to
”Alternate port functions” on page 72.
SHIFT
ENABLE
100
8042E–AVR–09/2013
ATmega16HVB/32HVB
Note: 1. See ”Alternate functions of Port B” on page 75 for a detailed description of how to define the
direction of the user defined SPI pins.
The following code examples show how to initialize the SPI as a Master and how to perform a
simple transmission. DDR_SPI in the examples must be replaced by the actual Data Direction
Register controlling the SPI pins. DD_MOSI, DD_MISO and DD_SCK must be replaced by the
actual data direction bits for these pins, for example, if MOSI is placed on pin PB5, replace
DD_MOSI with DDB5 and DDR_SPI with DDRB.
Table 18-1. SPI pin overrides (1).
Pin Direction, Master SPI Direction, Slave SPI
MOSI User Defined Input
MISO Input User Defined
SCK User Defined Input
SS User Defined Input
101
8042E–AVR–09/2013
ATmega16HVB/32HVB
Note: 1. See ”About code examples” on page 8.
Assembly code example (1)
SPI_MasterInit:
; Set MOSI and SCK output, all others input
ldi r17,(1< 2.2 CPU clock cycles for fck <12MHz, 3 CPU clock cycles for fck >=12MHz
High: > 2.2 CPU clock cycles for fck <12MHz, 3 CPU clock cycles for fck >=12MHz
30.6.1 Serial programming algorithm
When writing serial data to the Atmel ATmega16HVB/32HVB, data is clocked on the rising edge
of SCK.
When reading data from the ATmega16HVB/32HVB, data is clocked on the falling edge of SCK.
See ”Serial programming characteristics” on page 234 for timing details.
To program and verify the ATmega16HVB/32HVB in the Serial Programming mode, the following
sequence is recommended (see four byte instruction formats in Table 30-12 on page 210):
1. Power-up sequence:
Make sure the chip is started as explained in Section 11.2.1 ”Power-on reset and charger
connect” on page 43 while RESET and SCK are set to “0”. In some systems, the programmer
can not guarantee that SCK is held low during power-up. In this case, RESET
must be given a positive pulse of at least two CPU clock cycles duration after SCK has
been set to “0”.
2. Wait for at least 20ms and enable serial programming by sending the Programming
Enable serial instruction to pin MOSI.
Table 30-10. Pin mapping serial programming.
Symbol Pins I/O Description
SCK PB5 I Serial Clock
MOSI PB6 I Serial Data in
MISO PB7 O Serial Data out
GND
SCK
MISO
MOSI
RESET
+4.0V - 25.0V
VFET
GND
SCK
MISO
MOSI
RESET
+4.0V - 25.0V
VFET
209
8042E–AVR–09/2013
ATmega16HVB/32HVB
3. The serial programming instructions will not work if the communication is out of synchronization.
When in sync. the second byte (0x53), will echo back when issuing the third
byte of the Programming Enable instruction. Whether the echo is correct or not, all four
bytes of the instruction must be transmitted. If the 0x53 did not echo back, give RESET a
positive pulse and issue a new Programming Enable command.
4. The Flash is programmed one page at a time. The memory page is loaded one byte at a
time by supplying the 5 LSB of the address and data together with the Load Program
memory Page instruction. To ensure correct loading of the page, the data low byte must
be loaded before data high byte is applied for a given address. The Program memory
Page is stored by loading the Write Program memory Page instruction with the 7/8 MSB
of the address (Atmel ATmega16HVB/ATmega32HVB). If polling (RDY/BSY) is not used,
the user must wait at least tWD_FLASH before issuing the next page (see Table 30-11).
Accessing the serial programming interface before the Flash write operation completes
can result in incorrect programming.
5. A: The EEPROM array is programmed one byte at a time by supplying the address and
data together with the appropriate Write instruction. An EEPROM memory location is first
automatically erased before new data is written. If polling (RDY/BSY) is not used, the
user must wait at least tWD_EEPROM before issuing the next byte (see Table 30-11). In a
chip erased device, no 0xFFs in the data file(s) need to be programmed.
B: The EEPROM array is programmed one page at a time. The Memory page is loaded
one byte at a time by supplying the 2 LSB of the address and data together with the Load
EEPROM Memory Page instruction. The EEPROM Memory Page is stored by loading
the Write EEPROM Memory Page Instruction with the 7/8 MSB of the address
(ATmega16HVB/ATmega32HVB). When using EEPROM page access only byte locations
loaded with the Load EEPROM Memory Page instruction is altered. The remaining
locations remain unchanged. If polling (RDY/BSY) is not used, the used must wait at
least tWD_EEPROM before issuing the next page (see Table 30-8 on page 207). In a chip
erased device, no 0xFF in the data file(s) need to be programmed.
6. Any memory location can be verified by using the Read instruction which returns the content
at the selected address at serial output MISO.
7. At the end of the programming session, RESET can be set high to commence normal
operation.
8. Power-off sequence (if needed):
Set RESET to “1”.
Turn VCC power off.
Table 30-11. Minimum wait delay before writing the next flash or EEPROM location.
Symbol Minimum wait delay
tWD_FLASH 4.5ms
tWD_EEPROM 4.0ms
tWD_ERASE 4.0ms
tWD_FUSE 4.5ms
210
8042E–AVR–09/2013
ATmega16HVB/32HVB
30.6.2 Serial programming instruction set
Table 30-12 and Figure 30-2 on page 211 describes the instruction set.
Notes: 1. Not all instructions are applicable for all parts.
2. adr = address.
3. Bits are programmed ‘0’, unprogrammed ‘1’.
4. To ensure future compatibility, unused Fuses and Lock bits should be unprogrammed (‘1’).
5. Refer to the corresponding section for Fuse and Lock bits, Calibration and Signature bytes and Page size.
6. Instructions accessing program memory use word address. This address may be random within the page range.
7. See http://www.atmel.com/avr for Application Notes regarding programming and programmers.
Table 30-12. Serial programming instruction set.
Instruction/operation
Instruction format
Byte 1 Byte 2 Byte 3 Byte 4
Programming enable $AC $53 $00 $00
Chip erase (program memory/EEPROM) $AC $80 $00 $00
Poll RDY/BSY $F0 $00 $00 data byte out
Load instructions
Load extended address byte (1) $4D $00 Extended adr $00
Load program memory page, high byte $48 adr MSB adr LSB high data byte in
Load program memory page, low byte $40 adr MSB adr LSB low data byte in
Load EEPROM memory page (page access) $C1 adr MSB adr LSB data byte in
Read instructions
Read program memory, high byte $28 adr MSB adr LSB high data byte out
Read program memory, low byte $20 adr MSB adr LSB low data byte out
Read EEPROM memory $A0 adr MSB adr LSB data byte out
Read lock bits $58 $00 $00 data byte out
Read signature byte $30 $00 adr LSB data byte out
Read fuse bits $50 $00 $00 data byte out
Read fuse high bits $58 $08 $00 data byte out
Read extended fuse bits $50 $08 $00 data byte out
Read calibration byte $38 $00 $00 data byte out
Write instructions (6)
Write program memory page $4C adr MSB adr LSB $00
Write EEPROM memory $C0 adr MSB adr LSB data byte in
Write EEPROM memory page (page access) $C2 adr MSB adr LSB $00
Write lock bits $AC $E0 $00 data byte in
Write fuse bits $AC $A0 $00 data byte in
Write fuse high bits $AC $A8 $00 data byte in
Write extended fuse bits $AC $A4 $00 data byte in
211
8042E–AVR–09/2013
ATmega16HVB/32HVB
If the LSB in RDY/BSY data byte out is ‘1’, a programming operation is still pending. Wait until
this bit returns ‘0’ before the next instruction is carried out.
Within the same page, the low data byte must be loaded prior to the high data byte.
After data is loaded to the page buffer, program the EEPROM page, see Figure 30-2.
Figure 30-2. Serial programming instruction example.
30.7 Parallel programming
This section describes parameters, pin mapping, and commands used to parallel program and
verify Flash Program memory, EEPROM Data memory, Memory Lock bits, and Fuse bits in the
Atmel ATmega16HVB/32HVB. Pulses are assumed to be at least 250 ns unless otherwise
noted.
30.7.1 Considerations for efficient programming
The loaded command and address are retained in the device during programming. For efficient
programming, the following should be considered.
• The command needs only be loaded once when writing or reading multiple memory locations
• Skip writing the data value 0xFF, that is the contents of the entire EEPROM (unless the
EESAVE Fuse is programmed) and Flash after a Chip Erase
Address high byte needs only be loaded before programming or reading a new 256 word window
in Flash or 256 byte EEPROM. This consideration also applies to Signature bytes reading.
Byte 1 Byte 2 Byte 3 Byte 4
Adr MSB Adr LSB
Bit 15 B 0
Serial Programming Instruction
Program Memory/
EEPROM Memory
Page 0
Page 1
Page 2
Page N-1
Page Buffer
Write Program Memory Page/
Write EEPROM Memory Page
Load Program Memory Page (High/Low Byte)/
Load EEPROM Memory Page (page access)
Byte 1 Byte 2 Byte 3 Byte 4
Bit 15 B 0
Adr MSB Adr LSB
Page Offset
Page Number
Adr MSB Adr LSB
212
8042E–AVR–09/2013
ATmega16HVB/32HVB
30.7.2 Signal names
In this section, some pins of the Atmel ATmega16HVB/32HVB are referenced by signal names
describing their functionality during parallel programming, see Figure 30-3 and Table 30-13.
Pins not described in the following table are referenced by pin names.
The XA1/XA0 pins determine the action executed when the XTAL1 pin is given a positive pulse.
The bit coding is shown in Table 30-15 on page 213.
When pulsing WR or OE, the command loaded determines the action executed. The different
Commands are shown in Table 30-16 on page 213. Table 32-18 on page 236 shows the Parallel
programming characteristics.
Figure 30-3. Parallel programming.
Table 30-13. Pin name mapping.
Signal name in
programming mode
Pin
name I/O Function
RDY/BSY PA0 O 0: Device is busy programming
1: Device is ready for new command
BS1 PA1 I Byte select 1 (“0” selects low byte, “1” selects high byte)
BS2 PA2 I Byte select 2 (“0” selects low byte, “1” selects 2’nd high byte)
PAGEL PA3 I Program memory and EEPROM data page load
RESET RESET I
DATA PB[7:0] I/O Bi-directional data bus (output when OE is low)
WR PC0 I Write pulse (active low)
OE PC1 I Output enable (active low)
XTAL PC2 I
XA0 PC3 I XTAL action bit 0
XA1 PC4 I XTAL action bit 1
VFET
+4.0V - 18.0V
GND
DATA[7:0]
+11.5V - 12.5V
RESET
PAGEL
BS2
BS1
X1
X0
OE
XTAL1
WR
RDY/BSY
213
8042E–AVR–09/2013
ATmega16HVB/32HVB
30.7.3 Enter programming mode
The following algorithm puts the device in parallel programming mode:
1. Make sure the chip is started as explained in ”Power-on reset and charger connect” on
page 43.
2. Set RESET to “0” and toggle XTAL1 at least six times.
3. Set the Prog_enable pins listed in Table 30-14 to “0000” and wait at least 100ns.
4. Apply 11.5V - 12.5V to RESET. Any activity on Prog_enable pins within 100ns after +12V
has been applied to RESET, will cause the device to fail entering programming mode.
5. Wait at least 50µs before sending a new command.
30.7.4 Chip erase
The Chip Erase will erase the Flash and EEPROM (1) memories plus Lock bits. The Lock bits are
not reset until the program memory has been completely erased. The Fuse bits are not
changed. A Chip Erase must be performed before the Flash and/or EEPROM are
reprogrammed.
Note: 1. The EEPRPOM memory is preserved during Chip Erase if the EESAVE Fuse is programmed.
Table 30-14. Pin values used to enter programming mode.
Pin Symbol Value
PB3 Prog_enable[3] 0
PB2 Prog_enable[2] 0
PB1 Prog_enable[1] 0
PB0 Prog_enable[0] 0
Table 30-15. XA1 and XA0 coding.
XA1 XA0 Action when XTAL1 is pulsed
0 0 Load flash or EEPROM address (High or low address byte determined by BS1)
0 1 Load data (High or Low data byte for Flash determined by BS1)
1 0 Load command
1 1 No action, idle
Table 30-16. Command byte bit coding.
Command byte Command executed
1000 0000 Chip erase
0100 0000 Write fuse bits
0010 0000 Write lock bits
0001 0000 Write flash
0001 0001 Write EEPROM
0000 1000 Read signature bytes and calibration byte
0000 0100 Read fuse and lock bits
0000 0010 Read flash
0000 0011 Read EEPROM
214
8042E–AVR–09/2013
ATmega16HVB/32HVB
Load command “Chip Erase”.
1. Set XA1, XA0 to “10”. This enables command loading.
2. Set BS1 to “0”.
3. Set DATA to “1000 0000”. This is the command for Chip Erase.
4. Give XTAL1 a positive pulse. This loads the command.
5. Give WR a negative pulse. This starts the Chip Erase. RDY/BSY goes low.
6. Wait until RDY/BSY goes high before loading a new command.
30.7.5 Programming the flash
The Flash is organized in pages, see Table 30-7 on page 207. When programming the Flash,
the program data is latched into a page buffer. This allows one page of program data to be programmed
simultaneously. The following procedure describes how to program the entire Flash
memory:
A. Load Command “Write Flash”
1. Set XA1, XA0 to “10”. This enables command loading.
2. Set BS1 to “0”.
3. Set DATA to “0001 0000”. This is the command for Write Flash.
4. Give XTAL1 a positive pulse. This loads the command.
B. Load Address Low byte
1. Set XA1, XA0 to “00”. This enables address loading.
2. Set BS1 to “0”. This selects low address.
3. Set DATA = Address low byte (0x00 - 0xFF).
4. Give XTAL1 a positive pulse. This loads the address low byte.
C. Load Data Low Byte
1. Set XA1, XA0 to “01”. This enables data loading.
2. Set DATA = Data low byte (0x00 - 0xFF).
3. Give XTAL1 a positive pulse. This loads the data byte.
D. Load Data High Byte
1. Set BS1 to “1”. This selects high data byte.
2. Set XA1, XA0 to “01”. This enables data loading.
3. Set DATA = Data high byte (0x00 - 0xFF).
4. Give XTAL1 a positive pulse. This loads the data byte.
E. Latch Data
1. Set BS1 to “1”. This selects high data byte.
2. Give PAGEL a positive pulse. This latches the data bytes (see Figure 30-5 on page 216
for signal waveforms).
F. Repeat B through E until the entire buffer is filled or until all data within the page is loaded
While the lower bits in the address are mapped to words within the page, the higher bits address
the pages within the FLASH. This is illustrated in Figure 30-4 on page 215. Note that if less than
eight bits are required to address words in the page (pagesize <256), the most significant bit(s)
in the address low byte are used to address the page when performing a Page Write.
215
8042E–AVR–09/2013
ATmega16HVB/32HVB
G. Load Address High byte
1. Set XA1, XA0 to “00”. This enables address loading.
2. Set BS1 to “1”. This selects high address.
3. Set DATA = Address high byte (0x00 - 0xFF).
4. Give XTAL1 a positive pulse. This loads the address high byte.
H. Program Page
1. Give WR a negative pulse. This starts programming of the entire page of data. RDY/BSY
goes low.
2. Wait until RDY/BSY goes high (see Figure 30-5 on page 216 for signal waveforms).
I. Repeat B through H until the entire Flash is programmed or until all data has been
programmed.
J. End Page Programming
1. 1. Set XA1, XA0 to “10”. This enables command loading.
2. Set DATA to “0000 0000”. This is the command for No Operation.
3. Give XTAL1 a positive pulse. This loads the command, and the internal write signals are
reset.
Figure 30-4. Addressing the flash which is organized in pages (1).
Note: 1. PCPAGE and PCWORD are listed in Table 30-7 on page 207.
PROGRAM MEMORY
WORD ADDRESS
WITHIN A PAGE
PAGE ADDRESS
WITHIN THE FLASH
INSTRUCTION WORD
PAGE PCWORD[PAGEMSB:0]:
00
01
02
PAGEEND
PAGE
PCPAGE PCWORD
PCMSB PAGEMSB
PROGRAM
COUNTER
216
8042E–AVR–09/2013
ATmega16HVB/32HVB
Figure 30-5. Programming the flash waveforms (1).
Note: 1. “XX” is don’t care. The letters refer to the programming description above.
30.7.6 Programming the EEPROM
The EEPROM is organized in pages, see Table 30-8 on page 207. When programming the
EEPROM, the program data is latched into a page buffer. This allows one page of data to be
programmed simultaneously. The programming algorithm for the EEPROM data memory is as
follows (refer to ”Programming the flash” on page 214 for details on Command, Address and
Data loading):
1. A: Load Command “0001 0001”.
2. G: Load Address High Byte (0x00 - 0xFF).
3. B: Load Address Low Byte (0x00 - 0xFF).
4. C: Load Data (0x00 - 0xFF).
5. E: Latch data (give PAGEL a positive pulse).
K: Repeat 3 through 5 until the entire buffer is filled
L: Program EEPROM page
1. Set BS to “0”.
2. Give WR a negative pulse. This starts programming of the EEPROM page. RDY/BSY
goes low.
3. Wait until to RDY/BSY goes high before programming the next page (see Figure 30-6 on
page 217 for signal waveforms).
RDY/BSY
WR
OE
RESET +12V
PAGEL
BS2
0x10 ADDR. LOW ADDR. HIGH DATA DATA LOW DATA HIGH ADDR. LOW DATA LOW DATA HIGH
XA1
XA0
BS1
XTAL1
XX XX XX
A B C D EB C D E G H
F
217
8042E–AVR–09/2013
ATmega16HVB/32HVB
Figure 30-6. Programming the EEPROM waveforms.
30.7.7 Reading the flash
The algorithm for reading the flash memory is as follows (refer to ”Programming the flash” on
page 214 for details on Command and Address loading):
1. A: Load Command “0000 0010”.
2. G: Load Address High Byte (0x00 - 0xFF).
3. B: Load Address Low Byte (0x00 - 0xFF).
4. Set OE to “0”, and BS1 to “0”. The Flash word low byte can now be read at DATA.
5. Set BS to “1”. The Flash word high byte can now be read at DATA.
6. Set OE to “1”.
30.7.8 Reading the EEPROM
The algorithm for reading the EEPROM memory is as follows (refer to ”Programming the flash”
on page 214 for details on Command and Address loading):
1. A: Load Command “0000 0011”.
2. G: Load Address High Byte (0x00 - 0xFF).
3. B: Load Address Low Byte (0x00 - 0xFF).
4. Set OE to “0”, and BS1 to “0”. The EEPROM Data byte can now be read at DATA.
5. Set OE to “1”.
30.7.9 Programming the fuse low bits
The algorithm for programming the Fuse Low bits is as follows (refer to ”Programming the flash”
on page 214 for details on Command and Data loading):
1. A: Load Command “0100 0000”.
2. C: Load Data Low Byte. Bit n = “0” programs and bit n = “1” erases the Fuse bit.
3. Give WR a negative pulse and wait for RDY/BSY to go high.
RDY/BSY
WR
OE
RESET +12V
PAGEL
BS2
0x11 ADDR. HIGH DATA ADDR. LOW DATA ADDR. LOW DATA XX
XA1
XA0
BS1
XTAL1
XX
A G B C EB C E L
K
218
8042E–AVR–09/2013
ATmega16HVB/32HVB
30.7.10 Programming the fuse high bits
The algorithm for programming the Fuse High bits is as follows (refer to ”Programming the flash”
on page 214 for details on Command and Data loading):
1. A: Load Command “0100 0000”.
2. C: Load Data Low Byte. Bit n = “0” programs and bit n = “1” erases the Fuse bit.
3. Set BS1 to “1” and BS2 to “0”. This selects high data byte.
4. Give WR a negative pulse and wait for RDY/BSY to go high.
5. Set BS1 to “0”. This selects low data byte.
Figure 30-7. Programming the FUSES waveforms.
30.7.11 Programming the lock bits
The algorithm for programming the Lock bits is as follows (refer to ”Programming the flash” on
page 214 for details on Command and Data loading):
1. A: Load Command “0010 0000”.
2. C: Load Data Low Byte. Bit n = “0” programs the Lock bit. If LB mode 3 is programmed
(LB1 and LB2 is programmed), it is not possible to program the Boot Lock bits by any
External Programming mode.
3. Give WR a negative pulse and wait for RDY/BSY to go high.
The Lock bits can only be cleared by executing Chip Erase.
30.7.12 Reading the fuse and lock bits
The algorithm for reading the Fuse and Lock bits is as follows (refer to ”Programming the flash”
on page 214 for details on Command loading):
1. A: Load Command “0000 0100”.
2. Set OE to “0”, BS2 to “0” and BS1 to “0”. The status of the Fuse Low bits can now be
read at DATA (“0” means programmed).
3. Set OE to “0”, BS2 to “1” and BS1 to “1”. The status of the Fuse High bits can now be
read at DATA (“0” means programmed).
4. Set OE to “0”, BS2 to “0” and BS1 to “1”. The status of the Lock bits can now be read at
DATA (“0” means programmed).
5. Set OE to “1”.
RDY/BSY
WR
OE
RESET +12V
PAGEL
0x40 DATA DATA XX
XA1
XA0
BS1
XTAL1
A C
0x40 DATA XX
A C
Write Fuse Low byte Write Fuse high byte
0x40 DATA XX
A C
Write Extended Fuse byte
BS2
219
8042E–AVR–09/2013
ATmega16HVB/32HVB
Figure 30-8. Mapping between BS1, BS2 and the fuse and lock bits during read.
30.7.13 Reading the Signature bytes
The algorithm for reading the Signature bytes is as follows (refer to ”Programming the flash” on
page 214 for details on Command and Address loading):
1. A: Load Command “0000 1000”.
2. B: Load Address Low Byte (0x00 - 0x02).
3. Set OE to “0”, and BS to “0”. The selected Signature byte can now be read at DATA.
4. Set OE to “1”.
30.7.14 Reading the Calibration byte
The algorithm for reading the Calibration byte is as follows (refer to ”Programming the flash” on
page 214 for details on Command and Address loading):
1. A: Load Command “0000 1000”.
2. B: Load Address Low Byte, 0x00.
3. Set OE to “0”, and BS1 to “1”. The Calibration byte can now be read at DATA.
4. Set OE to “1”.
Lock Bits 0
1
BS2
Fuse High Byte
0
1
BS1
DATA
Fuse Low Byte 0
1
BS2
Extended Fuse Byte
220
8042E–AVR–09/2013
ATmega16HVB/32HVB
31. Operating circuit
Figure 31-1. Operating circuit, 4-cell.
R8
R6
D6
D7
D8
D9
D10
ATmega16HVB/32HVB
VFET OC PVT OD
+
PV4
PV3
PV2
PV1
NV
PA0/ADC0/SGND
PA1/ADC1/SGND
RESET VREG
PB3
PB4
PB5
PB6
PB7
BATT
R7
VREF VREFGND
SMBDATA
SMBCLK
R28 R29
VCC
R20 R19
R21
PC5
PA2
R27
PB0
PB1/CKOUT
PB2
PC3/SDA
PC4/SCL
PC0/EXT_PROT
D3
R23
R22 PC2
R17
C14 C13 C15
PC1
C7
C6
C5
R5
C16
C12
SW1
D4
SYS PRESENT
R24
FUSE BLOW
FUSE STATUS
R25
R26
F1
D1
R16
Q2 Q3
Q4
PA3
R9
R10
R11
R12
C9
PPI
PI
NI
NNI
R13
R14
R18
-
R4
R3
R2
R1
S-8244
R15
SENSE
VC1
VC2
VC3
VSS
VCC
ICT
CO
C8
VCC
VCC
VCC
VCC
C10
C4
C3
C2
C1
C11
R30
Q1
D2
D5
RT33 RT32
CELL4
CELL3
CELL2
CELL1
Pack+
PackC18
VCLMP10
Optional secondary protection and fuse blow circuitry
R31
R36 R37
221
8042E–AVR–09/2013
ATmega16HVB/32HVB
Figure 31-2. Operating circuit, 3-cell.
R8
R6
D6
D7
D8
D9
D10
ATmega16HVB/32HVB
VFET OC PVT OD
+
PV4
PV3
PV2
PV1
NV
PA0/ADC0/SGND
PA1/ADC1/SGND
RESET VREG
PB3
PB4
PB5
PB6
PB7
BATT
R7
VREF VREFGND
SMBDATA
SMBCLK
R28 R29
VCC
R20 R19
R21
PC5
PA2
R27
PB0
PB1/CKOUT
PB2
PC3/SDA
PC4/SCL
PC0/EXT_PROT
D3
R23
R22 PC2
R17
C14 C13 C15
PC1
C6
C5
R5
C12
SW1
D4
SYS PRESENT
R24
FUSE BLOW
FUSE STATUS
R25
R26
F1
D1
R16
Q2 Q3
Q4
PA3
R10
R11
R12
C9
PPI
PI
NI
NNI
R13
R14
R18
-
R4
R3
R2 S-8244
R15
SENSE
VC1
VC2
VC3
VSS
VCC
ICT
CO
VCC
VCC
VCC
VCC
C10
C4
C3
C2
C11
R30
Q1
D2
D5
CELL3
CELL2
CELL1
Pack+
PackC18
VCLMP10
Optional secondary protection and fuse blow circuitry
R9
C7
C16
RT33 RT32
R31
R36 R37
222
8042E–AVR–09/2013
ATmega16HVB/32HVB
Figure 31-3. Operating circuit, 2-cell.
R8
R6
D6
D7
D8
D9
D10
ATmega16HVB/32HVB
VFET OC PVT OD
+
PV4
PV3
PV2
PV1
NV
PA0/ADC0/SGND
PA1/ADC1/SGND
RESET VREG
PB3
PB4
PB5
PB6
PB7
BATT
R7
VREF VREFGND
SMBDATA
SMBCLK
R28 R29
VCC
R20 R19
R21
PA2
PC5
R27
PB0
PB1/CKOUT
PB2
PC3/SDA
PC4/SCL
PC0/EXT_PROT
D3
R23
R22 PC2
R17
C14 C13 C15
PC1
C6
C5
R5
C12
SW1
D4
SYS PRESENT
R24
FUSE BLOW
FUSE STATUS
R25
R26
F1
D1
R16
Q2 Q3
Q4
PA3
R10
R11
R12
C9
PPI
PI
NI
NNI
R13
R14
R18
-
R4
R3
S-8244
R15
SENSE
VC1
VC2
VC3
VSS
VCC
ICT
CO
VCC
VCC
VCC
VCC
C10
C4
C3
C11
R30
Q1
D2
D5
CELL2
CELL1
Pack+
PackC18
VCLMP10
Optional secondary protection and fuse blow circuitry
R9
Q5
R34
R35
C16
RT33 RT32
R31
R36 R37
223
8042E–AVR–09/2013
ATmega16HVB/32HVB
Table 31-1. Bill of materials.
Symbol Number Description
C1-C4, C10, C11 6 Capacitor, ceramic, 0.1µF - 1.0µF , 50V, X7R
C5-C8 4 Capacitor, ceramic, 0.01µF - 0.5µF, 50V, X7R
C9, C12, C13, C15 4 Capacitor, ceramic, 0.1µF, 50V, X7R
C14 1 Capacitor, ceramic, 2.2µF - 4.7µF, 10V, X7R
C16 1 Capacitor, ceramic, 1µF - 22µF, 10V, X7R
C18 1 Capacitor, ceramic, 22nF, 50V, X7R
D1 1 Diode, signal
D2 1 Diode, double, Shottky
D4 1 Diode, signal
D3 1 Diode, Zener, value from design considerations
D4 1 Diode, Zener, 5V6
D5 1 Diode, double, Zener, 5V6
D6-D10 5 LEDs
F1 1 Chemical fuse
Q1 1 N-FET, 50V, 0.22A
Q2, Q3 2 N-FET, 30V, 10A
Q4 1 N-FET, 20V, 1.3A
Q5 1 P-FET, 30V, 10A
R1-R4 4 Resistor, chip, 1k - 10k, 1/16W, 5%
R5-R9 5 Resistor, chip, 10k - 1000, 1/16W, 5%
R10 1 Sense resistor, 1m - 10m, 1W, 1%
R11, R12 2 Resistor, chip, 10 - 500, 1/16W, 5%
R13, R14, R18, R19, R20, R21, R25 7 Resistor, chip 1k, 1/16W, 5%
R15 1 Resistor, chip, 100 - 1000, 1/16W, 5%
R16, R17 2 Resistor, chip 200k, 1/16W, 5%
R22 1 Resistor, value from design considerations
R23 1 Resistor, value from design considerations
R24 1 Resistor, chip 1k, 1/16W, 5%
R26, R27 2 Resistor, chip 100, 1/16W, 5%
R28, R29 2 Resistor, chip 1M, 1/16W, 5%
R30 1 Resistor, chip 820, 1/16W, 5%
R31 1 Resistor, chip 2.4k, 1/16W, 5%
R32, R33 2 NTC thermistor, 10k, B = 3000 - 4000
R34 1 Resistor, value determined by battery pack and charger requirements
R35 1 Resistor, chip 1M, 1/16W, 5%
224
8042E–AVR–09/2013
ATmega16HVB/32HVB
R36, R37 2 Resistor, chip 5.1k, 1/16W, 5%
SW 1 Switch, push button
U1 1 Atmel ATmega32HVB
U2 1 S-8244 secondary protection device (Seiko Instruments)
Symbol Number Description
225
8042E–AVR–09/2013
ATmega16HVB/32HVB
32. Electrical characteristics
32.1 Absolute maximum ratings*
32.2 Supply current characteristics
Operating temperature .................................... -40C to +85C *NOTICE: Stresses beyond those listed under “Absolute
Maximum Ratings” may cause permanent damage
to the device. This is a stress rating only and
functional operation of the device at these or
other conditions beyond those indicated in the
operational sections of this specification is not
implied. Exposure to absolute maximum rating
conditions for extended periods may affect
device reliability.
Storage temperature...................................... -65°C to +150°C
Voltage on PA0 - PA3, PI, NI, PPI and NNI
with respect to ground .............................. -0.5V to VREG +0.5V
Voltage on PB0 - PB7
with respect to ground .............................. -0.5V to VCC +0.5V
Voltage on PC0 - PC4,
PV1, and NV with respect to ground..................-0.5V to +6.0V
Voltage on OC and OD with respect to ground...-0.5V to +35V
Voltage on PC5, BATT, PVT, VFET, PV4, PV3, and PV2
with respect to ground ........................................-0.5V to +25V
Voltage on PV4 with respect to PV3: ................. -0.5V to +10V
Voltage on PV3 with respect to PV2: ................. -0.5V to +10V
Voltage on PV2 with respect to PV1: ................. -0.5V to +10V
Voltage on PV1 with respect to NV: ................... -0.5V to +10V
Voltage on PVT with respect to VFET: .............................. 10V
Voltage on VCLMP10 and RESET
with respect to ground ........................................-0.5V to +13V
Maximum operating voltage on VREG and VCC.............. 4.5V
Maximum operating voltage on VFET ............................... 18V
Table 32-1. TA= 25°C unless otherwise noted.
Symbol Parameter Condition Minimum Typical Maximum Units
IVFET
Active current
VFET = 16V, CPU clock = 8MHz, All PRR bits set 3.75 5 mA
VFET = 16V, CPU clock = 1MHz, All PRR bits set 760 1000
µA
Idle current VFET = 16V, CPU clock = 1MHz, All PRR bits set 215 293
ADCNRM current VFET = 16V, CPU clock = 1MHz, All PRR bits except
PRVADC are set, VADC enabled
350
Power-save
current
VFET = 16V, Only WDT enabled, DUVR mode
disabled
28 46
VFET = 16V, WDT, CC-ADC, OC, OD and Battery
Protection enabled, DUVR mode disabled
115 170
Power-off current VFET = 6V <1 2
226
8042E–AVR–09/2013
ATmega16HVB/32HVB
32.3 NFET driver characteristics
Notes: 1. Measures NFET driver’s ability to switch OC/OD from 0V to specified output level with constant resistive load on the pin.
Loads above this limit may cause OC/OD not reaching the specified level. Drive capability is highly temperature dependent.
Refer to Section 33.2 ”NFET driver characteristics” on page 245 for details.
Note: The NFET drivers require a minimum total cell voltage of 6V or higher or a charger connected to turn-on the FETs. Note that this
limit only applies if the FET is disabled in advance. If the FET is already enabled, the FET will be fully operational in the entire
voltage range of the device (4V to 18V).
Table 32-2. TA= 25°C unless otherwise noted.
Symbol Parameter Condition Min. Typ. Max. Units
VOC,ON
OC pin on voltage relative to PVT
voltage
OC enabled, VFET = 16V 13
V
OC enabled, VFET = 10V 13
OC enabled, VFET = 4V 6
VOD,ON
OD pin on voltage relative to
BATT voltage
OD enabled, VFET = 16V 13
OD enabled, VFET = 10V 13
OD enabled, VFET = 4V 6
VOC,OFF OC pin off voltage realtive to GND 0.0
VOD,OFF OD pin off voltage realtive to GND 0.0
tr,OC Rise time on OC pin
V(OC-PVT) = 0V to 2V, Ceq = 4.7nF, VFET = 16V 0.8
ms
V(OC-PVT) = 0V to 2V, Ceq = 4.7nF, VFET = 10V 1.1
V(OC-PVT) = 0V to 2V, Ceq = 4.7nF, VFET = 6V 3
V(OC-PVT) = 2V to 4V, Ceq = 4.7nF, VFET = 16V 1
V(OC-PVT) = 2V to 4V, Ceq = 4.7nF, VFET = 10V 1.2
V(OC-PVT) = 2V to 4V, Ceq = 4.7nF, VFET = 6V 1.3
tr,OD Rise time on OD pin
V(OD-BATT) = 0V to 2V, Ceq = 4.7nF, VFET = 16V 0.8
V(OD-BATT) = 0V to 2V, Ceq = 4.7nF, VFET = 10V 1.1
V(OD-BATT) = 0V to 2V, Ceq = 4.7nF, VFET = 6V 3
V(OD-BATT) = 2V to 4V, Ceq = 4.7nF, VFET = 16V 1
V(OD-BATT) = 2V to 4V, Ceq = 4.7nF, VFET = 10V 1.2
V(OD-BATT) = 2V to 4V, Ceq = 4.7nF, VFET = 6V 1.3
tf,OC Fall time on OC pin V(OD-PVT) = VOC,ON to 0V, Ceq = 4.7nF, VFET = 16V 50
ns
tf,OD Fall time on OD pin V(OD-BATT) = VOD,ON to 0V, Ceq = 4.7nF, VFET =
16V 50
ILOAD OC/OD drive capability (1) VFET = 9V, TA = 85°C 3.5 µA
VVFET,DUV
R
Regulated VFET voltage in DUVR
mode DUVR enabled, VREF = 1.1V 4.1 4.9 V
227
8042E–AVR–09/2013
ATmega16HVB/32HVB
32.4 Reset characteristics
Notes: 1. The voltage at the pack + terminal will be slightly higher than VPOT when the chip is enabled. This is because of an internal
Pull-down current on the BATT pin in the range 50µA - 150µA and the RBATT resistor connected between the Pack + terminal
and the BATT pin. RBATT = 1k gives a voltage drop 0.05V - 0.15V.
2. The power-on reset will not work unless the voltage has been below VPOT (falling) after a power-off condition.
32.5 Voltage regulator characteristics
32.6 Voltage reference and temperature sensor characteristics
Notes: 1. Calibration is done in Atmel factory test. Software should calibrate the VREF by writing the BGCRR and BGCCR registers
with the calibration values stored in the signature row.
2. This value is not tested in production.
3. The measured VPTAT voltage must be scaled with the calibration value stored in the VPTAT Calibration Register to get the
absolute temperature. The design target accuracy for this parameter assumes an exact calibration temperature. Actual
accuracy of this parameter after calibration in Atmel factory test remains to be determined.
Table 32-3. TA= -40°C to +85°C unless otherwise noted.
Symbol Parameter Condition Min. Typ. Max. Units
VPOT
Power-on threshold voltage (rising) (1) 4.5 7
V
Power-on threshold voltage (falling) (1)(2) 4.5 6.3
t
RST Minimum pulse width on RESET Pin 900 ns
VBOT Brown-out detection (BOD) trigger level TA = 25°C 2.9 3.1 V
VHYST BOD level hysteresis TA = 25°C 50 mV
Table 32-4. TA= -40°C to +85°C unless otherwise noted.
Symbol Parameter Condition Min. Typ. Max. Unit
VVREG Regulator output voltage
VFET = 16.8V, IOUT = 20mA 3.1
V
VFET = 6V, IOUT = 20mA 3.1
VFET = 4V, IOUT = 7mA 3.1
VRSCL Voltage regulator short- circuit Level at VFET pin 3.3 3.8
VBLOD
Voltage Regulator Black-out Detection Level at
VREG pin TA = 25°C 2.65 2.75
Table 32-5. TA= -40°C to +85°C unless otherwise noted.
Parameter Condition Min. Typ. Max. Units
Reference voltage 1.100 V
Reference voltage accuracy (1) After factory calibration,
TA = 25°C ±0.1 ±0.2 %
Temperature drift (1)(2)
TA = -40C to +85C 60 90
ppm/K
TA = 0C to +60C 25 50
VREF calibration
Hold Off Time
CREG = 2.2µF, BGCCR write 2
µs
CREG = 2.2µf, BGCRR write 5
VPTAT, voltage proportional to absolute temperature (2) 0.6 mV/K
VPTAT absolute accuracy (3) ±5 K
228
8042E–AVR–09/2013
ATmega16HVB/32HVB
32.7 ADC characteristics
32.7.1 Voltage ADC characteristics
Notes: 1. Value is after Atmel factory offset and gain compensation in production (for details, see Table 29-3, “Signature row addressing.,”
on page 196) and it includes drift over the whole temperature range.
2. Value not tested in production but guaranteed by design and characterization.
Table 32-6. TA= -40°C to +85°C unless otherwise noted.
Parameter Condition Min. Typ. Max. Units
Conversion time clkVADC = 1MHz 519 µs
Resolution 12 Bits
Gain ADC0/1 (un-scaled) 263 µV/LSB
Gain cell inputs (x0.2) 1.42 mV/LSB
INL (2)
ADC0, ADC1 ±1 ±3
CELL1, CELL2, CELL3 ±1 ±3 LSB
CELL4 ±2 ±5
Input voltage range ADC0, ADC1, VTEMP 0 1
V
Input voltage range CELL1 1.8 5
Input voltage range CELL2 VPV1-GND>1.8V 0 5
Input voltage range CELL3 VPV2-GND>1.8V 0 5
Input voltage range CELL4 VPV3-GND>1.8V 0 5
Offset drift (1)(2)
ADC0, ADC1 1
CELL1, CELL2, CELL3 1 LSB
CELL4 5
Gain drift (1)(2)
ADC0, ADC1 6
CELL1, CELL2, CELL3 7 LSB
CELL4 15
229
8042E–AVR–09/2013
ATmega16HVB/32HVB
32.7.2 Coulomb counter ADC characteristics
Notes: 1. Values based on characterization data.
2. After software offset compensation, using the polarity switching (CADPOL) feature.
3. Value includes drift over the whole temperature range.
32.8 Clock characteristics
Notes: 1. The frequency is stored in the Value after factory calibration at 85°C.
2. Value not tested in production, but is guaranteed by design and characterization over the whole temperature range.
3. The actual oscillator frequency is measured in production and store in the device signature row (for detailes, see ”Reading
the signature row from software” on page 195.
4. TA = 0°C to +85°C.
Table 32-7. TA= -40°C to +85°C unless otherwise noted.
Parameter Condition Min. Typ. Max. Units
Conversion time
Instantaneous conversion, clkCC-ADC = 32kHz 3.9 ms
Accumulated conversion CADAS = 11, clkCC-ADC = 32kHz 1 s
Resolution
Instantaneous conversion 13
Bits
Accumulated conversion 18
Gain
Accumulated conversion, CADVSE=0 1.67
µV/LSB
Accumulated conversion, CADVSE=1 0.84
Instantaneous conversion, CADVSE=0 53.7
Instantaneous conversion, CADVSE=1 26.9
Input voltage range
CADVSE = 0 -200 200 mV
CADVSE = 1 -100 100
INL (1) TA= 0°C - 60°C ±0.003 ±0.005 % FSR
Offset error (2) Accumulated conversion, TA = 25°C -7 µV
Offset error drift (1)(2) Accumulated conversion 30 nV/°C
Gain error (1)(3) ±0.4 ±1
%
Gain error drift (1) 0.1
Table 32-8. TA= -40°C to +85°C unless otherwise noted.
Parameter Condition Min. Typ. Max. Units
Calibrated fast RC
oscillator
Frequency After factory calibration at
TA = 25°C 7.92 8 8.08 MHz
Frequency drift (2)
With run-time calibration with
OSI interface and slow RC
oscillator as calibration clock
3 %
Slow RC oscillator (1) Frequency (3) 91 131 171 kHz
Frequency prediction error (4) 0.2 %
Ultra low power RC
oscillator (1)
Frequency (3) 89 128 167 kHz
Frequency drift (2) 6 %
230
8042E–AVR–09/2013
ATmega16HVB/32HVB
32.9 Cell balancing characteristic
32.10 Battery protection characteristics
Notes: 1. Levels in charge and discharge direction can be configured independent of each other.
2. VSCD = VNNI - VPPI, VCOCD = VPPI - VNNI, VDOCD = VNNI - VPPI, VCHCD = VPPI - VNNI, VDHCD = VNNI - VPPI
32.11 External interrupt characteristics
Table 32-9. TA= 25°C unless otherwise noted.
Parameter Condition Min. Typ. Max. Unit
Balancing current Battery cell voltage VCELL = 4.2V, V-ADC filter resistance = 470 4 mA
Table 32-10. TA= -40°C to +85°C unless otherwise noted.
Parameter Condition Min. Max. Unit
Short circuit detection level error (1)
Charge/discharge over current detection level
error (1)
Charge/discharge high current detection
detection level error (1)
VSCD, VCOCD, VDOCD, VCHCD, and VDHCD
from 20mV to 70mV (2) -10 +10
mV
VSCD, VCOCD, VDOCD, VCHCD, and VDHCD
from 80mV to 140mV (2) -15 +15
VSCD, VCOCD, VDOCD, VCHCD, and VDHCD
from 150mV to 270mV (2) -35 +35
VSCD, VCOCD, VDOCD, VCHCD, and VDHCD
at 310mV (2) -50 +50
Table 32-11. Asynchronous external interrupt characteristics.
Symbol Parameter Condition Min. Typ. Max. Unit
tINT
Minimum pulse width for
asynchronous external interrupt 50 ns
231
8042E–AVR–09/2013
ATmega16HVB/32HVB
32.12 General I/O lines characteristics
32.12.1 Port A and B characteristics
Notes: 1. “Max” means the highest value where the pin is guaranteed to be read as low.
2. “Min” means the lowest value where the pin is guaranteed to be read as high.
3. Although each I/O port can sink more than the test conditions (5mA at VCC = 3.3V) under steady state conditions (non-transient),
the following must be observed:
- The sum of all IOL should not exceed 20mA
If IOL exceeds the test condition, VOL may exceed the related specification. Pins are not guaranteed to sink current greater
than the listed test condition.
4. Although each I/O port can source more than the test conditions (2mA at VCC = 3.3V) under steady state conditions (nontransient),
the following must be observed:
- The sum of all IOH should not exceed 2mA
This restriction is put because the device should be within spec throughout the whole operation range. The integrated voltage
regulator could have problems providing this output when supplying high currents at low VFET voltages.
5. The typical hysteresis on VIL/VIH is 300mV on all PA and PB pins except PA3. PA3 has a typical hysteresis of 50mV.
32.12.2 Port C characteristics
Note: 1. This values is based on characterization and is not tested in production.
Table 32-12. TA = -40°C to +85°C, VCC = 3.3V (unless otherwise noted).
Symbol Parameter Condition Min. Typ. Max. Units
VIL Input low voltage, Except RESET pin -0.5 0.3VCC (1)
V
VIL1 Input low voltage, RESET pin 0.3VCC (1)
VIH Input high voltage, Except RESET pin 0.6VCC (2) VCC + 0.5
VIH1 Input high voltage, RESET pin 0.9VCC (2) VCC + 0.5
VOL Output low voltage IOL = 5mA 0.5
VOH Output high voltage IOH = 2mA 2.3
IIL Input leakage current I/O Pin Pin low (absolute value) 1
µA
IIH Input leakage current I/O Pin Pin high (absolute value) 1
RRST Reset pull-up resistor 30 60
k
RPU I/O pin pull-up resistor 20 50
Table 32-13. PC0-PC4 characteristics.
Symbol Parameter Condition Min. Max. Unit
VIL Input low-voltage -0.5 0.8
VIH Input high-voltage 2.1 5.5 V
VOL (1) Output low-voltage 350µA sink current 0 0.4
Table 32-14. PC5 characteristic.
Symbol Parameter Condition Min. Max. Unit
VOL Output low-voltage 500µA sink current 0 0.2 V
232
8042E–AVR–09/2013
ATmega16HVB/32HVB
32.13 2-wire serial interface characteristics
Table 32-15 describes the requirements for devices connected to the Two-wire Serial Bus. The
Atmel ATmega16HVB/32HVB Two-wire Serial Interface meets or exceeds these requirements
under the noted conditions.
Timing symbols refer to Figure 32-1 on page 233.
Notes: 1. In ATmega16HVB/32HVB, this parameter is characterized and not tested.
2. Cb = capacitance of one bus line in pF.
3. fCK = CPU clock frequency.
4. This requirement applies to all ATmega16HVB/32HVB Two-wire Serial Interface operation. Other devices connected to the
Two-wire Serial Bus need only obey the general fSCL requirement.
Table 32-15. Two-wire serial bus requirements.
Symbol Parameter Condition Minimum Maximum Units
VIL Input low-voltage -0.5 0.8
VIH Input high-voltage 2.1 5.5 V
VOL (1) Output low-voltage 350µA sink current 0 0.4
tr
(1) Rise time for both SDA and SCL 300
tof ns (1) Output fall time from VIHmin to VILmax Cb < 400pF (2) 250
tSP (1) Spikes suppressed by input filter 0 50
Ii Input current each I/O pin 0.1VBUS < Vi
< 0.9VBUS -5 5 µA
Ci
(1) Capacitance for each I/O pin – 10 pF
fSCL SCL clock frequency fCK (3) > max(16fSCL, 450Hz) (4) 0 100 kHz
Rp Value of pull-up resistor fSCL 100Hz
tHD;STA Hold time (repeated) START condition fSCL 100kHz 4.0 –
µs
tLOW Low period of the SCL clock fSCL 100kHz 4.7 –
tHIGH High period of the SCL clock fSCL 100kHz 4.0 –
tSU;STA Set-up time for a repeated START condition fSCL 100kHz 4.7 –
tHD;DAT Data hold time fSCL 100kHz 0.3 3.45
tSU;DAT Data setup time fSCL 100kHz 250 –
tSU;STO Setup time for STOP condition fSCL 100kHz 4.0 –
tBUF
Bus free time between a STOP and START
condition fSCL 100kHz 4.7 –
VBUS – 0.4V
350µA ------------------------------- VBUS – 0.4V
100µA -------------------------------
233
8042E–AVR–09/2013
ATmega16HVB/32HVB
Figure 32-1. Two-wire serial bus timing.
32.14 SPI timing characteristics
See Figure 32-2 on page 234 and SPI interface timing requirements (Slave mode).234 for
details.
Note: 1. Refer to ”Serial programming” on page 207 for serial programming requirements.
t
SU;STA
t
LOW
t
HIGH
t
LOW
t
of
t
HD;STA t
HD;DAT t
SU;DAT t
SU;STO
t
BUF
SCL
SDA
t
r
Table 32-16. SPI timing parameters.
Description Mode Minimum Typical Maximum Units
1 SCK period Master See Figure 18-5
on page 106
ns
2 SCK high/low Master 50% duty cycle
3 Rise/fall time Master 3.6
4 Setup Master 10
5 Hold Master 10
6 Out to SCK Master 0.5 • tsck
7 SCK to out Master 10
8 SCK to out high Master 10
9 SS low to out Slave 15
10 SCK period Slave 4 • tck + 40ns
11 SCK high/low (1) Slave 2 • tck + 20ns
12 Rise/fall time Slave 1.6 µs
13 Setup Slave 10
ns
14 Hold Slave tck
15 SCK to out Slave 15
16 SCK to SS high Slave 20
17 SS high to tri-state Slave 10
18 SS low to SCK Slave 20
234
8042E–AVR–09/2013
ATmega16HVB/32HVB
Figure 32-2. SPI interface timing requirements (Master mode).
SPI interface timing requirements (Slave mode).
32.15 Serial programming characteristics
Figure 32-3. Serial programming timing.
MOSI
(Data Output)
SCK
(CPOL = 1)
MISO
(Data Input)
SCK
(CPOL = 0)
SS
MSB LSB
MSB LSB
...
...
6 1
2 2
4 5 3
7 8
MISO
(Data Output)
SCK
(CPOL = 1)
MOSI
(Data Input)
SCK
(CPOL = 0)
SS
MSB LSB
MSB LSB
...
...
10
11 11
13 14 12
15 17
9
X
16
MOSI
MISO
SCK
t
OVSH
t
SHSL
t t
SHOX SLSH
t
SLIV
235
8042E–AVR–09/2013
ATmega16HVB/32HVB
Figure 32-4. Serial programming waveforms.
Note: 1. 2.2 tCLCL for fck < 12MHz, 3 tCLCL for fck >= 12MHz.
32.16 Parallel programming characteristics
Figure 32-5. Parallel programming timing, including some general timing requirements.
MSB
MSB
LSB
LSB
SERIAL CLOCK INPUT
(SCK)
SERIAL DATA INPUT
(MOSI)
(MISO)
SAMPLE
SERIAL DATA OUTPUT
Table 32-17. Serial programming characteristics, TA = -40C to +85C, VCC = 3.3V (unless otherwise stated).
Symbol Parameter Min. Typ. Max. Units
1/tCLCL Oscillator frequency (the Atmel ATmega16HVB/32HVB) 0 8 MHz
tCLCL Oscillator period (ATmega16HVB/32HVB) 125
ns
t
SHSL SCK pulse width high 2.2 tCLCL (1)
t
SLSH SCK pulse width low 2.2 tCLCL
(1)
t
OVSH MOSI setup to SCK high tCLCL
t
SHOX MOSI Hold after SCK High 2 tCLCL
tSLIV SCK Low to MISO Valid 15
Data & Contol
(DATA, XA0/1, BS1, BS2)
XTAL1 t
XHXL
t
WLWH
t
DVXH t
XLDX
t
PLWL
t
WLRH
WR
RDY/BSY
PAGEL t
PHPL
t
PLBX t
BVPH
t
XLWL
t
WLBX
tBVWL
WLRL
236
8042E–AVR–09/2013
ATmega16HVB/32HVB
Figure 32-6. Parallel programming timing, loading sequence with timing requirements(1).
Note: 1. The timing requirements shown in Figure 32-5 on page 235 (that is, tDVXH, tXHXL, and tXLDX)
also apply to loading operation.
Figure 32-7. Parallel programming timing, reading sequence (within the same page) with timing
requirements (1).
Note: 1. The timing requirements shown in Figure 32-5 on page 235 (that is, tDVXH, tXHXL, and tXLDX)
also apply to reading operation.
Table 32-18. Parallel programming characteristics.
Symbol Parameter Min. Typ. Max. Units
VPP Programming enable voltage (RESET input) 11.5 12.5 V
IPP Programming enable current 250 A
tDVXH Data and control valid before XTAL1 high 67
ns
tXLXH XTAL1 low to XTAL1 high 200
tXHXL XTAL1 pulse Width high 150
tXLDX Data and control hold after XTAL1 low 67
XTAL1
PAGEL
t XLXH PLXH t t
XLPH
DATA ADDR0 (Low Byte) DATA (Low Byte) DATA (High Byte) ADDR1 (Low Byte)
BS1
XA0
XA1
LOAD ADDRESS
(LOW BYTE)
LOAD DATA
(LOW BYTE)
LOAD DATA
(HIGH BYTE)
LOAD DATA LOAD ADDRESS
(LOW BYTE)
XTAL1
OE
DATA ADDR0 (Low Byte) DATA (Low Byte) DATA (High Byte) ADDR1 (Low Byte)
BS1
XA0
XA1
LOAD ADDRESS
(LOW BYTE)
READ DATA
(LOW BYTE)
READ DATA
(HIGH BYTE)
LOAD ADDRESS
(LOW BYTE)
t
BVDV
t
OLDV
t
XLOL
t
OHDZ
237
8042E–AVR–09/2013
ATmega16HVB/32HVB
Notes: 1. tWLRH is valid for the Write Flash, Write Fuse bits and Write Lock bits commands.
2. is valid for the Write EEPROM command.
3. tWLRH_CE is valid for the Chip Erase command.
tXLWL XTAL1 low to WR low 0
ns
t
XLPH XTAL1 low to PAGEL high 0
tPLXH PAGEL low to XTAL1 high 150
tBVPH BS1 valid before PAGEL high 67
tPHPL PAGEL pulse width high 150
tPLBX BS1 hold after PAGEL low 67
t
WLBX
BS2/1 hold after WR low. (Fuse programming) 3200
BS2/1 hold after WR low. (All other operations) 67
tPLWL PAGEL low to WR low 67
tBVWL BS1 valid to WR low 67
tWLWH WR pulse Width low 150
tWLRL WR low to RDY/BSY low 0 1 µs
tWLRH WR low to RDY/BSY high (1) 3.7 4.5
tWLRH_EE WR low to RDY/BSY high ms (2) 2.8 3.6
tWLRH_CE WR low to RDY/BSY high for chip erase (3) 7.5 9.1
tXLOL XTAL1 low to OE low 0
ns
tBVDV BS1 valid to DATA valid 0 250
tOLDV OE low to DATA Valid 250
tOHDZ OE high to DATA Tri-stated 250
Table 32-18. Parallel programming characteristics. (Continued)
Symbol Parameter Min. Typ. Max. Units
238
8042E–AVR–09/2013
ATmega16HVB/32HVB
33. Typical characteristics
All Typical Characteristics contained in this data sheet are based on characterization of the
Atmel ATmega16/32HVB.
33.1 Supply current characteristics
33.1.1 Active supply current characteristics
Active mode current measurements with all bits in the PRR registers set and all I/O modules
turned off.
Figure 33-1. Active supply current vs. VVFET, internal RC oscillator, 8MHz.
85°C
25°C
-40°C
3.6
3.65
3.7
3.75
3.8
3.85
3.9
3.95
4
4 6 8 10 12 14 16 18 20
VVFET [V]
I [mA] VFET
239
8042E–AVR–09/2013
ATmega16HVB/32HVB
Figure 33-2. Active supply current vs. VVFET, internal RC oscillator, 4MHz.
Figure 33-3. Active supply current vs. VVFET, internal RC oscillator, 2MHz.
85°C
25°C
-40°C
2.2
2.24
2.28
2.32
2.36
2.4
2.44
4 6 8 10 12 14 16 18 20
VVFET [V]
I [mA] VFET
85°C
25°C
-40°C
1.21
1.23
1.25
1.27
1.29
1.31
1.33
4 6 8 10 12 14 16 18 20
VVFET [V]
I [mA] VFET
240
8042E–AVR–09/2013
ATmega16HVB/32HVB
Figure 33-4. Active supply current vs. VVFET, internal RC oscillator, 1MHz.
85°C
25°C
-40°C
0.72
0.73
0.74
0.75
0.76
0.77
0.78
0.79
0.8
4 6 8 10 12 14 16 18 20
VVFET [V]
I [mA] VFET
241
8042E–AVR–09/2013
ATmega16HVB/32HVB
33.1.2 Idle supply current characteristics
Idle current consumption measurements with all bits in the PRR registers set and all I/O modules
are turned off.
Figure 33-5. Idle supply current vs. VVFET, internal RC oscillator, 8MHz.
Figure 33-6. Idle supply current vs. VVFET, internal RC oscillator, 4MHz.
85°C
25°C
-40°C
0.675
0.695
0.715
0.735
0.755
0.775
0.795
0.815
4 6 8 10 12 14 16 18 20
VVFET [V]
I [mA] VFET
85°C
25°C
-40°C
0.42
0.43
0.44
0.45
0.46
0.47
0.48
4 6 8 10 12 14 16 18 20
VVFET [V]
I [mA] VFET
242
8042E–AVR–09/2013
ATmega16HVB/32HVB
Figure 33-7. Idle supply current vs. VVFET, internal RC oscillator, 2MHz.
Figure 33-8. Idle supply current vs. VVFET, internal RC oscillator, 1MHz.
85°C
25°C
-40°C
0.28
0.284
0.288
0.292
0.296
0.3
0.304
0.308
4 6 8 10 12 14 16 18 20
VVFET [V]
I [mA] VFET
85°C
25°C
-40°C
0.205
0.209
0.213
0.217
0.221
0.225
4 6 8 10 12 14 16 18 20
VVFET [V]
I [mA] VFET
243
8042E–AVR–09/2013
ATmega16HVB/32HVB
33.1.3 Power-save current characteristics
Power-save current consumption with External Interrupt and SMBus connect/disconnect functionality
enabled. The Watchdog Timer, CC-ADC, Current Battery Protection (CBP), VREF, and
OC/OD are disabled.
Figure 33-9. Power-save supply current vs. VVFET, external interrupt and SMBus enabled, all
other modules disabled.
Table 33-1 shows additional current consumption that needs to be added to the total power-budget
when additional modules are enableds.
Note: 1. Default I/O register configuration used. PPI and NNI connected to GND.
2. Measurements done with Fairchild FDS6690A N-Channel MOSFET.
Figure 33-11 on page 245 shows Power-Save current consumption vs VFET with all modules
listed in Table 33-1 enabled. The increased power consumption for low VFET voltage is caused
by the NFET driver operation described in Section 25.3 ”Operation and usage” on page 146.
Table 33-1. Typical additional I/O modules current consumption in power-save.
I/O modules enabled Typical current consumption
WDT VREF CBP (1) OC/OD (2) CC-ADC (TA = 25°C and VVFET = 12V)
X 0.8µA
X X 12µA
XXXX 41µA
XXXXX 85µA
85°C
25°C
-40°C
17
19
21
23
25
27
29
31
33
35
4 6 8 10 12 14 16 18 20
VVFET [V]
I [µA] VFET
244
8042E–AVR–09/2013
ATmega16HVB/32HVB
Figure 33-10. Power-save supply current vs. VVFET, WDT, VREF, CBP, OC/OD, and CC-ADC
enabled.
100
120
140
160
180
200
220
240
4 6 8 10 12 14 16 18
VFET [V]
85°C
25°C
-40°C
I [µA] VFET
245
8042E–AVR–09/2013
ATmega16HVB/32HVB
33.1.4 Power-off current characteristics
Figure 33-11. Power-off supply current vs. VVFET.
33.2 NFET driver characteristics
33.2.1 OC/OD levels
Figure 33-12. OC/OD pin voltage vs. VVFET .
85°C
25°C
-40°C
0.6
0.8
1
1.2
1.4
1.6
1.8
4 6 8 10 12 14 16 18 20
VVFET [V]
I [µA] VFET
85°C
25°C
-40°C
6 8 10 12 14 16 18
VVFET [V]
10
15
20
25
30
35
Pin Voltage [V]
246
8042E–AVR–09/2013
ATmega16HVB/32HVB
33.2.2 OC/OD rise time from 0V to 2V gate-source voltage with 4.7nF load
Figure 33-13. OC/OD rise time, VGS = 0V to 2V vs. VVFET .
33.2.3 OC/OD rise time from 2V to 4V gate-source voltage with 4.7nF load
Figure 33-14. OC/OD rise time, VGS = 2V to 4V vs. VVFET .
0
200
400
600
800
1000
1200
1400
1600
1800
6 8 10 12 14 16 18
VFET [V]
Time [µs]
T =25°C
T =70°C
0
200
400
600
800
1000
1200
1400
1600
6 8 10 12 14 16 18
VFET [V]
Time [µs]
T =25°C
T =70°C
247
8042E–AVR–09/2013
ATmega16HVB/32HVB
Figure 33-15. OC/OD drive capability vs temperature.
3
3.5
4
4.5
5
5.5
6
6.5
7
7.5
8
-10 10 30 50 70 90
Temperature [°C]
Max Load [µA]
VFET = 6V VFET = 9.5V VFET = 12V
248
8042E–AVR–09/2013
ATmega16HVB/32HVB
33.3 Battery protection characteristics
Figure 33-16. Battery protection level.
33.4 Clock characteristics
33.4.1 Fast RC oscillator characteristics
Figure 33-17. Fast RC oscillator frequency vs. temperature (after factory calibration).
10
60
110
160
210
260
310
[mV] Detection Level
Max
TYP(25°C)
F3 F4 F5 F6 F7 F8 F9 FA FB FC FD 77 78 79 7A 7B 7C 7D 37 38 39 3A 3B 3C 3D 17
Min
Register Value
7.75
7.8
7.85
7.9
7.95
8
8.05
8.1
-40 -30 -20 -10 0 10 20 30 40 50 60 70 80 90
Temperature [°C]
[MHz] Frequency
249
8042E–AVR–09/2013
ATmega16HVB/32HVB
Figure 33-18. Calibrated fast RC oscillator frequency vs. OSCCAL value.
33.4.2 Ultra low power RC oscillator characteristics
Figure 33-19. ULP RC oscillator frequency vs. temperature.
25°C
16
14
12
10
8
6
4
0 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256
OSCCAL VALUE
FRC (MHz)
105
106
107
108
109
110
111
112
113
-40 -30 -20 -10 0 10 20 30 40 50 60 70 80 90
Temperature [°C]
Frequency [kHz]
250
8042E–AVR–09/2013
ATmega16HVB/32HVB
33.4.3 Slow RC oscillator characteristics
Figure 33-20. Slow RC oscillator frequency vs. temperature.
Figure 33-21. Typical SlowRC frequency frequency prediction error based on algorithm in Section
9.2.2 on page 27.
127.0
128.0
129.0
130.0
131.0
132.0
133.0
134.0
Temperature [°C]
Frequency [kHz]
-40 -20 0 20 40 60 80 100
-0.4%
-0.2%
0.0%
0.2%
0.4%
0.6%
0.8%
1.0%
1.2%
1.4%
-40 -20 0 20 40 60 80 100
Temperature [°C]
Frequency prediction error [%]
251
8042E–AVR–09/2013
ATmega16HVB/32HVB
33.5 Voltage reference characteristics
Figure 33-22. Typical VREF curve with Atmel factory calibration at 25°C and 85°C.
Figure 33-23. Typical VREF deviation curve with Atmel factory calibration at 25°C and 85°C.
Temperature [°C]
-40 -20 0 20 40 60 80
1.091
1.092
1.093
1.094
1.095
1.096
1.097
1.098
1.099
1.100
1.101
VREF [V]
252
8042E–AVR–09/2013
ATmega16HVB/32HVB
33.6 Voltage regulator characteristics
Figure 33-24. Voltage regulator vs. VVFET, ILOAD = 10mA.
Figure 33-25. Voltage regulator vs. VVFET, ILOAD = 20mA.
85°C
25°C
-40°C
3.21
3.22
3.23
3.24
3.25
3.26
3.27
4 6 8 10 12 14 16 18 20 22 24 26
VVFET [V]
VREG [V]
85°C
25°C
-40°C
2.4
2.5
2.6
2.7
2.8
2.9
3
3.1
3.2
3.3
4 6 8 10 12 14 16 18 20 22 24 26
VVFET [V]
VREG [V]
253
8042E–AVR–09/2013
ATmega16HVB/32HVB
Figure 33-26. Voltage regulator short-circuit level at VVFET pin vs. temperature.
Figure 33-27. BLOD level.
3.45
3.5
3.55
3.6
3.65
3.7
3.75
-40 -30 -20 -10 0 10 20 30 40 50 60 70 80 90
Temperature [°C]
VRSCL [V]
Rising
Falling
2.637
2.639
2.641
2.643
2.645
2.647
2.649
2.651
2.653
2.655
2.657
2.659
2.661
-40 -30 -20 -10 0 10 20 30 40 50 60 70 80 90
Temperature [°C]
VBLOD [V]
254
8042E–AVR–09/2013
ATmega16HVB/32HVB
33.7 BOD threshold characteristics
Figure 33-28. BOD level.
Falling
Rising
2.82
2.84
2.86
2.88
2.9
2.92
2.94
2.96
2.98
3
-40 -30 -20 -10 0 10 20 30 40 50 60 70 80 90
Temperature [°C]
VCC [V]
255
8042E–AVR–09/2013
ATmega16HVB/32HVB
34. Register summary
Address Name Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 Page
(0xFF) Reserved – – – – – – – –
(0xFE) BPPLR – – – – – – BPPLE BPPL 137
(0xFD) BPCR – – EPID SCD DOCD COCD DHCD CHCD 138
(0xFC) BPHCTR – – HCPT[5:0] 140
(0xFB) BPOCTR – – OCPT[5:0] 139
(0xFA) BPSCTR – SCPT[6:0] 139
(0xF9) BPCHCD CHCDL[7:0] 142
(0xF8) BPDHCD DHCDL[7:0] 142
(0xF7) BPCOCD COCDL[7:0] 142
(0xF6) BPDOCD DOCDL[7:0] 141
(0xF5) BPSCD SCDL[7:0] 141
(0xF4) Reserved – – – – – – – –
(0xF3) BPIFR – – – SCIF DOCIF COCIF DHCIF CHCIF 144
(0xF2) BPIMSK – – – SCIE DOCIE COCIE DHCIE CHCIE 143
(0xF1) CBCR – – – – CBE4 CBE3 CBE2 CBE1 152
(0xF0) FCSR – – – – DUVRD CPS DFE CFE 149
(0xEF) Reserved – – – – – – – –
(0xEE) Reserved – – – – – – – –
(0xED) Reserved – – – – – – – –
(0xEC) Reserved – – – – – – – –
(0xEB) Reserved – – – – – – – –
(0xEA) CADRDC CADRDC[7:0] 115
(0xE9) CADRCC CADRCC[7:0] 114
(0xE8) CADCSRC - - - - - - - CADVSE 114
(0xE7) CADCSRB – CADACIE CADRCIE CADICIE – CADACIF CADRCIF CADICIF 112
(0xE6) CADCSRA CADEN CADPOL CADUB CADAS[1:0] CADSI[1:0] CADSE 111
(0xE5) CADICH CADIC[15:8] 114
(0xE4) CADICL CADIC[7:0] 114
(0xE3) CADAC3 CADAC[31:24] 114
(0xE2) CADAC2 CADAC[23:16] 114
(0xE1) CADAC1 CADAC[15:8] 114
(0xE0) CADAC0 CADAC[7:0] 114
(0xDF) Reserved – – – – – – – –
(0xDE) Reserved – – – – – – – –
(0xDD) Reserved – – – – – – – –
(0xDC) Reserved – – – – – – – –
(0xDB) Reserved – – – – – – – –
(0xDA) Reserved – – – – – – – –
(0xD9) Reserved – – – – – – – –
(0xD8) Reserved – – – – – – – –
(0xD7) Reserved – – – – – – – –
(0xD6) Reserved – – – – – – – –
(0xD5) Reserved – – – – – – – –
(0xD4) CHGDCSR – – – BATTPVL CHGDISC1 CHGDISC1 CHGDIF CHGDIE 128
(0xD3) Reserved – – – – – – – –
(0xD2) BGCSR – – BGD BGSCDE – – BGSCDIF BGSCDIE 125
(0xD1) BGCRR BGCR[7:0] 124
(0xD0) BGCCR – – BGCC[5:0] 255
(0xCF) Reserved – – – – – – – –
(0xCE) Reserved – – – – – – – –
(0xCD) Reserved – – – – – – – –
(0xCC) Reserved – – – – – – – –
(0xCB) Reserved – – – – – – – –
(0xCA) Reserved – – – – – – – –
(0xC9) Reserved – – – – – – – –
(0xC8) ROCR ROCS – – ROCD – – ROCWIF ROCWIE 131
(0xC7) Reserved – – – – – – – –
(0xC6) Reserved – – – – – – – –
(0xC5) Reserved – – – – – – – –
(0xC4) Reserved – – – – – – – –
(0xC3) Reserved – – – – – – – –
(0xC2) Reserved – – – – – – – –
(0xC1) Reserved – – – – – – – –
(0xC0) Reserved – – – – – – – –
256
8042E–AVR–09/2013
ATmega16HVB/32HVB
(0xBF) Reserved – – – – – – – –
(0xBE) TWBCSR TWBCIF TWBCIE – – – TWBDT1 TWBDT0 TWBCIP 184
(0xBD) TWAMR TWAM[6:0] – 184
(0xBC) TWCR TWINT TWEA TWSTA TWSTO TWWC TWEN – TWIE 181
(0xBB) TWDR 2–wire Serial Interface Data Register 183
(0xBA) TWAR TWA[6:0] TWGCE 183
(0xB9) TWSR TWS[7:3] – TWPS1 TWPS0 182
(0xB8) TWBR 2–wire Serial Interface Bit Rate Register 181
(0xB7) Reserved – – – – – – –
(0xB6) Reserved – – – – – – – –
(0xB5) Reserved – – – – – – – –
(0xB4) Reserved – – – – – – – –
(0xB3) Reserved – – – – – – – –
(0xB2) Reserved – – – – – – – –
(0xB1) Reserved – – – – – – – –
(0xB0) Reserved – – – – – – – –
(0xAF) Reserved – – – – – – – –
(0xAE) Reserved – – – – – – – –
(0xAD) Reserved – – – – – – – –
(0xAC) Reserved – – – – – – – –
(0xAB) Reserved – – – – – – – –
(0xAA) Reserved – – – – – – – –
(0xA9) Reserved – – – – – – – –
(0xA8) Reserved – – – – – – – –
(0xA7) Reserved – – – – – – – –
(0xA6) Reserved – – – – – – – –
(0xA5) Reserved – – – – – – – –
(0xA4) Reserved – – – – – – – –
(0xA3) Reserved – – – – – – – –
(0xA2) Reserved – – – – – – – –
(0xA1) Reserved – – – – – – – –
(0xA0) Reserved – – – – – – – –
(0x9F) Reserved – – – – – – – –
(0x9E) Reserved – – – – – – – –
(0x9D) Reserved – – – – – – – –
(0x9C) Reserved – – – – – – – –
(0x9B) Reserved – – – – – – – –
(0x9A) Reserved – – – – – – – –
(0x99) Reserved – – – – – – – –
(0x98) Reserved – – – – – – – –
(0x97) Reserved – – – – – – – –
(0x96) Reserved – – – – – – – –
(0x95) Reserved – – – – – – – –
(0x94) Reserved – – – – – – – –
(0x93) Reserved – – – – – – – –
(0x92) Reserved – – – – – – – –
(0x91) Reserved – – – – – – – –
(0x90) Reserved – – – – – – – –
(0x8F) Reserved – – – – – – – –
(0x8E) Reserved – – – – – – – –
(0x8D) Reserved – – – – – – – –
(0x8C) Reserved – – – – – – – –
(0x8B) Reserved – – – – – – – –
(0x8A) Reserved – – – – – – – –
(0x89) OCR1B Timer/Counter1 – Output Compare Register B 95
(0x88) OCR1A Timer/Counter1 – Output Compare Register A 95
(0x87) Reserved – – – – – – – –
(0x86) Reserved – – – – – – – –
(0x85) TCNT1H Timer/Counter1 (8 Bit) High Byte 95
(0x84) TCNT1L Timer/Counter1 (8 Bit) Low Byte 95
(0x83) Reserved – – – – – – – –
(0x82) Reserved – – – – – – – –
(0x81) TCCR1B – – – – – CS12 CS11 CS10 81
(0x80) TCCR1A TCW1 ICEN1 ICNC1 ICES1 ICS1 – – WGM10 94
(0x7F) Reserved – – – – – – – –
(0x7E) DIDR0 – – – – – – PA1DID PA0DID 121
Address Name Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 Page
257
8042E–AVR–09/2013
ATmega16HVB/32HVB
(0x7D) Reserved – – – – – – – –
(0x7C) VADMUX – – – – VADMUX[3:0] 119
(0x7B) Reserved – – – – – – – –
(0x7A) VADCSR – – – – VADEN VADSC VADCCIF VADCCIE 119
(0x79) VADCH – – – – VADC Data Register High byte 120
(0x78) VADCL VADC Data Register Low byte 120
(0x77) Reserved – – – – – – – –
(0x76) Reserved – – – – – – – –
(0x75) Reserved – – – – – – – –
(0x74) Reserved – – – – – – – –
(0x73) Reserved – – – – – – – –
(0x72) Reserved – – – – – – – –
(0x71) Reserved – – – – – – – –
(0x70) Reserved – – – – – – – –
(0x6F) TIMSK1 – – – – ICIE1 OCIE1B OCIE1A TOIE1 96
(0x6E) TIMSK0 – – – – ICIE0 OCIE0B OCIE0A TOIE0 96
(0x6D) Reserved – – – – – – – –
(0x6C) PCMSK1 PCINT[15:8] 60
(0x6B) PCMSK0 – – – – PCINT[3:0] 61
(0x6A) Reserved – – – – – – – –
(0x69) EICRA ISC31 ISC30 ISC21 ISC20 ISC11 ISC10 ISC01 ISC00 58
(0x68) PCICR – – – – – – PCIE1 PCIE0 60
(0x67) Reserved – – – – – – – –
(0x66) FOSCCAL Fast Oscillator Calibration Register 32
(0x65) Reserved – – – – – – – –
(0x64) PRR0 – PRTWI PRVRM – PRSPI PRTIM1 PRTIM0 PRVADC 40
(0x63) Reserved – – – – – – – –
(0x62) Reserved – – – – – – – –
(0x61) CLKPR CLKPCE – – – – – CLKPS1 CLKPS0 32
(0x60) WDTCSR WDIF WDIE WDP3 WDCE WDE WDP2 WDP1 WDP0 49
0x3F (0x5F) SREG I T H S V N Z C 10
0x3E (0x5E) SPH SP15 SP14 SP13 SP12 SP11 SP10 SP9 SP8 13
0x3D (0x5D) SPL SP7 SP6 SP5 SP4 SP3 SP2 SP1 SP0 13
0x3C (0x5C) Reserved – – – – – – – –
0x3B (0x5B) Reserved – – – – – – – –
0x3A (0x5A) Reserved – – – – – – – –
0x39 (0x59) Reserved – – – – – – – –
0x38 (0x58) Reserved – – – – – – – –
0x37 (0x57) SPMCSR SPMIE RWWSB SIGRD CTPB RFLB PGWRT PGERS SPMEN 202
0x36 (0x56) Reserved – – – – – – – –
0x35 (0x55) MCUCR – – CKOE PUD – – IVSEL IVCE 78/32
0x34 (0x54) MCUSR – – – OCDRF WDRF BODRF EXTRF PORF 49
0x33 (0x53) SMCR – – – – SM[2:0] SE 39
0x32 (0x52) Reserved – – – – – – – –
0x31 (0x51) DWDR debugWIRE Data Register 187
0x30 (0x50) Reserved – – – – – – – –
0x2F (0x4F) Reserved – – – – – – – –
0x2E (0x4E) SPDR SPI Data Register 107
0x2D (0x4D) SPSR SPIF WCOL – – – – – SPI2X 106
0x2C (0x4C) SPCR SPIE SPE DORD MSTR CPOL CPHA SPR1 SPR0 105
0x2B (0x4B) GPIOR2 General Purpose I/O Register 2 24
0x2A (0x4A) GPIOR1 General Purpose I/O Register 1 24
0x29 (0x49) OCR0B Timer/Counter0 Output Compare Register B 95
0x28 (0x48) OCR0A Timer/Counter0 Output Compare Register A 95
0x27 (0x47) TCNT0H Timer/Counter0 (8 Bit) High Byte 95
0x26 (0x46) TCNT0L Timer/Counter0 (8 Bit) Low Byte 95
0x25 (0x45) TCCR0B – – – – – CS02 CS01 CS00 81
0x24 (0x44) TCCR0A TCW0 ICEN0 ICNC0 ICES0 ICS0 – – WGM00 94
0x23 (0x43) GTCCR TSM – – – – – – PSRSYNC
0x22 (0x42) EEARH – – – – – – EEPROM High byte 20
0x21 (0x41) EEARL EEPROM Address Register Low Byte 20
0x20 (0x40) EEDR EEPROM Data Register 20
0x1F (0x3F) EECR – – EEPM1 EEPM0 EERIE EEMPE EEPE EERE 21
0x1E (0x3E) GPIOR0 General Purpose I/O Register 0 24
0x1D (0x3D) EIMSK – – – – INT3 INT2 INT1 INT0 59
0x1C (0x3C) EIFR – – – – INTF3 INTF2 INTF1 INTF0 59
Address Name Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 Page
258
8042E–AVR–09/2013
ATmega16HVB/32HVB
Notes: 1. For compatibility with future devices, reserved bits should be written to zero if accessed. Reserved I/O memory addresses
should never be written.
2. I/O registers within the address range $00 - $1F are directly bit-accessible using the SBI and CBI instructions. In these registers,
the value of single bits can be checked by using the SBIS and SBIC instructions.
3. Some of the status flags are cleared by writing a logical one to them. Note that the CBI and SBI instructions will operate on
all bits in the I/O register, writing a one back into any flag read as set, thus clearing the flag. The CBI and SBI instructions
work with registers 0x00 to 0x1F only.
4. When using the I/O specific commands IN and OUT, the I/O addresses $00 - $3F must be used. When addressing I/O registers
as data space using LD and ST instructions, $20 must be added to these addresses. The Atmel
ATmega16HVB/32HVB is a complex microcontroller with more peripheral units than can be supported within the 64 location
reserved in Opcode for the IN and OUT instructions. For the Extended I/O space from $60 - $FF in SRAM, only the
ST/STS/STD and LD/LDS/LDD instructions can be used.
0x1B (0x3B) PCIFR – – – – – – PCIF1 PCIF0 60
0x1A (0x3A) Reserved – – – – – – – –
0x19 (0x39) Reserved – – – – – – – –
0x18 (0x38) Reserved – – – – – – – –
0x17 (0x37) OSICSR – – – OSISEL0 – – OSIST OSIEN 33
0x16 (0x36) TIFR1 – – – – ICF1 OCF1B OCF1A TOV1 96
0x15 (0x35) TIFR0 – – – – ICF0 OCF0B OCF0A TOV0 96
0x14 (0x34) Reserved – – – – – – – –
0x13 (0x33) Reserved – – – – – – – –
0x12 (0x32) Reserved – – – – – – – –
0x11 (0x31) Reserved – – – – – – – –
0x10 (0x30) Reserved – – – – – – – –
0x0F (0x2F) Reserved – – – – – – – –
0x0E (0x2E) Reserved – – – – – – – –
0x0D (0x2D) Reserved – – – – – – – –
0x0C (0x2C) Reserved – – – – – – – –
0x0B (0x2B) Reserved – – – – – – – –
0x0A (0x2A) Reserved – – – – – – – –
0x09 (0x29) Reserved – – – – – – – –
0x08 (0x28) PORTC – – PORTC5 PORTC4 PORTC3 PORTC2 PORTC1 PORTC0 66
0x07 (0x27) Reserved – – – – – – – –
0x06 (0x26) PINC – – – PINC4 PINC3 PINC2 PINC1 PINC0 66
0x05 (0x25) PORTB PORTB7 PORTB6 PORTB5 PORTB4 PORTB3 PORTB2 PORTB1 PORTB0 78
0x04 (0x24) DDRB DDB7 DDB6 DDB5 DDB4 DDB3 DDB2 DDB1 DDB0 78
0x03 (0x23) PINB PINB7 PINB6 PINB5 PINB4 PINB3 PINB2 PINB1 PINB0 78
0x02 (0x22) PORTA – – – – PORTA3 PORTA2 PORTA1 PORTA0 78
0x01 (0x21) DDRA – – – – DDA3 DDA2 DDA1 DDA0 78
0x00 (0x20) PINA – – – – PINA3 PINA2 PINA1 PINA0 78
Address Name Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 Page
259
8042E–AVR–09/2013
ATmega16HVB/32HVB
35. Instruction set summary
Mnemonics Operands Description Operation Flags #Clocks
ARITHMETIC AND LOGIC INSTRUCTIONS
ADD Rd, Rr Add two Registers Rd Rd + Rr Z, C, N, V, H 1
ADC Rd, Rr Add with Carry two Registers Rd Rd + Rr + C Z, C, N, V, H 1
ADIW Rdl, K Add Immediate to Word Rdh:Rdl Rdh:Rdl + K Z, C, N, V, S 2
SUB Rd, Rr Subtract two Registers Rd Rd - Rr Z, C, N, V, H 1
SUBI Rd, K Subtract Constant from Register Rd Rd - K Z, C, N, V, H 1
SBC Rd, Rr Subtract with Carry two Registers Rd Rd - Rr - C Z, C, N, V, H 1
SBCI Rd, K Subtract with Carry Constant from Reg. Rd Rd - K - C Z, C, N, V, H 1
SBIW Rdl,K Subtract Immediate from Word Rdh:Rdl Rdh:Rdl - K Z, C, N, V, S 2
AND Rd, Rr Logical AND Registers Rd Rd Rr Z, N, V 1
ANDI Rd, K Logical AND Register and Constant Rd Rd K Z, N, V 1
OR Rd, Rr Logical OR Registers Rd Rd v Rr Z, N, V 1
ORI Rd, K Logical OR Register and Constant Rd Rd v K Z, N, V 1
EOR Rd, Rr Exclusive OR Registers Rd Rd Rr Z, N, V 1
COM Rd One’s Complement Rd 0xFF Rd Z, C, N, V 1
NEG Rd Two’s Complement Rd 0x00 Rd Z, C, N, V, H 1
SBR Rd, K Set Bit(s) in Register Rd Rd v K Z, N, V 1
CBR Rd, K Clear Bit(s) in Register Rd Rd (0xFF - K) Z, N, V 1
INC Rd Increment Rd Rd + 1 Z, N, V 1
DEC Rd Decrement Rd Rd 1 Z, N, V 1
TST Rd Test for Zero or Minus Rd Rd Rd Z, N, V 1
CLR Rd Clear Register Rd Rd Rd Z, N ,V 1
SER Rd Set Register Rd 0xFF None 1
MUL Rd, Rr Multiply Unsigned R1:R0 Rd x Rr Z, C 2
MULS Rd, Rr Multiply Signed R1:R0 Rd x Rr Z, C 2
MULSU Rd, Rr Multiply Signed with Unsigned R1:R0 Rd x Rr Z, C 2
FMUL Rd, Rr Fractional Multiply Unsigned R1:R0 (Rd x Rr) << 1 Z, C 2
FMULS Rd, Rr Fractional Multiply Signed R1:R0 (Rd x Rr) << 1 Z, C 2
FMULSU Rd, Rr Fractional Multiply Signed with Unsigned R1:R0 (Rd x Rr) << 1 Z, C 2
BRANCH INSTRUCTIONS
RJMP k Relative Jump PC PC + k + 1 None 2
IJMP Indirect Jump to (Z) PC Z None 2
JMP k Direct Jump PC k None 3
RCALL k Relative Subroutine Call PC PC + k + 1 None 3
ICALL Indirect Call to (Z) PC Z None 3
CALL k Direct Subroutine Call PC k None 4
RET Subroutine Return PC STACK None 4
RETI Interrupt Return PC STACK I 4
CPSE Rd, Rr Compare, Skip if Equal if (Rd = Rr) PC PC + 2 or 3 None 1/2/3
CP Rd, Rr Compare Rd Rr Z, N, V, C, H 1
CPC Rd, Rr Compare with Carry Rd Rr C Z, N, V, C, H 1
CPI Rd, K Compare Register with Immediate Rd K Z, N, V, C, H 1
SBRC Rr, b Skip if Bit in Register Cleared if (Rr(b) = 0) PC PC + 2 or 3 None 1/2/3
SBRS Rr, b Skip if Bit in Register is Set if (Rr(b) = 1) PC PC + 2 or 3 None 1/2/3
SBIC P, b Skip if Bit in I/O Register Cleared if (P(b) = 0) PC PC + 2 or 3 None 1/2/3
SBIS P, b Skip if Bit in I/O Register is Set if (P(b) = 1) PC PC + 2 or 3 None 1/2/3
BRBS s, k Branch if Status Flag Set if (SREG(s) = 1) then PCPC+k + 1 None 1/2
BRBC s, k Branch if Status Flag Cleared if (SREG(s) = 0) then PCPC+k + 1 None 1/2
BREQ k Branch if Equal if (Z = 1) then PC PC + k + 1 None 1/2
BRNE k Branch if Not Equal if (Z = 0) then PC PC + k + 1 None 1/2
BRCS k Branch if Carry Set if (C = 1) then PC PC + k + 1 None 1/2
BRCC k Branch if Carry Cleared if (C = 0) then PC PC + k + 1 None 1/2
BRSH k Branch if Same or Higher if (C = 0) then PC PC + k + 1 None 1/2
BRLO k Branch if Lower if (C = 1) then PC PC + k + 1 None 1/2
BRMI k Branch if Minus if (N = 1) then PC PC + k + 1 None 1/2
BRPL k Branch if Plus if (N = 0) then PC PC + k + 1 None 1/2
BRGE k Branch if Greater or Equal, Signed if (N V= 0) then PC PC + k + 1 None 1/2
BRLT k Branch if Less Than Zero, Signed if (N V= 1) then PC PC + k + 1 None 1/2
BRHS k Branch if Half Carry Flag Set if (H = 1) then PC PC + k + 1 None 1/2
BRHC k Branch if Half Carry Flag Cleared if (H = 0) then PC PC + k + 1 None 1/2
BRTS k Branch if T Flag Set if (T = 1) then PC PC + k + 1 None 1/2
BRTC k Branch if T Flag Cleared if (T = 0) then PC PC + k + 1 None 1/2
BRVS k Branch if Overflow Flag is Set if (V = 1) then PC PC + k + 1 None 1/2
BRVC k Branch if Overflow Flag is Cleared if (V = 0) then PC PC + k + 1 None 1/2
260
8042E–AVR–09/2013
ATmega16HVB/32HVB
BRIE k Branch if Interrupt Enabled if ( I = 1) then PC PC + k + 1 None 1/2
BRID k Branch if Interrupt Disabled if ( I = 0) then PC PC + k + 1 None 1/2
BIT AND BIT-TEST INSTRUCTIONS
SBI P, b Set Bit in I/O Register I/O(P,b) 1 None 2
CBI P, b Clear Bit in I/O Register I/O(P,b) 0 None 2
LSL Rd Logical Shift Left Rd(n+1) Rd(n), Rd(0) 0 Z, C, N, V 1
LSR Rd Logical Shift Right Rd(n) Rd(n+1), Rd(7) 0 Z, C, N, V 1
ROL Rd Rotate Left Through Carry Rd(0)C,Rd(n+1) Rd(n),CRd(7) Z, C, N, V 1
ROR Rd Rotate Right Through Carry Rd(7)C,Rd(n) Rd(n+1),CRd(0) Z, C, N, V 1
ASR Rd Arithmetic Shift Right Rd(n) Rd(n+1), n=0..6 Z, C, N, V 1
SWAP Rd Swap Nibbles Rd(3..0)Rd(7..4),Rd(7..4)Rd(3..0) None 1
BSET s Flag Set SREG(s) 1 SREG(s) 1
BCLR s Flag Clear SREG(s) 0 SREG(s) 1
BST Rr, b Bit Store from Register to T T Rr(b) T 1
BLD Rd, b Bit load from T to Register Rd(b) T None 1
SEC Set Carry C 1 C1
CLC Clear Carry C 0 C 1
SEN Set Negative Flag N 1 N1
CLN Clear Negative Flag N 0 N 1
SEZ Set Zero Flag Z 1 Z1
CLZ Clear Zero Flag Z 0 Z 1
SEI Global Interrupt Enable I 1 I1
CLI Global Interrupt Disable I 0 I 1
SES Set Signed Test Flag S 1 S1
CLS Clear Signed Test Flag S 0 S 1
SEV Set Twos Complement Overflow. V 1 V1
CLV Clear Twos Complement Overflow V 0 V 1
SET Set T in SREG T 1 T1
CLT Clear T in SREG T 0 T 1
SEH Set Half Carry Flag in SREG H 1 H1
CLH Clear Half Carry Flag in SREG H 0 H 1
DATA TRANSFER INSTRUCTIONS
MOV Rd, Rr Move Between Registers Rd Rr None 1
MOVW Rd, Rr Copy Register Word Rd+1:Rd Rr+1:Rr None 1
LDI Rd, K Load Immediate Rd K None 1
LD Rd, X Load Indirect Rd (X) None 2
LD Rd, X+ Load Indirect and Post-Inc. Rd (X), X X + 1 None 2
LD Rd, - X Load Indirect and Pre-Dec. X X - 1, Rd (X) None 2
LD Rd, Y Load Indirect Rd (Y) None 2
LD Rd, Y+ Load Indirect and Post-Inc. Rd (Y), Y Y + 1 None 2
LD Rd, - Y Load Indirect and Pre-Dec. Y Y - 1, Rd (Y) None 2
LDD Rd, Y+q Load Indirect with Displacement Rd (Y + q) None 2
LD Rd, Z Load Indirect Rd (Z) None 2
LD Rd, Z+ Load Indirect and Post-Inc. Rd (Z), Z Z+1 None 2
LD Rd, -Z Load Indirect and Pre-Dec. Z Z - 1, Rd (Z) None 2
LDD Rd, Z+q Load Indirect with Displacement Rd (Z + q) None 2
LDS Rd, k Load Direct from SRAM Rd (k) None 2
ST X, Rr Store Indirect (X) Rr None 2
ST X+, Rr Store Indirect and Post-Inc. (X) Rr, X X + 1 None 2
ST - X, Rr Store Indirect and Pre-Dec. X X - 1, (X) Rr None 2
ST Y, Rr Store Indirect (Y) Rr None 2
ST Y+, Rr Store Indirect and Post-Inc. (Y) Rr, Y Y + 1 None 2
ST - Y, Rr Store Indirect and Pre-Dec. Y Y - 1, (Y) Rr None 2
STD Y+q, Rr Store Indirect with Displacement (Y + q) Rr None 2
ST Z, Rr Store Indirect (Z) Rr None 2
ST Z+, Rr Store Indirect and Post-Inc. (Z) Rr, Z Z + 1 None 2
ST -Z, Rr Store Indirect and Pre-Dec. Z Z - 1, (Z) Rr None 2
STD Z+q, Rr Store Indirect with Displacement (Z + q) Rr None 2
STS k, Rr Store Direct to SRAM (k) Rr None 2
LPM Load Program Memory R0 (Z) None 3
LPM Rd, Z Load Program Memory Rd (Z) None 3
LPM Rd, Z+ Load Program Memory and Post-Inc Rd (Z), Z Z+1 None 3
SPM Store Program Memory (Z) R1:R0 None -
IN Rd, P In Port Rd P None 1
35. Instruction set summary (Continued)
Mnemonics Operands Description Operation Flags #Clocks
261
8042E–AVR–09/2013
ATmega16HVB/32HVB
OUT P, Rr Out Port P Rr None 1
PUSH Rr Push Register on Stack STACK Rr None 2
POP Rd Pop Register from Stack Rd STACK None 2
MCU CONTROL INSTRUCTIONS
NOP No Operation None 1
SLEEP Sleep (see specific descr. for Sleep function) None 1
WDR Watchdog Reset (see specific descr. for WDR/timer) None 1
BREAK Break For On-chip Debug Only None N/A
35. Instruction set summary (Continued)
Mnemonics Operands Description Operation Flags #Clocks
262
8042E–AVR–09/2013
ATmega16HVB/32HVB
36. Ordering information
36.1 The Atmel ATmega16HVB
Speed (MHz) Power supply Ordering code Package Operation range
1MHz - 8MHz 4V - 18V ATMEGA16HVB-8X3 44X1 -40C to 85C
Package type
44X1 44-lead, 4.4mm body width, plastic thin shrink small outline package (TSSOP)
263
8042E–AVR–09/2013
ATmega16HVB/32HVB
36.2 The Atmel ATmega32HVB
Speed (MHz) Power supply Ordering code Package Operation range
1MHz - 8MHz 4V - 18V ATMEGA32HVB-8X3 44X1 -40C to 85C
Package type
44X1 44-lead, 4.4mm body width, plastic thin shrink small outline package (TSSOP)
264
8042E–AVR–09/2013
ATmega16HVB/32HVB
37. Packaging information
37.1 44X1
TITLE DRAWING NO.
R
REV.
Note: These drawings are for general information only. Refer to JEDEC Drawing MO-153BE.
2325 Orchard Parkway
San Jose, CA 95131
5/16/07
44X1, 44-lead, 4.4 mm Body Width, Plastic Thin Shrink
Small Outline Package (TSSOP) 44X1 A
COMMON DIMENSIONS
(Unit of Measure = mm)
SYMBOL MIN NOM MAX NOTE
A – – 1.20
A1 0.05 –
b 0.17 – 0.27
C 0.09 – 0.20
D 10.90 11.00 11.10
E1 4.30 4.40 4.50
E 6.20 6.40 6.60
e 0.50 TYP
L 0.50 0.60 0.70
Ø 0o – 8o
Side View
Top View
End View
Ø
1
44
3 2
L
C
E1 E
D
e
b
A
A1
0.15
TITLE DRAWING NO.
R
REV.
Note: These drawings are for general information only. Refer to JEDEC Drawing MO-153BE.
2325 Orchard Parkway
San Jose, CA 95131
5/16/07
44X1, 44-lead, 4.4mm Body Width, Plastic Thin Shrink
Small Outline Package (TSSOP) 44X1 A
COMMON DIMENSIONS
(Unit of Measure = mm)
SYMBOL MIN NOM MAX NOTE
A – – 1.20
A1 0.05 – 0.15
b 0.17 – 0.27
C 0.09 – 0.20
D 10.90 11.00 11.10
E1 4.30 4.40 4.50
E 6.20 6.40 6.60
e 0.50 TYP
L 0.50 0.60 0.70
Ø 0o – 8o
Side View
Top View
End View
Ø
1
44
3 2
L
C
E1 E
D
e
b
A
A1
265
8042E–AVR–09/2013
ATmega16HVB/32HVB
38. Errata
38.1 The Atmel ATmega16HVB
38.1.1 Rev. E
TWI bus can get stuck if TWI STOP condition bit is set in slave mode
If the TWSTO bit in TWCR is set while the TWI starts to receive data in slave mode, it can result
in pulling the SCL pin low and then the TWI bus will get stuck. To release the SCL pin and get
out of this situation the TWI module needs to be disabled and then re-enabled.
Problem fix/workaround
While in slave mode the TWSTO bit should be written only to recover from an error condition and
then cleared before a data transfer starts.
38.1.2 Rev. D
Not sampled.
38.1.3 Rev. C
TWI bus can get stuck if TWI STOP condition bit is set in slave mode
If the TWSTO bit in TWCR is set while the TWI starts to receive data in slave mode, it can result
in pulling the SCL pin low and then the TWI bus will get stuck. To release the SCL pin and get
out of this situation the TWI module needs to be disabled and then re-enabled.
Problem fix/workaround
While in slave mode the TWSTO bit should be written only to recover from an error condition and
then cleared before a data transfer starts.
38.1.4 Rev. B
Stack pointer initial value
The stack pointer in ATmega16HVB is incorrectly initialized to 0x08ff instead of 0x04ff.
Problem fix/workaround
Initialize the stack pointer in software before the stack is used. Most C-compilers does initialize
the stack pointer without manual intervention.
Assembly Code Example:
ldi r16,high(RAMEND); Main program start out SPH,r16 ; Set Stack Pointer to top of RAM ldi
r16,low(RAMEND) out SPL,r16 C Code Example (if required): SP = RAMEND;
TWI bus can get stuck if TWI STOP condition bit is set in slave mode
If the TWSTO bit in TWCR is set while the TWI starts to receive data in slave mode, it can result
in pulling the SCL pin low and then the TWI bus will get stuck. To release the SCL pin and get
out of this situation the TWI module needs to be disabled and then re-enabled.
Problem fix/workaround
While in slave mode the TWSTO bit should be written only to recover from an error condition and
then cleared before a data transfer starts.
38.1.5 Rev. A
Not sampled.
266
8042E–AVR–09/2013
ATmega16HVB/32HVB
38.2 The Atmel ATmega32HVB
38.2.1 Rev. E
TWI bus can get stuck if TWI STOP condition bit is set in slave mode
If the TWSTO bit in TWCR is set while the TWI starts to receive data in slave mode, it can result
in pulling the SCL pin low and then the TWI bus will get stuck. To release the SCL pin and get
out of this situation the TWI module needs to be disabled and then re-enabled.
Problem fix/workaround
While in slave mode the TWSTO bit should be written only to recover from an error condition and
then cleared before a data transfer starts.
38.2.2 Rev. D
Not sampled.
38.2.3 Rev. C
TWI bus can get stuck if TWI STOP condition bit is set in slave mode
If the TWSTO bit in TWCR is set while the TWI starts to receive data in slave mode, it can result
in pulling the SCL pin low and then the TWI bus will get stuck. To release the SCL pin and get
out of this situation the TWI module needs to be disabled and then re-enabled.
Problem fix/workaround
While in slave mode the TWSTO bit should be written only to recover from an error condition and
then cleared before a data transfer starts.
38.2.4 Rev. B
TWI bus can get stuck if TWI STOP condition bit is set in slave mode
If the TWSTO bit in TWCR is set while the TWI starts to receive data in slave mode, it can result
in pulling the SCL pin low and then the TWI bus will get stuck. To release the SCL pin and get
out of this situation the TWI module needs to be disabled and then re-enabled.
Problem fix/workaround
While in slave mode the TWSTO bit should be written only to recover from an error condition and
then cleared before a data transfer starts.
38.2.5 Rev. A
Not sampled.
267
8042E–AVR–09/2013
ATmega16HVB/32HVB
39. Revision history
Please note that the referring page numbers in this section are referring to this document. The
referring revision in this section are referring to the document revision.
39.1 Rev. 8042E-09/2013
39.2 Rev. 8042D-10/2011
1. Updated ”Errata” on page 265:
ATmega16HVB: Added errata sections for “Rev. C” , “Rev. D” and “Rev. E” .
ATmega32HVB: Added errata sections for “Rev. B” , “Rev. C” , “Rev. D” and “Rev. E” .
1. Operating voltage has been changed from 4V - 25V to 4V - 18V
2. The methods for determing the actual clock period of the ULP Oscillator i Section 9.2.3 on page
27 have been changed
3. In ”Bit 1:0 – CLKPS[1:0]: Clock Prescaler select Bit[1:0]” on page 33 new text has been inserted
in and the text “If CKDIBV8 is programmed” has been corrected to “If CKDIV8 is programmed”
4. Note 2 in ”Bit 0 – OSIEN: Oscillator sampling interface enable” on page 34 has been deleted
5. Figure 11-1 on page 43 has been corrected
6. New Note 2 has been added below Table 11-2 on page 51
7. The last sentence in Section 21.5 on page 123 has been corrected
8. The text in Section 25.3.1 on page 146 below Figure 25-2 has been corrected several places
9. VCC in Figure 28-1 on page 186 has been corrected
10. Bit no 4 in Table 30-3 on page 205 has been corrected
11. Note 1 below Table 30-3 on page 205 has been corrected
12. The text in point 4 and 5 in Section 30.6.1 on page 208 has been corrected
13. The VFET value in Figure 30-3 on page 212 has been corrected
14. The table in Section 32.1 on page 225 hase been updated with several new values
15. ILOAD in Table 32-2 on page 226 has been added
16. Note 1 below Table 32-2 on page 226 has been added
17. The maximum value for VBOT in Table 32-3 on page 227 has been added
18. In Table 32-4 on page 227 the maximum value for VRSCL has been corrected and the maximum
value for VREG pin has been added
19. In Table 32-7 on page 229 the typical and maximum values for INL has been corrected
20. In Table 32-8 on page 229 the typical value for frequency prediction error (slow RC oscillator)
has been corrected
21. In Table 32-10 on page 230 the text below “Parameter” has been corrected
22. In Table 32-12 on page 231 Note 5 has been added
268
8042E–AVR–09/2013
ATmega16HVB/32HVB
39.3 Rev. 8042C-06/2011
23. In Table 32-18 on page 236 the maximum value for tWLRH_CE has been corrected
24. The former figure “Active supply current vs. VVFET, WDT, VREF, CBP, OC/OD and CC-ADC
enabled” on page 238 has been removed
25. In Table 33-1 on page 243 the text “CC-OD” has benn changed to “OC-OD” and below “Typical
current consumption” the value “55µA” has been changed to “85µA”
26. New text is added below the two notes for Table 33-1 on page 243
27. New Figure 33-11 on page 245 “Power-save supply current vs. VVFET, WDT, VREF, CBP, OC/OD,
and CC-ADC enabled” is added
28. The plot in Figure 33-13 on page 246 has been updated
29. The plot in Figure 33-14 on page 246 has been updated
30. New Figure 33-15 on page 247 has been added
31. New Figure 33-21 on page 250 has been added
32. Heading in Figure 33-27 on page 253 has been corrected
33. The power supply voltage in the table in Section 36.1 on page 262 has been corrected
34. The power supply voltage in the table in Section 36.2 on page 263 has been corrected
35. The Section 38. on page 265 has been corrected by adding an errata for “all revisions”
36. The text “...clock period of the Slow RC Oscillator...” in point 2 in Section 9.2.3 on page 27 has
been corrected to “...clock period of the ULP RC Oscillator...”
37. Note 1 below Table 19-1 on page 112 has been corrected
38. Note 1 below Table 19-2 on page 112 has been corrected
39. Figure 31-1 on page 220 has been updated
40. Figure 31-2 on page 221 has been updated
41. Figure 31-3 on page 222 has been updated
42. Table 31-1 on page 223 has been updated according to the changes in Figure 31-1 on page
220, Figure 31-2 on page 221, and Figure 31-3 on page 222
1. The columns “Minimum” and “Maximum” in Table 24-5 on page 142 are deleted
2. A new row (“Device lot ID and position”) in Table 29-3 on page 196 is added
3. A new note (“Note 16”) in Table 29-3 on page 196 is added
4. In ”Absolute maximum ratings*” on page 225 the following values have been changed: “Voltage
on OC and OD with respect to ground”, “Voltage on PC5, BATT, PVT, VFET, PV4, PV3, and PV2
with respect to ground”, and “Maximum operating voltage on VFET”
5. In Table 32-1 on page 225 the values for “Typical” and “Maximum” in the row “VFET = 16V,
WDT, CC-ADC, OC, OD, and battery protection enabled, DUVR mode disabled” are added
6. “Frequency drift” for “Slow RC oscillator” in Table 32-8 on page 229 is deleted
7. A new note (“Note 4”) in Table 32-8 on page 229 is added
8. Table 32-10 on page 230 is updated and corrected
269
8042E–AVR–09/2013
ATmega16HVB/32HVB
39.4 Rev. 8042B-06/2010
39.5 Rev. 8042A-08/2009
9. The text “CEQ = 4.7nF, VFET = 16V” is added to “Condition” for tf
,OC and tf
,OD in Table 32-2 on
page 226
10. New Figure 33-1 on page 238 is added
11. Corrected formula in Table 32-15 on page 232
12. Corrected and added some short-cuts in addition to general update and some minor corrections
in text
1. Removed direction arrow in Figure 17-1 on page 82.
2. Updated ”Configuring PA1 and PA0 for V-ADC operation” on page 117.
3. Updated ”Operating circuit” on page 220, with correct naming convention for thermistors RT32
and RT33.
1. Initial revision
270
8042E–AVR–09/2013
ATmega16HVB/32HVB
1
8042E–AVR–09/2013
ATmega16HVB/32HVB
Table of Contents
Features ..................................................................................................... 1
1 Pin configurations .................................................................................... 2
1.1TSSOP ......................................................................................................................2
1.2Pin descriptions .........................................................................................................3
2 Overview ................................................................................................... 5
2.1Comparison between the Atmel ATmega16HVB and the Atmel ATmega32HVB .....7
3 Disclaimer ................................................................................................. 8
4 Resources ................................................................................................. 8
5 About code examples .............................................................................. 8
6 Data retention ........................................................................................... 8
7 AVR CPU core .......................................................................................... 9
7.1Overview ....................................................................................................................9
7.2ALU – Arithmetic Logic Unit .....................................................................................10
7.3Status Register ........................................................................................................10
7.4General purpose Register File .................................................................................12
7.5Stack Pointer ...........................................................................................................13
7.6Instruction execution timing .....................................................................................14
7.7Reset and interrupt handling ...................................................................................14
8 AVR memories ........................................................................................ 17
8.1Overview ..................................................................................................................17
8.2In-system reprogrammable flash program memory .................................................17
8.3SRAM data memory ................................................................................................17
8.4EEPROM data memory ...........................................................................................19
8.5I/O memory ..............................................................................................................19
8.6Register description .................................................................................................20
9 System clock and clock options ........................................................... 25
9.1Clock systems and their distribution ........................................................................25
9.2Clock sources ..........................................................................................................26
9.3Clock startup sequence ...........................................................................................28
9.4Clock output .............................................................................................................28
9.5System clock prescaler ............................................................................................28
2
8042E–AVR–09/2013
ATmega16HVB/32HVB
9.6VADC clock prescaler ..............................................................................................29
9.7OSI – Oscillator sampling interface .........................................................................29
9.8Register description .................................................................................................32
10 Power management and sleep modes ................................................. 35
10.1Sleep modes ..........................................................................................................35
10.2Idle mode ...............................................................................................................37
10.3ADC noise reduction ..............................................................................................37
10.4Power-save mode ..................................................................................................37
10.5Power-off mode .....................................................................................................38
10.6Power Reduction Register .....................................................................................38
10.7Minimizing power consumption .............................................................................38
10.8Register description ...............................................................................................39
11 System control and reset ...................................................................... 42
11.1Resetting the AVR .................................................................................................42
11.2Reset sources ........................................................................................................42
11.3Reset and the voltage reference ...........................................................................45
11.4Watchdog timer .....................................................................................................46
11.5Register description ...............................................................................................49
12 Interrupts ................................................................................................ 52
12.1Overview ................................................................................................................52
12.2Interrupt vectors in Atmel ATmega16HVB/32HVB ................................................52
12.3Moving interrupts between application and boot space .........................................56
12.4Register description ...............................................................................................56
13 External interrupts ................................................................................. 58
13.1Overview ................................................................................................................58
13.2Register description ...............................................................................................58
14 High voltage I/O ports ............................................................................ 62
14.1Overview ................................................................................................................62
14.2High voltage ports as general digital I/O ................................................................63
14.3Overview ................................................................................................................64
14.4Alternate port functions ..........................................................................................64
14.5Register description ...............................................................................................66
15 Low voltage I/O-Ports ............................................................................ 67
15.1Overview ................................................................................................................67
3
8042E–AVR–09/2013
ATmega16HVB/32HVB
15.2Low voltage ports as general digital I/O ................................................................68
15.3Alternate port functions ..........................................................................................72
15.4Register description ...............................................................................................78
16 Timer/Counter0 and Timer/Counter1 prescalers ................................. 79
16.1Overview ................................................................................................................79
16.2External clock source ............................................................................................80
16.3Register description ...............................................................................................81
17 Timer/Counter (T/C0,T/C1) ..................................................................... 82
17.1Features ................................................................................................................82
17.2Overview ................................................................................................................82
17.3Timer/Counter clock sources .................................................................................83
17.4Counter unit ...........................................................................................................83
17.5Modes of operation ................................................................................................84
17.6Input capture unit ...................................................................................................86
17.7Output compare unit ..............................................................................................88
17.8Timer/counter timing diagrams ..............................................................................89
17.9Accessing registers in 16-bit mode ........................................................................90
17.10Register description .............................................................................................94
18 SPI – Serial Peripheral Interface ........................................................... 98
18.1Features ................................................................................................................98
18.2Overview ................................................................................................................98
18.3SS pin functionality ..............................................................................................103
18.4Data modes .........................................................................................................103
18.5Register description .............................................................................................105
19 Coulomb counter – Dedicated fuel gauging Sigma-Delta ADC ...... 108
19.1Features ..............................................................................................................108
19.2Overview ..............................................................................................................108
19.3Normal operation .................................................................................................109
19.4Regular current detection operation ....................................................................110
19.5Offset canceling by polarity switching ..................................................................110
19.6Configuration and usage .....................................................................................111
19.7Register description .............................................................................................111
20 Voltage ADC – 7-channel general purpose 12-bit Sigma-Delta ADC 116
20.1Features ..............................................................................................................116
4
8042E–AVR–09/2013
ATmega16HVB/32HVB
20.2Overview ..............................................................................................................116
20.3Operation .............................................................................................................116
20.4Register description .............................................................................................119
21 Voltage reference and temperature sensor ....................................... 122
21.1Features ..............................................................................................................122
21.2Overview ..............................................................................................................122
21.3Operation .............................................................................................................122
21.4Bandgap calibration .............................................................................................123
21.5Bandgap buffer settling time ................................................................................123
21.6Register description .............................................................................................124
22 Charger detect ...................................................................................... 126
22.1Features ..............................................................................................................126
22.2Overview ..............................................................................................................126
22.3Operation .............................................................................................................127
22.4Register description .............................................................................................128
23 Voltage regulator .................................................................................. 129
23.1Features ..............................................................................................................129
23.2Overview ..............................................................................................................129
23.3Regulator start-up ................................................................................................130
23.4Battery pack short detection ................................................................................130
23.5Black-out detection ..............................................................................................130
23.6Register description .............................................................................................131
24 Battery protection ................................................................................ 132
24.1Features ..............................................................................................................132
24.2Overview ..............................................................................................................132
24.3Operation .............................................................................................................133
24.4External protection input ......................................................................................134
24.5Optimizing usage for low power consumption .....................................................136
24.6Battery protection CPU interface .........................................................................137
24.7Register description .............................................................................................137
25 FET driver ............................................................................................. 145
25.1Features ..............................................................................................................145
25.2Overview ..............................................................................................................145
25.3Operation and usage ...........................................................................................146
5
8042E–AVR–09/2013
ATmega16HVB/32HVB
25.4Register description .............................................................................................149
26 Cell balancing ....................................................................................... 151
26.1Overview ..............................................................................................................151
26.2Register description .............................................................................................152
27 2-wire serial interface .......................................................................... 153
27.1Features ..............................................................................................................153
27.2Two-wire serial interface bus definition ...............................................................153
27.3Data transfer and frame format ...........................................................................154
27.4Multi-master bus systems, arbitration and synchronization .................................157
27.5Overview of the TWI module ...............................................................................159
27.6Using the TWI ......................................................................................................162
27.7Transmission modes ...........................................................................................165
27.8Multi-master systems and arbitration ...................................................................178
27.9Bus connect/disconnect for two-wire serial interface ...........................................179
27.10Register description ...........................................................................................181
28 debugWIRE on-chip debug system .................................................... 186
28.1Features ..............................................................................................................186
28.2Overview ..............................................................................................................186
28.3Physical interface ................................................................................................186
28.4Software break points ..........................................................................................187
28.5Limitations of debugWIRE ...................................................................................187
28.6Register description .............................................................................................187
29 Boot loader support – Read-while-write self-programming ............. 188
29.1Features ..............................................................................................................188
29.2Overview ..............................................................................................................188
29.3Application and boot loader flash sections ..........................................................188
29.4Read-while-write and no read-while-write flash sections .....................................189
29.5Boot loader lock bits ............................................................................................191
29.6Entering the boot loader program ........................................................................192
29.7Addressing the flash during self-programming ....................................................192
29.8Self-programming the flash .................................................................................193
29.9Register description .............................................................................................202
30 Memory programming ......................................................................... 204
30.1Program and data memory lock bits ....................................................................204
6
8042E–AVR–09/2013
ATmega16HVB/32HVB
30.2Fuse bits ..............................................................................................................205
30.3Signature bytes ....................................................................................................206
30.4Calibration bytes ..................................................................................................207
30.5Page size .............................................................................................................207
30.6Serial programming .............................................................................................207
30.7Parallel programming ..........................................................................................211
31 Operating circuit .................................................................................. 220
32 Electrical characteristics ..................................................................... 225
32.1Absolute maximum ratings* .................................................................................225
32.2Supply current characteristics .............................................................................225
32.3NFET driver characteristics .................................................................................226
32.4Reset characteristics ...........................................................................................227
32.5Voltage regulator characteristics .........................................................................227
32.6Voltage reference and temperature sensor characteristics .................................227
32.7ADC characteristics .............................................................................................228
32.8Clock characteristics ............................................................................................229
32.9Cell balancing characteristic ................................................................................230
32.10Battery protection characteristics ......................................................................230
32.11External interrupt characteristics .......................................................................230
32.12General I/O lines characteristics ........................................................................231
32.132-wire serial interface characteristics ................................................................232
32.14SPI timing characteristics ..................................................................................233
32.15Serial programming characteristics ...................................................................234
32.16Parallel programming characteristics ................................................................235
33 Typical characteristics ........................................................................ 238
33.1Supply current characteristics .............................................................................238
33.2NFET driver characteristics .................................................................................245
33.3Battery protection characteristics ........................................................................248
33.4Clock characteristics ............................................................................................248
33.5Voltage reference characteristics ........................................................................251
33.6Voltage regulator characteristics .........................................................................252
33.7BOD threshold characteristics .............................................................................254
34 Register summary ................................................................................ 255
35 Instruction set summary ..................................................................... 259
7
8042E–AVR–09/2013
ATmega16HVB/32HVB
36 Ordering information ........................................................................... 262
36.1The Atmel ATmega16HVB ..................................................................................262
36.2The Atmel ATmega32HVB ..................................................................................263
37 Packaging information ........................................................................ 264
37.144X1 ....................................................................................................................264
38 Errata ..................................................................................................... 265
38.1The Atmel ATmega16HVB ..................................................................................265
38.2The Atmel ATmega32HVB ..................................................................................266
39 Revision history ................................................................................... 267
39.1Rev. 8042E-09/2013 ............................................................................................267
39.2Rev. 8042D-10/2011 ...........................................................................................267
39.3Rev. 8042C-06/2011 ...........................................................................................268
39.4Rev. 8042B-06/2010 ............................................................................................269
39.5Rev. 8042A-08/2009 ............................................................................................269
Table of Contents...................................................................................... 1
8042E–AVR–09/2013
Atmel Corporation
1600 Technology Drive
San Jose, CA 95110
USA
Tel: (+1) (408) 441-0311
Fax: (+1) (408) 487-2600
www.atmel.com
Atmel Asia Limited
Unit 01-5 & 16, 19F
BEA Tower, Millennium City 5
418 Kwun Tong Roa
Kwun Tong, Kowloon
HONG KONG
Tel: (+852) 2245-6100
Fax: (+852) 2722-1369
Atmel Munich GmbH
Business Campus
Parkring 4
D-85748 Garching b. Munich
GERMANY
Tel: (+49) 89-31970-0
Fax: (+49) 89-3194621
Atmel Japan G.K.
16F Shin-Osaki Kangyo Bldg
1-6-4 Osaki, Shinagawa-ku
Tokyo 141-0032
JAPAN
Tel: (+81) (3) 6417-0300
Fax: (+81) (3) 6417-0370
© 2013 Atmel Corporation. All rights reserved. / Rev.: 8042E–AVR–09/2013
Disclaimer: The information in this document is provided in connection with Atmel products. No license, express or implied, by estoppel or otherwise, to any intellectual property right is granted by this
document or in connection with the sale of Atmel products. EXCEPT AS SET FORTH IN THE ATMEL TERMS AND CONDITIONS OF SALES LOCATED ON THE ATMEL WEBSITE, ATMEL ASSUMES
NO LIABILITY WHATSOEVER AND DISCLAIMS ANY EXPRESS, IMPLIED OR STATUTORY WARRANTY RELATING TO ITS PRODUCTS INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. IN NO EVENT SHALL ATMEL BE LIABLE FOR ANY DIRECT, INDIRECT,
CONSEQUENTIAL, PUNITIVE, SPECIAL OR INCIDENTAL DAMAGES (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS AND PROFITS, BUSINESS INTERRUPTION, OR LOSS OF
INFORMATION) ARISING OUT OF THE USE OR INABILITY TO USE THIS DOCUMENT, EVEN IF ATMEL HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Atmel makes no
representations or warranties with respect to the accuracy or completeness of the contents of this document and reserves the right to make changes to specifications and products descriptions at any time
without notice. Atmel does not make any commitment to update the information contained herein. Unless specifically provided otherwise, Atmel products are not suitable for, and shall not be used in,
automotive applications. Atmel products are not intended, authorized, or warranted for use as components in applications intended to support or sustain life.
Atmel®, Atmel logo and combinations thereof, Enabling Unlimited Possibilities®, AVR® and others are registered trademarks or trademarks of Atmel Corporation or
its subsidiaries. Other terms and product names may be trademarks of others.
Atmel QTouch Library
QTouch Library Peripheral Touch Controller
USER GUIDE
Description
Atmel®
QTouch®
Peripheral Touch Controller (PTC) offers built-in hardware
for capacitive touch measurement on sensors that function as buttons,
sliders, and wheels. The PTC supports both mutual and self-capacitance
measurement without the need for any external component. It offers superb
sensitivity and noise tolerance, as well as self-calibration, and minimizes the
sensitivity tuning effort by the user.
The PTC is intended for autonomously performing capacitive touch sensor
measurements. The external capacitive touch sensor is typically formed on a
PCB, and the sensor electrodes are connected to the analog charge
integrator of the PTC using the device I/O pins. The PTC supports mutual
capacitance sensors organized as capacitive touch matrices in different X-Y
configurations, including Indium Tin Oxide (ITO) sensor grids. In mutual
capacitance mode, the PTC requires one pin per X-line (drive line) and one
pin per Y-line (sense line). In self-capacitance mode, the PTC requires only
one pin with a Y-line driver for each self-capacitance sensor.
Features
• Implements low-power, high-sensitivity, environmentally robust
capacitive touch buttons, sliders, and wheels
• Supports mutual capacitance and self-capacitance sensing
• Up to 32 buttons in self-capacitance mode
• Up to 256 buttons in mutual capacitance mode
• Supports lumped mode configuration
• One pin per electrode - no external components
• Load compensating charge sensing
• Parasitic capacitance compensation for mutual capacitance mode
• Adjustable gain for superior sensitivity
• Zero drift over the temperature and VDD range
• No need for temperature or VDD compensation
• Hardware noise filtering and noise signal de-synchronization for high
conducted immunity
• Atmel provided QTouch Library firmware and QTouch Composer tool
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
Product Support
For assistance related to QTouch capacitive touch sensing software libraries and related issues, contact
your local Atmel sales representative or log on to myAtmel Design Support portal to submit a support
request or access a comprehensive knowledge base.
If you do not have a myAtmel account, please visit http://www.atmel.com/design-support/ to create a new
account by clicking on Create Account in the myAtmel menu at the top of the page.
When logged in, you will be able to access the knowledge base, submit new support cases from the
myAtmel page or review status of your ongoing cases.
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
2
Table of Contents
Description.......................................................................................................................1
Features.......................................................................................................................... 1
1. Development Tools ................................................................................................... 5
2. Device Variants Supported........................................................................................ 6
3. Capacitive Touch Technology.................................................................................... 8
3.1. Capacitive Touch Sensors............................................................................................................8
3.2. Capacitance Measurement Methods............................................................................................8
3.3. Self-capacitance Measurement Method.......................................................................................8
3.4. Mutual Capacitance Measurement Method..................................................................................9
3.5. Capacitive Touch Lumped Sensors..............................................................................................9
3.6. Capacitive Touch Low Power Sensor......................................................................................... 11
3.7. PTC and its Benefits...................................................................................................................13
3.8. PTC Block Diagram for Self-capacitance and Mutual Capacitance Method.............................. 13
3.9. Design Approach with PTC........................................................................................................ 15
3.10. Capacitive Touch Development Cycle........................................................................................16
4. Touch Sensor Debug and Status Information..........................................................17
4.1. Signal..........................................................................................................................................17
4.2. Reference...................................................................................................................................17
4.3. Delta........................................................................................................................................... 18
4.4. Touch Status & Slider/Wheel Position........................................................................................ 19
5. QTouch Library........................................................................................................ 20
5.1. Overview.....................................................................................................................................20
5.2. Library Parameters.....................................................................................................................21
5.3. Moisture Tolerance..................................................................................................................... 42
5.4. Reading Sensor States...............................................................................................................44
5.5. Application Flow......................................................................................................................... 44
5.6. API Sequence.............................................................................................................................46
5.7. State Machine.............................................................................................................................47
5.8. Operation Modes........................................................................................................................50
5.9. Touch Library API Error.............................................................................................................. 52
6. Tuning for Noise Performance.................................................................................54
6.1. Noise Sources............................................................................................................................ 54
6.2. Noise Counter Measures............................................................................................................54
7. Application Design...................................................................................................60
7.1. Touch Library and Associated Files............................................................................................60
7.2. Code and Data Memory Considerations.................................................................................... 60
8. Example Applications.............................................................................................. 63
8.1. Atmel Board Example Projects...................................................................................................63
8.2. User Board Example Projects.................................................................................................... 66
8.3. Using Atmel Software Framework (ASF) with the Example Projects......................................... 67
8.4. Using Xplained Pro Kit to Program User Board......................................................................... 67
8.5. Using QDebug Touch Data Debug Communication Interface.................................................... 67
8.6. Using Xplained Pro Kit for QDebug Data Streaming from User Board...................................... 68
8.7. Using Atmel ICE for QDebug Data Streaming from User Board................................................ 70
9. Known Issues.......................................................................................................... 71
10. FAQ on PTC Qtouch................................................................................................73
11. Appendix..................................................................................................................74
11.1. Macros........................................................................................................................................74
11.2. Typedef.......................................................................................................................................76
11.3. Enumeration............................................................................................................................... 76
11.4. Datastructures............................................................................................................................ 84
11.5. Global Variables......................................................................................................................... 92
11.6. API..............................................................................................................................................93
12. Revision History.....................................................................................................100
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
4
1. Development Tools
The following development tools are required for developing QTouch library using PTC:
• Development Environment for GCC Compiler:
– QTouch Composer 5.9.116 or later versions
– QTouch Library 5.9.211 or later versions
Note: The QTouch Library and Composer extensions work only with Atmel Studio 7 which
can be downloaded from http://www.atmel.com/
– Dependent Atmel Studio Extensions
• Atmel Software Framework 3.30.1 or later versions
• Atmel Kit Extension 7.0.70 or later versions
• Development Environment for IAR Compiler:
– IAR Embedded Workbench®
for ARM®
7.50.1.10273 or later
– IAR Embedded Workbench for Atmel AVR®
6.70.1 or later
– Atmel Software Framework 3.29.0 or later (optional)
– Atmel QTouch Library 5.9.211 IAR Installer (available at http://www.atmel.com/tools/
qtouchlibraryptc.aspx)
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
5
2. Device Variants Supported
QTouch Library for SAM and ATmega devices are available for the following device variants:
Series Variant
SAM D20 J Series ATSAMD20J18, ATSAMD20J17, ATSAMD20J16, ATSAMD20J15,
ATSAMD20J14
SAM D20 G Series ATSAMD20G18, ATSAMD20G18U, ATSAMD20G17, ATSAMD20G17U,
ATSAMD20G16, ATSAMD20G15, ATSAMD20G14
SAM D20 E Series ATSAMD20E18, ATSAMD20E17, ATSAMD20E16, ATSAMD20E15,
ATSAMD20E14
SAM D21 J Series ATSAMD21J18A, ATSAMD21J17A, ATSAMD21J16A, ATSAMD21J15A,
ATSAMD21J16B, ATSAMD21J15B
SAM D21 G Series ATSAMD21G18A, ATSAMD21G17A, ATSAMD21G16A, ATSAMD21G15A,
ATSAMD21G15B, ATSAMD21G16B, ATSAMD21G17AU, ATSAMD21G18AU
SAM D21 E Series ATSAMD21E18A, ATSAMD21E17A, ATSAMD21E16A, ATSAMD21E15A,
ATSAMD21E15B, ATSAMD21E15BU, ATSAMD21E16B, ATSAMD21E16BU
SAM D10 C Series ATSAMD10C14A
SAM D10 D Series ATSAMD10D14AM, ATSAMD10D14AS, ATSAMD10D14AU
SAM D11 C Series ATSAMD11C14A
SAM D11 D Series ATSAMD11D14AM, ATSAMD11D14AS, ATSAMD11D14AU
SAM L21 E Series ATSAML21E15B, ATSAML21E16B, ATSAML21E17B, ATSAML21E18B
SAM L21 G Series ATSAML21G16B, ATSAML21G17B, ATSAML21G18B
SAM L21 J Series ATSAML21J16B, ATSAML21J17B, ATSAML21J18B
SAM R21 E Series ATSAMR21E16A, ATSAMR21E17A, ATSAMR21E18A, ATSAMR21E19A
SAM R21 G Series ATSAMR21G16A, ATSAMR21G17A, ATSAMR21G18A
SAM DA1 E Series ATSAMDA1E14A, ATSAMDA1E15A, ATSAMDA1E16A
SAM DA1 G Series ATSAMDA1G14A, ATSAMDA1G15A, ATSAMDA1G16A
SAM DA1 J Series ATSAMDA1J14A, ATSAMDA1J15A, ATSAMDA1J16A
SAM C21 E Series ATSAMC21E15A, ATSAMC21E16A, ATSAMC21E17A, ATSAMC21E18A
SAM C21 G Series ATSAMC21G15A, ATSAMC21G16A. ATSAMC21G17A, ATSAMC21G18A
SAM C21 J Series ATSAMC21J16A, ATSAMC21J17A, ATSAMC21J18A
SAM C20 E Series ATSAMC20E15A, ATSAMC20E16A, ATSAMC20E17A, ATSAMC20E18A
SAM C20 G Series ATSAMC20G15A, ATSAMC20G16A. ATSAMC20G17A, ATSAMC20G18A
SAM C20 J Series ATSAMC20J16A, ATSAMC20J17A, ATSAMC20J18A
SAM L22 G Series ATSAML22G16A, ATSAML22G17A, ATSAML22G18A
SAM L22 J Series ATSAML22J16A, ATSAML22J17A, ATSAML22J18A
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
6
Series Variant
SAM L22 N Series ATSAML22N16A, ATSAML22N17A, ATSAML22N18A
ATmega Series ATmega328PB, ATmega324PB
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
7
3. Capacitive Touch Technology
3.1. Capacitive Touch Sensors
Capacitive touch sensors replace conventional mechanical interfaces and operate with no mechanical
wear and are closed to the environment. They provide greater flexibility in industrial design and result in
differentiating end product design. For more information, refer Capacitive Touch Lumped Sensors and
Capacitive Touch Low Power Sensor.
Figure 3-1. Sensor Types
3.2. Capacitance Measurement Methods
Self-capacitance measurement method involves charging a sense electrode of unknown capacitance to a
known potential. The resulting charge is transferred into a measurement circuit. By measuring the charge
with one or more charge-and transfer cycles, the capacitance of the sense plate can be determined.
Figure 3-2. Capacitance Measurement Principle
Mutual capacitance measurement method uses a pair of sensing electrodes. One electrode acts as an
emitter into which a charge consisting of logic pulses is driven in burst mode. The other electrode acts as
a receiver that couples to the emitter using the overlying panel dielectric. When a finger touches the
panel, the field coupling is reduced, and touch is detected.
3.3. Self-capacitance Measurement Method
• Uses a single sense electrode (Y-line)
– Self-capacitance button can be formed using one channel
– Self-capacitance slider and wheel is formed using 3 channels
• Robust and easy to use, ideal for low sensors count
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
8
Figure 3-3. Self-capacitance Method
3.4. Mutual Capacitance Measurement Method
• Uses a pair of sense electrodes (X-Y lines)
– Mutual capacitance buttons use one X-Y channel
– Mutual capacitance sliders and wheels can be configured to use 3 to 8 X-Y channels,
depending on the sensor size
• Suitable for high sensor count
• Better moisture tolerance
Figure 3-4. Mutual Capacitance Method
3.5. Capacitive Touch Lumped Sensors
Lumped sensor configuration is a combination of multiple sense lines (Self-capacitance measurement) or
multiple drive and sense lines (Mutual capacitance measurement) to act as one single sensor. Lumped
mode acts as a tool for application developers to improve overall system performance.
Improved Power Efficiency
When multiple sensors are lumped together and treated as one single sensor the time taken to perform
scans is reduced. For battery powered applications using multiple buttons, a group of touch sensors can
be lumped to form a single lumped sensor and this sensor alone can be scanned, thereby resulting in
reduced power consumption. Upon user presence detection on the lumped sensor all configured sensors
in the system can then be scanned individually.
Improved Response Time
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
9
In high key-count applications, there can be a significant latency between touching a sensor and the
detection of a touch contact. This is due to the time taken to sequentially measure the capacitance of
each key on each measurement cycle.With a Lumped mode implementation this latency can be reduced
by arranging the sensors into groups. When one of those lumped groups shows touch detection, only the
keys within that group are individually measured to determine which is touched.
E.g. A keyboard consisting 64 keys may be divided into 8 lumped groups of 8.
Thus, each measurement cycle is reduced to measure only the 8 lumped sensors. When a touch contact
is applied, first the lump sensor shows touch delta, then the 8 component keys are scanned and the
location is resolved. Only 16 measurements are required to resolve the touch status of all keys, compared
to 64 measurements in the traditional sequential scan of all keys.
It offers an additional edge during low power acquisition as a group of keys [in lumped configuration] can
be scanned thus reducing the power consumed drastically. Each sensor has its own pre-scaled clock and
series resistor for improved noise immunity.
Figure 3-5. Self-capacitance Sensors connected to PTC
Figure 3-6. Lumped Self-capacitance Sensors connected to PTC
In the preceeding figures, individual buttons are shown along with the lumped equivalent for selfcapacitance
arrangement.
Lumped Mode Pin and Sensor Configuration for Self-capacitance Method:
#define DEF_SELFCAP_LINES Y(5), Y(4), Y(11), Y(10), Y(13), Y(7), Y(12), Y(6), LUMP_Y(5,4)
touch_ret = touch_selfcap_sensor_config(SENSOR_TYPE_LUMP, CHANNEL_8, CHANNEL_8, NO_AKS_GROUP,
40u, HYST_6_25, RES_8_BIT, &sensor_id);
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
10
Figure 3-7. Lumped Sense Lines Mutual Capacitance Sensors connected to PTC
In the preceeding figure, mutual capacitance lumped sensor configuration is presented.
Lumped Mode Pin and Sensor Configuration for Mutual Capacitance Method:
#define DEF_MUTLCAP_NODES X(8), Y(10), X(9), Y(10), X(2), Y(12), X(3), Y(12), \X(8), Y(12),
X(9), Y(12), X(2), Y(13), X(3), Y(13), \X(8), Y(13), X(9), Y(13), LUMP_X(2,3,8,9),
LUMP_Y(10,13)
touch_ret = touch_mutlcap_sensor_config(SENSOR_TYPE_LUMP, CHANNEL_10, CHANNEL_10,
NO_AKS_GROUP, 20u, HYST_6_25, RES_8_BIT, 0, &sensor_id);
Limitations of Use
Lumped sensor capacitive load should not exceed the maximum sensor load for individual sensors in
either mutual or self-capacitance modes. Lumped mode treats the larger sensors as one single sensor
therefore the maximum lumped sensor load should also observe this specification, else this will result in
calibration error.
In mutual capacitance measurement mode the capacitive load of each sensor is normally much lower
than that of the self-capacitance method. It is therefore possible as a general rule to use more mutual
sensors together as a single lumped sensor.
The user can ensure that the lumped sensor does not result in a calibration error (value of 0x80) using
p_xxxxcap_measure_data->p_sensors[].state variable.
3.6. Capacitive Touch Low Power Sensor
The QTouch Library may be configured to operate PTC touch sensing autonomously using the Event
System. In this mode, a single sensor is designated as the ‘Low Power’ key and may be periodically
measured for touch detection without any CPU action. The CPU may be held in deep sleep mode
throughout the operation, minimizing power consumption.
The low power key may be a discrete electrode with one Y (Sense) line for Self-capacitance or One X
(Drive) plus one Y (Sense) for mutual capacitance, or it may be a combination of multiple Drive and/or
Sense lines as a Lumped mode sensor.
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
11
Figure 3-8. Low Power Flow
Active Measurement Mode
In the active measurement mode all configured sensors are measured at
DEF_TOUCH_MEASUREMENT_PERIOD_MS millisecond scan interval.
The user application arrangement could be designed such that when no touch activity is detected on any
of the configured sensors for NO_ACTIVITY_TRIGGER_TIME milliseconds, then the application switches
to low power measurement mode.
Low Power Measurement Mode
In the low power measurement mode, a designated sensor or a lumped sensor can be scanned as a
single sensor. In this mode, the system is in standby sleep mode, the CPU and other peripherals are in
sleep, excepting for the event system, the RTC and the PTC module / WDT and PTC module in SAM /
Mega devices. A user touch on the designated low power sensor will cause the CPU to wake up and
perform active measurement in order to resolve the touch. To keep reference tracking of the designated
low power sensor, the RTC/WDT is configured to periodically wake up the CPU every
DEF_LOWPOWER_SENSOR_DRIFT_PERIODICITY_MS millisecond to perform one active measurement.
Switching between Active Mode and Low Power Mode
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
12
When switching from active to low power mode, all sensors except the lumped sensor are disabled. So,
no reference tracking is performed on these sensors during the low power mode. When a touch is
detected on the lumped sensor, all disabled sensors shall now be re-enabled and measurement is
initiated on the sensors. If the device is in sleep for a very long time, then it is recommended to force
calibration on the re-enabled sensors to ensure proper reference values on these sensors.
3.7. PTC and its Benefits
• Mixed Hardware + Firmware solution, allows user to define sensor configuration
– Peripheral Touch Controller + QTouch library
• PTC runs data acquisition autonomously, resulting in low CPU utilization and power consumption
– User controlled power-performance trade-off
– CPU can sleep during acquisition to save power
– Alternatively, CPU can perform other time critical operations during touch acquisition
• Robust noise performance
Figure 3-9. User Application with PTC Device
3.8. PTC Block Diagram for Self-capacitance and Mutual Capacitance Method
The PTC block diagram for self-capacitance measurement is shown in the following figure. Only Y-lines
can be connected to self-capacitance sensors and are selected using the Input control. X-lines remain
unused and can be used for any other GPIO functionality. The acquisition module along with the
compensation circuit helps in measuring the change in capacitance due to user touch.
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
13
Figure 3-10. PTC Self-capacitance Method - Block Diagram
The PTC block diagram for mutual capacitance measurement is as shown in the following figure. Both Xlines
and Y-lines should be connected to mutual capacitance sensors and are selected using the Input
control.
Figure 3-11. PTC Mutual Capacitance Method - Block Diagram
3.8.1. Compensation Circuit
The PTC has an internal compensation circuit which is used to compensate the sensor capacitance. Both
self-capacitance and mutual capacitance sensing modes have the same compensation range. But the
mutual capacitance mode can compensate more parasitic capacitance compared to self-capacitance
mode.
The tag_touch_measure_data_t structure contains the p_cc_calibration_vals parameter
which represents the current channel's compensation circuit value. For more information, refer Measure
Data Type (tag_touch_measure_data_t) .
Compensation circuit value used in pF = (p_cc_calibration_vals[channel_no]& 0x0F)*0.00675 +
((p_cc_calibration_vals[channel_no] >> 4) & 0x0F)*0.0675 +
((p_cc_calibration_vals[channel_no] >> 8) & 0x0F)*0.675 + ((p_cc_calibration_vals[channel_no]
>> 12) & 0x3 ) * 6.75
Also, the touch_xxxxcap_sensors_calibrate function helps the user to calibrate the compensation
circuit according to the sensors used. If the routine fails to calibrate the compensation circuit due to
saturation, the measurement will return TOUCH_CC_CALIB_ERROR. The compensation circuit could have
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
14
exceeded its limit. The specific sensor that has failed can be determined using
p_xxxxcap_measure_data->p_sensors[].statewhen it contains the value of
SENSOR_CALIBRATION_ERROR(0x80u).
• Typical compensation circuit value for the self-capacitance mode ranges from 10 to 25 pF and for
the mutual capacitance mode it is around 2 pF.
• The compensation circuit value is affected by sensor size and the ground surrounding the sensor or
trace. The compensation ciruit value ranges from 0.00675 pF to 31.48 pF.
• If the compensation circuit value exceeds the limit, to reduce the value, use a mesh instead of a
solid plane in the sensor and ground plane.
• For detailed sensor design, refer http://www.atmel.com/images/doc10752.pdf.
3.9. Design Approach with PTC
Two design approaches are possible when using Atmel MCU along with PTC. The Atmel MCU could be
predominantly used as an MCU for touch measurement. Else, the Atmel MCU can function as a Host
MCU utilizing peripherals such as the USB, ADC, DAC, SERCOM, DMA and GPIO along with the PTC
used for "on-chip" touch functionality.
The design approaches are:
• Atmel MCU with PTC predominantly functioning as a touch MCU
– Used for touch sensor status and rotor/slider position detection
– Additionally used to indicate touch status using LED, buzzer etc
– Sends touch status and rotor/slider position information to a Host MCU
• Atmel MCU functions as a Host MCU with on-chip touch functionality
– Can be a cost saving design as a single chip solution with on-chip touch functionality
– Utilizes other on-chip peripheral for a desired user application
Figure 3-12. PTC Design Approach
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
15
3.10. Capacitive Touch Development Cycle
The capacitive touch development cycle involves PCB board design to develop the user interface
hardware as well as firmware application development. The QTouch Composer PC software available as
part of Atmel Studio extension gallery allows for PTC QTouch Library projects to be generated
automatically with a desired user configuration for touch sensors. The QTouch Composer also allows for
touch sensor data analysis and performance tuning for sensitivity and noise.
Figure 3-13. Capacitive Touch Development Cycle
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
16
4. Touch Sensor Debug and Status Information
The touch sensor debug information necessary for tuning of the sensors are signal, reference, delta, and
compensation capacitance. While the signal, reference and delta help in sensitivity and noise tuning the
sensor parameters, the compensation capacitance is an indicator for extreme sensor design. The sensor
status and position information are parameters that must be judged by the user application to initate the
relevant touch action.
4.1. Signal
Signal value is the raw measurement data on a given touch channel. The value increases upon touch.
Figure 4-1. Channel Signal
4.2. Reference
Reference value of a touch channel is the long term average measurement on a specific channel.
It represents:
• Resting signal when there is no touch
• Initial value obtained during the calibration process
• Reference is adapted by Drift Compensation algorithm
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
17
Figure 4-2. Channel Reference
4.3. Delta
Delta value of a touch channel represents touch strength.
• Delta = (signal - reference)
• Deltas increase with touch
Figure 4-3. Sensor Delta
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
18
4.4. Touch Status & Slider/Wheel Position
The sensor touch status is the primary touch sensor information utilized by a user application. The sensor
state can either be ON or OFF. For sliders and wheel, additionally the touch position is of interest. For an
8-bit resolution, the touch position ranges from 0 to 255 end-to-end. It is possible to configure with a lower
resolution by configuring setting in the touch library. The sensor touch status and slider/wheel position
must always be used once the library completes the measurements.
The touch sensor state for mutual capacitance or self-capacitance sensor can be obtained by reading the
following boolean variables.
bool sensor_state_self = GET_SELFCAP_SENSOR_STATE(SENSOR_NUMBER);
bool sensor_state_mutl = GET_MUTLCAP_SENSOR_STATE(SENSOR_NUMBER);
The touch sensor rotor or slider position information for mutual capacitance or self-capacitance sensor
can be obtained using the following parameters.
uint8_t rotor_slider_position_self = GET_SELFCAP_ROTOR_SLIDER_POSITION(ROTOR_SLIDER_NUMBER);
uint8_t rotor_slider_position_mutl = GET_MUTLCAP_ROTOR_SLIDER_POSITION(ROTOR_SLIDER_NUMBER);
The touch sensor noise status for mutual capacitance or self-capacitance sensor can be obtained using
the following parameters.
bool sensor_noise_state_self = GET_SELFCAP_SENSOR_NOISE_STATUS(SENSOR_NUMBER);
bool sensor_noise_state_mutl = GET_MUTLCAP_SENSOR_NOISE_STATUS(SENSOR_NUMBER);
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
19
5. QTouch Library
Atmel QTouch Library makes it simple for developers to embed capacitive touch button, slider, wheel
functionality into general purpose Atmel SMART | ARM and AVR®
microcontroller applications. The
royalty- free QTouch Library provides several library files for each device and supports different numbers
of touch channels, enabling both flexibility and efficiency in touch applications.
QTouch Library can be used to develop single-chip solutions for many control applications, or to reduce
chip count in more complex applications. Developers have the latitude to implement buttons, sliders, and
wheels in a variety of combinations on a single interface.
Figure 5-1. QTouch Library
5.1. Overview
QTouch Library API for PTC can be used for touch sensor pin configuration, acquisition parameter setting
as well as periodic sensor data capture and status update operations. The QTouch Library in turn
interfaces with the PTC module to perform the necessary action. The PTC module interfaces with the
external capacitive touch sensors and is capable of performing self and mutual capacitance method
measurements. The library features low power and lumped mode configuration.
Figure 5-2. QTouch Library Overview
The QTouch Library API is arranged such that the user application can use standalone self-capacitance
or mutual capacitance method or both methods, simultaneously. The following table captures the APIs
available for each method. For normal operation, it is sufficient to use the set of Regular APIs for each
method. The Helper APIs provides additional flexibility to the user application.
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
20
Method Regular API Helper API
Mutual capacitance touch_mutlcap_sensors_init
touch_mutlcap_sensor_config
touch_mutlcap_sensors_calibrate
touch_mutlcap_sensors_measure
touch_mutlcap_sensors_deinit
touch_mutlcap_lowpower_sensor_enable_event_measure
touch_mutlcap_sensor_get_delta
touch_mutlcap_sensor_update_config
touch_mutlcap_sensor_get_config
touch_mutlcap_update_global_param
touch_mutlcap_get_global_param
touch_mutlcap_update_acq_config
touch_mutlcap_get_acq_config
touch_mutlcap_sensor_disable
touch_mutlcap_sensor_reenable
touch_multcap_mois_tolrnce_enable
touch_multcap_mois_tolrnce_disable
touch_mutlcap_cnfg_mois_threshold
touch_mutlcap_cnfg_mois_mltchgrp
touch_mutlcap_mois_tolrnce_quick_reburst_enable
touch_mutlcap_mois_tolrnce_quick_reburst_disable
touch_mutlcap_get_libinfo
touch_library_get_version_info touch_resume_ptc
touch_suspend_ptc
Self-capacitance touch_selfcap_sensors_init
touch_selfcap_sensor_config
touch_selfcap_sensors_calibrate
touch_selfcap_sensors_measure
touch_selfcap_sensors_deinit
touch_selfcap_lowpower_sensor_enable_event_measure
touch_selfcap_sensor_get_delta
touch_selfcap_sensor_update_config
touch_selfcap_sensor_get_config
touch_selfcap_update_global_param
touch_selfcap_get_global_param
touch_selfcap_update_acq_config
touch_selfcap_get_acq_config
touch_selfcap_sensor_disable
touch_selfcap_sensor_reenable
touch_selfcap_mois_tolrnce_enable
touch_selfcap_mois_tolrnce_disable
touch_selfcap_cnfg_mois_threshold
touch_selfcap_cnfg_mois_mltchgrp
touch_selfcap_mois_tolrnce_quick_reburst_enable
touch_selfcap_mois_tolrnce_quick_reburst_disable
touch_selfcap_get_libinfo
touch_library_get_version_info touch_suspend_ptc
touch_resume_ptc
5.2. Library Parameters
The QTouch Library configuration parameters are listed in the following table:
Configuration Mutual capacitance Self-capacitance
Pin Configuration DEF_MUTLCAP_NODES DEF_SELFCAP_LINES
Sensor Configuration DEF_MUTLCAP_NUM_CHANNELS DEF_MUTLCAP_NUM_SENSORS
DEF_MUTLCAP_NUM_ROTORS_SLIDERS
DEF_MUTLCAP_PTC_GPIO_STATE
DEF_MUTLCAP_QUICK_REBURST_ENABLE
DEF_SELFCAP_NUM_CHANNELS DEF_SELFCAP_NUM_SENSORS
DEF_SELFCAP_NUM_ROTORS_SLIDERS
DEF_SELFCAP_PTC_GPIO_STATE
DEF_SELFCAP_QUICK_REBURST_ENABLE
Sensor Individual Parameters Detect Threshold
Detect Hysteresis
Position Resolution
Position Hysteresis
AKS group
Detect Threshold
Detect Hysteresis
Position Resolution
AKS group
Sensor Global Parameters DEF_MUTLCAP_DI DEF_MUTLCAP_TCH_DRIFT_RATE
DEF_MUTLCAP_ATCH_DRIFT_RATE
DEF_MUTLCAP_MAX_ON_DURATION
DEF_MUTLCAP_DRIFT_HOLD_TIME
DEF_MUTLCAP_ATCH_RECAL_DELAY
DEF_MUTLCAP_ATCH_RECAL_THRESHOLD
DEF_MUTLCAP_TOUCH_POSTPROCESS_MODE
DEF_MUTLCAP_AKS_ENABLE DEF_MUTLCAP_CSD
DEF_MUTLCAP_AUTO_OS_SIGNAL_STABILITY_LIMIT
DEF_SELFCAP_DI DEF_SELFCAP_TCH_DRIFT_RATE
DEF_SELFCAP_ATCH_DRIFT_RATE
DEF_SELFCAP_MAX_ON_DURATION
DEF_SELFCAP_DRIFT_HOLD_TIME
DEF_SELFCAP_ATCH_RECAL_DELAY
DEF_SELFCAP_ATCH_RECAL_THRESHOLD
DEF_SELFCAP_TOUCH_POSTPROCESS_MODE
DEF_SELFCAP_AKS_ENABLE DEF_SELFCAP_CSD
DEF_SELFCAP_AUTO_OS_SIGNAL_STABILITY_ LIMIT
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
21
Configuration Mutual capacitance Self-capacitance
Sensor Acquisition Parameters DEF_MUTLCAP_FILTER_LEVEL_PER_NODE
DEF_MUTLCAP_AUTO_OS_PER_NODE
DEF_MUTLCAP_GAIN_PER_NODE DEF_MUTLCAP_FREQ_MODE
DEF_MUTLCAP_HOP_FREQS
DEF_MUTLCAP_CLK_PRESCALE_PER_NODE
DEF_MUTLCAP_SENSE_RESISTOR_PER_NODE
DEF_SELFCAP_FILTER_LEVEL_PER_NODE
DEF_SELFCAP_AUTO_OS_PER_NODE
DEF_SELFCAP_GAIN_PER_NODE DEF_SELFCAP_FREQ_MODE
DEF_SELFCAP_HOP_FREQS
DEF_SELFCAP_CLK_PRESCALE_PER_NODE
DEF_SELFCAP_SENSE_RESISTOR_PER_NODE
Sensor Calibration Auto Tune
Setting
AUTO_TUNE_PRSC, AUTO_TUNE_RSEL, AUTO_TUNE_NONE AUTO_TUNE_PRSC, AUTO_TUNE_RSEL, AUTO_TUNE_NONE
Sensor Noise measurement and
Lockout Parameters
DEF_MUTLCAP_NOISE_MEAS_ENABLE
DEF_MUTLCAP_NOISE_MEAS_SIGNAL_STABILITY_LIMIT
DEF_MUTLCAP_NOISE_LIMIT
DEF_MUTLCAP_NOISE_MEAS_BUFFER_CNT
DEF_MUTLCAP_LOCKOUT_SEL
DEF_MUTLCAP_LOCKOUT_CNTDOWN
DEF_SELFCAP_NOISE_MEAS_ENABLE
DEF_SELFCAP_NOISE_MEAS_SIGNAL_STABILITY_LIMIT
DEF_SELFCAP_NOISE_LIMIT
DEF_SELFCAP_NOISE_MEAS_BUFFER_CNT
DEF_SELFCAP_LOCKOUT_SEL
DEF_SELFCAP_LOCKOUT_CNTDOWN
Sensor Acquisition Frequency
Auto-tuning Parameters
DEF_MUTLCAP_FREQ_AUTO_TUNE_ENABLE
DEF_MUTLCAP_FREQ_AUTO_TUNE_SIGNAL_STABILITY_LIMIT
DEF_MUTLCAP_FREQ_AUTO_TUNE_IN_CNT
DEF_SELFCAP_FREQ_AUTO_TUNE_ENABLE
DEF_SELFCAP_FREQ_AUTO_TUNE_SIGNAL_STABILITY_LIMIT
DEF_SELFCAP_FREQ_AUTO_TUNE_IN_CNT
Common Parameters DEF_TOUCH_MEASUREMENT_PERIOD_MS, DEF_TOUCH_PTC_ISR_LVL
Low Power Paramaters DEF_LOWPOWER_SENSOR_EVENT_PERIODICITY, DEF_LOWPOWER_SENSOR_DRIFT_PERIODICITY_MS,
DEF_LOWPOWER_SENSOR_ID
Moisture Parameters DEF_MUTLCAP_MOIS_TOLERANCE_ENABLE
DEF_MUTLCAP_NUM_MOIS_GROUPS
DEF_MUTLCAP_MOIS_QUICK_REBURST_ENABLE
DEF_SELFCAP_MOIS_TOLERANCE_ENABLE
DEF_SELFCAP_NUM_MOIS_GROUPS
DEF_SELFCAP_MOIS_QUICK_REBURST_ENABLE
5.2.1. Pin, Channel, and Sensor Parameters
Mutual capacitance method uses a pair of sensing electrodes for each touch channel. These electrodes
are denoted as X and Y lines. Capacitance measurement is performed sequentially in the order in which
touch (X-Y) nodes are specified in the DEF_MUTLCAP_NODES configuration parameter. A mutual
capacitance touch button sensor is formed using a single X-Y channel, while a touch rotor or slider sensor
is formed using three to eight X-Y channels.
Mutual Capacitance Channel (X-Y Sense Node)
• SAM D20J and SAM D21J (64 pins): up to 256 touch channels, 16 X and 16 Y-lines
• SAM D20G and SAM D21G (48 pins): up to 120 touch channels, 12 X and 10 Y-lines
• SAM D20E and SAM D21E (32 pins): up to 60 touch channels, 10 X and 6 Y-lines
• SAM R21E(32 pins): up to 12 touch channels, 6 X and 2 Y-lines
• SAM R21G(48 pins) up to 48 touch channels, 8 X and 6 Y-lines
• SAM DA1J (64 pins): up to 256 touch channels, 16 X and 16 Y-lines
• SAM DA1G (48 pins): up to 120 touch channels, 12 X and 10 Y-lines
• SAM DA1E (32 pins): up to 60 touch channels, 10 X and 6 Y-lines
• SAM D21G17AU and SAM D21G18AU (45 pins): up to 132 touch channels, 12 X and 11 Y-lines
• SAM D21E15BU and SAM D21E16BU (35 pins): up to 60 touch channels, 10 X and 6 Y-lines
The following devices have X and Y multiplexing option.
• SAM D10C14A and SAM D11C14A (14 pins): up to 12 touch channels, 4 X and 3 Y-lines
• SAM D10D14 AS/AU and SAM D11D14 AS/AU (20 pins): up to 42 touch channels, 7 X and 6 Ylines
• SAM D10D14AM and SAM D11D14AM (24 pins): up to 72 touch channels, 9 X and 8 Y-lines
• SAM L21E (32 pins): up to 42 touch channels, 7 X and 6 Y-lines
• SAM L21G (48 pins): up to 81 touch channels, 9 X and 9 Y-lines
• SAM L21J (64 pins): up to 169 touch channels, 13 X and 13 Y-lines
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
22
• SAM L22G (48 pins): up to 132 touch channels, 11 X and 12 Y-lines
• SAM L22J (64 pins): up to 182 touch channels, 13 X and 14 Y-lines
• SAM L22N (100 pins): up to 256 touch channels, 16 X and 16 Y-lines
• SAM C21E and SAM C20E(32 pins): up to 60 touch channels,10 X and 6 Y-lines
• SAM C21G and SAM C20G(48 pins): up to 120 touch channels,12 X and 10-Y lines
• SAM C21J and SAM C20J(64 pins): up to 256 touch channels,16 X and 16 Y-lines
• ATmega328PB (32 pins): up to 144 touch channels, 12 X and 12 Y-lines
• ATmega324PB (44 pins): up to 256 touch channels, 16 X and 16 Y-lines
A few pins can be used either as X-line or Y-line. The datasheets of individual devices provide more
information about this multiplexing option.
Figure 5-3. Mutual Capacitance Sensor Arrangement
Figure 5-4. Mutual Capacitance - Channel to Sensor Mapping
X-Y node pair can be specified using the configuration parameter DEF_MUTLCAP_NODES in a nonsequential
order. The channel numbering is done in the same order as the X-Y node pair specified in the
configuration parameter DEF_MUTLCAP_NODES.
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
23
Setting Configuration Name Data Type Unit Min Max Typical
Mutual Cap
Touch
Channel
Nodes
DEF_MUTLCAP_NODES uint16_t
array
None 1 X-Y
node
pair
256 X-Y
nodepair
-
Mutual Cap
Number of
Channels
DEF_MUTLCAP_NUM_CHANNELS uint16_t None 1 256 X-Y
nodepair
-
Mutual Cap
Number of
Sensors
DEF_MUTLCAP_NUM_SENSORS uint16_t None 1 256 X-Y
nodepair
-
Mutual Cap
Number of
Rotors and
Sliders
DEF_MUTLCAP_NUM_ROTORS_SLIDERS uint8_t None 0 85 node
pair
-
Self-capacitance method uses a single sense electrode, denoted by a Y-line. Capacitance measurement
is performed sequentially in the order in which Y-lines are specified in the DEF_SELFCAP_LINES
configuration parameter. Self-capacitance touch button sensor is formed using a single - line channel,
while a touch rotor or slider sensor can be formed using three Y-line channels.
Self-capacitance Channel (Y-sense line)
• SAM D20J and SAM D21J (64 pins): up to 16 channels
• SAM D20G and SAM D21G (48 pins): up to 10 channels
• SAM D20E and SAM D21E (32 pins): up to 6 channels
• SAM D10C14A and SAMD 11C14A (14 pins): up to 7 touch channels
• SAM D10D14 AS/AU and SAMD 11D14 AS/AU (20 pins): up to 13 touch channels
• SAM D10D14AM and SAMD 11D14AM (24 pins): up to 16 touch channels
• SAM L21E (32 pins): up to 7 touch channels
• SAM L21G (48 pins): up to 10 touch channels
• SAM L21J (64 pins): up to 16 touch channels
• SAMR21E (32 pins): up to 2 touch channels
• SAMR21G (48 pins): up to 6 touch channels
• SAM DA1J (64 pins): up to 16 channels
• SAM DA1G (48 pins): up to 10 channels
• SAM DA1E (32 pins): up to 6 channels
• SAM C21E and SAM C20E (32 pins): up to 16 touch channels
• SAM C21G and SAM C20G (48 pins): up to 22 touch channels
• SAM C21J and SAM C20J (64 pins): up to 32 touch channels
• SAM L22G (48 pins): up to 15 touch channels
• SAM L22J (64 pins): up to 19 touch channels
• SAM L22N (100 pins): up to 24 touch channels
• ATmega328PB (32 pins): up to 24 touch channels
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
24
• ATmega324PB (44 pins): up to 32 touch channels
Figure 5-5. Self-capacitance Sensor Arrangement
Figure 5-6. Self-capacitance Channel to Sensor Mapping
Y sense line can be specified using the configuration parameter DEF_SELFCAP_LINES in non-sequential
order. The channel numbering is done in the same order as the Y sense line specified in the configuration
parameter DEF_SELFCAP_LINES.
Setting Configuration Name Data
Type
Unit Min Max Typical
Self Cap
touch
channel
nodes
DEF_SELFCAP_NODES uint16_t
array
None 1 Yline
32 Yline
-
Self Cap
number of
channels
DEF_SELFCAP_NUM_CHANNELS uint16_t None 1 Yline
32 Yline
-
Self Cap
number of
Sensors
DEF_SELFCAP_NUM_SENSORS uint16_t None 1 Yline
32 Yline
-
Self Cap
number of
Rotors and
Sliders
DEF_SELFCAP_NUM_ROTORS_SLIDERS uint8_t None 0 Yline
10 Yline
-
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
25
The touch sensors must be enabled in the sequential order of the channels specified using the
touch_xx_sensor_config() API. For improved EMC performance, a series resistor with value of 1
Kilo-ohm must be used on X and Y lines. For more information about designing the touch sensor, refer to
Buttons, Sliders and Wheels Touch Sensor Design Guide available at www.atmel.com.
5.2.2. Sensor Individual Parameters
This section explains the settings that are specific to the individual sensor.
Detect Threshold
A sensor's detect threshold defines how much its signal must increase above its reference level to qualify
as a potential touch detect. However, the final detection confirmation must satisfy the Detect Integrator
(DI) limit. Larger threshold values desensitize sensors since the signal must change more (i.e. requires
larger touch) to exceed the threshold level. Conversely, lower threshold levels make sensors more
sensitive.
Threshold setting depends on the amount of signal swing when a sensor is touched. Usually, thicker front
panels or smaller electrodes have smaller signal swing on touch, thus require lower threshold levels.
Typically, detect threshold isset to 50% of touch delta. Desired touch delta for a buttons is ~30 to 80
counts and for wheels or sliders is ~50 to 120 counts.
Setting Configuration
Name
Data Type Unit Min Max Typical
Threshold detect_threshold threshold_t Counts 3 255 20-50(For buttons)
30-80(For sliders and wheels
Detect Hysteresis
This setting is sensor detection hysteresis value. It is expressed as a percentage of the sensor detection
threshold setting. Once a sensor goes into detect its threshold level is reduced (by the hysteresis value)
in order to avoid the sensor dither in and out of detect if the signal level is close to original threshold level.
• Setting of 0 = 50% of detect threshold value (HYST_50)
• Setting of 1 = 25% of detect threshold value (HYST_25)
• Setting of 2 = 12.5% of detect threshold value (HYST_12_5)
• Setting of 3 = 6.25% of detect threshold value (HYST_6_25)
Setting Configuration
Name
Data Type Unit Min Max Typical
Hysteresis detect_threshold uint8_t
(2bits)
Enum HYST_6_25 HYST_50 HYST_6_25
Position Resolution
The rotor or slider needs the position resolution (angle resolution in case of rotor and linear resolution in
case of slider)to be set. Resolution is the number of bits needed to report the position of rotor or slider. It
can have values from 2 bits to 8 bits.
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
26
Setting Configuration Name Data Type Unit Min Reported
Position
Max Reported
Position
Typical
Position
Resolution
position_resolution uint8_t
(3bits)
None 2bits 0-3 8bits 0-255 8
Position Hysteresis
In case of Mutual Cap, the rotor or slider needs the position hysteresis (angle hysteresis in case of rotor
and linear hysteresis in case of slider) to be set. It is the number of positions the user has to move back,
before touch position is reported when the direction of scrolling is changed and during the first scrolling
after user press.
Hysteresis can range from 0 (1 position) to 7 (8 positions). The hysteresis is carried out at 8 bits
resolution internally and scaled to desired resolution; therefore at resolutions lower than 8 bits there might
be a difference of 1 reported position from the hysteresis setting, depending on where the touch is
detected. At lower resolutions, where skipping of the reported positions is observed, hysteresis can be set
to 0 (1 position). At Higher resolutions (6 to 8bits), it would be recommended to have a hysteresis of at
least 2 positions or more.
Note: It is not valid to have a hysteresis value more than the available bit positions in the resolution. For
instance, a hysteresis value of 5 positions with a resolution of 2 bits (4 positions) is invalid. Position
hysteresis is invalid (unused) in case of self-capacitance method sensors.
Setting Configuration Name Data Type Unit Min Max Typical
Position
Hysteresis
position_hysteresis uint8_t
(3bits)
- 0 7 8
Adjacent Key Suppression (AKS®
)
In designs where the sensors are close together or configured for high sensitivity, multiple sensors might
report a detect simultaneously. To allow applications to determine the intended single touch, the touch
library provides the user the ability to configure a certain number of sensors in an AKS group.
When a group of sensors are in the same AKS group, only the first strongest sensor will report detection.
The sensor reporting detection will continue to report detection even if another sensor's delta becomes
stronger. The sensor stays indetect until its delta falls lower than its detection threshold. If any more
sensors in the AKS group are still in detect onlythe strongest will report detection. At a given time point,
only one sensor from each AKS group is reported to be indetect.
AKS feature can be enabled or disabled using a macro DEF_XXXXCAP_AKS_ENABLE
• 1u = AKS grouping functionality is enabled
• 0u = AKS grouping functionality is disabled
The library provides the ability to configure a sensor to belong to one of the Adjacent Key Suppression
Groups (AKS Group).
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
27
5.2.3. Sensor Global Parameters
This section explains the settings that are common all sensors. For instance, if recalibration threshold
(one of the global settings) of mutual cap sensors is set as RECAL_100, all mutual capacitance sensors
will be configured for a recalibration threshold of 100%.These sensor global parameter settings can be
independently set to self-capacitance and mutual capacitance sensors.
Detect Integration
The QTouch Library features a detect integration mechanism, which confirm detection in a robust
environment. The detect integrator (DI) acts as a simple signal filter to suppress false detections caused
by spurious events such as electrical noise.
A counter is incremented each time the sensor delta has exceeded its threshold and stayed there for a
specific numberof acquisitions, without going below the threshold levels. When this counter reaches a
preset limit (the DI value) the sensor is finally declared to be touched. If on any acquisition the delta is
below the threshold level, the counter is cleared and the process has to start from the beginning. The DI
process is applicable to a 'release' (going out of detect) event as well.
For example, if the DI value is 10, the device has to exceed its threshold and stay there for (10 + 2)
successive acquisitions without going below the threshold level, before the sensor is declared to be
touched.
Setting Configuration Name Data Type Unit Min Max Typical
DI DEF_MUTLCAP_DI, DEF_SELFCAP_DI uint8_t Cycles 0 255 4
Max-ON Duration
If an object unintentionally contacts a sensor resulting in a touch detection for a prolonged interval it is
usually desirable to recalibrate the sensor in order to restore its function, after a time delay of a few
seconds.
The Maximum ON duration timer monitors such detections; if detection exceeds the timer's settings, the
sensor is automatically recalibrated. After a recalibration has taken place, the affected sensor once again
functions normally even if it still in contact with the foreign object.
Max-ON duration can be disabled by setting it to zero (infinite timeout) in which case the channel never
recalibrates during a continuous detection (but the host could still command it).
Setting Configuration Name Data Type Unit Min Max Typical
Maximum ON
Duration
DEF_MUTLCAP_MAX_ON_DURATION,
DEF_SELFCAP_MAX_ON_DURATION
uint8_t 200ms 0 255 30(6s)
Away from Touch and Towards Touch Drift Rate
Drift in a general sense means adjusting reference level (of a sensor) to allow compensation for
temperature (or other factor) effect on physical sensor characteristics. Decreasing reference level for
such compensation is called Negative drift & increasing reference level is called Positive drift. Specifically,
the drift compensation should be set to compensate faster for increasing signals than for decreasing
signals.
Signals can drift because of changes in physical sensor characteristics over time and temperature. It is
crucial that such drift be compensated for; otherwise false detections and sensitivity shifts can occur.
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
28
Drift compensation occurs only while there is no detection in effect. Once a finger is sensed, the drift
compensation mechanism ceases since the signal is legitimately detecting an object. Drift compensation
works only when the signal inquestion has not crossed the 'Detect threshold' level.
The drift compensation mechanism can be asymmetric. It can be made to occur in one direction faster
than it does in the other simply by changing the appropriate setup parameters.
Signal values of a sensor tend to increase when an object (touch) is approaching it or a characteristic
change of sensor over time and temperature. Increasing signals should not be compensated quickly, as
an approaching finger could be compensated for partially or entirely before even touching the channel
(towards touch drift).
However, an object over the channel which does not cause detection, and for which the sensor has
already made full allowance (over some period of time), could suddenly be removed leaving the sensor
with an artificially suppressed reference level and thus become insensitive to touch. In the latter case, the
sensor should compensate for the object's removal by raising the reference level relatively quickly (away
from touch drift).
Setting Configuration Name Data Type Unit Min Max Typical
Towards touch
Drift
DEF_MUTLCAP_TCH_DRIFT_RATE,
DEF_SELFCAP_TCH_DRIFT_RATE
uint8_t 200ms 0 127 20(4s)
Away from touch
Drift
DEF_MUTLCAP_ATCH_DRIFT_RATE,
DEF_SELFCAP_ATCH_DRIFT_RATE
uint8_t 200ms 0 127 5(1s)
Drift Hold Time
Drift Hold Time (DHT) is used to restrict drift on all sensors while one or more sensors are activated. It
defines the length of time the drift is halted after a key detection.This feature is useful in cases of high
density keypads where touching a key or floating a finger over the keypad would cause untouched keys
to drift, and therefore create a sensitivity shift, and ultimately inhibit any touch detection.
Setting Configuration Name Data Type Unit Min Max Typical
Drift Hold Time DEF_MUTLCAP_DRIFT_HOLD_TIME,
DEF_SELFCAP_DRIFT_HOLD_TIME
uint8_t 200ms 0 255 20(4s)
Away From Touch Recalibration Threshold
Recalibration threshold is the level beyond which automatic recalibration occurs. Recalibration threshold
is expressed as a percentage of the detection threshold setting.
This setting is an enumerated value and its settings are as follows:
• Setting of 0 = 100% of detect threshold (RECAL_100)
• Setting of 1 = 50% of detect threshold (RECAL_50)
• Setting of 2 = 25% of detect threshold (RECAL_25)
• Setting of 3 = 12.5% of detect threshold (RECAL_12_5)
• Setting of 4 = 6.25% of detect threshold (RECAL_6_25)
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
29
However, an absolute value of 4 is the hard limit for this setting. For example, if the detection threshold is,
40 and the Recalibration threshold value is set to 4.
Although this implies an absolute value of 2 (40 * 6.25% = 2.5), it is hard limited to 4.
Setting Configuration Name Data Type Unit Min Max Typical
Recalibration
threshold
DEF_MUTLCAP_ATCH_RECAL_THRESHOLD,
DEF_SELFCAP_ATCH_RECAL_THRESHOLD
uint8_t Enum RECAL_6_25 Detect
threshold
RECAL_100
Away From Touch Recalibration Delay
If any key is found to have a significant negative delta, it is deemed to be an error condition. If this
condition persists for more than the away from touch recalibration delay, i.e., qt_pos_recal_delay
period, then an automatic recalibration is carried out.
A counter is incremented each time the sensor delta is equal to the away from touch recalibration
threshold and stayed there for a specific number of acquisitions. When this counter reaches a preset limit
(the PRD value) the sensor is finally recalibrated. If on any acquisition the delta is seen to be greater than
the away from touch recalibration threshold level, the counter is cleared and the away from touch drifting
is performed.
For example, if the away from touch recalibration delay setting is 10, then the delta has to drop below the
recalibration threshold and stay there for 10 acquisitions in succession without going below the threshold
level, before the sensor is declared to be recalibrated. Away from touch recalibration can be disabled with
a setting of 0.
Setting Configuration Name Data Type Unit Min Max Typical
Away from touch
Recalibration
Delay
DEF_MUTLCAP_ATCH_RECAL_DELAY,
DEF_SELFCAP_ATCH_RECAL_DELAY
uint8_t Cycles 0 255 10
Sensor Post-Processing Mode
When TOUCH_LIBRARY_DRIVEN mode is selected, the library self-initiates repeated touch
measurements to resolve touch press, release and calibration. This mode is suited for best response
time.
When TOUCH_APPLN_DRIVEN mode is selected, the library does not initiate repeated touch
measurement to resolve touch press, release and calibration. This mode suits deterministic PTC interrupt
execution time for applications requiring stringent CPU time requirements. As repeated touch
measurements are delayed due to other critical application code being executed. This mode can
potentially affect the touch response time.
In order to improve the touch response time with the TOUCH_APPLN_DRIVEN mode, the
touch_xxxcap_sensors_measure API call should be modified as below to initiate touch
measurements periodically or when the burst again acquisition status flag has been set.
if ((touch_time.time_to_measure_touch == 1u) ||(p_mutlcap_measure_data->acq_status &
TOUCH_BURST_AGAIN)
{
/* Start a touch sensors measurement process. */
touch_ret =
touch_mutlcap_sensors_measure(touch_time.current_time_ms,NORMAL_ACQ_MODE,touch_mutlcap_measure
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
30
_complete_callback);
}
Setting Configuration Name Data Type Options Typical
Sensor
postprocessing
mode
DEF_MUTLCAP_TOUCH_POSTPROCESS_MODE,
DEF_SELFCAP_TOUCH_POSTPROCESS_MODE
uint16_t TOUCH_LIBRARY_DR
IVEN,
TOUCH_APPLN_DRIV
EN
TOUCH_LIBRARY_DRIVEN
Charge Share Delay
Charge share delay indicates the number of additional charge cycles that are inserted within a
capacitance measurement cycle to ensure that the touch sensor is fully charged. The CSD value is
dependent on the sensor capacitance along with the series resistor on the Y line.
Note: Any increase in the charge share delay also increases the measurement time for a specific
configuration.
When manual tuning is performed, the CSD value for the sensor with largest combination of capacitance
along with series resistance should be considered.
Setting Configuration Name Data Type Options Min Max Typical
CSD (Charge
Share Delay)
DEF_MUTL_CAP_CSD_VALUE,
DEF_SELF_CAP_CSD_VALUE uint8_t PTC cycles 0 250 0
How to tune the CSD setting manually?
1. Initially, use an arbitrarily large value such as 64 and note the signal value. A large value ensures
that the charge time is enough for full charge transfer
2. Reduce the CSD and verify the signal value drop, until signal is approximately 97-98% of the value
used initially. This ensures a good charge transfer without any major loss in the signal.
3. Continue the same procedure [Step 1 and 2] for all the sensors available in the system. Use the
largest value of the CSD used in the system for the global setting.
Note: For the same CSD setting, Mutual capacitance has a lower burst time than self-capacitance. A
unit increase in mutual capacitance CSD consumes around 12 PTC cycles. Whereas for the selfcapacitance
an increase in CSD consumes approximately twice the mutual capacitance CSD time with
the same setting.
Auto-OS Signal Stability Limit
The parameter DEF_XXXXCAP_AUTO_OS_SIGNAL_STABILITY_LIMIT defines the stability limit of the
signals for performing over-samples. Stability limit is the variance in sensor signal value under noisy
environment. A high level of stability limit is set to auto trigger oversamples on large noise presence. It is
recommended to keep this setting close to the lowest sensor detect threshold of the system and tune it
further based on the noise.
Range: 1 to 1000
5.2.4. Sensor Acquisition Parameters
Filter Level
The filter level setting controls the number of samples taken to resolve each acquisition. A higher filter
level setting provides improved signal to noise ratio under noisy conditions, while increasing the total time
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
31
for measurement resulting in increased power consumption and response time. This setting is available
on per channel basis, allowing easy tuning.
Setting Configuration Name Data Type Options Min Max Typical
Filter level DEF_MUTLCAP_FILTER_LEVEL_PER_NODE,
DEF_SELFCAP_FILTER_LEVEL_PER_NODE
filter_level_t Number of samples 1 64 16
Auto Oversamples
Auto oversample controls the automatic oversampling of sensor channels when unstable signals are
detected with the default setting of 'Filter level'. Enabling Auto oversample results in 'Filter level' x 'Auto
Oversample' number of samples taken on the corresponding sensor channel when an unstable signal is
observed. In a case where 'Filter level' is set to FILTER_LEVEL_4 and 'Auto Oversample' is set to
AUTO_OS_4, 4 oversamples are taken with stable signal values and 16 oversamples are taken when
unstable signal is detected. This setting is available on per channel basis, allowing easy tuning.
A higher filter level setting provides improved signal to noise ratio under noisy conditions, while increasing
the total time for measurement resulting in increased power consumption and response time.
Figure 5-7. Auto oversamples
Auto oversamples can be disabled to obtain best power consumption.
Setting Configuration Name Data Type Options Min Max Typical
Auto Oversamples DEF_MUTLCAP_AUTO_OS_PER_NODE,
DEF_SELFCAP_AUTO_OS_PER_NODE
auto_os_t Sample
multiplier
2 128 AUTO_OS_NONE
Gain Setting
Gain setting is applied on a per-channel basis to allow a scaling-up of the touch delta upon contact. Gain
setting depends on the sensor design and touch panel thickness.
Setting Configuration Name Data Type Options Min Max Typical
Gain DEF_MUTLCAP_GAIN_PER_NODE,
DEF_SELFCAP_GAIN_PER_NODE
gain_t Gain multiplier 1 32 1 (For selfcapacitance)
4 (For
mutual
capacitance)
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
32
The figure shows the expected signal value for a given combination of gain setting and filter level setting.
The values provided are only indicative and the actual sensor signal values might be close to the
suggested levels.
Figure 5-8. Average Settling Signal Value for FILTER LEVEL and GAIN Combination
Prescalar Setting
The prescaler parameter denotes the clock divider for the particular channel. It can be set on per channel
basis and is independent to each sensor node/channel. This parameter is auto tuned based on the auto
tune settings. Tuning this parameter allows for improved noise performance.
Setting Configuration Name Data Type Options Min Max Typical
Prescalar DEF_MUTLCAP_CLK_PRESCALE_PER_NODE,
DEF_SELFCAP_CLK_PRESCALE_PER_NODE
prsc_div_sel_t PRSC_DIV_SEL_1,
PRSC_DIV_SEL_2,
PRSC_DIV_SEL_4,
PRSC_DIV_SEL_8
PRSC_DIV_SEL_1 PRSC_DIV_SEL_8 PRSC_DIV_SEL_1
Series Resistor Setting
The series resistor denotes the resistor used on the particular channel for the acquisition. The value is
tunable and allows both auto and manual tuning options. Tuning this parameter allows for improved noise
performance.
Settin
g
Configuration Name Data Type Options Min Max Typical
Series
Resist
or
DEF_MUTLCAP_SENSE_RESI
STOR_PER_NODE
DEF_SELFCAP_SENSE_RESI
STOR_PER_NODE
rsel_val_t RSEL_VAL_0,
RSEL_VAL_20,
RSEL_VAL_50,
RSEL_VAL_100
RSEL_VAL_0 RSEL_VAL_100 RSEL_VAL_100
Boot Prescalar Setting
The boot prescaler parameter denotes the clock divider for the particular channel. It can be set on per
channel basis and is independent to each sensor node/channel. This setting is used for calibrating the
sensors after a power-on. This parameter must be configured as the auto tune is not available.
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
33
Setting Configuration Name Data Type Options Min Max Typical
Boot
Prescalar
DEF_MUTLCAP_CC_CAL_CLK_PRESCALE_PER_NODE,
DEF_SELFCAP_CC_CAL_CLK_PRESCALE_PER_NODE
prsc_div_sel_t PRSC_DIV_SEL_1,
PRSC_DIV_SEL_2,
PRSC_DIV_SEL_4,
PRSC_DIV_SEL_8
PRSC_DIV_SEL_1 PRSC_DIV_SEL_8 PRSC_DIV_SEL_1
Boot Series Resistor Setting
The boot series resistor denotes the resistor used on the particular channel on device power-on
calibration. This parameter must be configured as the auto tune is not available.
Setting Configuration Name Data Type Options Min Max Typical
Boot Series
Resistor
DEF_MUTLCAP_CC_CAL_SENSE_RESISTOR_PER_NODE
DEF_SELFCAP_CC_CAL_SENSE_RESISTOR_PER_NODE
rsel_val_t RSEL_VAL_0,
RSEL_VAL_20,
RSEL_VAL_50,
RSEL_VAL_100
RSEL_VAL_0 RSEL_VAL_100 RSEL_VAL_100
Frequency Mode
Frequency mode setting allows users to tune the PTC touch acquisition frequency characteristics to
counter environment noise.
FREQ_MODE_HOP
When frequency mode hopping option is selected, the PTC runs a frequency hopping cycle with
subsequent measurements done using the three PTC acquisition frequency delay settings as specified in
DEF_SELFCAP_HOP_FREQS. In this case, an additional software median filter is applied to the measured
signal values.
FREQ_MODE_SPREAD
When frequency mode spread spectrum option is selected, the PTC runs with spread spectrum enabled
for jittered delay based acquisition.
FREQ_MODE_SPREAD_MEDIAN
When frequency mode spread spectrum median option is selected, the PTC runs with spread spectrum
enabled. In this case, an additional software median filter is applied to the measured signal values.
FREQ_MODE_NONE
When frequency mode none option is selected, the PTC runs at constant speed. This mode is suited for
best power consumption.
Setting Configuration Name Data Type Options Min Max Typical
Frequency
mode
DEF_MUTLCAP_FREQ_MODE
,
DEF_SELFCAP_FREQ_MODE
freq_mode_sel_t FREQ_MODE_NONE,
FREQ_MODE_HOP,
FREQ_MODE_SPREAD,
FREQ_MODE_SPREAD_MEDIAN
FREQ_MODE_NONE FREQ_MODE_SPREAD_MEDIAN FREQ_MODE_NONE
Frequency Hop Delay
The frequency hop delay setting is used when the Frequency mode is set to FREQ_MODE_HOP. A set of
three frequency hop delay settings should be specified. This delay setting inserts n PTC clock cycles
between consecutive measurements on a given sensor, thereby changing the PTC acquisition frequency.
FREQ_HOP_SEL_1 setting inserts 0 PTC clock cycle between consecutive measurements.
FREQ_HOP_SEL_16 setting inserts 15 PTC clock cycles. Hence, higher delay setting will increase the
total time taken for capacitance measurement on a given sensor as compared to a lower delay setting. A
desired setting can be used to avoid noise around the same frequency as the acquisition frequency.
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
34
Setting Configuration Name Data Type Unit Min Max Typical
Frequency
hop delay
DEF_MUTLCAP_HOP_FREQS,
DEF_SELFCAP_HOP_FREQS
freq_hop_sel_t nPTC_clock_cycles FREQ_HOP_SEL_1 FREQ_HOP_
SEL_16
FREQ_HOP_SEL_1,
FREQ_HOP_SEL_2,
FREQ_HOP_SEL_3
5.2.5. Sensor Calibration Auto Tune Setting
Auto tune parameter setting is passed to the touch_xx_sensors_calibrate API in order to allow
users to tune the PTC module for power consumption or noise performance.
AUTO_TUNE_PRSC
When Auto tuning of pre-scaler is selected, the PTC uses the user defined internal series resistor setting
(DEF_XXXXCAP_SENSE_RESISTOR_PER_NODE ) and the pre-scaler is adjusted to slow down the PTC
operation to ensure full charge transfer. Auto tuning of pre-scaler with RSEL_VAL_100 as the series
resistor results in least power consumption while resulting in increased power consumption and touch
response time.
AUTO_TUNE_RSEL
When Auto tuning of the series resistor is selected, the PTC runs at user defined pre-scaler setting speed
(DEF_XXXXCAP_CLK_PRESCALE_PER_NODE) and the internal series resistor is tuned automatically to
the optimum value to allow for full charge transfer. Auto tuning of series resistor with PRSC_DIV_SEL_1
as the PTC pre-scale results in best case power consumption.
AUTO_TUNE_NONE
When manual tuning option is selected, the user defined values of PTC pre-scaler and series resistor is
used for PTC operation as given in DEF_XXXXCAP_CLK_PRESCALE_PER_NODE and
DEF_XXXXCAP_SENSE_RESISTOR_PER_NODE
Setting Configuration Name Data Type Unit Values Typical
Auto tune Provided to
touch_xxcap_sensors_calibrate API
input
auto_tune_type_t None AUTO_TUNE_NONE,
AUTO_TUNE_PRSC,AU
TO_TUNE_RSEL
AUTO_TUNE_NONE
5.2.6. Sensor Noise Measurement and Lockout Parameters
Noise is measured on a per-channel basis after each channel acquisition, using historical data on a rolling
window of successive measurements. Reported noise to exclude the instance of an applied or removed
touch contact, but the noise indication must react sufficiently fast that false touch detection before noise
lockout is prevented.
Signal change from sample to sample during the window buffer is compared to the stability limit. Noise is
reported only when two changes occur within the window period and both of which exceed the
DEF_XXXXCAP_NOISE_MEAS_SIGNAL_STABILITY_LIMIT limit.
Noise is calculated using the following algorithm:
if (swing count > 2)
{
Nk = ((|Sn – Sn-1| > DEF_XXXXCAP_NOISE_MEAS_SIGNAL_STABILITY))?(0):(|Sn-Sn-1|-
DEF_XXXXCAP_NOISE_MEAS_SIGNAL_STABILITY))
}
else
{
Nk = 0
}
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
35
The swing count is number of signal changes that exceed
DEF_MUTLCAP_NOISE_MEAS_SIGNAL_STABILITY_LIMIT limit during buffer window period.
When the measured noise exceeds DEF_MUTLCAP_NOISE_LIMIT, the touch library locks out sensors,
reports no touch detection and drifting is stopped. Noise measurement is provided for all the channels.
Each byte in p_xxxxcap_measure_data-> p_nm_ch_noise_val provides the noise level
associated with that channel. Noise indication is provided for all the sensors configured by the application.
A bit is available in p_xxxxcap_measure_data-> p_sensor_noise_status for each sensor to
determine whether the sensor is noisy or not. The following code snippet provides the sample code to
read the noise status of a particular sensor.
Figure 5-9. Noise Calculation
Noise Measurement Signal Stability Limit
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
36
The parameter DEF_XXXXAP_NOISE_MEAS_SIGNAL_STABILITY_LIMIT is the variance in sensor
signal value under noisy environment. Any noise level over and above the noise signal stability limit
contributes to the Noise limit.
It is recommended to keep this setting close to the lowest sensor detect threshold of the system and tune
it further based on the noise.
Signal values can change from sample to sample during a window buffer period. The difference between
adjacent buffer value is compared to the user configured stability limit.
Noise is reported only when two changes occur within the specified window period and only if both of
which exceed the stability limit.
Range: 1 to 1000
Noise Limit
The DEF_XXXXCAP_NOISE_LIMIT specifies the limit to the total noise accumulated over the noise buffer
count. If the accumulated noise exceeds the noise limit, then lockout is triggered. There are two purposes
for this parameter:
• If the noise level calculated during a running window exceeds DEF_XXXXCAP_NOISE_LIMIT, then
the corresponding sensor are declared noisy and sensor global noisy bit is set as '1'.
• If the noise level calculated during a running window exceeds DEF_XXXXCAP_NOISE_LIMIT, then
system triggers the sensor lockout functionality.
Range: 1 to 255
Noise Measurement Buffer Count
The DEF_XXXXCAP_NOISE_MEAS_BUFFER_CNT parameter is used to select the buffer count for noise
measurement buffer.
Range: 3 to 10 (If N number of samples differences have to be checked, define this parameter as "N + 1")
If N = 4 then set DEF_XXXXCAP_NOISE_MEAS_BUFFER_CNT as 5u.
Sensor Lockout Selection
This feature locks out the sensors when the measured noise exceeds DEF_XXXXCAP_NOISE_LIMIT and
does not report a touch. This prevents post-processing. So, the high level of noise cannot cause the
channel to report false touch drift or recalibrate incorrectly.
The DEF_XXXXCAP_LOCKOUT_SEL parameter is used to select the lockout functionality method.
• If DEF_XXXXCAP_LOCKOUT_SEL is set to SINGLE_SENSOR_LOCKOUT and a sensor's noise level is
greater than DEF_XXXXCAP_NOISE_LIMIT, then corresponding sensor is locked out from touch
detection and drifting is disabled.
• If DEF_XXXXCAP_LOCKOUT_SEL is set to GLOBAL_SENSOR_LOCKOUT and any sensor's noise level
is greater than DEF_XXXXCAP_NOISE_LIMIT, then all sensors are locked out from touch detection
and drifting is disabled.
• If DEF_XXXXCAP_LOCKOUT_SEL is set to NO_LOCKOUT, then lockout feature is disabled.
Note: Global sensors noisy bit will be available for SINGLE_SENSOR_LOCKOUT and
GLOBAL_SENSOR_LOCKOUT. Global sensors noisy bit will not be available for NO_LOCK_OUT.
Range: 0 to 2
Sensor Lockout Countdown
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
37
If the sensor signal moves from noisy to a good condition and stays there for a DEF_XXXXCAP_
LOCKOUT_CNTDOWN number of measurements, the sensor is unlocked and sensors are ready for touch
detection and drifting is enabled.
Note: This parameter is valid only for global lockout.
Range: 1 to 255
5.2.7. Sensor Acquisition Frequency Auto Tuning Parameters
The Frequency Auto Tune feature provides the best quality of signal data for touch detection by
automatically selecting acquisition frequencies showing the best SNR in FREQ_MODE_HOP mode. During
each measurement cycle, the signal change since the last acquisition at the same frequency is recorded
for each sensor. After the cycle, when all sensors have been measured at the present acquisition
frequency, the largest signal variation of all sensors is stored as the variance for that frequency stage.
The variance for each frequency stage is compared to the DEF_XXXXCAP_FREQ_AUTO_SIGNAL_
STABILITY_LIMIT limit, and if the limit is exceeded, a per-stage counter is incremented. If the
measured variance is lower than the limit, the counter is decremented, if it has not been set as zero. If all
frequencies display noise exceeding the stability limit, only the counter for the specific frequency stage
with the highest variance is incremented after its cycle.
When a frequency counter reaches the DEF_XXXXCAP_FREQ_AUTO_TUNE_IN_CNT (auto-tune count in
variable), that frequency stage is selected for auto-tuning. A new frequency selection is applied and the
counters and variances for all frequencies are reset. After a frequency has been selected for auto-tuning,
the count-in for that frequency stage is set to half the original count-in and the process is repeated until
either all frequencies have been measured or a frequency is selected which does not re-trigger autotuning
is determined.
If all frequencies have been tested, and the variation exceeds the
DEF_XXXXCAP_FREQ_AUTO_SIGNAL_STABILITY_LIMIT limit then the frequency with the lowest
variance is selected for the frequency stage currently under tuning. The auto-tune process is re-initialized
and further tuning does not take place until a frequency stage's high variance counter again reaches the
count in limit.
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
38
Figure 5-10. Frequency Auto Tune
Frequency Auto Tune Signal Stability
The DEF_XXXXCAP_FREQ_AUTO_SIGNAL_STABILITY_LIMIT is the variance in sensor signal value
under noisy environment. A signal stability limit level is set to auto tune acquisition frequency on noise
presence. It is recommended to keep this setting close to the lowest sensor detect threshold of the
system and tune it further based on the noise.
Range: 1 to 1000
Frequency Auto Tune in Counter
The DEF_XXXXCAP_FREQ_AUTO_TUNE_IN_CNT parameter is used to trigger the frequency auto tune.If
sensor signal change at each frequency exceeds the value specified as
DEF_XXXXCAP_FREQ_AUTO_SIGNAL_STABILITY_LIMIT for
DEF_XXXXCAP_FREQ_AUTO_TUNE_IN_CNT, then frequency auto tune will be triggered at this frequency.
Range: 1 to 255
Note: The Frequency Auto Tune feature and related parameters are available only in FREQ_MODE_HOP
mode.
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
39
5.2.8. Quick Re-burst Parameter
Quick Reburst
This macro is used to enable or disable quick re-burst feature. When Quick re-burst is enabled, upon user
touch and release, only that touched sensor or channel is subsequently measured to resolve detect
integration (or debounce). Enabling this feature results in best touch response time.
When Quick re-burst is disabled, upon user touch and release, all sensors or channels are measured to
resolve detect integration (or debounce). This feature should only be disabled when developing any
special application involving all sensor measurements during user activity.
Within an AKS (Adjacent Key suppression) group, all the sensors within that group are measured during
user touch independent of this feature being enabled or disabled.
5.2.9. Common Parameters
Measurement Period
The measurement period setting is used to set the periodic interval for touch sensor measurement. The
minimum measurement period setting should be greater than the time taken to complete measurement
on all sensors. This can be simply determined by calling the touch_xx_sensors_measure API in a
while loop and then toggling a GPIO pin in the measurement complete callback.
main()
{
while(1)
{
touch_ret =
touch_mutlcap_sensors_measure(touch_time.current_time_ms,NORMAL_ACQ_MODE,touch_mutlcap_measure
_complete_callback);
}
}
void touch_mutlcap_measure_complete_callback( void )
{
if (!(p_mutlcap_measure_data->acq_status & TOUCH_BURST_AGAIN))
{
/* Set the Mutual Cap measurement done flag. */
p_mutlcap_measure_data->measurement_done_touch = 1u;
port_pin_toggle_output_level(PIN_PB00);
}
}
Setting Configuration Name Data Type Unit Values Max Typical
Sensor
measurement
interval
DEF_TOUCH_MEASUREMENT_PERIOD_MS uint16_t millisecond Should be
found
through
GPIO pin
toggle
procedure.
65535 20
PTC Interrupt Priority Level
The Nested Vectored Interrupt Controller (NVIC) in the SAM has four different priority levels. The priority
level of thePTC end of conversion ISR can be selected based on application requirements to
accommodate time critical operations. Setting the PTC interrupt priority level to lowest can have an
impact on the touch response time, depending on the execution time taken by other higher priority
interrupts.
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
40
Setting Configuration Name Data Type Unit Min Max Typical
PTC interrupt
priority level
DEF_TOUCH_PTC_ISR_LVL uint8_t None 0 (Highest
Priority)
3 (Lowest
Priority)
3
To avoid stack overflow, ensure that adequate stack size has been set in the user application.This
configuration is applicable only for SAM devices.
touch_suspend_app_cb
Callback function pointer that must be initialized by the application before a touch library API is called.
Touch library would call the function pointed by this function when suspension operation has to be carry
on by the application.
Setting Configuration Name Data Type Returns
Suspend Callback touch_suspend_app_cb void(* volatile
touch_suspend_app_cb) (void)
void
Low power Sensor Event Periodicity
When the CPU returns to standby mode from active, the sensor configured as the low power sensor is
scanned at this interval. A high value for this parameter will reduce power consumption but increase
response time for a low power sensor.
The following macros are used for configuring the low power sensor event periodicity:
• The macro LOWPOWER_PER0_SCAN_3_P_9_MS sets the scan rate at 3.9ms
• The macro LOWPOWER_PER1_SCAN_7_P_8_MS sets the scan rate at 7.8ms
• The macro LOWPOWER_PER2_SCAN_15_P_625_MS sets the scan rate at 15.625ms
• The macro LOWPOWER_PER3_SCAN_31_P_25_MS sets the scan rate at 31.25ms
• The macro LOWPOWER_PER4_SCAN_62_P_5_MS sets the scan rate at 62.5ms
• The macro LOWPOWER_PER5_SCAN_125_MS sets the scan rate at 125ms
• The macro LOWPOWER_PER6_SCAN_250_MS sets the scan rate at 250ms
• The macro LOWPOWER_PER7_SCAN_500_MS sets the scan rate at 500ms
Low power Sensor Drift Periodicity
This parameter configures the scan interval for a single active measurement during low power mode. This
active measurement is required for reference tracking of low power sensor.
Setting Configuration Name Data Type Unit Min Max Typical
Low
power
sensor
drift
rate
DEF_LOWPOWER_SENSOR_DRIFT_PERIODICITY_MS uint16_t milliseconds 0 65535 2000
Low power sensor ID
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
41
The macro DEF_LOWPOWER_SENSOR_ID is used to configure a sensor as low power sensor. Only one
sensor can be configured as low power sensor. Low power sensor can be a normal sensor or a lumped
sensor.
5.2.10. Moisture Parameters
Moisture Tolerance Enable
The macro DEF_XXXXCAP_MOIS_TOLERANCE_ENABLE is used to Enable or disable Moisture detection
feature.
Moisture Quick Reburst
The macro DEF_XXXXCAP_MOIS_QUICK_REBURST_ENABLE is used to enable or disable quick re-burst
feature within a given moisture group. When enabled, if within a given moisture group, when any sensor
is touched, repeated measurements are done only that sensor to resolve detect integration or de-bounce.
When disabled, if within a given moisture group, when any sensor is touched, repeated measurements
are done on all sensors within the moisture group to resolve detect integration or de-bounce. It is
recommended to enable this feature for best touch response time.
Moisture groups
The macro DEF_XXXXCAP_NUM_MOIS_GROUPS specifies the total number of individual moisture group
present the system.
5.2.11. PTC Lines Ground Feature
PTC GPIO State
The macro DEF_XXXXCAP_PTC_GPIO_STATE is used to set the unmeasured self/mutual capacitance
PTC lines to Ground / Vcc in between PTC measurement cycle. Setting the PTC lines to
GND_WHEN_NOT_MEASURED will set the state of the pin to low whenever the pin is unmeasured. Setting
the PTC lines to PULLHIGH_WHEN_NOT_MEASURED will make the PTC lines to float in between sensor
measurement in a measurement cycle. It is recommended to set GND_WHEN_NOT_MEASURED
configuration to get low power.
5.3. Moisture Tolerance
Moisture tolerance check executes at the end of each measurement cycle and compares the sum of delta
of all sensors in a moisture tolerance group against pre-configured threshold. If delta sum is greater than
sensor moisture lock threshold and less than system moisture lock threshold, then the ON-state sensors
within moisture tolerance group will be considered as moisture affected.
If delta sum is greater than system moisture lock threshold, all sensors within the moisture tolerance
group will be considered as moisture affected. This condition is referred as moisture global lock out. The
library will come out of the moisture global lock out state when delta sum is less than threshold for 5
consecutive measurements. Self cap and mutual cap sensors cannot be configured in a single moisture
group, Self cap moisture tolerance and mutual cap Moisture tolerance features can be enabled or
disabled separately.
Note: Lumped sensor and the sensor which is part of the specific lump should not be assigned to same
moisture group.
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
42
Figure 5-11. Moisture Tolerance Algorithm
5.3.1. Moisture Tolerance Group
This feature enables the customer application to group a set of sensors in to single moisture tolerance
group. If moisture on one sensor might affect other sensors due to physical proximity, they must be
grouped together into one Moisture tolerance group.
Using this feature the application can disable moisture tolerance detection for a set of sensors, Multiple
Moisture tolerance groups can be formed by the customer application. The library supports up to a
maximum of 8 moisture groups.
Note: Changing the moisture tolerance group configuration during runtime is not recommended.
However, muti-touch group configuration can be changed during runtime.
5.3.2. Multi-touch Group
If the user wants to touch multiple sensors within the moisture tolerance group simultaneously to indicate
a specificrequest, then the application should configure those sensors into single multi-touch group.
Multiple multi-touch groups can be formed by the customer application. The library supports a maximum
of 8 multi-touch groups within a single moisture tolerance group.
Moisture tolerance feature improves a system’s performance under the following scenarios:
• Droplets of water sprayed on the front panel surface
• Heavy water poured on the front panel surface
• Large water puddle on multiple sensors
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
43
• Trickling water on multiple sensors
Moisture tolerance feature is not expected to offer any significant performance improvement under the
following scenarios:
• Large isolated puddle on single sensor
• Direct water pour on single sensor
Within the same moisture group, user should not configure all the sensors to the single multi-touch group.
5.4. Reading Sensor States
When noise immunity and moisture tolerance features are enabled the validity of the sensor sate is based
on the moisture status and noise status. Refer Noise Counter Measures and Moisture Parameters for
information on noise immunity and moisture tolerance status of sensors. The state of a sensor is valid
only when the sensor is not affected by noise and moisture. If a sensor is noisy or affected by moisture,
then the state of sensor must be considered as OFF. The code snippet below depicts the same for
mutual-cap sensors.
When a sensor is touched or released during DI, library will burst on channels corresponding to sensors
whose state is other than OFF or DISABLED. If any sensor in an AKS group is in a state other than OFF
or DISABLED, the library will burst channels corresponding sensors belong to that AKS group. If a sensor
in any moisture group is in a state other than OFF or DISABLED, the library will burst on channels
corresponding to sensors belonging to that moisture group.
if(! (GET_MUTLCAP_SENSOR_NOISE_STATUS(SENSOR_NUMBER)))
{
if(! (GET_MUTLCAP_SENSOR_MOIS_STATUS (SENSOR_NUMBER)))
{
/*Sensor state is valid Read sensor state */
}
else
{
/* Sensor is Moisture affected*/
}
}
else
{
/* Sensor is noisy */
}
5.5. Application Flow
5.5.1. Application Flow SAM
The application periodically initiates a touch measurement on either mutual capacitance or selfcapacitance
sensors. At the end of each sensor measurement, the PTC module generates an end of
conversion (EOC) interrupt. The touch measurement is performed sequentially until all the sensors are
measured. Additional post-processing is performed on the measured sensor data to determine touch
status and rotor/slider position. An interrupt callback function is triggered to indicate completion of
measurement. The recommended sequence of operation facilitates the CPU to either sleep or perform
other functions during touch sensor measurement.
Before using the PTC, the generic clock generator for the PTC peripheral should be set up by the
Application. It is recommended to set the PTC generic clock to 4MHz.
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
44
Figure 5-12. Application vs QTouch Library Flow
5.5.2. Application Flow - megaAVR
The application periodically initiates a touch measurement on either mutual capacitance or selfcapacitance
sensors either in polled or interrupt mode. In polling mode, touch API's are blocking API's
and will consume more CPU time. In ISR mode, touch API's are non blocking and will generates an end
of conversion (EOC) interrupt at the end of each sensor measurement.Touch measurement is intiated on
first sensor by calling touch_xxxxcap_sensors_measure() API .The touch measurement is initiated
sequentially and additional post-processing is performed on the measured sensor data to determine
touch status and rotor/slider position by calling touch_ptc_process() API in application context
instead of interrupt context. A callback function is triggered to indicate completion of measurement .The
ISR mode sequence of operation facilitates the CPU to either sleep or perform other functions during
touch sensor measurement.
It is recommended to set the PTC clock to 4MHz.
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
45
Figure 5-13. Application vs QTouch Library Flow
5.6. API Sequence
The touch_xx_sensors_init API initializes the QTouch Library as well as the PTC module. It also
initializes the mutual or self-capacitance method specific pin, register, and global sensor configuration.
The touch_xx_sensor_config API configures the individual sensor. The sensor specific
configuration parameters can be provided as input arguments to this API.
The touch_xx_sensors_calibrate API calibrates all the configured sensors and prepares the
sensors for normal operation. The touch_xx_sensors_measure API initiates a sensor measurement
on all the configured sensors.
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
46
Figure 5-14. API Sequence with Combined self and Mutual Capacitance Sensors Enabled
5.7. State Machine
The PTC QTouch Library state machine that presents the various library States and Event transitions can
be found in the figure below. The state machine is maintained separately for each of the touch acquisition
method, which means the state of mutual capacitance sensor operation can be different from the state of
self-capacitance allowing them to co-exist.
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
47
Figure 5-15. Library State Machine
The touch_xx_sensors_init API initializes the QTouch Library as well as the PTC module. It also
initializes the mutual or self-capacitance method specific pin, register, and global sensor configuration.
The touch_xx_sensor_config API configures the individual sensor. The sensor specific configuration
parameters can be provided as input arguments to this API.
The touch_xx_sensors_calibrate API calibrates all the configured sensors and prepares the
sensors for normal operation.
The touch_xx_sensors_measure API initiates a sensor measurement on all the configured sensors.
The touch_xx_sensors_deinit function is used to clear the initialized library state. Used for clearing
the internal library data and states. When called will modify the library state to TOUCH_STATE_NULL.
The touch_xxxx_lowpower_sensor_enable_event_measure API is used to start a event trigger
based low power sensor measurement.
Touch Library Suspend Resume Operation
The touch library provides touch_suspend_ptc, touch_resume_ptc API to suspend and resume
the PTC.
When suspend API is called, the touch library initiates the suspend operation and return to the
application. After completing the current PTC conversion, the touch library will initiate suspend operation
and call the application touch suspend callback function pointer. The suspend complete callback function
pointer has to be registered by the application.
Note: If it is not registered, then the suspend call will return TOUCH_INVALID_INPUT_PARAM.
The application then should disable corresponding clock to reduce the power consumption. The following
flowchart depicts the suspend sequence.
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
48
Figure 5-16. Suspend Sequence
Touch_suspend_ptc()
Is Callback Received?
Wait for touch_suspend_callback
if touch state is in
TOUCH_STATE_BUSY or perform
some other application code
without calling any Touch _lib APIs
Yes
disable PTC GCLK
disable APBCMASK
disable GCLK generator
disable GCLK source
SUSPENSION_COMPLETE
SUPENSION_START
No
If the touch state is not TOUCH_STATE_BUSY the user can disable the clock and proceed to complete the
suspend routine.
To resume the operations, perform the following sequence:
Figure 5-17. Resume Sequence
The SAM controllers may be configured to operate PTC touch sensing autonomously using the Event
System. In this mode, a single sensor channel is designated as the 'Low Power' key and may be
periodically measured for touch detection without any CPU action. The CPU may be held in STANDBY
throughout the operation, minimizing power consumption.
The low power key may be a discrete electrode with one Y (Sense) line for self-capacitance or one X
(Drive) plus one Y (Sense) for mutual capacitance, or it may be a combination of multiple Drive and/or
Sense lines as a lumped mode sensor as described.
With this method, a fast response may be achieved even in large key-count applications while operating
at an extremely low power level, drawing less than 10uA at 3.3V.
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
49
5.8. Operation Modes
The QTouch Library can operate in the following sensor measurement modes.
• Periodic measurement
• Continuous measurement
5.8.1. Periodic Measurement
In the periodic measurement mode, sensor measurement is initiated by the application through a periodic
event such as timer interrupt. The periodic measurement mode scenario is when none of the sensors are
touched. While a long measurement period can be used to achieve lower device power consumption, a
short measurement period is required for better touch response time. Hence, the measurement period
should be tuned to suit a given application. Typical measurement period can range between 20
millisecond to 250 millisecond.
Figure 5-18. Periodic Measurement Mode
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
50
5.8.2. Continuous Measurement
In the continuous measurement mode, back to back sensor measurement can be initiated from the touch
library. This mode can be triggered to resolve user presence or resolve calibration under the following
scenario.
• Resolve user presence, when sensor is touched or released
• Resolve calibration, when
– Sensor is calibrated using the touch_xx_sensors_calibrate API
– Sensor is in Away from touch re-calibration condition
– Sensor is in Max-on duration condition
The TOUCH_BURST_AGAIN acquisition status data bit field in the measure data structure is set to indicate
continuous measurement mode.
void touch_mutlcap_measure_complete_callback(void)
{
if (!(p_mutlcap_measure_data->acq_status & TOUCH_BURST_AGAIN))
{
/* Set the Mutual Cap measurement done flag. */
p_mutlcap_measure_data->measurement_done_touch = 1u;
}
}
Touch Library Acquisition Status Flags
The touch library acquisition status information during continuous measurement mode is available using
the touch_acq_status_t acq_status element of the touch_measure_data_t touch measure
data structure.
Table 5-1. Touch Acquisition Status Bit Fields
Macro Bitfield Comment
TOUCH_NO_ACTIVITY 0x0000u No Touch activity
TOUCH_IN_DETECT 0x0001u Atleast one Touch channel is in detect
TOUCH_STATUS_CHANGE 0x0002u Change in Touch status of atleast one Touch
channel
TOUCH_ROTOR_SLIDER_POS_C
HANGE
0x0004u Change in Rotor or Slider position of atleast one
rotor or slider
TOUCH_CHANNEL_REF_CHANGE 0x0008u Change in Reference value of atleast one Touch
channel
TOUCH_BURST_AGAIN 0x0008u Indicates that reburst is required to resolve Filtering
or Calibration state
TOUCH_RESOLVE_CAL 0x0200u Indicates that reburst is needed to resolve
Calibration
TOUCH_RESOLVE_FILTERIN 0x0200u Indicates that reburst is needed to resolve Filtering
TOUCH_RESOLVE_DI 0x0800u Indicates that reburst is needed to resolve Detect
Integration
TOUCH_RESOLVE_POS_RECAL 0x1000u Indicates that reburst is needed to resolve
Recalibration
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
51
Macro Bitfield Comment
TOUCH_CC_CALIB_ERROR 0x2000u Indicates that CC calibration failed on at least one
channel
TOUCH_AUTO_OS_IN_PROGRES S 0x4000u Indicates that Auto OS in progress to get stable
channel signal
The acquisition status flags can be monitored within the measure complete callback as shown.
void touch_mutlcap_measure_complete_callback(void)
{
if ((p_mutlcap_measure_data->acq_status & TOUCH_BURST_AGAIN))
{
//Denotes acquisition is incomplete.
}
if ((p_mutlcap_measure_data->acq_status & TOUCH_RESOLVE_CAL))
{
//Denotes sensor calibration is on-going.
}
if (!(p_mutlcap_measure_data->acq_status & TOUCH_BURST_AGAIN))
{
//Denotes acquisition is completed.
/* Set the Mutual Cap measurement done flag. */
p_mutlcap_measure_data->measurement_done_touch = 1u;
}
}
Continuous Measurement Post Processing Mode
The sensor data post-processing mode for QTouch library can be selected using the
DEF_xxxxCAP_TOUCH_POSTPROCESS_MODE configuration item available as part of touch.h file.
When TOUCH_LIBRARY_DRIVEN mode is selected, the library self-initiates repeated touch
measurements to resolve touch press, release and calibration. This mode is suited for best response
time.
When TOUCH_APPLN_DRIVEN mode is selected, the library does not initiate repeated touch
measurement to resolve touch press, release and calibration. This mode suits deterministic PTC interrupt
execution time for applications requiring stringent CPU time requirements. As repeated touch
measurements are delayed due to other critical application code being executed. This mode can
potentially affect the touch response time.
In order to improve the response time with the TOUCH_APPLN_DRIVEN mode, the following condition
should be applied to initiate sensor measurement, so as to cater for additional measurements without any
delay. The same condition can also be applied to other application scenario such as sleep to check for
pending acquisitions to be completed before the system can go to sleep.
if ((touch_time.time_to_measure_touch == 1u)||(p_mutlcap_measure_data->acq_status &
TOUCH_BURST_AGAIN))
{
/* Start a touch sensors measurement process periodically, or if there is a pending
measurement. */
touch_ret =
touch_mutlcap_sensors_measure(touch_time.current_time_ms,NORMAL_ACQ_MODE,touch_mutlcap_meas
ure_complete_callback);
}
5.9. Touch Library API Error
The following table provides the touch library API error code information. The API error code type is
touch_ret_t enum.
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
52
ErrorCode Enumeration Comment
TOUCH_SUCCESS Successful completion of operation
TOUCH_ACQ_INCOMPLETE Touch Library is busy with pending previous touch
measurement
TOUCH_INVALID_INPUT_PARAM Invalid input parameter
TOUCH_INVALID_LIB_STATE Operation not allowed in the current Touch Library state
TOUCH_INVALID_SELFCAP_CONFIG_PARAM Invalid self-capacitance configuration input parameter
TOUCH_INVALID_MUTLCAP_CONFIG_PARAM Invalid mutual capacitance configuration input
parameter
TOUCH_INVALID_RECAL_THRESHOLD Invalid Recalibration threshold input value
TOUCH_INVALID_CHANNEL_NUM Channel number parameter exceeded total number of
channels configured
TOUCH_INVALID_SENSOR_TYPE Invalid sensor type. Sensor type can not be
SENSOR_TYPE_UNASSIGNED
TOUCH_INVALID_SENSOR_ID Invalid sensor number parameter
TOUCH_INVALID_RS_NUM Number of Rotor/Sliders set as 0, when trying to
configure a rotor/slider
The application error codes in touch projects can be enabled or disabled using a macro
DEF_TOUCH_APP_ERR_HANDLER. By default, the value of macro DEF_TOUCH_APP_ERR_HANDLER is
set to 0 in order to disable the application error handler. To enable the application error handler, set the
macro DEF_TOUCH_APP_ERR_HANDLER as 1. When it is enabled, while(1) is used to trap errors.
Refer Application Error Code (tag_touch_app_err_t) for further information.
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
53
6. Tuning for Noise Performance
The PTC has been designed with great care making it easy to design a capacitive touch solution, while at
the same time maintaining high quality of touch and performance. Nevertheless in any touch sensing
application, the system designer must consider how electrical interference in the target environment may
affect the performance of the sensors.
Touch sensors with insufficient tuning can show failures in tests of either radiated or conducted noise,
which can occur in the environment or power domain of the appliance or may be generated by the
appliance itself during normal operation. In many applications there are quality standards which must be
met where EMC performance criteria are clearly defined. However meeting the standards cannot be
considered as proof that the system will never show EMC problems, as the standards include only the
most commonly occurring types and sources of noise.
Noise immunity comes at a cost of increased touch response time and power consumption. The system
designer must carry out proper tuning of the touch sensors in order to ensure least power consumption.
The PTC QTouch library has anumber of user configurable features which can be tuned to give the best
balance between touch response time, noise immunity and power consumption.
6.1. Noise Sources
Noise sources that affect touch sensor performance can be classified as follows.
Self-generated
• Motors
• Piezo buzzers
• PWM controls Radiated
• Fluorescent lamp
• Radio transmission
• Inductive cook top Conducted
• Power supply / charger
• Mains supply
Applicable EMC standards
• Conducted Immunity EN61000-4-6
6.2. Noise Counter Measures
The effects of noise are highly dependent on the amplitude of the noise signal induced or injected onto
the sensors, and the frequency profile of that noise signal.
Generally, this noise can be classified as -
• Broadband noise
• Narrow band noise
6.2.1. Broadband Noise Counter Measures
Broadband noise refers to noise signals whose frequency components are not harmonically related to the
capacitance measurement acquisition frequencies of the PTC.
Provided that the maximum and minimum voltage levels of the acquisition signal combined with noise
signals are within the input range of the PTC and a sufficiently large number of samples are taken,
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
54
broadband noise interference can be averaged out by setting a high value of Filter level
(DEF_MUTLCAP_FILTER_LEVEL_PER_NODE, DEF_SELFCAP_FILTER_LEVEL_PER_NODE) and Auto
oversample (DEF_MUTLCAP_AUTO_OS_PER_NODE, DEF_SELFCAP_AUTO_OS_PER_NODE) settings.
If the noise amplitude is excessive, then PTC components experience saturation of measurement. In this
case the acquisition signals combined with the noise signals are outside the input range of the PTC,
which results in clipping of the measurements.
Often the clipping is not observable in the resolved measurement, as it occurs only on a portion of the
measurement samples, but the presence of clipped samples prevents effective averaging of the sample
points.
In this case, averaging of samples will not result in a noise-free measurement even with large rates of
oversampling. The resolved signal will show a shift from its correct level due to asymmetry of signal
clipping.
Configuration Parameter Setting
DEF_MUTLCAP_FILTER_LEVEL_PER_NODE,
DEF_SELFCAP_FILTER_LEVEL_PER_NODE
FILTER_LEVEL_64
DEF_MUTLCAP_AUTO_OS_PER_NODE, DEF_SELFCAP_AUTO_OS_PER_NODE AUTO_OS_DISABLE
DEF_MUTLCAP_FREQ_MODE, DEF_SELFCAP_FREQ_MODE FREQ_MODE_NONE
DEF_MUTLCAP_CLK_PRESCALE_PER_NODE,
DEF_SELFCAP_CLK_PRESCALE_PER_NODE
PRSC_DIV_SEL_1
DEF_MUTLCAP_SENSE_RESISTOR_PER_NODE,
DEF_SELFCAP_SENSE_RESISTOR_PER_NODE
RSEL_VAL_100
Auto-tune input to touch_mutlcap_sensors_calibrate(),
touch_selfcap_sensors_calibrate API
AUTO_TUNE_PRSC
STEP 1: PREVENT CLIPPING
This requires the implementation of a hardware low pass filter in order to reduce the scale of the noise
combined with acquisition signal. The sensor capacitance is combined with a series resistor on the Y
(Sense) line, either the PTC internal resistor or externally mounted on the PCB. The external series
resistor should be mounted between the Y line of the device to the Sensor, closest to the device pin.
Note: Always use an external series resistor for self-capacitance applications in order to prevent
clipping. The internal series resistor of the PTC is limited to 100K. Depending on the noise levels, external
series resistors up to1 megaohms can be evaluated.
STEP 2: CHARGE TRANSFER TEST
As an effect of adding a series resistor to form a low pass filter, the time constant for charging the sensors
is increased. It is essential to ensure that the sensor capacitance is fully charged and discharged during
each measurement sampling.
Insufficient charging can be observed as a reduced touch delta or it may be seen on an oscilloscope by
connecting to the sense electrode.
However, this problem may not be apparent in the touch sensor operation; the application may behave
perfectly well even in the presence of low-level noise, but show much worse performance during noise
tests with the addition of the resistor compared to a configuration which excludes the resistor.
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
55
Charge transfer though Auto tuning setting:
The QTouch library Auto tune setting provides a mechanism which carries out a charge transfer test on
each enabled key and sets the prescalar to the fastest available setting ensuring full charge transfer.
The following combination of setting should be used.
• DEF_MUTLCAP_SENSE_RESISTOR_PER_NODE and
DEF_SELFCAP_SENSE_RESISTOR_PER_NODE should be set to RSEL_VAL_100.
• Auto tune pre-scaler AUTO_TUNE_PRSC should be provided as input parameter to
touch_mutlcap_sensors_calibrate( AUTO_TUNE_PRSC )and
touch_mutlcap_sensors_calibrate(AUTO_TUNE_PRSC)
Testing for Charge transfer by Manual tuning:
• If the AUTO_TUNE_NONE setting is provided as an input to the
touch_mutlcap_sensors_calibrate(AUTO_TUNE_NONE ) and
touch_mutlcap_sensors_calibrate (AUTO_TUNE_NONE) calibration API, then the PTC
uses the user defined settings of the PTC Clock pre-scaler ( DEF_MUTLCAP_CLK_PRESCALE,
DEF_SELFCAP_CLK_PRESCALE_PER_NODE) and internal series resistor
(DEF_MUTLCAP_SENSE_RESISTOR_PER_NODE,
DEF_SELFCAP_SENSE_RESISTOR_PER_NODE).
• Reference measurement: An acquisition measurement (Signal value) is taken with the prescalar set
to maximum, i.e. PRSC_DIV_SEL_8
Test measurement: A second measurement (Signal value) is taken with reduced prescalar:
PRSC_DIV_SEL_4
If the difference between the two measurements is less than ~3% (1/32) of the first value, the conclusion
is that fullcharge transfer is achieved with PRSC_DIV_SEL_4.
This measurement is repeated for PRSC_DIV_SEL_2 and PRSC_DIV_SEL_1 to find the fastest PTC
operating speed for which full charge transfer is achieved.
STEP 3: ADJUST OVERSAMPLING
Once clipping is prevented by hardware filtering and full charge transfer is ensured the next step is to find
the best settings for Filter level ( DEF_MUTLCAP_FILTER_LEVEL_PER_NODE ,
DEF_SELFCAP_FILTER_LEVEL_PER_NODE ) and Auto over samples
(DEF_MUTLCAP_AUTO_OS_PER_NODE , DEF_SELFCAP_AUTO_OS_PER_NODE).
Auto over samples feature provides the advantage that additional samples are only taken on a sensor
which has showna significant change. In the absence of such a change, the measurement cycle can be
much shorter compared to applying ( * AUTO_OS) as the oversampling rate on every measurement.
Care should be taken when using AUTO_OS to ensure that it does not occur too frequently.
The measurement time for FILTER_LEVEL samples can be represented as:
A+ (B * FILTER_LEVEL)
Where A is the total time for PTC configuration and post-processing, and B is the oversampling period
(the per sample measurement time)
When AUTO_OS is applied, this time is increased to:
A + (B * FILTER_LEVEL*( 1 + AUTO_OS ))
FILTER_LEVEL should be sufficiently large to ensure that AUTO_OS is only applied during the worstcase
noise circumstances.
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
56
6.2.2. Narrowband Noise Counter Measures
If the noise includes a frequency component which is related to the PTC capacitance measurement
acquisition frequency, then no amount of oversampling will average out the noise effects. Any batch of
measurement samples taken with the same sampling frequency will result in a measurement offset. The
actual offset resulting from each measurement depends on the relative phase of the noise component
and the sampling frequency.
This effect is illustrated in the following diagram, where the noise is represented by a sine wave.
STEP 4: SELECT FREQUENCY MODE
Note: Step1, Step2 and Step3 provided in the previous section should be used in combination with this
step in a system which has both broadband noise and narrow band noise. Default settings provided
before STEP1 should be used as a starting point before starting noise tuning.
With FREQUENCY_MODE_NONE, a single acquisition frequency is used and samples are taken at the
fastest rate possible with the given pre-scalar setting. This gives the best response time, and with
sufficient oversampling excellent noise immunity at all noise frequencies which are not related to the
sampling frequency.
However in the case where the noise is at (or close to) a frequency which is harmonically related to the
sampling frequency then the noise issue becomes severe, as illustrated above.
This is particularly important in applications where a frequency sweep test is required, such as
EN61000-4-6.
FREQUENCY_MODE_SPREAD applies a modification to the sampling rate, such that the period between
successivesamples is modified in a saw-tooth fashion to apply a wider spectrum to the sampling
frequency. The sampling frequency F0 is thus spread across the range (F0/2, F0). With relatively low
noise amplitude, this can be effective atimproving performance with minimal cost in response time.
FREQUENCY_MODE_HOP utilizes 3 base frequencies and a median filter to avoid using measurements
taken at anaffected frequency. The frequencies should be selected to minimize the set of crossover
harmonics within the problemfrequency band.
Each of the 3 frequencies is used in sequence for each measurement cycle.i.e.
• Cycle 1: All sensors measured with Frequency 0
• Cycle 2: All sensors measured with Frequency 1
• Cycle 3: All sensors measured with Frequency 2
• Cycle 4: All sensors measured with Frequency 0
• Cycle 5: All sensors measured with Frequency 1
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
57
If Frequency 0 is related to the noise frequency, then the measurements taken with F0 will show high
variation. Using a median filter, this ensures that the outlying measurements will be rejected.
In some applications, self-generated noise may be present which affects one or more of the default HOP
frequencies. Insuch a case, the HOP frequencies should be changed to avoid this frequency.
Some noise frequencies can occur which are close to harmonics of two of the HOP frequencies, in which
case thesystem must be tuned with higher settings of FILTER_LEVEL or AUTO_OS to provide enough
samples to average the noise out of the measurement.
Determining PTC Acquisition Frequency
The PTC acquisition frequency is given by the following formula,
PTC Acquisition Frequency = (1/ PTC Acquisition Time)
The PTC acquisition time is given by the following formula,
PTC Acquisition Time = (Cycles per Acquisition + Hop Freq) * PTC IO Clock Period
Where, Cycles per Acquisition = Number of PTC clock cycles required for each acquisition. This is a fixed
value of 15. Hop Freq = PTC acquisition frequency delay setting
This parameter is represented in the touch.h file by the symbols DEF_MUTLCAP_HOP_FREQS and
DEF_SELFCAP_HOP_FREQS.
The PTC acquisition frequency is dependent on the Generic clock input to PTC and PTC clock pre- scaler
setting. This delay setting inserts n PTC clock cycles between consecutive measurements on a given
sensor, thereby changing the PTC acquisition frequency.
FREQ_HOP_SEL_1 setting inserts 0 PTC clock cycles between consecutive measurements.
FREQ_HOP_SEL_16 setting inserts 15 PTC clock cycles.
Hence, higher delay setting will increase the total time taken for capacitance measurement on a given
sensor as compared to a lower delay setting.A desired setting can be used to avoid noise around the
same frequency as the acquisition frequency.
Range: FREQ_HOP_SEL_1 to FREQ_HOP_SEL_16
Three frequency hop delay settings need to be specified when assigning values to this parameter.
Duration of each PTC clock period is given by the following formula,
Where,
CLKPTC = Generic clock input to the PTC
Refer touch_configure_ptc_clock() API in touch.c file for clock configuration.
Prescaler = PTC clock prescaler setting
This parameter is represented in the touch.h file by the symbols
DEF_MUTLCAP_CLK_PRESCALE_PER_NODE and DEF_SELFCAP_CLK_PRESCALE_PER_NODE.
Example: If Generic clock input to PTC = 4MHz, then:
• PRSC_DIV_SEL_1 sets PTC Clock to 4MHz
• PRSC_DIV_SEL_2 sets PTC Clock to 2MHz
• PRSC_DIV_SEL_4 sets PTC Clock to 1MHz
• PRSC_DIV_SEL_8 sets PTC Clock to 500KHz
Example:
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
58
When CLKPTC = 4MHz, Prescaler = PRSC_DIV_SEL_1, the PTC Acquisition Frequencies obtained are
as follows,
Hop Freq PTC Acquisition Frequency(kHz)
FREQ_HOP_SEL_1 66.67
FREQ_HOP_SEL_2 62.50
FREQ_HOP_SEL_3 58.82
FREQ_HOP_SEL_4 55.56
FREQ_HOP_SEL_5 52.63
FREQ_HOP_SEL_6 50.00
FREQ_HOP_SEL_7 47.62
FREQ_HOP_SEL_8 45.45
FREQ_HOP_SEL_9 43.48
FREQ_HOP_SEL_10 41.67
FREQ_HOP_SEL_11 40.00
FREQ_HOP_SEL_12 38.46
FREQ_HOP_SEL_13 37.04
FREQ_HOP_SEL_14 35.71
FREQ_HOP_SEL_15 34.48
FREQ_HOP_SEL_16 33.33
Note: The acquisition frequencies may vary based on the tolerance of the clock source.
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
59
7. Application Design
7.1. Touch Library and Associated Files
The table below provides the mandatory files required to use the QTouch library. In order to add QTouch
functionality into an existing user example project, these files and associated library based on the
compiler should be added to the user project.
Table 7-1. Touch Library Files
File Description
touch_api_ptc.h QTouch Library API header file, contains API and Data
structure used to interface with the library
touch.h QTouch library configuration header file
touch.c A helper file to demonstrate QTouch library initialization and
sensor configuration
libsamxxx_qtouch_iar.a or
libsamxxx_qtouch_gcc.a
QTouch library compiled for IAR or GCC compiler that supports
both self-capacitance and mutual capacitance sensors.
7.2. Code and Data Memory Considerations
The table below captures the typical code and data memory required for QTouch library. The typical
memory requirements provided in the table are arrived considering only Regular API usage in the
application. Usage of Helper API would consume additional code memory.
Each measurement method requires additional data memory from the application for storing the signals,
references, sensor configuration information, and touch status. This data memory is provided by the
application as 'data block' array. The size of this data block depends on the number of sensors
configured. The PRIV_xx_DATA_BLK_SIZE macro in touch_api_ptc.h calculates the size of this
data memory block.
Table 7-2. Mutual Capacitance Method
Series Code
Memory
Keys Only
Data
Memory
Keys Only
Code
Memory
Keys with
Rotor or
Slider
Data
Memory
Keys with
Rotor or
Slider
libsamd1x-qtouch-gcc.a 9602 845 11114 861
libsamd1x-qtouch-iar.a 9005 497 10377 513
libsamd2x-qtouch-gcc.a 9222 841 10734 857
libsamd2x-qtouch-iar.a 8881 497 10254 513
libsaml21-qtouch-gcc.a 9282 841 10794 857
libsaml21-qtouch-iar.a 9744 497 11115 513
libsamda1-qtouch-gcc.a 9222 841 10734 857
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
60
Series Code
Memory
Keys Only
Data
Memory
Keys Only
Code
Memory
Keys with
Rotor or
Slider
Data
Memory
Keys with
Rotor or
Slider
libsamda1-qtouch-iar.a 8881 497 10254 513
libsamc2x-qtouch-gcc.a 9752 841 11264 857
libsamc2x-qtouch-iar.a 9209 501 10567 517
libsamr21-qtouch-gcc.a 9246 841 10758 857
libsamr21-qtouch-iar.a 8905 497 10277 513
libsaml22-qtouch-gcc.a 9886 841 11078 857
libsaml22-qtouch-iar.a 9509 501 10981 517
libatmega328pb_qtouch_gcc.a 13338 503 15760 532
libMega328PB_qtouch.r90 10761 578 12391 607
libatmega324pb_qtouch_gcc.a 14082 482 16520 631
atmega324pb_qtouch_iar.r90 10646 441 12379 562
In case of ATmega328PB, for a single touch channel (mutual capacitance mode) without noise, moisture,
auto-tune and qdebug features, RAM usage is 503 bytes. RAM usage gets increased by 36 bytes for
each additional channel.
Table 7-3. Self-capacitance Method
Series Code
Memory
Keys Only
Data
Memory
Keys Only
Code
Memory
Keys with
Rotor or
Slider
Data
Memory
Keys with
Rotor or
Slider
libsamd1x-qtouch-gcc.a 9576 841 10884 849
libsamd1x-qtouch-iar.a 8952 497 10216 505
libsamd2x-qtouch-gcc.a 9198 845 10506 845
libsamd2x-qtouch-iar.a 8841 497 10101 505
libsam121-qtouch-gcc.a 9258 841 10566 845
libsaml21-qtouch-iar.a 9806 497 11070 505
libsamda1-qtouch-gcc.a 9198 845 10506 845
libsamda1-qtouch-iar.a 8841 497 10101 505
libsamc2x-qtouch-gcc.a 9716 841 11024 845
libsamc2x-qtouch-iar.a 9148 501 10400 509
libsamr21-qtouch-gcc.a 9542 841 10850 845
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
61
Series Code
Memory
Keys Only
Data
Memory
Keys Only
Code
Memory
Keys with
Rotor or
Slider
Data
Memory
Keys with
Rotor or
Slider
libsamr21-qtouch-iar.a 8851 497 10115 505
libsaml22-qtouch-gcc.a 9530 841 11158 845
libsaml22-qtouch-iar.a 9410 501 10733 509
libatmega328pb_qtouch_gcc.a 13274 500 15260 519
libMega328PB_qtouch.r90 10705 594 12041 613
libatmega324pb_qtouch_gcc.a 14026 478 16024 593
libMega328PB_qtouch.r90 10596 437 12329 558
In case of ATmega328PB, for a single touch channel (self-capacitance mode) without noise, moisture,
auto-tune and qdebug features, RAM usage is 500 bytes. RAM usage gets increased by 32 bytes for
each additional channel.
Note:
1. The total number of sensors supported by a specific device variant is limited by the number of XYlines
as well as code, data, and stack memory requirements.
2. To save the memory utilized for code and data, new lib-nano C library has been used for GCC
example projects.
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
62
8. Example Applications
8.1. Atmel Board Example Projects
The GCC Xplained Pro example projects can be accessed through File>New Example Project menu
option in Atmel Studio.
The IAR Xplained Pro example projects can be accessed through Atmel QTouch Library PTC Partpack.
The following example projects are available for Xplained Pro kits:
• SAM D20 Xplained Pro and QT1 Xplained Pro Mutual Capacitance example application
• SAM D20 Xplained Pro and QT1 Xplained Pro Self Capacitance example application
• SAM D21 Xplained Pro and QT1 Xplained Pro Mutual Capacitance example application
• SAM D21 Xplained Pro and QT1 Xplained Pro Self Capacitance example application
• SAM D20 Xplained Pro and QT1 Xplained Pro Mutual Capacitance example application with LumpLow
Power configuration
• SAM D20 Xplained Pro and QT1 Xplained Pro Self Capacitance example application with LumpLow
Power configuration
• SAM D11 Xplained Pro Self Capacitance example application
• SAM D10 Xplained Mini Self Capacitance example application
• SAM D20 QTouch Robustness Demo Moisture Example Application (self + mutual)
• SAM C20 QTouch Robustness Demo Moisture Example Application
• SAM D20 Xplained Pro and QT3 Xplained Pro Mutual Capacitance example application with LumpLow
Power configuration
• SAM L21 Xplained Pro and QT3 Xplained Pro Mutual Capacitance example application with LumpLow
Power configuration
• SAM DA1 Xplained Pro and QT4 Xplained Pro Self Capacitance example application
• SAM C21 Xplained Pro and QT1 Xplained Pro Mutual Capacitance example application
• SAM C21 Xplained Pro and QT1 Xplained Pro Self Capacitance example application
• SAM C21 Xplained Pro Self Capacitance example application(on-board sensor)
• SAM C21 Xplained Pro and QT5 Xplained Pro Mutual Capacitance example application
• SAM L22 Xplained Pro and Touch Segment LCD Xplained Pro Mutual Capacitance example
application
• ATmega328PB Xplained Mini Self Capacitance example application
• ATmega324PB Xplained Pro and QT5 Xplained Pro Mutual Capacitance example application
Note: For SAM L22, it is recommended to set the PTC Clock to 8MHz.
Clock Configuration Changes in Projects:
• For SAM C20/C21 RevB devices, DPLL is used as the main clock and OSC32K is used as
reference clock for the DPLL clock source. For SAM C20/C21 RevC devices, OSC48MHz is used
as the main clock. This is demonstrated in the example projects by using the same project for both
SAM C20/C21 RevB and SAM C20/C21 RevC devices.
• The example projects which have DFLL as main clock source use scaled OSC8MHz/OSC16MHz
clock as the reference input clock.
• SAM L22 example project configures DFLL for 16MHZ (performance level - PL2) and utilizes it as
the main clock. This clock setting offers high performance.
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
63
• SAM L22 low power user board project configures DFLL for 8MHZ (performance level - PL0) and
utilizes it as the main clock. This clock setting offers low power consumption.
• SAM L21/L22 low power example projects are configured in PL0 (Low power oriented mode) with
Buck regulator as the main regulator in standby sleep mode. This is the best suitable configuration
to achieve low power numbers.
The example projects make use of Xplained Pro boards and the extension kits for showcasing touch.
Those extension kits are explained in the following sections.
QT1 Xplained Pro kit:
The QT1 Xplained Pro self-capacitance and mutual capacitance extension boards are supported by SAM
D20, SAM D21, SAM DA1, SAM C21, and SAM L22 Xplained Pro Evaluation kits.
Figure 8-1. QT1 Xplained Pro Mutual Capacitance and Self-capacitance
Note: SAM C21 Xplained Pro can operate at 3.3V and 5V Vcc, while the QT1 Xplained Pro can operate
at a maximum voltage of 3.6V. Please make sure to put the Vcc selection header on the SAM C21
Xplained Pro in the 3.3V position.
The QT1 Xplained Pro boards demonstrate the following combinations of buttons, slider, and wheels.
• 2 buttons + 2 yellow LED
• 1 slider + 8 yellow LED
• 1 wheel + 1 RGB LED
QT3 Xplained Pro kit:
The QT3 Xplained Pro extension board has 12 mutual capacitance buttons on it and it is supported by
SAM D20, SAM D21, SAM DA1, SAM L21, SAM L22 and SAM C21 Xplained Pro Evaluation kits.
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
64
Figure 8-2. QT3 Xplained Pro
QT4 Xplained Pro kit:
The QT4 Xplained Pro boards demonstrate the following arrangement.
• Two self-capacitance buttons
• One unshielded proximity sensor
• One proximity sensor with driven shield with external op-amp driver
• One LED indicator for each self-capacitive button
• One LED indicator for each proximity sensor
Figure 8-3. QT4 Xplained Pro
QT5 Xplained Pro kit:
The QT5 Xplained Pro board demonstrates the following arrangement.
• One 4-channel (4X x 1Y) mutual capacitance curved slider
• Two mutual capacitance buttons
• 16 LEDs arranged as two 7-segment digits separated with a colon
• IS31FL3728 I2C LED matrix controller from ISSI
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
65
Figure 8-4. QT5 Xplained Pro
8.2. User Board Example Projects
Atmel Studio QTouch Composer can be used to create GCC projects based on the sensor and pin
configuration defined by the requirements of a user board. The generated example projects also allow for
QDebug data streaming to QTouch Analyzer.
The User board example project can be generated by accessing the QTouch Composer using the
following menu options in the Atmel Studio.
File > New Project > GCC C QTouch Executable Project > Create QTouch Library Project
The QTouch Project Builder wizard appears as shown in the screenshot. Selection of sensors, devices,
pins, debug interface and tuning of parameters can be done according to user preferences and project
can be generated. The figure shows one of the user board generated projects.
Figure 8-5. QTouch Project Builder
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
66
Figure 8-6. User Board Example Project
8.3. Using Atmel Software Framework (ASF) with the Example Projects
The example projects are based on Atmel Software Framework (ASF). For more information on ASF refer
to Atmel Software Framework User Guide http://www.atmel.com/.
The Atmel® Software Framework (ASF) is a MCU software library providing a large collection of
embedded software for Atmel flash MCUs: mega AVR, AVR XMEGA, AVR UC3 and SAM devices.
• It simplifies the usage of microcontrollers, providing an abstraction to the hardware and high- value
middleware
• ASF is designed to be used for evaluation, prototyping, design and production phases
• ASF is integrated in the Atmel Studio IDE with a graphical user interface or available as standalone
for GCC, IAR compilers
• ASF can be downloaded for free
8.4. Using Xplained Pro Kit to Program User Board
The SAM D20 Xplained Pro features a Cortex® Debug Connector (10-pin) for programming and
debugging an external target. The connector is limited to the SWD interface and is intended for in-system
programming and debugging of SAM D20 devices in the final product developed by the users. For more
information refer SAM D20 Xplained Pro User Guide (www.atmel.com).
8.5. Using QDebug Touch Data Debug Communication Interface
When using IAR and GCC example projects, QDebug touch data debug communication interface can be
enabled. This allows the communication between the touch device and QTouch Analyzer.
To enable or disable QDebug, configure DEF_TOUCH_QDEBUG_ENABLE in the touch.h file.
When QDebug is enabled and touch debug data is being updated in the QTouch Analyzer, touch
response time will be slower due to the debug communication data transfer which increases the delay in
the response time.
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
67
After tuning the touch sensors using QTouch Analyzer, disable the QDebug for optimized touch
performance.
Figure 8-7. Atmel DGI Interface for QDebug Data
Figure 8-8. QTouch Analyzer view
8.6. Using Xplained Pro Kit for QDebug Data Streaming from User Board
SAM D20 Xplained Pro contains Embedded Debugger (EDBG) that features an Atmel Data Gateway
Interface (DGI) over SPI and TWI. The DGI can be used to transmit a variety of data from the Xplained
Pro kit to the host PC. This arrangement can be used to send QDebug data from a user board to Atmel
Studio QTouch Analyzer for touch sensor data analysis and tuning.
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
68
Figure 8-9. Using Xplained Pro for Data Streaming from User Board
The example project generated using QTouch composer makes use of SPI for data transfer. To stream
QDebug data from user board, a relay firmware should be flashed onto the SAM D20/D21 microcontroller
on the Xplained Pro kit. After connecting the SAM D20/D21 Xplained Pro to the PC, the device name
appears in the connected kits of QTouch Start Page. Right click the device name and choose Enable
User Board Analysis to flash the relay firmware.
Figure 8-10. Flash Relay Firmware
The following table indicates the SPI connection between SAM D20 Xplained Pro Kit and User Board:
Table 8-1. SPI Connection Information
SAMD20 Xplained Pro Extension header EXT3 UserBoard Pin
Pin on EXT3 Function
16 SPIMOSI (PB22) MOSI
17 SPIMISO (PB16) MISO
18 SPISCK(PB23) SCK
- SS-Connect to GND
19 GND GND
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
69
8.7. Using Atmel ICE for QDebug Data Streaming from User Board
Atmel ICE can be used to stream data from the user board.
Refer the following table and connect the mini squid cable from AVR header of Atmel ICE to user board.
Atmel-ICE AVR port pins Target pins Mini-squid pin
Pin 1 (TCK) SCK 1
Pin 2 (GND) GND 2
Pin 3 (TDO) MISO 3
Pin 4 (VTG) VCC 4
Pin 5 (TMS) SS 5
Pin 6 (nSRST) - 6
Pin 7 (Not Connected) - 7
Pin 8 (nTRST) - 8
Pin 9 (TDI) MOSI 9
Pin 10 (GND) - 0
While creating the project using QTouch composer project builder wizard, the pins SCK, MISO, SS and
MOSI can be chosen from the debug interface setup pane as shown in the figure.
Figure 8-11. Debug Interface Setup Pane
When the connections are made correctly and debug interface setup is also done in the project, flash the
project in the user board. Data can be streamed and visualized via QTouch Analyzer.
Note: Atmel ICE would be listed in QTouch Analyzer as QDEBUG_DGI.
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
70
9. Known Issues
1. PTC in Self-capacitance Mode
The following errata is applicable for SAM D20 (Revision B)
Description:
The two lowest gain settings are not selectable and an attempt by the QTouch Library to set enable of
these may result in a higher sensitivity than optimal for the sensor. The PTC will not detect all
touches.This errata does not affect mutual capacitance mode which operates as specified.
Fix/workaround:
Use SAM D20 revision C or later for self-capacitance capacitive touch sensing.
2. Touch acquisition may fail and stop working
The following errata is applicable for QTouch Library versions up to 5.0.7. This issue has been fixed in
QTouch Library version 5.0.8 or later.
Description:
In QTouch applications, where either a single interrupt or a chain of nested non-PTC interrupts has
duration longer than the total touch measurement time, the touch acquisition may fail and stop working.
This issue occurs most likely in applications with few touch channels (2-3 channels) and a low level of
noise handling (filter level 16 or lower and no frequency hopping).
In an application with single touch channel and filter level 16, the total measurement time is ~350µs. The
total measurement time doubles for two touch channels, and triples for 3 touch channels. It increases up
to 10 times or 3.5ms with 10 touch channels.
Fix/workaround:
• Recommended workaround:
– Use QTouch Library version 5.0.8 or later.
• Other alternatives:
1. Always ensure that the duration of a single interrupt or a chain of nested non-PTC interrupts
does not exceed the total touch measurement time. (or)
2. Add a critical section by disabling interrupts for the touch_xxxxcap_sensors_measure()
function as shown in the following code snippet.
Disable_global_interrupt();
touch_ret = touch_xxxxcap_sensors_measure( touch_time.current_time_ms, NORMAL_ACQ_MODE,
touch_xxxxcap_measure_complete_callback);
Enable_global_interrupt();
The Interrupt Blocking Time while executing touch_xxxxcap_sensors_measure API for various CPU
frequencies are as follows.
CPU Frequency (in MHz) Interrupt Blocking Time ( in μs )
48 ~77
24 ~124
16 ~176
12 ~223
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
71
The interrupt blocking time varies based on the PTC_GCLK frequency, CPU frequency, and the library
version. The actual blocking time can be measured by toggling a GPIO pin before and after the
touch_xxxxcap_sensors_measure function.
When IAR compiler is used, utilize the system_interrupt_enable_global() and
system_interrupt_disable_global() functions to enable and disable the global interrupts,
respectively. In case of AVR, use cli() and sei() instructions to disable and enable the global
interrupts.
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
72
10. FAQ on PTC Qtouch
Table 10-1. Frequently Asked Questions
Query Answer
When can we change an
acquisition, sensor configuration or
global sensor parameter?
After changing an acquisition
parameter do we need to
recalibrate or reinitialize the
sensors and PTC?
Its best to call the helper APIs to update these parameter when
the measurement_done_touch flag (part of
touch_measure_data_t structure) is true, which means the
library is not in the middle of an (previously started) incomplete
acquisition. Changing Gain and Filter level settings can affect the
Signal value, so recalibration is mandatory by invoking the
touch_sensors_calibrate() API.
Can sensors be disabled and reenabled
run time?
For example, scan 2 sensors while
sleeping and then scan all sensors
when the system wakes up.
Yes, this is possible using the
touch_xxxcap_sensor_disable() and
touch_xxxcap_sensor_reenable() API.
There is a low amplitude pulse prior
to the 16 acquisition samples and a
large amplitude pulse after the 16
acquisition samples.
These pulses are part of setting up the sense line's initial
conditions.
Is Detect integration calculated
inside the PTC or by QTouch
library?
This is done by QTouch library.
When Auto Oversampling is
enabled how can one determine
touch timing?
The absolute maximum cycle, is the case that auto oversamples is
applied to all channels: (Normal acquisition time) x (1 + auto_os).
This can only happen with a poorly tuned system, as
FILTER_LEVEL should be sufficient to prevent AUTO_OS
happening except on a touched key under noisy conditions.
Can sensor signal lines (Y or X
lines) be used to drive LEDs, etc.,
when not being used for sensor
acquisitions?
No. This is not recommended
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
73
11. Appendix
11.1. Macros
11.1.1. Touch Library Acquisition Status Bit Fields
Keyword Type Description
TOUCH_NO_ACTIVITY 0x0000u No touch activity.
TOUCH_IN_DETECT 0x0001u Atleast one touch channel is in detect.
TOUCH_STATUS_CHANGE 0x0002u Change in touch status of at least one Touch
channel.
TOUCH_ROTOR_SLIDER_POS_CHANGE 0x0004u Change in the position of at least one rotor or slider.
TOUCH_CHANNEL_REF_CHANGE 0x0008u Changein the reference value of at least one touch
channel.
TOUCH_BURST_AGAIN 0x0100u Indicates that re-burst is required to resolve filtering
or calibration state.
TOUCH_RESOLVE_CAL 0X0200u Indicates that re-burst is required to resolve
calibration.
TOUCH_RESOLVE_FILTERIN 0x0400u Indicates that re-burst is required to resolve
calibration.
TOUCH_RESOLVE_DI 0x0800u Indicates that re-burst is needed to resolve Detect
Integration.
TOUCH_RESOLVE_POS_RECAL 0x1000u Indicates that re-burst is needed to resolve
recalibration.
TOUCH_CC_CALIB_ERROR 0X2000u Indicates that CC calibration failed on at least one
channel.
TOUCH_AUTO_OS_IN_PROGRESS 0X4000u Indicates that Auto-os in progress to get stable
channel signal.
11.1.2. Sensor State Configurations
GET_SENSOR_STATE (SENSOR_NUMBER)
To get the sensor state (whether detect or not) for parameter that corresponds to the sensor specified
using the SENSOR_NUMBER.
The macro returns either 0 or 1. If the bit value is 0, the sensor is not in detect. If the bit value is 1, the
sensor is in detect.
#define GET_XXXXCAP_SENSOR_STATE(SENSOR_NUMBER) p_xxxxcap_measure_data-
>p_sensor_states
[(SENSOR_NUMBER / 8)] & (1 << (SENSOR_NUMBER % 8))) >> (SENSOR_NUMBER %8)
GET_XXXXCAP_SENSOR_MOIS_STATUS (SNSR_NUM)
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
74
To get the moisture status of a particular sensor. The return value is 1 in case of sensor is affected by
moisture and returns 0 if sensor is affected by moisture.
#define GET_XXXXCAP_SENSOR_MOIS_STATUS(SNSR_NUM) ((p_xxxxcap_measure_data-
>p_sensor_mois_status
[(SNSR_NUM)/8] & (1<<((SNSR_NUM)%8))) >>(SNSR_NUM %8))
GET_XXXXCAP_MOIS_GRP_SUM_DELTA (GRP_ID)
To get the xxxxcap moisture group sum delta.
The return value is 32 bit integer indicating the sum delta of moisture group.
#define GET_XXXXCAP_MOIS_GRP_SUM_DELTA(GRP_ID)(mois_XXXX_grp_delta_arr[(GRP_ID)-1])
GET_XXXXCAP_MOIS_GRP_ADJ_DELTA (GRP_ID)
To get the xxxxcap moisture group Adjacent delta .The return value is 32 bit integer indicating the
adjacent delta of moisture group.
#define GET_MUTLCAP_MOIS_GRP_ADJ_DELTA(GRP_ID)(mois_mutl_grp_adj_delta_arr[(GRP_ID)-1])
GET_MOIS_XXXX_GLOB_LOCK_STATE
To get the moisture lock status of xxxxcap moisture groups. The return value is 1 if any moisture group is
in moisture global lockout and 0 if no moisture group is in moisture global lockout.
#define GET_MOIS_MUT_GLOB_LOCK_STATE(mois_lock_global_mutl)
GET_XXXXCAP_SENSOR_NOISE_STATUS (SENSOR_NUMBER)
To get the noise status of a particular sensor. The return value is 1 in case of sensor is noisy and returns
0 if sensor is not noisy.
#define GET_XXXXCAP_SENSOR_NOISE_STATUS (SENSOR_NUMBER)(p_xxxxcap_measure_data-
>p_sensor_noise_status
[(SENSOR_NUMBER / 8)] & (1 <<(SENSOR_NUMBER % 8))) >> (SENSOR_NUMBER % 8)
GET_ROTOR_SLIDER_POSITION (ROTOR_SLIDER_NUMBER)
To get the rotor angle or slider position. These values are valid only when the sensor state for
corresponding rotor or slider state is in detect.
ROTOR_SLIDER_NUMBER is the parameter for which the position is being obtained.
The macro returns rotor angle or sensor position.
#define
GET_XXXXCAP_ROTOR_SLIDER_POSITION(ROTOR_SLIDER_NUMBER)p_xxxxcap_measure_data-
>p_rotor_slider_values
[ROTOR_SLIDER_NUMBER]
DEF_TOUCH_MUTLCAP must be set to 1 in the application to enable the Mutual capacitance touch
acquisition method.
DEF_TOUCH_SELFCAP must be set to 1 in the application to enable the Self-capacitance touch
acquisition method.
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
75
11.2. Typedef
Field Unit Description
threshold_t uint8_t An unsigned 8-bit number setting a sensor detection
threshold.
sensor_id_t uint8_t Sensor number type.
touch_current_time_t uint16_t Current time type.
touch_delta_t int16_t Touch sensor delta value type.
touch_acq_status_t uint16_t Status of touch measurement.
mois_snsr_threshold_t int32_t Moisture threshold for individual sensor.
mois_system_threshold_t int32_t Moisture threshold for the entire system.
11.3. Enumeration
11.3.1. Gain Setting (tag_gain_t)
Gain per touch channel.
Gain is applied on a per-channel basis to allow a scaling-up of the touch sensitivity on contact.
Range: GAIN_1 (no scaling) to GAIN_32 (scale-up by32)
Data Fields
• GAIN_1
• GAIN_2
• GAIN_4
• GAIN_8
• GAIN_16
• GAIN_32
11.3.2. Filter Level Setting (tag_filter_level_t)
Touch library FILTER LEVEL setting.
The filter level setting controls the number of samples acquired to resolve each acquisition. A higher filter
level setting provides improved signal to noise ratio under noisy conditions, while increasing the total time
for measurement which results in increased power consumption. Refer filter_level_t in
touch_api_ptc.h
Range: FILTER_LEVEL_1 (one sample) to FILTER_LEVEL_64 (64 samples).
Data Fields
• FILTER_LEVEL_1
• FILTER_LEVEL_2
• FILTER_LEVEL_4
• FILTER_LEVEL_8
• FILTER_LEVEL_16
• FILTER_LEVEL_32
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
76
• FILTER_LEVEL_64
11.3.3. Auto Oversample Setting (tag_auto_os_t)
Auto oversample controls the automatic oversampling of sensor channels when unstable signals are
detected with the default setting of 'Filter level'. Enabling Auto oversample results in 'Filter level' x 'Auto
Oversample' number of samples taken on the corresponding sensor channel when an unstable signal is
observed. In a case where 'Filter level' is set to FILTER_LEVEL_4 and 'Auto Oversample' is set to
AUTO_OS_4, 4 oversamples are taken with stable signal values and 4+16 oversamples are taken when
unstable signal is detected.
Range: AUTO_OS_DISABLE (oversample disabled) to AUTO_OS_128 (128 oversamples).
Data Fields
• AUTO_OS_DISABLE
• AUTO_OS_2
• AUTO_OS_4
• AUTO_OS_8
• AUTO_OS_16
• AUTO_OS_32
• AUTO_OS_64
• AUTO_OS_128
11.3.4. Low Power Sensor Scan Rate (tag_lowpower_scan_int_t)
When the CPU returns to standby mode from active, the sensor configured as the low power sensor is
scanned at this interval. A high value for this parameter will reduce power consumption but increase
response time for a low power sensor.
Note: This enum is applicable only for ATmega devices.
Range: LOWPOWER_PER0_SCAN_3_P_9_MS to LOWPOWER_PER7_SCAN_250_MS
Data Fields
• LOWPOWER_PER0_SCAN_3_P_9_MS
• LOWPOWER_PER1_SCAN_7_P_8_MS
• LOWPOWER_PER2_SCAN_15_P_625_MS
• LOWPOWER_PER3_SCAN_31_P_25_MS
• LOWPOWER_PER4_SCAN_62_P_5_MS
• LOWPOWER_PER5_SCAN_125_MS
• LOWPOWER_PER6_SCAN_250_MS
11.3.5. Library Error Code (tag_touch_ret_t)
Touch Library error codes.
Data Fields
• TOUCH_SUCCESS Successful completion of touch operation.
• TOUCH_ACQ_INCOMPLETE Library is busy with pending previous touch measurement.
• TOUCH_INVALID_INPUT_PARAM Invalid input parameter.
• TOUCH_INVALID_LIB_STATE Operation not allowed in the current touch library state.
• TOUCH_INVALID_SELFCAP_CONFIG_PARAM Invalid self-capacitance configuration input
parameter.
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
77
• TOUCH_INVALID_MUTLCAP_CONFIG_PARAM Invalid mutual capacitance configuration input
parameter.
• TOUCH_INVALID_RECAL_THRESHOLD Invalid recalibration threshold input value.
• TOUCH_INVALID_CHANNEL_NUM Channel number parameter exceeded total number of channels
configured.
• TOUCH_INVALID_SENSOR_TYPE Invalid sensor type. Sensor type must NOT be
SENSOR_TYPE_UNASSIGNED.
• TOUCH_INVALID_SENSOR_ID Invalid sensor number parameter.
• TOUCH_INVALID_RS_NUM Number of rotor/sliders set as 0, while trying to configure a rotor/slider.
11.3.6. Application Error Code (tag_touch_app_err_t)
The application error codes are listed below.
Data Fields
• TOUCH_INIT_CONFIG_ERR The touch_xxxxcap_sensors_init is fed with an incompatible /
incomplete parameter.
• TOUCH_SENSOR_CONFIG_ERR The touch_xxxxcap_sensor_config is fed with an
incompatible parameter / Touch Library state is not in TOUCH_STATE_INIT.
• TOUCH_INIT_CALIB_ERR The touch_xxxxcap_sensors_calibrate is fed with an invalid
parameter / Touch Library state is TOUCH_STATE_NULL/ TOUCH_STATE_BUSY.
• TOUCH_MEASURE_INCOMPLETE The touch_measure api has error due to an invalid input
param / it was on an invalid Touch Library state.
• TOUCH_MEASURE_CC_CAL_FAILED Hardware calibration error; check the hardware and ensure it
is proper. If the error persists, check the user manual for sensor design guidelines.
11.3.7. Touch Channel (tag_channel_t)
Sensor start and end channel type of a Sensor. Channel number starts with value 0.
Data Fields
CHANNEL_0 to CHANNEL_255
11.3.8. Touch Library State (tag_touch_lib_state_t)
Touch library state.
Data Fields
• TOUCH_STATE_NULL Touch library is un-initialized. All sensors are disabled.
• TOUCH_STATE_INIT Touch library has been initialized
• TOUCH_STATE_READY Touch library is ready to start a new capacitance measurement on enabled
sensors.
• TOUCH_STATE_CALIBRATE Touch library is performing calibration on all sensors.
• TOUCH_STATE_BUSY Touch library is busy with on-going capacitance measurement.
11.3.9. Sensor Type (tag_touch_lib_state_t)
Sensor types available.
Data Fields
• SENSOR_TYPE_UNASSIGNED Sensor is not configured yet
• SENSOR_TYPE_KEY Sensor type key
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
78
• SENSOR_TYPE_ROTOR Sensor type rotor
• SENSOR_TYPE_LUMP Sensor type lump
• SENSOR_TYPE_SLIDER Sensor type slider
• MAX_SENSOR_TYPE Max value of enum type for testing
11.3.10. Touch Sensing Type (tag_touch_acq_t)
Based on the two types of charge transfer technology, the capacitive touch sensing may be either mutual
capacitance sensing or self-capacitance sensing.
Data Fields
• TOUCH_MUTUAL Mutual capacitance sensing
• TOUCH_SELF Self-capacitance sensing
• MAX_TOUCH_ACQ Max value of enum
11.3.11. Touch Library Acquisition Mode (tag_touch_acq_mode_t)
Touch library acquisition mode.
Data Fields
RAW_ACQ_MODE
When raw acquisition mode is used, the measure_complete_callback function is called immediately
once a fresh value of signals are available. In this mode, the Touch Library does not perform any post
processing. So, the references, sensor states or rotor/slider position values are not updated in this mode.
NORMAL_ACQ_MODE
When normal acquisition mode is used, the measure_complete_callback function is called only after
the Touch Library completes processing of the signal values obtained. The references, sensor states and
rotor/slider position values are updated in this mode.
11.3.12. Calibration Auto tune Setting (tag_auto_tune_type_t)
Touch library PTC prescaler clock and series resistor auto tuning setting
Data Fields
• AUTO_TUNE_NONE Auto tuning mode disabled. This mode uses the user defined PTC prescaler
and series resistor values.
• AUTO_TUNE_PRSC Auto tune PTC prescaler for best noise performance . This mode uses the user
defined series resistor value.
• AUTO_TUNE_RSEL Auto tune series resistor for least power consumption. This mode uses the user
defined PTC prescaler value.
11.3.13. PTC Acquisition Frequency Mode Setting (tag_freq_mode_sel_t)
The frequency mode setting option enables the PTC acquisition to be configured for the following modes.
• Frequency hopping and spread spectrum disabled.
• Frequency hopping enabled with median filter.
• Frequency spread spectrum enabled without median filter.
• Frequency spread spectrum enabled with median filter.
Range: FREQ_MODE_NONE (no frequency hopping & spread spectrum) to FREQ_MODE_SPREAD_MEDIAN
(spread spectrum with median filter)
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
79
Data Fields
• FREQ_MODE_NONE 0u
• FREQ_MODE_HOP 1u
• FREQ_MODE_SPREAD 2u
• FREQ_MODE_SPREAD_MEDIAN 3u
11.3.14. PTC Clock Pre-scaler Setting (tag_prsc_div_sel_t)
Refer touch_configure_ptc_clock() API in touch.c
Example:
If generic clock input to PTC = 4 MHz,
• PRSC_DIV_SEL_1 sets PTC Clock to 4 MHz.
• PRSC_DIV_SEL_2 sets PTC Clock to 2 MHz.
• PRSC_DIV_SEL_4 sets PTC Clock to 1 MHz.
• PRSC_DIV_SEL_8 sets PTC Clock to 500 kHz.
Data Fields
• PRSC_DIV_SEL_1
• PRSC_DIV_SEL_2
• PRSC_DIV_SEL_4
• PRSC_DIV_SEL_8
11.3.15. PTC Series Resistor Setting (tag_rsel_val_t)
For mutual capacitance mode, this series resistor is switched internally on the Y-pin. For self-capacitance
mode, the series resistor is switched internally on the sensor pin.
Example:
• RSEL_VAL_0 sets internal series resistor to 0 Ohms.
• RSEL_VAL_20 sets internal series resistor to 20 Kohms.
• RSEL_VAL_50 sets internal series resistor to 50 Kohms.
• RSEL_VAL_100 sets internal series resistor to 100 Kohms.
Data Fields
• RSEL_VAL_0
• RSEL_VAL_20
• RSEL_VAL_50
• RSEL_VAL_100
11.3.16. PTC Acquisition Frequency Delay Setting (tag_rsel_val_t)
The PTC acquisition frequency is dependent on the generic clock input to PTC and PTC clock prescaler
setting. This delay setting inserts n PTC clock cycles between consecutive measurements on a given
sensor, thereby changing the PTC acquisition frequency. FREQ_HOP_SEL_1 setting inserts 0 PTC clock
cycle between consecutive measurements. FREQ_HOP_SEL_16 setting inserts 15 PTC clock cycles.
Hence, higher delay setting will increase the total time required for capacitance measurement on a given
sensor as compared to a lower delay setting.
A desired setting avoids noise in the same frequency as the acquisition frequency.
Data Fields
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
80
• FREQ_HOP_SEL_1
• FREQ_HOP_SEL_2
• FREQ_HOP_SEL_3
• FREQ_HOP_SEL_4
• FREQ_HOP_SEL_5
• FREQ_HOP_SEL_6
• FREQ_HOP_SEL_7
• FREQ_HOP_SEL_8
• FREQ_HOP_SEL_9
• FREQ_HOP_SEL_10
• FREQ_HOP_SEL_11
• FREQ_HOP_SEL_12
• FREQ_HOP_SEL_13
• FREQ_HOP_SEL_14
• FREQ_HOP_SEL_15
• FREQ_HOP_SEL_16
11.3.17. AKS Group (tag_aks_group_t)
It provides information about the sensors that belong to specific AKS group. NO_AKS_GROUP indicates
that the sensor does not belong to any AKS group and cannot be suppressed. AKS_GROUP_x indicates
that the sensor belongs to the AKS group x.
Data Fields
• NO_AKS_GROUP
• AKS_GROUP_1
• AKS_GROUP_2
• AKS_GROUP_3
• AKS_GROUP_4
• AKS_GROUP_5
• AKS_GROUP_6
• AKS_GROUP_7
• MAX_AKS_GROUP Max value of enum type for testing.
11.3.18. Sensor Hysteresis Setting (tag_hysteresis_t)
A sensor detection hysteresis value. This is expressed as a percentage of the sensor detection threshold.
HYST_x = hysteresis value is x% of detection threshold value (rounded down).
Note: A minimum value of 2 is used.
Example: If detection threshold = 20,
• HYST_50 = 10 (50% of 20)
• HYST_25 = 5 (25% of 20)
• HYST_12_5 = 2 (12.5% of 20)
• HYST_6_25 = 2 (6.25% of 20 = 1, but value is hard limited to 2)
Data Fields
• HYST_50
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
81
• HYST_25
• HYST_12_5
• HYST_6_25
• MAX_HYST Max value of enum type for testing.
11.3.19. Sensor Recalibration Threshold (tag_recal_threshold_t)
This is expressed as a percentage of the sensor detection threshold. RECAL_x = recalibration threshold
is x% of detection threshold value (rounded down).
Note: A minimum value of 4 is used.
Example: If detection threshold = 40,
• RECAL_100 = 40 (100% of 40)
• RECAL_50 = 20 (50% of 40)
• RECAL_25 = 10 (25% of 40)
• RECAL_12_5 = 5 (12.5% of 40)
• RECAL_6_25 = 4 (6.25% of 40 = 2, but value is hard limited to 4)
Data Fields
• RECAL_100
• RECAL_50
• RECAL_25
• RECAL_12_5
• RECAL_6_25
• MAX_RECAL Max value of enum type for testing.
11.3.20. Rotor Slider Resolution (tag_resolution_t)
For rotors and sliders, the resolution of the reported angle or position.
• RES_x_BIT = rotor/slider reports x-bit values.
Example: If slider resolution is RES_7_BIT, then reported positions are in the range 0..127.
Data Fields
• RES_1_BIT
• RES_2_BIT
• RES_3_BIT
• RES_4_BIT
• RES_5_BIT
• RES_6_BIT
• RES_7_BIT
• RES_8_BIT
• MAX_RES Max value of enum type for testing.
11.3.21. PTC Sensor Noise Lockout setting (nm_sensor_lockout_t)
The sensor lockout setting option allows the system to be configured in the following modes.
• SINGLE_SENSOR_LOCKOUT Single sensor can be locked out.
• GLOBAL_SENSOR_LOCKOUT All the sensors are locked out for touch detection.
• NO_LOCK_OUT All the sensors are available for touch detection.
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
82
Range: SINGLE_SENSOR_LOCKOUT to NO_LOCK_OUT.
Data Fields
• SINGLE_SENSOR_LOCKOUT 0u
• GLOBAL_SENSOR_LOCKOUT 1u
• NO_LOCK_OUT 2u
11.3.22. 11_3_21_PTC_GPIO_STATE(ptc_gpio_state_t)
Detailed Description
PTC lines state in unmeasured condition can be set using this enum
• PULLHIGH_WHEN_NOT_MEASURED Indicates that default state of PTC lines are at vcc.
• GND_WHEN_NOT_MEASURED Indicates that default state PTC lines are grounded.
Range: PULLHIGH_WHEN_NOT_MEASURED=0 and GND_WHEN_NOT_MEASURED.
Data Fields
• PULLHIGH_WHEN_NOT_MEASURED
• GND_WHEN_NOT_MEASURED
11.3.23. Moisture Group Setting (moisture_grp_t)
Detailed Description
Sensor can be configured in the moisture group using this type.
• MOIS_DISABLED Indicates that the sensor does not belong to any moisture group.
• MOIS_GROUP_X Indicates that the sensor belongs to the moisture group x.
Range: MOIS_DISABLED = 0 to MOIS_GROUP_7.
Data Fields
• MOIS_DISABLED=0
• MOIS_GROUP_0
• MOIS_GROUP_1
• MOIS_GROUP_2
• MOIS_GROUP_3
• MOIS_GROUP_4
• MOIS_GROUP_5
• MOIS_GROUP_6
• MOIS_GROUP_7
• MOIS_GROUPN
11.3.24. Multi-touch Group Setting (mltch_grp_t)
Detailed Description
Sensor can be configured in the multi-touch group using this type
• MLTCH_NONE Indicates that the sensor does not belong to any multi-touch group.
• MLTCH_GROUP_X Indicates that the sensor belongs to the multi-touch group x.
Range: MLTCH_NONE=0 to MOIS_GROUP_7.
Data Fields
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
83
• MLTCH_NONE=0
• MLTCH_GROUP_0
• MLTCH_GROUP_1
• MLTCH_GROUP_2
• MLTCH_GROUP_3
• MLTCH_GROUP_4
• MLTCH_GROUP_5
• MLTCH_GROUP_6
• MLTCH_GROUP_7
• MLTCH_GROUPN
11.3.25. Touch Mode Configuration (tag_tch_mode)
Touch mode can be configured.
Note: This is applicable only for ATmega devices.
Data Fields
• TCH_MODE_POLLED Polled mode
• TCH_MODE_ISR Interrupt mode
• TCH_MODE_NONE Touch mode is null.
11.3.26. Trigger Mode (tag_trigger_mode)
Trigger source for continuous hardware PTC acquisition. It is n clock cycles of internal 128Khz clock.
Note: This is applicable only for ATmega devices.
Data Fields
• TCH_TRIGGER_128KHZ_4MS
• TCH_TRIGGER_128KHZ_8MS
• TCH_TRIGGER_128KHZ_16MS
• TCH_TRIGGER_128KHZ_32MS
• TCH_TRIGGER_128KHZ_64MS
• TCH_TRIGGER_128KHZ_128MS
• TCH_TRIGGER_128KHZ_256MS
11.4. Datastructures
11.4.1. Touch Library Timing Info (tag_touch_time_t)
Touch library time parameter.
Data Fields
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
84
Field Unit Description
measurement_period_ms uint16_t Touch measurement period in milliseconds. This
variable determines how often a new touch
measurement must be done.
current_time_ms volatile
uint16_t
Current time set by timer ISR.
time_to_measure_touch volatile
uint8_t
Flag set by timer ISR when it is time to measure
touch.
11.4.2. Sensor Info (tag_sensor_t)
Sensor structure for storing sensor related information.
Data Fields
Keyword Type Description
state uint8_t Sensor state (calibrate, on, off, filter-in, filter-out, disable, pos-recal)
general_counter uint8_t General purpose counter used for calibrating, drifting, etc
ndil_counter uint8_t Counter used for detect integration
type_aks_pos_hyst uint8_t bits 7..6: sensor type: {00: key,01: rotor,10: slider,11: reserved} bits
5..3: AKS group (0..7): 0 = no AKS group bit 2 : positive recal flag
bits 1..0: hysteresis
threshold uint8_t Sensor detection threshold
from_channel uint8_t Sensor from channel for keys: from channel = to channel. Rotors:
Top channel. Sliders : Left most channel
Note: We need to_channel for rotors/sliders only
to_channel uint8_t For keys, this is unused. For rotors: Bottom left channel. For sliders:
Middle channel
index uint8_t Index into array of rotor/slider values
11.4.3. Global Sensor Configuration Info (tag_touch_global_param_t)
Touch library global parameter.
Data Fields
Field Unit Description
di uint8_t Detect Integration (DI) limit.
atch_drift_rate uint8_t Sensor away from touch drift rate.
tch_drift_rate uint8_t Sensor towards touch drift rate.
max_on_duration uint8_t MaximumON time duration.
drift_hold_time uint8_t Sensor drift hold time.
atch_recal_delay uint8_t Sensor away from touch
recalibration delay.
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
85
Field Unit Description
cal_seq_1_count uint8_t Sensor calibration dummy burst
count.
cal_seq_2_count uint8_t Sensor calibration settling burst
count.
recal_threshold recal_threshold_t Sensor away from touch
recalibration threshold.
touch_postprocess_mode Uint16_t Sensor post-processing mode.
auto_os_sig_stability_limit uint8_t Stability limit for Auto Oversample
feature.
auto_tune_sig_stability_limit uint16_t Stability limit for frequency auto
tune feature.
auto_freq_tune_in_cnt uint8_t Frequency auto tune In counter.
nm_sig_stability_limit uint16_t Stability limit for noise
measurement.
nm_noise_limit uint8_t Noise limit.
nm_enable_sensor_lock_out nm_sensor_lockout_t Sensor lockout feature variable.
nm_lockout_countdown uint8_t Lockout countdown for noise
measurement.
Charge_share_delay uint8_t Charge share delay value;
applicable only for SAM C20, SAM
C21, SAM L22 and ATmega
devices.
11.4.4. Filter Callback Data Type (tag_touch_filter_data_t)
Touch library filter callback data type.
Data Fields
Field Unit Description
num_channel_signals uint16_t Length of the measured signal values list.
p_channel_signals uint16_t Pointer to measured signal values for each channel.
11.4.5. Measure Data Type (tag_touch_measure_data_t)
Touch library measure data type.
Data Fields
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
86
Field Unit Description
measurement_done_t
ouch
volatile uint8_t Flag set by
touch_xxxxcap_measure_complete_callba
ck() function when a latest Touch status is
available.
acq_status touch_acq_status_t Status of touch measurement.
num_channel_signal
s
uint16_t Length of the measured signal values list.
*p_channel_signals uint16_t Pointer to measured signal values for each
channel.
num_channel_refere
nces
uint16_t Length of the measured reference values list.
*p_channel_referen
ces
uint16_t Pointer to measured reference values for each
channel.
num_sensor_states uint8_t Number of sensor state bytes.
*p_sensor_states uint8_t Pointer to touch status of each sensor.
num_rotor_slider_v
alues
uint8_t Length of the rotor and slider position values list.
*p_rotor_slider_va
lues
uint8_t Pointer to rotor and slider position values.
num_sensors uint16_t Length of the sensors data list.
*p_cc_calibration_
vals
uint16_t Pointer to calibrated compensation values for a
given sensor channel.
*p_sensors sensor_t Pointer to sensor data.
*p_sensor_noise_st
atus
uint8_t Pointer to noise status of the sensors.
*p_nm_ch_noise_val uint16_t Pointer to noise level value of each channel.
*p_sensor_mois_sta
tus
uint8_t Pointer to moisture status
*p_auto_os_status uint8_t Pointer to auto-oversamples status
cc_calib_status_fl
ag
uint8_t Flag is set when CC-calibration is ongoing.
11.4.6. Sensor Configuration Parameter
(tag_touch_selfcap_param_t,tag_touch_mutlcap_param_t)
Touch library self-capacitance and mutual capacitance sensor parameter.
Data Fields
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
87
Field Unit Description
aks_group aks_group_t Which AKS group, the sensor belongs to.
detect_threshold threshold_t An unsigned 8-bit number setting a sensor detection
threshold.
detect_hysteresis hysteresis_t A sensor detection hysteresis value. This is expressed as
a percentage of the sensor detection threshold. HYST_x =
hysteresis value is x% of detection threshold value
(rounded down). A minimum value of 2 is used. Example: If
detection threshold = 20,
HYST_50= 10 (50% of 20)
HYST_25= 5 (25% of 20)
HYST_12_5 = 2 (12.5% of 20)
HYST_6_25 = 2 (6.25% of 20 = 1, but value is hard limited
to 2)
position_resolution resolution_t For rotors and sliders, the resolution of the reported angle
or position. RES_x_BIT = rotor/slider reports x-bit values.
Example: If slider resolution is RES_7_BIT, then reported
positions are in the range 0..127
position_hysteresis uint8_t Sensor position hysteresis. This is valid only for a rotor or
slider. bits 1..0: hysteresis.
Note: This parameter is valid only for mutual capacitance
method.
11.4.7. Sensor Acquisition Parameter
(tag_touch_selfcap_acq_param_t,_tag_touch_mutlcap_acq_param_t)
Sensor acquisition parameter.
Data Fields
Field Unit Description
*p_xxxxcap_gain_per_node gain_t Pointer to gain per node.
touch_xxxxcap_freq_mode Freq_mode_sel_t Set-up acquisition frequency mode.
*xxxxcap_ptc_prsc prsc_div_sel_t Pointer to PTC clock pre-scaler value.
*xxxxcap_resistor_value rsel_val_t Pointer to PTC series resistor value.
p_xxxxcap_hop_freqs *freq_hop_sel_t Pointer to acquisition frequency
settings.
*p_xxxxcap_filter_level filter_level_t Pointer to filter level.
*p_xxxxcap_auto_os auto_os_t Pointer to auto oversampling.
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
88
Field Unit Description
*xxxxcap_ptc_prsc_cc_cal prsc_div_sel_t Pointer to PTC clock prescale value
during CC calibration.
*xxxxcap_resistor_value_cc_cal rsel_val_t Pointer to PTC sense resistor value
during CC calibration.
11.4.8. Self-capacitance Sensor Configuration (touch_selfcap_config_t)
Touch Library self-capacitance configuration input type.
Data Fields
Field Unit Description
num_channels uint16_t Number of channels.
num_sensors uint16_t Number of sensors.
num_rotors_and_sliders uint8_t Number of rotors/
sliders.
global_param touch_global_param_t Global sensor
configuration
information.
touch_selfcap_acq_param touch_selfcap_acq_param_t Sensor acquisition
parameter information.
*p_data_blk uint8_t Pointer to data block
buffer.
buffer_size uint16_t Size of data block
buffer.
*p_selfcap_y_nodes uint16_t Pointer to selfcapacitance
nodes.
self_quick_reburst_enable uint8_t Quick re-burst enable.
(touch_filter_data_t
*p_filter_data)
void(*filter_callback) Self-capacitance filter
callback.
enable_freq_auto_tune uint8_t Frequency auto tune
enable.
enable_noise_measurement uint8_t Noise measurement
enable.
nm_buffer_cnt uint8_t Memory allocation
buffer.
self_mois_tlrnce_enable uint8_t Self-capacitance
moisture tolerance
enable flag.
self_mois_groups uint8_t Number of selfcapacitance
moisture
groups.
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
89
Field Unit Description
self_mois_quick_reburst_enable uint8_t Moisture Quick re-burst
enable.
self_ptc_gpio_state ptc_gpio_state_t GPIO state for Selfcapacitance
PTC pins
tlib_feature_list tlib_init_fn_ptr Library feature list.
11.4.9. Mutual Capacitance Sensor Configuration (touch_mutlcap_config_t)
Touch Library mutual capacitance configuration input type.
Data Fields
Field Unit Description
num_channels uint16_t Number of channels.
num_sensors uint16_t Number of sensors.
num_rotors_and_sliders uint8_t Number of rotors/
sliders.
global_param touch_global_param_t Noise measurement
enable/disable.
touch_xxxxcap_acq_param touch_xxxxcap_acq_param_t Sensor acquisition
parameter info.
*p_data_blk uint8_t Pointer to data block
buffer.
*buffer_size uint16_t Size of data block
buffer.
*p_mutlcap_xy_nodes uint16_t Pointer to xy-nodes.
mutl_quick_reburst_enable uint8_t Quick re-burst enable.
(touch_filter_data_t
*p_filter_data)
void(* filter_callback ) Mutual capacitance
filter callback.
enable_freq_auto_tune uint8_t Frequency auto tune
enable.
enable_noise_measurement uint8_t Noise measurement
enable.
nm_buffer_cnt uint8_t Memory allocation
buffer.
mutl_mois_tlrnce_enable uint8_t Mutual capacitance
moisture tolerance
enable flag.
mutl_mois_groups uint8_t Number of mutual
capacitance moisture
groups.
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
90
Field Unit Description
mutl_mois_quick_reburst_enable uint8_t Moisture Quick re-burst
enable.
mutl_ptc_gpio_state ptc_gpio_state_t GPIO state for mutual
capacitance PTC pins
tlib_feature_list tlib_init_fn_ptr Library feature list.
11.4.10. Moisture Structure (tag_snsr_mois_t)
Structure for storing moisture and multi-touch group information.
Data Fields
Field Unit Description
mois_grp uint8_t Moisture group member
multch_grp uint8_t Multi-touch group member
11.4.11. Touch Library Input Configuration (touch_config_t)
Touch Library Input Configuration Structure.
Data Fields
Field Unit Description
p_mutlcap_config touch_mutlcap_config_t Pointer to mutual capacitance configuration
structure.
p_selfcap_config touch_selfcap_config_t Pointer to self-capacitance configuration
structure.
ptc_isr_lvl uint8_t PTC ISR priority level.
Note: This is applicable only for SAM devices.
tch_mode tch_mode_t Touch mode configuration.
Note: This is applicable only for ATmega
devices.
11.4.12. Library Function List (tag_tlib_init_fn_ptr_t)
Touch Library support functions initializer.
Data Fields
Field Unit Description
auto_tune_init void(*auto_tune_init) Auto-tune function initializer
auto_os_init uint32_t (*auto_os_init) Auto-OS function initializer
lk_chk void(*lk_chk) Sensor lock-out function initializer
enable_aks void enable_aks(void) AKS function initializer
11.4.13. Touch Library Information (tag_touch_info_t)
Touch Library information structure.
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
91
Data Fields
Field Unit Description
tlib_state touch_tlib_state_t Touch library state is specified
num_channels_in_use unit16_t Number of channels in use;
irrespective of the corresponding
sensor being disabled or enabled
num_sensors_in_use uint16_t Number of sensors in use;
irrespective of the sensor being
disabled or enabled
num_rotors_sliders_in_use uint8_t Number of rotor sliders in use;
irrespective of the Rotor/Slider being
disabled or enabled
max_channels_per_rotor_slider uint8_t Max possible number of channels
per rotor or slider
11.4.14. Touch Library Version Information (touch_libver_info_t)
Touch Library version information structure.
Data Fields
Field Unit Description
chip_id unit32_t Chip ID
product_id uint16_t Product ID
fw_version uint16_t Touch Library Version
Bits[12:15] Reserved
Bits[8:11] TLIB_MAJOR_VERSION
Bits[4:7] TLIB_MINOR_VERSION
Bits[0:3] TLIB_PATCH_VERSION
11.5. Global Variables
Field Unit Description
touch_time touch_time_t This holds the library timing info
touch_acq_status touch_acq_status_t This holds the Touch Library acquisition
status
cc_cal_max_signal_limit uint16_t CC calibration maximum signal limit
variable
cc_cal_min_signal_limit uint16_t CC calibration minimum signal limit
variable
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
92
Field Unit Description
*p_selfcap_measure_data touch_measure_data_t This holds the self-capacitance method
measure data pointer
*p_mutlcap_measure_data touch_measure_data_t This holds the mutual capacitance method
measure data pointer
wake_up_touch uint8_t Wake up touch status from Library to
Application
low_power_mode uint8_t Low power mode status from Library to
Application
mois_lock_global_mutl uint8_t Moisture global lock variable for mutual
capacitance method
mois_lock_global_self uint8_t Moisture global lock variable for selfcapacitance
method
11.6. API
11.6.1. Sensor Init and De-init
touch_ret_t touch_mutlcap_sensors_init (touch_config_t * p_touch_config)
touch_ret_t touch_selfcap_sensors_init (touch_config_t * p_touch_config)
This API is used to initialize the Touch Library with Mutual cap or Self cap method pin, register and sensor
configuration provided by the user.
Parameters:p_touch_config Pointer to Touch configuration structure.
Returns:touch_ret_t: Touch Library Error status.
touch_ret_t touch_mutlcap_sensors_deinit(void)
touch_ret_t touch_selfcap_sensors_deinit(void);
This API can be used to de-initialize the sensor for specific sensing group.
Parameters:
void.
Returns:
touch_ret_t: Touch Library Error status.
11.6.2. Sensor Setup and Configuration
touch_ret_t touch_mutlcap_sensor_config (sensor_type_t sensor_type, channel_t from_channel,
channel_t to_channel, aks_group_t aks_group, threshold_t detect_threshold, hysteresis_t
detect_hysteresis, resolution_tposition_resolution, uint8_t position_hysteresis, sensor_id_t
* p_sensor_id)
touch_ret_t touch_selfcap_sensor_config (sensor_type_t sensor_type, channel_t from_channel,
channel_t to_channel, aks_group_t aks_group, threshold_t detect_threshold, hysteresis_t
detect_hysteresis, resolution_tposition_resolution, sensor_id_t * p_sensor_id)
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
93
This API can be used to configure a sensor of type key, rotor or slider.
Data Fields:
Field Description
sensor_type can be of type key, lump, rotor, or slider.
from_channel the first channel in the slider sensor.
to_channel the last channel in the slider sensor.
aks_group which AKS group (if any) the sensor is in.
detect_threshold the sensor detection threshold.
detect_hysteresis the sensor detection hysteresis value.
position_resolution the resolution of the reported position value.
position_hysteresis the hysteresis for position value (available only for mutual capacitance
mode).
p_sensor_id the sensor id value of the configured sensor is updated by the Touch Library.
Returns: touch_ret_t: Touch Library Error status.
11.6.3. Sensor Calibration
touch_ret_t touch_mutlcap_sensors_calibrate (auto_tune_type_t )
touch_ret_t touch_selfcap_sensors_calibrate (auto_tune_type_t )
This API is used to calibrate the sensors for the first time before starting a Touch measurement. This API
can also beused to force calibration of sensors when any of the Touch sensor parameters are changed
during runtime.
Returns:touch_ret_t: Touch Library Error status.
11.6.4. Sensor Measure
touch_ret_t touch_mutlcap_sensors_measure (touch_current_time_t current_time_ms,
touch_acq_mode_tmutlcap_acq_mode, void(*)(void) measure_complete_callback)
touch_ret_t touch_selfcap_sensors_measure (touch_current_time_t current_time_ms,
touch_acq_mode_tselfcap_acq_mode, void(*)(void) measure_complete_callback)
This API can be used to start a Touch measurement.
Parameters:
current_time_ms Current time in millisecond.
measure_complete_callback Interrupt callback to indicate measurement completion.
Returns:
touch_ret_t: Touch Library Error status.
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
94
11.6.5. Sensor Suspend and Resume
touch_ret_t touch_suspend_ptc(void)
touch_ret_t touch_resume_ptc(void)
The touch_suspend_ptc function suspends the PTC library's current measurement cycle. The
completion of the operation is indicated through callback pointer that must be initialized by the application.
Refer Sensor Global Parameters.
The touch_resume_ptc function resumes the PTC library's current measurement which was
suspended using touch_suspend_ptc. After the touch_resume_ptc function is called by the
application, the touch_xxxxcap_sensors_measure API should be called only after the measurement
complete callback function is received.
Parameters:
void.
Returns:
touch_ret_t: Touch Library Error status.
11.6.6. Sensor Disable and Re-enable
touch_ret_t touch_mutlcap_sensor_disable (sensor_id_t sensor_id)
touch_ret_t touch_selfcap_sensor_disable (sensor_id_t sensor_id)
This API can be used to disable any sensor.
Parameters:
sensor_id Sensor number which needs to be disabled
Returns:
touch_ret_t: Touch Library Error status.
touch_ret_t touch_mutlcap_sensor_reenable (sensor_id_t sensor_id, uint8_t no_calib)
touch_ret_t touch_selfcap_sensor_reenable (sensor_id_t sensor_id, uint8_t no_calib)
This API can be used to re-enable a disabled sensor.
Parameters:
sensor_id Sensor number which needs to be reenabled
no_calib When value is set to 1, force calibration is not applicable. When value is set to 0, force
calibration is applied
Returns:
touch_ret_t: Touch Library Error status.
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
95
11.6.7. Read-back Sensor Configuration
touch_ret_t touch_mutlcap_sensor_get_acq_config (touch_mutlcap_acq_param_t *
p_touch_mutlcap_acq_param)
touch_ret_t touch_selfcap_sensor_get_acq_config (touch_selfcap_acq_param_t *
p_touch_selfcap_acq_param)
This API can be used to read back the sensor acquisition parameters.
Parameters:
p_touch_mutlcap_acq_param The acquisition parameters for the mutual capacitance.
p_touch_selfcap_acq_param The acquisition parameters for the self-capacitance.
Returns:
touch_ret_t: Touch Library Error status.
touch_ret_t touch_mutlcap_sensor_get_config (sensor_id_t sensor_id, touch_mutlcap_param_t
*p_touch_sensor_param)
touch_ret_t touch_selfcap_sensor_get_config (sensor_id_t sensor_id, touch_selfcap_param_t
*p_touch_sensor_param)
This API can be used to read back the sensor configuration parameters.
Parameters:
sensor_id The sensor id for which the parameters has to be read-back.
p_touch_sensor_param The sensor parameters for the mutual or self-capacitance.
Returns:
touch_ret_t: Touch Library Error status.
touch_ret_t touch_mutlcap_sensor_get_delta (sensor_id_t sensor_id, touch_delta_t * p_delta)
touch_ret_t touch_selfcap_sensor_get_delta (sensor_id_t sensor_id, touch_delta_t * p_delta)
This API can be used to retrieve the delta value corresponding to a given sensor.
Parameters:
sensor_id The sensor id for which delta value is being seeked.
p_delta Pointer to the delta variable to be updated by the Touch Library.
Returns:
touch_ret_t: Touch Library Error status.
touch_ret_t touch_mutlcap_get_global_param (touch_global_param_t * p_global_param)
touch_ret_t touch_selfcap_get_global_param (touch_global_param_t * p_global_param)
This API can be used to read back the global parameter.
Parameters:
p_global_param The pointer to global sensor configuration.
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
96
Returns:
touch_ret_t: Touch Library Error status.
11.6.8. Update Sensor Configuration
touch_ret_t touch_mutlcap_sensor_update_acq_config (touch_mutlcap_acq_param_t
*p_touch_mutlcap_acq_param)
touch_ret_t touch_selfcap_sensor_update_acq_config (touch_selfcap_acq_param_t *
p_touch_selfcap_acq_param)
This API can be used to update the sensor acquisition parameters.
Parameters:
p_touch_mutlcap_acq_param The acquisition parameters for the mutual capacitance.
p_touch_selfcap_acq_param The acquisition parameters for the self-capacitance.
Returns:
touch_ret_t: Touch Library Error status.
touch_ret_t touch_mutlcap_sensor_update_config (sensor_id_t sensor_id, touch_mutlcap_param_t
*p_touch_sensor_param)
touch_ret_t touch_selfcap_sensor_update_config (sensor_id_t sensor_id, touch_selfcap_param_t
*p_touch_sensor_param
This API can be used to update the sensor configuration parameters.
Parameters:
sensor_id The sensor id whose configuration parameters has to be changed.
p_touch_sensor_param The touch sensor parameter structure that will be used by the Touch Library
to update.
Returns:
touch_ret_t: Touch Library Error status.
touch_ret_t touch_mutlcap_update_global_param (touch_global_param_t * p_global_param)
touch_ret_t touch_selfcap_update_global_param (touch_global_param_t * p_global_param)
This API can be used to update the global parameter.
Parameters:
p_global_param The pointer to global sensor configuration.
Returns:
touch_ret_t: Touch Library Error status.
11.6.9. Get Library Information and Version
touch_ret_t touch_mutlcap_get_libinfo (touch_info_t * p_touch_info)
touch_ret_t touch_selfcap_get_libinfo (touch_info_t * p_touch_info)
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
97
This API can be used to get the Touch Library configuration.
Parameters:
p_touch_info Pointer to the Touch info data structure that will be updated by the Touch Library.
Returns:
touch_ret_t: Touch Library Error status.
touch_ret_t touch_library_get_version_info (touch_libver_info_t * p_touch_libver_info)
This API can be used to get the Touch Library version information.
Parameters:
p_touch_libver_info Pointer to the Touch Library Version info data structure that will be updated by
the Touch Library.
11.6.10. Moisture Tolerance API
touch_ret_t touch_mutlcap_cnfg_mois_mltchgrp(sensor_id_t snsr_id, moisture_grp_t mois_grpid,
mltch_grp_t mltch_grpid)
touch_ret_t touch_selfcap_cnfg_mois_mltchgrp(sensor_id_t snsr_id, moisture_grp_t mois_grpid,
mltch_grp_t mltch_grpid)
This API can be used to assign moisture group and multi touch group for a sensor.
Parameters:
snsr_id - sensor ID
mois_grpid - moisture group ID
mltch_grp_t - multi-touch group
Returns:
touch_ret_t: Touch Library Error status.
touch_ret_t touch_mutlcap_cnfg_mois_threshold(moisture_grp_t mois_grpid,
mois_snsr_threshold_t snsr_threshold, mois_system_threshold_t system_threshold)
touch_ret_t touch_selfcap_cnfg_mois_threshold(moisture_grp_t mois_grpid,
mois_snsr_threshold_t snsr_threshold, mois_system_threshold_t system_threshold)
This API is used to assign moisture sensor threshold and moisture system threshold to a moisture group
ID
Parameters:
mois_grpid - moisture group ID
snsr_threshold - moisture sensor threshold
system_threshold - moisture system threshold
Returns:
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
98
touch_ret_t: Touch Library Error status.
touch_ret_t touch_mutlcap_mois_tolrnce_enable(void)
touch_ret_t touch_selfcap_mois_tolrnce_enable(void)
This API is used to enable moisture tolerance check during run time.
Returns:
touch_ret_t: Touch Library Error status.
touch_ret_t touch_mutlcap_mois_tolrnce_quick_reburst_enable(void)
touch_ret_t touch_selfcap_mois_tolrnce_quick_reburst_enable(void)
This API is used to enable moisture tolerance quick re- burst feature during run time.
Returns:
touch_ret_t: Touch Library Error status.
touch_ret_t touch_mutlcap_mois_tolrnce_disable(void)
touch_ret_t touch_selfcap_mois_tolrnce_disable(void)
This API is used to disable moisture tolerance check during run time.
Returns:
touch_ret_t: Touch Library Error status.
touch_ret_t touch_mutlcap_mois_tolrnce_quick_reburst_disable(void)
touch_ret_t touch_selfcap_mois_tolrnce_quick_reburst_disable(void)
This API is used to disable moisture tolerance quick re- burst feature during run time.
Returns:
touch_ret_t: Touch Library Error status.
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
99
12. Revision History
Doc. Rev. Date Comments
Rev.M 07/2016 1. Updated the latest software version numbers in Section 1
2. Added a new errata in Section 9
Rev.L 04/2016 Updated Sections 1, 5, and 8 with reference to the latest extension
release
Rev.K 02/2016 Added ATmega324PB support.
Updated Sections 1, 5 and 8 with reference to the latest extension
release
Rev.J 01/2016 Included the following new sections:
1. Compensation Circuit
2. Using Atmel ICE for Qdebug Data Streaming
3. Application flow for megaAVR
Updated Sections 5 and 8 with reference to the latest extension release
Rev.I 09/2015 Included Charge share delay
Updated Section 5 .2.8 and 5.2.10 - Library parameters for quick re-burst
and moisture parameters added
Updated Section 11.6.8 - Moisture API's Added
Updated section 8 - Example projects updated
Rev.H 06/2015 Revised Section 2 - Device Variants Supported and included information
on device multiplexing option
Updated Section 7.2 - Code and data memory considerations
Updated Section 5.2.1 - Pin, Channel, and Sensor Parameters
Rev.G 04/2015 Updated Section 2 - Device Variants Supported and included information
on device multiplexing option
Rev.F 02/2015 Included relevant information regarding low-power and lumped mode
support
Rev.E 11/2014 Included Section 5.2.6 and 5.2.7 regarding noise counter measures.
Included Section 3 regarding overview of capacitive touch technology.
Rev.D 02/2014 Global updates across the document related to QTouch Library and
QTouch Composer 5.3
Rev.C 10/2013 Included Section 3.3.4, Using QDebug Touch Data Debug
Communication
Included a note on interrupt handler for IAR example project in Section
3.3.3
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
100
Doc. Rev. Date Comments
Rev.B 10/2013 Updated errata in Section 4, Known Issues
Rev.A 09/2013 Initial document release
Atmel QTouch Library Peripheral Touch Controller [USER GUIDE]
Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
101
Atmel Corporation 1600 Technology Drive, San Jose, CA 95110 USA T: (+1)(408) 441.0311 F: (+1)(408) 436.4200 | www.atmel.com
© 2016 Atmel Corporation. / Rev.: Atmel-42195M-Peripheral-Touch-Controller_User Guide-07/2016
Atmel®
, Atmel logo and combinations thereof, Enabling Unlimited Possibilities®
, AVR ®
QTouch®
, AKS®
and others are registered trademarks or trademarks of Atmel
Corporation in U.S. and other countries. ARM®
and Cortex®
are registered trademarks of ARM Limited. Other terms and product names may be trademarks of
others.
DISCLAIMER: The information in this document is provided in connection with Atmel products. No license, express or implied, by estoppel or otherwise, to any
intellectual property right is granted by this document or in connection with the sale of Atmel products. EXCEPT AS SET FORTH IN THE ATMEL TERMS AND
CONDITIONS OF SALES LOCATED ON THE ATMEL WEBSITE, ATMEL ASSUMES NO LIABILITY WHATSOEVER AND DISCLAIMS ANY EXPRESS, IMPLIED
OR STATUTORY WARRANTY RELATING TO ITS PRODUCTS INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTY OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. IN NO EVENT SHALL ATMEL BE LIABLE FOR ANY DIRECT, INDIRECT,
CONSEQUENTIAL, PUNITIVE, SPECIAL OR INCIDENTAL DAMAGES (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS AND PROFITS, BUSINESS
INTERRUPTION, OR LOSS OF INFORMATION) ARISING OUT OF THE USE OR INABILITY TO USE THIS DOCUMENT, EVEN IF ATMEL HAS BEEN ADVISED
OF THE POSSIBILITY OF SUCH DAMAGES. Atmel makes no representations or warranties with respect to the accuracy or completeness of the contents of this
document and reserves the right to make changes to specifications and products descriptions at any time without notice. Atmel does not make any commitment to
update the information contained herein. Unless specifically provided otherwise, Atmel products are not suitable for, and shall not be used in, automotive
applications. Atmel products are not intended, authorized, or warranted for use as components in applications intended to support or sustain life.
SAFETY-CRITICAL, MILITARY, AND AUTOMOTIVE APPLICATIONS DISCLAIMER: Atmel products are not designed for and will not be used in connection with any
applications where the failure of such products would reasonably be expected to result in significant personal injury or death (“Safety-Critical Applications”) without
an Atmel officer's specific written consent. Safety-Critical Applications include, without limitation, life support devices and systems, equipment or systems for the
operation of nuclear facilities and weapons systems. Atmel products are not designed nor intended for use in military or aerospace applications or environments
unless specifically designated by Atmel as military-grade. Atmel products are not designed nor intended for use in automotive applications unless specifically
designated by Atmel as automotive-grade.
Software
Atmel Studio
USER GUIDE
Preface
Atmel®
Studio is an Integrated Development Environment (IDE) for writing
and debugging AVR®
/ARM®
applications in Windows®
XP/Windows Vista®
/
Windows 7/8 environments. Atmel Studio provides a project management
tool, source file editor, simulator, assembler, and front-end for C/C++,
programming, and on-chip debugging.
Atmel Studio supports the complete range of Atmel AVR tools. Each new
release contains the latest updates for the tools as well as support for new
AVR/ARM devices.
Atmel Studio has a modular architecture, which allows interaction with 3rd
party software vendors. GUI plugins and other modules can be written and
hooked to the system. Contact Atmel for more information.
Atmel-42167B-Atmel-Studio_User Guide-09/2016
Table of Contents
Preface............................................................................................................................ 1
1. Introduction................................................................................................................8
1.1. Features....................................................................................................................................... 8
1.2. New and Noteworthy.................................................................................................................... 8
1.2.1. Atmel Studio 7.0............................................................................................................ 8
1.2.2. Atmel Studio 6.2 Service Pack 2..................................................................................11
1.2.3. Atmel Studio 6.2 Service Pack 1..................................................................................11
1.2.4. Atmel Studio 6.2...........................................................................................................11
1.2.5. Atmel Studio 6.1 Update 2...........................................................................................12
1.2.6. Atmel Studio 6.1 Update 1.1........................................................................................12
1.2.7. Atmel Studio 6.1 Update 1...........................................................................................12
1.2.8. Atmel Studio 6.1.......................................................................................................... 12
1.2.9. Atmel Studio 6.0.......................................................................................................... 12
1.2.10. AVR Studio 5.1.............................................................................................................13
1.3. Installation.................................................................................................................................. 13
1.4. Contact Information.................................................................................................................... 14
2. Getting started......................................................................................................... 16
2.1. Starting Atmel Studio..................................................................................................................16
2.2. Creating a Project.......................................................................................................................17
2.2.1. Introduction.................................................................................................................. 17
2.2.2. Creating a new Project................................................................................................ 17
2.2.3. Choosing a Target Device............................................................................................19
2.2.4. Writing and Compiling Code........................................................................................ 19
3. Project Management................................................................................................22
3.1. Introduction.................................................................................................................................22
3.1.1. The Solution Container................................................................................................ 22
3.1.2. Save and Open Projects..............................................................................................22
3.1.3. Project Output View..................................................................................................... 22
3.1.4. Solution Explorer......................................................................................................... 22
3.1.5. Toolbar Icons............................................................................................................... 23
3.1.6. Hierarchical Display..................................................................................................... 23
3.1.7. Item Management Commands.................................................................................... 23
3.1.8. Project Components.................................................................................................... 23
3.2. GCC Projects..............................................................................................................................25
3.2.1. New Project Wizard..................................................................................................... 25
3.2.2. Starting a New GCC Project for AVR Device...............................................................25
3.2.3. Libraries Options..........................................................................................................29
3.2.4. Starting a New GCC Project for SAM (ARM) Device...................................................33
3.2.5. Code Editing................................................................................................................ 36
3.2.6. Starting a New GCC Static Library Project.................................................................. 37
3.2.7. GCC Project Options and Configuration......................................................................40
3.3. Assembler Projects.....................................................................................................................57
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
2
3.3.1. Create New Assembler Project....................................................................................57
3.3.2. Assembler Options ..................................................................................................... 60
3.4. Import of Projects....................................................................................................................... 62
3.4.1. Introduction.................................................................................................................. 62
3.4.2. Import AVR Studio 4 Project........................................................................................ 62
3.4.3. Import AVR 32 Studio Project...................................................................................... 65
3.4.4. Import Project Template...............................................................................................69
3.5. Debug Object File in Atmel Studio..............................................................................................71
3.5.1. Introduction.................................................................................................................. 71
3.5.2. Atmel Studio Supported Debug Formats..................................................................... 72
3.5.3. Opening Object Debug File in Atmel Studio................................................................ 72
4. Debugging............................................................................................................... 77
4.1. Introduction.................................................................................................................................77
4.1.1. Debug Platform Independent Debug Environment...................................................... 77
4.1.2. Differences Between Platforms....................................................................................77
4.2. Starting a Debug Session...........................................................................................................77
4.3. Ending a Debug Session............................................................................................................77
4.4. Attaching to a Target...................................................................................................................78
4.5. Start without Debugging............................................................................................................. 78
4.5.1. One Click Programming - Program and Run............................................................... 78
4.5.2. Keyboard Shortcut....................................................................................................... 79
4.6. Debug Control............................................................................................................................ 79
4.7. Breakpoints.................................................................................................................................81
4.7.1. General Information on Breakpoints............................................................................ 81
4.7.2. Operations with Breakpoints........................................................................................82
4.7.3. Breakpoint Window......................................................................................................84
4.8. Data Breakpoints........................................................................................................................86
4.8.1. Adding Data Breakpoint...............................................................................................86
4.8.2. Data Breakpoints Window........................................................................................... 87
4.8.3. General Information on Data Breakpoint..................................................................... 98
4.8.4. Data Breakpoint Usage................................................................................................99
4.9. QuickWatch, Watch, Locals, and Autos Windows......................................................................99
4.9.1. Watch Window...........................................................................................................100
4.9.2. Locals Window...........................................................................................................102
4.9.3. Autos Window............................................................................................................103
4.9.4. QuickWatch and Watches..........................................................................................104
4.9.5. Expression Formatting...............................................................................................105
4.10. DataTips................................................................................................................................... 106
4.10.1. Expanding and Editing Information............................................................................107
4.10.2. Making a DataTip Transparent...................................................................................108
4.10.3. Visualizing Complex Data Types............................................................................... 108
4.10.4. Adding Information to a Watch Window.....................................................................108
4.10.5. Importing and Exporting DataTips............................................................................. 108
4.11. Disassembly View ................................................................................................................... 108
4.12. I/O View.................................................................................................................................... 110
4.12.1. About the I/O View..................................................................................................... 110
4.12.2. Using the I/O View Tool.............................................................................................. 111
4.12.3. Editing Values and Bits in Break Mode...................................................................... 111
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
3
4.13. Processor View ........................................................................................................................ 111
4.14. Register View............................................................................................................................112
4.15. Memory View............................................................................................................................112
4.16. Call Stack Window....................................................................................................................113
4.17. Object File Formats.................................................................................................................. 116
4.18. Trace.........................................................................................................................................117
4.18.1. Application Output......................................................................................................117
4.18.2. Program Counter Sampling........................................................................................118
4.18.3. Variable Watching...................................................................................................... 118
4.19. Trace View................................................................................................................................119
4.19.1. Trace View Options....................................................................................................119
4.19.2. Trace View Interpretation...........................................................................................122
5. Programming Dialog..............................................................................................125
5.1. Introduction...............................................................................................................................125
5.2. Interface Settings......................................................................................................................128
5.3. Tool Information........................................................................................................................131
5.4. Board Settings/Tool Settings.................................................................................................... 132
5.4.1. Power Debugger........................................................................................................132
5.4.2. STK600......................................................................................................................132
5.4.3. QT600........................................................................................................................133
5.4.4. STK500......................................................................................................................133
5.5. Card Stack................................................................................................................................134
5.6. Device Information....................................................................................................................135
5.7. Oscillator Calibration................................................................................................................ 136
5.8. Memories..................................................................................................................................137
5.9. Fuse Programming...................................................................................................................139
5.10. Lock Bits...................................................................................................................................140
5.11. Production Signatures.............................................................................................................. 140
5.12. Production Files........................................................................................................................141
5.13. Security.....................................................................................................................................144
5.14. Automatic Firmware Upgrade Detection...................................................................................145
6. Miscellaneous Windows........................................................................................ 146
6.1. Device Pack Manager.............................................................................................................. 146
6.2. User Interface Profile Selection................................................................................................148
6.3. Available Tools View.................................................................................................................149
6.3.1. Introduction................................................................................................................ 149
6.3.2. Tool Actions............................................................................................................... 150
6.3.3. Add a Non-detectable Tool........................................................................................ 150
6.4. Tool Info Window...................................................................................................................... 152
6.4.1. Xplained Pro Kits....................................................................................................... 154
6.4.2. Disable the Tools Info Window...................................................................................154
6.4.3. Manually Showing the Window..................................................................................154
6.5. Firmware Upgrade....................................................................................................................154
6.5.1. Introduction................................................................................................................ 154
6.5.2. Automatic Upgrade.................................................................................................... 154
6.5.3. Manual Upgrade........................................................................................................ 155
6.6. Find and Replace Window........................................................................................................155
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
4
6.7. Export Template Wizard........................................................................................................... 159
6.7.1. Project Template........................................................................................................ 160
6.7.2. Item Template............................................................................................................ 160
6.7.3. Template Parameters.................................................................................................160
6.8. Kit Mode Setting....................................................................................................................... 162
7. Atmel GNU Toolchains...........................................................................................163
7.1. GNU Compiler Collection (GCC)..............................................................................................163
7.2. ARM Compiler and Toolchain Options: GUI ............................................................................ 163
7.3. ARM GNU Toolchain Options...................................................................................................168
7.3.1. ARM/GNU Common Options.....................................................................................168
7.3.2. Compiler Options....................................................................................................... 168
7.3.3. Linker Options............................................................................................................171
7.3.4. Assembler Options.................................................................................................... 172
7.3.5. Preprocessing Assembler Options............................................................................ 172
7.3.6. Archiver Options........................................................................................................ 172
7.4. Binutils......................................................................................................................................173
7.5. AVR Compiler and Toolchain Options: GUI .............................................................................173
7.6. Commonly Used Options..........................................................................................................178
7.6.1. Compiler Options....................................................................................................... 178
7.6.2. Linker Options............................................................................................................181
7.6.3. Assembler Options.................................................................................................... 182
7.7. 8-bit Specific AVR GCC Command Line Options.....................................................................182
7.7.1. AVR C Compiler.........................................................................................................182
7.7.2. AVR C Linker............................................................................................................. 183
7.8. 32-bit Specific AVR GCC Command Line Options...................................................................183
7.8.1. Optimization...............................................................................................................183
7.8.2. Debugging................................................................................................................. 184
7.8.3. AVR32 C Linker......................................................................................................... 185
7.9. Binutils......................................................................................................................................186
8. Extending Atmel Studio......................................................................................... 187
8.1. Extension Manager UI..............................................................................................................187
8.2. Registering at Atmel Extension Gallery....................................................................................188
8.3. Installing New Extensions in Atmel Studio............................................................................... 189
8.4. Visual Assist............................................................................................................................. 192
8.5. Overview of QTouch Composer and Library............................................................................ 193
8.5.1. Installation..................................................................................................................194
8.5.2. Overview of QTouch Project Builder.......................................................................... 194
8.5.3. Overview of QTouch Analyzer................................................................................... 195
8.6. Scripting Extensions.................................................................................................................196
8.6.1. Debug Scripting......................................................................................................... 196
9. Menus and Settings...............................................................................................199
9.1. Customizing Existing Menus and Toolbars...............................................................................199
9.2. Reset Your Settings..................................................................................................................200
9.3. Options Dialog Box...................................................................................................................201
9.3.1. Environment Options................................................................................................. 201
9.3.2. Project Options.......................................................................................................... 218
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
5
9.3.3. Source Control...........................................................................................................221
9.3.4. Text Editor Options.................................................................................................... 221
9.3.5. Debugger................................................................................................................... 237
9.3.6. Atmel Software Framework Settings......................................................................... 238
9.3.7. Builder........................................................................................................................239
9.3.8. Device and Tool Libraries.......................................................................................... 239
9.3.9. Status Management...................................................................................................239
9.3.10. Text Templating..........................................................................................................240
9.3.11. Toolchain....................................................................................................................240
9.3.12. GDB Settings............................................................................................................. 241
9.4. Code Snippet Manager............................................................................................................ 242
9.4.1. Managing Code Snippets.......................................................................................... 242
9.4.2. Code Snippet Manager Layout.................................................................................. 243
9.4.3. Modifying Existing Code Snippets............................................................................. 243
9.5. External Tools...........................................................................................................................244
9.5.1. Add an External Tool to the Tools Menu.................................................................... 244
9.5.2. Pass Variables to External Tools................................................................................245
9.5.3. Initial Directory........................................................................................................... 246
9.5.4. Run Behavior............................................................................................................. 246
9.5.5. Assign a Keyboard Shortcut...................................................................................... 246
9.6. Predefined Keyboard Shortcuts............................................................................................... 246
10. Command Line Utility (CLI)................................................................................... 262
11. Frequently Asked Questions..................................................................................263
11.1. Compatibility with Legacy AVR Software and Third-party Products.........................................265
11.1.1. How do I Import External ELF Files for Debugging?................................................. 265
11.1.2. How do I Reuse My AVR Studio 4 Projects with the New Atmel Studio?.................. 265
11.2. Atmel Studio Interface.............................................................................................................. 266
11.2.1. How can I Start Debugging My Code? What is the Keyboard Shortcut for Debugging?
...................................................................................................................................266
11.2.2. What is a Solution?....................................................................................................266
11.2.3. What is a Project........................................................................................................266
11.2.4. How can I use an External Makefile for my Project?................................................. 266
11.2.5. When Watching a Variable, the Debugger says Optimized away......................266
11.2.6. When Starting a Debug Session, I get an Error Stating that Debug Tool is not Set
...................................................................................................................................267
11.3. Performance Issues..................................................................................................................267
11.3.1. Atmel Studio Takes a Very Long Time to Start on My PC, but Runs Well in a VM
Environment. Is there Something I Can do With This?..............................................267
11.3.2. Verification and Programming often Fails with a Serial Port Buffer Overrun Error
Message when using STK500................................................................................... 267
11.3.3. I've connected my Tool through a USB Hub, and now I get Error Messages and
Inconsistent Results while Programming and Debugging......................................... 267
11.4. Driver and USB Issues............................................................................................................. 267
11.4.1. How do I get my Tool to be Recognized by Atmel Studio?........................................ 267
11.4.2. The Firmware upgrade Process fails or is Unstable on a Virtualized Machine..........268
11.4.3. Debugging never Breaks under a Virtualized Machine..............................................268
11.4.4. No Tool is recognized by Atmel Studio, but the Driver seems to be Working............268
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
6
11.4.5. Firmware Upgrade Fails on VirtualBox...................................................................... 268
11.4.6. Common Jungo USB Errors...................................................................................... 269
11.4.7. Issues with ARM Compatible Tools........................................................................... 270
12. Document Revision History................................................................................... 272
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
7
1. Introduction
1.1. Features
Atmel Studio provides a large set of features for project development and debugging. The most notable
features are listed below.
• Rich code editor for C/C++ and Assembly featuring the powerful Visual Assist extension
• Cycle correct simulator with advanced debug functionality
• Atmel Software Framework allowing creation of modular applications and providing building blocks
for a prototype on any AVR platform
• Debugging on actual devices using Debugging Tools
• Rich SDK to enable tight integration of customer plugins
• Compatible with many Microsoft®
Visual Studio®
plugins
1.2. New and Noteworthy
New features available.
1.2.1. Atmel Studio 7.0
Atmel Studio 7.0.1006
The following changes are done in Atmel Studio 7.0.1006:
• New Atmel Start extension that allows the user to create and configure Atmel Start projects within
Atmel Studio
• Ability to load multiple modules in a debug session (experimental)
• AVR 8-bit GCC Toolchain 3.5.3 with upstream versions:
– gcc 4.9.2
– Binutils 2.26
– avr-libc 2.0.0
– gdb 7.8
• ARM GCC Toolchain 5.3.1 with upstream versions:
– gcc (ARM/embedded-5-branch revision 234589)
– Binutils 2.26
– gdb 7.10
Atmel Studio 7.0.1006 contains a fix for the following issues that were present in 7.0.943:
• AVRSV-6878: Atmel Studio write the write-once wdt registers on some SAM devices.
• AVRSV-7470: SAM Cortex®
-M7 devices fails launch occasionally.
• AVRSV-7471: Devices with external and internal RAM lists all the RAM as available.
• AVRSV-7473: Atmel Studio hangs during startup.
• AVRSV-7474: Kits connected to Atmel Studio are not getting enumerated in the QTouch Start Page.
• AVRSV-7477: Show all files does not work from solution explorer.
• AVRSV-7482: Exception when adding breakpoint on SAM4L.
• AVRSV-7486: Debugging may fail in Cortex-M0+ SAM devices at high clock speeds.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
8
Atmel Studio 7.0.943
Atmel Studio 7.0.943 contains a fix for the following issue:
• AVRSV-7459: Projects containing files with upper case file names can fail to build. Saving files with
upper case file names converts file name to lower case.
Atmel Studio 7.0.934
The following changes are done in Atmel Studio 7.0.934:
• AVR 8-bit GCC Toolchain 3.5.2 with upstream versions:
– gcc 4.9.2
– Binutils 2.26
– avr-libc 2.0.0
– gdb 7.8
• AVR 32-bit GCC Toolchain 3.4.3 with upstream versions:
– gcc 4.4.7
– Binutils 2.23.1
– Newlib 1.16.0
• ARM GCC Toolchain 4.9.3 with upstream versions:
– gcc (ARM/embedded-4_9-branch revision 224288)
– Binutils 2.24
– gdb 7.8.0.20150304-cvs
Atmel Studio 7.0.934 resolves the following issues present in Atmel Studio 7.0.790:
• AVRSV-7376: Atmel-ICE slow programming.
• AVRSV-7379: Unhandled exception when writing fuses or lockbits when Auto Read is turned off.
• AVRSV-7396: Some machines shows an error regarding 'Exception in MemoryPressureReliever'.
• AVRSV-7400: When in Standard mode, Disable debugWire and Close are not visible in the
Debug menu.
• AVRSV-7408: When using Atmel Studio in Standard mode, the Set Startup Project menu is
missing.
Atmel Studio 7.0.790
The following features are added in Atmel Studio 7.0.790:
• Support for mass storage mode in embedded debugger (EDBG), enabling drag and drop
programming
• Introduction of user interface profiles. The user can choose an interface where some of the toolbar
buttons and menu items are removed.
• Support for importing libraries to previously imported sketches. Added support for Arduino Zero and
Zero Pro.
• Parallel build turned on by default
Atmel Studio 7.0.790 resolves the following issues present in Atmel Studio 7.0.634:
• AVRSV-7084: Persist user settings during upgrade.
• AVRSV-7014: Some ATmega and ATtiny devices failed to start debugging with the Simulator.
• AVRSV-7230: "Show all files" in Solution Explorer not consistent.
• AVRSV-7062: Firmware upgrade of Xplained Mini kits not detected.
• AVRSV-7164: Reading flash to .bin file created incorrect .bin file.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
9
• AVRSV-7106: Hex files with Unix®
or mixed file endings fail to load.
• AVRSV-7126: Databreakpoints for ARM should not be limited to RAM.
Atmel Studio 7.0.634
This release adds device support for the SAM B11 device family.
Atmel Studio 7.0.634 resolves the following issues present in Atmel Studio 7.0.594:
• AVRSV-6873: Jungo Driver issue with Windows 10.
Note: If you install this version of Atmel Studio in parallel with an older Studio versions or IAR
Embedded Workbench®
and are using AVR Dragon™
, AVRISP mkII, JTAGICE mkII, AVR ONE!,
STK®
600, or QT600 read How to downgrade to use older Jungo drivers.
• AVRSV-6676: Launching debugging fails due to issue with Intel graphics driver.
Atmel Studio 7.0.594
Atmel Studio 7.0.594 resolves the following issues present in Atmel Studio 7.0.582:
• AVRSV-7008: Opening a 6.2 project in Atmel studio 7.0.582 persists Debug configuration settings
for all the other configurations.
• AVRSV-6983: Uninstalling Studio extensions does not work in some cases.
• AVRSV-7018: Project Creation fails with some culture specific user names.
• AVRSV-7019: Help Viewer does not work on 32-bit machines.
• Issues with getting tools/debuggers recognized or visible see section 2.4 in ‘Atmel Studio 7.0.594-
readme.pdf’ for workarounds.
Atmel Studio 7.0.582
• Updated to Visual Studio Isolated Shell 2015
• Integration with Atmel Start.
– This tool will help you select and configure software components, drivers, middle-ware, and
example projects to tailor your embedded application in a usable and optimized manner
• New device support system, CMSIS Pack compliant
• Data Visualizer, used for processing and visualizing data
• Updated help system, improved context sensitive help
• Atmel Software Framework version 3.27.3. ASF is an extensive software library of software stacks
and examples.
• A major upgrade of the Visual Assist extension to Atmel Studio that assists with reading, writing, refactoring,
navigating code fast
• Import Arduino Sketch projects into Atmel Studio
• Support for Flip-compatible bootloaders in atprogram and programming dialogue. The connected
device appears as a tool.
• AVR 8-bit GCC Toolchain 3.5.0 with upstream versions1
:
– gcc 4.9.2
– Binutils 2.25
– avr-libc 1.8.0svn
– gdb 7.8
• AVR 32-bit GCC Toolchain 3.4.3 with upstream versions1
:
– gcc 4.4.7
– Binutils 2.23.1
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
10
– Newlib 1.16.0
• ARM GCC Toolchain 4.9.3 with upstream versions1
:
– gcc 4.9 (revision 221220)
– Binutils 2.24
– gdb 7.8.0.20150304-cvs
1.2.2. Atmel Studio 6.2 Service Pack 2
• Atmel Software Framework 3.21.0
• Added support for the ATSAML21 device family
• Added support for the ATSAMV7 device family, based on the ATM Cortex-M7 core
1.2.3. Atmel Studio 6.2 Service Pack 1
• Atmel Software Framework 3.19.0
• AVR 8-bit Toolchain 3.4.5 with upstream versions:
– GCC 4.8.1
– Binutils 2.41
– avr-libc 1.8.0svn
– gdb 7.8
• AVR 32-bit Toolchain 3.4.2 with upstream versions:
– GCC 4.4.7
– Binutils 2.23.1
• ARM GCC Toolchain 4.8.4 with upstream versions:
– GCC 4.8.4
– Binutils 2.23.1
– gdb 7.8
• Support for trace buffers for ARM (MTB) and 32-bit AVR UC3 (NanoTrace)
• Support for attaching to targets
1.2.4. Atmel Studio 6.2
• Atmel Software Framework 3.17.0
• AVR 8-bit Toolchain 3.4.4 (with upstream GCC 4.8.1)
• AVR 32-bit Toolchain 3.4.2 (with upstream GCC 4.4.7)
• ARM GCC Toolchain 4.8.3
• Support for Atmel-ICE
• Support for Xplained Mini
• Support for data breakpoints
• Read OSCCAL calibration for tinyAVR®
and megaAVR®
• Create ELF production files for AVR 8-bit using the programming dialogue
• Live Watch
1 For more information, see the readme that is installed as part of the toolchain.
2 For more information, see the readme that is installed as part of the toolchain.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
11
• Non-intrusive trace support for SAM3 and SAM4 family of devices including
– Interrupt trace and monitoring
– Data trace
– FreeRTOS™
awareness
– Statistical code profiling
• Polled Data trace support for Cortex M0+
• Default debugger for SAM devices is now GDB. GDB does in some scenarios handle debugging of
optimized code better.
• Support to create a GCC Board project (Atmel board\User board) for ALL the installed versions of
ASF
• New ASF Board Wizard, to Add or Remove Board Project Template
• Improved loading time of New Example Project dialog, by loading only one ASF version by default
• IDR events now gets displayed in a separate pane in the output window
• LSS file syntax highlighting
1.2.5. Atmel Studio 6.1 Update 2
• Support for SAM D20 devices on the JTAGICE3
• Atmel Software Framework 3.11.0
1.2.6. Atmel Studio 6.1 Update 1.1
• Fix programming of boot section for XMEGA devices introduced in 6.1 update 1
• Fix SAM4LSP32 bare-bone project setup
1.2.7. Atmel Studio 6.1 Update 1
• Atmel Software Framework 3.9.1
• Extension Development Kit (XDK). Support for packaging an Embedded Application project into an
Atmel Gallery Extension.
• Support for SAM D20 and SAM4N devices
• ARM GCC Toolchain 4.7.3 with experimental newlib-nano and multilibs
1.2.8. Atmel Studio 6.1
• Support for Embedded Debugger platform
• Support for Xplained Pro kits
• Atmel Software Framework 3.8.0
• AVR 8-bit Toolchain 3.4.2 (with upstream GCC 4.7.2)
• AVR 32-bit Toolchain 3.4.2 (with upstream GCC 4.4.7)
• ARM GCC Toolchain 4.7.3
• CMSIS 3.20
• Updated Visual Assist
• Command line utility for firmware upgrade
• Stimulus for simulator. Create a stimuli file to write register values while executing simulation.
1.2.9. Atmel Studio 6.0
• Support for Atmel ARM-based MCUs with Atmel SAM-ICE
• Atmel Software Framework 3.1.3
• AVR Toolchain 3.4.0
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
12
• ARM Toolchain 3.3.1
• Atmel Software Framework Explorer
• Support for QTouch Composer as extension
• Updated Visual Assist
• New extension gallery
1.2.10. AVR Studio 5.1
• New version of AVR Software Framework (ASF)
• Availability and installation of new ASF versions through extension manager, without having to
upgrade Studio 5
• Support for side by side versioning of ASF, with the ability to upgrade projects
• Syntax highlighting and better debugging support for C++ projects
• Support for importing AVR 32 Studio C++ projects
• New version of AVR Toolchain
• New command line utility (atprogram) with support for all Atmel AVR tools and devices
• Enhancements to programming dialog including support for ELF programming
• New version of Visual Assist with several enhancements and bugfixes
1.3. Installation
Installation instructions.
Supported Operating Systems
• Windows 7 Service Pack 1 or higher
• Windows Server 2008 R2 Service Pack 1 or higher
• Windows 8 / 8.1
• Windows Server 2012 and Windows Server 2012 R2
• Windows 10
Supported Architectures
• 32-bit (x86)
• 64-bit (x64)
Hardware Requirements
• Computer that has a 1.6GHz or faster processor
• RAM
– 1GB RAM for x86
– 2GB RAM for x64
– An additional 512MB RAM if running in a Virtual Machine
• 6GB of available hard disk space
Downloading and Installing
• Download the latest Atmel Studio installer
• Atmel Studio can be run side by side with older versions of Atmel Studio and AVR Studio®
.
Uninstallation of previous versions is not required.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
13
• Verify the hardware and software requirements from the "System Requirements" section
• Make sure your user have local administrator privileges
• Save all your work before starting. The installation might prompt you to restart, if required.
• Disconnect all Atmel USB/Serial hardware devices
• Double click the installer executable file and follow the installation wizard
• Once finished, the installer displays an option to Start Atmel Studio after completion. If you
choose to open, then note that Atmel Studio will launch with administrative privileges, since the
installer was either launched as administrator or with elevated privileges.
1.4. Contact Information
Report any problems you experience with this version of Atmel Studio. We would also like to receive good
ideas and requests that can help to improve further development and releases of Atmel Studio.
Check out the Atmel Knowledge Base for any issues that you might encounter. From the same page, it is
possible to contact Atmel Support through the new support portal which is linked up with your myAtmel
account.
For the latest updates of Atmel Studio, visit the Atmel web site: www.atmel.com.
Reporting Bugs
Copy the information from the version dialog (see the figure below) and include it in the email to Atmel.
Also, make sure to provide a detailed description of the problem:
1. Describe how to recreate the problem.
2. Attach any test program that causes the problem.
3. Check that the copied version information contains used debug platform and device.
The version dialog is opened by the file menu Help → About Atmel Studio. Debug platform and device
are only displayed if you are in debug mode. Push the copy button to copy the contents to the clipboard.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
14
Figure 1-1. Atmel Studio About Box
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
15
2. Getting started
2.1. Starting Atmel Studio
Atmel Studio is started by clicking on the Atmel Studio 7.0 shortcut in the Start-up menu.
Once started, the start page is displayed. From within this page you can create new projects and reopen
recently used projects, as well as browse through articles providing tutorials, help and news.
The Start page can also be accessed from View → Start Page, or Alt V G .
Figure 2-1. The Project Related Section of the Start Page
The left section of the start page contains project-related items:
• New project - Use this to create a new project. If you are new to the concept of software
development with Atmel Studio, refer to the step-by-step guides. The project settings and available
options are described in detail in Project Management.
• New example project - To take a step-by-step tour of the available Atmel platforms' functionalities
using the Atmel Software Framework, click this button.
• Open project - Load an existing project, not mentioned on the Recent projects pane.
The Recent projects lists the most recently opened projects. Clicking on any of the links will open the
project, restoring it and the GUI to its last saved settings. You can select the number of projects you
would like to be shown in the Menus and Settings.
Discover Atmel Studio
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
16
This section contains links to helpful information about how to use Atmel Studio and related tools.
Announcements
In the Announcements section you can read the Atmel RSS feed or any other RSS feed. From the
Tools > Options... menu, select Start Page > Feeds to configure which RSS feeds that should be seen.
In order to turn ON or OFF the feeds, use the Show feeds check-box.
2.2. Creating a Project
2.2.1. Introduction
Atmel Studio is based on Visual Studio, and hence the application development process is organized into
projects and The Solution Container.
The following sections demonstrates how to create a new GCC C executable project and write a simple
application.
2.2.2. Creating a new Project
On the Start Page discussed in Getting started, click the New Project option.
Figure 2-2. Project Options
The project wizard appears.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
17
Figure 2-3. Project Wizard
About project types
Table 2-1. Project Types
Category Project templates Description
C/C++ GCC C ASF Board Project Select this template to create an AVR 8-bit or AVR/ARM 32-
bit ASF Board project.
C/C++ GCC C Executable Project Select this template to create an AVR 8-bit or AVR/ARM 32-
bit GCC project.
C/C++ GCC C Static Library
Project
Select this template to create an AVR 8-bit or AVR/ARM 32-
bit GCC static library(LIB) project.
C/C++ GCC C++ Executable
Project
Select this template to create an AVR 8-bit or AVR/ARM 32-
bit C++ project.
C/C++ GCC C++ Static Library
Project
Select this template to create an AVR 8-bit or AVR/ARM 32-
bit C++ static library (LIB) project.
Assembler Assembler Project Select this template to create an AVR 8-bit Assembler project.
Category Project Templates Description
Note:
Extensions and plugins to Atmel Studio may provide new project templates.
Create a project
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
18
1. In the New Project dialog box, select Installed Templates. This lists the available project types.
2. For this example, create an GCC C Executable Project.
3. In the Name box, type a name for the new project.
4. In the Location box, select a save location.
5. Atmel Studio will suggest a name in the Solution name box. You can override this name if wanted.
6. Leave the Create directory for solution checkbox checked.
7. Click OK.
2.2.3. Choosing a Target Device
When a new project is created, the Device Selection dialog is displayed and you will be prompted to
select the project target device.
Figure 2-4. Device Selection
The device selection dialog lists all supported devices for the current project type. To narrow down the
selection of devices, select the device family in the Device Family field, or use the Search for Device
field to view a filtered list of devices matching your search string.
Select a device
1. In the Device Selection dialog, select ATxmega128A1.
2. Click OK.
2.2.4. Writing and Compiling Code
Your solution and project has been created. You can now start editing your application.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
19
Figure 2-5. Code Editor
Atmel Studio automatically opens the newly created C file in the source editor. If the file is closed at any
time, double click on [Project_name].c - in this case GccApplication1.c - to open it in the editor.
At this time the C file contains only an include statement for I/O manipulation and a simple main()
function.
Create and build a simple application
1. Replace the original main function with the following source code:
#define MAXINT 200000
int main(void)
{
unsigned int t=1000, k=0, l=5, pn=2;
unsigned int primes[t];
primes[0]=2;
primes[1]=3;
while (pn < t || primes[pn] < MAXINT)
{
for ( k = 0; k <= pn; k++)
{
if (l % primes[k] == 0)
{
goto otog;
}
else
{
if (k == pn)
primes[pn++]=l;
}
}
otog:
l += 2;
}
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
20
return 0;
}
2. To compile the project, press F7 key or select Build Solution from the Build menu.
Atmel Studio now builds the application. All output from the compiler is listed in the output window.
This concludes the introduction to creating code projects in Atmel Studio. All aspects of projects are
described in detail in Project Management.
The next section will describe how to debug this application using the built-in simulator.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
21
3. Project Management
3.1. Introduction
Atmel Studio is an Integrated Development Environment (IDE) for writing and debugging applications for
AVR/ARM platforms. Currently as a code writing environment, it supports the included AVR Assembler
and any external AVRGCC/ARMGCC compiler in a complete IDE environment.
Using Atmel Studio as an IDE gives you several advantages:
1. Editing and debugging in the same application window allows for a faster error tracking.
2. Breakpoints are saved and restored between sessions, even if the code was edited in the
meantime.
3. Project item management is made convenient and portable.
3.1.1. The Solution Container
With AVR Studio 5, the concept of "solution" is introduced. The solution is a container that may contain
several projects. A project cannot exist outside a solution. If you try to open a project file ( .cproj
or .asmproj extension) a solution will be created for you. This allow you to keep for example a
bootloader project, and several application projects in the same solution. In practice the Solution is stored
as an .atsln file. In general, projects that are added to the solution are placed in a separate folder
inside the folder that the .atsln file recides in.
3.1.2. Save and Open Projects
All projects are saved under a chosen name with the .cproj extension for GCC projects and .asmproj
extension for 8-bit assembler projects. The user can reopen a project, either from the file menu, from the
recently used projects list, or from the Project menu, under Open project.
3.1.3. Project Output View
After building, assembling, or compiling the project, the operation result will be shown in the build output
window. If any errors occur, the user can double-click on the message, which will position the marker over
the corresponding line in the source window.
3.1.4. Solution Explorer
Solution Explorer allows you to view items and perform item management tasks in a solution or a project.
It also allows you to use the Atmel Studio editors to work on files outside the context of a solution or
project. By default it appears on the right side of the Atmel Studio GUI.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
22
Figure 3-1. The Solution Explorer Pane
3.1.5. Toolbar Icons
Buttons specific to the item selected in the tree view appear on the Solution Explorer.
•
Displays the appropriate property user interface for the selected item in the tree view.
•
Shows all project items, including those that have been excluded in the project and those that
are hidden.
3.1.6. Hierarchical Display
A single solution and all its projects appear in a hierarchical display. This allows you to work on several
projects at the same time and at the same time keep track of all projects and items. Most source control
system extensions (such as AnkhSVN) will also add icon overlays to the item icons, to signal the up-todate
status of the project items that are under revision control.
3.1.7. Item Management Commands
Solution Explorer supports a variety of management commands for each project or solution item. Right
click on any item to get a menu with the available commands for that particular item.
3.1.8. Project Components
A project will contain a set of device specific components. This includes startup code, linker scripts, and
other support libraries.
Components are small pieces of code or other supporting files that are included in any project.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
23
Figure 3-2. Project Components
Components that are included in a project are listed in the Component drop-down. Selecting a
component from the drop-down menu shows the component version, the files that the component is
contributing with, and the dependencies that the component has.
The version of the component can be changed by clicking the Change version button.
3.1.8.1. Change Version
Components are versioned when added to the project. To change the version that is used, use this dialog.
There are two options when choosing the version of a component
Use a specific version Lock the project to a specific version of the component.
Use the latest version Choose the most recent version of the component that is available.
Figure 3-3. Change Version
Components are part of the device packs in Atmel Studio. These device packs are managed using the
Device Pack Manager.
Related Links
Device Pack Manager on page 146
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
24
3.2. GCC Projects
3.2.1. New Project Wizard
Select File → New from the menu, and the dialog below will appear. The startup wizard will also have an
option to start a new project.
Figure 3-4. New Project
Project types
Currently several project types are available in the Project Type box. AVR board examples - to guide you
through the usage of the AVR boards, User board project - if you have created your own product with the
AVR tools, and a general AVR GCC project - a board independent project with a GNU compiler. It is also
possible to create an AVR Assembler project and a general AVR Solution, which may include any
supported source code type.
Tip:
Projects can also be created by loading supported object files. If you want to create such a
project, you should use the File → Open file menu.
Project name and initial file
Input the project name. The project main file, which is generated automatically, will be named with the
same name by default (ASM or C). If you wish, you can change this name. It is possible to check a box to
create a new folder, bearing the project name. This box is unchecked by default.
You can choose to create a new solution in the Solution drop-down menu, or to reuse existing code.
Input the solution name in the Solution Name field.
If you are satisfied with the project name and type, press OK and proceed to the debugging platform
selection stage. You can also leave the platform undefined for now, but then the you will have to select
the debug platform and device upon starting a debug session. See also Assembler Projects, Object File
Formats
3.2.2. Starting a New GCC Project for AVR Device
1. Create a new project by selecting New Project from the Project menu. This will open the Project
Wizard.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
25
2. Select C/C++→GCC C Executable Project as a template, then specify a project name, select a
location, and write a solution name for the project. A file with the same name as the project will be
created and added to the project by default. It will contain an empty main() function. If you want to
change the name of the initial file, just edit the main file name afterward. Press OK when you are
satisfied with the settings.
3. Select C/C++→GCC C Static Library Project as a template, then specify a project name, select a
location, and write a solution name for the project. This creates a Static Library (LIB) project, which
is a good way to reuse code.
Tip:
See section Starting a New GCC Static Library Project to learn more about Static Library
projects.
4. A device selection table will appear. Choose the appropriate target platform for your project. To start
you can select the ATxmega128A1 device.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
26
Figure 3-5. Device Selection
5. The project tree will be set up. Notice that the initial file created in step 2 has been added to the
project node. Also, the initial file will be opened in the editor.
6. In order to facilitate applications development and verification you can also use the Driver Selection
Wizard, invoked from Project → ASF Wizard...
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
27
In the ASF Wizard you can select which Drivers, Components, and Services you would like to use
in the project for current build architecture and board.
7. Now, write the following code into the open editor window.
#define MAXINT 200000
int main(void)
{
unsigned int t=1000, k=0, l=5, pn=2;
unsigned int primes[t];
primes[0]=2;
primes[1]=3;
while (pn < t || primes[pn] < MAXINT)
{
for ( k = 0; k <= pn; k++)
{
if (l % primes[k] == 0)
{
goto otog;
}
else
{
if (k == pn)
primes[pn++]=l;
}
}
otog:
l += 2;
}
return 0;
}
8. Build the project.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
28
Figure 3-6. View of a GCC Project after Build Completed
Dependencies
All the included files are listed here. Double click on any file to open it in the editor.
Output Files
All output files will be displayed below this item.
Libraries
All Static Library files, Toolchain Library, and other Library Files will be displayed below this item.
Tip:
See section Library Options to know more about Library options.
3.2.3. Libraries Options
All Static Library files, Toolchain Library, and other Library Files will be displayed below this item.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
29
Figure 3-7. Libraries
3.2.3.1. Toolchain Libraries
The toolchain libraries would be listed here.
The Library search path provided by the toolchain would be enumerated to form the library list.
3.2.3.2. Project Libraries
The projects available at the current Solution would be enumerated and the static libraries would be listed
here.
3.2.3.3. Browse Libraries
You can browse for other libraries.
3.2.3.4. How to Add Project Library
Tip:
Ensure you have static library projects in the current solution.
Right click on Project or Libraries Node in the project to invoke "Add Library" Wizard.
Select Project Libraries Tab; here would see the all the static libraries in current solution listed.
Select the Static Library which you would like to add.
Click OK.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
30
Figure 3-8. View of a Project after Adding Libraries
Also you will see that at Project → Project Dependencies Static Library added.
Figure 3-9. View of a Project Dependencies after Adding Libraries
3.2.3.5. How to Add Toolchain Library
Right click on Project or Libraries Node in the project to invoke "Add Library" Wizard.
Select Toolchain Libraries Tab; here you will see the available toolchain libraries for the currently selected
toolchain for project.
Select the libraries which you like to add.
Click OK.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
31
Figure 3-10. View of a Project after Adding Libraries
You will also be able to see the new library added in the Toolchain Linker Settings.
Figure 3-11. View of a Linker Option after Adding Libraries
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
32
3.2.4. Starting a New GCC Project for SAM (ARM) Device
1. Create a new project by selecting New Project from the Project menu. This will open the Project
Wizard.
2. Select C/C++ → GCC C Executable Project as a template, then specify a project name, select a
location, and write a solution name for the project. Some start-up files will be added to the project
by default, which will contain some device specific functions and libraries. Press OK when you are
satisfied with the settings.
3. Select C/C++ → GCC C Static Library Project as a template, then specify a project name, select
a location, and write a solution name for the project. This creates a Static Library (LIB) project,
which is a good way to reuse code.
Tip:
See section Static Library Project to learn more about Static Library projects.
4. A device selection table will appear. Choose the device family as SAM3 or SAM4 and select the
target platform for your project. To start you can select the ATSAM3S1A device.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
33
5. The project tree will be set up. Notice that the initial files created in step 2 has been added to the
project node. Also, the file containing main() function will be opened in the editor.
Here is a list of files that will be created:
– A file with the same name as the project will be created and added to the project by default. It
will contain the main() function.
– A startup file(startup_*.c) will be available at "cmsis\src" directory. It contains the default
interrupt handlers for all the peripherals.
– A system file(system_*.c) available at "cmsis\src" provides the system level initialization
functions that are called on start-up
– Linker scripts with appropriate sections based on the device will be created at "cmsis
\LinkerScripts" directory in the project folder
– In case if you have deleted any files in cmsis folder and want to revert it back or if you have
changed the device, just right click the Project and click "CMSIS Update from Atmel" to get
the appropriate files.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
34
Note: It is recommended not to change the contents of the startup_*.c and system_*.c files unless
you have no other choice. These startup, system, and linker scripts will not be created for ARM
static library projects.
6. In order to facilitate applications development and verification you can also use the Driver Selection
Wizard, invoked from Project → ASF Wizard.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
35
In the ASF Wizard you can select which Drivers, Components, and Services you would like to use
in the project for current build architecture and board.
7. Now, write the following code into the open editor window:
#define MAXINT 200000
int main(void)
{
unsigned int t=1000, k=0, l=5, pn=2;
unsigned int primes[t];
primes[0]=2;
primes[1]=3;
while (pn < t || primes[pn] < MAXINT)
{
for ( k = 0; k <= pn; k++)
{
if (l % primes[k] == 0)
{
goto otog;
}
else
{
if (k == pn)
primes[pn++]=l;
}
}
otog:
l += 2;
}
return 0;
}
8. Build the project.
3.2.5. Code Editing
For the following part of the introduction we will reuse the same code as you have previously seen.
#define MAXINT 200000
int main(void)
{
unsigned int t=1000, k=0, l=5, pn=2;
unsigned int primes[t];
primes[0]=2;
primes[1]=3;
while (pn < t || primes[pn] < MAXINT)
{
for ( k = 0; k <= pn; k++)
{
if (l % primes[k] == 0)
{
goto otog;
}
else
{
if (k == pn)
primes[pn++]=l;
}
}
otog:
l += 2;
}
return 0;
}
Atmel Studio has a rich editor that is made even richer by Atmel and third-party plugins. Atmel Studio has
an automatic code generation faculty for snippets of C source code. To use it select and right click the
part of the code you wish to enclose in a conditional structure (like for,while,if … etc).
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
36
Using the code snippets you can add parts to your core source. In some snippets the variable names and
exit conditions are parametric within the IDE, so as if only one instance is changed all instances within the
snippet will also change, such is the case of for loop.
Table 3-1. Using "Surround With"
⇒ ⇒
3.2.6. Starting a New GCC Static Library Project
3.2.6.1. Why Static Libraries
Static Libraries (LIB) is a good way to reuse code. Rather than re-creating the same routines/functions in
all the programs, the user can write them once and reference from the applications that need the
functionality.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
37
3.2.6.2. Create New Static Library Project
Figure 3-12. New Static Library Project
Click OK to create the Static Library project. A default source file with the same name as the project will
be added to the solution. You may then write and compile your routines/functions. You can also add new
source files or header files into the project.
Open the Project Properties on the menu Project → "Your_project_name Properties". This menu item
is only available when a Static Library project is open. Select the Build property page. Here you will see
that the Artifact Type is selected as Static Library.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
38
Figure 3-13. Static Library Build Properties
Compile the project by selecting Build Solution from the Build menu. This creates a Static Library, which
can be used by other programs.
3.2.6.3. Static Library Project Options (AVR/GNU Archiver)
The AVR/GNU archiver, avr-ar, combines a collection of object files into a single archive file, also known
as a library.
Open the Project Properties on the menu Project → "Your_project_name Properties". This menu item
is only available when a Static Library project is open. In order to configure Static Library options, click on
the Toolchain property tab.
In the Toolchain property page, you will see AVR/GNU Archiver active and enabled. You may also see
that the AVR/GNU Linker is disabled for a static library project.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
39
Figure 3-14. AVR/GNU Archiver Setup Dialog, Command Line Shown
You can set the AVR/GNU Archiver flags at the Archiver Flags textbox in the above General options.
Now, save the project and compile by selecting Build Solution from the Build menu.
3.2.7. GCC Project Options and Configuration
Project options and configuration can be set up by either right clicking on the Solution Explorer → Project
Properties, or by pressing Alt Enter .
This will call up the Project properties window, it has seven tabs:
If a tab supports properties that are configuration specific, then the tab has two slide-down menus: The
Configuration field defines the project configurations to modify. By default, two configurations are
provided in each project - Debug and Release. The Platform field is set to AVR. If a tab supports
configuration independent properties, then the Configuration and Platform fields are disabled.
Note: Use the "Save All ( Ctrl Shift S )" from the File menu or toolbar to update the changes in the
project file whenever changes are made.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
40
3.2.7.1. Build Options
Figure 3-15. Build Configuration
In the Build tab page, you can configure whether you want to use an external Makefile for your project. In
that case, just tick the Use External Makefile check box and browse to select the correct path of make
file.
Build Commandline will be provided to the external makefile when build is invoked for the project. The
default build target is "all".
Clean Commandline will be provided to the external makefile when clean is invoked for the project. The
default clean target is "clean".
Besides the external make file configuration, you can also specify the type of application to build. The
options are Executable or Static Library, which can be selected using the Artifact Type combo box.
Note: Custom makefile must fulfill those conditions:
1. Target name must equal project name.
2. Makefile and target must exist in the same folder (can be referenced with NTFS links too).
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
41
3.2.7.2. Build Events
Figure 3-16. Build Events Options
The Build events tab contains a list of scheduled events for each configuration, launched by the prebuild
and post-build scripts. These events can be added, deleted, or modified by clicking either the Edit
pre-build... or Edit post-build... buttons. Upon clicking these buttons, you should manually add your
commands in the following dialog. As of the current release it is possible to use environment variables
and values declared within them as a link with other available applications. In order to use that function
press the Show Macros button.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
42
Figure 3-17. Build Event Editor
Macros
Expands the edit box to display the list of macros/environment variables to insert in the command line edit
box.
Macro Table
List the available macros/environment variables and its value. You can select only one macro at a time to
insert into the command line edit box. MSBuild also provides a set of reserved properties that store
information about the project file and the MSBuild binaries. These properties may also be listed in the edit
box.
See Macros/environment variables below for a description which are specific to Atmel Studio.
Table 3-2. Atmel Studio Build Macro Table
Macro Description
$(AVRSTUDIO_EXE_PATH) The installation directory of Atmel Studio (defined with drive and path)
$(SolutionDir) The directory of the solution (defined with drive and path)
$(SolutionPath) The absolute path name of the solution (defined with drive, path, base
name, and file extension)
$(SolutionFileName) The file name of the solution
$(SolutionName) The base name of the solution
$(SolutionExt) The file extension of the solution. It includes the '.' before the file
extension.
$(Configuration) The name of the current project configuration, for example, "Debug"
$(Platform) The name of the currently targeted platform, for example, "AVR"
$(DevEnvDir) The installation directory of Atmel Studio (defined with drive and path)
$(ProjectVersion) The version of the project
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
43
Macro Description
$(ProjectGuid) A unique identifier of the project
$(avrdevice) The name of the currently selected device
$(avrdeviceseries) The series of the selected device. Used internally by the Atmel Studio.
$(OutputType) Defines if the current project is an Executable or a Static Library type
$(Language) Language of the current project; for example, C, CPP, or Assembler
$(OutputFileName) The file name of the primary output file for the build (defined as base file
name)
$(OutputFileExtension) The file extension of the primary output file for the build. It includes the '.'
before the file extension
$(OutputDirectory) The absolute path of the output file directory
$(AssemblyName) The assembly name of the primary output for the build
$(Name) The base name of the project
$(RootNamespace) The base name of the project
$(ToolchainName) The name of the toolchain
$(ToolchainFlavour) The name of the toolchain's compiler
Macro Description
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
44
3.2.7.3. Compiler and Toolchain Options
Figure 3-18. Compiler and Toolchain Options
AVR GNU C Compiler Options
Table 3-3. AVR GNU C compiler Options
Option Description
General options
-mcall-prologues Use subroutines for functions prologues and epilogues
-mno-interrupts Change stack pointer without disabling interrupts
-funsigned-char Default char type is unsigned
-funsigned-bitfield Default bit field is unsigned
Preprocessor options
-nostdinc Do not search system directories
-F Preprocess only
Symbols options
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
45
Option Description
There one can define (-D) or undefine (-U) a number of in-source symbols. New symbol declarations
can be added, modified, or reordered, using the interface buttons below:
•
Add a new symbol. This and all following icons are reused with the same meaning in other
parts of Atmel Studio interface.
•
Remove a symbol.
•
Edit symbol.
•
Move the symbol up in the parsing order.
•
Move the symbol down in the parsing order.
Include directories
Contains all the included header and definition directories, can be modified, using the same interface as
symbols.
Optimization options
Optimization level (drop down menu): -O0, -
O1, -O2, -O3, -Os
No optimization, optimize for speed (level 1 - 3),
optimize for size
Other optimization flags (manual input form) Here you should write optimization flags specific for the
platform and your requirements
-ffunction-sections Prepare functions for garbage collection, if a function is
never used, its memory will be scrapped
-fpack-struct Pack structure members together
-fshort-enums Allocate only as many bytes needed by the enumerated
types
-mshort-calls Use rjmp/rcall limited range instructions on the >8K
devices
Debug options
Debug level (drop down menu): none, -g1, -
g2, -g3
Specifies the level of tracing and debugging code and
headers left or inserted in the source code
Other debug options (form field) Architecture specific debug options
Warning messages output options
-Wall All warnings
-Werror Escalate warnings to errors
-fsyntax-only Check syntax only
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
46
Option Description
-pedantic Check conformity to GNU, raise warnings on nonstandard
programming practice
-pedantic-errors Same as above, plus escalate warnings to errors
Miscellaneous options
Other flags (form field) Input other project-specific flags
-v Verbose
-ansi Support ANSI programs
-save-temps Do not delete temporary files
Option Description
AVR GCC Linker Options
Table 3-4. AVR GCC Linker Options
Option Description
-Wl -nostartfiles Do not use standard files
-Wl -nodefault Do not use default libraries
-Wl -nostdlib No start-up or default libraries
-Wl -s Omit all symbol information
-Wl -static Link statically
Libraries options
Libraries -Wl, -l (form field) You can add, prioritize, or edit library names here, using these
buttons: , , , ,
Library search path -Wl,-L (form field) You can add, prioritize or edit path where the linker will search for
dynamically linked libraries, same interface as above
Optimization options
-Wl, -gc-sections Garbage collect unused sections
--rodata-writable Put read-only data in writable spaces
-mrelax Relax branches
Miscellaneous options
Other linker flags (form field) Input other project-specific flags
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
47
AVR Assembler Options
Table 3-5. AVR Assembler Options
Option Description
Optimization options
Assembler flags (form field) Miscellaneous assembler flags
Include path (form field) You can add, prioritize or edit path to the architecture
and platform specific included files here
-v Announce version in the assembler output
Debugging options
Debugging level (drop down menu) -Wa -g1, -
Wa, -g2, -Wa, -g3
Defines a level of debugging symbol and debugging
source insertion
3.2.7.4. Device Options
This tab allows you to select and change the device for the current project and is similar to the device
selector, see Figure 3-5.
Tip:
Click on the Device button on the Device and Debugger toolbar to get to this tab quickly while
editing.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
48
3.2.7.5. Tool Options
This tab allows you to select and change the debugger platform for the current project.
Tip:
Click on the Device button on the Device and Debugger toolbar to get to this tab quickly while
editing.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
49
Select tool/debugger from the drop-down list. Current selection is shown.
Select Interface from the drop-down list. Current selection is shown.
Note: Only tools and interfaces valid for the current device selection are shown.
Further Properties are dependent on tool and interface selected.
JTAG
If you have selected JTAG as the programming interface, clock speed, use external reset - and daisy
chain setting may be available. This depends on the tool and device.
JTAG clock
JTAG clock is the maximum speed the tool will try to clock the device at. The clock range is different for
different tools and devices. If there are restrictions, they will be stated in a message below the clock
slider.
Clock can be set to Manual (all tools), Auto (SAM-ICE only), or Adaptive (SAM-ICE only).
Use external reset
If checked, the tool will pull the external reset line low when trying to connect to the device.
JTAG daisy chain settings
Specify the JTAG daisy chain settings relevant to the device to program.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
50
Target is not part of a daisy chain. Select this option when the target device is not part of a daisy chain.
Daisy chain - Manual. Allows you to manually configure the JTAG daisy chain in case you are
programming in a system-on-board.
• Devices before - specifies the number of devices preceding the target device.
• Instruction bits before - specifies the total size of the instruction registers of all devices, preceding
the target device.
• Devices after - specifies the number of devices following the target device.
• Instruction bits after - specifies the total size of the instruction registers of all devices, following
the target device.
Daisy chain-Auto. Automatically detects the devices in the JTAG daisy chain. Allows you to select the
device in the JTAG daisy chain. Auto-detection is supported only for SAM devices.
PDI
The PDI interface has only one setting – the PDI clock speed.
PDI Clock is the maximum speed the tool will try to clock the device at. The clock range is different for
different tools and devices. If there are restrictions, they will be stated in a message below the clock
slider.
The clock can not be adjusted on all tools, so an empty Interface settings page will be presented.
Programming and debug settings
In the drop-down menu it is possible to specify which parts of memory that should be erased during a
programming/debug cycle.
• Skip programming - specifies that no programming should occur. The tool will try to attach to the
program already in memory.
• Erase only program area - specifies that only the program area of memory should be erased.
• Erase entire chip - specifies that the entire chip is to be erased.
The "Preserve Eeprom" option lets you decide whether EEPROM data should be written when launching
a debug session. When this checkbox is checked, EEPROM data in the object file will be written to the
device at the start of each debug session. The EESAVE fuse will be set and cleared accordingly.
When a device is programmed at the start of a debug session, the default behavior is to erase the content
of the device (chip erase, if available). This can be changed by selecting a different option from the drop
down box under "Programming settings".
Keep timers running in stop mode
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
51
When checked, the timers set in the program will continue to run even when the program breaks at
breakpoint or is halted
This setting is only enabled for certain tool/interfaces.
Override Vector Table Offset Register
At reset, load PC and SP from the specified address.
Note: The tool you select on this page is also used with the command Start without Debugging. That
is why you also can select tools that do not have debugging capabilities. See Start without Debugging for
more information.
3.2.7.6. Advanced Options
Setting ToolchainFlavour
This section allows you to set the flavour of the toolchain for the current project. Default flavour of the
respective toolchain is selected. The toolchain path configured in the flavour is used for building the
projects. For configuring and adding new flavours Toolchain.
Use GDB
This section allows you to select whether GDB has to be used for the current project. The Current GDB
Path will be computed by the following
1. The Current GDB Path is taken from 'Tools → Options → Debugger → GDB Settings if configured
GDB Settings.
2. Otherwise it is taken from selected Toolchain Flavor if GDB is found there.
The Current GDB Path will be overridden when we use the option "Override Current GDB Path" in the
"Advanced" project property page.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
52
Note: The option "Use GDB" is enabled by default for ARM based devices and also the following
warning will be shown for AVR 32-bit devices if GDB is enabled.
3.2.7.7. Creating ELF Files with Other Memory Types
ELF files that contains data for all memory types can be made with the GCC compiler. The data sections
are specified in code as shown in following code examples.
Creating ELF Files for tinyAVR, megaAVR, and XMEGA devices
This code shows how to add memory sections for tinyAVR, megaAVR, and XMEGA devices (except
ATtiny4/5/9/10) . This example is for an ATxmega128A1 device. For other devices, it has to be modified
accordingly.
#include
// Example data for ATxmega128A1
const char eeprdata[] __attribute__ ((section (".eeprom"))) =
"Hello EEPROM";
// The order of the fuse values is from low to high. 0xA2 is written to Fuse byte 0, 0x00 to
byte 1...
const uint8_t fusedata[] __attribute__ ((section (".fuse"))) =
{0xA2, 0x00, 0xFF, 0xFF, 0xFF, 0xF5};
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
53
const uint8_t lockbits[] __attribute__ ((section (".lockbits"))) =
{0xFC};
const char userdata[] __attribute__ ((section (".user_signatures"))) =
"Hello User Signatures";
// Remember to set the following Toolchain project options,
// under AVR/GNU -> Miscellaneous:
//
// -Wl,--section-start,.user_signatures=0x00850000
int main(void)
{
while(1)
{
// TODO:: Please write your application code
}
}
Linker setup for User Signature section
The User Signatures section must have a specific Linker Setup, as shown below. This is necessary to get
the correct address offset for the user signature section in the elf file. Other memory sections gets the
correct address automatically.
Figure 3-19. Linker Setup for User Signature Section
Creating ELF Files for ATtiny4/5/9/10
This code shows how to add memory sections for ATtiny10.
#include
typedef struct _tagConfig
{
unsigned char f1;
} Config;
typedef struct _tagLock
{
unsigned char f1;
} Lock;
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
54
typedef struct _tagSig
{
unsigned char f1;
unsigned char f2;
unsigned char f3;
} Signature;
Config __config __attribute__((section(".config"))) =
{
f1 : 0xfb, // Set CKOUT
};
Lock __lock __attribute__((section(".lock"))) =
{
f1 : 0xfc, // Further programming and verification disabled
};
Signature __sig __attribute__((section(".signature"))) =
{
f1 : 0x03,
f2 : 0x90,
f3 : 0x1e,
};
int main(void)
{
while(1)
{
// TODO:: Write your application code
}
}
Creating ELF Files for UC3
The example below shows how to add data for the user page in UC3 devices.
#include
const char userdata[] __attribute__((section(".userpage"))) = "Hello Page";
int main(void)
{
while(1)
{
//TODO:: Write your application code
}
}
Project Properties
If the memory sections are defined but not referenced in the application code, the "Garbage collect
unused sections" option in Project Properties → Linker → Optimization must be unchecked. Otherwise
the linker will not include the sections in the .elf file.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
55
Figure 3-20. Project Properties
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
56
3.3. Assembler Projects
3.3.1. Create New Assembler Project
Figure 3-21. New Assembler Project
After pressing OK, you are asked to select your microcontroller.
You can try out the Assembler build and code debugging, using a simple LED-chaser code, given below.
It should fit any AVR 8-bit microcontroller, simply change the port (in this case E) to your hardware.
start:
nop
ldi R16, 0xff
sts PORTE_DIR, r16
ldi r17, 0x80
output:
sts PORTE_OUT, r17
rol r17
ldi r16, 0x00
delay:
ldi r18, 0x00
delay1:
inc r18
brne delay1
inc r16
brne delay
break
rjmp output
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
57
When a new project is created or an old project is loaded, the project view will be displayed with all the
project files. Files can be added, created, or removed from the project list using the context menu in the
Solution explorer window.
Figure 3-22. View of an Assembler Project
All the source files will be listed at the end of the list. Double click on any file to open it in the editor.
All custom include files will be listed directly under the project name item, unless you create a new folder
in the project.
Figure 3-23. View of an Assembler Project after Build Completed
Dependencies: All include files are listed here. Double click on any file to open it in the editor.
Labels: All labels in your assembler program are listed here. Double click on any item to show its location
in the source. A marker will point to the correct line.
Output Files: All output files will be displayed below this item.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
58
Figure 3-24. File Context Menu
Table 3-6. File Context Menu
Menu text Shortcut Description
Open Right click O Open the selected file
Open With... Right click n Open selected file with another editor or tool
Cut Ctrl X Cut the file from current category
Copy Ctrl C Copy the file from current category
Remove DEL Remove the selected file from the project
Rename F2 Rename the selected file
Set As EntryFile Set the selected file as entry file
Properties Alt ENTER Current file properties
Menu text Shortcut Description
All the interface views are docked by default. You can switch between docked and undocked views by
dragging windows around to a desirable location, or by dragging and dropping a window on a quick
docking menu of the Visual Studio IDE. The quick docking menu will appear every time you start dragging
an interface view or window.
3.3.1.1. Project Context Menu
Several build commands are available from the menu and the toolbars. There is also a context menu for
the project:
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
59
Figure 3-25. Project Context Menu
Table 3-7. Project Context Menu
Menu text Shortcut Description
Build Right click+u Build the selected project
Rebuild Right click e Will clean the project and build it
Clean Right click n Clean up and erase artifacts
Add Ctrl Shift A / Shift Alt A (existing
item)
Add new files or existing files to the project
Set as StartUp
Project
Right click + a Will set up to automatically open current
project at start up
Cut Ctrl X Cut project to paste it as a sub-project to
another solution
Remove Del Remove project or sub-project under cursor
Rename F2 Rename current project
Unload Project Right click l Unload active project files from the IDE
Properties Alt Enter Project properties
3.3.2. Assembler Options
Open the options window on the menu Project → "Your_project_name Properties". This menu item is
only available when an assembler project is open. After opening the Project properties window, you will
see six tabs, in order to configure assembler options click on the Toolchain.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
60
Figure 3-26. Assembler Setup Dialog, Command Line Shown
Figure 3-27. Assembler Setup Dialog, General Options Shown
3.3.2.1. Description of the Various Settings
Configuration menu allows to choose which stages of project maturity are going to be affected by the
modifications to the project properties. By default Debug is the initial stage and initially active
configuration. Following options are available:
1. Debug.
2. Release.
3. All configurations.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
61
Platform menu shows compatible target platforms available for prototyping.
Hex Output format The following file formats can be selected as additional output format:
1. Intel Hex.
2. Generic Hex.
3. Motorola Hex (S-record).
Wrap relative jumps The AVR RJMP/RCALL instructions allow a 12-bit PC-relative offset, corresponding
to ±2k words. For devices having 4k words (8kB) or less FLASH program memory, the Wrap option
causes the assembler's offset calculation to wrap around over the addressable program memory range,
enabling the entire program memory to be addressed using these instructions.
For devices with more than 4k words of program memory, using this option may cause unpredictable
results and it should be turned OFF. If it is left ON, the assembler will produce a warning when wrap takes
effect:
Attention:
Wrap rjmp/rcall illegal for device > 4k words - Turn off wrap option and use jmp/call.
This diagnostic is given as a warning and not an error to retain compatibility with earlier versions of the
assembler, but should be treated as an error by the user. The JMP/CALL 2-word instructions take 22-bit
absolute addresses and should be used instead.
Unsupported Instructions. By default, this option is set to give a warning when the assembler finds
unsupported instructions for the actual device. Optionally, you can output an error.
Include Paths (-I). Additional include paths can be set here, when using third party modules or your own
IP. Assembler's default include path:\Atmel\AVR Tools\AvrAssembler2\Appnotes.
Other optimization flags can be set to tailor optimization to your specific needs, see Assembler help for
more information.
3.4. Import of Projects
3.4.1. Introduction
Atmel Studio allow import of projects from several pre-existing project sources. This section details how to
import existing projects.
3.4.2. Import AVR Studio 4 Project
Click the menu File → Import → AVR Studio 4 Project.. or Ctrl+4.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
62
An Import AVR Studio 4 Project dialog will appear.
Type the name of your project or browse to the project location by clicking the Browse button of the APS
File location Tab.
Atmel Studio will proceed with conversion also updates the progress, warnings, and errors. They will be
shown in the Summary window.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
63
Check Show conversion log after this page is closed to view the complete conversion log.
Click Finish to access your newly converted project.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
64
Note: Currently, conversion only adds a project file and solution file if the Solution Folder is the same as
the APS File Location. No other files will be modified.
3.4.3. Import AVR 32 Studio Project
Click the menu File → Import → AVR Studio 32 Project.. or Ctrl+3.
An "Import AVR Studio 32 Project" dialog will appear.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
65
Type the name of your workspace or browse to the workspace location by clicking the ... (Browse button)
of the Workspace Tab. Click Find Projects to find all the project files and populate other folders available
in the workspace.
The Available AVR32 C/C++ Projects tab will be populated with all AVR32 C/C++ Projects that can be
imported and it will also display total number of available projects.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
66
The Invalid AVR32 Projects tab will be populated with all Unsupported AVR32 Projects that can not be
imported and it will also display total number of non convertible projects along with reason.
Atmel Studio will proceed with conversion also updates the progress, warnings, and errors. They will be
shown in the Summary window.
Check "Show conversion log after this page is closed" to view the complete conversion log.
Click Finish to access your newly converted project.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
67
Note:
• The current version of AVR32 Importer supports AVR32 C/C++ Projects
• AP7 device family is currently not supported by Atmel Studio
• Currently, conversion only adds project files and solution file if the Solution Folder is the same as
the Workspace folder. No other files will be modified.
• Pre/Post builds settings are not imported
• Automatically generate listing (*.lss) files setting is not imported
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
68
3.4.4. Import Project Template
A number of predefined project can be imported to Atmel Studio by File → Import → Project
Template..or Ctrl+T
These templates provide a starting point to begin creating new projects or expanding current projects.
Project templates provide the basic files needed for a particular project type, include standard assembly
references, and set default project properties and compiler options.
In the " Import Project Template " window specify the following:
• Specify the location of your project template
• Specify the save location. The combo box will show installed templates that are available in the
New Project → Installed Templates.
Select any template under which you would like to add your template. You can also add your
template at the root by selecting in "Add to folder".
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
69
• You can create a separate folder by specifying the name of the folder under the specified "Add to
Folder (Optional)", where you want to add your project template.
The resulting project template will be added to the existing installed templates and can be accessed from
File → New → Project .. or Ctrl+Shift+N.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
70
Note: "Import Project Template Importer" will work with template created for the same version.
3.5. Debug Object File in Atmel Studio
3.5.1. Introduction
Debug session requires you to load an object file which is supported by Atmel Studio. The debug file
contains symbolic information for debugging.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
71
3.5.2. Atmel Studio Supported Debug Formats
Table 3-8. Object File Formats Supported by Atmel Studio
Object file
format
Extension Description
UBROF .d90 UBROF is an IAR proprietary format. The debug output file contains a
complete set of debug information and symbols to support all type of
watches. UBROF8 and earlier versions are supported. This is the default
output format of IAR EW 2.29 and earlier versions. See below how to force
IAR EW 3.10 and later versions to generate UBROF8.
ELF/DWARF .elf ELF/DWARF debug information is an open standard. The debug format
supports a complete set of debug information and symbols to support all
type of watches. The version of the format read by Atmel Studio is
DWARF2. AVR-GCC versions configured for DWARF2 output can
generate this format.
AVRCOFF .cof COFF is an open standard intended for 3rd party vendors creating
extensions or tools supported by the Atmel Studio.
AVR Assembler
format
.obj The AVR assembler output file format contains source file info for source
stepping. It is an Atmel internal format only. The .map file are
automatically parsed to get some watch information.
Before debugging, make sure you have set up your compiler/assembler to generate a debug file like one
of the formats above. 3rd party compiler vendors should output the ELF/DWARF object file format.
3.5.3. Opening Object Debug File in Atmel Studio
Steps to create an Object Project
• On the File menu, click Open, and then click Open Object File For Debugging.
Open Object File For Debugging wizard will appear.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
72
• – In the Select the object file to debug, select your object file to debug. The object file must
be supported by Atmel Studio.
– In the Project Name, type a name for the project. Atmel Studio will suggest a name, which
you can override if wanted.
– In the Location, select a save location. Atmel Studio will suggest a name, which you can
override if wanted.
– Maintain Folder Hierarchy for Source Files option is selected by default which would create
a similar folder structure in the Solution Explorer as that of the source project i.e. the project
used to create the object file. Otherwise, all the files are added to the root folder of the project
file i.e. the user would not see any folder in the Solution explorer.
– Add File As Link option is selected by default in which the object project shall refer the files
from its original location without a local copy into the project directory. If the option is not
selected, Atmel Studio would copy the files into the object project directory.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
73
• Click Next. The Device Selection dialog will appear.
– Choose the appropriate target device. The target device should be the same, which was
originally chosen to create the object file.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
74
• Click Finish. The object project files re-mapper appears. In this particular dialog you need to remap
your original files of the project using, which the elf projects was created. If files are present at their
original place, it will show remapped already in dialog. If files are missing, you will have to remap it
manually. Check the screen shot below.
If the user resolves the parent folder for any original file, all other files in subsequent directory will
be remapped recursively. So, it is useful for the user to remap the number of files by just remapping
only one.
• Now the Object Project is Created. The files that are not remapped properly are shown in solution
explorer like "libgcc.S", with warning sign . Press F5 to debug this Project.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
75
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
76
4. Debugging
4.1. Introduction
Atmel Studio can be targeted towards the built-in Simulator, or a variety of tools (see Available Tools
View), for example AVR ONE!, JTAGICE mkII or JTAGICE3 (bought separately).
4.1.1. Debug Platform Independent Debug Environment
Independent of which debug platform is running, the Atmel Studio environment will appear identical.
When switching between debug platforms, all environment options are kept for the new platform. Some
platforms have unique features, and new functionality/windows will appear.
4.1.2. Differences Between Platforms
Although all debug platforms appear identical in the debug environment there will be small differences
between them. A real-time emulator will be significantly faster than the simulator for large projects. An
emulator will also allow debugging while the system is connected to the actual hardware environment,
while the simulator only allow predefined stimulus to be applied. In the simulator, all registers are always
potentially available for display, which might not be the case with an emulator.
4.2. Starting a Debug Session
To start a debug session and halt, press Alt+F5 or choose Debug → Start Debugging and Break from
the menu, alternatively, press the toolbar button as illustrated below:
Figure 4-1. Starting a Debug Session
To start a debug session and keep executing, press F5 or press the toolbar button with the continue
symbol, or choose Debug → Continue from the menu as illustrated below:
Figure 4-2. Starting a Debug Session
4.3. Ending a Debug Session
To end the debug session use the Stop Debugging button or keyboard shortcut Shift F5 .
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
77
4.4. Attaching to a Target
To attach a target, use the Attach to Target option in the Debug menu, or the attach icon in the
debug toolbar. This causes Atmel Studio to launch a debug session on the selected target without
uploading a new application or causing a reset. Once the debug session is established, the core of the
target is halted and the current execution position of the target is mapped to the code in the project. This
means that the state of the target is kept and is inspect-able with normal debug techniques, and the
program halts in the current position. Full run control and symbolic debugging should be available after a
successful attach.
Note:
• The code in the project is mapped to the content of the running target, without any possibility to
verify the correctness of this mapping. This means that if the project contains code that is not on the
target, then the state and run control might not reflect the truth, as variables and functions might
have different code locations on the target than in the project.
• The ability to activate a debug session without resetting a target is architecture dependent. Not all
architectures supports this feature.
Attention:
Physically connecting a debug probe to a target might cause the target to reset, as most debug
probes needs an electrical connection to the reset line of the device. Normal electrical
precautions needs to be taken to avoid this.
4.5. Start without Debugging
4.5.1. One Click Programming - Program and Run
The Start without Debugging command is a one-click alternative to the programming dialog. Execute it
by selecting Debug → Start without Debugging from the menu, or press the button on the toolbar.
Figure 4-3. Start without Debugging
This will build the solution (if any changes are made) and program the target device without starting a
debug session.
Start without Debugging uses the tool and interface settings specified in the project options. This is
different from what takes place when using the stand-alone Programming Dialog, which is not related to
the project at all.
Note: Programmers and starter kits can also be used with the Start without Debugging command, not
only debuggers.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
78
The Start without Debugging command will also program the EEPROM, fuses, lockbits, and user
signature (XMEGA only) segments if they are present in the object file. The GCC compiler can generate
ELF object format files with such segments. See Creating ELF Files with Other Memory Types for more
information.
Note: The user signature is not erased by Start without Debugging. The programmed user signature
from the ELF file will be AND-ed with the content in the device. If you want to replace the signatures with
what is in the file, you must perform a user signature erase manually.
4.5.2. Keyboard Shortcut
By default, there is no keyboard shortcut to this function, but you might want to add one if you use it a lot.
To add one, simply click the Tools → Options menu button and go to Environment → Keyboard. Start
typing startwithouttdebugging in the Show commands containing input field, and select
Debug.StartWithoutDebugging in the list. Then select the Press shortcut keys input field, and press
the desired key combination. You can for example press Ctrl+F5. Note that this shortcut is already
assigned to the BreakAll command. If you choose to override it, press the Assign button to assign the
new keyboard shortcut. Or, you can select an unused key combination.
Figure 4-4. Add Keyboard Shortcut
4.6. Debug Control
Several commands are available for controlling the debugger. They are available from both the Debug
menu and several toolbars. The Atmel Studio Integrated Development Environment (IDE) has two major
operating modes; design mode and debug mode. Design mode is when you are editing the source code
project, while debug mode is when you debug your project. The IDE adapts to modes, and menus an
toolbars changes.
Note: Some debug commands are available in design mode, some in debug mode.
• In design mode, the available debug commands are those that will start the debug session, e.g.
Start Debugging and Break, Start Debugging, Start without Debugging.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
79
• In debug mode, you will find commands like Break All, Step Out, and Reset.
Start Debugging and
Break
Starts the debugger, and breaks the execution on the first statement of the
program.
Start Debugging Starts the debugger, and runs the program. In debug mode and stopped, it
resumes execution.
Start Without
Debugging
Programs the project without starting debugging. For details, see Start without
Debugging.
Break All Halts the debugger.
Stop Debugging Stops and terminates the debug session, and returns to design mode.
Restart Restarts the debugger and reloads the program.
Reset Resets the program to the first statement.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
80
Disable debugWire
and Close
Available when debugging a device using the debugWire interface. The
command disables the debugWire interface (enabling the use of the ISP
interface) and terminates the debug session.
Step Into Executes one instruction. When in disassembly level, one assembly level
instruction is executed, otherwise one source level instruction is executed.
Step Over Similar to Step Into, Step Over executes one instruction. However, if the
instruction contains a function call/subroutine call, the function/subroutine is
executed as well. If a user breakpoint is encountered during Step Over,
execution is halted.
Step Out Continue execution until the current function has completed. If a user
breakpoint is encountered during Step Over, execution is halted. If a Step Out
command is issued when the program is on the top level, the program will
continue executing until it reaches a breakpoint or it is stopped by the user.
Quick Watch Adds a Quick Watch for the variable or expression under the cursor. For
details, see QuickWatch and Watches.
Toggle Breakpoint Toggle the breakpoint status for the instruction where the cursor is placed.
Note that this function is only available when the source window or
disassembly window is the active view.
New Breakpoint Create a new breakpoint at the location of the cursor. For more information,
see Breakpoints.
Disable All
Breakpoints
This function clears all set program breakpoints, including breakpoints which
have been disabled.
Clear All DataTips Clear all marked Data Tips. For more information, see DataTips.
Export Data Tips Save all marked Data Tips to a file in Visual Studio Shell format.
Import DataTips Load Data Tips from a Visual Studio Shell file.
Options and Settings Debug options and settings, see Debugger.
4.7. Breakpoints
4.7.1. General Information on Breakpoints
A breakpoint tells the debugger to temporarily suspend execution of a program when a specific condition
takes place, e.g. when a certain instruction is about to be executed.
Breakpoints provide a powerful tool that enables you to suspend execution where and when you need to.
Rather than stepping through your code line by line or instruction by instruction, you can allow your
program to run until it hits a breakpoint, and then start to debug. This speeds up the debugging process.
4.7.1.1. Breakpoint Glyphs
The source windows and the isassembly window show breakpoint locations by displaying symbols called
glyphs in the left margin. The following table describes these glyphs.
If you rest the mouse on a breakpoint glyph, a breakpoint tip appears with more information. This
information is especially useful for error and warning breakpoints.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
81
Table 4-1. Breakpoint Glyphs
Glyph Description
Normal breakpoint. The solid glyph indicates that the breakpoint is enabled. The hollow glyph
indicates that it is disabled.
Advanced breakpoint. Active/disabled. The + sign indicates that the breakpoint has at least one
advanced feature (such as condition, hit count, or filter) attached to it.
Breakpoint error. The X indicates that the breakpoint could not be set because of an error
condition.
Breakpoint warning. The exclamation mark indicates that a breakpoint could not be set because
of a temporary condition. Usually, this means that the code at the breakpoint or tracepoint
location has not been loaded. It can also be seen if you attach to a process and the symbols for
that process are not loaded. When the code or symbols are loaded, the breakpoint will be
enabled and the glyph will change.
4.7.2. Operations with Breakpoints
4.7.2.1. To Set a Breakpoint
1. In a source window, click a line of executable code where you want to set a breakpoint. On the
right-click menu, click Breakpoint, and then click Insert Breakpoint.
—or—
In a source window, click a line of executable code where you want to set a breakpoint.
On the Debug menu, click Toggle Breakpoint.
4.7.2.2. To Set an Address Breakpoint
1. On the Debug menu, point to Windows, and then click Disassembly if the Disassembly window is
not already visible. You need to be in a debug session for this option to be visible.
2. In the Disassembly window, click a line of code, and then click Toggle Breakpoint on the Debug
menu.
—or—
Right-click a line of code, and then select Insert Breakpoint .
4.7.2.3. To Edit a Breakpoint Location
1. In the Breakpoints window, right-click a breakpoint, then click Location on the right-click menu.
—or—
In a source, Disassembly, or Call Stack window, right-click a line that contains a breakpoint glyph,
and then click Location from Breakpoints on the right-click menu.
Note:
In a source window, you might have to right-click the exact character where the breakpoint is set.
This is necessary if the breakpoint is set on a specific character within a line of source code.
4.7.2.4. Hit Count Keeps Track of How Many Times a Breakpoint is Hit
By default, execution breaks every time that a breakpoint is hit. You can choose to:
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
82
• Break always (the default)
• Break when the hit count equals a specified value
• Break when the hit count equals a multiple of a specified value
• Break when the hit count is greater than or equal to a specified value
If you want to keep track of the number of times a breakpoint is hit but never break execution, you can set
the hit count to a very high value so that the breakpoint is never hit.
The specified hit count is retained only for the debugging session. When the debugging session ends, the
hit count is reset to zero.
4.7.2.5. To Specify a Hit Count
1. In the Breakpoints window, right-click a breakpoint, and then click Hit Count on the right-click
menu.
—or—
In a source, Disassembly, or Call Stack window, right-click a line that contains a breakpoint, and
then click Hit Count from the Breakpoints sub menu on the right-click menu.
2. In the Hit Count dialog box, select the behavior you want from the When the breakpoint is hit list.
If you choose any setting other than Break always, a text box appears next to the list. Edit the
integer that appears in the text box to set the hit count you want.
3. Click OK.
4.7.2.6. To Enable or Disable a Single Breakpoint
In a source, Disassembly, or Call Stack window, right-click a line that contains a breakpoint glyph, point to
Breakpoint, then click Enable Breakpoint or Disable Breakpoint.
—or—
In the Breakpoints window, select or clear the check box next to the breakpoint.
To enable or disable all breakpoints
From the Debug menu, click Enable All Breakpoints.
4.7.2.7. To Delete a Breakpoint
In the Breakpoints window, right-click a breakpoint, and then click Delete on the right-click menu.
—or—
In a source window or a Disassembly window, click the breakpoint glyph.
4.7.2.8. To Delete all Breakpoints
From the Debug menu, click Delete All Breakpoints .
Confirmation Prompt
When you delete all breakpoints, a prompt requesting confirmation of the action might appear, depending
on options settings.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
83
4.7.3. Breakpoint Window
Figure 4-5. Breakpoint Window
You can open the Breakpoints window from the Debug menu.
4.7.3.1. To Open the Breakpoints Window
On the Debug menu, point to Windows, and then click Breakpoints.
4.7.3.2. To Go to the Location of a Breakpoint
In the Breakpoints window, double-click a breakpoint.
—or—
In the Breakpoints window, right-click a breakpoint and choose Go To Source Code or Go To
Disassembly.
—or—
Click a breakpoint, and then click the Go To Source Code or Go To Disassembly tool.
4.7.3.3. To Display Additional Columns
In the toolbar at the top of the Breakpoints window, click the Columns tool, and then select the name of
the column you want to display.
4.7.3.4. To Export all Breakpoints that Match the Current Search Criteria
In the Breakpoints window toolbar, click the Export all breakpoints matching current search criteria icon.
1. The Save As dialog box appears.
2. In the Save As dialog box, type a name in the File name box.
3. This is the name of the XML file that will contain the exported breakpoints. Note the folder path
shown at the top of the dialog box. To save the XML file to a different location, change the folder
path shown in that box, or click Browse Folders to browse for a new location.
4. Click Save.
4.7.3.5. To Export Selected Breakpoints
1. In the Breakpoints window, select the breakpoints you want to export.
To select multiple breakpoints, hold down the Ctrl key and click additional breakpoints.
2. Right-click in the breakpoints list, and choose Export selected.
3. The Save As dialog box appears.
4. In the Save As dialog box, type a name in the File name box.
This is the name of the XML file that will contain the exported breakpoints.
The folder path is shown at the top of the dialog box. To save the XML file to a different location,
change the folder path shown in that box, or click Browse Folders to browse for a new location.
5. Click Save.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
84
4.7.3.6. To Import Breakpoints
1. In the Breakpoints window toolbar, click the Import breakpoints from a file icon.
2. The Open dialog box appears.
3. In the Open dialog box, browse to the directory where your file is located, and then type the file
name or select the file from the file list.
4. Click OK.
4.7.3.7. To View Breakpoints that Match a Specified String
In the Search box, perform one of the following actions:
1. Type your search string in the Search box and press ENTER.
—or—
2. Click the Search drop-down list and select a string from the list of previous search strings.
To limit the search to a specified column, click the In Column drop-down list and then click the name of
the column that you want to search in.
4.7.3.8. To View all Breakpoints after a Search
In the Search box, select and delete the search string and then press ENTER.
4.7.3.9. Breakpoint Labels
In Atmel Studio, you can use labels to help keep track of your breakpoints. A label is a name that you can
attach to a breakpoint or a group of breakpoints. You can create a name for a label or you can choose
from among a list of existing labels. You can attach multiple labels to each breakpoint.
Labels are useful when you want to mark a group of breakpoints that are related in some way. After you
have labeled the breakpoints, you can use the search function in the Breakpoints window to find all
breakpoints that have a specified label.
The search function searches all columns of information that are visible in the Breakpoints window. To
make your labels easy to search for, avoid using label names that might conflict with strings that appear in
another column. For example, if you have a source file that is named "Program.c", "Program.c" will
appear in the name of any breakpoint set in that file. If you use "Prog" as a label name, all breakpoints
set in Program.c will appear when you search for breakpoints labeled "Prog".
4.7.3.10. To Label Breakpoints
1. In the Breakpoints window, select one or more breakpoints.
2. To select multiple breakpoints, use the Ctrl key when selecting breakpoints.
3. Right-click the selected breakpoints, and then click Edit labels.
4. The Edit breakpoint labels dialog box appears.
5. Select one or more labels in the Choose among existing labels box.
—or—
Type a new label name in the Type a new label box, and then click Add.
4.7.3.11. To Search for Breakpoints that have a Specified Label
1. In the Breakpoints window toolbar, click the In Column box and select Labels from the drop-down
list.
2. In the Search box, type the name of the label you want to search for and press Enter.
4.7.3.12. To Remove Labels from Breakpoints
1. In the Breakpoints window, select one or more breakpoints.
Press Ctrl left-click to select multiple breakpoints.
2. Right-click the selected breakpoints, and then click Edit labels.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
85
3. The Edit breakpoint labels dialog box appears.
4. In the Choose among existing labels box, clear the checkboxes for labels that you want to
remove from the selected breakpoints.
4.7.3.13. To Sort the Breakpoint List by Label
1. In the Breakpoints window, right-click the breakpoint list.
2. Point to Sort by and then click Label.
(Optional) To change the sort order, right-click the breakpoint list again, point to Sort by, and then click
Sort Ascending or Sort Descending.
4.8. Data Breakpoints
Data breakpoints allow you to break execution when the value stored at a specified memory location is
accessed (read/write). In general, Data Breakpoint hardware module listens on the data address and data
value lines between the CPU and the data cache and can halt the CPU, if the address and/or value meets
a stored compare value. Unlike program breakpoints, data breakpoints halt on the next instruction after
the load/store instruction that caused the breakpoint has completed.
4.8.1. Adding Data Breakpoint
Adding Data Breakpoint using code editor context menu
You can add Data breakpoint from code editor. Select the variable in code editor and select Breakpoint
→ Add Databreakpoint from context menu. This adds data breakpoint for a given variable address.
Default access mode is write and default mask is none. You can invoke the same command using short
cut key Ctrl + Shift + R .
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
86
Figure 4-6. Adding Data Breakpoint from the Context Menu
Adding Data Breakpoint from Debug menu
You can add new Data breakpoint from Debug → New Breakpoint → New Data Breakpoint. This opens
the Data Breakpoint Configuration window.
Adding Data Breakpoint from Data Breakpoints tool window
You can add new Data breakpoint using the New button in Data Breakpoints tool window. This opens the
Data Breakpoint Configuration window.
Note: You can add or modify Data breakpoint only in debug mode.
4.8.2. Data Breakpoints Window
4.8.2.1. Data Breakpoints Tool Window
The Data Breakpoint window provides the options to set data breakpoint and lists the added data
breakpoints. Enable this window by choosing Debug → Windows → Data Breakpoints.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
87
Figure 4-7. Data Breakpoint Window
Data Breakpoints toolbar has following elements:
•
- provides the data breakpoint configuration window to add a new data breakpoint.
•
- provides the data breakpoint configuration window to edit the selected data breakpoint.
•
- removes the selected data breakpoint. You can invoke the same command using the Delete
key.
•
- removes the all data breakpoints.
•
- enable or disable all the data breakpoints.
Data Breakpoints window displays several columns related to breakpoint configuration. Some of the
columns are dynamically hidden based on the breakpoints configuration. E.g.: if none of the breakpoints
has Mask configured, then Mask related columns are not displayed.
Name column has three parts:
• Check box - Use Check box to enable or disable breakpoint.
• Icon - Glyph to represent the current state of the breakpoint. The following table describes these
glyphs. If you rest the mouse on a breakpoint glyph, a breakpoint tip appears with more information.
This information is especially useful for error and warning breakpoints.
• Text - Displays the configured location expression for breakpoint.
Table 4-2. Breakpoint Icons
Icon Description
Normal breakpoint. The solid glyph indicates that the breakpoint is enabled. The hollow glyph
indicates that it is disabled.
Advanced breakpoint. Active/disabled. The + sign indicates that the breakpoint has hit count
attached to it.
Tracepoint. Active/disabled. Hitting this point performs a specified action but doesn't break
program execution.
Advanced tracepoint. Active/disabled. The + sign indicates that the tracepoint has hit count
attached to it.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
88
Icon Description
Breakpoint or tracepoint error. The X indicates that the breakpoint or tracepoint couldn't be set
because of an error condition. Check Message column for more details on error message.
Breakpoint or tracepoint is set but with warning. Check Message column for more details on
warning message.
4.8.2.2. Data Breakpoint Configuration Window for Mega
This window provides configuration options related to data breakpoint for ATmega devices. Address mask
is optional.
Location
You can enter a specific address in RAM (e.g.: 0x8004) directly or an expression that evaluates to an
address in RAM (e.g.: &x). Make sure the expression you enter represents the address of the data to
monitor.
Note: Data breakpoints on local variables can result in false hits due to reuse of stack memory.
Suggestion to declare it as static for debugging purpose.
Access Mode
You can configure the breakpoint to break on specific Access Mode. Three types of access modes are
supported.
• Read - Program breaks on read at specified location.
• Write (Default) - Program breaks on write at specified location.
• Read/Write - Program breaks on read or write at specified location.
Address Mask
Address Mask on Mega Data Breakpoints is optional. Use address mask to break on more than one
address or a range of address on particular access.
Mask Mask value to mask the Location address to define more than one address or range of
address. Bits with value 1 in the mask are significant bits and 0 are don't care bits.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
89
In general for a given address A and mask M, an address B successfully matches when:
(A) & (M) == (B) & (M), where A is resolved address for the expression entered in Location,
M is mask value entered in Mask and B is any address in RAM.
Masked
Address
This is a read only field which shows the range of matching addresses on which program
can break. The masked address is shown in the binary format for simplicity. 'X' represents
don't care bits, remaining bits are expected to match.
E.g. 0b000000010XX000XX means it can break as per access mode, at addresses which
has all bits as per this string except X bits. In this case 0th, 1st, 5th, and 6th bit (lsb) can be
anything since these bits are don't care (X).
Note: ATmega devices don't support Data Masks.
4.8.2.3. Data Breakpoint Configuration Window for XMEGA
This window provides configuration options related to data breakpoint for XMEGA devices.
Location
You can enter a specific address in RAM (e.g.: 0x8004) directly or an expression that evaluates to an
address in RAM (e.g.: &x). Make sure the expression you enter represents the address of the data to
monitor.
Note: Data breakpoints on local variables can result in false hits due to reuse of stack memory.
Suggestion to declare it as static for debugging purpose.
Access Mode
You can configure the breakpoint to break on specific Access Mode. Three types of access modes are
supported.
• Read - Program breaks on read at specified location.
• Write (Default) - Program breaks on write at specified location.
• Read/Write - Program breaks on read or write at specified location.
Data Match
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
90
Use the Data Match option to configure Data Breakpoint to compare the data at specified location based
on one of the following conditions:
• Location content is equal to the value
• Location content is greater than the value
• Location content is less than or equal to the value
• Location content is within the range
• Location content is outside the range
• Bits of the location is equal to the value
Note: Bit Mask: It is an 8-bit value where bits with '1' are significant and the bits with '0' are don't
care.
In general for a given value V and bit mask M, the break event is triggered when the value in the
location field VL satisfies the condition
(V) & (M) == (VL) & (M)
For example, using Value = 0xA0 and Bit Mask = 0xF0 will trigger a break event when the
location field has any of the values between0xA0 to 0xAF.
Note: Condition Value field has to be of 1 byte.
4.8.2.4. Data Breakpoint Configuration Window for UC3
This window provides configuration options related to data breakpoint for UC3 devices.
Location
You can enter a specific address in RAM (e.g.: 0x8004) directly or an expression that evaluates to an
address in RAM (e.g.: &x). Make sure the expression you enter represents the address of the data to
monitor.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
91
Note: Data breakpoints on local variables can result in false hits due to reuse of stack memory.
Suggestion to declare it as static for debugging purpose.
Access Mode
You can configure the breakpoint to break on specific Access Mode. Three types of access modes are
supported.
• Read - Program breaks on read at specified location.
• Write (Default) - Program breaks on write at specified location.
• Read/Write - Program breaks on read or write at specified location.
Access Size
You can configure the breakpoint to break on specific Access Size. Four types of access size are
supported.
• Any Access (Default) - Program breaks on any access size at specified location.
• Byte Access - Program breaks on Byte access at specified location.
• HalfWord Access - Program breaks on HalfWord access at specified location.
• Word Access - Program breaks on Word access at specified location.
Example for setting access size
Configuration:
Code:
1: int word = 0;
2: short *halfWord = (short*)&word;
3:
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
92
4: int main(void)
5: {
6: word = 0xAABBCCFF;
7: *halfWord = 0xDDEE;
8: }
For the above configuration and code, program breaks at line eight after halfWord
access.
Data Match
Use the Data Match option to configure Data Breakpoint to compare the data at specified location with a
32-bit value. Break event is triggered on a successful match.
Value 32-bit (4-byte) value to compare with data at Location address. The value can be decimal or
hexadecimal (e.g.: 100 or 0x64). Based on Access Size, respective bytes are used for data
comparison. For example, if you select "HalfWord Access" as Access Size and enter
0xAABBCCDD as Value, then only the last two bytes (0xCCDD) are used for data comparison.
You could further refine the Value by specifying Mask.
Mask
(Byte)
Each check box controls the significance of respective byte in the Value field. Select
appropriate check box to mask specific byte in the Value field. The number of check boxes
displayed is decided based on Access Size. Four check boxes (one per byte) are displayed
for "Any" and "Word Access", two check boxes for "HalfWord Access" and one check box for
"Byte Access".
Match
Value
A read only field, which displays masked value based on Access Size, Value, and Mask
(Byte) field. Masked byte is represented as 'XX', which means that byte is insignificant in
data comparison.
4.8.2.5. Data Breakpoint Configuration Window for SAM
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
93
Provides the configuration options related to data breakpoint for SAM devices. Address mask and Data
match are optional.
Location
You can enter a specific address (e.g.: 0x8004) directly or an expression that evaluates to an address
(e.g.: &x). Make sure the expression you enter represents the address of the data to monitor.
Note: Data breakpoints on local variables can result in false hits due to reuse of stack memory.
Suggestion to declare it as static for debugging purpose.
Access Mode
You can configure the breakpoint to break on a specific Access Mode. Three types of access modes are
supported.
• Read - Program breaks on read at specified location.
• Write (Default) - Program breaks on write at specified location.
• Read/Write - Program breaks on read or write at specified location.
Address Mask
Use this setting to define range of addresses to monitor for access.
Byte Count You can enter a number of address locations to monitor starting at Location address. The
actual range of monitored address can be wider than the expected range. E.g.: if the
Location is 0x23FA and the Byte Count is 5, then the actual range of the monitored
address is [0x23F8 to 0x23FF]. The way actual range is computed is by calculating the
number of least significant bits that has to be masked in the Location address (0x23FA)
in order to cover the expected range [0x23FA to 0x23FA + 5]. In this case the number of
bits to be masked is three. As a result the actual range [0x23F8 to 0x23FF] is wider than
the expected range [0x23FA to 0x23FF].
Mask Size This is a read only field, which displays the number of least significant bits masked in the
Location address. Mask Size is calculated based on the Byte Count and Location
addresses.
Address
Range
This is a read only field, which displays the actual range of address monitored for access.
Range is closed interval including both minimum and maximum address.
Data Match
Use the Data Match option to configure Data Breakpoint to compare the data at specified location with a
32-bit value. Break event is triggered on a successful match.
Value 32-bit (4-byte) value to compare with data at the Location address. The value can be decimal
or hexadecimal (e.g.: 100 or 0x64). You could further refine the Value by specifying Mask.
Mask You can use Mask to extract appropriate bytes from Value to use for data comparison. E.g.: if
the Value is 0xAABBCCDD and Mask is HalfWord, then last two bytes (0xCCDD) is extracted
from Value and used for data comparison. This means data comparison would succeed for
the following matches 0xXXXXCCDD, 0xXXCCDDXX, and 0xCCDDXXXX, where X is a don't
care hexadecimal digit (0 to F). Three types of Mask's are supported.
• Byte - Last byte extracted from Value is used for data comparison.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
94
• HalfWord - Last two bytes extracted from Value is used for data comparison.
• Word (Default) - Whole four bytes from Value is used for data comparison.
Match
Value
This is a read only field which displays match values.
Data Match Example
Byte matching example
• Location = 0x200008D4
• Value = 0x0000CCAA
• Mask = Byte
The program breaks when Location0x200008D4 has any of the following values:
• 0xXXXXXXAA
• 0xXXXXAAXX
• 0xXXAAXXXX
• 0xAAXXXXXX
HalfWord matching example
• Location = 0x200008D4
• Value = 0x0000CCAA
• Mask = HalfWord
The program breaks when Location0x200008D4 has any of the following values:
• 0xXXXXCCAA
• 0xXXCCAAXX
• 0xCCAAXXXX
Word matching example
• Location = 0x200008D4
• Value = 0x0000CCAA
• Mask = Word
The program breaks when Location 0x200008D4 has the following value:
• 0x00000CCAA
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
95
4.8.2.6. Data Breakpoint Configuration Window for Simulator Tool
The above configuration window is displayed for any device architecture when a simulator tool is
selected.
Location
You can enter a specific address in RAM (e.g.: 0x8004) directly or an expression that evaluates to an
address in RAM (e.g.: &x). Make sure the expression you enter represents the address of the data to
monitor.
Note: Data breakpoints on local variables can result in false hits due to reuse of stack memory.
Suggestion to declare it as static for debugging purpose.
Access Mode
You can configure the breakpoint to break on specific Access Mode. Three types of access modes are
supported.
• Read - Program breaks on read at specified location.
• Write (Default) - Program breaks on write at specified location.
• Read/Write - Program breaks on read or write at specified location.
Byte Count
You can enter number of address locations to monitor starting at Location address.
Note:
• Simulator supports unlimited number of data breakpoints
4.8.2.7. How to: Specify a Data Breakpoint Hit Count
Hit count
The number of times the value stored in the specified memory location is accessed (read/write).
To specify a hit count
To specify or edit the Hit Count property, you must open the Hit Count Dialog Box.
In Data Breakpoints window, select a breakpoint row, and then choose Hit Count on the context menu.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
96
Figure 4-8. Hit Count Dialog Box
To set or modify a hit count property, use the following controls:
• When the breakpoint is hit: This setting determines how the breakpoint should behave when it is
hit. You can choose to:
• Break always (the default)
• Break when the hit count equals a specified value
• Break when the hit count equals a multiple of a specified value
• Break when the hit count is greater or equal to a specified value
• Current hit count: This value shows the number of times the data breakpoint has been hit. A read/
write data for a variable will be converted into multiple instructions, resulting in several memory
access. So the data breakpoint hits multiple times for the same variable and the hit count will be
updated accordingly.
• Reset: This button resets the value shown for the Current hit count to 0.
If you choose any option other than the default in When the breakpoint is hit list control, an edit box
appears next to it. Edit the value in this edit box to set the hit count value. For example, you might choose
break when hit count is equal to and enter 5. This causes execution to stop the 5th time the breakpoint is
hit, not on any other hit.
4.8.2.8. When Breakpoint is Hit Dialog Box
With this dialog box you can print a message in the output window when a data breakpoint is hit.
To open the When Breakpoint Is Hit Dialog Box, go to the Data Breakpoints window, select a
breakpoint row, and then choose When Hit on the context menu.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
97
Specify the message
• You can use any of the keywords that are described on the When Breakpoint Is Hit dialog box.
E.g.: Process Id : $PID.
• You can also specify expressions in the message by placing it in the curly braces, such as sum={a
+b}
Specify the breakpoint behavior
To break execution when the breakpoint is hit, clear the Continue Execution check box. When Continue
Execution is checked, execution is not halted. In both cases, the message is printed.
4.8.3. General Information on Data Breakpoint
• Data Breakpoint can be edited/added only in debug mode
• Local variables must always be qualified with the function name. This is also the case if the user
wants to add a variable from the function that the program has stopped in.
Data breakpoints on local variables can result in false hits due to reuse of stack memory.
Tip:
Declare local variables as static and provide the static variable's address in the location
field, the address of the static variable is fixed during compilation/linking.
• Global variables are initialized with default values during the start up, the valid data breakpoint for
global variables will hit in the disassembly or initialization code during the start up
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
98
• There can be several instructions to perform read/write data for a variable, for example 'int' data
type can have two individual byte read/write instructions so the data breakpoint hits twice for the
same variable
• Data breakpoint event can occur when the bus access happens for the specific address
• Maximum number of data breakpoint supported: (this may vary based on specific device/family
refer data sheet)
Architecture Maximum Data breakpoint supported
ATmega • Two without Data Mask (OR)
• One without Data Mask and one with Data Mask
XMEGA • Two without Data Mask (OR)
• One without Data Mask and one with Data Mask (OR)
• Two with Data Mask
UC3 • Two without Data Mask (OR)
• One without Data Mask and one with Data Mask (OR)
• Two with Data Mask
SAM Device dependent refer data sheet
Tiny Does not support data breakpoint
Most of the devices conforms to the above limit.
Note: ATmega and SAM device uses multiple hardware resources when a data breakpoint with data
mask is set. Hence, using data mask can reduce the number of data breakpoint that can be set.
4.8.4. Data Breakpoint Usage
4.8.4.1. Stack Overflow Detection Using Data Breakpoint
You can decide on maximum stack size for the your application and calculate the approximate end
address for the stack.
In the end address set the data breakpoint for address range by applying address mask and access type
as Read/Write.
Note: The above method may cause false break when heap memory tries to access the specified stack
end address.
4.9. QuickWatch, Watch, Locals, and Autos Windows
The Atmel Studio debugger provides several windows, collectively known as variable windows, for
displaying variable information while you are debugging.
Each variable window has a grid with three columns: Name, Value, and Type. The Name column shows
the names of variables added automatically in the Auto and Locals windows.
In the Watch window, the Name column is where you can add your own variables or expressions. See
how to watch an expression in the Debugger.
The Value and Type columns display the value and data type of the corresponding variable or expression
result.
You can edit the value of a variable in the Value column.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
99
The variable windows, Autos, Locals, and Watch, display the values of certain variables during a
debugging session. The QuickWatch dialog box can also display variables. When the debugger is in
break mode, you can use the variable windows to edit the values of most variables that appear in these
locations.
Note: Editing floating-point values can result in minor inaccuracies because of decimal-to-binary
conversion of fractional components. Even a seemingly harmless edit can result in changes to some of
the least significant bits in the floating-point variable.
When an expression is evaluated in the Watch window, you might see a refresh icon. This indicates an
error or out-of-date value. For more information, see How to: Refresh Watch Values.
If you want to, you can enter an expression for a value. The debugger will evaluate the expression and
replace it with the resulting value. The debugger accepts most valid language expressions in a Watch
window. For more information, see Expression Formatting.
If you are programming in native code, you might sometimes have to qualify the context of a variable
name or an expression that contains a variable name. The context means the function, source file, and
module where a variable is located. If you have to do this, you can use the context operator syntax. For
more information, see Context Operator (C/C++ Language Expressions).
Evaluating some expressions can change the value of a variable or otherwise affect the state of your
program. For example, evaluating the following expression changes the value of var1 and var2:
var1 = var2++
var1 = var2++
Expressions that change data are said to have side effects, which can produce unexpected results if you
are not aware of them. Therefore, make sure you understand the effect of an expression before you
execute it.
To edit a value in a variable window
1. The debugger must be in break mode.
2. If the variable is an array or an object, a tree control appears next to the name in the Name box. In
the Name column, expand the variable, if necessary, to find the element whose value you want to
edit.
3. In the row you want to change, double-click the Value column.
4. Type the new value.
5. Press ENTER.
To display a variable window
On the Debug menu, choose Windows, then choose the name of the variable window you want to display
(Autos, Locals, Watch, or Watch1 through Watch4).
You cannot access these menu items or display these windows in design mode. To display these menu
items, the debugger must be running or in break mode.
4.9.1. Watch Window
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
100
The Watch window and QuickWatch dialog box are places where you can enter variable names and
expressions that you want to watch during a debugging session.
The QuickWatch dialog box enables you to examine a single variable or expression at a time. It is useful
for taking a quick look at one value or a larger data structure. The Watch window can store several
variables and expressions that you want to view over the course of the debugging session. Atmel Studio
has multiple Watch windows, which are numbered Watch1 through Watch4.
A variable name is the simplest expression you can enter. If you are debugging native code, you can use
register names as well as variable names. The debugger can accept much more complex expressions
than that, however. For example, you could enter the following expression to find the average value of
three variables:
(var1 + var2 + var3) / 3
The debugger accepts most valid language expressions in a Watch window. For more information, see
Expression Formatting.
If you are programming in native code, you may sometimes need to qualify the context of a variable name
or an expression containing a variable name. The context means the function, source file, and module
where a variable is located. If you have to do this, you can use the context operator syntax.
Expressions that Affect the State of Your Program
Evaluating some expressions can change the value of a variable or otherwise affect the state of your
program. For example, evaluating the following expression changes the value of var1:
var1 = var2
Expressions that change data are said to have side effects. If you enter an expression that has a side
effect into the Watch window, the side effect will occur every time the expression is evaluated by the
Watch window. This can produce unexpected results if you are unaware that the expression has side
effects. An expression that is known to have side effects is only evaluated one time, when you first enter
it. Subsequent evaluations are disabled. You can manually override this behavior by clicking an update
icon that appears next to the value.
Unexpected side effects are frequently the result of function evaluation. For example, you could enter the
following function call into the Watch window:
PrintFunc1(var1)
Func1(var1)
If you call a function from the Watch window or QuickWatch, the function you are calling might change
data, creating a side effect. One way to avoid possible unexpected side effects from function evaluation is
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
101
to turn OFF automatic function evaluation in the Options dialog box. This disables automatic evaluation of
newer language features, such as properties. However, it is safer.
Note: When you examine an expression in the Watch window, you might see an update icon, which
resembles two green arrows, circling in opposite directions within a green circle. This is especially likely if
you have turned OFF automatic function evaluation. The update icon indicates an error or out-of-date
value.
The Atmel Studio debugger automatically expands common data types to show their most important
elements. You add expansions for custom data types. For more information, see Displaying Custom Data
Types and Visualizers.
Note: The dialog boxes and menu commands you see might differ from those described in Help
depending on your active settings or edition. To change your settings, choose Import and Export
Settings on the Tools menu. For more information, see Menus and Settings.
To evaluate an expression in the Watch window
1. In the Watch window, click an empty row in the Name column. The debugger must be in break
mode at this point. Type or paste the variable name or expression you want to watch.
—or—
Drag a variable to a row in the Watch window.
2. Press ENTER.
3. The result appears in the Value column. If you type the name of an array or object variable, a tree
control appears next to the name in the Name column. Expand or collapse the variable in the Name
column.
4. The expression remains in the Watch window until you remove it.
To evaluate an expression in QuickWatch
1. In the QuickWatch dialog box, type or paste the variable, register, or expression into the Expression
text box.
2. Click Reevaluate or press ENTER.
3. The value appears in the Current value box.
4. If you type the name of an array or object variable in the Expression box, a tree control appears
next to the name in the Current value box. Expand or collapse the variable in the Name column.
To reevaluate a previous expression in QuickWatch
1. In the QuickWatch dialog box, click the down arrow that appears to the right of the Expression box.
2. Choose one of the previous expressions from the drop-down list.
3. Click Reevaluate.
4.9.2. Locals Window
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
102
The Locals window displays variables local to the current context.
4.9.2.1. To Display the Locals Window
From the Debug menu, choose Windows and click Locals. (The debugger must be running or in break
mode.)
4.9.2.2. To Choose an Alternative Context
The default context is the function containing the current execution location. You can choose an alternate
context to display in the Locals window:
• Use the Debug Location toolbar to select the desired function, thread, or program
• Double click on an item in the Call Stack or Threads window
To view or modify information in the Locals window, the debugger must be in break mode. If you choose
Continue, some information may appear in the Locals window while your program executes, but it will not
be current until the next time your program breaks (in other words, it hits a breakpoint or you choose
Break All from the Debug menu).
4.9.2.3. To Modify the Value of a Variable in the Locals Window
1. The debugger must be in break mode.
2. In the Locals window, select the value you want to edit by double-clicking on it or by using the TAB
key.
3. Type the new value, and press ENTER.
Attention:
Editing floating-point values can result in minor inaccuracies because of decimal-to-binary
conversion of fractional components. Even a seemingly harmless edit can result in changes to
some of the least significant bits in the floating-point variable.
Setting Numeric Format
You can set the numeric format used in the debugger windows to decimal or hexadecimal. Right click
inside the Locals window, and check/uncheck the Hexadecimal display menu item.
4.9.3. Autos Window
The Autos window displays variables used in the current statement and the previous statement.
The current statement is the statement at the current execution location (the statement that will be
executed next if execution continues). The debugger identifies these variables for you automatically,
hence the window name.
Structure and array variables have a tree control that you can use to display or hide the elements.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
103
To display the Autos window
From the Debug menu, choose Windows and click Autos. (The debugger must be running or in break
mode.)
4.9.3.1. To Modify the Value of a Variable in the Autos Window
1. The debugger must be in break mode.
2. Display the Autos window, if necessary.
3. In the Value column, double-click the value you want to change.
-orSingle-click
to select the line, then press the TAB key.
4. Type the new value, and press ENTER.
Attention:
Editing floating-point values can result in minor inaccuracies because of decimal-to-binary
conversion of fractional components. Even a seemingly harmless edit can result in changes to
some of the least significant bits in the floating-point variable.
4.9.3.2. Setting Numeric Format
You can set the numeric format used in the debugger windows to decimal or hexadecimal. Right click
inside the Autos window, and check/uncheck the Hexadecimal display menu item.
4.9.4. QuickWatch and Watches
While debugging you might want to track a value of a variable or an expression. To do so you can right
click at the expression under cursor and select Add a Watch or Quickwatch.
The QuickWatch dialog box lets you examine and evaluate variables and expressions. Because
QuickWatch is a modal dialog box, you have to close it before you can continue to debug. You can also
edit the value of a variable in QuickWatch. For more information on how to watch a variable, see Watch
Window.
Some users might wonder why QuickWatch is useful. Why not add the variable or expression to the
Watch window? That is possible, but if you just want to do a quick scratch calculation that involves one or
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
104
more variables, you do not want to clutter the Watch window with such calculations. That is when the
QuickWatch dialog box is especially useful.
Another feature of the QuickWatch dialog box is that it is resizeable. If you want to examine the members
of a large object, it is frequently easier to expand and examine the tree QuickWatch than it is in the
Watch, Locals, or Autos window.
The QuickWatch dialog box does not allow you to view more than one variable or expression at a time.
Also, because QuickWatch is a modal dialog box, you cannot perform operations such as stepping
through your code while QuickWatch is open. If you want to do these things, use the Watch window
instead.
Some expressions have side effects that change the value of a variable or otherwise change the state of
your program when they are executed. Evaluating an expression in the QuickWatch dialog box will have
the same effect as executed the expression in your code. This can produce unexpected results if you do
not consider the side effects of the expression.
Note: In Atmel Studio, you can view a variable's value by placing the cursor over the variable. A small
box called a DataTip appears and shows the value.
To open the QuickWatch dialog box
While in break mode, choose QuickWatch on the Debug menu.
To open the QuickWatch dialog box with a variable added
While in break mode, right-click a variable name in the source window name and choose QuickWatch.
This automatically places the variable into the QuickWatch dialog box.
To add a QuickWatch expression to the Watch window
In the QuickWatch dialog box, click Add Watch.
Whatever expression that was displayed in the QuickWatch dialog box is added to the list of expressions
in the Watch window. The expression will normally be added to the Watch1 window.
4.9.5. Expression Formatting
The Atmel Studio debugger includes expression evaluators that work when you enter an expression in
the QuickWatch and Watches, Memory View, Watch Window, or Immediate window. The expression
evaluators are also at work in the Breakpoints window and many other places in the debugger.
General Syntax:
Val, formatString
Format Specifier for values
The following tables show the format specifiers recognized by the debugger.
Table 4-3. Debug Format Specifiers for Values
Specifier Format Expression Value displayed
d,i signed decimal integer 0xF000F065, d -268373915
u unsigned decimal integer 0x0065, u 101
b unsigned binary number 0xaa,b2 0b10101010
o unsigned octal integer 0xF065, o 0170145
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
105
Specifier Format Expression Value displayed
x,X Hexadecimal integer 61541, x 0x0000F065
1,2,4,8 As a suffix specifying number of bytes for: d, i, u, o, x, X. 00406042,x2 0x0c22
s String 0x2000, s "Hello World"
f signed floating point (3./2.), f 1.500000
e signed scientific notation (3./2.), e 1.500000e+000
g signed floating point or signed scientific notation,
whichever is shorter
(3./2.), g 1.5
c Single character 0x0065, c 101 'e'
Size Specifier for Pointers as Arrays
If you have a pointer to an object you want to view as an array, you can use an integer to specify the
number of array elements:
ptr,10 or array,20
Memory type specifier
The following memory type specifiers will force the memory reference to a specific memory type. To be
used in the memory window in the address field, you should have a pointer to an object you want to view
as an array. You can use an integer to specify the number of the array elements:
Table 4-4. Debug Memory Type Specifiers
Specifier Expression Value displayed
flash or program Program memory 0,flash
data Data memory 0x2000,data
sram SRAM 0x100,sram
reg or registers registers 1,reg
io, eeprom, fusebytes, lockbytes, signature,
usersign, prodsign
Memory types with same names
4.10. DataTips
DataTips provide a convenient way to view information about variables in your program during debugging.
DataTips work only in break mode and only with variables that are in the current scope of execution.
In Atmel Studio, DataTips can be pinned to a specific location in a source file, or they can float on top of
all Atmel Studio windows.
To display a DataTip (in break mode only)
1. In a source window, place the mouse pointer over any variable in the current scope. A DataTip
appears.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
106
2. The DataTip disappears when you remove the mouse pointer. To pin the DataTip so that it remains
open, click the Pin to source icon, or
– Right-click on a variable, then click Pin to source
The pinned DataTip closes when the debugging session ends.
To unpin a DataTip and make it float
• In a pinned DataTip, click the Unpin from source icon
The pin icon changes to the unpinned position. The DataTip now floats above any open windows.
The floating DataTip closes when the debugging session ends.
To repin a floating DataTip
• In a DataTip, click the pin icon
The pin icon changes to the pinned position. If the DataTip is outside a source window, the pin icon
is disabled and the DataTip cannot be pinned.
To close a DataTip
• Place the mouse pointer over a DataTip, and then click the Close icon
To close all DataTips
• On the Debug menu, click Clear All DataTips
To close all DataTips for a specific file
• On the Debug menu, click Clear All DataTips Pinned to File
4.10.1. Expanding and Editing Information
You can use DataTips to expand an array, a structure, or an object to view its members. You can also edit
the value of a variable from a DataTip.
To expand a variable to see its elements:
• In a DataTip, put the mouse pointer over the + sign that comes before the variable name
The variable expands to show its elements in tree form.
When the variable is expanded, you can use the arrow keys on your keyboard to move up and down.
Alternatively, you can use the mouse.
To edit the value of a variable using a DataTip
1. In a DataTip, click the value. This is disabled for read-only values.
2. Type a new value and press ENTER.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
107
4.10.2. Making a DataTip Transparent
If you want to see the code that is behind a DataTip, you can make the DataTip temporarily transparent.
This does not apply to DataTips that are pinned or floating.
To make a DataTip transparent
• In a DataTip, press CTRL
The DataTip will remain transparent as long as you hold down the CTRL key.
4.10.3. Visualizing Complex Data Types
If a magnifying glass icon appears next to a variable name in a DataTip, one or more Visualizers are
available for variables of that data type. You can use a visualizer to display the information in a more
meaningful, usually graphical, manner.
To view the contents of a variable using a visualizer
• Click the magnifying glass icon to select the default visualizer for the data type
-orClick
the pop-up arrow next to the visualizer to select from a list of appropriate visualizers for the
data type.
A visualizer displays the information.
4.10.4. Adding Information to a Watch Window
If you want to continue to watch a variable, you can add the variable to the Watch window from a DataTip.
To add a variable to the Watch window
• Right-click a DataTip, and then click Add Watch
The variable is added to the Watch window. If you are using an edition that supports multiple Watch
windows, the variable is added to Watch 1.
4.10.5. Importing and Exporting DataTips
You can export DataTips to an XML file, which can be shared with a colleague or edited using a text
editor.
To Export DataTips
1. On the Debug menu, click Export DataTips.
The Export DataTips dialog box appears.
2. Use standard file techniques to navigate to the location where you want to save the XML file, type a
name for the file in the File name box, and then click OK.
To Import DataTips
1. On the Debug menu, click Import DataTips.
The Import DataTips dialog box appears.
2. Use the dialog box to find the XML file that you want to open and click OK.
4.11. Disassembly View
The Disassembly window is only available when debugging. When any supported high level language is
used, the source window is automatically displayed and the disassembly window is OFF. Enable it by
choosing Debug → Windows → Disassembly or Ctrl Alt D during a debugging session.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
108
The disassembly window shows your program code disassembled. Program execution and AVR
instructions can be followed in this view. By right clicking inside the Disassembly window you will be able
to set breakpoints, run to the position of the cursor, or go to the source code. You cannot modify the
source code from the Disassembly window.
In addition to assembly instructions, the Disassembly window can show the following optional information:
• Memory address where each instruction is located. For native applications, this is the actual
memory address.
• Source code from which the assembly code derives
• Code bytes byte representations of the actual machine
• Symbol names for the memory addresses
• Line numbers corresponding to the source code
Assembly-language instructions consist of mnemonics, which are abbreviations for instruction names,
and symbols that represent variables, registers, and constants. Each machine-language instruction is
represented by one assembly-language mnemonic, usually followed by one or more variables, registers,
or constants.
Because assembly code relies heavily on processor registers or, in the case of managed code, common
language runtime registers, you will often find it useful to use the Disassembly window in conjunction with
the Registers window, which allows you to examine register contents.
Note: You may see inconsistencies in instructions that work on explicit addresses. This stems from the
historic difference between the AVR Assembler and Assembly Language and the GCC Assembler and
the assembly used on bigger computer systems. You might therefore encounter disassemblies that look
like the one below.
13: asm volatile ("JMP 0x0001778A");
0000007D 0c.94.c5.bb JMP 0x0000BBC5 Jump >
Here the assembly instruction JMP 0x0001778A is being assembled by the GCC Assembler, and
disassembled using the built-in disassembler in Atmel Studio, which resolves the jump to 0x0000BBC5,
which is exactly half of the address in the initial assembly.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
109
It should be noted that the addresses are always of the same dimension as the line addresses shown in
the disassembly, so the code is functionally similar.
4.12. I/O View
4.12.1. About the I/O View
The purpose of the I/O View is to provide an overview of the registers of the target device for the current
project. It serves as a quick reference during design, and is capable of displaying register values when
the project is in debug mode. The view supports both 32- and 8-bit devices equally.
The default view of the tool window is a vertically split window with peripheral groups in the top section,
and registers in the bottom section. Each peripheral typically has a set of defined settings and value
enumerations, which can be displayed by expanding a register in the peripheral view (top section). The
register view (bottom section) will display all registers which belong to a selected peripheral group. If no
peripheral is selected, the view is empty. Each register can also be expanded to display the pre-defined
value groupings which belongs to the register.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
110
4.12.2. Using the I/O View Tool
The I/O View is confined to a single tool window in the development environment. There can only be one
instance of the I/O view at a time. To open the window, select Debug → Windows → I/O View. When in
design mode, the I/O View will be disabled for inputs. It is still possible to change the layout or filters, and
to navigate the view, but no values can be set or read. To read or change a value in the registers, AVR
Studio must be in debug break mode (execution paused). In this mode, all the controls of the I/O View will
be enabled and values can be read and updated in the view.
In addition to simply displaying the value of a register, the I/O View will display each bit in the register in a
separate column. Bits which are set will have a dark color by default, and cleared bits will have no color
(default white). To change a bit, simply click it, and the value will be toggled.
4.12.3. Editing Values and Bits in Break Mode
When the project is in debug break mode, any value can be changed by clicking the value field and
writing a new value. Some values and bits cannot be modified as they are read-only, and some bits may
be write-only. See the documentation for each device for more information. When a bit or value is set, it is
immediately read back from the device, ensuring that the I/O View only displays actual values from the
device. If a new value is set, but the I/O view does not update as expected, the register might be writeonly
or simply not accessible.
When a register has changed since last time it was displayed, it will indicate so with a red colored value
and bits in the display. If a bit has been set since last time, it will be solid red. If it has been cleared it will
simply have a red border. This feature can be toggled on or off in the toolbar.
4.13. Processor View
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
111
Debug → Processor View. The processor view offers a simulated or direct view of the current target
device MPU or MCU. On the picture above you can see a partial list of the simulated device's
ATxmega128U1 registers.
The program counter shows the address of the instruction being executed, the stack pointer shows the
application's current stack pointer value. The X,Y, and Z registers are temporary pointers that can be used
in indirect passing or retrieving arguments or objects to and from functions. Cycle counter counts the
cycles elapsed from the simulation’s start. Status register or SREG shows the currently set flags. Further
on you will be able to toggle a setting for displaying the flag names.
The stop watch field allows you to make rudimentary profiling of your application. It is influenced by the
frequency set in the Frequency field, which defines target MCU/MPU frequency, in case when the
prototyping board is connected.
Each register can be displayed in hexadecimal, decimal, octal, and binary (flag) format by right-clicking
and choosing Display in binary, etc., or Display in.... Each field can also be modified, as shown in the
below image. If a field is a status or flags register, composed of a number of the one-bit flags, you can
toggle individual flags by clicking on them - .
The processor view is only active in the debug mode.
4.14. Register View
Debug → Windows → Register View or Ctrl Alt G. The register view offers a simple way to see the data
and system registers of your target or simulated device. You cannot modify the registers' contents from
the Register view.
4.15. Memory View
Debug → Windows → Memory view, or Ctrl Alt M n where n is the memory's number. The memory view
gives you an outline of the memory. It is possible to select among the attached memories to see all the
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
112
segments by switching between them in a Segment drop-down menu on top of the memory view. You
can also specify the starting address for the memory view window in the Address form field on top of the
memory view. In order to specify the address you can use either a normal hexadecimal entry or an
expression. See Expression Formatting. The Columns drop-down menu allows you to specify how many
byte-aligned memory columns you wish to see at one time, most often this should be left at Auto setting,
but if you have to manually check a fixed-length type values and you know how many words or bytes
those values occupy, you could align the memory view so that each row will correspond to a desired
number of values.
4.16. Call Stack Window
Note: Call Stack Window is currently only supported for 32-bit devices.
Call stack shows the hierarchical information of callers of the current method. By default, the Call Stack
window displays the name of each function. To display Call Stack, Click the menu, Debug → Windows →
Call Stack.
Along with function name, optional information such as module name, line number, etc. may also be
displayed. The display of this optional information can be turned ON or OFF. To switch ON/OFF the
optional information displayed, Right-click the Call Stack window and select or deselect Show
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
113
Stack frame of the current execution pointer is indicated by an yellow arrow. By default, this is the frame
whose information appears in the source, Disassembly, Locals, Watch, and Auto windows. The stack
frame context can also be changed to be another frame displayed in the Call Stack window.
Warning: Call Stack may not show all the call frames with Optimization levels -O1 and higher.
To switch to another stack frame
1. In the Call Stack window, right-click the frame whose code and data you want to view.
2. Select Switch to Frame.
A green arrow with a curly tail indicates the changed stack context. The execution pointer remains
in the original frame, which is still marked with the yellow arrow. If you select Step or Continue from
the Debug menu, the execution will be continued from the yellow arrow, not the frame you selected.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
114
To view the source/disassembly code for a function on the call stack
1. In the Call Stack window, right-click the function whose source code you want to see and select Go
To Source Code.
2. In the Call Stack window, right-click the function whose disassembly code you want to see and
select Go To Disassembly.
To set a breakpoint on the exit point of a function call
In the Call Stack window, right-click the stack frame to which you would like to add the breakpoint. Select
"BreakPoint → Insert Breakpoint" to add the breakpoint.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
115
4.17. Object File Formats
While Atmel Studio uses ELF/DWARF as the preferred object file-/debug info-format, You may debug
other formats. Several object file formats from various compiler vendors are supported. You can open and
debug these files, but you may not be able to edit the code from within Atmel Studio. Using your own
editor to edit code and Atmel Studio to debug (use the reload button), you will still have a powerful code/
debug environment.
All external debug sessions require you to load an object file supported by Atmel Studio. An object file for
debugging usually contains symbolic information which is not included in a release file. The debug
information enables Atmel Studio to give extended possibilities when debugging, e.g. Source file stepping
and breakpoints set in high level language like C.
Precompiled object files can be opened by using the menu command Open file → Open Object File for
Debugging. See section Debug Object File in Atmel Studio for more info.
Table 4-5. Object File Formats Supported by Atmel Studio
Object file
format
Extension Description
UBROF .d90 UBROF is an IAR proprietary format. The debug output file contains a
complete set of debug information and symbols to support all type of
watches. UBROF8 and earlier versions are supported. This is the default
output format of IAR EW 2.29 and earlier versions. See below how to force
IAR EW 3.10 and later versions to generate UBROF8.
ELF/DWARF .elf ELF/DWARF debug information is an open standard. The debug format
supports a complete set of debug information and symbols to support all
types of watches. The version of the format read by Atmel Studio is
DWARF2. AVR-GCC versions configured for DWARF2 output can
generate this format.
AVRCOFF .cof COFF is an open standard intended for 3rd party vendors creating
extensions or tools supported by the Atmel Studio.
AVR Assembler
format
.obj The AVR assembler output file format contains source file info for source
stepping. It is an Atmel internal format only. The .map file are
automatically parsed to get some watch information.
Before debugging, make sure you have set up your external compiler/assembler to generate an object file
with debug information in one of the formats above.
3
rd party compiler vendors should output the ELF/DWARF object file format to ensure support in Atmel
Studio. Optionally you could provide an extension to have both debugging and compile support. See
Contact Information for more information.
Tip:
How to generate AVR-compatible ELF file in IARW32:
In the Project options → Output format dialog choose elf/dwarf, and in the Project options
→ Format variant select ARM-compatible "-yes".
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
116
Tip:
How to force IAR EW 3.10 and later versions to generate UBROF8:
By default IAR EW 3.10 and later versions output UBROF9. Currently, Atmel Studio cannot read
this format. To force the debug format to UBROF8 open the project options dialog and change
the Output format setting to ubrof 8 (forced). Note that the default file name extension is
changed from '.d90' to '.dbg' when selecting this option. To keep the '.d90' extension, click the
Override default check button and change the extension.
4.18. Trace
In Atmel Studio, trace is provided on a plug-in basis. This means that different plugins separate from the
core of Atmel Studio will be the provider of the different graphics view to visualize trace.
In the realm of trace, there are some terminology that describe the different trace sources that a device
and tool combination supports. These high level source names are mapped to different architecture
specific trace sources.
The following sections will describe some of the high level trace sources that might be available, and how
it is mapped to the target architecture. Only a high level description of the different sources will be given,
as the device specific details are available in the respective datasheet.
Note: The architecture for discovering trace capabilities in Atmel Studio is based on what the chip itself
reports. This means that a debug session needs to be running so that the capabilities can be probed. This
means that when activating a trace source, Atmel Studio might fail if the device does not support the
source that was asked for during launch.
4.18.1. Application Output
Application output is a common name for a technique that provides what is known as a stimuli port. This
implies some mean for the application running on the device to output data to a debugger that is
connected.
4.18.1.1. ITM
ITM is an optional part of the debug system on ARM cores. The module provides a set of registers that an
application can write data to, that will be streamed out to the debugger.
4.18.1.2. IDR Events
When the application program writes a byte of data to the OCDR register of an AVR device while being
debugged, the debugger reads this value out and displays it as IDR events in the output window as
shown in the figure below. The OCDR register is polled at a given interval, so writing to it at a higher
frequency than the one specified for the debugger will not yield reliable results. The datasheet of the
device will explain how to check that a given value has been read.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
117
Figure 4-9. IDR Events
Note that the Output window does not have the “IDR Messages” drop down if no IDR events have been
sent from the debugger.
4.18.2. Program Counter Sampling
This trace source involves some sort of sample system that reads out the program counter of the device
periodically. This can then be used to graph where execution time is being spent, based on some
statistical average.
4.18.2.1. ARM Implementations
There are two ways of sampling the program counter on an ARM Cortex core. The first is using an
optional module in the debug system that emits the program counter to the debugger without any impact
on the core itself. The program counter is emitted on the SWO pin.
As not all Cortex implementation can emit the program counter, Atmel Studio also supports doing a
periodical readout of the program counter while to core is running. This is possible as most Cortex
devices supports readout of memory while the core is running, with a small impact on the running
application as the debug system needs to access the memory bus.
4.18.2.2. AVR 32-bit Implementation
Reading the program counter on the AVR 32-bit core is possible in the same way as mentioned in ARM
Implementations, as the core supports live readout of memory while the core is running.
4.18.3. Variable Watching
Watching variables are usually covered by data breakpoints, see Data Breakpoints. However, on some
systems it is also possible to make a data breakpoint emit the information to the debugger without halting
the core, meaning that it is possible to watch variables in applications that for instance has some sort of
external timing requirement that a data breakpoint would cause to fail.
4.18.3.1. ARM Implementations
Data breakpoints on a Cortex core can be changed to emit a trace packet if the debug system
implements the needed modules. This means that it is possible to get information about reads or writes to
a specific memory location without an interference with the execution on the core.
As a fallback to this, it is also possible to read a memory location at a given interval while the core is
executing. This will not be any specific event data, but means that if the core supports live memory
readout, it is possible to sample some parts of the memory. This has a minor impact on the execution, as
the debug system needs to have access to the memory bus.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
118
4.18.3.2. AVR 32-bit Implementation
The AVR 32-bit core also supports live readout of memory locations. This means that Atmel Studio can
poll a memory location while to core is executing, giving a statistical view of how the variable is changing
over time.
4.19. Trace View
The Trace View allows you to record the program counter trace when a target is running. The program
counter branches are mapped with the respective source line information. It also contains coverage and
statistics for the source lines executed. To open the Trace View, go to Debug → Windows → Trace
View. To use the functionality of the Trace View, a project has to be opened in Atmel Studio.
Figure 4-10. Opening Trace View From the Menu
4.19.1. Trace View Options
The Trace View toolbar has the following elements:
•
- Starts the program trace
•
- Stops the program trace
•
- Clears the program trace
•
- Toggles the highlighting of source code
•
- Configures the device to record the program trace
•
- Finds the exception record in the Trace Stack view
•
- Exports coverage statistics into an xml/xslt report
4.19.1.1. Starting the Program Trace
The Program Trace can be started by clicking the play button in the Trace View Window. The start button
is enabled during debug. Trace can be started and stopped any number of times in a debug session.
Starting a new trace session clears all trace information of the previous trace session.
Note: A region of SRAM has to be allocated to let the device record the trace. Refer to Trace View
Settings for more information.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
119
Figure 4-11. Trace View Window
4.19.1.2. Stop Trace
Trace can be stopped in run or debug mode. The trace session will be ended automatically without user
intervention when the debugging session ends.
4.19.1.3. Clear Trace
The clear button clears the trace in the Trace View Window. New trace information will be logged in the
same tool window with continuous sequence number. Clear can be done any number of times within a
trace session. Once cleared the trace data cannot be recovered.
4.19.1.4. Highlight Source Code
Highlight is a toggle button which toggles between highlighting and non-highlighting of the source code.
The source code that are covered are highlighted with a green color and remaining source lines with a
red color representing the uncovered source code for the current execution.
Figure 4-12. Code Highlight
Note: Only the compilable lines are taken into consideration. For example, lines with comments and
variable declaration are ignored.
4.19.1.5. Trace View Settings
The device has to be configured to record the trace information in SRAM. The allocated size for recording
the program trace can be configured from this setting. The memory can be allocated in:
• Source code, allocating a global array
• Linker scripts, reserving an amount of the memory map
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
120
Select the memory size to be allocated for recording the program trace. Copy the snippet of code
displayed in configuration window by clicking on the CopyToClipBoard button and paste into your source
code. Follow the instructions given in the dialog to enable the tracing capability.
Figure 4-13. Trace Settings Window Through Source Code
Note: If both the linker script and the source code is configured for trace, the linker script settings takes
the higher precedence over source code settings.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
121
Figure 4-14. Trace Settings Window through Linker Script
4.19.2. Trace View Interpretation
The Trace View window contains the following items:
• Trace Stack View
• Coverage View
4.19.2.1. Trace Stack View
Trace Stack View is populated with program trace information while the target is in a running or
debugging state.
Trace Stack View contains a sequence number, source and destination address, and a repeat count. A
new program trace record is shown when a branching instruction happens on the target, for example as a
function call or a return from a function.
• Sequence Number - Number that keeps track of the order of the record. This number is reset for
every trace session. This number will be continued without break when trace is cleared using clear
button from the toolbar.
• Source - Represents the instruction/source line from which the branch happened. For example, in a
function call, Source is the source line from where the function is being called.
• Destination - Represents the instruction/source line to which the branching happened. For example,
in a function call, Destination is the source code of the starting line of the function.
• Repeat Count - Represents the number of times the same source and destination combination
occurred consecutively. For example, if there is a delay which is logging the same packets, it will be
grouped together and number of times record occurrence is termed as repeat count
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
122
The source and destination contains instruction address, function name, source file name, and line
number. If the source line cannot be mapped only the instruction address is given. Double click on the
source or destination navigates the cursor in the editor to the appropriate line. Navigation keys Up, Down,
Left, Right, and Tab can be used to locate the source/disassembly view for the trace records.
The program trace that is shown in the TraceStack view are cut down to the latest 20000 records by
default. The threshold value can be changed using the slider.
The program trace records are highlighted with a yellow color when the branching instruction was not an
expected one. Unexpected branches usually happens due to some exception, and the entry and exit of
the exception handler is highlighted with yellow color. The branching inside the exception are not
highlighted.
Figure 4-15. Exception Record
Tip:
The next and previous exception records can be easily navigated to by using the up and down
arrow buttons in the trace view window tool bar.
There are some exceptional cases where some program traces could be missed. In that case there will
be a packet with red color which represents that there are some discontinuation of the program trace
information in the sequence. Since the number of missed packets are unknown, the sequence number
shown in the Trace Stack view will be continued without any break except adding a red colored packet
with a sequence number for it.
Note: The disassembly view is not supported when navigation keys are used, but it is supported when
the record is double clicked using mouse.
4.19.2.2. Coverage View
The coverage view shows statistics on the source covered as part of the current target execution. All the
files and functions are listed in the coverage view with the information of number of lines covered or
uncovered against the total number of lines in the source file.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
123
Figure 4-16. Code Coverage
Note: Only the compilable lines are taken into consideration for the statistics. For example, lines with
comments and variable declaration are not taken into account.
A coverage report can be exported. Click the export icon in the trace view toolbar to invoke the export
operation.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
124
5. Programming Dialog
5.1. Introduction
The Device Programming window (also known as the programming dialog), gives you the most low-level
control of the debugging and programming tools. With it, you can program the device's different
memories, fuses, and lockbits, erase memories, and write user signatures. It can also adjust some of the
starter kit properties such as voltage and clock generators.
Note: If you are editing a code project in Atmel Studio and want to see the results of a compilation by
downloading the code into the device, take a look at the Start without Debugging command. It is a sort of
one-click programming alternative to the programming dialog. See section Start without Debugging for
more information.
The programming dialog is accessible from a button on the standard toolbar or the menu Tools →
Device Programming.
Figure 5-1. Device Programming Icon
Figure 5-2. Opening Device Programming Dialog
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
125
Figure 5-3. Device Programming
The programming dialog contains the following options and tabs:
Top status bar
Tool
You can choose which tool you want to use from this drop-down menu. Only tools connected to the
machine are listed. Also, if a tool is used in a debug session, it will not be listed. Several tools of the same
type can be connected at the same time. In order to identify them, the serial number will be shown below
the tool name in the list.
When a tool is selected, the name (and serial number) will be shown in the title bar of the Device
Programming dialog.
Note: The Simulator will only offer limited support for the programming dialog features. The Simulator
has no persistent memory, so you will not be able to make permanent changes to any simulated devices.
Device
As soon as a tool is selected, the device list will show all devices supported by that tool. There are two
ways to select a device:
• Select from the list
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
126
Click on the arrow. This will reveal the list of supported devices. Click to select.
• Select by typing. In this example, we will select the ATxmega128A3:
2.1. Double-click in the text field to select the text already present.
2.2. Start typing some part of the device's name, in this example 128A. The list updates while
you type, showing all devices containing what is typed.
2.3. Press the Arrow Down keyboard button to move the selection into the list. Use the up and
down keys to navigate. Press ENTER to make a selection.
2.4. The ATxmega128A3 is now selected.
Note: A red border around the device selector indicates that the text entered is not a valid device
name. Continue typing until the device name is complete, or select from the list.
Interface
When a tool and a device is selected, the interface list will show the available interfaces. Only interfaces
available on both the tool and the device will appear in this menu.
Select the interface to use to program the AVR.
Apply button
When tool, device, and interface is selected, press the Apply button to make the selections take effect.
This will establish connection to the tool. The list on the left side of the window will be updated with the
relevant pages for the selected tool.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
127
If a different tool, device, or interface is selected, the Apply button must be pressed again, to make the
new selections take effect.
Device ID
Press the Read button to read the signature bytes from the device. The device's unique tag will appear in
this field, and can be used for tool compatibility checking and to obtain help either from customer support
or from the people at AVR Freaks®
.
Target voltage
All tools are capable of measuring the target's operating voltage. Press the refresh button to make a new
measurement.
A warning message will appear if the measured voltage is outside the operating range for the selected
device, and the target voltage box will turn red.
5.2. Interface Settings
The programming interfaces have different settings. Some interfaces have no settings at all, some
interfaces settings are only available on some tools. This section will describe all settings, but they are not
available for all tools and devices.
JTAG
If you have selected JTAG as the programming interface, clock speed, use external reset and daisy chain
setting may be available. This depends on the tool and device.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
128
JTAG Clock
JTAG clock is the maximum speed the tool will try to clock the device at. The clock range is different for
different tools and devices. If there are restrictions, they will be stated in a message below the clock
slider.
Use external reset
If checked the tool will pull the external reset line low when trying to connect to the device.
JTAG Daisy chain settings
Specify the JTAG daisy chain settings relevant to the device to program.
Target is not part of a daisy chain. Select this option when the target device is not part of a daisy chain.
Daisy chain-Manual. Allows you to manually configure the JTAG daisy chain in case you are
programming in a system-on-board.
• Devices before - specifies the number of devices preceding the target device.
• Instruction bits before - specifies the total size of the instruction registers of all devices, preceding
the target device.
• Devices after - specifies the number of devices following the target device.
• Instruction bits after - specifies the total size of the instruction registers of all devices, following
the target device.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
129
Daisy chain-Auto. Automatically detects the devices in the JTAG daisy chain. Allows you to select the
device in the JTAG daisy chain. Auto-detection is supported only for SAM devices.
To accept the changes and configure the tool, press the Set button.
PDI
The PDI interface has only one setting – the PDI clock speed.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
130
PDI Clock is the maximum speed the tool will try to clock the device at. The clock range is different for
different tools and devices. If there are restrictions, they will be stated in a message below the clock
slider.
To apply the changes and configure the tool, press the Set button.
The clock cannot be adjusted on all tools, so an empty Interface settings page will be presented.
5.3. Tool Information
Figure 5-4. Tool Info
The Tool information page contains a number of useful tool parameters.
Tool Name denotes the common name for the connected tool.
Debug Host is the debug session's host IP address for the remote debugging case. If the tool is
connected to your machine, then the loopback interface IP (127.0.0.1) will show.
Debug Port is the port opened specifically for the remote debugging access to the debugging tool. The
port is automatically assigned when Atmel Studio starts, and is usually 4711.
Serial number - tool serial number.
Connection - Microsoft Driver Framework Method's name used to connect the Tool on your PC.
xxx version - Firmware, hardware and FPGA file versions are listed here.
Using the link on the bottom of the dialog you can access extensive information on your tool online.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
131
5.4. Board Settings/Tool Settings
Some tools (Power Debugger, STK500, STK600, QT600) have on-board voltage and clock generators.
They can be controlled from the Board settings/Tool settings page.
5.4.1. Power Debugger
The Power Debugger has a single voltage source and two channels of voltage/current measurement.
Figure 5-5. Power Debugger Tool Settings
The voltage output (VOUT) is adjusted by the slider, or by typing a voltage in the Generated text boxes
below the slider.
After adjusting the set-point, press the Write button to apply the changes. The value is then sent to the
tool, and the measured value is read back.
Press the Read button to read both the set-point (Generated) and the Measured values from the Power
Debugger.
Note: There may be slight differences between the Generated and the Measured voltages.
The output voltage range is 1.6V to 5.5V.
The Channel A and Channel B measurements are snapshots of analog readings taken by the Power
Debugger. The tool is optimized for real-time monitoring of voltage and current, and this snapshot is thus
approximate. It does not perform calibration compensation, and readings are locked in the highest-current
range. For best results, use the Atmel Data Visualizer.
Note: When no load is connected to a measurement channel, non-zero measurements can be
expected.
5.4.2. STK600
The STK600 has three voltage sources and one clock generator.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
132
Figure 5-6. STK600 Board Settings
The set-points of the three voltage sources (VTG, ARef0, and ARef1) are adjusted by the means of three
sliders. It is also possible to type a voltage in the Generated text boxes below the sliders. When you drag
the sliders, the text boxes will update. And when you type a value in the text box, the slider will move.
After adjusting the set-points, press the Write button to apply the changes. The values are sent to the
tool, and measure values are read back.
Measurements are shown in the Measured row, and shown as blue columns as part of the slider controls.
The measured values cannot be edited.
Press the Read button to read both the set-point (Generated) and the Measured values from the
STK600.
Note: What is the difference between the Generated and the Measured voltages? The generated
voltage is the setting on the adjustable power supply, the measured voltage is the readout from the builtin
volt meter. If the measured value is different from the generated voltage, this may indicate that the
target circuitry draws a lot of current from the generator.
Note: If the VTARGET jumper on STK600 is not mounted, the measured voltage will be 0, unless an
external voltage is applied to the VTARGET net.
The Clock generator is also adjusted by dragging the slider or typing into the text box below. Press the
Write button to apply the new value.
5.4.3. QT600
The QT600 has only one setting, the VTarget voltage. This voltage can be set to five fixed voltages: 0,
1.8, 2.7, 3.3, and 5V. Press the Write button to apply the changes.
The actual VTarget value is read back automatically when pressing the Write button. It is also possible to
read it back manually using the Read button.
5.4.4. STK500
STK500 has settings similar to the STK600, but only one Aref voltage and combined generated/measured
values.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
133
5.5. Card Stack
The STK600 uses a combination of routing and socket cards to let all AVR devices to be mounted. Given
the device, only certain combinations of routing and socket cards are valid. The Card stack page has
information about this.
Figure 5-7. Card Stack
The card stack page tells which cards are mounted on the STK600 and if they support the selected
device. If they do match, a list of devices supported by that card combination is listed.
If the mounted cards do not match, a list of suggested card combinations will be listed.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
134
5.6. Device Information
Figure 5-8. Device Information
The device information page contains basic information on the selected device. When the page is
accessed, it will try to read the JTAG (or device) signature from the connected device.
In the upper part of the dialog you can see the device name, its signature, the JTAG part identification
number, and the device revision (extracted from the JTAG signature).
In the lower part of the dialog you see the device variants and characteristics of each variant. Acceptable
voltage range, followed by maximum operating clock speed, and the sizes of on-chip memories.
The two links on the bottom of the dialog offer you to see a slightly more detailed device information in the
purchase catalog online, or to download a complete datasheet of the target device.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
135
5.7. Oscillator Calibration
Figure 5-9. Oscillator Calibration
Oscillator Calibration Byte(s) for ATtiny and ATmega parts
From the Advanced tab you can read the Oscillator Calibration Byte(s) for ATtiny and ATmega parts. The
oscillator calibration byte is a value that can be written to the OSCCAL register found in selected devices,
in order to tune the internal RC Oscillator to run as close to a chosen clock frequency as possible.
Program
The oscillator calibration byte is stored in the device during manufacturing and can not be erased or
altered by the user. It is automatically transferred to the OSCCAL register during device start-up, or set
during program initialization, depending on the device. On devices where the application sets it during
program initialization, it must be transferred to FLASH or EEPROM first, using the programming dialog or
the command line tools.
Reading and Writing the Oscillator Calibration Byte for ATtiny and ATmega parts
The calibration value is read from the storage in the device and shown in the Value text box by pressing
the Read button.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
136
The calibration byte is programmed into FLASH or EEPROM memory by pressing the Write button.
Memory type and address must be specified first.
5.8. Memories
Figure 5-10. Memories Programming
From the Memories tab you can access all the programmable memories on the target device. Memory is
erased by first selecting the memory type and then clicking on the Erase button. Selecting Erase Chip
will erase the entire contents of the device, including FLASH, EEPROM (unless the EESAVE fuse is
programmed), and lock-bits, but not Userpages if the device contains this.
Program
To program a file into the device's Flash memory, write the full path and file name in the combo box in the
flash section. Or, select the file by pressing the browse button (...).
Now, press the Program button to program the file into the memory.
If the Erase device before programming check box is checked, a chip erase operation will be
performed before the programming operation starts.
If the Verify device after programming check box is checked, the content will be verified after the
programming operation is done.
Some devices can also be programmed through a flashloader. This is mainly an advanced technique, but
it will usually give a significant speedup in the programming speed. For devices where this is supported, a
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
137
checkbox will be shown named Program flash from RAM. If this box is checked, the base address of the
location of the flashloader needs to be given.
Verify
To verify the flash content of the device, first select the file you want to verify against. Then press the
Verify button.
Read
The contents of the Flash memory can be read out in Intel®
hexadecimal file format, using the Read
button. Pressing the Read button will bring up a dialog offering you to specify where the file will be saved.
EEPROM
The device's EEPROM memory can be programmed in a similar way.
User Signatures
The XMEGA device's User Signature memory can be programmed the same way.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
138
5.9. Fuse Programming
Figure 5-11. Fuse Programming
The Fuses page presents the fuses of the selected device.
Press the Read button to read the current value of the fuses, and the Program button to write the current
fuse setting to the device. Fuse settings are presented as check boxes or as drop down lists.
Detailed information on which fuses are available in the different programming modes and their functions
can be found in the device datasheet. Note that the selected fuse setting is not affected by erasing the
device with a chip-erase cycle (i.e. pressing the Chip Erase button on the Memories page).
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
139
Fuse values can also be written directly into the fuse registers in the lower pane as hexadecimal values.
Auto read If this check box is checked, the fuse settings will be read from the device
each time you enter the fuse page.
Verify after
programming
When this check box is checked, the settings will be verified after a
programming operation is completed.
The appearance of the fuse glyph describes whether the fuse information is up to date compared to the
state of the device.
the fuse value is up to date. i.e the same state as in the device.
the fuse has been modified by the user and it is not yet programmed into the device.
the fuse state is unknown, it has not been read from the device, nor modified by the user.
5.10. Lock Bits
The lock bit page is similar to the fuse page. For usage, see section Fuse Programming.
5.11. Production Signatures
The production signature page is only visible for AVR XMEGA devices and shows factory programmed
data in the production signature row. It contains calibration data for functions such as oscillators and
analog modules. The production signature row can not be written or erased.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
140
Figure 5-12. Production Signatures
5.12. Production Files
The ELF production file format can hold the contents of both Flash, EEPROM, and User Signatures
(XMEGA devices only) as well as the Fuse- Lockbit configuration in one single file. The format is based
on the Executable and Linkable Format (ELF).
The production file format is currently supported for tinyAVR, megaAVR, and XMEGA. See Creating ELF
Files with Other Memory Types for description on how to configure the project in order to generate such
files.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
141
Figure 5-13. Production Files Programming
Program device from ELF production file: To program your device from an ELF file, you must first
select a source file by typing its full path into the combo box, or by pressing the browse button .
Depending on the contents of your file, check boxes for the different memory segments will be activated.
It is possible to select one or several of the memory segments that the ELF production file contains. You
can then program and verify the device with the content of these segments in one single operation. Select
which memory segments you want to program ticking off the corresponding check boxes.
Select the Erase memory before programming check box, if you want an erase operation to be
performed before the programming operation.
Note: The erase memory operation will depend on the device selection. For tinyAVR and megaAVR,
both Flash, EEPROM, and lockbits will be erased (chip erase) independent of which memories are
selected, while for XMEGA only the selected memories will be erased.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
142
Select the Verify device after programming check box, if you want the contents to be verified after the
programming operation is done.
Select the Verify Device ID check box, if you want to verify the device id stored in the file (signature
bytes) with the connected device.
Now, press the Program button to program the file into the memory.
You can verify the contents of the device against an ELF file by pressing the Verify button. The
verification will only verify the contents of the selected memory segments.
Figure 5-14. Production Files Creation
Save to ELF production file: Prior to creating the ELF file, specify the input file path for FLASH,
EEPROM, and Usersignature on the production file tab. Then configure the Fuse and Lockbits on the
corresponding tab and program it. The Fuse and Lockbits, which are programmed in the device will be
taken as input while creating ELF file. Back on the production file tab, press the "Save" button" to
generate the ELF file.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
143
You must specify which segments are to be present in the production ELF file by ticking the
corresponding check boxes.
5.13. Security
The security bit allows the entire chip to be locked from external JTAG or other debug access for code
security. Once set, the only way to clear the security bit is through the Chip Erase command.
Figure 5-15. Security Page
To check the state of the security bit, press the Read button on the Security page of the programming
dialog. The value should now read Cleared or Set. Set meaning that the security bit is set, and Cleared
meaning that it is not set. If the Auto Read check box is ticked off, the Read operation will be performed
automatically when the Security page is opened.
To set the security bit, simply press the Set button on the Security page of the programming dialog. Now
the device is locked for all further JTAG or aWire access except for the Chip Erase command.
Locked device
When the security bit is set, the device is locked for most external debug access. Attempts to program or
read any memories or fuses, will cause an error message to appear.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
144
Figure 5-16. Security Bit Error
To unset the security bit, issue the Chip Erase command. This can be done from the Memories page, see
Memories.
5.14. Automatic Firmware Upgrade Detection
As mentioned in the Firmware Upgrade section, you may encounter a dialog stating that your tool's
firmware is out of date when you open the Device Programming dialog.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
145
6. Miscellaneous Windows
6.1. Device Pack Manager
The Device Pack Manager is used to manage the devices supported by Atmel Studio.
The Device Pack Manager is launched from Tools → Device Pack Manager.
Figure 6-1. Device Pack Manager Menu
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
146
Figure 6-2. Device Pack Manager
The Device Pack Manager consists of two panes. The left pane shows the list of packs that are installed.
The right pane shows the devices that are provided by the pack selected in the left pane.
Packs can have any of the following statuses:
Up to date Pack is already up to date and latest.
Update Available New update is available.
Not Installed Pack is not installed, but can be downloaded.
Actions
Install selected packs Download and install all packs that have been selected using the check-boxes
besides the version.
Install all updates Download and install all available updates.
Browse pack file Install an already downloaded pack file.
Uninstall Uninstalls all packs that have been selected using the check-boxes besides the
version.
Check for Updates Check for new and updated packs.
Search The search box can be used to search after a specific pack, or a device in any
of the packs.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
147
Reset cache Resetting the cache will re-index all installed packs. This does not uninstall or
remove anything. It is in the Advanced menu.
Note: After installing, updating, or removing packs, Atmel Studio has to be restarted before the changes
becomes visible.
6.2. User Interface Profile Selection
Different user interface profiles targeted for different use is available in Atmel Studio.
The user interface profile controls the visibility of menus, window layouts, toolbars, context menus, and
other elements of Atmel Studio. The following modes are available:
Standard The default profile. Includes the most used windows and menus.
Advanced The profile used in previous versions of Atmel Studio. This profile includes advanced
debugging and re-factoring tools.
Figure 6-3. Profile Selection
The profile selection window is shown the first time Atmel Studio is started. Selecting a profile in the list
will show a description of the profile. Clicking the Apply button applies the profile to Atmel Studio.
The profile can be changed at any time by navigating to Tools → Select Profile, or by clicking the profile
name that is displayed in the top right corner of Atmel Studio.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
148
Figure 6-4. Selected Profile
When switching profiles, any changes done to the active profile is saved. Going back to the previous
profile will restore the changes as well as the profile.
Using the Reset option discards any changes saved to the profile and restores it to the default profile.
6.3. Available Tools View
6.3.1. Introduction
The Available Tools view (View → Available Atmel Tools) contains a list of all connected tools such as
programmers, debuggers and starter kits. The Simulator is always present. Other tools will show up when
they are connected to the PC.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
149
6.3.2. Tool Actions
The following actions can be selected by right clicking tools in the Available Tools view:
Device Programming Opens the Device Programming window with the tool preselected.
Self test Some tools are capable of performing a self test. Follow the displayed
instructions.
Add target Adds a tool to the list of available tools that is not auto-detectable. See Add a
Non-detectable Tool for more information.
Upgrade Starts the firmware upgrade tool with the selected tool.
Show Info Window Shows the Tool Info window. Not all tools supports this feature. See Tool Info
Window for more information.
6.3.3. Add a Non-detectable Tool
The STK500 does not have a USB connection, and cannot be automatically detected by Atmel Studio. So
it must be added to the list of available tools before it can be used by the Device Programming window.
To add an STK500, right click inside the Available Tools view, select Add target and select the STK500
as the tool and the COM port your STK500 will be connected to.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
150
Press the Apply button, and the STK500 will be displayed in the list of available tools.
Note: An STK500 that has been added will be visible in the Available Tools view event even if no
STK500 is connected to the specified COM port.
If you want to remove STK500 from the list, you can right click on it and select Remove from the context
menu.
6.3.3.1. Add J-Link over IP
In the Add target dialog, it is possible to add a remote Segger J-Link debug probe. Both using a debug
probe with built-in ethernet such as the J-Link PRO3
and any other Segger probe by using the J-Link
Remote Server software4
.
Figure 6-5. Add J-Link over IP
To add a debug probe that is connected to a J-Link Remote Server, choose Connect by hostname and
enter the IP address or the hostname of the computer running the J-Link Remote Server. If the J-Link
3 See https://www.segger.com/jlink-pro.html
4 See https://www.segger.com/jlink-remoteserver.html
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
151
Remote server is running on a non-standard port5
then the port also needs to be entered. If the J-Link
Remote Server is running on the default port, the port can be left empty.
To add a debug probe that has built-in ethernet, choose Connect by serial number in the Add target
dialog, and enter the serial number of the debug probe.
6.4. Tool Info Window
The Tools Info window shows information about connected tools. At the moment, only the Xplained Pro
series is supported.
5 The standard port of the J-Link Remote Server is port 19020
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
152
Figure 6-6. The Tool Info Window
When a tool is connected, the window will open. It has a short description about the tool, an image of the
tool, and a section of links to then user guide, relevant datasheets on the internet, etc.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
153
There is also a table with technical details about the tool, such as firmware version, serial number, etc.
6.4.1. Xplained Pro Kits
The Xplained Pro family of boards supports a range of expansion boards. When an Xplained Pro board is
connected, the Tool Info window will show a list on the left side of the window, containing the main board,
and all connected expansions. Click on the main board and the expansion to see details about the
different boards.
6.4.2. Disable the Tools Info Window
By deselecting the Show page on connect check box, the window will not automatically open when
Atmel Studio is open and you connect the kit.
This feature works on a per-tool basis, which means you can select for every tool you have, if they should
show the Tool Info window when connected.
6.4.3. Manually Showing the Window
If you want to see the Tool Info window again after it has been closed, you can right-click on the tool in
the Available Tools view, and select Show Info Window.
Figure 6-7. Show Tool Info Window
See also Available Tools View.
6.5. Firmware Upgrade
6.5.1. Introduction
Atmel Studio will include the latest firmware for all Atmel tools. New firmware may provide support for new
devices and bugfixes.
6.5.2. Automatic Upgrade
Atmel Studio will automatically upgrade the tool's firmware when needed. A potential firmware upgrade is
triggered once you start using a tool. Examples: the first time you launch a debug session or the first time
you select the tool in the Device Programming dialog.
The tool cannot be used by Atmel Studio if the user chooses not to upgrade.
You can also check for firmware upgrades by using the Available Tools view (View → Available Atmel
Tools). Right click on a tool and select Upgrade.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
154
For a description on how to do manual upgrade, downgrade and upgrade with a custom firmware image,
see Manual Upgrade.
6.5.3. Manual Upgrade
Atmel Studio includes a command line utility called atfw.exe which can be used to do manual upgrade
of most Atmel tools. atfw.exe is installed in the atbackend subfolder.
atfw.exe can be used to:
• Perform upgrade from a script
• Upgrade using a custom firmware file
• Read out firmware version
For details on how to upgrade using this utility, execute atfw.exe -h.
Note: If a tool is locked in firmware upgrade mode, and normal reset does not restore normal operation,
a forced firmware upgrade should reset the tool to a working state.
To do a firmware upgrade on a tool already in upgrade mode, invoke atfw the same way as normal
firmware upgrade. Some warnings may be displayed as the tool is unable to switch the tool to upgrade
mode, but should proceed with the upgrade.
If a tool listing is done, the tool will have a name that is related to the mode it is in. atfw should however
be invoked with the tool name as it is presented to the user in normal operation.
6.6. Find and Replace Window
You can use the Find and Replace window to search for text strings, expressions, or entity names within
the code of your documents. To access this window, from the Edit menu, click Find and Replace, and
then select one of the options listed.
The Find and Replace window contains a toolbar with two drop-downs, one for find operations and one
for replace operations. When you select an operation, the corresponding options for the operation are
displayed. You can search and replace in one or more files or an entire solution for text, code, or symbols.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
155
Figure 6-8. Find and Replace
Quick Find allows you to search the code of one or more open documents for a string or expression. The
selection moves from match to match, allowing you to review each match in its surrounding context.
Note: The matches found are not listed in the Find Results window.
You can use any of the following methods to display Quick Find in the Find and Replace window.
To display Quick Find
1. On the Edit menu, expand Find and Replace.
2. Choose Quick Find.
-orIf
the Find and Replace window is already open, on the toolbar, click the triangular View button on
the left drop-down and then choose Quick Find.
Quick Find can search through a document either forward or backward from the insertion point. The
search automatically continues past the end or start of the document into the unsearched portion. A
message appears when the entire document has been searched.
Find what
These controls allow you to specify the string or expression that will be matched.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
156
Reuse one of the last 20 search strings by selecting it from this drop-down list, or type a new text string or
expression to find.
Table 6-1. Quick Find
Option Description
[string with
wildcards]
If you want to use wildcards such as asterisks (*) and question marks (?) in your
search string, select the Use check box under Find options and then choose
Wildcards.
[regular expression] To instruct the search engine to expect regular expressions, select the Use check
box under Find options and then choose Regular expressions.
Expression Builder
This triangular button next to the Find what field becomes available when the Use check box is selected
in Find options and Regular Expressions appears in the drop-down list. Click this button to display a list
of wildcards or regular expressions, depending upon the Use option selected. Choosing any item from
this list adds it into the Find what string.
Find Next
Click this button to find the next instance of the Find what string within the search scope chosen in Look
in.
Bookmark All
Click this button to display blue bookmarks at the left edge of the code editor to indicate each line where
an instance of the Find what string occurs.
Look in
The option chosen from the Look in drop-down list determines whether Quick Find searches only in
currently active files.
Look in
Select a predefined search scope from this list.
Table 6-2. Look in Scopes
Option Description
Selection This option is available when text is selected in the code editor. Searches only the
selected text in the currently active document.
The name of this option indicates the location of the insertion point in the code editor.
Searches within the current procedure, module, paragraph, or code block.
Current
Document
This option is available when a document is open in an editor. Searches only the
active document for the Find what string.
Current Window This option is available when a searchable tool window, such as the View in Browser
window, has focus. Searches all content displayed in this window for the Find what
string.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
157
Option Description
All Open
Documents
Searches all files currently open for editing as if they were one document. When the
starting point of the search is reached in the current file, the search automatically
moves to the next file and continues until the last open file has been searched for the
Find what string.
Current Project Searches all files in the current project as if they were one document. When the
starting point of the search is reached in one file, the search continues in the next
until the last file in the project has been searched.
Find options
You can expand or collapse the Find options section. The following options can be selected or cleared:
Match case
Only displays instances of the Find what string that are matched both by content and by case. For
example, a search for "MyObject" with Match case selected will return "MyObject" but not "myobject" or
"MYOBJECT".
Match whole word
Only displays instances of the Find what string that are matched in complete words. For example, a
search for "MyObject" will return "MyObject" but not "CMyObject" or "MyObjectC".
Search up
When selected, files are searched from the insertion point to the top of the file.
Search hidden text
When selected, the search will also include concealed and collapsed text, such as the metadata of a
design-time control; a hidden region of an outlined document; or a collapsed class or method.
Use
Indicates how to interpret special characters entered in the Find what or Replace with text boxes. The
options include:
Table 6-3. Search with Special Characters
Option Description
Wildcards Special characters such as asterisks (*) and question marks (?) represent one or
more characters. For a list, see Wildcards (Visual Studio).
Regular Expressions Special notations define patterns of text to match. For a list, see Regular
Expressions (Visual Studio).
Toolbar
A toolbar, with two drop-downs, appears at the top of the Find and Replace window. These drop-downs
allow you to choose the type of search or replace you intend to perform and changes the options
displayed in the window to match.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
158
Table 6-4. Find and Replace Toolbar
Drop-down View menu
Find (left drop-down) Quick Find
Find in Files
Find Symbol
Replace (right drop-down) Quick Replace
Replace in Files
Figure 6-9. Find Results
Figure 6-10. Find Symbol Results
6.7. Export Template Wizard
Atmel Studio project and item templates provide reusable and customizable project and item stubs that
accelerate the development process because users do not have to create new projects and items from
scratch.
Note: This functionality is inherited from Microsoft Visual Studio®
and the documentation from Microsoft
goes beyond what is mentioned in this section. See MSDN for in-depth information.
Open the Export Template Wizard by clicking File → Export Template.... This opens the Export Template
Wizard shown in the figure below.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
159
Figure 6-11. Export Template Wizard...
6.7.1. Project Template
A Project template is a template that contains a whole project. This template can be redistributed to other
users to ease setup of a default project. The code, which is to be template, can contain parameters that
are substituted on creation. See Default Template Parameters for information on this.
The template wizard is mostly self explanatory, and on completion the created template will be available
in the File → File → New Project... dialog.
6.7.2. Item Template
An Item template is a template that contains a single file or collection of files. The code which is to be
templated can contain parameters that are substituted on creation. See Default Template Parameters for
information on this.
The template wizard is mostly self explanatory, and on completion the created template will be available
as a file type when files are added to the project.
6.7.3. Template Parameters
All templates support parameter substitution to enable replacement of key parameters, such as class
names and namespaces, when the template is instantiated. These parameters are replaced by the
template wizard that runs in the background when a user clicks OK in the New Project or Add New Item
dialog boxes.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
160
6.7.3.1. Declaring and Enabling Template Parameters
Template parameters are declared in the format $parameter$.
6.7.3.2. Default Template Parameters
The table below lists the reserved template parameters that can be used by any template.
Note: Template parameters are case-sensitive.
Table 6-5. Template Parameters
Parameter Description
$itemname$ The name provided by the user in the Add New Item dialog box
$machinename$ The current computer name
$projectname$ The name provided by the user in the New Project dialog box
$registeredorganization$ The registry key value from HKLM\Software\Microsoft\Windows NT
\CurrentVersion\RegisteredOrganization
$safeitemname$ The name provided by the user in the Add New Item dialog box, with all
unsafe characters and spaces removed
$safeprojectname$ The name provided by the user in the New Project dialog box, with all unsafe
characters and spaces removed
$time$ The current time in the format DD/MM/YYYY 00:00:00
$userdomain$ The current user domain
$username$ The current user name
$year$ The current year in the format YYYY
$guid[1-10]$ A GUID used to replace the project GUID in a project file. You can specify up
to 10 unique GUIDs (for example, guid1)
6.7.3.3. Custom Template Parameters
You can use the CustomParameter element in your .vstemplate file to add new parameters to a
template.
1. Locate the TemplateContent element in the .vstemplate file for the template.
2. Add a CustomParameters element and one or more CustomParameter child elements as
children of the TemplateContent element.
Figure 6-12. Adding Custom Parameters
...
3. Use the parameter in one or more of the code files in the template as shown in Default Template
Parameters.
More information on this can be found on MSDN.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
161
6.8. Kit Mode Setting
Some kits operate with different modes. This window can be used to change the mode.
Figure 6-13. Kit Mode Settings
Some examples of the choices that can be made are listed in the following table.
Select mode Persistent Resulting mode
Mass Storage
Yes
Auto, enumerating as a Mass Storage Device kit
DGI Auto, enumerating as a DGI kit
Mass Storage
No
Mass Storage, enumerating once as a Mass Storage Device kit before
returning to the previous mode
DGI DGI, enumerating once as a DGI kit before return to the previous mode
Note: When the persistent mode is used, the kit will reboot into Auto mode, since the persistent choice
changes the kit default.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
162
7. Atmel GNU Toolchains
Atmel GNU Toolchains are a set of standalone command line programs used to create applications for
Atmel SAM and Atmel AVR microcontrollers.
7.1. GNU Compiler Collection (GCC)
The GNU Compiler Collection is used by Atmel Studio at the build stage. The architecture specific
versions of the GNU Compiler Collection supports c-code compilation, assembly and linking of C and C+
+.
The AVR GNU compiler collection is distributed under the terms of the GNU General Public License,
http://www.gnu.org/licenses/gpl.html. A copy of this license is also found in the installation folder of Atmel
Studio .
7.2. ARM Compiler and Toolchain Options: GUI
To get help about ARM GCC Toolchain, you can do the following:
• For general information about GCC, visit the official GNU GCC web site
• Alternatively, you can write arm-none-eabi-gcc --help and see the explanation of some of the
parameters in the command output
This section illustrates the GUI options that are available for the ARM GNU Toolchain in Atmel Studio.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
163
Figure 7-1. ARM GNU Toolchain Properties
Table 7-1. ARM GNU Common Options
Option Description
Thumb(-mthumb)/Arm(-marm) Switch between Arm and Thumb processor mode
Table 7-2. ARM GNU C Compiler Options
Option Description
Preprocessor options
-nostdinc Do not search system include directories
-E Preprocess only; Do not compile, Assemble or link
Symbols options
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
164
Option Description
There one can define (-D) or undefine (-U) a number of in-source symbols. New symbol declarations
can be added, modified, or reordered, using the interface buttons below:
•
Add a new symbol. This and all following icons are reused with the same meaning in other parts
of Atmel Studio interface.
•
Remove a symbol.
•
Edit symbol.
•
Move the symbol up in the parsing order.
•
Move the symbol down in the parsing order.
Include directories
Default Include Path Enabling this option will add the include path that are
specific for the selected SAM device
Contains all the included header and definition directories, can be modified, using the same interface as
symbols
Optimization options
Optimization level (drop down menu): -O0, -
O1, -O2, -O3, -Os
No optimization, optimize for speed (level 1 - 3),
optimize for size
Other optimization flags (manual input form) Here you should write optimization flags specific for the
platform and your requirements
-ffunction-sections Place each function into its own section
-funsafe-math-optimizations Enable unsafe match optimizations
-ffast-math Enable fast math
-fpic Generate position independent code
Debug options
Debug level (drop down menu): none, -g1, -
g2, -g3
Specifies the level of tracing and debugging code and
headers left or inserted in the source code
Other debug options (form field) Architecture specific debug options
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
165
Option Description
-pg Generate gprof information
-p Generate prof information
Warning messages output options
-Wall All warnings
-Werror Treat all warnings as errors
-fsyntax-only Check syntax only
-pedantic Check conformity to GNU, raise warnings on nonstandard
programming practice
-pedantic-errors Same as above, plus escalate warnings to errors
-w Inhibits all warnings
Miscellaneous options
Other flags (form field) Input other project-specific flags
-v Verbose (Display the programs invoked by the compiler)
-ansi Support ANSI programs
-save-temps Do not delete intermediate files
Option Description
Table 7-3. ARM GCC Linker Options
Option Description
-Wl -nostartfiles Do not use standard files
-Wl -nodefault Do not use default libraries
-Wl -nostdlib No start-up or default libraries
-Wl -s Omit all symbol information
-Wl -static Link statically
-Map Generates Map file
Libraries options
Libraries -Wl, -l (form field) You can add, prioritize or edit library names here, using those
buttons: , , , ,
Library search path -Wl, -L (form field) You can add, prioritize or edit path where the linker will search
for dynamically linked libraries, same interface as above
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
166
Option Description
Optimization options
-Wl, -gc-sections Garbage collect unused sections
-funsafe-math-optimizations Enable unsafe math optimizations
-ffast-math Enable fast math
-fpic Generate position independent code
Miscellaneous options
Other linker flags (form field) Input other project-specific flags
Option Description
Linker Scripts
• In "linker->miscellaneous->linker flags" ($LinkerScript_FLASH) is added by
default. It will be replaced with the appropriate (device_name)_flash.ld file during Build. Similarly
($LinkerScript_SRAM) will be replaced with the appropriate (device_name)_sram.ld file.
• You can always override the default flash linker scripts by replacing ($LinkerScript_FLASH) or
($LinkerScript_SRAM) with your custom linker script option -
T"custom_linker_script.ld".
Note: These device specific linker scripts will be available in the "ProjectFolder/Linkerscripts" directory.
In case of changing the device after project creation, Atmel Studio will automatically add the correct linker
scripts for the selected device.
ARM Assembler Options
Table 7-4. Arm Assembler Options
Option Description
Optimization options
Assembler flags (form field) Miscellaneous assembler flags
Include path (form field) You can add, prioritize or edit path to the architecture and
platform specific included files here
-v Announce version in the assembler output
-W Suppress Warnings
Debugging options
Debugging level (drop down menu) None ,
(-g).
Enable debugging symbols and debugging source insertion
Option Description
ARM Preprocessing Assembler Options
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
167
Table 7-5. ARM Preprocessing Assembler Options
Option Description
Optimization options
Assembler flags (form field) Miscellaneous assembler flags
Include path (form field) You can add, prioritize or edit path to the architecture and
platform specific included files here
-v Announce version in the assembler output
-W Suppress Warnings
Debugging options
Debugging level (drop down menu) None ,
-Wa -g.
Enables debugging symbols and debugging source
insertion
Option Description
7.3. ARM GNU Toolchain Options
7.3.1. ARM/GNU Common Options
• Thumb(-mthumb)/Arm(-marm)
Allows you to select the processor mode.
7.3.2. Compiler Options
7.3.2.1. Preprocessor
• -nostdinc
Do not search the standard system directories for header files. Only the directories you have
specified with -I options (and the directory of the current file, if appropriate) are searched.
• -E
Stop after the preprocessing stage; do not run the compiler proper. The output is in the form of
preprocessed source code, which is sent to the standard output. Input files which don't require
preprocessing are ignored.
7.3.2.2. Symbols
• -D
• -D name
Predefine name as a macro, with definition 1.
Eg:
• -D name=value
Predefine name as a macro, with definition value. The contents of definition are tokenized
and processed as if they appeared during translation phase three in a #define directive. In
particular, the definition will be truncated by embedded newline characters.
• -U
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
168
Cancel any previous definition of name, either built in or provided with a -D option.
-D and -U options are processed in the order they are given on the command line. All -imacros file and -
include file options are processed after all -D and -U options.
7.3.2.3. Directories
• -I dir
Add the directory dir to the list of directories to be searched for header files. Directories named by -I
are searched before the standard system include directories. If the directory dir is a standard
system include directory, the option is ignored to ensure that the default search order for system
directories and the special treatment of system headers are not defeated .
7.3.2.4. Optimization
• There is a general switch ‘-O’ which specifies the level of optimization used
when generating the code:
– -Os
Signal that the generated code should be optimized for code size. The compiler will not care
about the execution performance of the generated code.
– -O0
No optimization. GCC will generate code that is easy to debug but slower and larger than with
the incremental optimization levels outlined below.
– -O1 or -O
This will optimize the code for both speed and size. Most statements will be executed in the
same order as in the C/C++ code and most variables can be found in the generated code.
This makes the code quite suitable for debugging. This is default.
– -O2
Turn on most optimizations in GCC except for some optimizations that might drastically
increase code size. This also enables instruction scheduling, which allows instructions to be
shuffled around to minimize CPU stall cycles because of data hazards and dependencies, for
CPU architectures that might benefit from this. Overall this option makes the code quite small
and fast, but hard to debug.
– -O3
Turn on some extra performance optimizations that might drastically increase code size but
increase performance compared to the -O2 and -O1 optimization levels. This includes
performing function inlining
• Other optimization options
– -ffunction-sections
– -fdata-sections
Place each function or data item into its own section in the output file if the target supports
arbitrary sections. The name of the function or the name of the data item determines the
section's name in the output file.
Only use these options when there are significant benefits from doing so. When you specify
these options, the assembler and linker will create larger object and executable files and will
also be slower.
– -funroll-loops
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
169
Perform loop unrolling when iteration count is known. If code size is not a concern then some
extra performance might be obtained by making gcc unroll loops by using the ‘-funroll-loops’’
switch in addition to the ‘-O3’ switch.
7.3.2.5. Debugging
• -g level (Debugging level)
• -g1
It produces minimal information, enough for making backtraces in parts of the program that
you don't plan to debug. This includes descriptions of functions and external variables, but no
information about local variables and no line numbers.
• -g2
It is the default debugging level.
• -g3
It includes extra information, such as all the macro definitions present in the program. Some
debuggers support macro expansion when you use -g3.
7.3.2.6. Warnings
• -Wall
Show all warnings.
• -Werror
Show warnings as errors.
• -fsyntax-only
Check the code for syntax errors, but don't do anything beyond that.
• -pedantic
Issue all the warnings demanded by strict ISO C, reject all programs that use forbidden extensions,
and some other programs that do not follow ISO C. Valid ISO C programs should compile properly
with or without this option (though a rare few will require -ansi or a -std option specifying the
required version of ISO C). However, without this option, certain GNU extensions and traditional C
features are supported as well. With this option, they are rejected.
• -pedantic-errors
Pedantic warnings are produced as errors.
• -w
Inhibit all warning messages.
7.3.2.7. Miscellaneous
• -v
Verbose option. It prints (on standard error output) the commands executed to run the stages of
compilation. Also print the version number of the compiler driver program and of the preprocessor
and the compiler proper.
• -ansi
Support ANSI programs. This turns off certain features of GCC that are incompatible with ISO C90
(when compiling C code). For the C compiler, it disables recognition of C++ style // comments as
well as the inline keyword. The -ansi option does not cause non-ISO programs to be rejected
gratuitously. For that, -pedantic is required in addition to -ansi.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
170
7.3.3. Linker Options
7.3.3.1. General
• -Wl,option
Pass option as an option to the linker. If option contains commas, it is split into multiple options
at the commas. You can use this syntax to pass an argument to the option. For example, `-Wl,-
Map,output.map' passes `-Map output.map' to the linker.
• -Wl, -nostartfiles
Do not use the standard system startup files when linking. The standard system libraries are used
normally, unless -nostdlib or -nodefaultlibs is used.
• -Wl,-nodefault
Do not use the standard system libraries when linking. Only the libraries you specify will be passed
to the linker, options specifying linkage of the system libraries, such as -static-libgcc or -
shared-libgcc, will be ignored. The standard start-up files are used normally, unless -
nostartfiles is used. The compiler may generate calls to memcmp, memset, memcpy and
memmove. These entries are usually resolved by entries in libc. These entry points should be
supplied through some other mechanism when this option is specified.
• -Wl,-nostdlib
Do not use the standard system start-up files or libraries when linking.
One of the standard libraries bypassed by -nostdlib and -nodefaultlibs is libgcc.a, a
library of internal subroutines that GCC uses to overcome shortcomings of particular machines, or
special needs for some languages. In most cases, you need libgcc.a even when you want to avoid
other standard libraries. In other words, when you specify -nostdlib or -nodefaultlibs you
should usually specify -lgcc as well. This ensures that you have no unresolved references to
internal GCC library subroutines.
• -Wl,-s
Remove all symbol table and relocation information from the executable.
• -Wl,-static
On systems that support dynamic linking, this prevents linking with the shared libraries. On other
systems, this option has no effect.
• -Wl,-Map
Generates Map file.
7.3.3.2. Libraries
• -Wl,-llibrary
Search the library named library when linking.
It makes a difference where in the command you write this option; the linker searches and
processes libraries and object files in the order they are specified. Thus, foo.o -lz bar.o searches
library z after file foo.o but before bar.o.
The linker searches a standard list of directories for the library, which is actually a file named
liblibrary.a. The linker then uses this file as if it had been specified precisely by name.
• -Wl, Ldir
Add directory dir to the list of directories to be searched for -l.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
171
7.3.3.3. Optimization
• -Wl, --gc-sections
Garbage collect unused sections.
Enable garbage collection of unused input sections. It is ignored on targets that do not support this
option. The default behavior (of not performing this garbage collection) can be restored by
specifying `--no-gc-sections' on the command line. `--gc-sections' decides which input sections are
used by examining symbols and relocations. The section containing the entry symbol and all
sections containing symbols undefined on the command-line will be kept, as will sections containing
symbols referenced by dynamic objects.
• -funsafe-math-optimizations
Enable unsafe math optimizations.
• -ffast-math
Enable fast math
• -fpic
Generate position independent code.
7.3.4. Assembler Options
• -I
Use this option to add a path to the list of directories as searches for files specified in .include
directives (see .include). You may use -I as many times as necessary to include a variety of paths.
The current working directory is always searched first; after that, as searches any `-I' directories in
the same order as they were specified (left to right) on the command line.
• -v
Announce version.
• Debugging(-g)
Use this option to enable the debug level.
7.3.5. Preprocessing Assembler Options
• -I
Use this option to add a path to the list of directories as searches for files specified in .include
directives (see .include). You may use -I as many times as necessary to include a variety of paths.
The current working directory is always searched first; after that, as searches any `-I' directories in
the same order as they were specified (left to right) on the command line.
• -v
Announce version.
• Debugging(Wa,-g)
Use this option to enable the debug level.
7.3.6. Archiver Options
• -r
Replace existing or insert new file(s) into the archive.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
172
7.4. Binutils
The following ARM GNU Binutils are available:
• arm-none-eabi-ld - GNU linker.
• arm-none-eabi-as - GNU assembler.
• arm-none-eabi-addr2line - Converts addresses into filenames and line numbers.
• arm-none-eabi-ar - A utility for creating, modifying and extracting from archives.
• arm-none-eabi-c++filt - Filter to demangle encoded C++ symbols.
• arm-none-eabi-nm - Lists symbols from object files.
• arm-none-eabi-objcopy - Copies and translates object files.
• arm-none-eabi-objdump - Displays information from object files.
• arm-none-eabi-ranlib - Generates an index to the contents of an archive.
• arm-none-eabi-readelf - Displays information from any ELF format object file.
• arm-none-eabi-size - Lists the section sizes of an object or archive file.
• arm-none-eabi-strings - Lists printable strings from files.
• arm-none-eabi-strip - Discards symbols.
For more information about each util, use the built in help command: --help.
7.5. AVR Compiler and Toolchain Options: GUI
To get help about AVR GNU toolchain, you can do the following:
• For information about avr32-gcc usage in Atmel Studio and general parameters consult the GCC
Project Options and Configuration section
• The API reference for the AVR libc implementation can be found here
The API Alphabetical index can be consulted here
• For general information about GCC, visit the official GNU GCC web site
• Alternatively you can write avr32-gcc --help and see explanations on some of the parameters
in the command output
This section illustrates the GUI options that are available for the AVR GNU toolchain from the Atmel
Studio frontend.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
173
Figure 7-2. AVR GNU Toolchain Options
AVR GNU C Compiler Options
Table 7-6. AVR GNU C Compiler Options
Option Description
General options
-mcall-prologues Use subroutines for functions prologues and epilogues
-mno-interrupts Change stack pointer without disabling interrupts
-funsigned-char Default char type is unsigned
-funsigned-bitfield Default bit field is unsigned
Preprocessor options
-nostdinc Do not search system directories
-E Preprocess only
Symbols options
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
174
Option Description
There one can define (-D) or undefine (-U) a number of in-source symbols. New symbol declarations
can be added, modified, or reordered, using the interface buttons below:
•
Add a new symbol. This and all following icons are reused with the same meaning in other parts
of Atmel Studio interface.
•
Remove a symbol.
•
Edit symbol.
•
Move the symbol up in the parsing order.
•
Move the symbol down in the parsing order.
Include directories
Contains all the included header and definition directories, can be modified, using the same interface as
symbols.
Optimization options
Optimization level (drop down menu): -O0, -
O1, -O2, -O3, -Os
No optimization, optimize for speed (level 1 - 3),
optimize for size
Other optimization flags (manual input form) Here you should write optimization flags specific for the
platform and your requirements
-ffunction-sections Prepare functions for garbage collection, if a function is
never used, its memory will be scrapped
-fpack-struct Pack structure members together
-fshort-enums Allocate only as many bytes needed by the enumerated
types
-mshort-calls Use rjmp/rcall limited range instructions on the >8K
devices
Debug options
Debug level (drop down menu): none, -g1, -
g2, -g3
Specifies the level of tracing and debugging code and
headers left or inserted in the source code
Other debug options (form field) Architecture specific debug options
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
175
Option Description
Warning messages output options
-Wall All warnings
-Werror Escalate warnings to errors
-fsyntax-only Check syntax only
-pedantic Check conformity to GNU, raise warnings on nonstandard
programming practice
-pedantic-errors Same as above, plus escalate warnings to errors
Miscellaneous options
Other flags (form field) Input other project-specific flags
-v Verbose
-ansi Support ANSI programs
-save-temps Do not delete temporary files
AVR GCC Linker Options
Table 7-7. AVR GCC Linker Options
Option Description
-Wl -nostartfiles Do not use standard files
-Wl -nodefault Do not use default libraries
-Wl -nostdlib No start-up or default libraries
-Wl -s Omit all symbol information
-Wl -static Link statically
Libraries options
Libraries -Wl, -l (form field) You can add, prioritize or edit library names here, using those
buttons: , , , ,
Library search path -Wl,-L (form field) You can add, prioritize or edit path where the linker will search for
dynamically linked libraries, same interface as above
Optimization options
-Wl, -gc-sections Garbage collect unused sections
--rodata-writable Put read-only data in writable spaces
-mrelax Relax branches
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
176
Option Description
Miscellaneous options
Other linker flags (form field) Input other project-specific flags
Memory Settings
Displays a dialog where it is possible to configure memory segments. (Syntax for specifying segment
values: = , for example boot=0xff)
The address must be given as a hexadecimal number prefixed with 0x. It is interpreted as a word address
for flash memory and a byte addresse for SRAM and EEPROM memory.
Figure 7-3. Memory settings
Notes about the AVR port of gcc
The AVR is a Harvard architecture CPU. This means that it separates instruction memory and data
memory. The gcc was originally designed to support Von Neumann architectures which define a single
storage structure to hold both instructions and data. This dichotomy is solved by a series of nifty tricks in
the AVR port of gcc, of which three should be noted:
• The .text segment starts at 0x0
• The .data segment starts at 0x800000
• The .eeprom segment starts at 0x810000
These peculiarities have been abstracted away by the GUI , but users will see the truth when building
projects with relocated segments.
A relocation definition for flash will be passed to the GNU linker via avr-gcc as the option:
• -Wl,-section-start=bootloader=0x1fc00
Note that the address has been multiplied by 2 to get the byte address.
A relocation definition for the .data section will be passed as:
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
177
• -Wl,-section-start=anewdatasegment=0x800
AVR Assembler Options
Table 7-8. AVR Assembler Options
Option Description
Optimization options
Assembler flags (form field) Miscellaneous assembler flags
Include path (form field) You can add, prioritize or edit path to the architecture and
platform specific included files here
-v Announce version in the assembler output
Debugging options
Debugging (drop down menu) None, -Wa
-g
Enables debugging symbol and debugging source insertion
7.6. Commonly Used Options
7.6.1. Compiler Options
7.6.1.1. General
• -funsigned-char
Each kind of machine has a default for what char should be. It is either like unsigned char by
default or like signed char by default. This option says that the default char type is unsigned.
• -funsigned-bitfields
These options control whether a bit-field is signed or unsigned, when the declaration does not use
either signed or unsigned. This options says that the default bitfield type is unsigned.
7.6.1.2. Preprocessor
• -nostdinc
Do not search the standard system directories for header files. Only the directories you have
specified with -I options (and the directory of the current file, if appropriate) are searched.
• -E
Stop after the preprocessing stage; do not run the compiler proper. The output is in the form of
preprocessed source code, which is sent to the standard output. Input files which don't require
preprocessing are ignored.
7.6.1.3. Symbols
• -D
• -D name
Predefine name as a macro, with definition 1.
E.g.:
• -D name=value
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
178
Predefine name as a macro, with definition value. The contents of definition are tokenized
and processed as if they appeared during translation phase three in a #define directive. In
particular, the definition will be truncated by embedded newline characters.
• -U
Cancel any previous definition of name, either built in or provided with a -D option.
-D and -U options are processed in the order they are given on the command line. All -imacros file and -
include file options are processed after all -D and -U options.
7.6.1.4. Directories
• -I dir
Add the directory dir to the list of directories to be searched for header files. Directories named by -I
are searched before the standard system include directories. If the directory dir is a standard
system include directory, the option is ignored to ensure that the default search order for system
directories and the special treatment of system headers are not defeated .
7.6.1.5. Optimization
• There is a general switch ‘-O’ which specifies the level of optimization used
when generating the code:
– -Os
Signal that the generated code should be optimized for code size. The compiler will not care
about the execution performance of the generated code.
– -O0
No optimization. This is the default. GCC will generate code that is easy to debug but slower
and larger than with the incremental optimization levels outlined below.
– -O1 or -O
This will optimize the code for both speed and size. Most statements will be executed in the
same order as in the C/C++ code and most variables can be found in the generated code.
This makes the code quite suitable for debugging.
– -O2
Turn on most optimizations in GCC except for some optimizations that might drastically
increase code size. This also enables instruction scheduling, which allows instructions to be
shuffled around to minimize CPU stall cycles because of data hazards and dependencies, for
CPU architectures that might benefit from this. Overall this option makes the code quite small
and fast, but hard to debug.
– -O3
Turn on some extra performance optimizations that might drastically increase code size but
increase performance compared to the -O2 and -O1 optimization levels. This includes
performing function inlining
• Other optimization options
– -ffunction-sections
– -fdata-sections
Place each function or data item into its own section in the output file if the target supports
arbitrary sections. The name of the function or the name of the data item determines the
section's name in the output file.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
179
Only use these options when there are significant benefits from doing so. When you specify
these options, the assembler and linker will create larger object and executable files and will
also be slower.
– -funroll-loops
If code size is not a concern then some extra performance might be obtained by making gcc
unroll loops by using the ‘-funroll-loops’’ switch in addition to the ‘-O3’ switch.
7.6.1.6. Debugging
• -g level (Debugging level)
• -g1
It produces minimal information, enough for making back-traces in parts of the program that
you don't plan to debug. This includes descriptions of functions and external variables, but no
information about local variables and no line numbers.
• -g2
It is the default debugging level.
• -g3
It includes extra information, such as all the macro definitions present in the program. Some
debuggers support macro expansion when you use -g3.
7.6.1.7. Warnings
• -Wall
Show all warnings.
• -Werror
Show warnings as errors.
• -fsyntax-only
Check the code for syntax errors, but don't do anything beyond that.
• -pedantic
Issue all the warnings demanded by strict ISO C, reject all programs that use forbidden extensions,
and some other programs that do not follow ISO C. Valid ISO C programs should compile properly
with or without this option (though a rare few will require -ansi or a -std option specifying the
required version of ISO C). However, without this option, certain GNU extensions and traditional C
features are supported as well. With this option, they are rejected.
• -pedantic-errors
Pedantic warnings are produced as errors.
• -w
Inhibit all warning messages.
7.6.1.8. Miscellaneous
• -v
Verbose option. It prints (on standard error output) the commands executed to run the stages of
compilation. Also print the version number of the compiler driver program and of the preprocessor
and the compiler proper.
• -ansi
Support ANSI programs. This turns off certain features of GCC that are incompatible with ISO C90
(when compiling C code). For the C compiler, it disables recognition of C++ style // comments as
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
180
well as the inline keyword. The -ansi option does not cause non-ISO programs to be rejected
gratuitously. For that, -pedantic is required in addition to -ansi.
7.6.2. Linker Options
7.6.2.1. General
• -Wl,option
Pass option as an option to the linker. If option contains commas, it is split into multiple options
at the commas. You can use this syntax to pass an argument to the option. For example, `-Wl,-
Map,output.map' passes `-Map output.map' to the linker.
• -Wl, -nostartfiles
Do not use the standard system startup files when linking. The standard system libraries are used
normally, unless -nostdlib or -nodefaultlibs is used.
• -Wl,-nodefault
Do not use the standard system libraries when linking. Only the libraries you specify will be passed
to the linker, options specifying linkage of the system libraries, such as -static-libgcc or -
shared-libgcc, will be ignored. The standard start-up files are normally used, unless -
nostartfiles is used. The compiler may generate calls to memcmp, memset, memcpy, and
memmove. These entries are usually resolved by entries in libc. These entry points should be
supplied through some other mechanism when this option is specified.
• -Wl,-nostdlib
Do not use the standard system start-up files or libraries when linking.
One of the standard libraries bypassed by -nostdlib and -nodefaultlibs is libgcc.a, a
library of internal subroutines that GCC uses to overcome shortcomings of particular machines, or
special needs for some languages. In most cases, you need libgcc.a even when you want to avoid
other standard libraries. In other words, when you specify -nostdlib or -nodefaultlibs you
should usually specify -lgcc as well. This ensures that you have no unresolved references to
internal GCC library subroutines.
• -Wl,-s
Remove all symbol table and relocation information from the executable.
• -Wl,-static
On systems that support dynamic linking, this prevents linking with the shared libraries. On other
systems, this option has no effect.
7.6.2.2. Libraries
• -Wl,-llibrary
Search the library named library when linking.
It makes a difference where in the command you write this option; the linker searches and
processes libraries and object files in the order they are specified. Thus, foo.o -lz bar.o searches
library z after file foo.o but before bar.o.
The linker searches a standard list of directories for the library, which is actually a file named
liblibrary.a. The linker then uses this file as if it had been specified precisely by name.
• -Wl, Ldir
Add directory dir to the list of directories to be searched for -l.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
181
7.6.2.3. Optimization
• -Wl, --gc-sections
Garbage collect unused sections.
Enable garbage collection of unused input sections. It is ignored on targets that do not support this
option. The default behavior (of not performing this garbage collection) can be restored by
specifying `--no-gc-sections' on the command line. `--gc-sections' decides which input sections are
used by examining symbols and relocations. The section containing the entry symbol and all
sections containing symbols undefined on the command-line will be kept, as will sections containing
symbols referenced by dynamic objects.
• --rodata-writable
Put read-only data in writable data section.
7.6.3. Assembler Options
• -I
Use this option to add a path to the list of directories as searches for files specified in .include
directives (see .include). You may use -I as many times as necessary to include a variety of paths.
The current working directory is always searched first; after that, as searches any `-I' directories in
the same order as they were specified (left to right) on the command line.
• -v
Announce version.
7.7. 8-bit Specific AVR GCC Command Line Options
This section describes the options specific to AVR 8-bit Toolchain.
7.7.1. AVR C Compiler
7.7.1.1. General
• -mcall-prologues
Functions prologues/epilogues are expanded as call to appropriate subroutines. Code size will be
smaller.
• -mno-interrupts
Change the stack pointer without disabling interrupts. Generated code is not compatible with
hardware interrupts. Code size will be smaller.
• -mno-tablejump
Do not generate table jump instructions (removed from gcc 4.5.1 coz same as -fno-jump-tables).
• -msize
Output instruction sizes to the asm file (removed from avr-gcc coz same as using -dp switch which
prints the instruction length).
7.7.1.2. Optimization
• -fpack-struct
Without a value specified, pack all structure members together without holes. When a value is
specified (which must be a small power of two), pack structure members according to this value,
representing the maximum alignment (that is, objects with default alignment requirements larger
than this will be output potentially unaligned at the next fitting location).
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
182
• -fshort-enums
Allocate to an enum type only as many bytes as it needs for the declared range of possible values.
Specifically, the enum type will be equivalent to the smallest integer type which has enough room.
• -mshort-calls
Use rjmp/rcall (limited range) on >8K devices.
7.7.1.3. Miscellaneous
• -save-temps
Do not delete temporary files. Store the usual "temporary" intermediate files permanently; place
them in the current directory and name them based on the source file. Thus, compiling foo.c with -c
-save-temps would produce files foo.i and foo.s, as well as foo.o. This creates a preprocessed foo.i
output file even though the compiler now normally uses an integrated preprocessor.
7.7.2. AVR C Linker
7.7.2.1. Optimization
• -mrelax
Relax branches. Linker relaxing is enabled in the linker by passing the ‘—relax’ option to the linker.
Using GCC as a frontend for the linker, this option is automatically passed to the linker when using
‘-O2’ or ‘-O3’ or explicitly using the ‘-mrelax’ option. When this option is used, GCC outputs pseudo
instructions like lda.w, call etc. The linker can then, if the input file is tagged as relaxable, convert a
pseudo instruction into the best possible instruction with regards to the final symbol address.
7.8. 32-bit Specific AVR GCC Command Line Options
7.8.1. Optimization
• -mfast-float
The switch, causes fast, non-ieee compliant versions of some of the optimized AVR 32-bit floatingpoint
library functions to be used. This switch is by default enabled if the ‘-ffast-math’ switch is used.
• -funsafe-math-optimizations
Allow optimizations for floating-point arithmetic that (a) assume that arguments and results are valid
and (b) may violate IEEE or ANSI standards. When used at link-time, it may include libraries or
start-up files that change the default FPU control word or other similar optimizations. This option is
not turned ON by any ‘-O’ option since it can result in incorrect output for programs which depend
on an exact implementation of IEEE or ISO rules/specifications for math functions. It may, however,
yield faster code for programs that do not require the guarantees of these specifications. Enables ‘-
fno-signed-zeros’, ‘-fno-trapping-math’, ‘-fassociative-math’ and ‘-freciprocal-math’.
• -ffast-math
This option causes the preprocessor macro __FAST_MATH__ to be defined. This option is not
turned on by any ‘-O’ option since it can result in incorrect output for programs which depend on an
exact implementation of IEEE or ISO rules/specifications for math functions. It may, however, yield
faster code for programs that do not require the guarantees of these specifications. It sets ‘-fnomath-errno’,
‘-funsafe-math-optimizations’, ‘-ffinite-math-only’, ‘-fno-rounding-math’, ‘-fno-signalingnans’
and ‘-fcx-limited-range’.
• -fpic
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
183
Generate position-independent code (PIC) suitable for use in a shared library, if supported for the
target machine. Such code accesses all constant addresses through a global offset table (GOT).
The dynamic loader resolves the GOT entries when the program starts (the dynamic loader is not
part of GCC; it is part of the operating system). If the GOT size for the linked executable exceeds a
machine-specific maximum size, you get an error message from the linker indicating that ‘-fpic’
does not work; in that case, recompile with ‘-fPIC’ instead. (These maximums are 8k on the SPARC
and 32k on the m68k and RS/6000. The 386 has no such limit.) Position-independent code requires
special support, and therefore works only on certain machines. For the 386, GCC supports PIC for
System V but not for the Sun 386i. Code generated for the IBM RS/6000 is always positionindependent.
When this flag is set, the macros __pic__ and __PIC__ are defined to 1.
• -mno-init-got
Do not initialize GOT register before using it when compiling PIC code.
• -masm-addr-pseudos
This option is enabled by default and causes GCC to output the pseudo instructions call and lda.w
for calling direct functions and loading symbol addresses respectively. It can be turned OFF by
specifying the switch ‘-mno-asm-addr-pseudos’. The advantage of using these pseudo-instructions
is that the linker can optimize these instructions at link time if linker relaxing is enabled. The ‘-
mrelax’ option can be passed to GCC to signal to the assembler that it should generate a relaxable
object file.
• -mforce-double-align
Force double-word alignment for double-word memory accesses.
• -mimm-in-const-pool
When GCC needs to move immediate values not suitable for a single move instruction into a
register, it has two possible choices; it can put the constant into the code somewhere near the
current instruction (the constant pool) and then use a single load instruction to load the value or it
can use two immediate instruction for loading the value directly without using a memory load. If a
load from the code memory is faster than executing two simple one-cycle immediate instructions,
then putting these immediate values into the constant pool will be most optimal for speed. This is
often true for MCU architectures implementing an instruction cache, whereas architectures with
code executing from internal flash will probably need several cycles for loading values from code
memory. By default GCC will use the constant pool for AVR 32-bit products with an instruction
cache and two immediate instructions for flash-based MCUs. This can be overridden by using the
option ‘-mimm-in-const-pool’ or its negated option ‘-mno-imm-in-const-pool’.
• -muse-rodata-sections
By default GCC will output read-only data into the code (.text) section. If the code memory is slow it
might be more optimal for performance to put read-only data into another faster memory, if
available. This can be done by specifying the switch ‘-muse-rodata-section’, which makes GCC put
read-only data into the .rodata section. Then the linker file can specify where the content of
the .rodata section should be placed. For systems running code from flash this might however
mean that the read-only data must be placed in flash and then copied over to another memory at
start-up, which means that extra memory usage is required with this scheme.
7.8.2. Debugging
• -pg
Generate extra code to write profile information suitable for the analysis program gprof. You must
use this option when compiling the source files you want data about, and you must also use it when
linking.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
184
• -p
Generate extra code to write profile information suitable for the analysis program prof. You must
use this option when compiling the source files you want data about, and you must also use it when
linking.
7.8.3. AVR32 C Linker
7.8.3.1. Optimization
• -mfast-float
Enable fast floating-point library. Enabled by default if the -funsafe-math-optimizations switch is
specified.
• -funsafe-math-optimizations
Allow optimizations for floating-point arithmetic that (a) assume that arguments and results are valid
and (b) may violate IEEE or ANSI standards. When used at link-time, it may include libraries or
start-up files that change the default FPU control word or other similar optimizations. This option is
not turned on by any ‘-O’ option since it can result in incorrect output for programs which depend on
an exact implementation of IEEE or ISO rules/specifications for math functions. It may, however,
yield faster code for programs that do not require the guarantees of these specifications. Enables ‘-
fno-signed-zeros’, ‘-fno-trapping-math’, ‘-fassociative-math’, and ‘-freciprocal-math’. The default is ‘-
fno-unsafe-math-optimizations’.
• -ffast-math
This option causes the preprocessor macro __FAST_MATH__ to be defined. This option is not
turned on by any ‘-O’ option since it can result in incorrect output for programs which depend on an
exact implementation of IEEE or ISO rules/specifications for math functions. It may, however, yield
faster code for programs that do not require the guarantees of these specifications. It sets ‘-fnomath-errno’,
‘-funsafe-math-optimizations’, ‘-ffinite-math-only’, ‘-fno-rounding-math’, ‘-fno-signalingnans’,
and ‘-fcx-limited-range’.
• -fpic
Generate position-independent code (PIC) suitable for use in a shared library, if supported for the
target machine. Such code accesses all constant addresses through a global offset table (GOT).
The dynamic loader resolves the GOT entries when the program starts (the dynamic loader is not
part of GCC; it is part of the operating system). If the GOT size for the linked executable exceeds a
machine-specific maximum size, you get an error message from the linker indicating that ‘-fpic’
does not work; in that case, recompile with ‘-fPIC’ instead. (These maximums are 8k on the SPARC
and 32k on the m68k and RS/6000. The 386 has no such limit.) Position-independent code requires
special support, and therefore works only on certain machines. For the 386, GCC supports PIC for
System V but not for the Sun 386i. Code generated for the IBM RS/6000 is always positionindependent.
When this flag is set, the macros __pic__ and __PIC__ are defined to 1.
• -Wl,--direct-data
Allow direct data references when optimizing. To enable the linker to convert an lda.w into an
immediate move instruction, i.e. linker relaxing, the option ‘—direct-data’ must be given to the linker.
7.8.3.2. Miscellaneous
• -Xlinker[option]
Pass option as an option to the linker. You can use this to supply system-specific linker options
which GCC does not know how to recognize. If you want to pass an option that takes a separate
argument, you must use -Xlinker twice, once for the option and once for the argument. For
example, to pass -assert definitions, you must write `-Xlinker -assert -Xlinker definitions'. It does not
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
185
work to write -Xlinker "-assert definitions", because this passes the entire string as a single
argument, which is not what the linker expects. When using the GNU linker, it is usually more
convenient to pass arguments to linker options using the option=value syntax than as separate
arguments. For example, you can specify `-Xlinker -Map=output.map' rather than `-Xlinker -Map -
Xlinker output.map'. Other linkers may not support this syntax for command-line options.
7.9. Binutils
The following AVR 32-bit GNU Binutils are available:
• avr32-ld- GNU linker.
• avr32-as - GNU assembler.
• avr32-addr2line - Converts addresses into file-names and line numbers.
• avr32-ar - A utility for creating, modifying and extracting from archives.
• avr32-c++filt - Filter to demangle encoded C++ symbols.
• avr32-nm - Lists symbols from object files.
• avr32-objcopy - Copies and translates object files.
• avr32-objdump - Displays information from object files.
• avr32-ranlib - Generates an index to the contents of an archive.
• avr32-readelf - Displays information from any ELF format object file.
• avr32-size - Lists the section sizes of an object or archive file.
• avr32-strings - Lists printable strings from files.
• avr32-strip - Discards symbols.
For more information about each util, use the built in help command: avr32- --
help.
• For general information about GNU Assembler (GAS), GNU linker and other binutils, visit the official
GNU Binutils web site.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
186
8. Extending Atmel Studio
Atmel Studio includes a tool named Extension Manager that lets you add, remove, enable, and disable
Atmel Studio extensions. To open Extension Manager, on the Tools menu, click Extension Manager.
Extension developers are advised to uninstall previous versions of extensions in progress, and uninstall
or disable potentially conflicting extensions to prevent conflicts during development.
8.1. Extension Manager UI
The Extension Manager window is divided into three panes. The left pane lets you select by group:
installed extensions and new extensions from the online gallery.
Figure 8-1. Extension Manager
The extensions are displayed in the middle pane. You can sort the list by name or author from the
combobox above the list.
When you select an extension in the middle pane, information about it appears in the right pane.
Extension installed by the current user can be uninstalled or disabled, extensions distributed with Atmel
Studio cannot be changed.
The Extension Manager window also includes a search box. Depending on the selection in the left pane,
you can search installed extensions, the online gallery, or available updates.
Online Gallery Extension Manager can install extensions from the Atmel Studio Gallery. These extensions
may be packages, templates, or other components that add functionality to Atmel Studio.
To get started with the extension manager check the Installing New Extensions in Atmel Studio.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
187
Extension Types
Extension Manager supports extensions in the VSIX package format, which may include project
templates, item templates, toolbox items, Managed Extension Framework (MEF) components, and
VSPackages. Extension Manager can also download and install MSI-based extensions, but it cannot
enable or disable them. Atmel Studio Gallery contains both VSIX and MSI extensions.
Dependency Handling
If a user tries to install an extension that has dependencies, the installer verifies that those dependencies
are already installed. If they are not installed, Extension Manager shows the user a list of dependencies
that must be installed before the extension can be installed.
Installing Without Using Extension Manager
Extensions that have been packaged in .vsix files may be available in locations other than the Atmel
Studio Gallery. Extension Manager cannot detect these files. However, you can install a .vsix file by
double-clicking it and then following the setup instructions. When the extension is installed, you can use
Extension Manager to enable it, disable it, or remove it.
8.2. Registering at Atmel Extension Gallery
In order to download extensions, registering at the Atmel Extension Gallery is required. The first time
Updates are accessed or a download is invoked, this login screen is displayed:
Figure 8-2. Extension Manager Registration
Follow the instructions on the screen.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
188
8.3. Installing New Extensions in Atmel Studio
Step 1
Figure 8-3. Extension Manager
Opening the extension manager window will show extensions installed.
In order to find and install a new extension, click the Available Downloads tab on the left pane.
Step 2
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
189
Figure 8-4. Retrieving List of Extensions
Updating the available extension list will take some time.
Step 3
Figure 8-5. List of Extensions
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
190
A green check mark identifies already installed extensions.
Select QTouch Composer and press Download. If you have not previously registered as a user in the
Extension Gallery you will be taken to the Registering at Atmel Extension Gallery at this point.
.
Figure 8-6. Extension Download Progression
Download will start as indicated in the status bar of Atmel Studio. If the extension is distributed as a
standalone installer you will be asked for location to save the file. Downloading can take several minutes
for large files. A dialog with a running bar is displayed during download. Not that download can take a
long time for large extensions. Press Cancel to abort the download.
Step 4
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
191
Figure 8-7. Extension License
A license agreement will appear for you to read, most of the times, when you install a new extension.
Read it carefully and install only the extensions you really need as most of the extensions' authors do not
take liability in a possible malfunction resulting from installation of mutually incompatible extensions and
collateral damages, for example if extension security is breached.
Step 5
Once the extension is downloaded a message in the lower status bar will appear.
Figure 8-8. Extension Manager Restart Warning
Click the Restart Now button to restart the IDE immediately, otherwise if you plan to restart it later - click
the Close button.
If you have an unsaved project you will be requested to save the changes you made, before restarting.
Step 6
Figure 8-9. QTouch Composer Button
After restarting Atmel Studio, a new button is added for starting QTouch Composer.
8.4. Visual Assist
The Atmel Studio comes with a preinstalled extension - the Visual Assist from WholeTomato Software.
The documentation on Visual Assist is available from several sources:
• Go to the www.wholetomato.com. Click in the left hand menu to browse documentation by feature.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
192
Figure 8-10. WholeTomato Software Documentation
• Jump directly to relevant documentation using hyperlinks in the Visual Assist options dialog
Figure 8-11. Visual Assist Options
• Click terms in the Glossary
8.5. Overview of QTouch Composer and Library
The Atmel QTouch Composer and library allows you to easily and seamlessly develop capacitive touch
functionality for your application. This simplifies the design process by tying together the tools required to
edit the code in Atmel Studio and tune the touch design. QTouch Composer, formerly called QTouch
Studio, is fully integrated in Atmel Studio 6 as an extension. QTouch Library is a software framework
extension to Atmel studio, which allows you to add touch functionality on various Atmel devices.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
193
8.5.1. Installation
1. Start Atmel Studio.
2. Go to Tools → Extension Manager → Online Gallery.
3. Select QTouch Library and click “Download” and then install it.
4. Select QTouch Composer and click “Download” and then install it.
5. Click “Restart Now” button in the Extension manager window.
6. After starting Atmel Studio, go to Tools → Extension Manager. Check QTouch library and QTouch
composer are listed and status is enabled.
8.5.2. Overview of QTouch Project Builder
QTouch Project builder will guide you through all steps from selecting device and touch sensors to
automatically generate a complete touch project.
1. Start Atmel Studio.
2. Open the File menu. Click on "New → Project".
3. The “New Project” dialog is opened. Select “GCC C QTouch Executable Project” in the New Project
dialog.
Enter the following details in the “New Project” dialog and click on the button OK.
– Name of the project
– Location of the project and solution
– Name of the solution
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
194
4. The “QTouch Project Builder” wizard is opened, which will guide through the steps involved in
creating a project.
Sample QTouch Project creation video here.
8.5.3. Overview of QTouch Analyzer
QTouch Analyzer reads and interprets touch data sent from QTouch kit into different views. The Analyzer
is separated into Kit View, Kit/Sensor Properties, Sensor Data, Trace View, Power View, and Graph view.
When touch kit is connected and Atmel Studio is opened, QTouch Analyzer window opens up and
connection information is updated.
The Virtual Kit view shows touch events such as button press, wheel, and slider use. The image is
updated based on the touch data read from the connected Touch Kit.
The Kit/Sensor Properties view allows you to view and modify the kit/sensor configuration options.
The Sensor Data View provides touch data information of the currently connected kit.
The Graph View displays one or more selected touch data's on a graph. Graph shall display most recent
touch data. The data set to show can be selected from the data set list at the right side of the view. The
datasets are displayed in tabbed pages representing the Signals, Deltas, References, and Wheel/Slider
positions. Each data set selection list follows normal selection convention; click on an item in the list to
selected that one item. To select a continuous range of items first click on first item then hold down the
SHIFT key and select the last item in the range. Multiple items can also be selected one at a time by
holding down the CTRL key prior to selecting the next item in the list. In the last case the items need not
be in a continuous range. Using CTRL select method also allows deselection of individual items from a
selection of multiple items.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
195
The Trace contains one or more data series with touch data in a chart. The trace keeps all historical data
of one single reading session (pressing start and stop reading), and the data can be saved in a separate
file and opened again later.
8.6. Scripting Extensions
Atmel Studio provides some scripting hooks that can be executed automatically by the IDE. These
extensions are mainly written in Python, and will execute for instance when a breakpoint is hit, when an
expression is evaluated or when the program is being reset.
8.6.1. Debug Scripting
The debug scripting interface is function based and depends on certain, named functions to be defined in
a Python®
file. The function will then be called when the corresponding event is occurring inside Atmel
Studio.
Attention:
Error checking is kept at a minimum for the functions exported into the Python environment so
that the time used on initialization during normal sessions are kept low. This means that there
are many ways to crash Atmel Studio through this interface.
To load a Python file, place a file named debughooks.py in the Debug folder of your project, next to the
ELF file, or one folder up where the project file is. It is also possible to place this file inside the Atmel
Studio installation directory to make the script load for all projects.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
196
Note: The Python file is loaded and compiled when a project is launched, so changes to the Python file
during a debug session will not be active until the next debug session is started. The Python file is
running in an IronPython context, with full access to .NET and a Python 2.7 runtime. See http://
ironpython.net/documentation/dotnet/ for more information of the runtime.
The functions that Atmel Studio will try to load is shown below with its function signature.
def should_process_breakpoint(studio_interface,
breakpoint_address,
breakpoint_id,
obj):
"""
Called to determine if a breakpoint should cause Atmel Studio to enter debug mode.
If this function returns False, Atmel Studio will not break at the breakpoint.
"""
return True
def has_processed_breakpoint(studio_interface,
breakpoint_address,
breakpoint_id,
obj):
"""
This function is called if Atmel Studio is breaking at a breakpoint.
The GUI is now in halted mode.
"""
pass
def on_reset(studio_interface,
reset_address):
"""
This function is called when the target is reset. The address
where the reset went to is 'reset_address'.
"""
pass
def on_eval_expr(studio_interface,
expression):
"""
This function is called for each expression that is evaluated in Atmel Studio.
This includes the watch window and other windows that show data from the target.
Pass the 'expression' string through to evaluate it, or return another expression
to be evaluated to override the expression. This override is not visible in the
Atmel Studio GUI.
"""
return expression
Note: Atmel Studio expects all these functions to be available if the script has been found and is loaded
correctly. If for instance the should_process_breakpoint is undefined, breakpoints might start to
misbehave as the return value of a undefined function is in itself undefined.
In the code shown above, the main interface back into the Atmel Studio is the studio_interface
object. This object contains some functions to show messages and do target interaction.
The Print function in the studio_interface object is used to show text in the output window inside
Atmel Studio. The function takes two arguments, the string to print and the name of the tab in the output
window. The example below prints all evaluated expression to the “Expressions” tab.
def on_eval_expr(studio_interface, expression):
studio_interface.Print("Evaluating {}".format(expression), "Expressions")
return expression
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
197
Note: The severity level of text sent through Print is set to INFO, which means that the output may be
masked by Atmel Studio. To lower the threshold, go to Tools > Tools, select Status Management, and
set the Display Threshold to INFO.
The ExecStmt function in the studio_interface object is used to execute statements in the
debugger. This can for instance be used to set variables. See MSDN Debugger.ExecuteStatement
Method for more information.
The WriteMemory and ReadMemory are symmetric functions for reading and writing memory on the
target. It is important to use a System.Array[System.Byte] object to pass the data between the
script and Atmel Studio.
import System
def should_process_breakpoint(studio_interface,
breakpoint_address,
breakpoint_id,
obj):
vals = System.Array[System.Byte]([1, 2, 3, 4, 5, 6, 7, 8, 9])
studio_interface.WriteMemory(data=vals, adr=0, type="eeprom")
ret = studio_interface.ReadMemory(adr=0, type="eeprom", count=9)
studio_interface.Print("ret == vals => {!r}".format(ret == vals), "Python")
return True
The CalcNumericValue is a shorthand for the CalcValue call. It will return the numeric value of the
symbol or the provided default value if the function fails to retrieve the value of the symbol.
def should_process_breakpoint(studio_interface,
breakpoint_address,
breakpoint_id,
obj):
a = studio_interface.CalcNumericValue("a", 0)
if a == 0:
studio_interface.Print("a was 0 or default", "Value scripts")
else:
studio_interface.Print("a = {}".format(a), "Value scripts")
return True
The CalcValue function is used to retrieve information about a symbol in the scope where the target
code is running. The return value of this call is a list of information, containing the address of the symbol,
symbol information and value. The objects sent in this list contains all known information about a symbol,
but the most useful field is the last element which contains the value of the evaluated symbol.
def should_process_breakpoint(studio_interface,
breakpoint_address,
breakpoint_id,
obj):
a = studio_interface.CalcValue("a")
# a now contains all information about the variable a.
# It is a list with the following members:
# a = [
# ,
# ,
# ,
# '1' ] <-- This is the value of the symbol as a string, here it had the value 1
studio_interface.Print("Value of a = {}".format(a[3]), "Value Scripts")
return True
Note: The different objects returned by the CalcValue call contains objects that are either internal, or
documented in the Atmel Studio SDK. Use the python dir() command to look at the fields that are
exported.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
198
9. Menus and Settings
9.1. Customizing Existing Menus and Toolbars
You can add or remove commands on any menu or toolbar, or change the order and grouping of those
commands. You can also add toolbars, and change the layout, position, and content of existing toolbars in
the integrated development environment (IDE).
To add a command to a menu or toolbar
1. On the Tools menu, click Customize.
2. In the Customize dialog box, on the Commands tab, under Choose a menu or tool bar to
rearrange, select the menu or tool bar you want to change and then click Add command.
3. In the Add Command dialog box, select a category name on the Categories list and then, on the
Commands list, select the command you want to add.
4. Click OK.
5. Click Close.
To remove a command from a menu or toolbar
1. On the Tools menu, click Customize.
2. In the Customize dialog box, on the Commands tab, under Choose a menu or toolbar to
rearrange, select the menu or toolbar you want to change.
3. Select the command you want to remove, and then click Delete.
4. Click Close.
To separate commands on a menu or toolbar
1. On the Tools menu, click Customize.
2. In the Customize dialog box, on the Commands tab, under Choose a menu or toolbar to
rearrange, select the menu or toolbar you want to change.
3. Select the command you want to separate from the commands above it.
4. In the Modify Selection list, select Begin a Group.
5. A separator bar appears on the list of commands, above the selected command.
6. Click OK.
7. Click Close.
The command appears on the menu or toolbar with a separator before it.
To add a new menu
1. On the Tools menu, click Customize.
2. In the Customize dialog box, on the Commands tab, click Add New Menu. The menu appears,
named New Menu.
3. In the Modify Selection list, enter the name for the new menu.
4. Click OK.
5. Click Close.
The command appears on the menu or toolbar before it.
To change the order of menus
1. On the Tools menu, click Customize.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
199
2. In the Customize dialog box, on the Commands tab, under Choose a menu or toolbar to rearrange,
select the menu or toolbar you want to move.
3. Select Move Up or Move Down to move the command.
4. Click OK.
5. Click Close.
The command appears on the menu or toolbar with a separator before it.
To create a toolbar
1. On the Tools menu, click Customize.
2. In the Customize dialog box, on the Toolbars tab, click New.
3. In the New Toolbar dialog box, type a name for the toolbar.
4. Use the steps described earlier in this topic to add commands to the toolbar.
Changing Toolbar Layout
You can arrange toolbars by dragging them in the main docking area, or by using the Customize dialog
box to move them to other docking areas.
To arrange toolbars in the main docking area
1. Drag a toolbar by its left edge to move it where you want it.
2. Surrounding toolbars will be automatically rearranged.
3. To change the docking location of a toolbar.
4. On the Tools menu, click Customize.
5. In the Customize dialog box, on the Toolbars tab, on the Modify Selection list, select a dock
location.
6. Click Close.
For more information about how to improve the usability and accessibility of toolbars, see How to: Set
Accessibility Options.
Resetting the Main Menu and Shortcut Menus
If you change the locations of commands or change command icons, you can reset them to their original
configurations.
To reset a menu or toolbar
1. On the Tools menu, click Customize.
2. In the Customize dialog box, on the Commands tab, under Choose a menu or toolbar to
rearrange, select the menu or toolbar you want to reset.
3. Click Reset all.
The selected menu bar, toolbar, or context menu returns to its original configuration.
9.2. Reset Your Settings
You can reset the integrated development environment (IDE) to a previous state using the Import and
Export Settings wizard. All settings and categories are applied by default; if you want to specify which
settings to change, use the option Import selected environment settings.
To reset your settings
1. On the Tools menu, click Import and Export Settings.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
200
2. On the Welcome to the Import and Export Settings Wizard page, click Reset all settings, and
then click Next.
3. If you want to save your current settings combination, click Yes, save my current settings, specify
a file name, and then click Next.
—or—
If you want to delete your current settings combination, choose No, just reset settings, overwriting
my current settings, and then click Next. This option does not delete default settings, which will still
be available the next time you use the wizard.
4. In Which collection of settings do you want to reset to, select a settings collection from the list.
5. Click Finish.
The Reset Complete page alerts you to any problems encountered during the reset.
9.3. Options Dialog Box
The Options dialog box enables you to configure the integrated development environment (IDE) to your
needs. For example, you can establish a default save location for your projects, alter the default
appearance and behavior of windows, and create shortcuts for commonly used commands. There are
also options specific to your development language and platform. You can access Options from the
Tools menu.
Note: The options available in dialog boxes, and the names and locations of menu commands you see,
might differ from what is described in Help depending on your active settings or edition. To change your
settings, choose Import and Export Settings on the Tools menu.
Layout of the Options dialog box
The Options dialog box is divided into two parts: a navigation pane on the left and a display area on the
right. The tree control in the navigation pane includes folder nodes, such as Environment, Text Editor,
Projects and Solutions, and Source Control. Expand any folder node to list the pages of options that it
contains. When you select the node for a particular page, its options appear in the display area.
Options for an IDE feature do not appear in the navigation pane until the feature is loaded into memory.
Therefore, the same options might not be displayed as you begin a new session that were displayed as
you ended the last. When you create a project or run a command that uses a particular application, nodes
for relevant options are added to the Options dialog box. These added options will then remain available
as long as the IDE feature remains in memory.
Note: Some settings collections scope the number of pages that appear in the navigation pane of the
Options dialog box. You can choose to view all possible pages by selecting Show all settings.
How options are applied
Clicking OK in the Options dialog box saves all settings on all pages. Clicking on Cancel any page
cancels all change requests, including any just made on other Options pages. Some changes to option
settings, such as those made on Fonts and Colors, Environment, Options Dialog Box, will only take
effect after you close and reopen Atmel Studio.
9.3.1. Environment Options
The pages in the Environment folder in the Options dialog box let you set how certain elements of the
integrated development environment (IDE) display and behave. You can access the Environment pages
by clicking Options on the Tools menu, and then clicking Environment.
9.3.1.1. General Environment Settings
Items shown in Window menu
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
201
Customizes the number of windows that appear in the Windows list of the Window menu. Type a number
between 1 and 24. By default, the number is 10.
Items shown in recently used lists
Customizes the number of most recently used projects and files that appear on the File menu. Type a
number between 1 and 24. By default, the number is 10. This is an easy way to retrieve recently used
projects and files.
Automatically adjust visual experience based on client performance
Specifies whether Atmel Studio sets the adjustment to the visual experience automatically or you set the
adjustment explicitly. This adjustment may change the display of colors from gradients to flat colors, or it
may restrict the use of animations in menus or pop-up windows.
Enable rich client experience
Enables the full visual experience of Atmel Studio, including gradients and animations. Clear this option
when using Remote Desktop connections or older graphics adapters, because these features may have
poor performance in those cases. This option is available only when you clear the Automatically adjust
visual experience based on client option.
Use hardware graphics acceleration if available
Uses hardware graphics acceleration if it is available, rather than software acceleration.
Show status bar
Displays the status bar. The status bar is located at the bottom of the IDE window and displays
information about the progress of ongoing operations.
Close button affects active tool window only
Specifies that when the Close button is clicked, only the tool window that has focus is closed and not all
of the tool windows in the docked set. By default, this option is selected.
Auto Hide button affects active tool window only
Specifies that when the Auto Hide button is clicked, only the tool window that has focus is hidden
automatically and not all of the tool windows in the docked set. By default, this option is not selected.
Restore File Associations
Registers file types that are typically associated with Atmel Studio. Registration causes Windows to
display the correct icons in Windows Explorer, and to recognize Atmel Studio as the correct application
for opening these file types.
This option can be useful if you have two different versions of Atmel Studio installed on the same
computer, and you later uninstall one of the versions. After uninstalling, the icons for Atmel Studio files no
longer appear in Windows Explorer. In addition, Windows no longer recognizes Atmel Studio as the
default application for editing these files. This option restores those associations.
9.3.1.2. Add-in/Macros Security
Add-in Security Settings
To enhance security by preventing malicious add-ins from automatically activating, Atmel Studio provides
settings in a Tools Options page named Add-in/Macros Security.
In addition, this options page allows you to specify the folders in which Atmel Studio searches for .Addin
registration files. This enhances security by allowing you to limit the locations where .Addin registration
files can be read, helping prevent malicious .Addin files from inadvertently being used.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
202
The settings in the Add-in/Macros Security, Environment, and Options Dialog Box that relate to add-in
security are:
• Allow add-in components to load. Checked by default. When checked, add-ins are allowed to load
in Atmel Studio. When unchecked, add-ins are prohibited from loading in Atmel Studio.
• Allow add-in components to load from a URL. Unchecked by default. When checked, add-ins are
allowed to be loaded from external Web sites. When unchecked, remote add-ins are prohibited
from loading in Atmel Studio. If an add-in cannot load for some reason, then it cannot be loaded
from the web. This setting controls only the loading of the add-in DLL. The .Addin registration files
must always be located on the local system.
Default .Add-In File Search Locations
In addition to the security settings, the options page has a list containing folders in which to search
for .Addin registration files. By default, the following tokens are included:
• %ALLUSERSDOCUMENTS%
• %ALLUSERSPROFILE%
• %APPDATA%
• %VSAPPDATA%
• %VSCOMMONAPPDATA%
• %VSMYDOCUMENTS%
When Atmel Studio begins searching for .AddIn files, it replaces these tokens with the following path
strings:
Table 9-1. AddIn Files Search Path Tokens
Token Path
%ALLUSERSDOCUMENTS% %PUBLIC%\Documents
%ALLUSERSPROFILE% %ALLUSERSPROFILE% (defined by OS)
%APPDATA% %USERPROFILE%\AppData
%VSAPPDATA% %USERPROFILE%\AppData\Roaming\Microsoft\AVR Studio
5\
--OR--
%USERPROFILE%\AppData\Local\Microsoft\Atmel Studio 6\
%VSCOMMONAPPDATA% %ProgramData%\Microsoft\Atmel Studio 6\
%VSMYDOCUMENTS% \Atmel Studio 6
Note: Some of the default paths may resolve to targets that do not exist on your system.
You can remove these predefined tokens from the list by highlighting the token and clicking Remove. To
add other folders to the search list, click Add and specify a folder in the Browse for Folder dialog box. For
more information, see Add-In Registration.
9.3.1.3. AutoRecover
Use this page of the Options dialog box to specify whether or not files are automatically backed up. This
page also allows you to specify whether or not modified files are restored when the integrated
development environment (IDE) shuts down unexpectedly. You can access this dialog box by selecting
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
203
the Tools menu and choosing Options, and then selecting the Environment folder and choosing the
AutoRecover page. If this page does not appear in the list, select Show all settings in the Options dialog
box.
Save AutoRecover information every minutes
Use this option to customize how often a file is automatically saved in the editor. For previously saved
files, a copy of the file is saved in \...\My Documents\Atmel Studio 6.2\Backup Files
\. If the file is new and has not been manually saved, the file is auto-saved using a
randomly generated file name.
Keep AutoRecover information for days
Use this option to specify how long Atmel Studio keeps files created for auto recovery.
9.3.1.4. Find and Replace
Use this page of the Options dialog box to control message boxes and other aspects of a find and replace
operation. You can access this dialog box from the Tools menu by clicking Options, expanding
Environment, and then clicking Find and Replace. If this page does not appear in the list, select Show all
settings in the Options dialog box.
Display informational messages
Select this option to display all Find and Replace informational messages that have the Always show this
message option. For example, if you chose not to display the message "Find reached the starting point of
the search.", selecting this option would cause this informational message to appear again when you use
Find and Replace.
If you do not want to see any informational messages for Find and Replace, clear this option.
When you have cleared the Always show this message option on some, but not all, Find and Replace
informational messages, the Display informational messages check box appears to be filled but not
selected. To restore all optional Find and Replace messages, clear this option and then select it again.
Note: This option does not affect any Find and Replace informational messages that do not display the
Always show this message option.
Display warning messages
Select this option to display all cautionary Find and Replace messages that have the Always show this
message option. For example, if you chose not to display the Replace All warning message that appears
when you attempt to make replacements in files not currently opened for editing, selecting this option
would cause this warning message to appear again when you attempt to Replace All.
If you do not want to see any cautionary messages for Find and Replace, clear this option.
When you have cleared the Always show this message option on some, but not all, Find and Replace
warning messages, the Display warning messages check box appears to be filled but not selected. To
restore all optional Find and Replace messages, clear this option and then select it again.
Note: This option does not affect any Find and Replace warning messages that do not display the
Always show this message option.
Automatically populate Find What with text from the editor
Select this option to paste the text on either side of the current editor's insertion point into the Find what
field when you select any view of the Find and Replace Window window from the Edit menu. Clear this
option to use the last search pattern from the previous search as the Find what string.
Hide Find and Replace window after a match is located for Quick Find or Quick Replace
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
204
Select this option to automatically close the Find and Replace window when the first match is found for
Quick Find. To go to the next match, use the shortcut key for Edit.FindNext, usually F3, or display the
Find and Replace window again.
9.3.1.5. Fonts and Colors
The Fonts and Colors page of the Options dialog box lets you establish a custom font and color scheme
for various user interface elements in the integrated development environment (IDE). You can access this
dialog box by clicking Options on the Tools menu, and then selecting the Fonts and Colors page in the
Environment folder. If this page does not appear in the list, select Show all settings in the Options dialog
box.
Note: The dialog boxes and menu commands you see might differ from those described in Help
depending on your active settings or edition. To change your settings, choose Import and Export Settings
on the Tools menu. For more information, see Working with Settings.
Color scheme changes do not take effect during the session in which you make them. You can evaluate
color changes by opening another instance of Atmel Studio and producing the conditions under which you
expect your changes to apply.
Show settings for
Lists all of the user interface elements for which you can change font and color schemes. After selecting
an item from this list you can customize color settings for the item selected in Display items.
Text Editor
Changes to font style, size, and color display settings for Text Editor affect the appearance of text in your
default text editor. Documents opened in a text editor outside the IDE will not be affected by these
settings. For information about changing your default text editor, see How to: Change or Add a Default
Editor.
Printer
Changes to font style, size, and color display settings for Printer affect the appearance of text in printed
documents.
Note: As needed, you can select a different default font for printing than that used for display in the text
editor. This can be useful when printing code that contains both single-byte and double-byte characters.
Statement Completion
Changes the font style and size for the text that appears in statement completion pop-up in the editor.
Editor Tool tip
Changes the font style and size for the text that appears in ToolTips displayed in the editor.
Environment Font
Changes the font style and size for all IDE user interface elements that do not already have a separate
option in Show settings for. For example, this option applies to the Start Page but would not affect the
Output window.
[All Text Tool Windows]
Changes to font style, size, and color display settings for this item affect the appearance of text in tool
windows that have output panes in the IDE. For example, Output window, Command window, Immediate
window, etc.
Note: Changes to the text of [All Text Tool Windows] items do not take effect during the session in which
you make them. You can evaluate such changes by opening another instance of Atmel Studio.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
205
Use Defaults/Use
Resets the font and color values of the list item selected in Show settings for. The Use button appears
when other display schemes are available for selection. For example, you can choose from two schemes
for the Printer.
Font (bold type indicates fixed-width fonts)
Lists all the fonts installed on your system. When the drop-down menu first appears, the current font for
the element selected in the Show settings for field is highlighted. Fixed fonts — which are easier to align
in the editor — appear in bold.
Size
Lists available point sizes for the highlighted font. Changing the size of the font affects all Display items
for the Show settings for selection.
Display items
Lists the items for which you can modify the foreground and background color.
Note: PlainText is the default display item. As such, properties assigned to PlainText will be overridden
by properties assigned to other display items. For example, if you assign the color blue to PlainText and
the color green to Identifier, all identifiers will appear in green. In this example, Identifier properties
override PlainText properties.
Some of display items include:
Display items
Description.
Plain Text
Text in the editor.
Selected Text
Text that is included in the current selection when the editor has focus.
Inactive Selected Text
Text that is included in the current selection when the editor has lost focus.
Indicator Margin
The margin at the left of the Code Editor where breakpoints and bookmark icons are displayed.
Line Numbers
Optional numbers that appear next to each line of code.
Visible White Space
Spaces, tabs and word wrap indicators.
Bookmark
Lines that have bookmarks. Bookmark is visible only if the indicator margin is disabled.
Brace Matching (Highlight)
Highlighting that is typically bold formatting for matching braces.
Brace Matching (Rectangle)
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
206
Highlighting that is typically a grey rectangle in the background.
Breakpoint (Enabled)
Specifies the highlight color for statements or lines containing simple breakpoints. This option is
applicable only if statement-level breakpoints are active or the Highlight entire source line for breakpoints
or current statement option is selected on General, Debugging, Options Dialog Box.
Breakpoint (Error)
Specifies the highlight color for statements or lines containing breakpoints that are in an error state.
Applicable only if statement-level breakpoints are active or the Highlight entire source line for breakpoints
or current statement option is selected on General, Debugging, Options Dialog Box.
Breakpoint (Warning)
Specifies the highlight color for statements or lines containing breakpoints that are in a warning state.
Applicable only if statement-level breakpoints are active or the Highlight entire source line for breakpoints
or current statement option is selected on General, Debugging, Options Dialog Box.
Breakpoint - Advanced (Disabled)
Specifies the highlight color for statements or lines containing disabled conditional or hit-counted
breakpoints. Applicable only if statement-level breakpoints are active or the Highlight entire source line for
breakpoints or current statement option is selected on General, Debugging, Options Dialog Box.
Breakpoint - Advanced (Enabled)
Specifies the highlight color for statements or lines containing conditional or hit-counted breakpoints.
Applicable only if statement-level breakpoints are active or the Highlight entire source line for breakpoints
or current statement option is selected on General, Debugging, Options Dialog Box.
Breakpoint - Advanced (Error)
Specifies the highlight color for statements or lines containing conditional or hit-counted breakpoints that
are in an error state. Applicable only if statement-level breakpoints are active or the Highlight entire
source line for breakpoints or current statement option is selected on General, Debugging, Options Dialog
Box.
Breakpoint - Advanced (Warning)
Specifies the highlight color for statements or lines containing conditional or hit-counted breakpoints that
are in a warning state. Applicable only if statement-level breakpoints are active or the Highlight entire
source line for breakpoints or current statement option is selected on General, Debugging, Options Dialog
Box.
Code Snippet Dependent Field
A field that will be updated when the current editable field is modified.
Code Snippet Field Editable
Field when a code snippet is active.
Collapsible Text
A block of text or code that can be toggled in and out of view within the Code Editor.
Comment
Code comments.
Compiler Error
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
207
Blue squiggles in the editor indicating a compiler error.
Coverage Not Touched Area
Code that has not been covered by a unit test.
Coverage Partially Touched Area
Code that has been partially covered by a unit test. Coverage Touched Area Code that has been
completely covered by a unit test.
Current list location
Current line navigated to in a list tool window, such as the Output window or Find Results windows.
Current Statement
Specifies the highlight color for the source statement or line that indicates the current step position when
debugging.
Debugger Data Changed
The color of text used to display changed data inside the Registers and Memory windows. Definition
Window Background The background color of the Code Definition window.
Definition Window Current Match
The current definition in the Code Definition window.
Disassembly File Name
The color of text used to display file name breaks inside the Disassembly window.
Disassembly Source
The color of text used to display source lines inside the Disassembly window. Disassembly Symbol The
color of text used to display symbol names inside the Disassembly window.
Disassembly Text
The color of text used to display op-code and data inside the Disassembly window. Excluded Code that is
not to be compiled, per a conditional preprocessor directive such as #if.
Identifier
Identifiers in code such as the class names, methods names, and variable names.
Keyword
Keywords for the given language that are reserved. For example: class and namespace.
Memory Address
The color of text used to display the address column inside the Memory window.
Memory Changed
The color of text used to display changed data inside the Memory window.
Memory Data
The color of text used to display data inside the Memory window.
Memory Unreadable
The color of text used to display unreadable memory areas within the Memory window.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
208
Number
A number in code that represents an actual numeric value. Operators such as +, -, and !=.
Other Error
Other error types not covered by other error squiggles. Currently, this includes rude edits in
Edit and Continue .
Preprocessor Keyword
Keywords used by the preprocessor such as #include. Read-Only Region Code that cannot be edited.
For example code displayed in the Code Definition View window or code that cannot be modified during
Edit and Continue.
Register Data
The color of text used to display data inside the Registers window.
Register NAT
The color of text used to display unrecognized data and objects inside the Registers window.
Stale Code
Superseded code awaiting an update. In some cases, Edit and Continue cannot apply code changes
immediately, but will apply them later as you continue debugging. This occurs if you edit a function that
must call the function currently executing, or if you add more than 64 bytes of new variables to a function
waiting on the call stack. When this happens, the debugger displays a "Stale Code Warning" dialog box,
and the superseded code continues to execute until the function in question finishes and is called again.
Edit and Continue applies the code changes at that time.
String
String literals.
Syntax Error
Parse errors. Task List Shortcut. If a Task List shortcut is added to a line, and the indicator margin is
disabled, the line will be highlighted.
Tracepoint (Enabled)
Specifies the highlight color for statements or lines containing simple tracepoints. This option is applicable
only if statement-level tracepoints are active or the Highlight entire source line for breakpoints or current
statement option is selected on General, Debugging, Options Dialog Box.
Tracepoint (Error)
Specifies the highlight color for statements or lines containing tracepoints that are in an error state. This
option is applicable only if statement-level tracepoints are active or the Highlight entire source line for
breakpoints or current statement option is selected on General, Debugging, Options Dialog Box.
Tracepoint (Warning)
Specifies the highlight color for statements or lines containing tracepoints that are in a warning state. This
option is applicable only if statement-level tracepoints are active or the Highlight entire source line for
breakpoints or current statement option is selected on General, Debugging, Options Dialog Box.
Tracepoint - Advanced (Disabled)
Specifies the highlight color for statements or lines containing disabled conditional or hit-counted
tracepoints. This option is applicable only if statement-level tracepoints are active or the Highlight entire
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
209
source line for breakpoints or current statement option is selected on General, Debugging, Options Dialog
Box.
Tracepoint - Advanced (Enabled)
Specifies the highlight color for statements or lines containing conditional or hit-counted tracepoints. This
option is applicable only if statement-level tracepoints are active or the Highlight entire source line for
breakpoints or current statement option is selected on General, Debugging, Options Dialog Box.
Tracepoint - Advanced (Error)
Specifies the highlight color for statements or lines containing conditional or hit-counted tracepoints that
are in an error state. This option is applicable only if statement-level tracepoints are active or the Highlight
entire source line for breakpoints or current statement option is selected on General, Debugging, Options
Dialog Box.
Tracepoint - Advanced (Warning)
Specifies the highlight color for statements or lines containing conditional or hit-counted tracepoints that
are in a warning state. This option is applicable only if statement-level tracepoints are active or the
Highlight entire source line for breakpoints or current statement option is selected on General,
Debugging, Options Dialog Box.
Track Changes after save
Lines of code that have been modified since the file was opened but are saved to disk.
Track Changes before save
Lines of code that have been modified since the file was opened but are not saved to disk.
User Types
Types defined by users. User Types (Delegates) Type color for delegates.
User Types (Enums)
Type color used for enums. User Types (Interfaces) Type color for interfaces.
User Types (Value types)
Type color for value types such as structs in C.
Warning
Compiler warnings.
Warning Lines
Path Used for Static Analysis warning lines.
XML Attribute
Attribute names.
XML Attribute Quotes
The quote characters for XML attributes.
XML Attribute Value
Contents of XML attributes.
XML Cdata Section
Contents of .
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
210
XML Comment
The contents of . XML Delimiter XML Syntax delimiters, including <, , , ?>, ,
and [, ].
XML Doc Attribute
The value of an XML documentation attribute, such as where the "I" is colorized.
XML Doc Comment
The comments enclosed in the XML documentation comments.
XML Doc Tag
The tags in XML documentation comments, such as /// .
XML Keyword
DTD keywords such as CDATA, IDREF, and NDATA.
XML Name Element
Names and Processing Instructions target name.
XML Processing Instruction
Contents of Processing Instructions, not including target name.
XML Text Plain
Text element content.
XSLT Keyword
XSLT element names.
Item foreground
Lists the available colors you can choose for the foreground of the item selected in Display items.
Because some items are related, and should therefore maintain a consistent display scheme, changing
the foreground color of the text also changes the defaults for elements such as Compiler Error, Keyword,
or Operator. Automatic Items can inherit the foreground color from other display items such as Plain Text.
Using this option, when you change the color of an inherited display item, the color of the related display
items also change automatically. For example, if you selected the Automatic value for Compiler Error and
later changed the color of Plain Text to Red, the Compiler Error would also automatically inherit the color
Red. Default the color that appears for the item the first time you start AVR Studio 5. Clicking the Use
Defaults button resets to this color. Custom Displays the Color dialog box to allow you to set a custom
color for the item selected in the Display items list.
Note: Your ability to define custom colors may be limited by the color settings for your computer display.
For example, if your computer is set to display 256 colors and you select a custom color from the Color
dialog box, the IDE defaults to the closest available Basic color and displays the color black in the Color
preview box.
Item background
Provides a color palette from which you can choose a background color for the item selected in Display
items.
Because some items are related, and should therefore maintain a consistent display scheme, changing
the background color of text also changes the defaults for elements such as Compiler Error, Keyword, or
Operator.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
211
Automatic Items can inherit the background color from other display items such as Plain Text.
Using this option, when you change the color of an inherited display item, the color of the related display
items also change automatically. For example, if you selected the Automatic value for Compiler Error and
later changed the color of Plain Text to Red, Compiler Error would also automatically inherit the color
Red.
Clicking the Use Defaults button resets to this color. Custom Displays the Color dialog box to allow you to
set a custom color for the item selected in the Display items list. Bold Select this option to display the text
of selected Display items in bold text. Bold text is easier to identify in the editor. Sample Displays a
sample of the font style, size, and color scheme for the Show settings for and Display items selected. You
can use this box to preview the results as you experiment with different formatting options.
9.3.1.6. Language and International Settings
The International Settings page allows you to change the default language when you have more than one
language version of the integrated development environment (IDE) installed on your machine.
You can access this dialog box by selecting Options from the Tools menu and then choosing
International Settings from the Environment folder. If this page does not appear in the list, select Show
all settings in the Options dialog box.
Any changes you make on this page apply only to the default IDE and do not take effect until the
environment is restarted.
Language
Lists the available languages for the installed product language versions. This option is unavailable
unless you have more than one language version installed on your machine. If multiple languages of
products or a mixed language installation of products share the environment, the language selection is
changed to Same as Microsoft Windows.
Caution:
In a system with multiple languages installed, the build tools are not affected by this setting.
These tools use the version for last language installed and the tools for the previously installed
language are overwritten because the build tools do not use the satellite DLL model.
9.3.1.7. Keyboard Settings
The shortcut key combinations in the scheme currently applied, (Default), depend on the settings you
have selected as well as any customizations you might have made. For more information about the
shortcut keys associated with a settings combination, see Working with Settings. Visual Studio also
includes seven other keyboard mapping schemes, each of which differs from the others in the shortcut
key combinations assigned by default to various UI elements. For a list of these combinations, organized
by mapping scheme, see Pre-defined Keyboard Shortcuts.
Commands with shortcut key combinations that are part of the Global scope can be superseded by
commands in other scopes depending on the current context of the integrated development environment
(IDE). For example, if you are editing a file, commands that are part of the Text Editor scope have
precedence over commands in the Global scope that start with the same key combination. For example, if
several Global commands have key combinations that start with CTRL + K and the Text Editor also has
several commands with key combinations that start with CTRL + K, when you are editing code the Text
Editor key combinations will work and the Global key combinations will be ignored.
Note: The options available in dialog boxes, and the names and locations of menu commands you see,
might differ from what is described in Help depending on your active settings or edition. This Help page
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
212
was written with General Development Settings in mind. To change your settings, from the Tools menu,
choose Import and Export Settings. For more information, see Working with Settings.
Determine the Shortcut Key Assigned to a Command
You can manually search for a command to determine whether or not it has an assigned shortcut key
combination.
To determine the shortcut key combination for a command
1. On the Tools menu, click Options.
2. Expand the Environment folder and select Keyboard.
Note: If you do not see the Keyboard page, check Show all settings located in the lower left of the
Options dialog box.
In the Show commands containing box, enter the name of the command without spaces. For
example, solutionexplorer.
3. In the list, select the correct command.
For example, View.SolutionExplorer.
4. If a shortcut key combination exists for the command, the combination appears in the Shortcut(s)
for selected command drop-down list.
Create Custom Shortcut Keys
You can create new shortcut key combinations for any command or change the shortcut key combination
for commands with existing combinations.
To create a new shortcut key combination
1. On the Tools menu, click Options.
2. Expand the Environment folder, and select Keyboard.
Note: If you do not see the Keyboard page, check Show all settings located in the lower left corner
of the Options dialog box. In the Show commands containing box, enter the name of the command
without spaces.
For example, solutionexplorer.
3. In the list, select the command you want to assign to a shortcut key combination.
4. On the Use new shortcut in drop-down list, select the feature area in which you want to use the
shortcut. For example, you can choose Global if you want the shortcut to work in all contexts.
Unless the same shortcut is mapped (as Global) in another editor, you can use it. Otherwise, the
editor overrides the shortcut.
Note: The following keys cannot be assigned to a command in Global: PRINT SCRN/SYS RQ,
SCROLL LOCK, PAUSE/BREAK, TAB, CAPS LOCK, INSERT, HOME, END, PAGE UP, PAGE
DOWN, Windows logo keys, Application key, any of the ARROW keys, or ENTER; NUM LOCK,
DEL, or CLEAR on the numeric keypad; or CTRL+ALT+DELETE.
5. Place the cursor in the Press shortcut key(s) box, and then use the keyboard to enter the key
combination you intend to use for the command.
Note: Shortcuts can contain the SHIFT, ALT, and/or CTRL keys in combination with letters. Be
sure to check the Shortcut currently used by box to see if the key combination is already assigned
to another command in the mapping scheme. Press BACKSPACE to delete the key combination, if
the combination is already in use, before trying another combination.
6. Click Assign.
Note: Changes made by using the Assign button are not canceled if you click the Cancel button.
Exporting and Importing Shortcut Keys
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
213
You can share the shortcut key combinations in the current keyboard mapping scheme by exporting the
information to a file so others can import the data.
To export shortcut keys only
1. On the Tools menu, choose Import and Export Settings Wizard.
2. Select Export select environment settings and then click Next.
3. Under What settings do you want to export?, clear all categories selected by default.
4. Expand Options and then expand Environment.
5. Select Keyboard and then click Next.
6. For What do you want to name your settings file?, enter a name and then click Finish.
To import only shortcut keys
1. On the Tools menu, click Import and Export Settings Wizard.
2. Select Import select environment settings and then click Next.
3. Click No, just import new settings, overwriting my current settings and then click Next.
4. Under My Settings, select the settings file that contains the shortcut keys you want to import, or
click Browse to locate the correct settings file.
5. Click Next.
6. Under Which settings do you want to import?, clear all categories.
7. Expand Options and then expand Environment.
8. Select Keyboard and then click Finish.
9.3.1.8. Start-up Page — to Change the Default UI Displayed when You Start Atmel Studio
1. On the Tools menu, chose Options.
2. Expand Environment and then chose Startup.
3. From the At startup drop-down list, chose one of the options. For more information, see Startup,
Environment, Options Dialog Box.
4. Click OK.
Your changes take affect the next time you start Atmel Studio.
Use this page to specify what content or user interface (UI), if any, is displayed when you start Atmel
Studio. To access this page, on the Tools menu, click Options, expand Environment, and then click
Startup. If this page does not appear in the list in the Options dialog box, select Show all settings.
Note: The options available in dialog boxes, and the names and locations of menu commands you see,
might differ from what is described in Help depending on your active settings or edition. This Help page
was written with General Development settings in mind. To change your settings, on the Tools menu, click
Import and Export Settings.
At start-up
You can specify what you want to view every time you start AVR Studio 5.
Open Home Page
Displays the default Web page specified by the Home page option in Web Browser, Environment, Options
Dialog Box.
Load last loaded solution
Loads the last saved solution in its previous state. Any files that were open in the solution when it was last
closed are opened and displayed when you start Atmel Studio. If no solution is loaded when you exit the
product, no solution is loaded when you return.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
214
Show Open Project dialog box
Displays the Open Project dialog box when you start Atmel Studio. The dialog box uses the folder set in
the Atmel Studio Projects location field of the Projects and Solutions, Environment, Options Dialog Box.
Show New Project dialog box
Displays the New Project dialog box when you open Atmel Studio.
Show empty environment
Displays an empty integrated development environment (IDE) when you start Atmel Studio.
Show Start Page
Displays the Start Page associated with the settings that you have currently applied when you start Atmel
Studio.
Start Page news channel
Specifies the RSS feed used to display content in the Atmel Studio News section of the Start Page.
Download content every n minutes
Specifies how often the IDE checks for new RSS feed content and product headlines for the Start Page. If
this setting is not selected, RSS feed content and product headlines are not downloaded to the Start
Page.
Customize Start Page
If you have custom Start Pages installed, you can specify which Start Page to load. The Customize Start
Page drop-down list includes an (Default Start Page) entry to load the default Atmel Studio Start Page,
and an entry for each custom Start Page on your system.
Any .XAML file in your user start pages directory is considered a custom start page. For more information,
see Custom Start Pages.
9.3.1.9. Import and Export Settings
Use this page of the Options dialog box to set preferences for saving settings files as well as specifying
whether or not to use team settings files stored on a server. You can access this dialog box by selecting
Options from the Tools menu and choosing the Import and Export Settings page from the Environment
folder.
Tip:
If this page does not appear in the list, select Show all setting in the Options dialog box.
Note: The options available in dialog boxes, and the names and locations of menu commands you see,
might differ from what is described in Help depending on your active settings or edition. This Help page
was written with General Development Settings in mind. To change your settings, choose Import and
Export Settings on the Tools menu. For more information, see Working with Settings.
Automatically load and save settings
Automatically save my settings to this file:
Displays the location and name of the .vssettings file you are currently using. When you close the IDE,
any changes you have made, such as moving windows or changing option selections, are saved to the
current file. The next time you start the IDE, your settings are loaded.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
215
Team settings
Use team settings file:
When selected, allows you to navigate to a shared .vssettings file by using the Browse button. This
settings file is automatically re-applied each time Atmel Studio detects if a newer version is available.
Note: The location of the team settings file must be specified as a UNC path or local path. URLs and
other protocols are not supported paths.
9.3.1.10. Task List
This Options page allows you to add, delete, and change the comment tokens that generate Task List
reminders. To display these settings, select Options from the Tools menu, expand the Environment folder,
and choose Task List.
Confirm deletion of tasks
When selected, a message box is displayed whenever a User Task is deleted from the Task List, allowing
you to confirm the deletion. This option is selected by default.
Note: To delete a Task Comment, use the link to find the comment, and then remove it from your code.
Hide full file paths
When selected, the File column of the Task List displays only the names of files to be edited, not their full
paths.
Tokens
When you insert a comment into your code whose text begins with a token from the Token List, the Task
List displays your comment as new entry whenever the file is opened for editing. You can click this Task
List entry to jump directly to the comment line in your code. For more information, see How to: Create
Task List Comments.
Token List
Displays a list of tokens, and allows you to add or remove custom tokens. Comment tokens are case
sensitive.
Note: If you do not type the desired token exactly as it appears in the Token List, a comment task will
not be displayed in the Task List.
Priority
Sets the priority of tasks that use the selected token. Task comments that begin with this token are
automatically assigned the designated priority in the Task List.
Name
Enter the token string. This enables the Add button. On Add, this string is included in the Token List, and
comments that begin with this name will be displayed in the Task List.
Add
Enabled when you enter a new Name. Click to add a new token string using the values entered in the
Name and Priority fields.
Delete
Click to delete the selected token from the Token List. You cannot delete the default comment token.
Change
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
216
Click to make changes to an existing token using the values entered in the Name and Priority fields.
Note: You cannot rename or delete the default comment token, but you can change its priority level.
9.3.1.11. Web Browser Options
Sets options for both the internal Web browser and Internet Explorer. To access this dialog box, click
Options on the Tools menu, expand the Environment folder, and select Web Browser.
Note: The dialog boxes and menu commands you see might differ from those described in Help
depending on your active settings or edition. To change your settings, choose Import and Export Settings
on the Tools menu. For more information, see Working with Settings.
Attention:
Opening certain files or components from the Web can execute code on your computer. For
more information, see Code Access Security.
Home page
Sets the page displayed when you open the Integrated Development Environment Web Browser.
Search page
Lets you designate a Search page for the internal Web browser. This location can differ from the search
page used by instances of Internet Explorer initiated outside of the integrated development environment
(IDE).
View Source in
Sets the editor used to open a Web page when you choose View Source on the page from the internal
Web browser.
Source editor
Select to view source in the Code and Text Editor.
HTML editor
Select to view source in the HTML Designer. Use this selection to edit the Web page in one of two views:
Design view or the standard text-based Source view.
External editor
Select to view source in another editor. Specify the path of any editor you choose, for example,
Notepad.exe.
Internet Explorer Options
Click to change options for Internet Explorer in the Internet Properties dialog box. Changes made in this
dialog box affect both the internal Web browser and instances of Internet Explorer initiated outside of the
Atmel Studio IDE (for example, from the Start menu).
9.3.1.12. Custom Start Pages
The Atmel Studio Start Page is a Windows Presentation Foundation (WPF) Extensible Application
Markup Language (XAML) page that runs in an Atmel Studio tool window. The Start Page tool window
can run Atmel Studio internal commands. When Atmel Studio starts, it opens the current default Start
Page. If you have installed a third-party Start Page, you can set that page as the default by using the
Options dialog box.
Installing and Applying a Custom Start Page
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
217
You can install custom Start Pages by using the Online Gallery section of Extension Manager. You can
also install directly from a Web site or local intranet page by locating and opening a .vsix file that contains
a custom Start Page, or by copying the Start Page files and pasting them into in the Documents\Atmel
Studio\StartPages\ folder on your computer.
You can apply a custom Start Page by selecting it in the Options dialog box. Start pages installed by
Extension Manager will appear in the Customize Start Page list as [InstalledExtension] Extension Name.
Start pages dropped into the \StartPages folder will include a partial file path in the list entry, as shown in
the following example.
Documents\Atmel Studio 6\StartPages\StartPage.xaml
To apply a custom Start Page
1. On the Tools menu, click Options.
2. On the left side of the Options dialog box, expand the Environment node, and then click Startup.
3. In the Customize Start Page list, select the Start Page you want.
4. This list includes every .xaml file in your user Start Pages folder and any installed extensions of
type StartPage.
5. Click OK.
Troubleshooting
It is possible for an error in a third-party Start Page to cause Atmel Studio to crash. If this happens, you
can start Atmel Studio in safe mode by adding the /SafeMode switch to the application, i.e.
avrstudio5.exe /SafeMode.
This prevents the bad Start Page from loading. You can then return to the Options dialog box and reset
Atmel Studio to use the default Start Page.
9.3.2. Project Options
9.3.2.1. General Settings
Sets the default path of Atmel Studio project folders, and determines the default behavior of the Output
window, Task List, and Solution Explorer as projects are developed and built. To access this dialog box,
on the Tools menu, click Options, expand Projects and Solutions, and click General.
Note: The options are available in the dialog boxes, and the names and locations of menu commands
you see, might differ from what is described in Help depending on your active settings or edition. This
Help page was written with the General Development settings in mind. To view or change your settings,
choose Import and Export Settings on the Tools menu. For more information, see Working with Settings.
Projects location
Sets the default location where new projects and solution folders and directories are created. Several
dialog boxes also use the location set in this option for folder starting points. For example, the Open
Project dialog box uses this location for the My Projects shortcut.
User project templates location
Sets the default location that is used by the New Project dialog box to create the list of My Templates. For
more information, see How to: Locate and Organize Project and Item Templates.
User item templates location
Sets the default location that is used by the Add New Item dialog box to create the list of My Templates.
For more information, see How to: Locate and Organize Project and Item Templates.
Always show Error List if build finishes with errors
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
218
Opens the Error List window on build completion, only if a project failed to build. Errors that occur during
the build process are displayed. When this option is cleared, the errors still occur but the window does not
open when the build is complete. This option is enabled by default.
Track Active Item in Solution Explorer
When selected, Solution Explorer automatically opens and the active item is selected. The selected item
changes as you work with different files in a project or solution, or different components in a designer.
When this option is cleared, the selection in Solution Explorer does not change automatically. This option
is enabled by default.
Show advanced build configurations
When selected, the build configuration options appear on the Project Property Pages dialog box and the
Solution Property Pages dialog box. When cleared, the build configuration options do not appear on the
Project Property Pages dialog box and the Solution Property Pages dialog box for projects that contain
one configuration or the two configurations debug and release. If a project has a user-defined
configuration, the build configuration options are shown.
When deselected, the commands on the Build menu, such as Build Solution, Rebuild Solution, and Clean
Solution, are performed on the Release configuration and the commands on the Debug menu, such as
Start Debugging and Start Without Debugging, are performed on the Debug configuration.
Always show solution
When selected, the solution and all commands that act on solutions are always shown in the IDE. When
cleared, all projects are created as standalone projects and you do not see the solution in Solution
Explorer or commands that act on solutions in the IDE if the solution contains only one project.
Save new projects when created
When selected, you can specify a location for your project in the New Project dialog box. When cleared,
all new projects are created as temporary projects. When you are working with temporary projects, you
can create and experiment with a project without having to specify a disk location.
Warn user when the project location is not trusted
If you attempt to create a new project or open an existing project in a location that is not fully trusted (for
example, on a UNC path or an HTTP path), a message is displayed. Use this option to specify whether
the message is displayed each time that you attempt to create or open a project in a location that is not
fully trusted.
Show Output window when build starts
Automatically displays the Output Window in the IDE at the outset of solution builds. For more
information, see How to: Control the Output Window. This option is enabled by default.
Prompt for symbolic renaming when renaming files
When selected, displays a message box asking whether or not AVR Studio 5 should also rename all
references in the project to the code element.
9.3.2.2. Build and Run Options
Determines whether changed files are automatically saved when a project or its solution is built, the
maximum number of Visual C++ projects that can build at the same time, and certain default behavior on
Run. To access this dialog box, on the Tools menu, click Options, click Projects and Solutions, and then
click Build and Run.
Save all changes
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
219
Automatically saves changes to the solution file and all project files that were changed since the last build
when you press F5, or click Start on the Debug menu or Build on the Build menu. No prompt is given.
Items are saved with their current names. By default, this option is enabled.
Save changes to open documents only
Automatically saves changes to all open documents when you press F5, or click Start on the Debug
menu or Build on the Build menu. No prompt is given.
Prompt to save all changes
When selected, displays a dialog box that asks whether you want to save changes to the solution and
project items when you press F5 or click Start on the Debug menu or Build on the Build menu. The Save
As dialog box is displayed so that you can assign a name and location to your project. If this option is not
selected, the project runs by using the memory image that contains your changes, but the changes are
not saved.
Don't save any changes
When you run your project, the integrated development environment (IDE) runs the code version in the
open documents and does not save changes to open documents.
Maximum number of parallel project builds
Specifies the maximum number of projects that can build at the same time. To optimize the build process,
the maximum number of parallel project builds is automatically set to the number of CPUs of your
computer. The maximum is 32. For more information, see Multiprocessor Builds.
Only build start-up projects and dependencies on Run
When selected, pressing F5 or clicking Start on the Debug menu or Build on the Build menu only builds
the start-up project and its dependencies. When this option is cleared, pressing F5 builds all projects,
dependencies, and solution files. By default, this option is cleared.
Always build
The message box is not displayed and the out of date project configuration is built. This option is set
when you select Do not show this dialog again in the message, and then click Yes.
Never build
The message box is not displayed and the out of date project configuration is not built. This option is set
when you select Do not show this dialog again in the message, and then click No.
Prompt to build
Displays the message box every time that a project configuration is out of date.
Prompt to launch
Displays the message box every time that build errors occur.
Do not launch
The message box is not displayed and the application is not started. This option is set when you select
Do not show this dialog again in the message box, and then click No.
Launch old version
The message box is not displayed and the newly built version of the application is not started. This option
is set when you select Do not show this dialog again in the message box, and then click Yes.
For new solutions use the currently selected project as the start-up project
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
220
If selected, new solutions use the currently selected project as the start-up project.
MSBuild project build output verbosity
Sets the verbosity level for the build output. For more information, see the /verbosity switch in MSBuild
Command Line Reference.
MSBuild project build log file verbosity
Sets the verbosity level for the build log file. For more information, see the /verbosity switch in MSBuild
Command Line Reference.
9.3.3. Source Control
If you have plugins for source control (SVN, ClearCase, Vault, Git, etc.) installed, you should select it from
the drop-down list in this section, to activate and use your plugin with the source repository.
9.3.4. Text Editor Options
9.3.4.1. General Settings
This dialog box lets you change global settings for the Visual Studio Code and Text Editor. To display this
dialog box, click Options on the Tools menu, expand the Text Editor folder, and then click General.
Note: The dialog boxes and menu commands you see might differ from those described in Help
depending on your active settings or edition. To change your settings, choose Import and Export Settings
on the Tools menu. For more information, see Working with Settings.
Settings
Drag and drop text editing
When selected, this enables you to move text by selecting and dragging the text with the mouse to
another location within the current document or any other open document.
Automatic delimiter highlighting
When selected, delimiter characters that separate parameters or item-value pairs, as well as matching
braces, are highlighted.
Track changes
When selected, the code editor's selection margin displays a vertical yellow line to mark code recently
changed, and vertical green lines next to unchanged code.
Auto-detect UTF-8 encoding without signature
By default, the editor detects encoding by searching for byte order marks or charset tags. If neither is
found in the current document, the code editor attempts to auto-detect UTF-8 encoding by scanning byte
sequences. To disable the auto-detection of encoding, clear this option.
Display
Selection margin
When selected, a vertical margin along the left edge of the editor's text area is displayed. You can click
this margin to select an entire line of text, or click and drag to select consecutive lines of text. Selection
Margin on / Selection Margin off
Indicator margin
When selected, a vertical margin outside the left edge of the editor's text area is displayed. When you
click in this margin, an icon and ToolTip that are related to the text appear. For example, breakpoint or
task list shortcuts appear in the indicator margin. Indicator Margin information does not print.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
221
Vertical scroll bar
When selected, a vertical scrollbar which allows you to scroll up and down to view elements that fall
outside the viewing area of the Editor is displayed. If vertical scrollbars are not available, you can use the
Page Up, Page Down, and cursor keys to scroll.
Horizontal scroll bar
When selected, a horizontal scrollbar which allows you to scroll from side-to-side to view elements that
fall outside the viewing area of the Editor is displayed. If horizontal scrollbars are unavailable, you can
use the cursor keys to scroll.
9.3.4.2. File Extensions and Associations
There you can specify tool association of the source file extensions.
9.3.4.3. General Language Options
This dialog box allows you to change the default behavior of the Code Editor. These settings also apply to
other editors based upon the Code Editor, such as the HTML Designer's Source view. To open this dialog
box, select Options from the Tools menu. Within the Text Editor folder, expand the All Languages sub
folder and then select General.
Caution:
This page sets default options for all development languages. Remember that resetting an
option in this dialog will reset the General options in all languages to whatever choices are
selected here. To change Text Editor options for just one language, expand the sub folder for
that language and select its option pages.
A grayed checkmark is displayed when an option has been selected on the General options pages for
some programming languages, but not for others.
Note: The dialog boxes and menu commands you see might differ from those described in Help
depending on your active settings or edition. To change your settings, choose Import and Export Settings
on the Tools menu. For more information, see Working with Settings.
Statement Completion
Auto list members
When selected, pop-up lists of available members, properties, values, or methods are displayed by
IntelliSense as you type in the editor. Choose any item from the pop-up list to insert the item into your
code. Selecting this option enables the Hide advanced members option. For more information, see List
Members.
Hide advanced members
When selected, shortens pop-up statement completion lists by displaying only those items most
commonly used. Other items are filtered from the list.
Parameter information
When selected, the complete syntax for the current declaration or procedure is displayed under the
insertion point in the editor, with all of its available parameters. The next parameter you can assign is
displayed in bold. For more information, see Parameter Info.
Settings
Enable virtual space
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
222
When this option is selected and Word wrap is cleared, you can click anywhere beyond the end of a line
in the Code Editor, and type. This feature can be used to position comments at a consistent point next to
your code.
Word wrap
When selected, any portion of a line that extends horizontally beyond the viewable editor area is
automatically displayed on the next line. Selecting this option enables the Show visual glyphs for word
wrap option.
Note: The Virtual Space feature is turned off while Word Wrap is on.
Show visual glyphs for word wrap
When selected, a return-arrow indicator is displayed where a long line wraps onto a second line.
Clear this option if you prefer not to display these indicators.
Note: These reminder arrows are not added to your code, and do not print. They are for reference only.
Apply Cut or Copy commands to blank lines when there is no selection
This option sets the behavior of the editor when you place the insertion point on a blank line, select
nothing, and then Copy or Cut.
When this option is selected, the blank line is copied or cut. If you then Paste, a new and blank line is
inserted.
When this option is cleared, the Cut command removes blank lines. However, the data on the Clipboard
is preserved. Therefore, if you then use the Paste command, the content most recently copied onto the
Clipboard is pasted. If nothing has been copied previously, nothing is pasted.
This setting has no effect on Copy or Cut when a line is not blank. If nothing is selected, the entire line is
copied or cut. If you then Paste, the text of the entire line and its endline character are pasted.
Tip:
To display indicators for spaces, tabs, and line ends, and thus distinguish indented lines from
lines that are entirely blank, select Advanced from the Edit menu and choose View White
Space.
Display
Line numbers
When selected, a line number appears next to each line of code.
Note: These line numbers are not added to your code, and do not print. They are for reference only.
Enable single-click URL navigation
When selected, the mouse cursor changes to a pointing hand as it passes over a URL in the editor. You
can click the URL to display the indicated page in your Web browser.
Navigation bar
When selected, the Navigation bar at the top of the code editor is displayed. Its drop-down Objects and
Members lists allow you to choose a particular object in your code, select from its members, and
navigates to the declaration of the selected member in the Code Editor.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
223
9.3.4.4. Tabs Dialog
This dialog box allows you to change the default behavior of the Code Editor. These settings also apply to
other editors based upon the Code Editor, such as the HTML Designer's Source view. To display these
options, select Options from the Tools menu. Within the Text Editor folder expand the All Languages sub
folder, and then choose Tabs.
Caution:
This page sets default options for all development languages. Remember that resetting an
option in this dialog will reset the Tabs options in all languages to whatever choices are selected
here. To change Text Editor options for just one language, expand the sub folder for that
language and select its option pages.
If different settings are selected on the Tabs options pages for particular programming
languages, then the message "The indentation settings for individual text formats conflict with
each other," is displayed for differing Indenting options; and the message "The tab settings for
individual text formats conflict with each other," is displayed for differing Tab options.
Note: The dialog boxes and menu commands you see might differ from those described in Help
depending on your active settings or edition. To change your settings, choose Import and Export Settings
on the Tools menu. For more information, see Working with Settings.
Indenting
None
When selected, new lines are not indented. The insertion point is placed in the first column of a new line.
Block
When selected, new lines are automatically indented. The insertion point is placed at the same starting
point as the preceding line.
Smart
When selected, new lines are positioned to fit the code context, per other code formatting settings and
IntelliSense conventions for your development language. This option is not available for all development
languages.
For example, lines enclosed between an opening brace ( { ) and a closing brace ( } ) might automatically
be indented an extra tab stop from the position of the aligned braces.
Tab and indent size
Sets the distance in spaces between tab stops and for automatic indentation. The default is four spaces.
Tab characters, space characters, or both will be inserted to fill the specified size.
Insert spaces
When selected, indent operations insert only space characters, not TAB characters. If the Tab and Indent
size is set to 5, for example, then five space characters are inserted whenever you press the TAB key or
the Increase Indent button on the Formatting toolbar.
Keep tabs
When selected, each indent operation inserts one TAB character.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
224
9.3.4.5. AVR Assembler Language-specific Settings
General Language Options
This dialog box allows you to change the default behavior of the Code Editor. These settings also apply to
other editors based upon the Code Editor, such as the HTML Designer's Source view. To open this dialog
box, select Options from the Tools menu. Within the Text Editor folder, expand the All Languages sub
folder and then choose General.
Caution:
This page sets default options for all development languages. Remember that resetting an
option in this dialog will reset the General options in all languages to whatever choices are
selected here. To change Text Editor options for just one language, expand the sub folder for
that language and select its option pages.
A grayed checkmark is displayed when an option has been selected on the General options pages for
some programming languages, but not for others.
Note: The dialog boxes and menu commands you see might differ from those described in Help
depending on your active settings or edition. To change your settings, choose Import and Export Settings
on the Tools menu. For more information, see Working with Settings.
Statement Completion
Auto list members
When selected, pop-up lists of available members, properties, values, or methods are displayed by
IntelliSense as you type in the editor. Choose any item from the pop-up list to insert the item into your
code. Selecting this option enables the Hide advanced members option. For more information, see List
Members.
Hide advanced members
When selected it shortens the pop-up statement completion lists by displaying only those items most
commonly used. Other items are filtered from the list.
Parameter information
When selected, the complete syntax for the current declaration or procedure is displayed under the
insertion point in the editor, with all of its available parameters. The next parameter you can assign is
displayed in bold. For more information, see Parameter Info.
Settings
Enable virtual space
When this option is selected and Word wrap is cleared, you can click anywhere beyond the end of a line
in the Code Editor and type. This feature can be used to position comments at a consistent point next to
your code.
Word wrap
When selected, any portion of a line that extends horizontally beyond the viewable editor area is
automatically displayed on the next line. Selecting this option enables the Show visual glyphs for word
wrap option.
Note: The Virtual Space feature is turned off while Word Wrap is on.
Show visual glyphs for word wrap
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
225
When selected, a return-arrow indicator is displayed where a long line wraps onto a second line.
Clear this option if you prefer not to display these indicators.
Note: These reminder arrows are not added to your code, and do not print. They are for reference only.
Apply Cut or Copy commands to blank lines when there is no selection
This option sets the behavior of the editor when you place the insertion point on a blank line, select
nothing, and then Copy or Cut.
When this option is selected, the blank line is copied or cut. If you then Paste, a new, blank line is
inserted.
When this option is cleared, the Cut command removes blank lines. However, the data on the Clipboard
is preserved. Therefore, if you then use the Paste command, the content most recently copied onto the
Clipboard is pasted. If nothing has been copied previously, nothing is pasted.
This setting has no effect on Copy or Cut when a line is not blank. If nothing is selected, the entire line is
copied or cut. If you then Paste, the text of the entire line and its endline character are pasted.
Tip:
To display indicators for spaces, tabs, and line ends, and thus distinguish indented lines from
lines that are entirely blank, select Advanced from the Edit menu and choose View White
Space.
Display
Line numbers
When selected, a line number appears next to each line of code.
Note: These line numbers are not added to your code, and do not print. They are for reference only.
Enable single-click URL navigation
When selected, the mouse cursor changes to a pointing hand as it passes over a URL in the editor. You
can click the URL to display the indicated page in your Web browser.
Navigation bar
When selected, displays the Navigation bar at the top of the code editor. Its dropdown Objects and
Members lists allow you to choose a particular object in your code, select from its members, and
navigates to the declaration of the selected member in the Code Editor.
Tabs Dialog
This dialog box allows you to change the default behavior of the Code Editor. These settings also apply to
other editors based upon the Code Editor, such as the HTML Designer's Source view. To display these
options, select Options from the Tools menu. Within the Text Editor folder expand the All Languages sub
folder, and then choose Tabs.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
226
Caution:
This page sets default options for all development languages. Remember that resetting an
option in this dialog will reset the Tabs options in all languages to whatever choices are selected
here. To change Text Editor options for just one language, expand the sub folder for that
language and select its option pages.
If different settings are selected on the Tabs options pages for particular programming
languages, then the message "The indentation settings for individual text formats conflict with
each other," is displayed for differing Indenting options; and the message "The tab settings for
individual text formats conflict with each other," is displayed for differing Tab options.
Note: The dialog boxes and menu commands you see might differ from those described in Help
depending on your active settings or edition. To change your settings, choose Import and Export Settings
on the Tools menu. For more information, see Working with Settings.
Indenting
None
When selected, new lines are not indented. The insertion point is placed in the first column of a new line.
Block
When selected, new lines are automatically indented. The insertion point is placed at the same starting
point as the preceding line.
Smart
When selected, new lines are positioned to fit the code context, per other code formatting settings and
IntelliSense conventions for your development language. This option is not available for all development
languages.
For example, lines enclosed between an opening brace ( { ) and a closing brace ( } ) might automatically
be indented an extra tab stop from the position of the aligned braces.
Tab and indent size
Sets the distance in spaces between tab stops and for automatic indentation. The default is four spaces.
Tab characters, space characters, or both will be inserted to fill the specified size.
Insert spaces
When selected, indent operations insert only space characters, not TAB characters. If the Tab and Indent
size is set to 5, for example, then five space characters are inserted whenever you press the TAB key or
the Increase Indent button on the Formatting toolbar.
Keep tabs
When selected, each indent operation inserts one TAB character.
9.3.4.6. AVR GCC Language-specific Settings
General Language Options
This dialog box allows you to change the default behavior of the Code Editor. These settings also apply to
other editors based upon the Code Editor, such as the HTML Designer's Source view. To open this dialog
box, select Options from the Tools menu. Within the Text Editor folder, expand the All Languages sub
folder and then choose General.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
227
Caution:
This page sets default options for all development languages. Remember that resetting an
option in this dialog will reset the General options in all languages to whatever choices are
selected here. To change Text Editor options for just one language, expand the sub folder for
that language and select its option pages.
A grayed checkmark is displayed when an option has been selected on the General options pages for
some programming languages, but not for others.
Note: The dialog boxes and menu commands you see might differ from those described in Help
depending on your active settings or edition. To change your settings, choose Import and Export Settings
on the Tools menu. For more information, see Working with Settings.
Statement Completion
Auto list members
When selected, pop-up lists of available members, properties, values, or methods are displayed by
IntelliSense as you type in the editor. Choose any item from the pop-up list to insert the item into your
code. Selecting this option enables the Hide advanced members option. For more information, see List
Members.
Hide advanced members
When selected it shortens the pop-up statement completion lists by displaying only those items most
commonly used. Other items are filtered from the list.
Parameter information
When selected, the complete syntax for the current declaration or procedure is displayed under the
insertion point in the editor, with all of its available parameters. The next parameter you can assign is
displayed in bold. For more information, see Parameter Info.
Settings
Enable virtual space
When this option is selected and Word wrap is cleared, you can click anywhere beyond the end of a line
in the Code Editor and type. This feature can be used to position comments at a consistent point next to
your code.
Word wrap
When selected, any portion of a line that extends horizontally beyond the viewable editor area is
automatically displayed on the next line. Selecting this option enables the Show visual glyphs for word
wrap option.
Note: The Virtual Space feature is turned off while Word Wrap is on.
Show visual glyphs for word wrap
When selected, a return-arrow indicator is displayed where a long line wraps onto a second line.
Clear this option if you prefer not to display these indicators.
Note: These reminder arrows are not added to your code, and do not print. They are for reference only.
Apply Cut or Copy commands to blank lines when there is no selection
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
228
This option sets the behavior of the editor when you place the insertion point on a blank line, select
nothing, and then Copy or Cut.
When this option is selected, the blank line is copied or cut. If you then Paste, a new, blank line is
inserted.
When this option is cleared, the Cut command removes blank lines. However, the data on the Clipboard
is preserved. Therefore, if you then use the Paste command, the content most recently copied onto the
Clipboard is pasted. If nothing has been copied previously, nothing is pasted.
This setting has no effect on Copy or Cut when a line is not blank. If nothing is selected, the entire line is
copied or cut. If you then Paste, the text of the entire line and its endline character are pasted.
Tip:
To display indicators for spaces, tabs, and line ends, and thus distinguish indented lines from
lines that are entirely blank, select Advanced from the Edit menu and choose View White
Space.
Display
Line numbers
When selected, a line number appears next to each line of code.
Note: These line numbers are not added to your code, and do not print. They are for reference only.
Enable single-click URL navigation
When selected, the mouse cursor changes to a pointing hand as it passes over a URL in the editor. You
can click the URL to display the indicated page in your Web browser.
Navigation bar
When selected, displays the Navigation bar at the top of the code editor. Its drop-down Objects and
Members lists allow you to choose a particular object in your code, select from its members, and
navigates to the declaration of the selected member in the Code Editor.
Tabs Dialog
This dialog box allows you to change the default behavior of the Code Editor. These settings also apply to
other editors based upon the Code Editor, such as the HTML Designer's Source view. To display these
options, select Options from the Tools menu. Within the Text Editor folder expand the All Languages
subfolder, and then choose Tabs.
Caution:
This page sets default options for all development languages. Remember that resetting an
option in this dialog will reset the Tabs options in all languages to whatever choices are selected
here. To change Text Editor options for just one language, expand the subfolder for that
language and select its option pages.
If different settings are selected on the Tabs options pages for particular programming
languages, then the message "The indentation settings for individual text formats conflict with
each other," is displayed for differing Indenting options; and the message "The tab settings for
individual text formats conflict with each other," is displayed for differing Tab options.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
229
Note: The dialog boxes and menu commands you see might differ from those described in Help
depending on your active settings or edition. To change your settings, choose Import and Export Settings
on the Tools menu. For more information, see Working with Settings.
Indenting
None
When selected, new lines are not indented. The insertion point is placed in the first column of a new line.
Block
When selected, new lines are automatically indented. The insertion point is placed at the same starting
point as the preceding line.
Smart
When selected, new lines are positioned to fit the code context, per other code formatting settings and
IntelliSense conventions for your development language. This option is not available for all development
languages.
For example, lines enclosed between an opening brace ( { ) and a closing brace ( } ) might automatically
be indented an extra tab stop from the position of the aligned braces.
Tab and indent size
Sets the distance in spaces between tab stops and for automatic indentation. The default is four spaces.
Tab characters, space characters, or both will be inserted to fill the specified size.
Insert spaces
When selected, indent operations insert only space characters, not TAB characters. If the Tab and Indent
size is set to 5, for example, then five space characters are inserted whenever you press the TAB key or
the Increase Indent button on the Formatting toolbar.
Keep tabs
When selected, each indent operation inserts one TAB character.
9.3.4.7. Plain Text Settings
General Language Options
This dialog box allows you to change the default behavior of the Code Editor. These settings also apply to
other editors based upon the Code Editor, such as the HTML Designer's Source view. To open this dialog
box, select Options from the Tools menu. Within the Text Editor folder, expand the All Languages
subfolder and then choose General.
Caution:
This page sets default options for all development languages. Remember that resetting an
option in this dialog will reset the General options in all languages to whatever choices are
selected here. To change Text Editor options for just one language, expand the subfolder for
that language and select its option pages.
A grayed checkmark is displayed when an option has been selected on the General options pages for
some programming languages, but not for others.
Note: The dialog boxes and menu commands you see might differ from those described in Help
depending on your active settings or edition. To change your settings, choose Import and Export Settings
on the Tools menu. For more information, see Working with Settings.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
230
Statement Completion
Auto list members
When selected, pop-up lists of available members, properties, values, or methods are displayed by
IntelliSense as you type in the editor. Choose any item from the pop-up list to insert the item into your
code. Selecting this option enables the Hide advanced members option. For more information, see List
Members.
Hide advanced members
When selected, it shortens the pop-up statement completion lists by displaying only those items most
commonly used. Other items are filtered from the list.
Parameter information
When selected, the complete syntax for the current declaration or procedure is displayed under the
insertion point in the editor, with all of its available parameters. The next parameter you can assign is
displayed in bold. For more information, see Parameter Info.
Settings
Enable virtual space
When this option is selected and Word wrap is cleared, you can click anywhere beyond the end of a line
in the Code Editor and type. This feature can be used to position comments at a consistent point next to
your code.
Word wrap
When selected, any portion of a line that extends horizontally beyond the viewable editor area is
automatically displayed on the next line. Selecting this option enables the Show visual glyphs for word
wrap option.
Note: The Virtual Space feature is turned OFF while Word Wrap is ON.
Show visual glyphs for word wrap
When selected, a return-arrow indicator is displayed where a long line wraps onto a second line.
Clear this option if you prefer not to display these indicators.
Note: These reminder arrows are not added to your code, and do not print. They are for reference only.
Apply Cut or Copy commands to blank lines when there is no selection
This option sets the behavior of the editor when you place the insertion point on a blank line, select
nothing, and then Copy or Cut.
When this option is selected, the blank line is copied or cut. If you then Paste, a new, blank line is
inserted.
When this option is cleared, the Cut command removes blank lines. However, the data on the Clipboard
is preserved. Therefore, if you then use the Paste command, the content most recently copied onto the
Clipboard is pasted. If nothing has been copied previously, nothing is pasted.
This setting has no effect on Copy or Cut when a line is not blank. If nothing is selected, the entire line is
copied or cut. If you then Paste, the text of the entire line and its endline character are pasted.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
231
Tip:
To display indicators for spaces, tabs, and line ends, and thus distinguish indented lines from
lines that are entirely blank, select Advanced from the Edit menu and choose View White
Space.
Display
Line numbers
When selected, a line number appears next to each line of code.
Note: These line numbers are not added to your code, and do not print. They are for reference only.
Enable single-click URL navigation
When selected, the mouse cursor changes to a pointing hand as it passes over a URL in the editor. You
can click the URL to display the indicated page in your Web browser.
Navigation bar
When selected, displays the Navigation bar at the top of the code editor. Its drop-down Objects and
Members lists allow you to choose a particular object in your code, select from its members, and
navigates to the declaration of the selected member in the Code Editor.
Tabs Dialog
This dialog box allows you to change the default behavior of the Code Editor. These settings also apply to
other editors based upon the Code Editor, such as the HTML Designer's Source view. To display these
options, select Options from the Tools menu. Within the Text Editor folder expand the All Languages
subfolder, and then choose Tabs.
Caution:
This page sets default options for all development languages. Remember that resetting an
option in this dialog will reset the Tabs options in all languages to whatever choices are selected
here. To change Text Editor options for just one language, expand the subfolder for that
language and select its option pages.
If different settings are selected on the Tabs options pages for particular programming
languages, then the message "The indentation settings for individual text formats conflict with
each other," is displayed for differing Indenting options; and the message "The tab settings for
individual text formats conflict with each other," is displayed for differing Tab options.
Note: The dialog boxes and menu commands you see might differ from those described in Help
depending on your active settings or edition. To change your settings, choose Import and Export Settings
on the Tools menu. For more information, see Working with Settings.
Indenting
None
When selected, new lines are not indented. The insertion point is placed in the first column of a new line.
Block
When selected, new lines are automatically indented. The insertion point is placed at the same starting
point as the preceding line.
Smart
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
232
When selected, new lines are positioned to fit the code context, per other code formatting settings and
IntelliSense conventions for your development language. This option is not available for all development
languages.
For example, lines enclosed between an opening brace ( { ) and a closing brace ( } ) might automatically
be indented an extra tab stop from the position of the aligned braces.
Tab and indent size
Sets the distance in spaces between tab stops and for automatic indentation. The default is four spaces.
Tab characters, space characters, or both will be inserted to fill the specified size.
Insert spaces
When selected, indent operations insert only space characters, not TAB characters. If the Tab and Indent
size is set to 5, for example, then five space characters are inserted whenever you press the TAB key or
the Increase Indent button on the Formatting toolbar.
Keep tabs
When selected, each indent operation inserts one TAB character.
9.3.4.8. XML Settings
General Language Options
This dialog box allows you to change the default behavior of the Code Editor. These settings also apply to
other editors based upon the Code Editor, such as the HTML Designer's Source view. To open this dialog
box, select Options from the Tools menu. Within the Text Editor folder, expand the All Languages
subfolder and then choose General.
Caution:
This page sets default options for all development languages. Remember that resetting an
option in this dialog will reset the General options in all languages to whatever choices are
selected here. To change Text Editor options for just one language, expand the subfolder for
that language and select its option pages.
A grayed checkmark is displayed when an option has been selected on the General options pages for
some programming languages, but not for others.
Note: The dialog boxes and menu commands you see might differ from those described in Help
depending on your active settings or edition. To change your settings, choose Import and Export Settings
on the Tools menu. For more information, see Working with Settings.
Statement Completion
Auto list members
When selected, pop-up lists of available members, properties, values, or methods are displayed by
IntelliSense as you type in the editor. Choose any item from the pop-up list to insert the item into your
code. Selecting this option enables the Hide advanced members option. For more information, see List
Members.
Hide advanced members
When selected, shortens pop-up statement completion lists by displaying only those items most
commonly used. Other items are filtered from the list.
Parameter information
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
233
When selected, the complete syntax for the current declaration or procedure is displayed under the
insertion point in the editor, with all of its available parameters. The next parameter you can assign is
displayed in bold. For more information, see Parameter Info.
Settings
Enable virtual space
When this option is selected and Word wrap is cleared, you can click anywhere beyond the end of a line
in the Code Editor and type. This feature can be used to position comments at a consistent point next to
your code.
Word wrap
When selected, any portion of a line that extends horizontally beyond the viewable editor area is
automatically displayed on the next line. Selecting this option enables the Show visual glyphs for word
wrap option.
Note: The Virtual Space feature is turned off while Word Wrap is on.
Show visual glyphs for word wrap
When selected, a return-arrow indicator is displayed where a long line wraps onto a second line.
Clear this option if you prefer not to display these indicators.
Note: These reminder arrows are not added to your code, and do not print. They are for reference only.
Apply Cut or Copy commands to blank lines when there is no selection
This option sets the behavior of the editor when you place the insertion point on a blank line, select
nothing, and then Copy or Cut.
When this option is selected, the blank line is copied or cut. If you then Paste, a new, blank line is
inserted.
When this option is cleared, the Cut command removes blank lines. However, the data on the Clipboard
is preserved. Therefore, if you then use the Paste command, the content most recently copied onto the
Clipboard is pasted. If nothing has been copied previously, nothing is pasted.
This setting has no effect on Copy or Cut when a line is not blank. If nothing is selected, the entire line is
copied or cut. If you then Paste, the text of the entire line and its endline character are pasted.
Tip:
To display indicators for spaces, tabs, and line ends, and thus distinguish indented lines from
lines that are entirely blank, select Advanced from the Edit menu and choose View White
Space.
Display
Line numbers
When selected, a line number appears next to each line of code.
Note: These line numbers are not added to your code, and do not print. They are for reference only.
Enable single-click URL navigation
When selected, the mouse cursor changes to a pointing hand as it passes over a URL in the editor. You
can click the URL to display the indicated page in your Web browser.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
234
Navigation bar
When selected, displays the Navigation bar at the top of the code editor. Its drop-down Objects and
Members lists allow you to choose a particular object in your code, select from its members, and
navigates to the declaration of the selected member in the Code Editor.
Tabs Dialog
This dialog box allows you to change the default behavior of the Code Editor. These settings also apply to
other editors based upon the Code Editor, such as the HTML Designer's Source view. To display these
options, select Options from the Tools menu. Within the Text Editor folder expand the All Languages
subfolder, and then choose Tabs.
Caution:
This page sets default options for all development languages. Remember that resetting an
option in this dialog will reset the Tabs options in all languages to whatever choices are selected
here. To change Text Editor options for just one language, expand the subfolder for that
language and select its option pages.
If different settings are selected on the Tabs options pages for particular programming
languages, then the message "The indentation settings for individual text formats conflict with
each other," is displayed for differing Indenting options; and the message "The tab settings for
individual text formats conflict with each other," is displayed for differing Tab options.
Note: The dialog boxes and menu commands you see might differ from those described in Help
depending on your active settings or edition. To change your settings, choose Import and Export Settings
on the Tools menu. For more information, see Working with Settings.
Indenting
None
When selected, new lines are not indented. The insertion point is placed in the first column of a new line.
Block
When selected, new lines are automatically indented. The insertion point is placed at the same starting
point as the preceding line.
Smart
When selected, new lines are positioned to fit the code context, per other code formatting settings and
IntelliSense conventions for your development language. This option is not available for all development
languages.
For example, lines enclosed between an opening brace ( { ) and a closing brace ( } ) might automatically
be indented an extra tab stop from the position of the aligned braces.
Tab and indent size
Sets the distance in spaces between tab stops and for automatic indentation. The default is four spaces.
Tab characters, space characters, or both will be inserted to fill the specified size.
Insert spaces
When selected, indent operations insert only space characters, not TAB characters. If the Tab and Indent
size is set to 5, for example, then five space characters are inserted whenever you press the TAB key or
the Increase Indent button on the Formatting toolbar.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
235
Keep tabs
When selected, each indent operation inserts one TAB character.
XML Formatting Options
This dialog box allows you to specify the formatting settings for the XML Editor. You can access the
Options dialog box from the Tools menu.
Note: These settings are available when you select the Text Editor folder, the XML folder, and then the
Formatting option from the Options dialog box.
Attributes
Preserve manual attribute formatting Attributes are not reformatted. This is the default.
Note: If the attributes are on multiple lines, the editor indents each line of attributes to match the
indentation of the parent element.
Align attributes each on their own line
Aligns the second and subsequent attributes vertically to match the indentation of the first attribute. The
following XML text is an example of how the attributes would be aligned.
-
Auto Reformat
On paste from the Clipboard
Reformats XML text pasted from the Clipboard.
On completion of end tag
Reformats the element when the end tag is completed.
Mixed Content
Preserve mixed content by default
Determines whether the editor reformats mixed content. By default, the editor attempts to reformat mixed
content, except when the content is found in an xml:space="preserve" scope.
If an element contains a mix of text and markup, the contents are considered to be mixed content. The
following is an example of an element with mixed content.
c:\data\AlphaProject\
test1.txt
test2.txt
XML Miscellaneous Options
This dialog box allows you to change the autocompletion and schema settings for the XML Editor. You
can access the Options dialog box from the Tools menu.
Note: These settings are available when you select the Text Editor folder, the XML folder, and then the
Miscellaneous option from the Options dialog box.
Auto Insert
Close tags
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
236
If the autocompletion setting is checked, the editor automatically adds an end tag when you type a right
angle bracket (>) to close a start tag, if the tag is not already closed. This is the default behavior.
The completion of an empty element does not depend on the autocompletion setting. You can always
autocomplete an empty element by typing a backslash (/).
Attribute quotes
When authoring XML attributes, the editor inserts the =" " characters and positions the caret (^) inside the
double quotes.
Selected by default.
Namespace declarations
The editor automatically inserts namespace declarations wherever they are needed.
Selected by default.
Other markup (Comments, CDATA)
Comments, CDATA, DOCTYPE, processing instructions, and other markup are auto-completed.
Selected by default.
Network
Automatically download DTDs and schemas
Schemas and document type definitions (DTDs) are automatically downloaded from HTTP locations. This
feature uses System.Net with auto-proxy server detection enabled.
Selected by default.
Outlining
Enter outlining mode when files open
Turns on the outlining feature when a file is opened.
Selected by default.
Caching
Schemas
Specifies the location of the schema cache. The browse button ( ...) opens the Directory Browse dialog
box at the current schema cache location. You can select a different directory, or you can select a folder
in the dialog, right-click, and choose Open to see what is in the directory.
9.3.5. Debugger
9.3.5.1. Usage
In Atmel Studio, you can specify various settings for debugger behavior, including how variables are
displayed, whether certain warnings are presented, how breakpoints are set, and how breaking affects
running programs. You specify debugger settings in the Options dialog box.
To set debugger options
On the Tools menu, click Options.
In the Options dialog box, open the Debugging folder.
In the Debugging folder, choose the category of options you want.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
237
9.3.5.2. AVR Debugger Settings
AVR Communication Timeout
Shows the timeout delay used for communication with the back-end. If the watchdog detects that timeout
is exceeded the back-end is restarted. 20000ms by default.
AVR Debugger Path
Shows the path to the AVR Debugger.
AVR Debugger Port
Indicates the Windows Comm API Port number, used by the AVR debugger. 0 by default.
RPC transaction times
File name to put statistic logging in. This is log data from the communication with the back-end. Empty
means no logging. Note that the file must be written to a directory where the user has write permission.
E.g. C:/tmp/transactionlog.csv
User Tool polling
Use internal port polling method for hardware tool discovery, instead of relying on Windows Comm
Framework. Must restart Atmel Studio if activated, it may slow down your PC considerably, so use it only
if you have errors related to Windows Comm Framework. Disabled by default.
9.3.6. Atmel Software Framework Settings
Path of the application used to compare files
An application is normally used to compare files in the Atmel Software Framework, as such you must
specify a path here.
Command line arguments used for file comparison
Command line argument macros:
• %original - Path of the original Software Framework file.
• %mine - Path of the modified file in the local project
If the command line for the configured file compare application is FileCompare.exe filepath1
filepath2, specify %original for filepath1 and %mine for filepath2. For example, if configuring
WinMerge as the compare application, specify the following command line arguments: %original
%mine /s /u.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
238
9.3.7. Builder
Figure 9-1. Builder
ShellUtils Packages
It will list Default, Custom, and installed Shell Utility extensions.
ShellUtils Path
Based on the package selected the ShellUtils Path will point to the corresponding utilities folder. If you
select a custom ShellUtil package then you can configure a custom Shell utilities folder by clicking on ...
button. If you select default or installed shell extension package then the path will be read only and point
to the package path.
Make Configuration
You can configure the path to the Make executable by clicking on ... button by default it points to
INSTALLDIR\shellUtils\make.exe and you can enable parallel build of projects by checking the box.
9.3.8. Device and Tool Libraries
In the Devices sub-menu you can specify the path to custom libraries for your device. In the Tools submenu,
you can specify the path to custom tools for your device.
9.3.9. Status Management
Contains path to the log files and logging settings.
Location
Path to the log file. You can change it by clicking and browsing to the desired location.
Severity threshold
How severe the incident must be in order to generate a log entry. You can choose whether you want to
have an output when all operations are successful - OK level, when some unorthodox code is present -
Info level, when some operations have been canceled - Cancel setting. If you want to generate output
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
239
only in the case when the code is potentially unstable or erroneous, choose either Warning or Error
setting.
Component filter
Filter messages coming from the source code for standard or custom components in your design.
Severity threshold
Meaning identical to the Severity threshold for your source code log generation.
Use filter
Whether the logging process should use a filter to separate components output from your code output.
9.3.10. Text Templating
Show security message
Display a dialog prompting the user to ensure that the text templates are from a trusted source when a
text transformation operation is initiated.
9.3.11. Toolchain
Figure 9-2. Toolchain Flavor Configuration
Toolchain
Toolchain is used to compile, link, and transform the source code to an executable form targeting the AVR
devices. By default, AVR Studio has the following Toolchain Type extensions.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
240
Table 9-2. Toolchain Options
Toolchain type Language Description
AVR Assembler Assembly Used for building 8-Bit Assembler projects
Atmel AVR 8-bit C Used for building 8-Bit C/C++ projects
C++
Atmel AVR 32-bit C Used for building 32-Bit C/C++ projects
C++
Atmel ARM 32-bit C Used for building ARM C/C++ projects
C++
9.3.11.1. Flavor
Flavor identifies a particular version of Toolchain extension of a desired Toolchain type. You could have
different flavors of same Toolchain type extensions installed for Atmel Studio.
Add Flavor
1. Select a Toolchain type for which the new Flavor is to be added.
Figure 9-3. Add Toolchain Flavor
2. Enter a new Flavor Name.
3. Configure the Toolchain path for the Flavor. The path should contain desired Toolchain executable,
e.g. avr-gcc.exe for Atmel AVR 8-bit.
4. Click the Add button.
Set Default Flavor
1. Select a Flavor to set as default. The flavor would be the default for the selected toolchain type.
Hence, a new project using the toolchain type, would use the configured Flavor settings.
2. You can view and switch between various Flavors after creating the project through the project
properties page shown in Advanced Options.
Delete Flavor
Pressing the Delete Flavor button deletes the Flavor configuration.
Note: If the customized default flavor is deleted, then the Native flavor will be set as default. Also the
projects that were configured with the deleted flavor will be changed to the default flavor of the respective
toolchain type when the project is opened the next time.
9.3.12. GDB Settings
We can configure architecture specific GDB path in this page. This will override the default toolchain
flavor GDB path.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
241
9.4. Code Snippet Manager
Code snippets are particularly useful when writing AVR GCC applications. You can use the Code
Snippets Manager to add folders to the folder list that the Code Snippet Picker scans for XML .snippet
files. Having these building blocks of code at your disposal can facilitate project development.
The Code Snippets Manager can be accessed from the Tools menu.
9.4.1. Managing Code Snippets
To access the Code Snippets Manager
On the Tools menu, click Code Snippets Manager.
To add a directory to the Code Snippet Manager
1. In the Language: drop-down list, select the language that you want to add a directory to.
2. Click Add. This opens the Code Snippets Directory window.
3. Select the directory that you want to add to the Code Snippets Manager and click OK. The directory
will now be used to search for available code snippets.
To remove a directory from the Code Snippet Manager
1. Select the directory that you want to remove.
2. Click Remove.
To import a code snippet into the Code Snippet Manager
1. In the Language: drop-down list, select the language that you want to add the code snippet to.
2. Select the existing folder that you want to place the imported code snippet into.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
242
3. Click Import. This opens the Code Snippets Directory window.
4. Select the code snippet file that you want to add to the Code Snippets Manager and click OK. The
code snippet is now available for insertion into the code editor.
9.4.2. Code Snippet Manager Layout
Language
Selects the development language whose code snippet folders are displayed in the folder list.
Location
Displays the path to the folders in the folder list, or to the code snippet file selected there.
Folder list
Shows the set of sub-folders, if any, and the code snippet files available for the Language selected. Click
any folder to expand it and list its files.
Description
Displays information on the folder or code snippet file selected in the folder list. When a code snippet file
is selected, displays the text from its Author, Description, Shortcut, and Type fields.
Add
Opens the Code Snippet Directory dialog box. Allows you to navigate to the desired snippets folder on
your local drive or server, and include it in the folder list.
Remove
Removes a selected top-level folder and its contents from the folder list. Does not physically delete the
folder.
Import
Opens the Code Snippet Directory dialog box. Allows you to navigate to the desired snippet on your local
drive or server, and add it to an existing code snippet folder.
Security
Whenever you store a new snippet in a folder accessed by the Code Snippets Manager, you are
responsible for ensuring that its code is constructed as securely as the rest of your application. Because
using code snippets saves development time, snippets can be reused frequently as you construct
applications. You should therefore make sure that model code saved in snippets is designed to address
security issues. Development teams should establish procedures to review code snippets for compliance
with general security standards.
9.4.3. Modifying Existing Code Snippets
IntelliSense Code Snippets are XML files with a .snippet file name extension that can be easily modified
using any XML editor, including Atmel Studio.
To modify an existing IntelliSense Code Snippet
1. Use the Code Snippets Manager to locate the snippet that you want to modify.
2. Copy the path of the code snippet to the clipboard and click OK.
3. On the File menu, click Open, and click File.
4. Paste the snippet path into the File location box and click OK.
5. Modify the snippet.
6. On the File menu, click Save. You must have write access to the file to save it.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
243
9.5. External Tools
You can add items to the Tools menu that allow you to launch external tools from within Visual Studio. For
example, you can add an item to the Tools menu to launch utilities such as avrdude or a diffing tool.
9.5.1. Add an External Tool to the Tools Menu
You can add a command to the Tools menu to start another application, such as Notepad, from within the
integrated development environment (IDE).
Figure 9-4. External Tool Dialog
The dialog contains a list box where all previously defined external tools are listed. If you have not defined
any tool, the list box will be empty.
• On the Tools menu, choose External Tools
• In the External Tools dialog box, choose Add, and enter a name for the menu option in the Title box
Tip:
Type an ampersand before one of the letters in the tool name to create an accelerator key
for the command when it appears on the Tools menu. For example, if you use M&y
External Tool, the letter 'y' will be the accelerator key. See Assign a Keyboard Shortcut for
more information.
• In the Command box, enter the path to the file you intend to launch, or choose Browse (...) to
navigate to the file. Files types that you can launch include .exe, .bat, .com, .cmd, and .pif.
Note: If the file resides on the system path, you can enter just the file name. If not, enter the full
path to the file.
• Select Use output window and Close on exit, as appropriate, and then choose OK
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
244
9.5.2. Pass Variables to External Tools
You can specify that certain information be passed to a command when it is launched, such as command
line switches for console applications.
Fill in the Arguments box with the necessary launch arguments, either manually or using the auto-fill
button.
The auto-fill argument button can provide you with the macros described in the table below.
Table 9-3. External Tools Macros
Name Argument Description
Item Path $(ItemPath) The complete file name of the current source (defined as
drive + path + file name); blank if a non-source window is
active.
Item Directory $(ItemDir) The directory of the current source (defined as drive +
path); blank if a non-source window is active.
Item File Name $(ItemFilename) The file name of the current source (defined as file
name); blank if a non-source window is active.
Item Extension $(ItemExt) The file name extension of the current source.
Current Line $(CurLine) The current line position of the cursor in the editor.
Current Column $(CurCol) The current column position of the cursor in the editor.
Current Text $(CurText) The selected text.
Target Path $(TargetPath) The complete file name of the item to be built, (defined as
drive + path + file name).
Target Directory $(TargetDir) The directory of the item to be built.
Target Name $(TargetName) The file name of the item to be built.
Target Extension $(TargetExt) The file name extension of the item to be built.
Binary Directory $(BinDir) The final location of the binary that is being built (defined
as drive + path).
Project Directory $(ProjectDir) The directory of the current project (defined as drive +
path).
Project file name $(ProjectFileName) The file name of the current project (defined as drive +
path + file name).
Solution Directory $(SolutionDir) The directory of the current solution (defined as drive +
path).
Solution file name $(SolutionFileName) The file name of the current solution (defined as drive +
path + file name).
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
245
9.5.3. Initial Directory
You can also specify the working directory for the tool or command. For example, if the tool reads file
system data from the current directory, the tool requires that certain program components are present in
the current directory at start-up.
9.5.4. Run Behavior
Underneath the argument boxes you can modify the tool behavior.
Use output window - if this box is checked, the tool will output processing information to the Atmel
Studio output window, otherwise the output will be suppressed.
Close on exit - if the box is checked the tool window, if any will be automatically closed after completing
all operations.
Prompt for arguments - used for toolchain automation. If the box is checked, external tool will require
user intervention to input additional processing parameters, otherwise the tool will be silent.
Treat output as Unicode - internationalization option. Some tools have a capacity to output Unicode
results for better interpretation. This option allows for correct output rendering if you are using such a tool.
9.5.5. Assign a Keyboard Shortcut
To assign a shortcut (accelerator) to a command, add an ampersand (&) in the title of the tool, just before
the letter that you want to use as the access key.
After the ampersand has been added the accelerator needs to be included as a keyboard shortcut.
• On the Tools menu, click Options
• Select Keyboard on the Environment page
• In the Show commands containing list, type Tools
• In the Command names list, locate the appropriate External Command n entry
Note: You can define keyboard shortcuts for up to twenty external tools. External tools are listed
as External Command 1-20 in the Command names list. The numbers correspond to the number
to the left of the custom external command name on the Tools menu. If the menu command
already has a shortcut assigned to it, that information appears in the Shortcuts for selected
command list.
• Put the cursor in the Press shortcut keys box, and then press the keys you want to assign to the
external tool
Note: If the keyboard shortcut is already assigned to another command, the Shortcut currently
assigned to list will display that information.
• Click Assign
9.6. Predefined Keyboard Shortcuts
The Atmel Studio uses the Visual Studio Shell framework from Microsoft Visual Studio 2010 and therefore
the integrated development environment (IDE) includes several predefined keyboard shortcut schemes,
identical to those in the Visual Studio. When you start Atmel Studio for the first time and select your
settings, the associated schemes are automatically set. Thereafter, by using the keyboard options page in
the Options dialog box, you can choose from additional schemes and you can also create your own
keyboard shortcuts.
Designers and Editors, Shared Shortcuts
These shortcuts work in both designers and editors.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
246
Command Description General development,
web
Edit.Copy Copies the selected item to the Clipboard. CTRL+C or CTRL
+INSERT
Edit.Cut Deletes the selected item from the file and
copies it to the Clipboard.
CTRL+X or SHIFT
+DELETE
Edit.CycleClipboardRing Pastes an item from the Clipboard ring to the
cursor location in the file. To paste the next item
in the Clipboard ring instead, press the shortcut
again.
CTRL+SHIFT+V
Edit.Delete Deletes one character to the right of the cursor. DELETE
Edit.Find Displays the Quick tab of the Find and Replace
dialog box.
CTRL+F
Edit.FindAllReferences Displays the list of references for the selected
symbol.
SHIFT+ALT+F
Edit.FindinFiles Displays the In Files tab of the Find and Replace
dialog box.
CTRL+SHIFT+F
Edit.FindNext Finds the next occurrence of the search text. F3
Edit.FindNextSelected Finds the next occurrence of the currently
selected text, or the word at the cursor.
CTRL+F3
Edit.FindPrevious Finds the previous occurrence of the search text. SHIFT+F3
Edit.FindPreviousSelected Finds the previous occurrence of the currently
selected text, or the word at the cursor.
CTRL+SHIFT+F3
Edit.FindSymbol Displays the Find Symbol pane of the Find and
Replace dialog box.
ALT+F12
Edit.GoToFindCombo Puts the cursor in the Find/Command box on the
Standard toolbar.
CTRL+D
Edit.IncrementalSearch Activates incremental search. If incremental
search is on, but no input is passed, the previous
search query is used. If search input has been
found, the next invocation searches for the next
occurrence of the input text.
CTRL+I
Edit.Paste Inserts the Clipboard contents at the cursor. CTRL+V or SHIFT
+INSERT
Edit.QuickFindSymbol Searches for the selected object or member and
displays the matches in the Find Symbol Results
window.
SHIFT+ALT+F12
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
247
Command Description General development,
web
Edit.NavigateTo Displays the Navigate To dialog box. CTRL+,
Edit.Redo Repeats the most recent action. CTRL+Y or SHIFT+ALT
+BACKSPACE or CTRL
+SHIFT+Z
Edit.Replace Displays the replace options on the Quick tab of
the Find and Replace dialog box.
CTRL+H
Edit.ReplaceinFiles Displays the replace options on the In Files tab
of the Find and Replace dialog box.
CTRL+SHIFT+H
Edit.SelectAll Selects everything in the current document. CTRL+A
Edit.StopSearch Stops the current Find in Files operation. ALT+F3, S
Edit.Undo Reverses the last editing action. CTRL+Z or ALT
+BACKSPACE
View.ViewCode For the selected item, opens the corresponding
file and puts the cursor in the correct location.
CTRL+ALT+0
Text Navigation
These shortcuts are for moving around in an open document.
Command Description Shortcut
Edit.CharLeft Moves the cursor one character to the left. LEFT ARROW
Edit.CharRight Moves the cursor one character to the right. RIGHT ARROW
Edit.DocumentEnd Moves the cursor to the last line of the document. CTRL+END
Edit.DocumentStart Moves the cursor to the first line of the document. CTRL+HOME
Edit.GoTo Displays the Go To Line dialog box. CTRL+G
Edit.GoToDefinition Navigates to the declaration for the selected
symbol in code.
ALT+G
Edit.GoToNextLocation Moves the cursor to the next item, such as a task in
the Task List window or a search match in the Find
Results window. Subsequent invocations move to
the next item in the list.
F8
Edit.GoToPrevLocation Moves the cursor back to the previous item. SHIFT+F8
Edit.IncrementalSearch Starts incremental search. If incremental search is
started but you have not typed any characters,
recalls the previous pattern. If text has been found,
searches for the next occurrence.
CTRL+I
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
248
Command Description Shortcut
Edit.LineDown Moves the cursor down one line. DOWN ARROW
Edit.LineEnd Moves the cursor to the end of the current line. END
Edit.LineStart Moves the cursor to the start of the line. HOME
Edit.LineUp Moves the cursor up one line. UP ARROW
Edit.NextBookmark Moves to the next bookmark in the document. CTRL+K, CTRL
+N
Edit.NextBookmarkInFolder If the current bookmark is in a folder, moves to the
next bookmark in that folder. Bookmarks outside
the folder are skipped.
If the current bookmark is not in a folder, moves to
the next bookmark at the same level.
If the Bookmark window contains folders,
bookmarks in folders are skipped.
CTRL+SHIFT+K,
CTRL+SHIFT+N
Edit.PageDown Scrolls down one screen in the editor window. PAGE DOWN
Edit.PageUp Scrolls up one screen in the editor window. PAGE UP
Edit.PreviousBookmark Moves the cursor to the location of the previous
bookmark.
CTRL+K, CTRL
+P
Edit.PreviousBookmarkInFolder If the current bookmark is in a folder, moves to the
previous bookmark in that folder. Bookmarks
outside the folder are skipped.
If the current bookmark is not in a folder, moves to
the previous bookmark at the same level.
If the Bookmark window contains folders,
bookmarks in folders are skipped.
CTRL+SHIFT+K,
CTRL+SHIFT+P
Edit.ReverseIncrementalSearch Changes the direction of incremental search to
start at the bottom of the file and progress toward
the top.
CTRL+SHIFT+I
Edit.ScrollLineDown Scrolls text down one line. Available in text editors
only.
CTRL+DOWN
ARROW
Edit.ScrollLineUp Scrolls text up one line. Available in text editors
only.
CTRL+UP
ARROW
Edit.ViewBottom Moves to the last visible line of the active window. CTRL+PAGE
DOWN
Edit.ViewTop Moves to the first visible line of the active window. CTRL+PAGE UP
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
249
Command Description Shortcut
Edit.WordNext Moves the cursor to the right one word. CTRL+RIGHT
ARROW
Edit.WordPrevious Moves the cursor to the left one word. CTRL+LEFT
ARROW
View.NavigateBackward Moves to the previously browsed line of code. CTRL+-
View.NavigateForward Moves to the next browsed line of code. CTRL+SHIFT+-
View.NextError Moves to the next error entry in the Error List
window, which automatically scrolls to the affected
section of text in the editor.
CTRL+SHIFT
+F12
View.NextTask Moves to the next task or comment in the Task List
window.
Visual Assist shortcuts
These shortcuts are for Visual Assist.
Command Description Shortcut
VAssistX.FindReference Find all references to the marked text. SHIFT+ALT+F
VAssistX.FindSymbolDialog Opens the symbols dialog listing all symbols in
the project.
SHIFT+ALT+S
VAssistX.GotoImplementation Go to implementation. ALT+G
VAssistX.ListMethodsInCurrentFile Opens the list of all methods in the current file. ALT+M
VAssistX.OpenCorrespondingFile Opens the corresponding file (i.e. .h/.c). ALT+O
VAssistX.OpenFileInSolutionDialog Displays a list of all files in the solution. SHIFT+ALT+O
VAssistX.Paste Shows the paste history menu. CTRL+SHIFT+V
VAssistX.RefactorContextMenu Shows the refactor context menu. SHIFT+ALT+Q
VAssistX.RefactorRename Shows the rename dialog. SHIFT+ALT+R
VAssistX.ScopeNext Jump to next scope. ALT+Down Arrow
VAssitX.ScopePrevious Jump to previous scope. ALT+Up Arrow
Text Selection
These shortcuts are for selecting text in an open document.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
250
Command Description Shortcut
Edit.CharLeftExtend Moves the cursor one character to the left and
extends the current selection.
SHIFT+LEFT
ARROW
Edit.CharLeftExtendColumn Moves the cursor to the left one character,
extending the column selection.
SHIFT+ALT+LEFT
ARROW
Edit.CharRightExtend Moves the cursor one character to the right
and extends the current selection.
SHIFT+RIGHT
ARROW
Edit.CharRightExtendColumn Moves the cursor to the right one character,
extending the column selection.
SHIFT+ALT+RIGHT
ARROW
Edit.DocumentEndExtend Selects the text from the cursor to the last line
of the document.
CTRL+SHIFT+END
Edit.DocumentStartExtend Selects the text from the cursor to the first line
of the document.
CTRL+SHIFT
+HOME
Edit.LineDownExtend Extends text selection down one line, starting
at the location of the cursor.
SHIFT+DOWN
ARROW
Edit.LineDownExtendColumn Moves the pointer down one line, extending
the column selection.
SHIFT+ALT+DOWN
ARROW
Edit.LineEndExtend Selects text from the cursor to the end of the
current line.
SHIFT+END
Edit.LineEndExtendColumn Moves the cursor to the end of the line,
extending the column selection.
SHIFT+ALT+END
Edit.LineStartExtend Selects text from the cursor to the start of the
line.
SHIFT+HOME
Edit.LineStartExtendColumn Moves the cursor to the start of the line,
extending the column selection.
SHIFT+ALT+HOME
Edit.LineUpExtend Selects text up, line by line, starting from the
location of the cursor.
SHIFT+UP ARROW
Edit.LineUpExtendColumn Moves the cursor up one line, extending the
column selection.
SHIFT+ALT+UP
ARROW
Edit.PageDownExtend Extends selection down one page. SHIFT+PAGE
DOWN
Edit.PageUpExtend Extends selection up one page. SHIFT+PAGE UP
Edit.SelectCurrentWord Selects the word that contains the cursor or
the word to the right of the cursor.
CTRL+W
Edit.SelectionCancel Cancels the current selection. ESC
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
251
Command Description Shortcut
Edit.ViewBottomExtend Moves the cursor and extends the selection to
the last line in view.
CTRL+SHIFT
+PAGE DOWN
Edit.ViewTopExtend Extends the selection to the top of the active
window.
CTRL+SHIFT
+PAGE UP
Edit.WordNextExtend Extends the selection one word to the right. CTRL+SHIFT
+RIGHT ARROW
Edit.WordNextExtendColumn Moves the cursor to the right one word,
extending the column selection.
CTRL+SHIFT+ALT
+RIGHT ARROW
Edit.WordPreviousExtend Extends the selection one word to the left. CTRL+SHIFT+LEFT
ARROW
Edit.WordPreviousExtendColumn Moves the cursor to the left one word,
extending the column selection.
CTRL+SHIFT+ALT
+LEFT ARROW
Text Viewing
These shortcuts are for changing how text is displayed without changing the text itself, for example, by
hiding a selected area or by outlining methods.
Command Description Shortcut
Edit.ClearBookmarks Removes all bookmarks in all open documents. CTRL+K, CTRL+L
Edit.CollapseAllOutlining Collapses all regions on the page to show just the
outermost groups in the hierarchy; typically the
using/imports section and the namespace
definition.
CTRL+M, CTRL+A
Edit.CollapseCurrentRegion Collapses the region that contains the cursor to
show just the top line of the region, followed by an
ellipsis. Regions are indicated by triangles on the
left edge of the document window.
CTRL+M, CTRL+S
Edit.CollapseTag Hides the selected HTML tag and displays an
ellipsis (. . .) instead. You can view the complete
tag as a tooltip by putting the mouse pointer over
the ellipsis.
CTRL+M, CTRL+T
Edit.CollapsetoDefinitions Collapses existing regions to provide a high-level
view of the types and members in the source file.
CTRL+M, CTRL+O
Edit.EnableBookmark Enables bookmark usage in current document.
Edit.ExpandAllOutlining Expands all collapsed regions on the page. CTRL+M, CTRL+X
Edit.ExpandCurrentRegion Expands the current region. Put the cursor on a
collapsed region to use this command.
CTRL+M, CTRL+E
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
252
Command Description Shortcut
Edit.HideSelection Hides the selected text. A signal icon marks the
location of the hidden text in the file.
CTRL+M, CTRL+H
Edit.StopHidingCurrent Removes the outlining information for the currently
selected region.
CTRL+M, CTRL+U
Edit.StopOutlining Removes all outlining information from the whole
document.
CTRL+M, CTRL+P
Edit.ToggleAllOutlining Toggles all previously collapsed outlining regions
between collapsed and expanded states.
CTRL+M, CTRL+L
Edit.ToggleBookmark Sets or removes a bookmark at the current line. CTRL+K, CTRL+K
Edit.ToggleOutliningExpansion Toggles the currently selected collapsed region
between the collapsed and expanded state.
CTRL+M, CTRL+M
Edit.ToggleTaskListShortcut Sets or removes a shortcut at the current line. CTRL+K, CTRL+H
Edit.ToggleWordWrap Enables or disables word-wrap in an editor. CTRL+E, CTRL+W
Edit.ViewWhiteSpace Shows or hides spaces and tab marks. CTRL+R, CTRL+W
Text Manipulation
These shortcuts are for deleting, moving, or formatting text in an open document.
Command Description Shortcut
Edit.BreakLine Inserts a new line. ENTER
Edit.CharTranspose Swaps the characters on either side of the
cursor. For example, AC|BD becomes AB|CD.
CTRL+T
Edit.CommentSelection Applies comment characters for the current
language to the current selection.
CTRL+K, CTRL+C
Edit.CompleteWord Completes the current word in the completion
list.
ALT+RIGHT ARROW or
CTRL+SPACEBAR
Edit.DeleteBackwards Deletes one character to the left of the cursor. BACKSPACE
Edit.FormatDocument Formats the current document according to the
indentation and code formatting settings
specified on the Formatting pane in the Options
dialog box, for the current language.
CTRL+K, CTRL+D
Edit.FormatSelection Formats the current selection according to the
indentation and code formatting settings
specified on the Formatting pane in the Options
dialog box, for the current language.
CTRL+K, CTRL+F
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
253
Command Description Shortcut
Edit.InsertSnippet Displays the Code Snippet Picker. The selected
code snippet will be inserted at the cursor
position.
CTRL+K, CTRL+X
Edit.InsertTab Indents the line of text a specified number of
spaces.
TAB
Edit.LineCut Cuts all selected lines, or the current line if
nothing has been selected, to the Clipboard.
CTRL+L
Edit.LineDelete Deletes all selected lines, or the current line if no
selection has been made.
CTRL+SHIFT+L
Edit.LineOpenAbove Inserts a blank line above the cursor. CTRL+SHIFT+ENTER
Edit.LineOpenBelow Inserts a blank line below the cursor. CTRL+ENTER
Edit.LineTranspose Moves the line that contains the cursor below the
next line.
SHIFT+ALT+T
Edit.ListMembers Invokes the IntelliSense completion list. CTRL+J
Edit.MakeLowercase Changes the selected text to lowercase
characters.
CTRL+U
Edit.MakeUppercase Changes the selected text to uppercase
characters.
CTRL+SHIFT+U
Edit.OvertypeMode Toggles between insert and over-type insertion
modes.
INSERT
Edit.ParameterInfo Displays the name, number, and type of
parameters required for the specified method.
CTRL+SHIFT
+SPACEBAR
Edit.SurroundWith Displays the Code Snippet Picker. The selected
code snippet will be wrapped around the
selected text.
CTRL+K, CTRL+S
Edit.TabifySelectedLines Replaces spaces with tabs in the selected text.
Edit.TabLeft Moves selected lines to the left one tab stop. SHIFT+TAB
Edit.UncommentSelection Removes the comment syntax from the current
line of code.
CTRL+K, CTRL+U
Edit.UntabifySelectedLines Replaces tabs with spaces in selected text.
Edit.WordDeleteToEnd Deletes the word to the right of the cursor. CTRL+DELETE
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
254
Command Description Shortcut
Edit.WordDeleteToStart Deletes the word to the left of the cursor. CTRL+BACKSPACE
Edit.WordTranspose Transposes the words on either side of the
cursor. For example, |End Sub would be changed
to read Sub End|.
CTRL+SHIFT+T
File and Project Operations
These shortcuts are for file and project operations, and can be used anywhere in the IDE.
Command Description Shortcut
Build.BuildSelection Builds the selected project and its dependencies.
Build.BuildSolution Builds all the projects in the solution. F7
Build.Cancel Stops the current build. CTRL+BREAK
Build.Compile Creates an object file that contains machine code, linker
directives, sections, external references, and function/
data names for the selected file.
CTRL+F7
Build.RebuildSolution Rebuilds the solution. CTRL+ALT+F7
File.NewFile Displays the New File dialog box so that you can add a
new file to the current project.
CTRL+N
File.NewProject Displays the New Project dialog box. CTRL+SHIFT+N
File.OpenFile Displays the Open File dialog box. CTRL+O
File.OpenProject Displays the Open Project dialog box so that you can add
existing projects to your solution.
CTRL+SHIFT+O
File.Print Displays the Print dialog box so that you can select printer
settings.
CTRL+P
File.Rename Lets you modify the name of the item selected in Solution
Explorer.
F2
File.SaveAll Saves all documents in the current solution and all files in
the external files project.
CTRL+SHIFT+S
File.SaveSelectedItems Saves the selected items in the current project. CTRL+S
File.SaveSelectedItemsAs Displays the Save File As dialog box when items are
selected in the editor.
Project.AddExistingItem Displays the Add Existing Item dialog box, which lets you
add an existing file to the current project.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
255
Command Description Shortcut
Project.AddNewItem Displays the Add New Item dialog box, which lets you add
a new file to the current project.
Project.Properties Displays the Project Properties dialog box for the current
project in the editing frame.
Window Management
These shortcuts are for moving, closing, or navigating in tool windows and document windows.
Command Description Shortcut
View.FullScreen Toggles Full Screen mode ON and OFF. SHIFT+ALT
+ENTER
Window.ActivateDocumentWindow Closes a menu or dialog box, cancels an
operation in progress, or puts focus in the
current document window.
ESC
Window.CloseDocumentWindow Closes the current tab. CTRL+F4
Window.CloseToolWindow Closes the current tool window. SHIFT+ESC
Window.Dock Returns a floating tool or document window
to its most recent docked location in the
IDE.
Window.NextDocumentWindow Cycles through the open documents. CTRL+F6
Window.NextDocumentWindowNav Displays the IDE Navigator, with the first
document window selected.
CTRL+TAB
Window.NextPane Moves to the next pane of the current tool
or document window.
ALT+F6
Window.NextToolWindow Moves to the next tool window.
Window.NextToolWindowNav Displays the IDE Navigator, with the first
tool window selected.
ALT+F7
Window.PreviousDocumentWindow Moves to the previous document in the
editor.
CTRL+SHIFT+F6
Window.PreviousDocumentWindowNav Displays the IDE Navigator, with the
previous document window selected.
CTRL+SHIFT
+TAB
Window.PreviousPane Moves to the previously selected window. SHIFT+ALT+F6
Window.ShowEzMDIFileList Displays a pop-up listing all open
documents only.
CTRL+ALT
+DOWN ARROW
Tool Windows
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
256
These shortcuts are for opening tool windows anywhere in the IDE.
Command Description Shortcut
Tools.CodeSnippetsManager Displays the Code Snippets Manager, which lets
you search for and insert code snippets in files.
CTRL+K, CTRL+B
Tools.GoToCommandLine Puts the pointer in the Find/Command box on
the Standard toolbar.
CTRL+/
View.BookmarkWindow Displays the Bookmark window. CTRL+K, CTRL+W
View.CallHierarchy Displays the Call Hierarchy window. CTRL+ALT+K
View.CommandWindow Displays the Command window, where
commands can be invoked to make changes to
the IDE.
CTRL+ALT+A
View.EditLabel Lets you change the name of the selected item
in Solution Explorer.
F2
View.ErrorList Displays the Error List window. CTRL+\, E
View.FindSymbolResults Displays the Find Symbol Results window. CTRL+ALT+F12
View.Output Displays the Output window to view status
messages at run time.
CTRL+ALT+O
View.SolutionExplorer Displays Solution Explorer, which lists the
projects and files in the current solution.
CTRL+ALT+L
View.TaskList Displays the Task List window, which displays
custom tasks, comments, shortcuts, warnings,
and error messages.
CTRL+\, T
View.WebBrowser Displays the Web Browser window, which lets
you view pages on the Internet.
CTRL+ALT+R
Window.PreviousToolWindow Brings focus to the previous tool-window.
Window.PreviousToolWindowNav Displays the IDE Navigator, with the previous
tool window selected.
SHIFT+ALT+F7
Bookmark Window
These shortcuts are for working with bookmarks, either in the Bookmarks window or in the editor. For
more information, see .
Command Description Shortcut
Edit.ClearBookmarks Removes all bookmarks in all open documents. CTRL+K, CTRL+L
Edit.EnableBookmark Enables bookmark usage in current document.
Edit.NextBookmark Moves to the next bookmark in the document. CTRL+K, CTRL+N
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
257
Command Description Shortcut
Edit.NextBookmarkInFolder If the current bookmark is in a folder, moves to the
next bookmark in that folder. Bookmarks outside
the folder are skipped.
If the current bookmark is not in a folder, moves to
the next bookmark at the same level.
If the Bookmark window contains folders,
bookmarks in folders are skipped.
CTRL+SHIFT+K,
CTRL+SHIFT+N
Edit.ToggleBoomark Toggles a bookmark on the current line in the
document.
CTRL+K, CTRL+K
View.BookmarkWindow Displays the Bookmark window. CTRL+K, CTRL
+W
Edit.PreviousBookmark Moves the cursor to the location of the previous
bookmark.
CTRL+K, CTRL+P
Edit.PreviousBookmarkInFolder If the current bookmark is in a folder, moves to the
previous bookmark in that folder. Bookmarks
outside the folder are skipped.
If the current bookmark is not in a folder, moves to
the previous bookmark at the same level.
If the Bookmark window contains folders,
bookmarks in folders are skipped.
CTRL+SHIFT+K,
CTRL+SHIFT+P
Debugging
These shortcuts are for debugging code.
Command Description Shortcut
Debug.Autos Displays the Auto window, which displays
variables used in the current line of code and the
previous line of code.
CTRL+ALT+V, A
Debug.BreakAll Temporarily stops execution of all processes in a
debugging session. Available only in Run mode.
CTRL+F5
Debug.BreakatFunction Displays the New Breakpoint dialog box. CTRL+B
Debug.Breakpoints Displays the Breakpoints dialog box, where you
can add, remove, and modify breakpoints.
ALT+F9 or CTRL
+ALT+B
Debug.CallStack Displays the Call Stack window, which displays a
list of all active methods or stack frames for the
current thread of execution.
ALT+7 or CTRL
+ALT+C
Debug.DeleteAllBreakpoints Clears all the breakpoints in the project. CTRL+SHIFT+F9
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
258
Command Description Shortcut
Debug.Disassembly Displays the Disassembly window. CTRL+ALT+D or
ALT+8
Debug.EnableBreakpoint Toggles the breakpoint between disabled and
enabled.
CTRL+F9
Debug.Exceptions Displays the Exceptions dialog box. CTRL+ALT+E
Debug.Immediate Displays the Immediate window, where
expressions can be evaluated.
CTRL+ALT+I
Debug.Locals Displays the Locals window, which displays the
local variables and their values for each method in
the current stack frame.
ALT+4 or CTRL
+ALT+V, L
Debug.Memory1 Displays the Memory 1 window to view large
buffers, strings, and other data that do not display
clearly in the Watch or Variables windows.
CTRL+ALT+M, 1
Debug.Memory2 Displays the Memory 2 window to view large
buffers, strings, and other data that do not display
clearly in the Watch or Variables windows.
CTRL+ALT+M, 2
Debug.Memory3 Displays the Memory 3 window to view large
buffers, strings, and other data that do not display
clearly in the Watch or Variables windows.
CTRL+ALT+M, 3
Debug.Memory4 Displays the Memory 4 window to view large
buffers, strings, and other data that do not display
clearly in the Watch or Variables windows.
CTRL+ALT+M, 4
Debug.Modules Displays the Modules window, which lets you view
the .dll or .exe files that are used by the program.
In multiprocess debugging, you can right-click and
then click Show Modules for all Programs.
CTRL+ALT+U
Debug.ParallelStacks Opens the Parallel Stacks window. CTRL+SHIFT+D,
S
Debug.ParallelTasks Opens the Parallel Tasks window. CTRL+SHIFT+D,
K
Debug.Processes Displays the Processes window. Available in Run
mode.
CTRL+ALT+Z
Debug.QuickWatch Displays the QuickWatch dialog box that has the
current value of the selected expression. Available
only in Break mode. Use this command to
examine the current value of a variable, property,
or other expression for which you have not defined
a watch expression.
CTRL+ALT+Q or
SHIFT+F9
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
259
Command Description Shortcut
Debug.Registers Displays the Registers window, which displays
registers content for debugging native code
applications.
ALT+5 or CTRL
+ALT+G
Debug.RunToCursor In Break mode, resumes execution of your code
from the current statement to the selected
statement. The Current Line of Execution margin
indicator appears in the Margin Indicator bar. In
Design mode, starts the debugger and executes
your code to the pointer location.
CTRL+F10
Debug.Start Launches the application under the debugger
based off of the settings from the start-up project.
When in Break mode, invoking this command will
run the application until the next breakpoint.
F5
Debug.StepInto Executes code one statement at a time, following
execution into method calls.
F11
Debug.StepIntoCurrentProcess Available from the Processes window. CTRL+ALT+F11
Debug.StepOver Sets the execution point to the line of code you
select.
F10
Debug.StopDebugging Stops running the current application under the
debugger.
CTRL+SHIFT+F5
Debug.Threads Displays the Threads window to view the running
threads.
CTRL+ALT+H
Debug.ToggleBreakpoint Sets or removes a breakpoint at the current line. F9
Debug.Watch1 Displays the Watch window, which displays the
values of selected variables or watch expressions.
CTRL+ALT+W, 1
Debug.Watch2 Displays the Watch2 window to view the values of
selected variables or watch expressions.
CTRL+ALT+W, 2
Debug.Watch3 Displays the Watch3 window to view the values of
selected variables or watch expressions.
CTRL+ALT+W, 3
Debug.Watch4 Displays the Watch4 window to view the values of
selected variables or watch expressions.
CTRL+ALT+W, 4
Help
These shortcuts are for viewing topics in Help and moving among them.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
260
Command Description Shortcut
Help.F1Help Displays a topic from Help that corresponds to the user
interface that has focus.
F1
Help.ManageHelpSettings Displays the Help Library Manager. CTRL+ALT+F1
Help.WindowHelp Displays a topic from Help that corresponds to the user
interface that has focus.
SHIFT+F1
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
261
10. Command Line Utility (CLI)
Atmel Studio comes with a command line software utility called atprogram.exe.
Tip:
You can start a command shell with the PATH set up to run atprogram by clicking on Start > All
Programs > Atmel AVR Tools > Atmel Studio 6.2 Command Prompt as shown in the figure
below.
atprogram.exe can be used to:
• Program a .bin .hex or .elf file to a device
• Verify that the programming was correct
• Read, write, and erase the device memories
• Program fuses, lock bits, security bits, user page, and user signature
• Program a production file to a device 6
• List out all connected tools
• Set interface and interface clock speeds
To get help on how to use the utility, execute: atprogram.exe.
This will print out the atprogram CLI help text on stdout.
6 The ELF production file format can hold the contents of both Flash, EEPROM and User Signatures
(XMEGA devices only) as well as the Fuse- LockBit configuration in one single file. The format is
based on the Executable and Linkable Format (ELF).
The production file format is currently supported for tinyAVR, megaAVR, and XMEGA. See Creating
ELF Files with Other Memory Types for description on how to configure the project in order to
generate such files.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
262
11. Frequently Asked Questions
Frequently asked questions about Atmel Studio.
What is the Atmel USB
Driver?
The Atmel USB Driver is a cumulative installer that bundles the Jungo
USB driver for the AVR tools and the Segger USB Driver for SAM tools.
I get an error during
installation of the Atmel
USB Driver Package.
During installation of the Atmel USB Driver Package, you might get the
error 0x800b010a - A certificate chain could not be built to a trusted root
authority. This means that the certificate that signs the installer could not
be validated using the certificate authority built in to Windows.
The reason for not being able to validate the certificate is because the
certificate chain needs to be updated through Windows Update. Make
sure that you have received all updates, so that Windows is able to
validate the certificate.
If you are not able to update your computer due to the computer being
offline or restricted in some way, then the root certificate update can be
downloaded from http://support2.microsoft.com/kb/931125.
Will Atmel Studio work in
parallel with older versions
of Atmel Studio, AVR
Studio, and AVR32 Studio?
Yes, it will work side by side between major and minor versions. Side by
side installation with different build numbers are not possible. If you are
uninstalling AVR Studio 4.0 or AVR32 Studio be careful when you
manually delete folders or registry entries after uninstall, as there might
be other keys and folders deployed by Atmel Studio inside the Atmel
folder and registry paths. Note that drivers may be incompatible
between versions.
I have AVR Studio 4 in my
PC. When installing Atmel
Studio it updated the Jungo
USB driver. Will AVR Studio
4 still work?
Yes, it will work. If Jungo driver is already present and its version is
anything less than the new one, then the installer will update the Jungo
driver you already have. The newest Jungo USB driver (version 12)
breaks compatibility with older versions. See KB: Downgrading tools for
how to switch between Jungo versions.
Atmel Studio cannot find
any debuggers or
programmers when Norton
AntiVirus is running.
Atmel Studio might not show any connected tools if Norton AntiVirus is
running. To make it work make sure Norton AntiVirus allows
atprogram.exe to communicate with Atmel Studio by adding
atbackend.exe as an exception in the Norton AntiVirus allowed
programs. This is the same with any anti-virus program that by default
blocks ports.
Windows shows a message
box with the following
message when attempting
to run Atmel Studio
installer: "Windows cannot
access the specified device,
path or file. You may not
have the appropriate
permissions to access the
item. "
This might be caused by an anti-virus program blocking the installation
of the Atmel Studio. We have seen this with the Sophos antivirus
package. Temporarily disable the Sophos service running on the
machine (or any corresponding anti-virus service), and attempt
installation.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
263
Atmel Studio takes a very
long time to start, but runs
well in a VM environment.
The Visual Studio shell (and thus Atmel Studio) does a considerable
amount of processing during start-up. Parts of the operations are WPF
operations which benefits greatly by updated graphics libraries and
drivers. Installing the latest graphics driver may give a performance
boost both during normal operation and during start-up.
Verification and
programming often fails
with a serial port buffer
overrun error message
when using STK500.
This is a known issue. Due to DPC latency, serial communication can
have buffer overruns on the UART chipset. A workaround which works
for most systems is to use an USB to serial adapter.
When launching from a
guest account, the following
error is displayed when
starting Atmel Studio:
"Exception has been thrown
by the target of an
invocation".
Atmel Studio neither installs under guest account and nor runs under it.
Can install and run Atmel
Studio from within a Virtual
Machine.
Yes, with simulator there should be no issues. However with physical
devices like debuggers and programmers, the VM must offer support for
physical USB and Serial port connections.
How can I reduce the startup
time of Atmel Studio?
• Make sure you have uninstalled unwanted extensions
• Disable Allow Add-in components to load:
2.1. Go to Tools, Options, Add-in/Macro Security.
2.2. Then uncheck the Allow Add-in components to load
option.
• Disable the start-up page:
3.1. Go to Tools, Options, Environment, Startup, At Startup.
3.2. Select the Show empty environment option.
How to improve studio
performance for any
supported version of
Windows?
• Make sure your system has the latest version of the Windows
Automation API
• Exclude the following directories and files from your antivirus
scanner:
– The Atmel Studio installation directory, and all files and
folders inside it
– %AppData%\Roaming\Atmel directory, and all files and
folders inside it
– %AppData%\Local\Atmel directory, and all files and folders
inside it
– Your project directories
• Visual Studio Shell requires a lot of swap space. Increase the
paging file. Also put the system to maximize performance. Both
options are found in the System, Properties, Performance,
Settings menu.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
264
Should I install the latest
Windows Automation API
3.0?
Yes, if your OS is any of the following:
• Windows Server 2008
How can I make sure my
system has the latest
Windows Automation API
3.0?
Your system has the latest Windows Automation API if you have
Windows 7 or Windows 8. Only Windows XP, Windows Vista,
Windows Server 2003, and Windows Server 2008 have the old version
of the API. Find the UIAutomationCore.dll file in your system (normally
found in the windows folder) and compare the version number of that
file. The version should be 7.X.X.X. for the new API. The latest API can
be found at http://support.microsoft.com/kb/971513.
My Project is large and it
takes a long time to open. Is
there any option to avoid
this delay?
Visual Assist X parses all the files when we opening the existing project.
You could disable this option:
1. Go to VAssistX, Visual Assist X Options, Performance.
2. Uncheck the Parse all files when opening the project.
I have the limited RAM size
in my system and I work
long hours in the same
instance of Atmel Studio.
After some time, Atmel
Studio becomes slow on my
system.
Press Ctrl+Shift+Alt+F12 twice to force Atmel Studio to garbage collect.
Does Atmel Studio perform
better on multi-core
processors than on singlecore
systems?
Yes, Atmel Studio performs better on a multi-core system.
How can I make my projects
build faster?
You can enable parallel build Option from Tools, Options, Builder, GNU
Make, Make Parallel Execution Of Build. This option will enable the
parallel execution feature in the GNU make utility. This option may
cause the build log to be displayed unordered.
11.1. Compatibility with Legacy AVR Software and Third-party Products
11.1.1. How do I Import External ELF Files for Debugging?
Use the File → Open object file for debugging.
11.1.2. How do I Reuse My AVR Studio 4 Projects with the New Atmel Studio?
1. Click the menu File→Import AVR Studio 4 project.
2. An "Import AVR Studio 4 Project" dialog will appear.
3. Type in the name of your project or browse to the project location by clicking the Browse button of
the APFS File location Tab.
4. Name the new solution resulting from the conversion of your project in the Solution Folder Tab.
5. Click Next.
6. Atmel Studio will proceed with conversion. Depending on the complexity and specificity of your
project there might be some warnings and errors. They will be shown in the Summary window.
7. Click Finish to access your newly converted project.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
265
11.2. Atmel Studio Interface
11.2.1. How can I Start Debugging My Code? What is the Keyboard Shortcut for Debugging?
Unlike the AVR Studio 4 to build your project, without starting debugging, you should press F7.
If you need to rebuild your project after a change to the source files, press Ctrl Alt F7 .
To Start debugging - press F5.
To open the Debugging Interface without running directly, press the Debug→Start Debugging and
Break menu button, or press F11.
To start a line-by-line debugging press F10, to start an instruction by instruction debugging session -
press F11.
To run your project without debugging, press the Debug→Start Without Debugging menu button.
11.2.2. What is a Solution?
A solution is a structure for organizing projects in Atmel Studio. The solution maintains the state
information for projects in .sln (text-based, shared) and .suo (binary, user-specific solution options) files.
11.2.3. What is a Project
A project is a logic folder that contains references to all the source files contained in your project, all the
included libraries and all the built executables. Projects allow seamless reuse of code and easy
automation of the build process for complex applications.
11.2.4. How can I use an External Makefile for my Project?
The usage of external makefiles and other project options can be configured in the project properties.
Remember that an external makefile has to contain the rules needed by Atmel Studio to work.
11.2.5. When Watching a Variable, the Debugger says Optimized away
Most compilers today are what is known as an optimizing compiler. This means that the compiler will
employ a number of tricks to reduce the size of your program, or speed it up.
Note: This behavior is usually controlled by the -On switches.
The cause of this error is usually trying to debug parts of code that does nothing. Trying to watch the
variable a in the following example may cause this behavior.
int main() {
int a = 0;
while (a < 42) {
a += 2;
}
}
The reason for a to be optimized away is obvious as the incrementation of a does not affect any other
part of our code. This example of a busy wait loop is a prime example of unexpected behavior if you are
unaware of this fact.
To fix this, either lower the optimization level used during compilation, or preferably declare a as
volatile. Other situations where a variable should be declared volatile is if some variable is shared
between the code and a ISR7
.
For a thorough walk through of this issue, have a look at Cliff Lawsons excellent tutorial on this issue.
7
Interrupt Service Routine
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
266
11.2.6. When Starting a Debug Session, I get an Error Stating that Debug Tool is not Set
The reason for this message is that there are no tool capable to debug that are selected for your project.
Go to the Tool project pane and change the to a supported tool.
If the tool you have selected does support debug, then check that the correct interface is chosen and that
the frequency is according to the specification. If the issue persist, try to lower the frequency to a
frequency where programming is stable, and then slowly increase the frequency as long as it keeps
stable.
11.3. Performance Issues
11.3.1. Atmel Studio Takes a Very Long Time to Start on My PC, but Runs Well in a VM Environment. Is
there Something I Can do With This?
Visual Studio shell (and thus Atmel Studio) uses WPF as a graphics library and does a lot of processing
in the GUI thread. WPF has support for hardware acceleration. Some graphics card drivers does not
utilize this well and spend time in kernel space even when no graphics update is required. Installing the
latest graphics driver may give a performance boost.
11.3.2. Verification and Programming often Fails with a Serial Port Buffer Overrun Error Message when
using STK500
This is a known issue. Interrupt DPC latency for serial communication may be disrupted by other drivers,
thus causing buffer overruns on the UART chipset. A workaround which works for most systems is to use
a USB to serial adapter.
11.3.3. I've connected my Tool through a USB Hub, and now I get Error Messages and Inconsistent
Results while Programming and Debugging
Tools and devices should be connected directly to an USB port on your debugging PC. If this is not an
option, you may reduce/eliminate problems by:
• Disconnect any other USB devices connected to the hub
• Switch ports on the USB hub
• Set the tool clock frequency low. E.g. Set JTAG Clock < 600kHz.
• If Use external reset is an option for your tool/device combination, enable this
Note: The AVR Dragon should be connected through a powered USB hub. This because the power
supply on the Dragon can be too weak if the motherboard does not provided enough power. If the Dragon
times out or freezes, then the hub might be of to low quality.
11.4. Driver and USB Issues
11.4.1. How do I get my Tool to be Recognized by Atmel Studio?
This should happen automatically, but sometimes the Windows driver does not recognize the tool
correctly. To correct this, you have to check that the tool is listed under the Jungo item in the device
manager in Windows. If your tool is not listed, try to find it under Unknown devices. If it is located there,
try to reinstall the driver by double clicking the tool, click the Driver tab and choose Update Driver. Let
Windows search for the driver. The driver should be reinstalled and the tool should be displayed under
Jungo. Now, the tool should be usable from Atmel Studio.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
267
11.4.2. The Firmware upgrade Process fails or is Unstable on a Virtualized Machine
Most tools will perform a reset when asked to switch from normal operation mode to firmware upgrade
mode. This forces the tool to re-enumerate on the USB bus, and the virtualization software may not
reattach to it making your virtualized system with a disconnected tool.
Normal virtualization software supports the idea of USB filters where you set a collection of USB devices
you want to automatically attach to a given guest operating system. Check the manual for your
virtualization solution to see how this is done, or see the Firmware Upgrade Fails on VirtualBox.
11.4.3. Debugging never Breaks under a Virtualized Machine
Some virtualization solutions have a limit on how many USB endpoints it supports. This may become an
issue if the number of endpoints is lower than the required number for the tool. Usually this causes
programming to work as expected but debug not to work as debug events are transmitted on a higher
endpoint number.
Check with your virtualization software how many endpoints are available, and on other endpoint specific
issues with your virtualization software regarding this.
11.4.4. No Tool is recognized by Atmel Studio, but the Driver seems to be Working
On some systems the Jungo driver is known not to activate properly. This can be seen as the WinDriver
unit under Jungo in the device manager in Windows is missing. To remedy this, try the following:
1. In your Device Manager, right click on your computer name (the very top item) and choose Add
Legacy Hardware.
2. Click next, and choose to install the hardware manually.
3. Choose the Show All Devices item on the top of the list, and click next.
4. Click the Have Disk button.
5. Navigate to the folder Atmel USB which is located under the install directory for Atmel Studio
(typical location is C:\Program Files (x86)\Atmel\Atmel USB.
6. Choose the usb32 or usb64 folder depending on the architecture you are running.
7. Inside there should be only one file named windrvr#.inf, where the hash is the revision number for
the driver. Double click this, click OK, and the WinDriver should appear in the list. If you get an error
message, you probably have chosen the wrong architecture.
8. Click Next until finished.
9. Verify that the WinDriver has appeared under Jungo.
The tools should be working straight away, but you may have to restart your machine if you are still
having problems.
11.4.5. Firmware Upgrade Fails on VirtualBox
When doing a firmware upgrade on any tool, the tool needs to be reconnected in another mode than the
one used during regular operation. This causes the tool to be re-enumerated, and can cause the tool to
be disconnected from the VirtualBox instance and returned to the host operating system.
To make the tool connect automatically to the VirtualBox instance, you need to set up a couple of USB
filters. More information on USB filters can be found in the VirtualBox documentation.
Make two filters that are similar to the two shown in the figure below.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
268
Figure 11-1. VirtualBox USB Filter
Note that the example in the figure above is specific for the JTAGICE mkII. There are one entry for the
tool, here the JTAGICE mkII, and one for AVRBLDR, which is the firmware upgrade mode for the tool.
The name, serial, Vendor ID, and Product ID may be different for your tool, so change those values
accordingly.
Note: This section contains specifics to VirtualBox. The same logic applies to other virtualization
software, but the steps may differ.
11.4.6. Common Jungo USB Errors
Jungo is the driver stack that is used for older programmers and debuggers, up to the JTAGICE3.
Common Jungo USB Error Codes
Table 11-1. Common Jungo USB Errors
Error Cause Resolution
Internal system error USB subsystem malfunctions Reinstall driver and check Driver and USB
Issues page
Conflict between read
and write operations
Directional error in data Disconnect and reconnect the tool
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
269
Error Cause Resolution
Data mismatch Expected and received/sent data
error
Make sure that you use the latest driver for
your USB controller and the latest firmware
for your tool Packet size is zero Sent or received a zero packet
Insufficient resources Unable to set up send/receive
buffers due to memory limitation
Free more memory or try to restart your
machine
USB descriptor error
Error in control data on USB bus Try connection tool to another USB port
Wrong unique ID
Device not found
Wrong unique ID
Timeout expired
Error Cause Resolution
11.4.7. Issues with ARM Compatible Tools
In some rare instances all ARM compatible tools disappears from Atmel Studio. This has been tracked
down to different dll load strategies used in different versions of Windows.
To check that it is a dll load error, try to read out the chip information using atprogram. This can be done
by opening the Atmel Studio command prompt from the Tools menu inside Atmel Studio or from the start
menu. In the command prompt, enter the following command and check that it does not fail.
atprogram -t -i -d info
In the snippet above, replace with the tool name, e.g. atmelice, samice, or edbg. Likewise,
replace interface with the used interface and the device with the full device name, e.g. atsam3s4c.
Invoking the above command should output information about the memory layout, the supply voltage for
the chip, and the fuse settings. If it fails it is likely a driver issue, which is covered by Driver and USB
Issues.
If atprogram is able to communicate with the device it means that the issue is most likely a wrong
version of JLinkArm.dll being loaded due to loader precedence. To check this, use the Procmon tool
to check what dll is being loaded.
Download the Procmon tool, open it, and configure the filter shown in the figure below. Then start Atmel
Studio. A couple of seconds after Atmel Studio has started, one line should become visible showing the
path to where the dll is being loaded from. It should be loaded from the atbackend folder inside the
Atmel Studio installation directory.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
270
Figure 11-2. Procmon Filter Configuration
If the path of the dll is different it means that Atmel Studio has picked up the wrong dll, and this dll is
incompatible with the dll shipped with Atmel Studio. An example of this is shown in the figure below.
Figure 11-3. Procmon Filter Configuration
To solve the above issue, we recommend backing up the dll that is being loaded and then replacing it with
the JLinkARM.dll found in the atbackend directory inside the Atmel Studio installation directory. This
can be done given the assumption that the dll bundled with Atmel Studio is newer than the one that is
being loaded, and the dll is backwards compatible.
Note: Remember to back up the offending JLinkARM.dll before replacing it, as it is not given that it
will be compatible with the program that deployed it.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
271
12. Document Revision History
Doc Rev. Date Comments
42167B 09/2016 Section "Power Debugger" is added
42167A 07/2016 Initial document release.
Atmel Atmel Studio [USER GUIDE]
Atmel-42167B-Atmel-Studio_User Guide-09/2016
272
Index
A
AsmToolchainOptions 3, 60
Atmel Studio 1
AVR Studio 1
C
Choose file 201
D
Device selection 26, 33
T
ToolchainOptions 5, 163, 173
Atmel Corporation 1600 Technology Drive, San Jose, CA 95110 USA T: (+1)(408) 441.0311 F: (+1)(408) 436.4200 | www.atmel.com
© 2016 Atmel Corporation. / Rev.: Atmel-42167B-Atmel-Studio_User Guide-09/2016
Atmel®
, Atmel logo and combinations thereof, Enabling Unlimited Possibilities®
, AVR®
, megaAVR®
, STK®
, tinyAVR®
, XMEGA®
, and others are registered trademarks
or trademarks of Atmel Corporation in U.S. and other countries. ARM®
, ARM Connected®
logo, Cortex®
, and others are the registered trademarks or trademarks of
ARM Ltd. Windows®
is a registered trademark of Microsoft Corporation in U.S. and or other countries. Other terms and product names may be trademarks of others.
DISCLAIMER: The information in this document is provided in connection with Atmel products. No license, express or implied, by estoppel or otherwise, to any
intellectual property right is granted by this document or in connection with the sale of Atmel products. EXCEPT AS SET FORTH IN THE ATMEL TERMS AND
CONDITIONS OF SALES LOCATED ON THE ATMEL WEBSITE, ATMEL ASSUMES NO LIABILITY WHATSOEVER AND DISCLAIMS ANY EXPRESS, IMPLIED
OR STATUTORY WARRANTY RELATING TO ITS PRODUCTS INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTY OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. IN NO EVENT SHALL ATMEL BE LIABLE FOR ANY DIRECT, INDIRECT,
CONSEQUENTIAL, PUNITIVE, SPECIAL OR INCIDENTAL DAMAGES (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS AND PROFITS, BUSINESS
INTERRUPTION, OR LOSS OF INFORMATION) ARISING OUT OF THE USE OR INABILITY TO USE THIS DOCUMENT, EVEN IF ATMEL HAS BEEN ADVISED
OF THE POSSIBILITY OF SUCH DAMAGES. Atmel makes no representations or warranties with respect to the accuracy or completeness of the contents of this
document and reserves the right to make changes to specifications and products descriptions at any time without notice. Atmel does not make any commitment to
update the information contained herein. Unless specifically provided otherwise, Atmel products are not suitable for, and shall not be used in, automotive
applications. Atmel products are not intended, authorized, or warranted for use as components in applications intended to support or sustain life.
SAFETY-CRITICAL, MILITARY, AND AUTOMOTIVE APPLICATIONS DISCLAIMER: Atmel products are not designed for and will not be used in connection with any
applications where the failure of such products would reasonably be expected to result in significant personal injury or death (“Safety-Critical Applications”) without
an Atmel officer's specific written consent. Safety-Critical Applications include, without limitation, life support devices and systems, equipment or systems for the
operation of nuclear facilities and weapons systems. Atmel products are not designed nor intended for use in military or aerospace applications or environments
unless specifically designated by Atmel as military-grade. Atmel products are not designed nor intended for use in automotive applications unless specifically
designated by Atmel as automotive-grade.
Atmel-8291C-AVR-XMEGA B -09/2014
This document contains complete and detailed description of all modules included in the
Atmel®AVR®XMEGA® B microcontroller family. The Atmel AVR XMEGA B is a family of lowpower,
high-performance, and peripheral-rich CMOS 8/16-bit microcontrollers based on the
AVR enhanced RISC architecture with integrated LCD controller. The available Atmel AVR
XMEGA B modules described in this manual are:
z Atmel AVR CPU
z Memories
z DMAC - Direct memory access controller
z Event system
z System clock and clock options
z Power management and sleep modes
z System control and reset
z WDT - Watchdog timer
z Interrupts and programmable multilevel interrupt controller
z PORT - I/O ports
z TC - 16-bit timer/counters
z AWeX - Advanced waveform extension
z Hi-Res - High resolution extension
z RTC - Real-time counter
z USB - Universal serial bus interface
z TWI - Two-wire serial interface
z SPI - Serial peripheral interface
z USART - Universal synchronous and asynchronous serial receiver and transmitter
z IRCOM - Infrared communication module
z AES and DES cryptographic engine
z CRC - Cyclic redundancy check
z LCD - Liquid Crystal Display controller
z ADC - Analog-to-digital converter
z AC - Analog comparator
z IEEE 1149.1 JTAG interface
z PDI - Program and debug interface
z Memory programming
z Peripheral address map
z Register summary
z Interrupt vector summary
z Instruction set summary
8-bit Atmel XMEGA B Microcontroller
XMEGA B MANUAL
XMEGA B [MANUAL] 2
Atmel-8291C-AVR-XMEGA B -09/2014
1. About the Manual
This document contains in-depth documentation of all peripherals and modules available for the Atmel AVR XMEGA B
microcontroller family. All features are documented on a functional level and described in a general sense. All peripherals
and modules described in this manual may not be present in all Atmel AVR XMEGA B devices.
For all device-specific information such as characterization data, memory sizes, modules, peripherals available and their
absolute memory addresses, refer to the device datasheets. When several instances of a peripheral exists in one device,
each instance will have a unique name. For example each port module (PORT) have unique name, such as PORTA,
PORTB, etc. Register and bit names are unique within one module instance.
For more details on applied use and code examples for peripherals and modules, refer to the Atmel AVR XMEGA
specific application notes available from http://www.atmel.com/avr.
1.1 Reading the Manual
The main sections describe the various modules and peripherals. Each section contains a short feature list and overview
describing the module. The remaining section describes the features and functions in more detail.
The register description sections list all registers and describe each register, bit and flag with their function. This includes
details on how to set up and enable various features in the module. When multiple bits are needed for a configuration
setting, these are grouped together in a bit group. The possible bit group configurations are listed for all bit groups
together with their associated Group Configuration and a short description. The Group Configuration refers to the defined
configuration name used in the Atmel AVR XMEGA assembler header files and application note source code.
The register summary sections list the internal register map for each module type.
The interrupt vector summary sections list the interrupt vectors and offset address for each module type.
1.2 Resources
A comprehensive set of development tools, application notes, and datasheets are available for download from
http://www.atmel.com/avr.
1.3 Recommended Reading
z Atmel AVR XMEGA B device datasheets
z AVR XMEGA application notes
This manual contains general modules and peripheral descriptions. The AVR XMEGA B device datasheets contains the
device-specific information. The XMEGA application notes and Atmel Software Framework contain example code and
show applied use of the modules and peripherals.
For new users, it is recommended to read the AVR1000 - Getting Started Writing C Code for Atmel XMEGA.
XMEGA B [MANUAL] 3
Atmel-8291C-AVR-XMEGA B -09/2014
2. Overview
The AVR XMEGA B microcontrollers is a family of low-power, high-performance, and peripheral-rich CMOS 8/16-bit
microcontrollers based on the AVR enhanced RISC architecture. By executing powerful instructions in a single clock
cycle, the Atmel AVR XMEGA B devices achieve throughputs approaching one million instructions per second (MIPS)
per megahertz, allowing the system designer to optimize power consumption versus processing speed.
The AVR CPU combines a rich instruction set with 32 general purpose working registers. All 32 registers are directly
connected to the arithmetic logic unit (ALU), allowing two independent registers to be accessed in a single instruction,
executed in one clock cycle. The resulting architecture is more code efficient while achieving throughputs many times
faster than conventional single-accumulator or CISC based microcontrollers.
The Atmel AVR XMEGA B devices provide the following features: in-system programmable flash with read-while-write
capabilities; internal EEPROM and SRAM; two-channel DMA controller; four-channel event system and programmable
multilevel interrupt controller; up to 53 general purpose I/O lines; 16-bit real-time counter (RTC); up to three flexible 16-bit
timer/counters with capture, compare and PWM modes; up to two USARTs; one I2
C and SMBUS compatible two-wire
serial interface (TWI); one full-speed USB 2.0 interface; one serial peripheral interface (SPI); one LCD controller
supporting display capacity up to 4 Common and up to 40 Segment terminals; CRC module; AES and DES cryptographic
engine; up to two 8-channel, 12-bit ADCs with programmable gain; up to four analog comparators with window mode;
programmable watchdog timer with separate internal oscillator; accurate internal oscillators with PLL and prescaler; and
programmable brown-out detection.
The program and debug interface (PDI), a fast, two-pin interface for programming and debugging, is available. Selected
devices also have an IEEE std. 1149.1 compliant JTAG interface, and this can also be used for on-chip debug and
programming.
The Atmel AVR XMEGA devices have five software selectable power saving modes. The idle mode stops the CPU while
allowing the SRAM, DMA controller, event system, interrupt controller, and all peripherals to continue functioning. The
power-down mode saves the SRAM and register contents, but stops the oscillators, disabling all other functions until the
next TWI, USB resume, or pin-change interrupt, or reset. In power-save mode, the asynchronous real-time counter
continues to run, allowing the application to maintain a timer base while the rest of the device is sleeping. In this mode,
the LCD controller is allowed to refresh data to the panel. In standby mode, the external crystal oscillator keeps running
while the rest of the device is sleeping. This allows very fast startup from the external crystal, combined with low power
consumption. In extended standby mode, both the main oscillator and the asynchronous timer continue to run. In this
mode, the LCD controller is allowed to refresh data to the panel. To further reduce power consumption, the peripheral
clock to each individual peripheral can optionally be stopped in active mode and idle sleep mode.
The devices are manufactured using Atmel high-density, nonvolatile memory technology. The program flash memory can
be reprogrammed in-system through the PDI or JTAG interfaces. A boot loader running in the device can use any
interface to download the application program to the flash memory. The boot loader software in the boot flash section will
continue to run while the application flash section is updated, providing true read-while-write operation. By combining an
8/16-bit RISC CPU with In-system, self-programmable flash, the Atmel AVR XMEGA is a powerful microcontroller family
that provides a highly flexible and cost effective solution for many embedded applications.
The Atmel AVR XMEGA B devices are supported with a full suite of program and system development tools, including C
compilers, macro assemblers, program debugger/simulators, programmers, and evaluation kits.
XMEGA B [MANUAL] 4
Atmel-8291C-AVR-XMEGA B -09/2014
Figure 2-1. Atmel AVR XMEGA B block diagram.
In Table 2-1 on page 5 a feature summary for the XMEGA B family is shown, split into one feature summary column for
each sub-family. Each sub-family has identical feature set, but different memory options, refer to their device datasheet
for ordering codes and memory options.
Power
Supervision
POR/BOD &
RESET
PORT A (8)
PORT B (8)
EVENT ROUTING NETWORK
DMA
Controller
BUS Matrix
SRAM
ADCA
ACA
ADCB
ACB
OCD
PORT M (8)
PDI
SEG[31..24] /
PM[0..7]
SEG[0..23]
COM[0..3]
PA[0..7]
PB[0..7]/
JTAG
Watchdog
Timer
Watchdog
Oscillator
Interrupt
Controller
DATA BUS
Prog/Debug
Controller
VCC
GND
PORT R (2)
PR[0..1]
Oscillator
Control
Real Time
Counter
Event System
Controller
JTAG
PDI_DATA
RESET /
PDI_CLK
PORT B
Sleep
Controller
DES
CRC
IRCOM
PORT G (8) SEG[39..32] /
PG[0..7]
LCD POWER[0..4]
PORT C (8)
PC[0..7] TCC0:1 USARTC0 SPIC
TWIC
PD[0..2] PE[0..7]
PORT D (3)
TCE0
USARTE0
PORT E (8)
USB
EVENT ROUTING NETWORK
AES Int. Refs.
AREFA
AREFB
Tempref
VCC/10
CPU
NVM Controller
Flash EEPROM
DATA BUS
LCD
TOSC1
TOSC2
To Clock
Generator
XTAL2 /
TOSC2
XTAL1 /
TOSC1
Oscillator
Circuits/
Clock
Generation
(Alternate)
Digital function
Analog function / Oscillators
Programming, debug, test
External clock / Crystal pins
General Purpose I/O
Ground
Power LCD
XMEGA B [MANUAL] 5
Atmel-8291C-AVR-XMEGA B -09/2014
Table 2-1. XMEGA B feature summary overview.
Feature Details / sub-family B1 B3
Pins, I/O
Total 100 64
Programmable I/O pins 53 36
Memory
Program memory (KB) 64 - 128 64 - 128
Boot memory (KB) 4 - 8 4 - 8
SRAM (KB) 4 - 8 4 - 8
EEPROM 2 2 - 4
General purpose registers 16 16
Package
TQFP 100A 64A
QFN /VQFN – 64M2
BGA 100C1/100C2 –
QTouch Sense channels 56 56
DMA Controller Channels 2 2
Event System
Channels 4 4
QDEC 1 1
Crystal Oscillator
0.4 - 16MHz XOSC Yes Yes
32.768 kHz TOSC Yes Yes
Internal Oscillator
2MHz calibrated Yes Yes
32MHz calibrated Yes Yes
128MHz PLL Yes Yes
32.768kHz calibrated Yes Yes
32kHz ULP Yes Yes
Timer / Counter
TC0 - 16-bit, 4 CC 2 1
TC1 - 16-bit, 2 CC 1 1
TC2 - 2x 8-bit 2 1
Hi-Res 1 1
AWeX 1 1
RTC 1 1
RTC32
Serial Communication
USB full-speed device 1 1
USART 2 1
SPI 1 1
TWI 1 1
XMEGA B [MANUAL] 6
Atmel-8291C-AVR-XMEGA B -09/2014
Crypto /CRC
AES-128 Yes Yes
DES Yes Yes
CRC-16 Yes Yes
CRC-32 Yes Yes
Liquid Crystal Display
Controller (LCD)
Segments 40 25
Common terminals 4 4
Analog to Digital Converter
(ADC)
2 1
Resolution (bits) 12 12
Sampling speed (kbps) 300 300
Input channels per ADC 16 8
Conversion channels 1 1
Analog Comparator (AC) 4 2
Program and Debug Interface
PDI Yes Yes
JTAG Yes Yes
Boundary scan Yes Yes
Feature Details / sub-family B1 B3
XMEGA B [MANUAL] 7
Atmel-8291C-AVR-XMEGA B -09/2014
3. Atmel AVR CPU
3.1 Features
z 8/16-bit, high-performance Atmel AVR RISC CPU
z 142 instructions
z Hardware multiplier
z 32x8-bit registers directly connected to the ALU
z Stack in RAM
z Stack pointer accessible in I/O memory space
z Direct addressing of up to 16MB of program memory and 16MB of data memory
z True 16/24-bit access to 16/24-bit I/O registers
z Efficient support for 8-, 16-, and 32-bit arithmetic
z Configuration change protection of system-critical features
3.2 Overview
All Atmel AVR XMEGA devices use the 8/16-bit AVR CPU. The main function of the CPU is to execute the code and
perform all calculations. The CPU is able to access memories, perform calculations, control peripherals, and execute the
program in the flash memory. Interrupt handling is described in a separate section, “Interrupts and Programmable
Multilevel Interrupt Controller” on page 115.
3.3 Architectural Overview
In order to maximize performance and parallelism, the AVR CPU uses a Harvard architecture with separate memories
and buses for program and data. Instructions in the program memory are executed with single-level pipelining. While one
instruction is being executed, the next instruction is pre-fetched from the program memory. This enables instructions to
be executed on every clock cycle. For a summary of all AVR instructions, refer to “Instruction Set Summary” on page
395. For details of all AVR instructions, refer to http://www.atmel.com/avr.
Figure 3-1. Block diagram of the AVR CPU architecture.
XMEGA B [MANUAL] 8
Atmel-8291C-AVR-XMEGA B -09/2014
The arithmetic logic unit (ALU) supports arithmetic and logic operations between registers or between a constant and a
register. Single-register operations can also be executed in the ALU. After an arithmetic operation, the status register is
updated to reflect information about the result of the operation.
The ALU is directly connected to the fast-access register file. The 32 x 8-bit general purpose working registers all have
single clock cycle access time allowing single-cycle arithmetic logic unit operation between registers or between a
register and an immediate. Six of the 32 registers can be used as three 16-bit address pointers for program and data
space addressing, enabling efficient address calculations.
The memory spaces are linear. The data memory space and the program memory space are two different memory
spaces.
The data memory space is divided into I/O registers, SRAM, and external RAM. In addition, the EEPROM can be
memory mapped in the data memory.
All I/O status and control registers reside in the lowest 4KB addresses of the data memory. This is referred to as the I/O
memory space. The lowest 64 addresses can be accessed directly, or as the data space locations from 0x00 to 0x3F.
The rest is the extended I/O memory space, ranging from 0x0040 to 0x0FFF. I/O registers here must be accessed as
data space locations using load (LD/LDS/LDD) and store (ST/STS/STD) instructions.
The SRAM holds data. Code execution from SRAM is not supported. It can easily be accessed through the five different
addressing modes supported in the AVR architecture. The first SRAM address is 0x2000.
Data addresses 0x1000 to 0x1FFF are reserved for memory mapping of EEPROM.
The program memory is divided in two sections, the application program section and the boot program section. Both
sections have dedicated lock bits for write and read/write protection. The SPM instruction that is used for selfprogramming
of the application flash memory must reside in the boot program section. The application section contains
an application table section with separate lock bits for write and read/write protection. The application table section can
be used for save storing of nonvolatile data in the program memory.
3.4 ALU - Arithmetic Logic Unit
The arithmetic logic unit supports arithmetic and logic operations between registers or between a constant and a register.
Single-register operations can also be executed. The ALU operates in direct connection with all 32 general purpose
registers. In a single clock cycle, arithmetic operations between general purpose registers or between a register and an
immediate are executed and the result is stored in the register file. After an arithmetic or logic operation, the status
register is updated to reflect information about the result of the operation.
ALU operations are divided into three main categories – arithmetic, logical, and bit functions. Both 8- and 16-bit
arithmetic is supported, and the instruction set allows for efficient implementation of 32-bit arithmetic. The hardware
multiplier supports signed and unsigned multiplication and fractional format.
3.4.1 Hardware Multiplier
The multiplier is capable of multiplying two 8-bit numbers into a 16-bit result. The hardware multiplier supports different
variations of signed and unsigned integer and fractional numbers:
z Multiplication of unsigned integers
z Multiplication of signed integers
z Multiplication of a signed integer with an unsigned integer
z Multiplication of unsigned fractional numbers
z Multiplication of signed fractional numbers
z Multiplication of a signed fractional number with an unsigned one
A multiplication takes two CPU clock cycles.
XMEGA B [MANUAL] 9
Atmel-8291C-AVR-XMEGA B -09/2014
3.5 Program Flow
After reset, the CPU starts to execute instructions from the lowest address in the flash program memory ‘0.’ The program
counter (PC) addresses the next instruction to be fetched.
Program flow is provided by conditional and unconditional jump and call instructions capable of addressing the whole
address space directly. Most AVR instructions use a 16-bit word format, while a limited number use a 32-bit format.
During interrupts and subroutine calls, the return address PC is stored on the stack. The stack is allocated in the general
data SRAM, and consequently the stack size is only limited by the total SRAM size and the usage of the SRAM. After
reset, the stack pointer (SP) points to the highest address in the internal SRAM. The SP is read/write accessible in the
I/O memory space, enabling easy implementation of multiple stacks or stack areas. The data SRAM can easily be
accessed through the five different addressing modes supported in the AVR CPU.
3.6 Instruction Execution Timing
The AVR CPU is clocked by the CPU clock, clkCPU. No internal clock division is used. Figure 3-2 on page 9 shows the
parallel instruction fetches and instruction executions enabled by the Harvard architecture and the fast-access register
file concept. This is the basic pipelining concept used to obtain up to 1MIPS/MHz performance with high power efficiency.
Figure 3-2. The parallel instruction fetches and instruction executions.
Figure 3-3 on page 9 shows the internal timing concept for the register file. In a single clock cycle, an ALU operation
using two register operands is executed and the result is stored back to the destination register.
Figure 3-3. Single Cycle ALU Operation
clk
1st Instruction Fetch
1st Instruction Execute
2nd Instruction Fetch
2nd Instruction Execute
3rd Instruction Fetch
3rd Instruction Execute
4th Instruction Fetch
T1 T2 T3 T4
CPU
Total Execution Time
Register Operands Fetch
ALU Operation Execute
Result Write Back
T1 T2 T3 T4
clkCPU
XMEGA B [MANUAL] 10
Atmel-8291C-AVR-XMEGA B -09/2014
3.7 Status Register
The status register (SREG) contains information about the result of the most recently executed arithmetic or logic
instruction. This information can be used for altering program flow in order to perform conditional operations. Note that
the status register is updated after all ALU operations, as specified in the instruction set reference. This will in many
cases remove the need for using the dedicated compare instructions, resulting in faster and more compact code.
The status register is not automatically stored when entering an interrupt routine nor restored when returning from an
interrupt. This must be handled by software.
The status register is accessible in the I/O memory space.
3.8 Stack and Stack Pointer
The stack is used for storing return addresses after interrupts and subroutine calls. It can also be used for storing
temporary data. The stack pointer (SP) register always points to the top of the stack. It is implemented as two 8-bit
registers that are accessible in the I/O memory space. Data are pushed and popped from the stack using the PUSH and
POP instructions. The stack grows from a higher memory location to a lower memory location. This implies that pushing
data onto the stack decreases the SP, and popping data off the stack increases the SP. The SP is automatically loaded
after reset, and the initial value is the highest address of the internal SRAM. If the SP is changed, it must be set to point
above address 0x2000, and it must be defined before any subroutine calls are executed or before interrupts are enabled.
During interrupts or subroutine calls, the return address is automatically pushed on the stack. The return address can be
two or three bytes, depending on program memory size of the device. For devices with 128KB or less of program
memory, the return address is two bytes, and hence the stack pointer is decremented/incremented by two. For devices
with more than 128KB of program memory, the return address is three bytes, and hence the SP is
decremented/incremented by three. The return address is popped off the stack when returning from interrupts using the
RETI instruction, and from subroutine calls using the RET instruction.
The SP is decremented by one when data are pushed on the stack with the PUSH instruction, and incremented by one
when data is popped off the stack using the POP instruction.
To prevent corruption when updating the stack pointer from software, a write to SPL will automatically disable interrupts
for up to four instructions or until the next I/O memory write.
3.9 Register File
The register file consists of 32 x 8-bit general purpose working registers with single clock cycle access time. The register
file supports the following input/output schemes:
z One 8-bit output operand and one 8-bit result input
z Two 8-bit output operands and one 8-bit result input
z Two 8-bit output operands and one 16-bit result input
z One 16-bit output operand and one 16-bit result input
Six of the 32 registers can be used as three 16-bit address register pointers for data space addressing, enabling efficient
address calculations. One of these address pointers can also be used as an address pointer for lookup tables in flash
program memory.
XMEGA B [MANUAL] 11
Atmel-8291C-AVR-XMEGA B -09/2014
Figure 3-4. AVR CPU general purpose working registers.
The register file is located in a separate address space, and so the registers are not accessible as data memory.
3.9.1 The X-, Y-, and Z- Registers
Registers R26..R31 have added functions besides their general-purpose usage.
These registers can form 16-bit address pointers for addressing data memory. These three address registers are called
the X-register, Y-register, and Z-register. The Z-register can also be used as an address pointer to read from and/or write
to the flash program memory, signature rows, fuses, and lock bits.
Figure 3-5. The X-, Y- and Z-registers.
7 0 Addr.
R0 0x00
R1 0x01
R2 0x02
…
R13 0x0D
General R14 0x0E
Purpose R15 0x0F
Working R16 0x10
Registers R17 0x11
…
R26 0x1A X-register Low Byte
R27 0x1B X-register High Byte
R28 0x1C Y-register Low Byte
R29 0x1D Y-register High Byte
R30 0x1E Z-register Low Byte
R31 0x1F Z-register High Byte
Bit (individually) 7 R27 0 7 R26 0
X-register XH XL
Bit (X-register) 15 8 7 0
Bit (individually) 7 R29 0 7 R28 0
Y-register YH YL
Bit (Y-register) 15 8 7 0
Bit (individually) 7 R31 0 7 R30 0
Z-register ZH ZL
Bit (Z-register) 15 8 7 0
XMEGA B [MANUAL] 12
Atmel-8291C-AVR-XMEGA B -09/2014
The lowest register address holds the least-significant byte (LSB), and the highest register address holds the mostsignificant
byte (MSB). In the different addressing modes, these address registers function as fixed displacement,
automatic increment, and automatic decrement (see the instruction set reference for details).
3.10 RAMP and Extended Indirect Registers
In order to access program memory or data memory above 64KB, the address pointer must be larger than 16 bits. This is
done by concatenating one register to one of the X-, Y-, or Z-registers. This register then holds the most-significant byte
(MSB) in a 24-bit address or address pointer.
These registers are available only on devices with external bus interface and/or more than 64KB of program or data
memory space. For these devices, only the number of bits required to address the whole program and data memory
space in the device is implemented in the registers.
3.10.1 RAMPX, RAMPY and RAMPZ Registers
The RAMPX, RAMPY and RAMPZ registers are concatenated with the X-, Y-, and Z-registers, respectively, to enable
indirect addressing of the whole data memory space above 64KB and up to 16MB.
Figure 3-6. The combined RAMPX + X, RAMPY + Y and RAMPZ + Z registers.
When reading (ELPM) and writing (SPM) program memory locations above the first 128KB of the program memory,
RAMPZ is concatenated with the Z-register to form the 24-bit address. LPM is not affected by the RAMPZ setting.
3.10.2 RAMPD Register
This register is concatenated with the operand to enable direct addressing of the whole data memory space above 64KB.
Together, RAMPD and the operand will form a 24-bit address.
Figure 3-7. The combined RAMPD + K register.
Bit (Individually) 7 0 7 0 7 0
RAMPX XH XL
Bit (X-pointer) 23 16 15 8 7 0
Bit (Individually) 7 0 7 0 7 0
RAMPY YH YL
Bit (Y-pointer) 23 16 15 8 7 0
Bit (Individually) 7 0 7 0 7 0
RAMPZ ZH ZL
Bit (Z-pointer) 23 16 15 8 7 0
Bit (Individually) 7 0 15 0
RAMPD K
Bit (D-pointer) 23 16 15 0
XMEGA B [MANUAL] 13
Atmel-8291C-AVR-XMEGA B -09/2014
3.10.3 EIND - Extended Indirect Register
EIND is concatenated with the Z-register to enable indirect jump and call to locations above the first 128KB (64K words)
of the program memory.
Figure 3-8. The combined EIND + Z register.
3.11 Accessing 16-bit Registers
The AVR data bus is 8 bits wide, and so accessing 16-bit registers requires atomic operations. These registers must be
byte-accessed using two read or write operations. 16-bit registers are connected to the 8-bit bus and a temporary register
using a 16-bit bus.
For a write operation, the low byte of the 16-bit register must be written before the high byte. The low byte is then written
into the temporary register. When the high byte of the 16-bit register is written, the temporary register is copied into the
low byte of the 16-bit register in the same clock cycle.
For a read operation, the low byte of the 16-bit register must be read before the high byte. When the low byte register is
read by the CPU, the high byte of the 16-bit register is copied into the temporary register in the same clock cycle as the
low byte is read. When the high byte is read, it is then read from the temporary register.
This ensures that the low and high bytes of 16-bit registers are always accessed simultaneously when reading or writing
the register.
Interrupts can corrupt the timed sequence if an interrupt is triggered and accesses the same 16-bit register during an
atomic 16-bit read/write operation. To prevent this, interrupts can be disabled when writing or reading 16-bit registers.
The temporary registers can also be read and written directly from user software.
3.11.1 Accessing 24- and 32-bit Registers
For 24- and 32-bit registers, the read and write access is done in the same way as described for 16-bit registers, except
there are two temporary registers for 24-bit registers and three for 32-bit registers. The least-significant byte must be
written first when doing a write, and read first when doing a read.
3.12 Configuration Change Protection
System critical I/O register settings are protected from accidental modification. The SPM instruction is protected from
accidental execution, and the LPM instruction is protected when reading the fuses and signature row. This is handled
globally by the configuration change protection (CCP) register. Changes to the protected I/O registers or bits, or
execution of protected instructions, are only possible after the CPU writes a signature to the CCP register. The different
signatures are described in the register description.
There are two modes of operation: one for protected I/O registers, and one for the protected instructions, SPM/LPM.
3.12.1 Sequence for write operation to protected I/O registers
1. The application code writes the signature that enable change of protected I/O registers to the CCP register.
2. Within four instruction cycles, the application code must write the appropriate data to the protected register. Most
protected registers also contain a write enable/change enable bit. This bit must be written to one in the same operation
as the data are written. The protected change is immediately disabled if the CPU performs write operations to
the I/O register or data memory or if the SPM, LPM, or SLEEP instruction is executed.
Bit (Individually) 7 0 7 0 7 0
EIND ZH ZL
Bit (D-pointer) 23 16 15 8 7 0
XMEGA B [MANUAL] 14
Atmel-8291C-AVR-XMEGA B -09/2014
3.12.2 Sequence for execution of protected SPM/LPM
1. The application code writes the signature for the execution of protected SPM/LPM to the CCP register.
2. Within four instruction cycles, the application code must execute the appropriate instruction. The protected change
is immediately disabled if the CPU performs write operations to the data memory or if the SLEEP instruction is
executed.
Once the correct signature is written by the CPU, interrupts will be ignored for the duration of the configuration change
enable period. Any interrupt request (including non-maskable interrupts) during the CCP period will set the
corresponding interrupt flag as normal, and the request is kept pending. After the CCP period is completed, any pending
interrupts are executed according to their level and priority. DMA requests are still handled, but do not influence the
protected configuration change enable period. A signature written by DMA is ignored.
3.13 Fuse Lock
For some system-critical features, it is possible to program a fuse to disable all changes to the associated I/O control
registers. If this is done, it will not be possible to change the registers from the user software, and the fuse can only be
reprogrammed using an external programmer. Details on this are described in the datasheet module where this feature is
available.
XMEGA B [MANUAL] 15
Atmel-8291C-AVR-XMEGA B -09/2014
3.14 Register Descriptions
3.14.1 CCP – Configuration Change Protection register
z Bit 7:0 – CCP[7:0]: Configuration Change Protection
The CCP register must be written with the correct signature to enable change of the protected I/O register or execution of
the protected instruction for a maximum period of four CPU instruction cycles. All interrupts are ignored during these
cycles. After these cycles, interrupts will automatically be handled again by the CPU, and any pending interrupts will be
executed according to their level and priority. When the protected I/O register signature is written, CCP[0] will read as
one as long as the protected feature is enabled. Similarly when the protected SPM/LPM signature is written, CCP[1] will
read as one as long as the protected feature is enabled. CCP[7:2] will always read as zero. Table 3-1 shows the
signature for the various modes.
Table 3-1. Modes of CPU change protection.
3.14.2 RAMPD – Extended Direct Addressing register
This register is concatenated with the operand for direct addressing (LDS/STS) of the whole data memory space on
devices with more than 64KB of data memory. This register is not available if the data memory, including external
memory, is less than 64KB.
z Bit 7:0 – RAMPD[7:0]: Extended Direct Addressing bits
These bits hold the MSB of the 24-bit address created by RAMPD and the 16-bit operand. Only the number of bits
required to address the available data memory is implemented for each device. Unused bits will always read as zero.
Bit 7 6 5 4 3 2 1 0
+0x04 CCP[7:0]
Read/Write W W W W W W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
Signature Group Configuration Description
0x9D SPM Protected SPM/LPM
0xD8 IOREG Protected IO register
Bit 7 6 5 4 3 2 1 0
+0x08 RAMPD[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 16
Atmel-8291C-AVR-XMEGA B -09/2014
3.14.3 RAMPX – Extended X-Pointer register
This register is concatenated with the X-register for indirect addressing (LD/LDD/ST/STD) of the whole data memory
space on devices with more than 64KB of data memory. This register is not available if the data memory, including
external memory, is less than 64KB.
z Bit 7:0 – RAMPX[7:0]: Extended X-pointer Address bits
These bits hold the MSB of the 24-bit address created by RAMPX and the 16-bit X-register. Only the number of bits
required to address the available data memory is implemented for each device. Unused bits will always read as zero.
3.14.4 RAMPY – Extended Y-Pointer register
This register is concatenated with the Y-register for indirect addressing (LD/LDD/ST/STD) of the whole data memory
space on devices with more than 64KB of data memory. This register is not available if the data memory, including
external memory, is less than 64KB.
z Bit 7:0 – RAMPY[7:0]: Extended Y-pointer Address bits
These bits hold the MSB of the 24-bit address created by RAMPY and the 16-bit Y-register. Only the number of bits
required to address the available data memory is implemented for each device. Unused bits will always read as zero.
3.14.5 RAMPZ – Extended Z-Pointer register
This register is concatenated with the Z-register for indirect addressing (LD/LDD/ST/STD) of the whole data memory
space on devices with more than 64KB of data memory. RAMPZ is concatenated with the Z-register when reading
(ELPM) program memory locations above the first 64KB and writing (SPM) program memory locations above the first
128KB of the program memory.
This register is not available if the data memory, including external memory and program memory in the device, is less
than 64KB.
z Bit 7:0 – RAMPZ[7:0]: Extended Z-pointer Address bits
These bits hold the MSB of the 24-bit address created by RAMPZ and the 16-bit Z-register. Only the number of bits
required to address the available data and program memory is implemented for each device. Unused bits will always
read as zero.
Bit 7 6 5 4 3 2 1 0
+0x09 RAMPX[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
Bit 7 6 5 4 3 2 1 0
+0x0A RAMPY[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 000000
Bit 7 6 5 4 3 2 1 0
+0x0B RAMPZ[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 00000000
XMEGA B [MANUAL] 17
Atmel-8291C-AVR-XMEGA B -09/2014
3.14.6 EIND – Extended Indirect register
This register is concatenated with the Z-register for enabling extended indirect jump (EIJMP) and call (EICALL) to the
whole program memory space on devices with more than 128KB of program memory. The register should be used for
jumps to addresses below 128KB if ECALL/EIJMP are used, and it will not be used if CALL and IJMP commands are
used. For jump or call to addresses below 128KB, this register is not used. This register is not available if the program
memory in the device is less than 128KB.
z Bit 7:0 – EIND[7:0]: Extended Indirect Address bits
These bits hold the MSB of the 24-bit address created by EIND and the 16-bit Z-register. Only the number of bits
required to access the available program memory is implemented for each device. Unused bits will always read as zero.
3.14.7 SPL – Stack Pointer Register Low
The SPH and SPL register pair represent the 16-bit SP value. The SP holds the stack pointer that points to the top of the
stack. After reset, the stack pointer points to the highest internal SRAM address. To prevent corruption when updating
the stack pointer from software, a write to SPL will automatically disable interrupts for the next four instructions or until
the next I/O memory write.
Only the number of bits required to address the available data memory, including external memory, up to 64KB is
implemented for each device. Unused bits will always read as zero.
Note: 1. Refer to specific device datasheets for exact initial values.
z Bit 7:0 – SP[7:0]: Stack Pointer Register Low
These bits hold the LSB of the 16-bit stack pointer (SP).
3.14.8 SPH – Stack Pointer Register High
Note: 1. Refer to specific device datasheets for exact initial values.
z Bit 7:0 – SP[15:8]: Stack Pointer Register High
These bits hold the MSB of the 16-bit stack pointer (SP).
Bit 7 6 5 4 3 2 1 0
+0x0C EIND[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
Bit 7 6 5 4 3 2 1 0
+0x0D SP[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value(1) 0/1 0/1 0/1 0/1 0/1 0/1 0/1 0/1
Bit 7 6 5 4 3 2 1 0
+0x0E SP[15:8]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value(1) 0/1 0/1 0/1 0/1 0/1 0/1 0/1 0/1
XMEGA B [MANUAL] 18
Atmel-8291C-AVR-XMEGA B -09/2014
3.14.9 SREG – Status Register
The status register (SREG) contains information about the result of the most recently executed arithmetic or logic
instruction.
z Bit 7 – I: Global Interrupt Enable
The global interrupt enable bit must be set for interrupts to be enabled. If the global interrupt enable register is cleared,
none of the interrupts are enabled independent of the individual interrupt enable settings. This bit is not cleared by
hardware after an interrupt has occurred. This bit can be set and cleared by the application with the SEI and CLI
instructions, as described in “Instruction Set Description.” Changing the I flag through the I/O-register result in a onecycle
wait state on the access.
z Bit 6 – T: Bit Copy Storage
The bit copy instructions bit load (BLD) and bit store (BST) use the T bit as source or destination for the operated bit. A bit
from a register in the register file can be copied into this bit by the BST instruction, and this bit can be copied into a bit in
a register in the register file by the BLD instruction.
z Bit 5 – H: Half Carry Flag
The half carry flag (H) indicates a half carry in some arithmetic operations. Half carry Is useful in BCD arithmetic. See
“Instruction Set Description” for detailed information.
z Bit 4 – S: Sign Bit, S = N ⊕ V
The sign bit is always an exclusive or between the negative flag, N, and the two’s complement overflow flag, V. See
“Instruction Set Description” for detailed information.
z Bit 3 – V: Two’s Complement Overflow Flag
The two’s complement overflow flag (V) supports two’s complement arithmetic. See “Instruction Set Description” for
detailed information.
z Bit 2 – N: Negative Flag
The negative flag (N) indicates a negative result in an arithmetic or logic operation. See “Instruction Set Description” for
detailed information.
z Bit 1 – Z: Zero Flag
The zero flag (Z) indicates a zero result in an arithmetic or logic operation. See “Instruction Set Description” for detailed
information.
z Bit 0 – C: Carry Flag
The carry flag (C) indicates a carry in an arithmetic or logic operation. See “Instruction Set Description” for detailed
information.
Bit 7 6 5 4 3 2 1 0
+0x0F I THSVNZC
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 19
Atmel-8291C-AVR-XMEGA B -09/2014
3.15 Register Summary
Address Name Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 Page
+0x00 Reserved – – – – – – – –
+0x01 Reserved – – – – – – – –
+0x02 Reserved – – – – – – – –
+0x03 Reserved – – – – – – – –
+0x04 CCP CCP[7:0] 15
+0x05 Reserved – – – – – – – –
+0x06 Reserved – – – – – – – –
+0x07 Reserved – – – – – – – –
+0x08 RAMPD RAMPD[7:0] 15
+0x09 RAMPX RAMPX[7:0] 16
+0x0A RAMPY RAMPY[7:0] 16
+0x0B RAMPZ RAMPZ[7:0] 16
+0x0C EIND EIND[7:0] 17
+0x0D SPL SPL[7:0] 17
+0x0E SPH SPH[7:0] 17
+0x0F SREG I T H S V N Z C 18
XMEGA B [MANUAL] 20
Atmel-8291C-AVR-XMEGA B -09/2014
4. Memories
4.1 Features
z Flash program memory
z One linear address space
z In-system programmable
z Self-programming and boot loader support
z Application section for application code
z Application table section for application code or data storage
z Boot section for application code or bootloader code
z Separate read/write protection lock bits for all sections
z Built in fast CRC check of a selectable flash program memory section
z Data memory
z One linear address space
z Single-cycle access from CPU
z SRAM
z EEPROM
z Byte and page accessible
z Optional memory mapping for direct load and store
z I/O memory
z Configuration and status registers for all peripherals and modules
z 4 bit-accessible general purpose registers for global variables or flags
z Bus arbitration
z Safe and deterministic handling of priority between CPU, DMA controller, and other bus masters
z Separate buses for SRAM, EEPROM, I/O memory, and external memory access
z Simultaneous bus access for CPU and DMA controller
z Production signature row memory for factory programmed data
z ID for each microcontroller device type
z Serial number for each device
z Calibration bytes for factory calibrated peripherals
z User signature row
z One flash page in size
z Can be read and written from software
z Content is kept after chip erase
4.2 Overview
This section describes the different memory sections. The AVR architecture has two main memory spaces, the program
memory and the data memory. Executable code can reside only in the program memory, while data can be stored in the
program memory and the data memory. The data memory includes the internal SRAM, and EEPROM for nonvolatile
data storage. All memory spaces are linear and require no memory bank switching. Nonvolatile memory (NVM) spaces
can be locked for further write and read/write operations. This prevents unrestricted access to the application software.
A separate memory section contains the fuse bytes. These are used for configuring important system functions, and can
only be written by an external programmer.
4.3 Flash Program Memory
All XMEGA devices contain on-chip, in-system reprogrammable flash memory for program storage. The flash memory
can be accessed for read and write from an external programmer through the PDI or from application software running in
the device.
XMEGA B [MANUAL] 21
Atmel-8291C-AVR-XMEGA B -09/2014
All AVR CPU instructions are 16 or 32 bits wide, and each flash location is 16 bits wide. The flash memory is organized
in two main sections, the application section and the boot loader section, as shown in Figure 4-1 on page 21. The sizes
of the different sections are fixed, but device-dependent. These two sections have separate lock bits, and can have
different levels of protection. The store program memory (SPM) instruction, which is used to write to the flash from the
application software, will only operate when executed from the boot loader section.
The application section contains an application table section with separate lock settings. This enables safe storage of
nonvolatile data in the program memory.
Figure 4-1. Flash memory sections.
4.3.1 Application Section
The Application section is the section of the flash that is used for storing the executable application code. The protection
level for the application section can be selected by the boot lock bits for this section. The application section can not store
any boot loader code since the SPM instruction cannot be executed from the application section.
4.3.2 Application Table Section
The application table section is a part of the application section of the flash memory that can be used for storing data.
The size is identical to the boot loader section. The protection level for the application table section can be selected by
the boot lock bits for this section. The possibilities for different protection levels on the application section and the
application table section enable safe parameter storage in the program memory. If this section is not used for data,
application code can reside here.
4.3.3 Boot Loader Section
While the application section is used for storing the application code, the boot loader software must be located in the boot
loader section because the SPM instruction can only initiate programming when executing from this section. The SPM
instruction can access the entire flash, including the boot loader section itself. The protection level for the boot loader
section can be selected by the boot loader lock bits. If this section is not used for boot loader software, application code
can be stored here.
Application Flash
Section
0x000000
End Application
Start Boot Loader
Flashend
Application Table
Flash Section
Boot Loader Flash
Section
XMEGA B [MANUAL] 22
Atmel-8291C-AVR-XMEGA B -09/2014
4.3.4 Production Signature Row
The production signature row is a separate memory section for factory programmed data. It contains calibration data for
functions such as oscillators and analog modules. Some of the calibration values will be automatically loaded to the
corresponding module or peripheral unit during reset. Other values must be loaded from the signature row and written to
the corresponding peripheral registers from software. For details on calibration conditions such as temperature, voltage
references, etc., refer to the device datasheet.
The production signature row also contains an ID that identifies each microcontroller device type and a serial number for
each manufactured device. The serial number consists of the production lot number, wafer number, and wafer
coordinates for the device.
The production signature row cannot be written or erased, but it can be read from application software and external
programmers.
For accessing the production signature row, refer to “NVM Flash Commands” on page 380.
4.3.5 User Signature Row
The user signature row is a separate memory section that is fully accessible (read and write) from application software
and external programmers. It is one flash page in size, and is meant for static user parameter storage, such as calibration
data, custom serial number, identification numbers, random number seeds, etc. This section is not erased by chip erase
commands that erase the flash, and requires a dedicated erase command. This ensures parameter storage during
multiple program/erase operations and on-chip debug sessions.
4.4 Fuses and Lockbits
The fuses are used to configure important system functions, and can only be written from an external programmer. The
application software can read the fuses. The fuses are used to configure reset sources such as brownout detector,
watchdog and startup configuration.
The lock bits are used to set protection levels for the different flash sections (i.e., if read and/or write access should be
blocked). Lock bits can be written by external programmers and application software, but only to stricter protection levels.
Chip erase is the only way to erase the lock bits. To ensure that flash contents are protected even during chip erase, the
lock bits are erased after the rest of the flash memory has been erased.
An unprogrammed fuse or lock bit will have the value one, while a programmed fuse or lock bit will have the value zero.
Both fuses and lock bits are reprogrammable like the flash program memory.
For some fuse bytes, leaving them unprogrammed (0xFF) will result in invalid settings. The user must ensure that the
fuse bytes are programmed to values which give valid settings. Refer to the detailed description of the individual fuse
bytes for further information.
4.5 Data Memory
The data memory contains the I/O memory, internal SRAM, optionally memory mapped and EEPROM. The data memory
is organized as one continuous memory section, as shown in Figure 4-2 on page 23.
XMEGA B [MANUAL] 23
Atmel-8291C-AVR-XMEGA B -09/2014
Figure 4-2. Data memory map.
I/O memory, EEPROM, and SRAM will always have the same start addresses for all XMEGA devices.
4.6 Internal SRAM
The internal SRAM always starts at hexadecimal address 0x2000. SRAM is accessed by the CPU using the load
(LD/LDS/LDD) and store (ST/STS/STD) instructions.
4.7 EEPROM
All XMEGA devices have EEPROM for nonvolatile data storage. It is addressable in a separate data space (default) or
memory mapped and accessed in normal data space. The EEPROM supports both byte and page access. Memory
mapped EEPROM allows highly efficient EEPROM reading and EEPROM buffer loading. When doing this, EEPROM is
accessible using load and store instructions. Memory mapped EEPROM will always start at hexadecimal address
0x1000.
4.8 I/O Memory
The status and configuration registers for peripherals and modules, including the CPU, are addressable through I/O
memory locations. All I/O locations can be accessed by the load (LD/LDS/LDD) and store (ST/STS/STD) instructions,
which are used to transfer data between the 32 registers in the register file and the I/O memory. The IN and OUT
instructions can address I/O memory locations in the range of 0x00 to 0x3F directly. In the address range 0x00 - 0x1F,
single-cycle instructions for manipulation and checking of individual bits are available.
4.8.1 General Purpose I/O Registers
The lowest 4 I/O memory addresses are reserved as general purpose I/O registers. These registers can be used for
storing global variables and flags, as they are directly bit-accessible using the SBI, CBI, SBIS, and SBIC instructions.
4.9 Data Memory and Bus Arbitration
Since the data memory is organized as four separate sets of memories, the different bus masters (CPU, DMA controller
read and DMA controller write, etc.) can access different memory sections at the same time. See Figure 4-3 on page 24.
I/O Memory
(Up to 4 KB)
EEPROM
(Up to 4 KB)
Internal SRAM
0x0000
0x1000
0x2000
Start/End
Address Data Memory
XMEGA B [MANUAL] 24
Atmel-8291C-AVR-XMEGA B -09/2014
The USB module acts as a bus master, and is connected directly to internal SRAM through a pseudo-dual-port (PDP)
interface.
Figure 4-3. Bus access.
4.9.1 Bus Priority
When several masters request access to the same bus, the bus priority is in the following order (from higher to lower
priority):
1. Bus Master with ongoing access.
2. Bus Master with ongoing burst.
z Alternating DMA controller read and DMA controller write when they access the same data memory section.
3. Bus Master requesting burst access.
z CPU has priority.
4. Bus Master requesting bus access.
z CPU has priority.
4.10 Memory Timing
Read and write access to the I/O memory takes one CPU clock cycle. A write to SRAM takes one cycle, and a read from
SRAM takes two cycles. For burst read (DMA), new data are available every cycle. EEPROM page load (write) takes one
cycle, and three cycles are required for read. For burst read, new data are available every second cycle. Refer to the
instruction summary for more details on instructions and instruction timing.
4.11 Device ID and Revision
Each device has a three-byte device ID. This ID identifies Atmel as the manufacturer of the device and the device type. A
separate register contains the revision number of the device.
Peripherals and system modules
Bus matrix
DMA CPU
RAM
OCD
USART
SPI
Timer /
Counter
TWI
USB Interrupt
Controller
Power
Management
SRAM
External
Programming
AVR core PDI CH0
ADC
AC
Crypto
modules
Event System
Controller
Oscillator
Control
CH1
Non-Volatile
Memory
EEPROM
Flash CRC
Real Time
Counter
I/O
NVM
Controller
XMEGA B [MANUAL] 25
Atmel-8291C-AVR-XMEGA B -09/2014
4.12 I/O Memory Protection
Some features in the device are regarded as critical for safety in some applications. Due to this, it is possible to lock the
I/O register related to the clock system, the event system, and the advanced waveform extensions. As long as the lock is
enabled, all related I/O registers are locked and they can not be written from the application software. The lock registers
themselves are protected by the configuration change protection mechanism. For details, refer to “Configuration Change
Protection” on page 13.
XMEGA B [MANUAL] 26
Atmel-8291C-AVR-XMEGA B -09/2014
4.13 Register Description – NVM Controller
4.13.1 ADDR0 – Address register 0
The ADDR0, ADDR1, and ADDR2 registers represent the 24-bit value, ADDR. This is used for addressing all NVM
sections for read, write, and CRC operations.
z Bit 7:0 – ADDR[7:0]: Address Byte 0
This register gives the address low byte when accessing NVM locations.
4.13.2 ADDR1 – Address register 1
z Bit 7:0 – ADDR[15:8]: Address Byte 1
This register gives the address high byte when accessing NVM locations.
4.13.3 ADDR2 – Address register 2
z Bit 7:0 – ADDR[23:16]: Address Byte 2
This register gives the address extended byte when accessing NVM locations.
4.13.4 DATA0 – Data register 0
The DATA0, DATA1, and DATA registers represent the 24-bit value, DATA. This holds data during NVM read, write, and
CRC access.
z Bit 7:0 – DATA[7:0]: Data Byte 0
This register gives the data value byte 0 when accessing NVM locations.
Bit 7 6 5 4 3 2 1 0
+0x00 ADDR[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 1 1 1 1 1 1 1 1
Bit 7 6 5 4 3 2 1 0
+0x01 ADDR[15:8]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
Bit 7 6 5 4 3 2 1 0
+0x02 ADDR[23:16]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
Bit 7 6 5 4 3 2 1 0
+0x04 DATA[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 27
Atmel-8291C-AVR-XMEGA B -09/2014
4.13.5 DATA1 – Data register 1
z Bit 7:0 – DATA[15:8]: Data Byte 1
This register gives the data value byte 1 when accessing NVM locations.
4.13.6 DATA2 – Data register 2
z Bit 7:0 – DATA[23:16]: Data Byte 2
This register gives the data value byte 2 when accessing NVM locations.
4.13.7 CMD – Command register
z Bit 7 – Reserved
This bit is unused and reserved for future use. For compatibility with future devices, always write this bit to zero when this
register is written.
z Bit 6:0 – CMD[6:0]: Command
These bits define the programming commands for the flash. Bit 6 is only set for external programming commands. See
“Memory Programming” on page 375” for programming commands.
4.13.8 CTRLA – Control register A
z Bit 7:1 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 0 – CMDEX: Command Execute
Setting this bit will execute the command in the CMD register. This bit is protected by the configuration change protection
(CCP) mechanism. Refer to “Configuration Change Protection” on page 13 for details on the CCP.
Bit 7 6 5 4 3 2 1 0
+0x05 DATA[15:8]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
Bit 7 6 5 4 3 2 1 0
+0x06 DATA[23:16]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
Bit 7 6 5 4 3 2 1 0
+0x0A – CMD[6:0]
Read/Write R R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
Bit 7 6 5 4 3 2 1 0
+0x0B – – – – – – – CMDEX
Read/Write R RRRRRRS
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 28
Atmel-8291C-AVR-XMEGA B -09/2014
4.13.9 CTRLB – Control register B
z Bit 7:4 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 3 – EEMAPEN: EEPROM Data Memory Mapping Enable
Setting this bit enables data memory mapping of the EEPROM section. The EEPROM can then be accessed using load
and store instructions.
z Bit 2 – FPRM: Flash Power Reduction Mode
Setting this bit enables power saving for the flash memory. If code is running from the application section, the boot loader
section will be turned off, and vice versa. If access to the section that is turned off is required, the CPU will be halted for
a time equal to the start-up time from the idle sleep mode.
z Bit 1 – EPRM: EEPROM Power Reduction Mode
Setting this bit enables power saving for the EEPROM. The EEPROM will then be turned off in a manner equal to
entering sleep mode. If access is required, the bus master will be halted for a time equal to the start-up time from idle
sleep mode.
z Bit 0 – SPMLOCK: SPM Locked
This bit can be written to prevent all further self-programming. The bit is cleared at reset, and cannot be cleared from
software. This bit is protected by the configuration change protection (CCP) mechanism. Refer to “Configuration Change
Protection” on page 13 for details on the CCP.
4.13.10 INTCTRL – Interrupt Control register
z Bit 7:4 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 3:2 – SPMLVL[1:0]: SPM Ready Interrupt Level
These bits enable the interrupt and select the interrupt level, as described in “Interrupts and Programmable Multilevel
Interrupt Controller” on page 115. This is a level interrupt that will be triggered only when the NVMBUSY flag in the
STATUS register is set to zero. Thus, the interrupt should not be enabled before triggering an NVM command, as the
NVMBUSY flag will not be set before the NVM command is triggered. The interrupt should be disabled in the interrupt
handler.
z Bit 1:0 – EELVL[1:0]: EEPROM Ready Interrupt Level
These bits enable the EEPROM ready interrupt and select the interrupt level, as described in “Interrupts and
Programmable Multilevel Interrupt Controller” on page 115. This is a level interrupt that will be triggered only when the
NVMBUSY flag in the STATUS register is set to zero. Thus, the interrupt should not be enabled before triggering an NVM
command, as the NVMBUSY flag will not be set before the NVM command is triggered. The interrupt should be disabled
in the interrupt handler.
Bit 7 6 5 4 3 2 1 0
+0x0C – – – – EEMAPEN FPRM EPRM SPMLOCK
Read/Write R R R R R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
Bit 7 6 5 4 3 2 1 0
+0x0D – – – – SPMLVL[1:0] EELVL[1:0]
Read/Write R R R R R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 29
Atmel-8291C-AVR-XMEGA B -09/2014
4.13.11 STATUS – Status register
z Bit 7 – NVMBUSY: Nonvolatile Memory Busy
The NVMBUSY flag indicates if the NVM (Flash, EEPROM, lock bit) is being programmed. Once an operation is started,
this flag is set and remains set until the operation is completed. The NVMBUSY flag is automatically cleared when the
operation is finished.
z Bit 6 – FBUSY: Flash Busy
The FBUSY flag indicates if a flash programming operation is initiated. Once an operation is started, the FBUSY flag is
set and the application section cannot be accessed. The FBUSY flag is automatically cleared when the operation is
finished.
z Bit 5:2 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 1 – EELOAD: EEPROM Page Buffer Active Loading
The EELOAD flag indicates that the temporary EEPROM page buffer has been loaded with one or more data bytes. It
remains set until an EEPROM page write or a page buffer flush operation is executed. For more details, see “Flash and
EEPROM Programming Sequences” on page 377.
z Bit 0 – FLOAD: Flash Page Buffer Active Loading
The FLOAD flag indicates that the temporary flash page buffer has been loaded with one or more data bytes. It remains
set until an application page write, boot page write, or page buffer flush operation is executed. For more details, see
“Flash and EEPROM Programming Sequences” on page 377.
4.13.12 LOCKBITS – Lock Bit register
This register is a mapping of the NVM lock bits into the I/O memory space, which enables direct read access from the
application software. Refer to “LOCKBITS – Lock Bit register” on page 33 for a description.
Bit 7 6 5 4 3 2 1 0
+0x04 NVMBUSY FBUSY – – – – EELOAD FLOAD
Read/Write R R RRRR R R
Initial Value 0 0 0 0 0 0 0 0
Bit 7 6 5 4 3 2 1 0
+0x07 BLBB[1:0] BLBA[1:0] BLBAT[1:0] LB[1:0]
Read/Write R R R RRRRR
Initial Value 11111111
XMEGA B [MANUAL] 30
Atmel-8291C-AVR-XMEGA B -09/2014
4.14 Register Descriptions – Fuses and Lock Bits
4.14.1 FUSEBYTE1 – Fuse Byte1
z Bit 7:4 – WDWPER[3:0]: Watchdog Window Timeout Period
These fuse bits are used to set initial value of the closed window for the Watchdog Timer in Window Mode. During reset
these fuse bits are automatically written to the WPER bits Watchdog Window Mode Control Register. Refer to “WINCTRL
– Window Mode Control register” on page 113 for details.
z Bit 3:0 – WDPER[3:0]: Watchdog Timeout Period
These fuse bits are used to set the initial value of the watchdog timeout period. During reset these fuse bits are
automatically written to the PER bits in the watchdog control register. Refer to “CTRL – Control register” on page 112 for
details.
4.14.2 FUSEBYTE2 – Fuse Byte2
z Bit 7 – Reserved
This bit is unused and reserved for future use. For compatibility with future devices, always write this bit to one when this
register is written.
z Bit 6 – BOOTRST: Boot Loader Section Reset Vector
This fuse can be programmed so the reset vector is pointing to the first address in the boot loader flash section. The
device will then start executing from the boot loader flash section after reset.
Table 4-1. Boot reset fuse.
z Bit 5 – TOSCSEL: 32.768kHz Timer Oscillator Pin Selection
This fuse is used to select the pin location for the 32.768kHz timer oscillator (TOSC). This fuse is available only on
devices where XTAL and TOSC pins by default are shared.
Bit 7 6 5 4 3 2 1 0
+0x01 WDWPER[3:0] WDPER[3:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
Bit 7 6 5 4 3 2 1 0
+0x02 – BOOTRST TOSCSEL – – – BODPD[1:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 1 1 1 1 1 1 1 1
BOOSTRST Reset address
0 Reset vector = Boot loader reset
1 Reset vector = Application reset (address 0x0000)
XMEGA B [MANUAL] 31
Atmel-8291C-AVR-XMEGA B -09/2014
Table 4-2. TOSCSEL fuse.
Note: 1. See the device datasheet for alternate TOSC position.
z Bit 4:2 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to one
when this register is written.
z Bit 1:0 – BODPD[1:0]: BOD Operation in Power-down Mode
These fuse bits set the BOD operation mode in all sleep modes except idle mode.
For details on the BOD and BOD operation modes, refer to “Brownout Detection” on page 104.
Table 4-3. BOD operation modes in sleep modes.
4.14.3 FUSEBYTE4 – Fuse Byte4
z Bit 7:5 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to one
when this register is written.
z Bit: 4 – RSTDISBL: External Reset Disable
This fuse can be programmed to disable the external reset pin functionality. When this is done, pulling the reset pin low
will not cause an external reset. A reset is required before this bit will be read correctly after it is changed.
z Bit 3:2 – STARTUPTIME[1:0]: Start-up time
These fuse bits can be used to set at a programmable timeout period from when all reset sources are released until the
internal reset is released from the delay counter. A reset is required before these bits will be read correctly after they are
changed.
The delay is timed from the 1kHz output of the ULP oscillator. Refer to “Reset Sequence” on page 103 for details.
TOSCSEL Group configuration Description
0 ALTERNATE(1) TOSC1/2 on separate pins
1 XTAL TOSC1/2 shared with XTAL
BODPD[1:0] Description
00 Reserved
01 BOD enabled in sampled mode
10 BOD enabled continuously
11 BOD disabled
Bit 7 6 5 4 3 2 1 0
+0x04 – – – RSTDISBL STARTUPTIME[1:0] WDLOCK –
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 1 1 1 1 1 1 1 1
XMEGA B [MANUAL] 32
Atmel-8291C-AVR-XMEGA B -09/2014
Table 4-4. Start-up time
z Bit 1 – WDLOCK: Watchdog Timer Lock
The WDLOCK fuse can be programmed to lock the watchdog timer configuration. When this fuse is programmed, the
watchdog timer configuration cannot be changed, and the ENABLE bit in the watchdog CTRL register is automatically set
at reset and cannot be cleared from the application software. The WEN bit in the watchdog WINCTRL register is not set
automatically, and needs to be set from software. A reset is required before this bit will be read correctly after it is
changed.
Table 4-5. Watchdog timer lock
z Bit 0 – Reserved
This bit is unused and reserved for future use. For compatibility with future devices, always write this bit to one when this
register is written.
4.14.4 FUSEBYTE5 – Fuse Byte 5
z Bit 7:6 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to one
when this register is written.
z Bit 5:4 – BODACT[1:0]: BOD Operation in Active Mode
These fuse bits set the BOD operation mode when the device is in active and idle modes. For details on the BOD and
BOD operation modes. Refer to “Brownout Detection” on page 104.
Table 4-6. BOD operation modes in active and idle modes
STARTUPTIME[1:0 1kHz ULP oscillator cycles
00 64
01 4
10 Reserved
11 0
WDLOCK Description
0 Watchdog timer locked for modifications
1 Watchdog timer not locked
Bit 7 6 5 4 3 2 1 0
+0x05 – – BODACT[1:0] EESAVE BODLEVEL[2:0]
Read/Write R R R/W R/W R/W R/W R/W R/W
Initial Value 1 1 – – – – – –
BODACT[1:0] Description
00 Reserved
01 BOD enabled in sampled mode
10 BOD enabled continuously
11 BOD disabled
XMEGA B [MANUAL] 33
Atmel-8291C-AVR-XMEGA B -09/2014
z Bit 3 – EESAVE: EEPROM is Preserved through the Chip Erase
A chip erase command will normally erase the flash, EEPROM, and internal SRAM. If this fuse is programmed, the
EEPROM is not erased during chip erase. This is useful if EEPROM is used to store data independently of the software
revision.
Table 4-7. EEPROM preserved through chip erase
Changes to the EESAVE fuse bit take effect immediately after the write timeout elapses. Hence, it is possible to update
EESAVE and perform a chip erase according to the new setting of EESAVE without leaving and reentering programming
mode.
z Bit 2:0 – BODLEVEL[2:0]: Brownout Detection Voltage Level
These fuse bits sets the BOD voltage level. Refer to “Reset System” on page 102 for details. For BOD level nominal
values, see Table 9-2 on page 105.
4.14.5 LOCKBITS – Lock Bit register
z Bit 7:6 – BLBB[1:0]: Boot Lock Bit Boot Loader Section
These lock bits control the software security level for accessing the boot loader section. The BLBB bits can only be
written to a more strict locking. Resetting the BLBB bits is possible by executing a chip erase command.
Table 4-8. Boot lock bit for the boot loader section
EESAVE Description
0 EEPROM is preserved during chip erase
1 EEPROM is erased during chip erase
Bit 7 6 5 4 3 2 1 0
+0x07 BLBB[1:0] BLBA[1:0] BLBAT[1:0] LB[1:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 1 1 1 1 1 1 1 1
BLBB[1:0] Group Configuration Description
11 NOLOCK No lock – no restrictions for SPM and (E)LPM accessing the boot
loader section.
10 WLOCK Write lock – SPM is not allowed to write the boot loader section.
01 RLOCK
Read lock – (E)LPM executing from the application section is not
allowed to read from the boot loader section.
If the interrupt vectors are placed in the application section,
interrupts are disabled while executing from the boot loader
section.
00 RWLOCK
Read and write lock – SPM is not allowed to write to the boot loader
section, and (E)LPM executing from the application section is not
allowed to read from the boot loader section.
If the interrupt vectors are placed in the application section,
interrupts are disabled while executing from the boot loader
section.
XMEGA B [MANUAL] 34
Atmel-8291C-AVR-XMEGA B -09/2014
z Bit 5:4 – BLBA[1:0]: Boot Lock Bit Application Section
These lock bits control the software security level for accessing the application section according to Table 4-9 on page
34. The BLBA bits can only be written to a more strict locking. Resetting the BLBA bits is possible only by executing a
chip erase command.
Table 4-9. Boot lock bit for the application section
z Bit 3:2 – BLBAT[1:0]: Boot Lock Bit Application Table Section
These lock bits control the software security level for accessing the application table section for software access. The
BLBAT bits can only be written to a more strict locking. Resetting the BLBAT bits is possible only by executing a chip
erase command.
Table 4-10. Boot lock bit for the application table section
z Bit 1:0 – LB[1:0]: Lock Bits(1)
These lock bits control the security level for the flash and EEPROM during external programming. These bits are writable
only through an external programming interface. Resetting the lock bits is possible only by executing a chip erase
BLBA[1:0] Group Configuration Description
11 NOLOCK No Lock - no restrictions for SPM and (E)LPM accessing the
application section.
10 WLOCK Write lock – SPM is not allowed to write the application section.
01 RLOCK
Read lock – (E)LPM executing from the boot loader section is not
allowed to read from the application section.
If the interrupt vectors are placed in the boot loader section,
interrupts are disabled while executing from the application section.
00 RWLOCK
Read and write lock – SPM is not allowed to write to the application
section, and (E)LPM executing from the boot loader section is not
allowed to read from the application section.
If the interrupt vectors are placed in the boot loader section,
interrupts are disabled while executing from the application section.
BLBAT[1:0] Group Configuration Description
11 NOLOCK No lock – no restrictions for SPM and (E)LPM accessing the
application table section.
10 WLOCK Write lock – SPM is not allowed to write the application table
01 RLOCK
Read lock – (E)LPM executing from the boot loader section is not
allowed to read from the application table section.
If the interrupt vectors are placed in the boot loader section,
interrupts are disabled while executing from the application
section.
00 RWLOCK
Read and write lock – SPM is not allowed to write to the
application table section, and (E)LPM executing from the boot
loader section is not allowed to read from the application table
section.
If the interrupt vectors are placed in the boot loader section,
interrupts are disabled while executing from the application
section.
XMEGA B [MANUAL] 35
Atmel-8291C-AVR-XMEGA B -09/2014
command. All other access; using the TIF and OCD, is blocked if any of the Lock Bits are written to 0. These bits do not
block any software access to the memory.
Table 4-11. Lock bit protection mode.
Note: 1. Program the Fuse Bits and Boot Lock Bits before programming the Lock Bits.
LB[1:0] Group Configuration Description
11 NOLOCK3 No lock – no memory locks enabled.
10 WLOCK
Write lock – programming of the flash and EEPROM is disabled for
the programming interface. Fuse bits are locked for write from the
programming interface.
00 RWLOCK
Read and write lock – programming and read/verification of the
flash and EEPROM are disabled for the programming interface.
The lock bits and fuses are locked for read and write from the
programming interface.
XMEGA B [MANUAL] 36
Atmel-8291C-AVR-XMEGA B -09/2014
4.15 Register Description – Production Signature Row
4.15.1 RCOSC2M – Internal 2MHz Oscillator Calibration register
z Bit 7:0 – RCOSC2M[7:0]: Internal 2MHz Oscillator Calibration Value
This byte contains the oscillator calibration value for the internal 2MHz oscillator. Calibration of the oscillator is performed
during production test of the device. During reset this value is automatically loaded into calibration register B for the
2MHz DFLL. Refer to “CALB – DFLL Calibration register B” on page 92 for more details.
4.15.2 RCOSC2MA – Internal 2MHz Oscillator Calibration register
z Bit 7:0 – RCOSC2MA[7:0]: Internal 2MHz Oscillator Calibration Value
This byte contains the oscillator calibration value for the internal 2MHz oscillator. Calibration of the oscillator is performed
during production test of the device. During reset this value is automatically loaded into calibration register A for the
2MHz DFLL. Refer to “CALA – DFLL Calibration Register A” on page 92 for more details.
4.15.3 RCOSC32K – Internal 32.768kHz Oscillator Calibration register
z Bit 7:0 – RCOSC32K[7:0]: Internal 32.768kHz Oscillator Calibration Value
This byte contains the oscillator calibration value for the internal 32.768kHz oscillator. Calibration of the oscillator is
performed during production test of the device. During reset this value is automatically loaded into the calibration register
for the 32.768kHz oscillator. Refer to “RC32KCAL – 32kHz Oscillator Calibration register” on page 90 for more details.
4.15.4 RCOSC32M – Internal 32MHz Oscillator Calibration register
z Bit 7:0 – RCOSC32M[7:0]: Internal 32MHz Oscillator Calibration Value
This byte contains the oscillator calibration value for the internal 32MHz oscillator. Calibration of the oscillator is
performed during production test of the device. During reset this value is automatically loaded into calibration register B
for the 32MHz DFLL. Refer to “CALB – DFLL Calibration register B” on page 92 for more details.
Bit 7 6 5 4 3 2 1 0
0x00 RCOSC2M[7:0]
Read/Write R R R R R R R R
Initial Value x x x x x x x x
Bit 7 6 5 4 3 2 1 0
0x01 RCOSC2MA[7:0]
Read/Write R R R R R R R R
Initial Value x x x x x x x x
Bit 7 6 5 4 3 2 1 0
0x02 RCOSC32K[7:0]
Read/Write RRRR R R R R
Initial Value x x x x x x x x
Bit 7 6 5 4 3 2 1 0
0x03 RCOSC32M[7:0]
Read/Write RRRR R R R R
Initial Value x x x x x x x x
XMEGA B [MANUAL] 37
Atmel-8291C-AVR-XMEGA B -09/2014
4.15.5 RCOSC32MA – Internal 32MHz RC Oscillator Calibration register
z Bit 7:0 – RCOSC32MA[7:0]: Internal 32MHz Oscillator Calibration Value
This byte contains the oscillator calibration value for the internal 32MHz oscillator. Calibration of the oscillator is
performed during production test of the device. During reset this value is automatically loaded into calibration register A
for the 32MHz DFLL. Refer to “CALA – DFLL Calibration Register A” on page 92 for more details.
4.15.6 LOTNUM0 – Lot Number register 0
LOTNUM0, LOTNUM1, LOTNUM2, LOTNUM3, LOTNUM4 and LOTNUM5 contain the lot number for each device.
Together with the wafer number and wafer coordinates this gives a serial number for the device.
z Bit 7:0 – LOTNUM0[7:0]: Lot Number Byte 0
This byte contains byte 0 of the lot number for the device.
4.15.7 LOTNUM1 – Lot Number register 1
z Bit 7:0 – LOTNUM1[7:0]: Lot Number Byte 1
This byte contains byte 1 of the lot number for the device.
4.15.8 LOTNUM2 – Lot Number Register 2
z Bit 7:0 – LOTNUM2[7:0]: Lot Number Byte 2
This byte contains byte 2 of the lot number for the device.
Bit 7 6 5 4 3 2 1 0
0x04 RCOSC32MA[7:0]
Read/Write R R R R R R R R
Initial Value x x x x x x x x
Bit 7 6 5 4 3 2 1 0
0x08 LOTNUM0[7:0]
Read/Write R R R R R R R R
Initial Value x x x x x x x x
Bit 7 6 5 4 3 2 1 0
0x09 LOTNUM1[7:0]
Read/Write R R R R R R R R
Initial Value x x x x x x x x
Bit 7 6 5 4 3 2 1 0
0x0A LOTNUM2[7:0]
Read/Write R R R R R R R R
Initial Value x x x x x x x x
XMEGA B [MANUAL] 38
Atmel-8291C-AVR-XMEGA B -09/2014
4.15.9 LOTNUM3 – Lot Number register 3
z Bit 7:0 – LOTNUM3[7:0]: Lot Number Byte 3
This byte contains byte 3 of the lot number for the device.
4.15.10 LOTNUM4 – Lot Number register 4
z Bit 7:0 – LOTNUM4[7:0]: Lot Number Byte 4
This byte contains byte 4 of the lot number for the device.
4.15.11 LOTNUM5 – Lot Number register 5
z Bit 7:0 – LOTNUM5[7:0]: Lot Number Byte 5
This byte contains byte 5 of the lot number for the device.
4.15.12 WAFNUM – Wafer Number register
z Bit 7:0 – WAFNUM[7:0]: Wafer Number
This byte contains the wafer number for each device. Together with the lot number and wafer coordinates this gives a
serial number for the device.
Bit 7 6 5 4 3 2 1 0
0x0B LOTNUM3[7:0]
Read/Write R R R R R R R R
Initial Value x x x x x x x x
Bit 7 6 5 4 3 2 1 0
0x0C LOTNUM4[7:0]
Read/Write RRRR R R R R
Initial Value x x x x x x x x
Bit 7 6 5 4 3 2 1 0
0x0D LOTNUM5[7:0]
Read/Write R R R R R R R R
Initial Value x x x x x x x x
Bit 7 6 5 4 3 2 1 0
0x10 WAFNUM[7:0]
Read/Write R R R R R R R R
Initial Value 0 0 0 x x x x x
XMEGA B [MANUAL] 39
Atmel-8291C-AVR-XMEGA B -09/2014
4.15.13 COORDX0 – Wafer Coordinate X register 0
COORDX0, COORDX1, COORDY0 and COORDY1 contain the wafer X and Y coordinates for each device. Together
with the lot number and wafer number, this gives a serial number for each device.
z Bit 7:0 – COORDX0[7:0]: Wafer Coordinate X Byte 0
This byte contains byte 0 of wafer coordinate X for the device.
4.15.14 COORDX1 – Wafer Coordinate X register 1
z Bit 7:0 – COORDX0[7:0]: Wafer Coordinate X Byte 1
This byte contains byte 1 of wafer coordinate X for the device.
4.15.15 COORDY0 – Wafer Coordinate Y register 0
z Bit 7:0 – COORDY0[7:0]: Wafer Coordinate Y Byte 0
This byte contains byte 0 of wafer coordinate Y for the device.
4.15.16 COORDY1 – Wafer Coordinate Y register 1
z Bit 7:0 – COORDY1[7:0]: Wafer Coordinate Y Byte 1
This byte contains byte 1 of wafer coordinate Y for the device.
Bit 7 6 5 4 3 2 1 0
0x12 COORDX0[7:0]
Read/Write RRRR R R R R
Initial Value x x x x x x x x
Bit 7 6 5 4 3 2 1 0
0x13 COORDX1[7:0]
Read/Write R R R R R R R R
Initial Value x x x x x x x x
Bit 7 6 5 4 3 2 1 0
0x14 COORDY0[7:0]
Read/Write R R R R R R R R
Initial Value x x x x x x x x
Bit 7 6 5 4 3 2 1 0
0x15 COORDY1[7:0]
Read/Write R R R R R R R R
Initial Value x x x x x x x x
XMEGA B [MANUAL] 40
Atmel-8291C-AVR-XMEGA B -09/2014
4.15.17 USBCAL0 – USB Calibration register 0
USBCAL0 and USBCAL1 contain the calibration value for the USB pins. Calibration is done during production to enable
operation without requiring external components on the USB lines for the device. The calibration bytes are not loaded
automatically into the USB calibration registers, and so this must be done from software.
z Bit 7:0 – USBCAL0[7:0]: USB Pad Calibration byte 0
This byte contains byte 0 of the USB pin calibration data, and must be loaded into the USB CALL register.
4.15.18 USBCAL1 – USB Pad Calibration register 1
z Bit 7:0 – USBCAL1[7:0]: USB Pad Calibration byte 1
This byte contains byte 1 of the USB pin calibration data, and must be loaded into the USB CALH register.
4.15.19 USBRCOSC – USB RCOSC Calibration
z Bit 7:0 – USBRCOSC[7:0]: 48MHz RSCOSC Calibration
This byte contains a 48MHz calibration value for the internal 32MHz oscillator. When this calibration value is written to
calibration register B for the 32MHz DFLL, the oscillator is calibrated to 48MHz to enable full-speed USB operation from
internal oscillator.
Note: The COMP2 and COMP1 registers inside the DFLL32M must be set to B71B.
4.15.20 ADCACAL0 – ADCA Calibration register 0
ADCACAL0 and ADCACAL1 contain the calibration value for the analog to digital converter A (ADCA). Calibration is
done during production test of the device. The calibration bytes are not loaded automatically into the ADC calibration
registers, so this must be done from software.
z Bit 7:0 – ADCACAL0[7:0]: ADCA Calibration Byte 0
This byte contains byte 0 of the ADCA calibration data, and must be loaded into the ADCA CALL register.
Bit 7 6 5 4 3 2 1 0
0x1A USBCAL0[7:0]
Read/Write RRRR R R R R
Initial Value x x x x x x x x
Bit 7 6 5 4 3 2 1 0
0x1B USBCAL1[7:0]
Read/Write RRRR R R R R
Initial Value xxxx x x x x
Bit 7 6 5 4 3 2 1 0
0x1C USBRCOSC[7:0]
Read/Write RRRR R R R R
Initial Value x x x x x x x x
Bit 7 6 5 4 3 2 1 0
0x20 ADCACAL0[7:0]
Read/Write RRRR R R R R
Initial Value xxxx x x x x
XMEGA B [MANUAL] 41
Atmel-8291C-AVR-XMEGA B -09/2014
4.15.21 ADCACAL1 – ADCA Calibration register 1
z Bit 7:0 – ADCACAL1[7:0]: ADCA Calibration Byte 1
This byte contains byte 1 of the ADCA calibration data, and must be loaded into the ADCA CALH register.
4.15.22 TEMPSENSE0 – Temperature Sensor Calibration register 0
TEMPSENSE0 and TEMPSENSE1 contain the 12-bit ADCA value from a temperature measurement done with the
internal temperature sensor. The measurement is done in production test at 85°C and can be used for single- or multipoint
temperature sensor calibration.
z Bit 7:0 – TEMPSENSE0[7:0]: Temperature Sensor Calibration Byte 0
This byte contains the byte 0 of the temperature measurement.
4.15.23 TEMPSENSE1 – Temperature Sensor Calibration register 1
z Bit 7:0 – TEMPSENSE1[7:0]: Temperature Sensor Calibration Byte 1
This byte contains byte 1 of the temperature measurement.
Bit 7 6 5 4 3 2 1 0
0x21 ADCACAL1[7:0]
Read/Write RRRR R R R R
Initial Value x x x x x x x x
Bit 7 6 5 4 3 2 1 0
0x2E TEMPSENSE0[7:0]
Read/Write R R R R R R R R
Initial Value x x x x x x x x
Bit 7 6 5 4 3 2 1 0
0x2F TEMPSENSE1[7:0]
Read/Write R R R R R R R R
Initial Value 0 0 0 0 x x x x
XMEGA B [MANUAL] 42
Atmel-8291C-AVR-XMEGA B -09/2014
4.16 Register Description – General Purpose I/O Memory
4.16.1 GPIORn – General Purpose I/O register n
These are general purpose registers that can be used to store data, such as global variables and flags, in the bitaccessible
I/O memory space.
4.17 Register Descriptions – MCU Control
4.17.1 DEVID0 – Device ID register 0
DEVID0, DEVID1 and DEVID2 contain the byte identification that identifies each microcontroller device type. For details
on the actual ID, refer to the device datasheets.
z Bit 7:0 – DEVID0[7:0]: Device ID Byte 0
Byte 0 of the device ID. This byte will always be read as 0x1E. This indicates that the device is manufactured by Atmel.
4.17.2 DEVID1 – Device ID register 1
z Bit 7:0 – DEVID[7:0]: Device ID Byte 1
Byte 1 of the device ID indicates the flash size of the device.
4.17.3 DEVID2 – Device ID register 2
z Bit 7:0 – DEVID2[7:0]: Device ID Byte 2
Byte 2 of the device ID indicates the device number.
Bit 7 6 5 4 3 2 1 0
+n GPIORn[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 00000
Bit 7 6 5 4 3 2 1 0
+0x00 DEVID0[7:0]
Read/Write R R RRRRRR
Initial Value 00011110
Bit 7 6 5 4 3 2 1 0
+0x01 DEVID1[7:0]
Read/Write R R RRRRRR
Initial Value 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0
Bit 7 6 5 4 3 2 1 0
+0x02 DEVID2[7:0]
Read/Write R R RRRRRR
Initial Value 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0
XMEGA B [MANUAL] 43
Atmel-8291C-AVR-XMEGA B -09/2014
4.17.4 REVID – Revision ID
z Bit 7:4 – Reserved
These bits are unused and reserved for future use.
z Bit 3:0 – REVID[3:0]: Revision ID
These bits contains the device revision. 0 = A, 1 = B, and so on.
4.17.5 ANAINIT – Analog Initialization register
z Bit 7:2 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 1:0 – STARTUPDLYx
Setting these bits enables sequential start of the internal components used for the ADC, DAC, and analog comparator
with the main input/output connected to that port. When this is done, the internal components such as voltage reference
and bias currents are started sequentially when the module is enabled. This reduces the peak current consumption
during startup of the module. For maximum effect, the start-up delay should be set so that it is larger than 0.5μs.
Table 4-12. Analog start-up delay
4.17.6 EVSYSLOCK – Event System Lock register
z Bit 7:1 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
Bit 7 6 5 4 3 2 1 0
+0x03 – – – – REVID[3:0]
Read/Write R RRRRRRR
Initial Value 0 0 0 0 1/0 1/0 1/0 1/0
Bit 7 6 5 4 3 2 1 0
+0x07 – – – – – – STARTUPDLYA[1:0]
Read/Write R R R R R R R/W R/W
Initial Value 0 0 0 00000
STARTUPDLYx Group Configuration Description
00 NONE Direct startup
11 2CLK 2 * CLKPER
10 8CLK 8 * CLKPER
11 32CLK 32 * CLKPER
Bit 7 6 5 4 3 2 1 0
+0x08 – – – – – – – EVSYS0LOCK
Read/Write R R R R R R R R/W
Initial Value 0 0 0 0000 0
XMEGA B [MANUAL] 44
Atmel-8291C-AVR-XMEGA B -09/2014
z Bit 0 – EVSYS0LOCK:
Setting this bit will lock all registers in the event system related to event channels 0 to 3 against further modification. The
following registers in the event system are locked: CH0MUX, CH0CTRL, CH1MUX, CH1CTRL, CH2MUX, CH2CTRL,
CH3MUX, and CH3CTRL. This bit is protected by the configuration change protection mechanism. For details, refer to
“Configuration Change Protection” on page 13.
4.17.7 AWEXLOCK – Advanced Waveform Extension Lock register
z Bit 7:1 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 0 – AWEXCLOCK: Advanced Waveform Extension Lock for TCC0
Setting this bit will lock all registers in the AWEXC module for timer/counter C0 for against further modification. This bit is
protected by the configuration change protection mechanism. For details, refer to “Configuration Change Protection” on
page 13.
Bit 7 6 5 4 3 2 1 0
+0x09 – – – – – – – AWEXCLOCK
Read/Write R R R R R R R R/W
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 45
Atmel-8291C-AVR-XMEGA B -09/2014
4.18 Register Summary - NVM Controller
4.19 Register Summary - Fuses and Lock Bits
4.20 Register Summary - Production Signature Row
Address Name Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 Page
+0x00 ADDR0 Address Byte 0 25
+0x01 ADDR1 Address Byte 1 25
+0x02 ADDR2 Address Byte 2 25
+0x03 Reserved – – – – – – – –
+0x04 DATA0 Data Byte 0 26
+0x05 DATA1 Data Byte 1 26
+0x06 DATA2 Data Byte 2 26
+0x07 Reserved – – – – – – – –
+0x08 Reserved – – – – – – – –
+0x09 Reserved – – – – – – – –
+0x0A CMD – CMD[6:0] 26
+0x0B CTRLA – – – – – – – CMDEX 27
+0x0C CTRLB – – – – EEMAPEN FPRM EPRM SPMLOCK 27
+0x0D INTCTRL – – – – SPMLVL[1:0] EELVL[1:0] 28
+0x0E Reserved – – – – – – – –
+0x0F STATUS NVMBUSY FBUSY – – – – EELOAD FLOAD 28
+0x10 LOCKBITS BLBB[1:0] BLBA[1:0] BLBAT[1:0] LB[1:0] 29
Address Name Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 Page
+0x00 Reserved – – – – – – – –
+0x01 FUSEBYTE1 WDWPER3:0] WDPER[3:0] 30
+0x02 FUSEBYTE2 – BOOTRST TOSCSEL – – – BODPD[1:0] 30
+0x03 Reserved – – – – – – – –
+0x04 FUSEBYTE4 – – – RSTDISBL STARTUPTIME[1:0] WDLOCK – 31
+0x05 FUSEBYTE5 – – BODACT[1:0] EESAVE BODLEVEL[2:0] 32
+0x06 Reserved – – – – – – – –
+0x07 LOCKBITS BLBB[1:0] BLBA[1:0] BLBAT[1:0] LB[1:0] 34
Address Auto Load Name Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 Page
0x00 YES RCOSC2M RCOSC2M[7:0] 36
0x01 YES RCOSC2MA RCOSC2MA[7:0] 37
0x02 YES RCOSC32K RCOSC32K[7:0] 36
0x03 YES RCOSC32M RCOSC32M[7:0] 36
0x04 YES RCOSC32MA RCOSC32MA[7:0] 37
0x05 Reserved – – – – – – – –
0x06 Reserved – – – – – – – –
0x07 Reserved – – – – – – – –
0x08 NO LOTNUM0 LOTNUM0[7:0] 37
0x09 NO LOTNUM1 LOTNUM1[7:0] 37
0x0A NO LOTNUM2 LOTNUM2[7:0] 37
0x0B NO LOTNUM3 LOTNUM3[7:0] 38
0x0C NO LOTNUM4 LOTNUM4[7:0] 38
0x0D NO LOTNUM5 LOTNUM5[7:0] 38
0x0E Reserved – – – – – – – –
0x0F Reserved – – – – – – – –
0x10 NO WAFNUM WAFNUM[7:0] 38
0x11 Reserved – – – – – – – –
0x12 NO COORDX0 COORDX0[7:0] 39
0x13 NO COORDX1 COORDX1[7:0] 39
0x14 NO COORDY0 COORDY0[7:0] 39
0x15 NO COORDY1 COORDY1[7:0] 39
0x16 Reserved – – – – – – – –
0x17 Reserved – – – – – – – –
0x18 Reserved – – – – – – – –
0x19 Reserved – – – – – – – –
0x1A USBCAL0 USBCAL0[7:0] 40
0x1B USBCAL1 USBCAL1[7:0] 40
0x1C USBRCOSC USBRCOSC[7:0] 40
XMEGA B [MANUAL] 46
Atmel-8291C-AVR-XMEGA B -09/2014
4.21 Register Summary – General Purpose I/O Registers
4.22 Register Summary – MCU Control
4.23 Interrupt Vector Summary – NVM Controller
0x1D Reserved – – – – – – – –
0x0E Reserved – – – – – – – –
0x1E Reserved – – – – – – – –
0x20 NO ADCACAL0 ADCACAL0[7:0] 40
0x21 NO ADCACAL1 ADCACAL1{7:0] 41
0x22 Reserved – – – – – – – –
0x23 Reserved – – – – – – – –
0x24 Reserved – – – – – – – –
0x25 Reserved – – – – – – – –
0x26 Reserved – – – – – – – –
0x27 Reserved – – – – – – – –
0x28 Reserved – – – – – – – –
0x29 Reserved – – – – – – – –
0x2A Reserved – – – – – – – –
0x2B Reserved – – – – – – – –
0x2C Reserved – – – – – – – –
0x2D Reserved – – – – – – – –
0x2E NO TEMPSENSE0 TEMPSENSE0[7:0] 41
0x2F NO TEMPSENSE1 – – – – TEMPSENSE1[11:8] 41
0x38 Reserved – – – – – – – –
0x39 Reserved – – – – – – – –
0x3A Reserved – – – – – – – –
0x3B Reserved – – – – – – – –
0x3C Reserved – – – – – – – –
0x3D Reserved – – – – – – – –
0x3E Reserved – – – – – – – –
Address Auto Load Name Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 Page
Address Name Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 Page
+0x00 GPIOR0 GPIOR[7:0] 42
+0x01 GPIOR1 GPIOR[7:0] 42
+0x02 GPIOR2 GPIOR[7:0] 42
+0x03 GPIOR3 GPIOR[7:0] 42
Address Name Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 Page
+0x00 DEVID0 DEVID0[7:0] 42
+0x01 DEVID1 DEVID1[7:0] 42
+0x02 DEVID2 DEVID2[7:0] 42
+0x03 REVID – – – – REVID[3:0] 43
+0x04 Reserved – – – – – – – –
+0x05 Reserved – – – – – – – –
+0x06 Reserved – – – – – – – –
+0x07 ANAINIT – – – – STARTUPDLYB[1:0] STARTUPDLYA[1:0] 43
+0x08 EVSYSLOCK – – – – – – – EVSYS0LOC 43
+0x09 AWEXLOCK – – – – – – – AWEXCLOCK 44
+0x0A Reserved – – – – – – – –
+0x0B Reserved – – – – – – – –
Offset Source Interrupt Description
0x00 EE_vect Nonvolatile memory EEPROM interrupt vector
0x02 SPM_vect Nonvolatile memory SPM interrupt vector
XMEGA B [MANUAL] 47
8291C–AVR–09/2014
5. DMAC - Direct Memory Access Controller
5.1 Features
z Allows high speed data transfers with minimal CPU intervention
z from data memory to data memory
z from data memory to peripheral
z from peripheral to data memory
z from peripheral to peripheral
z Two DMA channels with separate
z transfer triggers
z interrupt vectors
z addressing modes
z Programmable channel priority
z From 1 byte to 16MB of data in a single transaction
z Up to 64KB block transfers with repeat
z 1, 2, 4, or 8 byte burst transfers
z Multiple addressing modes
z Static
z Incremental
z Decremental
z Optional reload of source and destination addresses at the end of each
z Burst
z Block
z Transaction
z Optional interrupt on end of transaction
z Optional connection to CRC generator for CRC on DMA data
5.2 Overview
The two-channel direct memory access (DMA) controller can transfer data between memories and peripherals, and thus
offload these tasks from the CPU. It enables high data transfer rates with minimum CPU intervention, and frees up CPU
time. The two DMA channels enable up to two independent and parallel transfers.
The DMA controller can move data between SRAM and peripherals, between SRAM locations and directly between
peripheral registers. With access to all peripherals, the DMA controller can handle automatic transfer of data to/from
communication modules. The DMA controller can also read from memory mapped EEPROM.
Data transfers are done in continuous bursts of 1, 2, 4, or 8 bytes. They build block transfers of configurable size from 1
byte to 64KB. A repeat counter can be used to repeat each block transfer for single transactions up to 16MB. Source and
destination addressing can be static, incremental or decremental. Automatic reload of source and/or destination
addresses can be done after each burst or block transfer, or when a transaction is complete. Application software,
peripherals, and events can trigger DMA transfers.
The two DMA channels have individual configuration and control settings. This include source, destination, transfer
triggers, and transaction sizes. They have individual interrupt settings. Interrupt requests can be generated when a
transaction is complete or when the DMA controller detects an error on a DMA channel.
To allow for continuous transfers, two channels can be interlinked so that the second takes over the transfer when the
first is finished, and vice versa.
XMEGA B [MANUAL] 48
8291C–AVR–09/2014
Figure 5-1. DMA Overview.
5.3 DMA Transaction
A complete DMA read and write operation between memories and/or peripherals is called a DMA transaction. A
transaction is done in data blocks, and the size of the transaction (number of bytes to transfer) is selectable from
software and controlled by the block size and repeat counter settings. Each block transfer is divided into smaller bursts.
5.3.1 Block Transfer and Repeat
The size of the block transfer is set by the block transfer count register, and can be anything from 1 byte to 64KB.
A repeat counter can be enabled to set a number of repeated block transfers before a transaction is complete. The
repeat is from 1 to 255, and an unlimited repeat count can be achieved by setting the repeat count to zero.
5.3.2 Burst Transfer
Since the AVR CPU and DMA controller use the same data buses, a block transfer is divided into smaller burst transfers.
The burst transfer is selectable to 1, 2, 4, or 8 bytes. This means that if the DMA acquires the data bus and a transfer
request is pending, it will occupy the bus until all bytes in the burst are transferred.
A bus arbiter controls when the DMA controller and the AVR CPU can use the bus. The CPU always has priority, and so
as long as the CPU requests access to the bus, any pending burst transfer must wait. The CPU requests bus access
when it executes an instruction that writes or reads data to SRAM, I/O memory, EEPROM or the external bus interface.
For more details on memory access bus arbitration, refer to “Data Memory” on page 22.
Figure 5-2. DMA transaction.
R/W Master port
Arbitration
BUF
Bus
matrix
Arbiter
Read
Write
Slave port
Read /
Write
CTRL
DMA Channel 1
DMA trigger /
Event
DMA Channel 0
SRCADDR
TRFCNT DESTADDR
TRIGSRC
REPCNT
Control Logic
Enable
Burst
CTRLA
CTRLB
XMEGA B [MANUAL] 49
8291C–AVR–09/2014
5.4 Transfer Triggers
DMA transfers can be started only when a DMA transfer request is detected. A transfer request can be triggered from
software, from an external trigger source (peripheral), or from an event. There are dedicated source trigger selections for
each DMA channel. The available trigger sources may vary from device to device, depending on the modules or
peripherals that exist in the device. Using a transfer trigger for a module or peripherals that does not exist will have no
effect. For a list of all transfer triggers, refer to “TRIGSRC – Trigger Source” on page 57.
By default, a trigger starts a block transfer operation. When the block transfer is complete, the channel is automatically
disabled. When enabled again, the channel will wait for the next block transfer trigger. It is possible to select the trigger to
start a burst transfer instead of a block transfer. This is called a single-shot transfer, and for each trigger only one burst is
transferred. When repeat mode is enabled, the next block transfer does not require a transfer trigger. It will start as soon
as the previous block is done.
If the trigger source generates a transfer request during an ongoing transfer, this will be kept pending, and the transfer
can start when the ongoing one is done. Only one pending transfer can be kept, and so if the trigger source generates
more transfer requests when one is already pending, these will be lost.
5.5 Addressing
The source and destination address for a DMA transfer can either be static or automatically incremented or
decremented, with individual selections for source and destination. When address increment or decrement is used, the
default behaviour is to update the address after each access. The original source and destination addresses are stored
by the DMA controller, and so the source and destination addresses can be individually configured to be reloaded at the
following points:
z End of each burst transfer
z End of each block transfer
z End of transaction
z Never reloaded
5.6 Priority Between Channels
If several channels request a data transfer at the same time, a priority scheme is available to determine which channel is
allowed to transfer data. Application software can decide whether one or more channels should have a fixed priority or if
a round robin scheme should be used. A round robin scheme means that the channel that last transferred data will have
the lowest priority.
5.7 Double Buffering
To allow for continuous transfer, two channels can be interlinked so that the second takes over the transfer when the first
is finished, and vice versa. This leaves time for the application to process the data transferred by the first channel,
prepare fresh data buffers, and set up the channel registers again while the second channel is working. This is referred to
as double buffering or chained transfers.
When double buffering is enabled for a channel pair, it is important that the two channels are configured with the same
repeat count. The block sizes need not be equal, but for most applications they should be, along with the rest of the
channel’s operation mode settings.
Note that the double buffering channel pairs are limited to channels 0 and 1 as the first pair and channels 2 and 3 as the
second pair. However, it is possible to have one pair operate in double buffered mode while the other is left unused or
operating independently.
5.8 Transfer Buffers
To avoid unnecessary bus loading when doing data transfer between memories with different access timing (for
example, I/O register and external memory), the DMA controller has a four-byte buffer. Two bytes will be read from the
source address and written to this buffer before a write to the destination is started.
XMEGA B [MANUAL] 50
8291C–AVR–09/2014
5.9 Error detection
The DMA controller can detect erroneous operation. Error conditions are detected individually for each DMA channel,
and the error conditions are:
z Write to memory mapped EEPROM locations
z Reading EEPROM when the EEPROM is off (sleep entered)
z DMA controller or a busy channel is disabled in software during a transfer
5.10 Software Reset
Both the DMA controller and a DMA channel can be reset from the user software. When the DMA controller is reset, all
registers associated with the DMA controller, including channels, are cleared. A software reset can be done only when
the DMA controller is disabled.
When a DMA channel is reset, all registers associated with the DMA channel are cleared. A software reset can be done
only when the DMA channel is disabled.
5.11 Protection
In order to ensure safe operation, some of the channel registers are protected during a transaction. When the DMA
channel busy flag (CHnBUSY) is set for a channel, the user can modify only the following registers and bits:
z CTRL register
z INTFLAGS register
z TEMP registers
z CHEN, CHRST, TRFREQ, and REPEAT bits of the channel CTRL register
z TRIGSRC register
5.12 Interrupts
The DMA controller can generate interrupts when an error is detected on a DMA channel or when a transaction is
complete for a DMA channel. Each DMA channel has a separate interrupt vector, and there are different interrupt flags
for error and transaction complete.
If repeat is not enabled, the transaction complete flag is set at the end of the block transfer. If unlimited repeat is enabled,
the transaction complete flag is also set at the end of each block transfer.
XMEGA B [MANUAL] 51
8291C–AVR–09/2014
5.13 Register Description – DMA Controller
5.13.1 CTRL – Control register
z Bit 7 – ENABLE: Enable
Setting this bit enables the DMA controller. If the DMA controller is enabled and this bit is written to zero, the ENABLE bit
is not cleared before the internal transfer buffer is empty, and the DMA data transfer is aborted.
z Bit 6 – RESET: Software Reset
Writing a one to RESET will be ignored as long as DMA is enabled (ENABLE = 1). This bit can be set only when the DMA
controller is disabled (ENABLE = 0).
z Bit 5:3 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 2 – DBUFMODE: Double Buffer Mode
This bit enables the double buffer mode.
z Bit 1 – Reserved
This bit is unused and reserved for future use. For compatibility with future devices, always write this bits to zero when
this register is written.
z Bit 0 – PRIMODE: Channel Priority Mode
This bit determines the internal channel priority according to Table 5-1.
Table 5-1. Channel priority settings
5.13.2 INTFLAGS – Interrupt Status register
z Bit 7:6 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
Bit 7 6 5 4 3 2 1 0
+0x00 ENABLE RESET – – – DBUFMODE – PRIMODE
Read/Write R/W R/W R R R R/W R R/W
Initial Value 0 0 0 0 0 0 0 0
PRIMODE Group Configuration Description
0 RR01 Round robin
1 CH01 Channel0 has priority
Bit 7 6 5 4 3 2 1 0
+0x03 – – CH1ERRIF CH0ERRIF – – CH1TRNFIF CH0TRNFIF
Read/Write R R R/W R/W R R R/W R/W
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 52
8291C–AVR–09/2014
z Bit 5:4 – CHnERRIF[1:0]: Channel n Error Interrupt Flag
If an error condition is detected on DMA channel n, the CHnERRIF flag will be set. Writing a one to this bit location will
clear the flag.
z Bit 3:2 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 1:0 – CHnTRNFIF[1:0]: Channel n Transaction Complete Interrupt Flag
When a transaction on channel n has been completed, the CHnTRFIF flag will be set. If unlimited repeat count is
enabled, this flag is read as one after each block transfer. Writing a one to this bit location will clear the flag.
5.13.3 STATUS – Status register
z Bit 7:6 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 5:4 – CHnBUSY[1:0]: Channel Busy
When channel n starts a DMA transaction, the CHnBUSY flag will be read as one. This flag is automatically cleared when
the DMA channel is disabled, when the channel n transaction complete interrupt flag is set, or if the DMA channel n error
interrupt flag is set.
z Bit 3:2 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written
z Bit 1:0 – CHnPEND[1:0]: Channel Pending
If a block transfer is pending on DMA channel n, the CHnPEND flag will be read as one. This flag is automatically cleared
when the block transfer starts or if the transfer is aborted.
5.13.4 TEMPL – Temporary register Low
z Bit 7:0 – TEMP[7:0]: Temporary register 0
This register is used when reading 16- and 24-bit registers in the DMA controller. Byte 1 of the 16/24-bit register is stored
here when it is written by the CPU. Byte 1 of the 16/24-bit register is stored when byte 0 is read by the CPU. This register
can also be read and written from the user software.
Reading and writing 16- and 24-bit registers requires special attention. For details, refer to “Accessing 16-bit Registers”
on page 13.
Bit 7 6 5 4 3 2 1 0
+0x04 – – CH1BUSY CH0BUSY – – CH1PEND CH0PEND
Read/Write R R R R R R R R
Initial Value 0 0 0 0 0 0 0 0
Bit 7 6 5 4 3 2 1 0
+0x06 TEMP[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 53
8291C–AVR–09/2014
5.13.5 TEMPH – Temporary Register High
z Bit 7:0 – TEMP[15:8]: Temporary Register
This register is used when reading and writing 24-bit registers in the DMA controller. Byte 2 of the 24-bit register is stored
when it is written by the CPU. Byte 2 of the 24-bit register is stored here when byte 1 is read by the CPU. This register
can also be read and written from the user software.
Reading and writing 24-bit registers requires special attention. For details, refer to “Accessing 16-bit Registers” on page
13.
5.14 Register Description – DMA Channel
5.14.1 CTRLA – Control register A
z Bit 7 – ENABLE: Channel Enable
Setting this bit enables the DMA channel. This bit is automatically cleared when the transaction is completed. If the DMA
channel is enabled and this bit is written to zero, the CHEN bit is not cleared until the internal transfer buffer is empty and
the DMA transfer is aborted.
z Bit 6 – RESET: Software Reset
Setting this bit will reset the DMA channel. It can only be set when the DMA channel is disabled (CHEN = 0). Writing a
one to this bit will be ignored as long as the channel is enabled (CHEN=1). This bit is automatically cleared when reset is
completed.
z Bit 5 – REPEAT: Repeat Mode
Setting this bit enables the repeat mode. In repeat mode, this bit is cleared by hardware at the beginning of the last block
transfer. The REPCNT register should be configured before setting the REPEAT bit.
z Bit 4 – TRFREQ: Transfer Request
Setting this bit requests a data transfer on the DMA channel. This bit is automatically cleared at the beginning of the data
transfer. Writing this bit does not have any effect unless the channel is enabled.
z Bit 3 – Reserved
This bit is unused and reserved for future use. For compatibility with future devices, always write this bit to zero when this
register is written.
z Bit 2 – SINGLE: Single-Shot Data transfer
Setting this bit enables the single-shot mode. The channel will then do a burst transfer of BURSTLEN bytes on the
transfer trigger. A write to this bit will be ignored while the channel is enabled.
Bit 7 6 5 4 3 2 1 0
+0x07 TEMP[15:8]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 00000000
Bit 7 6 5 4 3 2 1 0
+0x00 ENABLE RESET REPEAT TRFREQ – SINGLE BURSTLEN[1:0]
Read/Write R/W R/W R/W R/W R R/W R/W R/W
Initial Value 0 0 000000
XMEGA B [MANUAL] 54
8291C–AVR–09/2014
z Bit 1:0 – BURSTLEN[1:0]: Burst Mode
These bits decide the DMA channel burst mode according to Table 5-2 on page 54. These bits cannot be changed if the
channel is busy.
Table 5-2. DMA channel burst mode
Table 5-3. Summary of triggers, transaction complete flag and channel disable according to DMA channel
configuration.
5.14.2 CTRLB – Control register B
z Bit 7 – CHBUSY: Channel Busy
When the DMA channel starts a DMA transaction, the CHBUSY flag will be read as one. This flag is automatically
cleared when the DMA channel is disabled, when the channel transaction complete interrupt flag is set or when the
channel error interrupt flag is set.
BURSTLEN[1:0] Group Configuration Description
00 1BYTE 1 byte burst mode
01 2BYTE 2 bytes burst mode
10 4BYTE 4 bytes burst mode
11 8BYTE 8 bytes burst mode
REPEAT SINGLE REPCNT Trigger Flag Set After Channel Disabled After
0 0 0 Block 1 block 1 block
0 0 1 Block 1 block 1 block
0 0 n > 1 Block 1 block 1 block
0 1 0 BURSTLEN 1 block 1 block
0 1 1 BURSTLEN 1 block 1 block
0 1 n > 1 BURSTLEN 1 block 1 block
1 0 0 Block Each block Each block
1 0 1 Transaction 1 block 1 block
1 0 n > 1 Transaction n blocks n blocks
1 1 0 BURSTLEN Each block Never
1 1 1 BURSTLEN 1 block 1 block
1 1 n > 1 BURSTLEN n blocks n blocks
Bit 7 6 5 4 3 2 1 0
+0x01 CHBUSY CHPEND ERRIF TRNIF ERRINTLVL[1:0] TRNINTLVL[1:0]
Read/Write R R R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 55
8291C–AVR–09/2014
z Bit 6 – CHPEND: Channel Pending
If a block transfer is pending on the DMA channel, the CHPEND flag will be read as one. This flag is automatically
cleared when the transfer starts or if the transfer is aborted.
z Bit 5 – ERRIF: Error Interrupt Flag
If an error condition is detected on the DMA channel, the ERRIF flag will be set and the optional interrupt is generated.
Since the DMA channel error interrupt shares the interrupt address with the DMA channel n transaction complete
interrupt, ERRIF will not be cleared when the interrupt vector is executed. This flag is cleared by writing a one to this
location.
z Bit 4 – TRNIF: Channel n Transaction Complete Interrupt Flag
When a transaction on the DMA channel has been completed, the TRNIF flag will be set and the optional interrupt is
generated. When repeat is not enabled, the transaction is complete and TRNIFR is set after the block transfer. When
unlimited repeat is enabled, TRNIF is also set after each block transfer.
Since the DMA channel transaction n complete interrupt shares the interrupt address with the DMA channel error
interrupt, TRNIF will not be cleared when the interrupt vector is executed. This flag is cleared by writing a one to this
location.
z Bit 3:2 – ERRINTLVL[1:0]: Channel Error Interrupt Level
These bits enable the interrupt for DMA channel transfer errors and select the interrupt level, as described in “Interrupts
and Programmable Multilevel Interrupt Controller” on page 115. The enabled interrupt will trigger for the conditions when
ERRIF is set.
z Bit 1:0 – TRNINTLVL[1:0]: Channel Transaction Complete Interrupt Level
These bits enable the interrupt for DMA channel transaction completes and select the interrupt level, as described in
“Interrupts and Programmable Multilevel Interrupt Controller” on page 115. The enabled interrupt will trigger for the
conditions when TRNIF is set.
5.14.3 ADDRCTRL – Address Control register
z Bit 7:6 – SRCRELOAD[1:0]: Channel Source Address Reload
These bits decide the DMA channel source address reload according to Table 5-4. A write to these bits is ignored while
the channel is busy.
Table 5-4. DMA channel source address reload settings
Bit 7 6 5 4 3 2 1 0
+0x02 SRCRELOAD[1:0] SRCDIR[1:0] DESTRELOAD[1:0] DESTDIR[1:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0000000
SRCRELOAD[1:0] Group Configuration Description
00 NONE No reload performed.
01 BLOCK DMA source address register is reloaded with initial value at end
of each block transfer.
10 BURST DMA source address register is reloaded with initial value at end
of each burst transfer.
11 TRANSACTION DMA source address register is reloaded with initial value at end
of each transaction.
XMEGA B [MANUAL] 56
8291C–AVR–09/2014
z Bit 5:4 – SRCDIR[1:0]: Channel Source Address Mode
These bits decide the DMA channel source address mode according to Table 5-5. These bits cannot be changed if the
channel is busy.
Table 5-5. DMA channel source address mode settings.
z Bit 3:2 – DESTRELOAD[1:0]: Channel Destination Address Reload
These bits decide the DMA channel destination address reload according to Table 5-6. These bits cannot be changed if
the channel is busy.
Table 5-6. DMA channel destination address reload settings
z Bit 1:0 – DESTDIR[1:0]: Channel Destination Address Mode
These bits decide the DMA channel destination address mode according to Table 5-7. These bits cannot be changed if
the channel is busy.
Table 5-7. DMA channel destination address mode settings
SRCDIR[1:0] Group Configuration Description
00 FIXED Fixed
01 INC Increment
10 DEC Decrement
11 - Reserved
DESTRELOAD[1:0] Group Configuration Description
00 NONE No reload performed.
01 BLOCK DMA channel destination address register is reloaded with
initial value at end of each block transfer.
10 BURST DMA channel destination address register is reloaded with
initial value at end of each burst transfer.
11 TRANSACTION DMA channel destination address register is reloaded with
initial value at end of each transaction.
DESTDIR[1:0] Group Configuration Description
00 FIXED Fixed
01 INC Increment
10 DEC Decrement
11 - Reserved
XMEGA B [MANUAL] 57
8291C–AVR–09/2014
5.14.4 TRIGSRC – Trigger Source
z Bit 7:0 – TRIGSRC[7:0]: Channel Trigger Source Select
These bits select which trigger source is used for triggering a transfer on the DMA channel. A zero value means that the
trigger source is disabled. For each trigger source, the value to put in the TRIGSRC register is the sum of the module’s or
peripheral’s base value and the offset value for the trigger source in the module or peripheral. Table 5-8 on page 57
shows the base value for all modules and peripherals. Table 5-9 on page 58 to Table 5-11 on page 58 shows the offset
value for the trigger sources in the different modules and peripheral types. For modules or peripherals which do not exist
for a device, the transfer trigger does not exist. Refer to the device datasheet for the list of peripherals available.
If the interrupt flag related to the trigger source is cleared or the interrupt level enabled so that an interrupt is triggered,
the DMA request will be lost. Since a DMA request can clear the interrupt flag, interrupts can be lost.
Note: For most trigger sources, the request is cleared by accessing a register belonging to the peripheral with the request. Refer to the different
peripheral chapters for how requests are generated and cleared.
Table 5-8. DMA trigger source base values for all modules and peripherals.
Bit 7 6 5 4 3 2 1 0
+0x03 TRIGSRC[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
TRIGSRC Base Value Group Configuration Description
0x00 OFF Software triggers only
0x01 SYS Event system DMA triggers base value
0x04 AES AES DMA trigger value
0x10 ADCA ADCA DMA trigger value
0x40 TCC0 Timer/counter C0 DMA triggers base value
0x46 TCC1 Timer/counter C1 triggers base value
0x4A SPIC SPI C DMA trigger value
0x4B USARTC0 USART C0 DMA triggers base value
0x60 TCD0 Timer/counter D0 DMA triggers base value
0x6A SPID SPI D DMA triggers value
0x6B USARTD0 USART D0 DMA triggers base value
0x80 TCE0 Timer/counter E0 DMA triggers base value
0x8B USARTE0 USART E0 DMA triggers base value
0xA0 TCF0 Timer/counter F0 DMA triggers base value
0xAB USARTF0 USART F0 DMA triggers base value
XMEGA B [MANUAL] 58
8291C–AVR–09/2014
Note: 1. CC channel C and D triggers are available only for timer/counters 0.
The group configuration is the “base_offset;” for example, TCC1_CCA for the timer/counter C1 CC channel A the transfer
trigger.
5.14.5 TRFCNTL – Channel Block Transfer Count register Low
The TRFCNTH and TRFCNTL register pair represents the 16-bit value TRFCNT. TRFCNT defines the number of bytes
in a block transfer. The value of TRFCNT is decremented after each byte read by the DMA channel. When TRFCNT
reaches zero, the register is reloaded with the last value written to it.
z Bit 7:0 – TRFCNT[7:0]: Channel n Block Transfer Count low byte
These bits hold the LSB of the 16-bit block transfer count.
The default value of this register is 0x1. If a user writes 0x0 to this register and fires a DMA trigger, DMA will be doing
0xFFFF transfers.
Table 5-9. DMA trigger source offset values for event system triggers.
TRGSRC Offset Value Group Configuration Description
+0x00 CH0 Event channel 0
+0x01 CH1 Event channel 1
+0x02 CH2 Event channel 2
Table 5-10. DMA trigger source offset values for timer/ counter triggers.
TRGSRC Offset Value Group Configuration Description
+0x00 OVF Overflow/underflow
+0x01 ERR Error
+0x02 CCA Compare or capture channel A
+0x03 CCB Compare or capture channel B
+0x04 CCC(1) Compare or capture channel C
+0x05 CCD(1) Compare or capture channel D
Table 5-11. DMA trigger source offset values for USART triggers.
TRGSRC Offset Value Group Configuration Description
0x00 RXC Receive complete
0x01 DRE Data register empty
Bit 7 6 5 4 3 2 1 0
+0x04 TRFCNT[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 00000000
XMEGA B [MANUAL] 59
8291C–AVR–09/2014
5.14.6 TRFCNTH – Channel Block Transfer Count register High
Reading and writing 16-bit values requires special attention. For details, refer to “Accessing 16-bit Registers” on page 13.
z Bit 7:0 – TRFCNT[15:8]: Channel n Block Transfer Count high byte
These bits hold the MSB of the 16-bit block transfer count.
The default value of this register is 0x1. If a user writes 0x0 to this register and fires a DMA trigger, DMA will be doing
0xFFFF transfers.
5.14.7 REPCNT – Repeat Counter register
REPCNT counts how many times a block transfer is performed. For each block transfer, this register will be
decremented.
When repeat mode is enabled (see REPEAT bit in “ADDRCTRL – Address Control register” on page 55), this register is
used to control when the transaction is complete. The counter is decremented after each block transfer if the DMA has to
serve a limited number of repeated block transfers. When repeat mode is enabled, the channel is disabled when
REPCNT reaches zero and the last block transfer is completed. Unlimited repeat is achieved by setting this register to
zero.
5.14.8 SRCADDR0 – Source Address 0
SRCADDR0, SRCADDR1, and SRCADDR2 represent the 24-bit value SRCADDR, which is the DMA channel source
address. SRCADDR2 is the most significant byte in the register. SRCADDR may be automatically incremented or
decremented based on settings in the SRCDIR bits in “ADDRCTRL – Address Control register” on page 55.
z Bit 7:0 – SRCADDR[7:0]: Channel Source Address byte 0
These bits hold byte 0 of the 24-bit source address.
Bit 7 6 5 4 3 2 1 0
+0x05 TRFCNT[15:8]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 00000
Bit 7 6 5 4 3 2 1 0
+0x06 REPCNT[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 000000
Bit 7 6 5 4 3 2 1 0
+0x08 SRCADDR[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 60
8291C–AVR–09/2014
5.14.9 SRCADDR1 – Channel Source Address 1
z Bit 7:0 – SRCADDR[15:8]: Channel Source Address byte 1
These bits hold byte 1 of the 24-bit source address.
5.14.10 SRCADDR2 – Channel Source Address 2
Reading and writing 24-bit values require special attention. For details, refer to “Accessing 24- and 32-bit Registers” on
page 13.
z Bit 7:0 – SRCADDR[23:16]: Channel Source Address byte 2
These bits hold byte 2 of the 24-bit source address.
5.14.11 DESTADDR0 – Channel Destination Address 0
DESTADDR0, DESTADDR1, and DESTADDR2 represent the 24-bit value DESTADDR, which is the DMA channel
destination address. DESTADDR2 holds the most significant byte in the register. DESTADDR may be automatically
incremented or decremented based on settings in the DESTDIR bits in “ADDRCTRL – Address Control register” on page
55.
z Bit 7:0 – DESTADDR[7:0]: Channel Destination Address byte 0
These bits hold byte 0 of the 24-bit source address.
Bit 7 6 5 4 3 2 1 0
+0x09 SRCADDR[15:8]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 00000
Bit 7 6 5 4 3 2 1 0
+0x0A SRCADDR[23:16]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
Bit 7 6 5 4 3 2 1 0
+0x0C DESTADDR[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 00000000
XMEGA B [MANUAL] 61
8291C–AVR–09/2014
5.14.12 DESTADDR1 – Channel Destination Address 1
z Bit 7:0 – DESTADDR[15:8]: Channel Destination Address byte 1
These bits hold byte 1 of the 24-bit source address.
5.14.13 DESTADDR2 – Channel Destination Address 2
Reading and writing 24-bit values require special attention. For details, refer to “Accessing 24- and 32-bit Registers” on
page 13.
z Bit 7:0 – DESTADDR[23:16]: Channel Destination Address byte 2
These bits hold byte 2 of the 24-bit source address.
Bit 7 6 5 4 3 2 1 0
+0x0D DESTADDR[15:8]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
Bit 7 6 5 4 3 2 1 0
+0x0E DESTADDR[23:16]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 62
8291C–AVR–09/2014
5.15 Register Summary – DMA Controller
5.16 Register Summary – DMA Channel
5.17 DMA Interrupt Vector Summary
Address Name Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 Page
+0x00 CTRL ENABLE RESET – – – DBUFMODE – PRIMODE 51
+0x01 Reserved – – – – – – – –
+0x02 Reserved – – – – – – – –
+0x03 INTFLAGS – – CH1ERRIF CH0ERRIF – – CH1TRNFIF CH0TRNFIF 51
+0x04 STATUS – – CH1BUSY CH0BUSY – – CH1PEND CH0PEND 52
+0x05 Reserved – – – – – – – –
+0x06 TEMPL TEMP[7:0] 52
+0x07 TEMPH TEMP[15:8] 53
+0x10 CH0 Offset Offset address for DMA Channel 0
+0x20 CH1 Offset Offset address for DMA Channel 1
+0x30 Reserved – – – – – – – –
+0x40 Reserved – – – – – – – –
Address Name Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 Page
+0x00 CTRLA ENABLE RESET REPEAT TRFREQ – SINGLE BURSTLEN[1:0] 53
+0x01 CTRLB CHBUSY CHPEND ERRIF TRNIF ERRINTLVL[1:0] TRNINTLVL[1:0] 54
+0x02 ADDCTRL SRCRELOAD[1:0] SRCDIR[1:0] DESTRELOAD[1:0] DESTDIR[1:0] 55
+0x03 TRIGSRC TRIGSRC[7:0] 57
+0x04 TRFCNTL TRFCNT[7:0] 58
+0x05 TRFCNTH TRFCNT[15:8] 59
+0x06 REPCNT REPCNT[7:0] 59
+0x07 Reserved – – – – – – – –
+0x08 SRCADDR0 SRCADDR[7:0] 59
+0x09 SRCADDR1 SRCADDR[15:8] 60
+0x0A SRCADDR2 SRCADDR[23:16] 60
+0x0B Reserved – – – – – – – –
+0x0C DESTADDR0 DESTADDR[7:0] 60
+0x0D DESTADDR1 DESTADDR[15:8] 61
+0x0E DESTADDR2 DESTADDR[23:16] 61
+0x0F Reserved – – – – – – – –
Offset Source Interrupt Description
0x00 CH0_vect DMA controller channel 0 interrupt vector
0x02 CH1_vect DMA controller channel 1 interrupt vector
XMEGA B [MANUAL] 63
8291C–AVR–09/2014
6. Event System
6.1 Features
z System for direct peripheral-to-peripheral communication and signaling
z Peripherals can directly send, receive, and react to peripheral events
z CPU and DMA controller independent operation
z 100% predictable signal timing
z Short and guaranteed response time
z Four event channels for up to eight different and parallel signal routings and configurations
z Events can be sent and/or used by most peripherals, clock system, and software
z Additional functions include
z Quadrature decoders
z Digital filtering of I/O pin state
z Works in active mode and idle sleep mode
6.2 Overview
The event system enables direct peripheral-to-peripheral communication and signaling. It allows a change in one
peripheral’s state to automatically trigger actions in other peripherals. It is designed to provide a predictable system for
short and predictable response times between peripherals. It allows for autonomous peripheral control and interaction
without the use of interrupts CPU or DMA controller resources, and is thus a powerful tool for reducing the complexity,
size and execution time of application code. It also allows for synchronized timing of actions in several peripheral
modules.
A change in a peripheral’s state is referred to as an event, and usually corresponds to the peripheral’s interrupt
conditions. Events can be directly passed to other peripherals using a dedicated routing network called the event routing
network. How events are routed and used by the peripherals is configured in software.
Figure 6-1 on page 64 shows a basic diagram of all connected peripherals. The event system can directly connect
together analog converters, analog comparators, I/O port pins, the real-time counter, timer/counters, IR communication
module (IRCOM) and USB interface. It can also be used to trigger DMA transactions (DMA controller). Events can also
be generated from software and the peripheral clock.
XMEGA B [MANUAL] 64
8291C–AVR–09/2014
Figure 6-1. Event system overview and connected peripherals.
The event routing network consists of four software-configurable multiplexers that control how events are routed and
used. These are called event channels, and allow for up to four parallel event configurations and routings. The maximum
routing latency is two peripheral clock cycles. The event system works in both active mode and idle sleep mode.
6.3 Events
In the context of the event system, an indication that a change of state within a peripheral has occurred is called an
event. There are two main types of events: signaling events and data events. Signaling events only indicate a change of
state while data events contain additional information about the event.
The peripheral from which the event originates is called the event generator. Within each peripheral (for example, a
timer/counter), there can be several event sources, such as a timer compare match or timer overflow. The peripheral
using the event is called the event user, and the action that is triggered is called the event action.
Timer /
Counters
USB
ADC Real Time
Counter
Port pins
CPU /
Software
DMA
Controller
IRCOM
Event Routing Network
Event
System
Controller
clkPER
Prescaler
AC
XMEGA B [MANUAL] 65
8291C–AVR–09/2014
Figure 6-2. Example of event source, generator, user, and action.
Events can also be generated manually in software.
6.3.1 Signaling Events
Signaling events are the most basic type of event. A signaling event does not contain any information apart from the
indication of a change in a peripheral. Most peripherals can only generate and use signaling events. Unless otherwise
stated, all occurrences of the word ”event” are to be understood as meaning signaling events.
6.3.2 Data Events
Data events differ from signaling events in that they contain information that event users can decode to decide event
actions based on the receiver information.
Although the event routing network can route all events to all event users, those that are only meant to use signaling
events do not have decoding capabilities needed to utilize data events. How event users decode data events is shown in
Table 6-1 on page 66.
Event users that can utilize data events can also use signaling events. This is configurable, and is described in the
datasheet module for each peripheral.
6.3.3 Peripheral Clock Events
Each event channel includes a peripheral clock prescaler with a range from 1 (no prescaling) to 32768. This enables
configurable periodic event generation based on the peripheral clock. It is possible to periodically trigger events in a
peripheral or to periodically trigger synchronized events in several peripherals. Since each event channel include a
prescaler, different peripherals can receive triggers with different intervals.
6.3.4 Software Events
Events can be generated from software by writing the DATA and STROBE registers. The DATA register must be written
first, since writing the STROBE register triggers the operation. The DATA and STROBE registers contain one bit for each
event channel. Bit n corresponds to event channel n. It is possible to generate events on several channels at the same
time by writing to several bit locations at once.
Software-generated events last for one clock cycle and will overwrite events from other event generators on that event
channel during that clock cycle.
Table 6-1 on page 66 shows the different events, how they can be manually generated, and how they are decoded.
Event User
Event
Routing
Network |
Compare Match
Over-/Underflow
Error
Timer/Counter
Syncsweep
Single
Conversion
ADC
Event Generator
Event Source Event Action
Event Action Selection
XMEGA B [MANUAL] 66
8291C–AVR–09/2014
Table 6-1. Manually generated events and decoding of events.
6.4 Event Routing Network
The event routing network routes the events between peripherals. It consists of eight multiplexers (CHnMUX), which can
each be configured to route any event source to any event users. The output from a multiplexer is referred to as an event
channel. For each peripheral, it is selectable if and how incoming events should trigger event actions. Details on
configurations can be found in the datasheet for each peripheral. The event routing network is shown in Figure 6-3 on
page 67.
STROBE DATA Data Event User Signaling Event User
0 0 No event No event
0 1 Data event 01 No event
1 0 Data event 02 Signaling event
1 1 Data event 03 Signaling event
XMEGA B [MANUAL] 67
8291C–AVR–09/2014
Figure 6-3. Event routing network.
Four multiplexers means that it is possible to route up to four events at the same time. It is also possible to route one
event through several multiplexers.
Not all XMEGA devices contain all peripherals. This only means that a peripheral is not available for generating or using
events. The network configuration itself is compatible between all devices.
6.5 Event Timing
An event normally lasts for one peripheral clock cycle, but some event sources, such as a low level on an I/O pin, will
generate events continuously. Details on this are described in the datasheet for each peripheral, but unless otherwise
stated, an event lasts for one peripheral clock cycle.
(48)
PORTA
PORTB
PORTC
PORTD
PORTE
PORTF
ADCA
TCF0 (6)
TCE0
TCD0
TCC0
TCC1
(6)
(4)
(4)
(4)
(4)
(10)
(6)
(29)
(4)
(4)
(4)
RTC
ClkPER
(8)
(8)
(8)
(8)
(8)
(8)
CH0MUX[7:0]
CH1MUX[7:0]
CH2MUX[7:0]
CH3MUX[7:0]
CH0CTRL[7:0]
CH1CTRL[7:0]
CH2CTRL[7:0]
CH3CTRL[7:0]
Event Channel 3
Event Channel 2
Event Channel 1
Event Channel 0
(6)
(16)
(2)
ACA (3)
USB (4)
XMEGA B [MANUAL] 68
8291C–AVR–09/2014
It takes a maximum of two peripheral clock cycles from when an event is generated until the event actions in other
peripherals are triggered. This ensures short and 100% predictable response times, independent of CPU or DMA
controller load or software revisions.
6.6 Filtering
Each event channel includes a digital filter. When this is enabled, an event must be sampled with the same value for a
configurable number of system clock cycles before it is accepted. This is primarily intended for pin change events.
6.7 Quadrature Decoder
The event system includes one quadrature decoder (QDEC), which enable the device to decode quadrature input on I/O
pins and send data events that a timer/counter can decode to count up, count down, or index/reset. Table 6-2
summarizes which quadrature decoder data events are available, how they are decoded, and how they can be
generated. The QDEC and related features, control and status registers are available for event channel 0.
Table 6-2. Quadrature decoder data events.
6.7.1 Quadrature Operation
A quadrature signal is characterized by having two square waves that are phase shifted 90 degrees relative to each
other. Rotational movement can be measured by counting the edges of the two waveforms. The phase relationship
between the two square waves determines the direction of rotation.
Figure 6-4. Quadrature signals from a rotary encoder.
Figure 6-4 shows typical quadrature signals from a rotary encoder. The signals QDPH0 and QDPH90 are the two
quadrature signals. When QDPH90 leads QDPH0, the rotation is defined as positive or forward. When QDPH0 leads
QDPH90, the rotation is defined as negative or reverse. The concatenation of the two phase signals is called the
quadrature state or the phase state.
STROBE DATA Data Event User Signaling Event User
0 0 No event No event
0 1 Index/reset No event
1 0 Count down Signaling event
1 1 Count up Signaling event
XMEGA B [MANUAL] 69
8291C–AVR–09/2014
In order to know the absolute rotary displacement, a third index signal (QINDX) can be used. This gives an indication
once per revolution.
6.7.2 QDEC Setup
For a full QDEC setup, the following is required:
z Tho or three I/O port pins for quadrature signal input
z Two event system channels for quadrature decoding
z One timer/counter for up, down, and optional index count
The following procedure should be used for QDEC setup:
1. Choose two successive pins on a port as QDEC phase inputs.
2. Set the pin direction for QDPH0 and QDPH90 as input.
3. Set the pin configuration for QDPH0 and QDPH90 to low level sense.
4. Select the QDPH0 pin as a multiplexer input for an event channel, n.
5. Enable quadrature decoding and digital filtering in the event channel.
6. Optional:
1. Set up a QDEC index (QINDX).
2. Select a third pin for QINDX input.
3. Set the pin direction for QINDX as input.
4. Set the pin configuration for QINDX to sense both edges.
5. Select QINDX as a multiplexer input for event channel n+1
6. Set the quadrature index enable bit in event channel n+1.
7. Select the index recognition mode for event channel n+1.
7. Set quadrature decoding as the event action for a timer/counter.
8. Select event channel n as the event source for the timer/counter.
z Set the period register of the timer/counter to ('line count' * 4 - 1), the line count of the quadrature encoder.
z Enable the timer/counter without clock prescaling.
The angle of a quadrature encoder attached to QDPH0, QDPH90 (and QINDX) can now be read directly from the
timer/counter count register. If the count register is different from BOTTOM when the index is recognized, the
timer/counter error flag is set. Similarly, the error flag is set if the position counter passes BOTTOM without the
recognition of the index.
XMEGA B [MANUAL] 70
8291C–AVR–09/2014
6.8 Register Description
6.8.1 CHnMUX – Event Channel n Multiplexer register
z Bit 7:0 – CHnMUX[7:0]: Channel Multiplexer
These bits select the event source according to Table 6-3. This table is valid for all XMEGA devices regardless of
whether the peripheral is present or not. Selecting event sources from peripherals that are not present will give the same
result as when this register is zero. When this register is zero, no events are routed through. Manually generated events
will override CHnMUX and be routed to the event channel even if this register is zero.
Table 6-3. CHnMUX[7:0] bit settings.
Bit 7 6 5 4 3 2 1 0
CHnMUX[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 00000000
CHnMUX[7:4] CHnMUX[3:0] Group Configuration Event Source
0000 0 0 0 0 None (manually generated events only)
0000 0 0 0 1 (Reserved)
0000 0 0 1 X (Reserved)
0000 0 1 X X (Reserved)
0000 1 0 0 0 RTC_OVF RTC overflow
0000 1 0 0 1 RTC_CMP RTC compare match
0000 1 0 1 0
USB start of frame on CH0(2)
USB error on CH1(2)
USB overflow on CH2(2)
USB setup on CH3(2)
0000 1 0 1 X (Reserved)
0000 1 1 X X (Reserved)
0001 0 0 0 0 ACA_CH0 ACA channel 0
0001 0 0 0 1 ACA_CH1 ACA channel 1
0001 0 0 1 0 ACA_WIN ACA window
0001 0 0 1 1 (Reserved)
0001 0 1 X X (Reserved)
0001 1 X X X (Reserved)
0010 0 0 0 0 ADCA_CH0 ADCA
0010 0 0 0 1 (Reserved)
0010 0 0 1 X (Reserved)
0010 0 1 X X (Reserved)
XMEGA B [MANUAL] 71
8291C–AVR–09/2014
Notes: 1. The description of how the ports generate events is described in “Port Event” on page 130.
2. The different USB events can be selected for only event channel, 0 to 3.
Table 6-4. Timer/counter events
0010 1 X X X (Reserved)
0011 X X X X (Reserved)
0100 X X X X (Reserved)
0101 0 n PORTA_PINn(1) PORTA pin n (n= 0, 1, 2 ... or 7)
0101 1 n PORTB_PINn(1) PORTB pin n (n= 0, 1, 2 ... or 7)
0110 0 n PORTC_PINn(1) PORTC pin n (n= 0, 1, 2 ... or 7)
0110 1 n PORTD_PINn(1) PORTD pin n (n= 0, 1, 2 ... or 7)
0111 0 n PORTE_PINn(1) PORTE pin n (n= 0, 1, 2 ... or 7)
0111 1 n PORTF_PINn(1) PORTF pin n (n= 0, 1, 2 ... or 7)
1000 M PRESCALER_M ClkPER divide by 2M (M=0 to 15)
1001 X X X X (Reserved)
1010 X X X X (Reserved)
1011 X X X X (Reserved)
1100 0 E See Table 6-4 Timer/counter C0 event type E
1100 1 E See Table 6-4 Timer/counter C1 event type E
1101 0 E See Table 6-4 Timer/counter D0 event type E
1111 1 X X X (Reserved)
1110 0 E See Table 6-4 Timer/counter E0 event type E
1111 1 X X X (Reserved)
1111 0 E See Table 6-4 Timer/counter F0 event type E
1111 1 X X X (Reserved)
T/C Event E Group Configuration Event Type
0 0 0 TCxn_OVF Over/Underflow (x = C, D, E or F) (n= 0 or 1)
0 0 1 TCxn_ERR Error (x = C, D, E or F) (n= 0 or 1)
0 1 X – (Reserved)
1 0 0 TCxn_CCA Capture or compare A (x = C, D, E or F) (n= 0 or 1)
1 0 1 TCxn_CCB Capture or compare B (x = C, D, E or F) (n= 0 or 1)
1 1 0 TCxn_CCC Capture or compare C (x = C, D, E or F) (n= 0)
1 1 1 TCxn_CCD Capture or compare D (x = C, D, E or F) (n= 0)
CHnMUX[7:4] CHnMUX[3:0] Group Configuration Event Source
XMEGA B [MANUAL] 72
8291C–AVR–09/2014
6.8.2 CHnCTRL – Event Channel n Control register
Note: 1. Only available for CH0CTRL and CH2CTRL. These bits are reserved in CH1CTRL and CH3CTRL.
z Bit 7 – Reserved
This bit is reserved and will always be read as zero. For compatibility with future devices, always write this bit to zero
when this register is written.
z Bit 6:5 – QDIRM[1:0]: Quadrature Decode Index Recognition Mode
These bits determine the quadrature state for the QDPH0 and QDPH90 signals, where a valid index signal is recognized
and the counter index data event is given according to Table 6-5. These bits should only be set when a quadrature
encoder with a connected index signal is used.These bits are available only for CH0CTRL and CH2CTRL.
Table 6-5. QDIRM bit settings.
z Bit 4 – QDIEN: Quadrature Decode Index Enable
When this bit is set, the event channel will be used as a QDEC index source, and the index data event will be enabled.
This bit is available only for CH0CTRL and CH2CTRL.
z Bit 3 – QDEN: Quadrature Decode Enable
Setting this bit enables QDEC operation.
This bit is available only for CH0CTRL and CH2CTRL.
z Bit 2:0 – DIGFILT[2:0]: Digital Filter Coefficient
These bits define the length of digital filtering used, according to Table 6-6 on page 72. Events will be passed through to
the event channel only when the event source has been active and sampled with the same level for the number of
peripheral clock cycles defined by DIGFILT.
Bit 7 6 5 4 3 2 1 0
– QDIRM[1:0](1) QDIEN(1) QDEN(1) DIGFILT[2:0]
– – – – – DIGFILT[2:0]
Read/Write R R/W R/W R/W R/W R/W R/W R
Initial Value 0 0 0 0 0 0 0 0
QDIRM[1:0] Index Recognition State
0 0 {QDPH0, QDPH90} = 0b00
0 1 {QDPH0, QDPH90} = 0b01
1 0 {QDPH0, QDPH90} = 0b10
1 1 {QDPH0, QDPH90} = 0b11
Table 6-6. Digital filter coefficient values .
DIGFILT[2:0] Group Configuration Description
000 1SAMPLE One sample
001 2SAMPLES Two samples
010 3SAMPLES Three samples
XMEGA B [MANUAL] 73
8291C–AVR–09/2014
6.8.3 STROBE – Strobe register
If the STROBE register location is written, each event channel will be set according to the STROBE[n] and corresponding
DATA[n] bit settings, if any are unequal to zero.
A single event lasting for one peripheral clock cycle will be generated.
6.8.4 DATA – Data register
This register contains the data value when manually generating a data event. This register must be written before the
STROBE register. For details, See ”STROBE – Strobe register” on page 73.
011 4SAMPLES Four samples
100 5SAMPLES Five samples
101 6SAMPLES Six samples
110 7SAMPLES Seven samples
111 8SAMPLES Eight samples
Table 6-6. Digital filter coefficient values (Continued).
DIGFILT[2:0] Group Configuration Description
Bit 7 6 5 4 3 2 1 0
+0x10 STROBE[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
Bit 7 6 5 4 3 2 1 0
+0x11 DATA[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 00000000
XMEGA B [MANUAL] 74
8291C–AVR–09/2014
6.9 Register Summary
Address Name Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 Page
+0x00 CH0MUX CH0MUX[7:0] 70
+0x01 CH1MUX CH1MUX[7:0] 70
+0x02 CH2MUX CH2MUX[7:0] 70
+0x03 CH3MUX CH3MUX[7:0] 70
+0x04 Reserved – – – – – – – –
+0x05 Reserved – – – – – – – –
+0x06 Reserved – – – – – – – –
+0x07 Reserved – – – – – – – –
+0x08 CH0CTRL – QDIRM[1:0] QDIEN QDEN DIGFILT[2:0] 72
+0x09 CH1CTRL – – – – – DIGFILT[2:0] 72
+0x0A CH2CTRL – QDIRM[1:0] QDIEN QDEN DIGFILT[2:0] 72
+0x0B CH3CTRL – – – – – DIGFILT[2:0] 72
+0x0C Reserved – – – – – – – –
+0x0D Reserved – – – – – – – –
+0x0E Reserved – – – – – – – –
+0x0F Reserved – – – – – – – –
+0x10 STROBE STROBE[7:0] 73
+0x11 DATA DATA[7:0] 73
XMEGA B [MANUAL] 75
8291C–AVR–09/2014
7. System Clock and Clock Options
7.1 Features
z Fast start-up time
z Safe run-time clock switching
z Internal oscillators:
z 32MHz run-time calibrated and tunable oscillator
z 2MHz run-time calibrated oscillator
z 32.768kHz calibrated oscillator
z 32kHz ultra low power (ULP) oscillator with 1kHz output
z External clock options
z 0.4MHz - 16MHz crystal oscillator
z 32.768kHz crystal oscillator
z External clock
z PLL with 20MHz - 128MHz output frequency
z Internal and external clock options and 1x to 31x multiplication
z Lock detector
z Clock prescalers with 1x to 2048x division
z Fast peripheral clocks running at 2 and 4 times the CPU clock
z Automatic run-time calibration of internal oscillators
z External oscillator and PLL lock failure detection with optional non-maskable interrupt
7.2 Overview
XMEGA devices have a flexible clock system supporting a large number of clock sources. It incorporates both accurate
internal oscillators and external crystal oscillator and resonator support. A high-frequency phase locked loop (PLL) and
clock prescalers can be used to generate a wide range of clock frequencies. A calibration feature (DFLL) is available,
and can be used for automatic run-time calibration of the internal oscillators to remove frequency drift over voltage and
temperature. An oscillator failure monitor can be enabled to issue a non-maskable interrupt and switch to the internal
oscillator if the external oscillator or PLL fails.
When a reset occurs, all clock sources except the 32kHz ultra low power oscillator are disabled. After reset, the device
will always start up running from the 2MHz internal oscillator. During normal operation, the system clock source and
prescalers can be changed from software at any time.
Figure 7-1 on page 76 presents the principal clock system in the XMEGA family of devices. Not all of the clocks need to
be active at a given time. The clocks for the CPU and peripherals can be stopped using sleep modes and power
reduction registers, as described in “Power Management and Sleep Modes” on page 94.
XMEGA B [MANUAL] 76
8291C–AVR–09/2014
Figure 7-1. The clock system, clock sources, and clock distribution.
Real Time
Counter Peripherals RAM AVR CPU Non-Volatile
Memory
Watchdog
Timer
Brown-out
Detector
System Clock Prescalers
USB
Prescaler
System Clock Multiplexer
(SCLKSEL)
PLLSRC
RTCSRC
DIV32
32 kHz
Int. ULP
32.768 kHz
Int. OSC
32.768 kHz
TOSC
2 MHz
Int. Osc
32 MHz
Int. Osc
0.4 – 16 MHz
XTAL
DIV32
DIV32
DIV4
XOSCSEL
PLL
USBSRC
TOSC1
TOSC2
XTAL1
XTAL2
clkSYS clkRTC
clkPER2
clkPER
clkCPU
clkPER4
clkUSB
XMEGA B [MANUAL] 77
8291C–AVR–09/2014
7.3 Clock Distribution
Figure 7-1 on page 76 presents the principal clock distribution system used in XMEGA devices.
7.3.1 System Clock - ClkSYS
The system clock is the output from the main system clock selection. This is fed into the prescalers that are used to
generate all internal clocks except the asynchronous and USB clocks.
7.3.2 CPU Clock - ClkCPU
The CPU clock is routed to the CPU and nonvolatile memory. Halting the CPU clock inhibits the CPU from executing
instructions.
7.3.3 Peripheral Clock - ClkPER
The majority of peripherals and system modules use the peripheral clock. This includes the DMA controller, event
system, interrupt controller, external bus interface and RAM. This clock is always synchronous to the CPU clock, but may
run even when the CPU clock is turned off.
7.3.4 Peripheral 2x/4x Clocks - ClkPER2/ClkPER4
Modules that can run at two or four times the CPU clock frequency can use the peripheral 2x and peripheral 4x clocks.
7.3.5 Asynchronous Clock - ClkRTC
The asynchronous clock allows the real-time counter (RTC) to be clocked directly from an external 32.768kHz crystal
oscillator or the 32 times prescaled output from the internal 32.768kHz oscillator or ULP oscillator. The dedicated clock
domain allows operation of this peripheral even when the device is in sleep mode and the rest of the clocks are stopped.
7.3.6 USB Clock - ClkUSB
The USB device module requires a 12MHz or 48MHz clock. It has a separate clock source selection in order to avoid
system clock source limitations when USB is used.
7.4 Clock Sources
The clock sources are divided in two main groups: internal oscillators and external clock sources. Most of the clock
sources can be directly enabled and disabled from software, while others are automatically enabled or disabled,
depending on peripheral settings. After reset, the device starts up running from the 2MHz internal oscillator. The other
clock sources, DFLLs and PLL, are turned off by default.
7.4.1 Internal Oscillators
The internal oscillators do not require any external components to run. For details on characteristics and accuracy of the
internal oscillators, refer to the device datasheet.
7.4.1.1 32kHz Ultra Low Power Oscillator
This oscillator provides an approximate 32kHz clock. The 32kHz ultra low power (ULP) internal oscillator is a very low
power clock source, and it is not designed for high accuracy.The oscillator employs a built-in prescaler that provides a
1kHz output, see “RTCCTRL – RTC Control register” on page 85 for details. The oscillator is automatically
enabled/disabled when it is used as clock source for any part of the device. This oscillator can be selected as the clock
source for the RTC.
7.4.1.2 32.768kHz Calibrated Oscillator
This oscillator provides an approximate 32.768kHz clock. It is calibrated during production to provide a default frequency
close to its nominal frequency. The calibration register can also be written from software for run-time calibration of the
oscillator frequency. The oscillator employs a built-in prescaler, which provides both a 32.768kHz output and a 1.024kHz
XMEGA B [MANUAL] 78
8291C–AVR–09/2014
output, see “RTCCTRL – RTC Control register” on page 85 for details.
7.4.1.3 32MHz Run-time Calibrated Oscillator
The 32MHz run-time calibrated internal oscillator is a high-frequency oscillator. It is calibrated during production to
provide a default frequency close to its nominal frequency. A digital frequency looked loop (DFLL) can be enabled for
automatic run-time calibration of the oscillator to compensate for temperature and voltage drift and optimize the oscillator
accuracy. This oscillator can also be adjusted and calibrated to any frequency between 30MHz and 55MHz. The
production signature row contains 48 MHz calibration values intended used when the oscillator is used a full-speed USB
clock source.
7.4.1.4 2MHz Run-time Calibrated Oscillator
The 2MHz run-time calibrated internal oscillator is the default system clock source after reset. It is calibrated during
production to provide a default frequency close to its nominal frequency. A DFLL can be enabled for automatic run-time
calibration of the oscillator to compensate for temperature and voltage drift and optimize the oscillator accuracy.
7.4.2 External Clock Sources
The XTAL1 and XTAL2 pins can be used to drive an external oscillator, either a quartz crystal or a ceramic resonator.
XTAL1 can be used as input for an external clock signal. The TOSC1 and TOSC2 pins is dedicated to driving a
32.768kHz crystal oscillator.
7.4.2.1 0.4MHz - 16MHz Crystal Oscillator
This oscillator can operate in four different modes optimized for different frequency ranges, all within 0.4MHz - 16MHz.
Figure 7-2 shows a typical connection of a crystal oscillator or resonator.
Figure 7-2. Crystal oscillator connection.
Two capacitors, C1 and C2, may be added to match the required load capacitance for the connected crystal.
7.4.2.2 External Clock Input
To drive the device from an external clock source, XTAL1 must be driven as shown in Figure 7-3 on page 78. In this
mode, XTAL2 can be used as a general I/O pin.
Figure 7-3. External clock drive configuration.
C1
C2
XTAL2
XTAL1
GND
General
Purpose
I/O
XTAL2
XTAL1
External
Clock
Signal
XMEGA B [MANUAL] 79
8291C–AVR–09/2014
7.4.2.3 32.768kHz Crystal Oscillator
A 32.768kHz crystal oscillator can be connected between the TOSC1 and TOSC2 pins and enables a dedicated low
frequency oscillator input circuit. A typical connection is shown in Figure 7-4 on page 79. A low power mode with reduced
voltage swing on TOSC2 is available. This oscillator can be used as a clock source for the system clock and RTC, and as
the DFLL reference clock.
Figure 7-4. 32.768kHz crystal oscillator connection.
Two capacitors, C1 and C2, may be added to match the required load capacitance for the connected crystal. For details
on recommended TOSC characteristics and capacitor load, refer to device datasheets.
7.5 System Clock Selection and Prescalers
All the calibrated internal oscillators, the external clock sources (XOSC), and the PLL output can be used as the system
clock source. The system clock source is selectable from software, and can be changed during normal operation. Built-in
hardware protection prevents unsafe clock switching. It is not possible to select a non-stable or disabled oscillator as the
clock source, or to disable the oscillator currently used as the system clock source. Each oscillator option has a status
flag that can be read from software to check that the oscillator is ready.
The system clock is fed into a prescaler block that can divide the clock signal by a factor from 1 to 2048 before it is routed
to the CPU and peripherals. The prescaler settings can be changed from software during normal operation. The first
stage, prescaler A, can divide by a factor of from 1 to 512. Then, prescalers B and C can be individually configured to
either pass the clock through or combine divide it by a factor from 1 to 4. The prescaler guarantees that derived clocks
are always in phase, and that no glitches or intermediate frequencies occur when changing the prescaler setting. The
prescaler settings are updated in accordance with the rising edge of the slowest clock.
Figure 7-5. System clock selection and prescalers.
Prescaler A divides the system clock, and the resulting clock is clkPER4. Prescalers B and C can be enabled to divide the
clock speed further to enable peripheral modules to run at twice or four times the CPU clock frequency. If Prescalers B
and C are not used, all the clocks will run at the same frequency as the output from Prescaler A.
The system clock selection and prescaler registers are protected by the configuration change protection mechanism,
employing a timed write procedure for changing the system clock and prescaler settings. For details, refer to
“Configuration Change Protection” on page 13.
C1
C2
TOSC2
TOSC1
GND
Prescaler A
1, 2, 4, ... , 512
Prescaler B
1, 2, 4
Prescaler C
1, 2
Internal 2MHz Osc.
Internal 32.768kHz Osc.
Internal 32MHz Osc.
External Oscillator or Clock.
ClkCPU
Clock Selection
ClkPER
ClkSYS
ClkPER4 ClkPER2
Internal PLL.
XMEGA B [MANUAL] 80
8291C–AVR–09/2014
7.6 PLL with 1x-31x Multiplication Factor
The built-in phase locked loop (PLL) can be used to generate a high-frequency system clock. The PLL has a userselectable
multiplication factor of from 1 to 31. The output frequency, fOUT, is given by the input frequency, fIN, multiplied
by the multiplication factor, PLL_FAC.
Four different clock sources can be chosen as input to the PLL:
z 2MHz internal oscillator
z 32MHz internal oscillator divided by 4
z 0.4MHz - 16MHz crystal oscillator
z External clock
To enable the PLL, the following procedure must be followed:
1. Enable reference clock source.
2. Set the multiplication factor and select the clock reference for the PLL.
3. Wait until the clock reference source is stable.
4. Enable the PLL.
Hardware ensures that the PLL configuration cannot be changed when the PLL is in use. The PLL must be disabled
before a new configuration can be written.
It is not possible to use the PLL before the selected clock source is stable and the PLL has locked.
The reference clock source cannot be disabled while the PLL is running.
7.7 DFLL 2MHz and DFLL 32MHz
Two built-in digital frequency locked loops (DFLLs) can be used to improve the accuracy of the 2MHz and 32MHz
internal oscillators. The DFLL compares the oscillator frequency with a more accurate reference clock to do automatic
run-time calibration of the oscillator and compensate for temperature and voltage drift. The choices for the reference
clock sources are:
z 32.768kHz calibrated internal oscillator
z 32.768kHz crystal oscillator connected to the TOSC pins
z External clock
z USB start of frame
The DFLLs divide the oscillator reference clock by 32 to use a 1.024kHz reference. The reference clock is individually
selected for each DFLL, as shown on Figure 7-6 on page 81.
f OUT f IN = ⋅ PLL_FAC
XMEGA B [MANUAL] 81
8291C–AVR–09/2014
Figure 7-6. DFLL reference clock selection.
The ideal counter value representing the frequency ratio between the internal oscillator and a 1.024kHz reference clock
is loaded into the DFLL oscillator compare register (COMP) during reset. For the 32MHz oscillator, this register can be
written from software to make the oscillator run at a different frequency or when the ratio between the reference clock
and the oscillator is different (for example when the USB start of frame is used). The 48MHz calibration values must be
read from the production signature row and written to the 32MHz CAL register before the DFLL is enabled with USB SOF
as reference source.
The value that should be written to the COMP register is given by the following formula:
When the DFLL is enabled, it controls the ratio between the reference clock frequency and the oscillator frequency. If the
internal oscillator runs too fast or too slow, the DFLL will decrement or increment its calibration register value by one to
adjust the oscillator frequency. The oscillator is considered running too fast or too slow when the error is more than a half
calibration step size.
32.768 kHz Crystal Osc
External Clock
32.768 kHz Int. Osc
DFLL32M
32 MHz Int. RCOSC
DFLL2M
2 MHz Int. RCOSC
clkRC32MCREF
clkRC2MCREF
TOSC1
TOSC2
XTAL1
DIV32 DIV32
XOSCSEL
USB Start of Frame
XMEGA B [MANUAL] 82
8291C–AVR–09/2014
Figure 7-7. Automatic run-time calibration.
The DFLL will stop when entering a sleep mode where the oscillators are stopped. After wake up, the DFLL will continue
with the calibration value found before entering sleep. The reset value of the DFLL calibration register can be read from
the production signature row.
When the DFLL is disabled, the DFLL calibration register can be written from software for manual run-time calibration of
the oscillator.
7.8 PLL and External Clock Source Failure Monitor
A built-in failure monitor is available for the PLL and external clock source. If the failure monitor is enabled for the PLL
and/or the external clock source, and this clock source fails (the PLL looses lock or the external clock source stops) while
being used as the system clock, the device will:
z Switch to run the system clock from the 2MHz internal oscillator
z Reset the oscillator control register and system clock selection register to their default values
z Set the failure detection interrupt flag for the failing clock source (PLL or external clock)
z Issue a non-maskable interrupt (NMI)
If the PLL or external clock source fails when not being used for the system clock, it is automatically disabled, and the
system clock will continue to operate normally. No NMI is issued. The failure monitor is meant for external clock sources
above 32kHz. It cannot be used for slower external clocks.
When the failure monitor is enabled, it will not be disabled until the next reset.
The failure monitor is stopped in all sleep modes where the PLL or external clock source are stopped. During wake up
from sleep, it is automatically restarted.
The PLL and external clock source failure monitor settings are protected by the configuration change protection
mechanism, employing a timed write procedure for changing the settings. For details, refer to “Configuration Change
Protection” on page 13.
DFLL CNT
COMP
0
tRCnCREF
Frequency
OK RCOSC fast,
CALA decremented
RCOSC slow,
CALA incremented
clkRCnCREF
XMEGA B [MANUAL] 83
8291C–AVR–09/2014
7.9 Register Description – Clock
7.9.1 CTRL – Control register
z Bit 7:3 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 2:0 – SCLKSEL[2:0]: System Clock Selection
These bits are used to select the source for the system clock. See Table 7-1 for the different selections. Changing the
system clock source will take two clock cycles on the old clock source and two more clock cycles on the new clock
source. These bits are protected by the configuration change protection mechanism. For details, refer to “Configuration
Change Protection” on page 13.
SCLKSEL cannot be changed if the new clock source is not stable. The old clock can not be disabled until the clock
switching is completed.
Table 7-1. System clock selection.
7.9.2 PSCTRL – Prescaler register
This register is protected by the configuration change protection mechanism. For details, refer to “Configuration Change
Protection” on page 13.
z Bit 7 – Reserved
This bit is unused and reserved for future use. For compatibility with future devices, always write this bit to zero when this
register is written.
Bit 7 6 5 4 3 2 1 0
+0x00 – – – – – SCLKSEL[2:0]
Read/Write R R R R R R/W R/W R/W
Initial Value 0 0 0 00000
SCLKSEL[2:0] Group Configuration Description
000 RC2MHZ 2MHz internal oscillator
001 RC32MHZ 32MHz internal oscillator
010 RC32KHZ 32.768kHz internal oscillator
011 XOSC External oscillator or clock
100 PLL Phase locked loop
101 – Reserved
110 – Reserved
111 – Reserved
Bit 7 6 5 4 3 2 1 0
+0x01 – PSADIV[4:0] PSBCDIV
Read/Write R R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 84
8291C–AVR–09/2014
z Bit 6:2 – PSADIV[4:0]: Prescaler A Division Factor
These bits define the division ratio of the clock prescaler A according to Table 7-2. These bits can be written at run-time
to change the frequency of the ClkPER4 clock relative to the system clock, ClkSYS.
Table 7-2. Prescaler A division factor.
z Bit 1:0 – PSBCDIV: Prescaler B and C Division Factors
These bits define the division ratio of the clock prescalers B and C according to Table 7-3. Prescaler B will set the clock
frequency for the ClkPER2 clock relative to the ClkPER4 clock. Prescaler C will set the clock frequency for the ClkPER and
ClkCPU clocks relative to the ClkPER2 clock. Refer to Figure 7-5 on page 79 fore more details.
Table 7-3. Prescaler B and C division factors.
PSADIV[4:0] Group Configuration Description
00000 1 No division
00001 2 Divide by 2
00011 4 Divide by 4
00101 8 Divide by 8
00111 16 Divide by 16
01001 32 Divide by 32
01011 64 Divide by 64
01101 128 Divide by 128
01111 256 Divide by 256
10001 512 Divide by 512
10101 – Reserved
10111 – Reserved
11001 – Reserved
11011 – Reserved
11101 – Reserved
11111 – Reserved
PSBCDIV[1:0] Group Configuration Prescaler B division Prescaler C division
00 1_1 No division No division
01 1_2 No division Divide by 2
10 4_1 Divide by 4 No division
11 2_2 Divide by 2 Divide by 2
XMEGA B [MANUAL] 85
8291C–AVR–09/2014
7.9.3 LOCK – Lock register
z Bit 7:1 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 0 – LOCK: Clock System Lock
When this bit is written to one, the CTRL and PSCTRL registers cannot be changed, and the system clock selection and
prescaler settings are protected against all further updates until after the next reset. This bit is protected by the
configuration change protection mechanism. For details, refer to “Configuration Change Protection” on page 13.
The LOCK bit can be cleared only by a reset.
7.9.4 RTCCTRL – RTC Control register
z Bit 7:4 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 3:1 – RTCSRC[2:0]: RTC Clock Source
These bits select the clock source for the real-time counter according to Table 7-4.
Table 7-4. RTC clock source selection.
z Bit 0 – RTCEN: RTC Clock Source Enable
Setting the RTCEN bit enables the selected RTC clock source for the real-time counter.
Bit 7 6 5 4 3 2 1 0
+0x02 – – – – – – – LOCK
Read/Write R R R R R R R R/W
Initial Value 00000000
Bit 7 6 5 4 3 2 1 0
+0x03 – – – – RTCSRC[2:0] RTCEN
Read/Write R R R R R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
RTCSRC[2:0] Group Configuration Description
000 ULP 1kHz from 32kHz internal ULP oscillator
001 TOSC 1.024kHz from 32.768kHz crystal oscillator on TOSC
010 RCOSC 1.024kHz from 32.768kHz internal oscillator
011 — Reserved
100 — Reserved
101 TOSC32 32.768kHz from 32.768kHz crystal oscillator on TOSC
110 RCOSC32 32.768kHz from 32.768kHz internal oscillator
111 EXTCLK External clock from TOSC1
XMEGA B [MANUAL] 86
8291C–AVR–09/2014
7.9.5 USBSCTRL – USB Control register
z Bit 7:6 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 5:3 – USBPSDIV[2:0]: USB Prescaler Division Factor
These bits define the division ratio of the USB clock prescaler according to Table 7-5. These bits are locked as long as
the USB clock source is enabled.
Table 7-5. USB prescaler division factor.
z Bit 2:1 – USBSRC[1:0]: USB Clock Source
These bits select the clock source for the USB module according to Table 7-6.
Table 7-6. USB clock source.
Note: 1. The 32MHz internal oscillator must be calibrated to 48MHz before selecting this as source for the USB device module. Refer to “DFLL 2MHz and
DFLL 32MHz” on page 80.
z Bit 0 – USBSEN: USB Clock Source Enable
Setting this bit enables the selected clock source for the USB device module.
Bit 7 6 5 4 3 2 1 0
+0x04 – – USBPSDIV[2:0] USBSRC[1:0] USBSEN
Read/Write R R R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
USBPSDIV[2:0] Group Configuration Description
000 1 No division
001 2 Divide by 2
010 4 Divide by 4
011 8 Divide by 8
100 16 Divide by 16
101 32 Divide by 32
110 — Reserved
111 — Reserved
USBSRC[1:0] Group Configuration Description
00 PLL PLL
01 RC32M 32MHz internal oscillator(1)
XMEGA B [MANUAL] 87
8291C–AVR–09/2014
7.10 Register Description – Oscillator
7.10.1 CTRL – Oscillator Control register
z Bit 7:5 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 4 – PLLEN: PLL Enable
Setting this bit enables the PLL. Before the PLL is enabled, it must be configured with the desired multiplication factor
and clock source. See ”STATUS – Oscillator Status register” on page 87.
z Bit 3 – XOSCEN: External Oscillator Enable
Setting this bit enables the selected external clock source. Refer to “XOSCCTRL – XOSC Control register” on page 88
for details on how to select the external clock source. The external clock source should be allowed time to stabilize
before it is selected as the source for the system clock. See ”STATUS – Oscillator Status register” on page 87.
z Bit 2 – RC32KEN: 32.768kHz Internal Oscillator Enable
Setting this bit enables the 32.768kHz internal oscillator. The oscillator must be stable before it is selected as the source
for the system clock. See ”STATUS – Oscillator Status register” on page 87.
z Bit 1 – RC32MEN: 32MHz Internal Oscillator Enable
Setting this bit will enable the 32MHz internal oscillator. The oscillator must be stable before it is selected as the source
for the system clock. See ”STATUS – Oscillator Status register” on page 87.
z Bit 0 – RC2MEN: 2MHz Internal Oscillator Enable
Setting this bit enables the 2MHz internal oscillator. The oscillator must be stable before it is selected as the source for
the system clock. See ”STATUS – Oscillator Status register” on page 87.
By default, the 2MHz internal oscillator is enabled and this bit is set.
7.10.2 STATUS – Oscillator Status register
z Bit 7:5 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 4 – PLLRDY: PLL Ready
This flag is set when the PLL has locked on the selected frequency and is ready to be used as the system clock source.
z Bit 3 – XOSCRDY: External Clock Source Ready
This flag is set when the external clock source is stable and is ready to be used as the system clock source.
z Bit 2 – RC32KRDY: 32.768kHz Internal Oscillator Ready
This flag is set when the 32.768kHz internal oscillator is stable and is ready to be used as the system clock source.
Bit 7 6 5 4 3 2 1 0
+0x00 – – – PLLEN XOSCEN RC32KEN RC32MEN RC2MEN
Read/Write R R R R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 1
Bit 7 6 5 4 3 2 1 0
+0x01 – – – PLLRDY XOSCRDY RC32KRDY RC32MRDY RC2MRDY
Read/Write R R R R R R R R
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 88
8291C–AVR–09/2014
z Bit 1 – RC32MRDY: 32MHz Internal Oscillator Ready
This flag is set when the 32MHz internal oscillator is stable and is ready to be used as the system clock source.
z Bit 0 – RC2MRDY: 2MHz Internal Oscillator Ready
This flag is set when the 2MHz internal oscillator is stable and is ready to be used as the system clock source.
7.10.3 XOSCCTRL – XOSC Control register
z Bit 7:6 – FRQRANGE[1:0]: 0.4 - 16MHz Crystal Oscillator Frequency Range Select
These bits select the frequency range for the connected crystal oscillator according to Table 7-7.
Table 7-7. 16MHz crystal oscillator frequency range selection.
z Bit 5 – X32KLPM: Crystal Oscillator 32.768kHz Low Power Mode
Setting this bit enables the low power mode for the 32.768kHz crystal oscillator. This will reduce the swing on the TOSC2
pin.
z Bit 4 – XOSCPWR: Crystal Oscillator Drive
Setting this bit will increase the current in the 0.4MHz - 16MHz crystal oscillator and increase the swing on the XTAL2
pin. This allows for driving crystals with higher load or higher frequency than specified by the FRQRANGE bits.
z Bit 3:0 – XOSCSEL[3:0]: Crystal Oscillator Selection
These bits select the type and start-up time for the crystal or resonator that is connected to the XTAL or TOSC pins. See
Table 7-8 on page 89 for crystal selections. If an external clock or external oscillator is selected as the source for the
system clock, see “CTRL – Oscillator Control register” on page 87. This configuration cannot be changed.
Bit 7 6 5 4 3 2 1 0
+0x02 FRQRANGE[1:0] X32KLPM XOSCPWR XOSCSEL[3:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0000
FRQRANGE[1:0] Group Configuration Typical Frequency Range
Recommended Range for
Capacitors C1 and C2 (pF)
00 04TO2 0.4MHz - 2MHz 100-300
01 2TO9 2MHz - 9MHz 10-40
10 9TO12 9MHz - 12MHz 10-40
11 12TO16 12MHz - 16MHz 10-30
XMEGA B [MANUAL] 89
8291C–AVR–09/2014
Table 7-8. External oscillator selection and start-up time..
Notes: 1. This option should be used only when frequency stability at startup is not important for the application. The option is not suitable for crystals.
2. This option is intended for use with ceramic resonators. It can also be used when the frequency stability at startup is not important for the
application.
3. When the external oscillator is used as the reference for a DFLL, only EXTCLK and 32KHZ can be selected.
7.10.4 XOSCFAIL – XOSC Failure Detection register
z Bit 7:4 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 3 – PLLFDIF: PLL Fault Detection Flag
If PLL failure detection is enabled, PLLFDIF is set when the PLL looses lock. Writing logic one to this location will clear
PLLFDIF.
z Bit 2 – PLLFDEN: PLL Fault Detection Enable
Setting this bit will enable PLL failure detection. A non-maskable interrupt will be issued when PLLFDIF is set.
This bit is protected by the configuration change protection mechanism. Refer to “Configuration Change Protection” on
page 13 for details.
z Bit 1 – XOSCFDIF: Failure Detection Interrupt Flag
If the external clock source oscillator failure monitor is enabled, XOSCFDIF is set when a failure is detected. Writing logic
one to this location will clear XOSCFDIF.
z Bit 0 – XOSCFDEN: Failure Detection Enable
Setting this bit will enable the failure detection monitor, and a non-maskable interrupt will be issued when XOSCFDIF is
set.
This bit is protected by the configuration change protection mechanism. Refer to “Configuration Change Protection” on
page 13 for details. Once enabled, failure detection can only be disabled by a reset.
XOSCSEL[3:0] Group Configuration Selected Clock Source Start-up Time
0000 EXTCLK(3) External Clock 6 CLK
0010 32KHZ(3) 32.768kHz TOSC 16K CLK
0011 XTAL_256CLK(1) 0.4MHz - 16MHz XTAL 256 CLK
0111 XTAL_1KCLK(2) 0.4MHz - 16MHz XTAL 1K CLK
1011 XTAL_16KCLK 0.4MHz - 16MHz XTAL 16K CLK
Bit 7 6 5 4 3 2 1 0
+0x03 – – – – PLLFDIF PLLFDEN XOSCFDIF XOSCFDEN
Read/Write R R R R R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 90
8291C–AVR–09/2014
7.10.5 RC32KCAL – 32kHz Oscillator Calibration register
z Bit 7:0 – RC32KCAL[7:0]: 32.768kHz Internal Oscillator Calibration bits
This register is used to calibrate the 32.768kHz internal oscillator. A factory-calibrated value is loaded from the signature
row of the device and written to this register during reset, giving an oscillator frequency close to 32.768kHz. The register
can also be written from software to calibrate the oscillator frequency during normal operation.
7.10.6 PLLCTRL – PLL Control register
z Bit 7:6 – PLLSRC[1:0]: Clock Source
The PLLSRC bits select the input source for the PLL according to Table 7-9.
Table 7-9. PLL clock source.
Notes: 1. The 32.768kHz TOSC cannot be selected as the source for the PLL. An external clock must be a minimum 0.4MHz to be used as the source clock.
z Bit 5 – PLLDIV: PLL Divided Output Enable
Setting this bit will divide the output from the PLL by 2.
z Bit 4:0 – PLLFAC[4:0]: Multiplication Factor
These bits select the multiplication factor for the PLL. The multiplication factor can be in the range of from 1x to 31x.
7.10.7 DFLLCTRL – DFLL Control register
z Bit 7:3 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
Bit 7 6 5 4 3 2 1 0
+0x04 RC32KCAL[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value x xxxxxxx
Bit 7 6 5 4 3 2 1 0
+0x05 PLLSRC[1:0] PLLDIV PLLFAC[4:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
PLLSRC[1:0] Group Configuration PLL Input Source
00 RC2M 2MHz internal oscillator
01 — Reserved
10 RC32M 32MHz internal oscillator
11 XOSC External clock source(1)
Bit 7 6 5 4 3 2 1 0
+0x06 – – – – – RC32MCREF[1:0] RC2MCREF
Read/Write R R R R R R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 91
8291C–AVR–09/2014
z Bit 2:1 – RC32MCREF[1:0]: 32MHz Oscillator Calibration Reference
These bits are used to select the calibration source for the 32MHz DFLL according to the Table 7-10. These bits will
select only which calibration source to use for the DFLL. In addition, the actual clock source that is selected must enabled
and configured for the calibration to function.
Table 7-10. 32MHz oscillator reference selection.
z Bit 0 – RC2MCREF: 2MHz Oscillator Calibration Reference
This bit is used to select the calibration source for the 2MHz DFLL. By default, this bit is zero and the 32.768kHz internal
oscillator is selected. If this bit is set to one, the 32.768kHz crystal oscillator on TOSC is selected as the reference. This
bit will select only which calibration source to use for the DFLL. In addition, the actual clock source that is selected must
enabled and configured for the calibration to function.
7.11 Register Description – DFLL32M/DFLL2M
7.11.1 CTRL – DFLL Control register
z Bit 7:1 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 0 – ENABLE: DFLL Enable
Setting this bit enables the DFLL and auto-calibration of the internal oscillator. The reference clock must be enabled and
stable before the DFLL is enabled.
After disabling the DFLL, the reference clock can not be disabled before the ENABLE bit is read as zero.
RC32MCREF[1:0] Group Configuration Description
00 RC32K 32.768kHz internal oscillator
01 XOSC32 32.768kHz crystal oscillator on TOSC
10 USBSOF USB start of frame
11 – Reserved
Bit 7 6 5 4 3 2 1 0
+0x00 – – – – – – – ENABLE
Read/Write R R R R R R R R/W
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 92
8291C–AVR–09/2014
7.11.2 CALA – DFLL Calibration Register A
The CALA and CALB registers hold the 13-bit DFLL calibration value that is used for automatic run-time calibration of the
internal oscillator. When the DFLL is disabled, the calibration registers can be written by software for manual run-time
calibration of the oscillator. The oscillators will also be calibrated according to the calibration value in these registers
when the DFLL is disabled.
z Bit 7 – Reserved
This bit is unused and reserved for future use. For compatibility with future devices, always write this bit to zero when this
register is written.
z Bit 6:0 – CALA[6:0]: DFLL Calibration Bits
These bits hold the part of the oscillator calibration value that is used for automatic runtime calibration. A factorycalibrated
value is loaded from the signature row of the device and written to this register during reset, giving an oscillator
frequency approximate to the nominal frequency for the oscillator. The bits cannot be written when the DFLL is enabled.
7.11.3 CALB – DFLL Calibration register B
z Bit 7:6 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 5:0 – CALB[5:0]: DFLL Calibration bits
These bits hold the part of the oscillator calibration value that is used to select the oscillator frequency. A factorycalibrated
value is loaded from the signature row of the device and written to this register during reset, giving an oscillator
frequency approximate to the nominal frequency for the oscillator. These bits are not changed during automatic run-time
calibration of the oscillator. The bits cannot be written when the DFLL is enabled. When calibrating to a frequency
different from the default, the CALA bits should be set to a middle value to maximize the range for the DFLL.
7.11.4 COMP1 – DFLL Compare register 1
The COMP1 and COMP2 register pair represent the frequency ratio between the oscillator and the reference clock. The
initial value for these registers is the ratio between the internal oscillator frequency and a 1.024kHz reference
z Bit 7:0 – COMP1[7:0]: Compare value byte 1
These bits hold byte 1 of the 16-bit compare register.
Bit 7 6 5 4 3 2 1 0
+0x02 – CALA[6:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 x x x x x x x
Bit 7 6 5 4 3 2 1 0
+0x03 – – CALB[5:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 x x x x x x
Bit 7 6 5 4 3 2 1 0
+0x05 COMP[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 93
8291C–AVR–09/2014
7.11.5 COMP2 – DFLL Compare register 2
z Bit 7:0 – COMP2[15:8]: Compare Register value byte 2
These bits hold byte 2 of the 16-bit compare register.
Table 7-11. Nominal DFLL32M COMP values for different output frequencies.
Bit 7 6 5 4 3 2 1 0
+0x06 COMP[15:8]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 00000000
Oscillator Frequency (MHz) COMP Value (ClkRCnCREF = 1.024kHz)
30.0 0x7270
32.0 0x7A12
34.0 0x81B3
36.0 0x8954
38.0 0x90F5
40.0 0x9896
42.0 0xA037
44.0 0xA7D8
46.0 0xAF79
48.0 0xB71B
50.0 0xBEBC
52.0 0xC65D
54.0 0xCDFE
XMEGA B [MANUAL] 94
8291C–AVR–09/2014
7.12 Register Summary - Clock
7.13 Register Summary - Oscillator
7.14 Register Summary - DFLL32M/DFLL2M
7.15 Oscillator Failure Interrupt Vector Summary
Address Name Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 Page
+0x00 CTRL – – – – – SCLKSEL[2:0] 83
+0x01 PSCTRL – PSADIV[4:0] PSBCDIV[1:0] 83
+0x02 LOCK – – – – – – – LOCK 85
+0x03 RTCCTRL – – – – RTCSRC[2:0] RTCEN 85
+0x04 USBSCTR – – USBPSDIV[2:0] USBSRC[1:0] USBSEN 85
+0x05 Reserved – – – – – – – –
+0x06 Reserved – – – – – – – –
+0x07 Reserved – – – – – – – –
Address Name Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 Page
+0x00 CTRL – – – PLLEN XOSCEN RC32KEN R32MEN RC2MEN 87
+0x01 STATUS – – – PLLRDY XOSCRDY RC32KRD R32MRDY RC2MRDY 87
+0x02 XOSCCTR FRQRANGE[1:0] X32KLPM XOSCPW XOSCSEL[3:0] 88
+0x03 XOSCFAIL – – – – PLLFDIF PLLFDEN XOSCFDIF XOSCFDEN 89
+0x04 RC32KCAL RC32KCAL[7:0] 90
+0x05 PLLCTRL PLLSRC[1:0] – PLLFAC[4:0] 90
+0x06 DFLLCTRL – – – – – RC32MCREF[1:0] RC2MCREF 90
+0x07 Reserved – – – – – – – –
Address Name Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 Page
+0x00 CTRL – – – – – – – ENABLE 91
+0x01 Reserved – – – – – – – –
+0x02 CALA – CALA[6:0] 92
+0x03 CALB – – CALB[5:0] 92
+0x04 Reserved – – – – – – – –
+0x05 COMP1 COMP[7:0] 92
+0x06 COMP2 COMP[15:8] 93
+0x07 Reserved – – – – – – – –
Offset Source Interrupt Description
0x00 OSCF_vect PLL and external oscillator failure interrupt vector (NMI)
XMEGA B [MANUAL] 95
Atmel-8291C-AVR-XMEGA B -09/2014
8. Power Management and Sleep Modes
8.1 Features
z Power management for adjusting power consumption and functions
z Five sleep modes
z Idle
z Power down
z Power save
z Standby
z Extended standby
z Power reduction register to disable clock and turn off unused peripherals in active and idle modes
8.2 Overview
Various sleep modes and clock gating are provided in order to tailor power consumption to application requirements.
This enables the XMEGA microcontroller to stop unused modules to save power.
All sleep modes are available and can be entered from active mode. In active mode, the CPU is executing application
code. When the device enters sleep mode, program execution is stopped and interrupts or a reset is used to wake the
device again. The application code decides which sleep mode to enter and when. Interrupts from enabled peripherals
and all enabled reset sources can restore the microcontroller from sleep to active mode.
In addition, power reduction registers provide a method to stop the clock to individual peripherals from software. When
this is done, the current state of the peripheral is frozen, and there is no power consumption from that peripheral. This
reduces the power consumption in active mode and idle sleep modes and enables much more fine-tuned power
management than sleep modes alone.
8.3 Sleep Modes
Sleep modes are used to shut down modules and clock domains in the microcontroller in order to save power. XMEGA
microcontrollers have five different sleep modes tuned to match the typical functional stages during application
execution. A dedicated sleep instruction (SLEEP) is available to enter sleep mode. Interrupts are used to wake the
device from sleep, and the available interrupt wake-up sources are dependent on the configured sleep mode. When an
enabled interrupt occurs, the device will wake up and execute the interrupt service routine before continuing normal
program execution from the first instruction after the SLEEP instruction. If other, higher priority interrupts are pending
when the wake-up occurs, their interrupt service routines will be executed according to their priority before the interrupt
service routine for the wake-up interrupt is executed. After wake-up, the CPU is halted for four cycles before execution
starts.
Table 8-1 on page 96 shows the different sleep modes and the active clock domains, oscillators, and wake-up sources.
XMEGA B [MANUAL] 96
Atmel-8291C-AVR-XMEGA B -09/2014
Table 8-1. Active clock domains and wake-up sources in the different sleep modes.
The wake-up time for the device is dependent on the sleep mode and the main clock source. The startup time for the
system clock source must be added to the wake-up time for sleep modes where the system clock source is not kept
running. For details on the startup time for the different oscillator options, refer to “System Clock and Clock Options” on
page 77.
The content of the register file, SRAM and registers are kept during sleep. If a reset occurs during sleep, the device will
reset, start up, and execute from the reset vector.
8.3.1 Idle Mode
In idle mode the CPU and nonvolatile memory are stopped (note that any ongoing programming will be completed), but
all peripherals, including the interrupt controller, event system and DMA controller are kept running. Any enabled
interrupt will wake the device.
8.3.2 Power-down Mode
In power-down mode, all clocks, including the real-time counter clock source, are stopped. This allows operation only of
asynchronous modules that do not require a running clock. The only interrupts that can wake up the MCU are the twowire
interface address match interrupt, asynchronous port interrupts, and the USB resume interrupt.
8.3.3 Power-save Mode
Power-save mode is identical to power down, with two exceptions:
1. If the real-time counter (RTC) is enabled, it will keep running during sleep, and the device can also wake up from
either an RTC overflow or compare match interrupt.
2. If the LCD is enabled, it will keep running during sleep, and the device can wake up from LCD frame completed
interrupt.
8.3.4 Standby Mode
Standby mode is identical to power down, with the exception that the enabled system clock sources are kept running
while the CPU, peripheral, and RTC/LCD clocks are stopped. This reduces the wake-up time.
Active Clock Domain Oscillators Wake-up Sources
Sleep Modes
CPU Clock
Peripheral and USB Clock
RTC and LCD Clock
System Clock Source
RTC Clock Source
USB Resume
Asynchronous Port Interrupts
TWI Address Match Interrupts
RTC and LCD Clock Interrupts
All Interrupts
Idle X X X X X X X X X
Power down X X X
Power save X X X X X X
Standby X X X X
Extended standby X X X X X X X
XMEGA B [MANUAL] 97
Atmel-8291C-AVR-XMEGA B -09/2014
8.3.5 Extended Standby Mode
Extended standby mode is identical to power-save mode, with the exception that the enabled system clock sources are
kept running while the CPU and peripheral clocks are stopped. This reduces the wake-up time.
8.4 Power Reduction Registers
The power reduction (PR) registers provide a method to stop the clock to individual peripherals. When this is done, the
current state of the peripheral is frozen and the associated I/O registers cannot be read or written. Resources used by the
peripheral will remain occupied; hence, the peripheral should be disabled before stopping the clock. Enabling the clock to
a peripheral again puts the peripheral in the same state as before it was stopped. This can be used in idle mode and
active modes to reduce the overall power consumption. In all other sleep modes, the peripheral clock is already stopped.
Not all devices have all the peripherals associated with a bit in the power reduction registers. Setting a power reduction
bit for a peripheral that is not available will have no effect.
8.5 Minimizing Power Consumption
There are several possibilities to consider when trying to minimize the power consumption in an AVR MCU controlled
system. In general, correct sleep modes should be selected and used to ensure that only the modules required for the
application are operating.
All unneeded functions should be disabled. In particular, the following modules may need special consideration when
trying to achieve the lowest possible power consumption.
8.5.1 Analog-to-Digital Converter - ADC
When entering idle mode, the ADC should be disabled if not used. In other sleep modes, the ADC is automatically
disabled. When the ADC is turned off and on again, the next conversion will be an extended conversion. Refer to “ADC –
Analog-to-Digital Converter” on page 326 for details on ADC operation.
8.5.2 Analog Comparator - AC
When entering idle mode, the analog comparator should be disabled if not used. In other sleep modes, the analog
comparator is automatically disabled. However, if the analog comparator is set up to use the internal voltage reference as
input, the analog comparator should be disabled in all sleep modes. Otherwise, the internal voltage reference will be
enabled, irrespective of sleep mode. Refer to “AC – Analog Comparator” on page 352 for details on how to configure the
analog comparator.
8.5.3 Brownout Detector
If the brownout detector is not needed by the application, this module should be turned off. If the brownout detector is
enabled by the BODLEVEL fuses, it will be enabled in all sleep modes, and always consume power. In the deeper sleep
modes, it can be turned off and set in sampled mode to reduce current consumption. Refer to “Brownout Detection” on
page 109 for details on how to configure the brownout detector.
8.5.4 Watchdog Timer
If the watchdog timer is not needed in the application, the module should be turned off. If the watchdog timer is enabled,
it will be enabled in all sleep modes and, hence, always consume power. Refer to “WDT – Watchdog Timer” on page 115
for details on how to configure the watchdog timer.
8.5.5 Port Pins
When entering a sleep mode, all port pins should be configured to use minimum power. Most important is to ensure that
no pins drive resistive loads. In sleep modes where the Peripheral Clock (ClkPER) is stopped, the input buffers of the
device will be disabled. This ensures that no power is consumed by the input logic when not needed.
8.5.6 On-chip Debug Systems
If the On-chip debug system is enabled and the chip enters sleep mode, the main clock source is enabled and hence
always consumes power. In the deeper sleep modes, this will contribute significantly to the total current consumption.
XMEGA B [MANUAL] 98
Atmel-8291C-AVR-XMEGA B -09/2014
8.6 Register Description – Sleep
8.6.1 CTRL – Control Register
z Bit 7:4 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 3:1 – SMODE[2:0]: Sleep Mode selection
These bits select sleep modes according to Table 8-2.
Table 8-2. Sleep mode selection.
z Bit 0 – SEN: Sleep Enable
This bit must be set to make the MCU enter the selected sleep mode when the SLEEP instruction is executed. To avoid
unintentional entering of sleep modes, it is recommended to write SEN just before executing the SLEEP instruction and
clear it immediately after waking up.
8.7 Register Description – Power Reduction
8.7.1 PRGEN – General Power Reduction register
z Bit 7 – LCD: LCD Module
Setting this bit stops the clock to the LCD module. When the bit is cleared the peripheral should be reinitialized to ensure
proper operation.
Bit 7 6 5 4 3 2 1 0
+0x00 – – – – SMODE[2:0] SEN
Read/Write R R R R R/W R/W R/W R/W
Initial Value 00000000
SMODE[2:0] Group configuration Description
000 IDLE Idle mode
001 – Reserved
010 PDOWN Power-down mode
011 PSAVE Power-save mode
100 – Reserved
101 – Reserved
110 STDBY Standby mode
111 ESTDBY Extended standby mode
Bit 7 6 5 4 3 2 1 0
+0x00 LCD USB – AES – RTC EVSYS DMA
Read/Write R/W R/W R R/W R R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 99
Atmel-8291C-AVR-XMEGA B -09/2014
z Bit 6 – USB: USB Module
Setting this bit stops the clock to the USB module. When this bit is cleared, the peripheral should be reinitialized to
ensure proper operation.
z Bit 5 – Reserved
This bit is unused and reserved for future use. For compatibility with future devices, always write this bit to zero when this
register is written.
z Bit 4 – AES: AES Module
Setting this bit stops the clock to the AES module. When this bit is cleared, the peripheral should be reinitialized to
ensure proper operation.
z Bit 3 – Reserved
This bit is unused and reserved for future use. For compatibility with future devices, always write this bit to zero when this
register is written.
z Bit 2 – RTC: Real-Time Counter
Setting this bit stops the clock to the real-time counter. When this bit is cleared, the peripheral should be reinitialized to
ensure proper operation.
z Bit 1 – EVSYS: Event System
Setting this stops the clock to the event system. When this bit is cleared, the module will continue as before it was
stopped.
z Bit 0 – DMA: DMA Controller
Setting this bit stops the clock to the DMA controller. This bit can be set only if the DMA controller is disabled.
8.7.2 PRPA/B – Power Reduction Port A/B register
Note: Disabling of analog modules stops the clock to the analog blocks themselves and not only the interfaces.
z Bit 7:2 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 1 – ADC: Power Reduction ADC
Setting this bit stops the clock to the ADC. The ADC should be disabled before stopped.
z Bit 0 – AC: Power Reduction Analog Comparator
Setting this bit stops the clock to the analog comparator. The AC should be disabled before shutdown.
8.7.3 PRPC/E – Power Reduction Port C/E Register
z Bit 7 – Reserved
This bit is unused and reserved for future use. For compatibility with future devices, always write this bit to zero when this
register is written.
Bit 7 6 5 4 3 2 1 0
+0x01/+0x02 – – – – – – ADC AC
Read/Write R R R R R R R/W R/W
Initial Value 0 0 0 0 0 0 0 0
Bit 7 6 5 4 3 2 1 0
+0x03/+0x04/
+0x05/+0x06 – TWI – USART0 SPI HIRES TC1 TC0
Read/Write R R/W R R/W R/W R/W R/W R/W
Initial Value 0 0000000
XMEGA B [MANUAL] 100
Atmel-8291C-AVR-XMEGA B -09/2014
z Bit 6 – TWI: Two-Wire Interface
Setting this bit stops the clock to the two-wire interface. When this bit is cleared, the peripheral should be reinitialized to
ensure proper operation.
z Bit 5 – Reserved
This bit is unused and reserved for future use. For compatibility with future devices, always write this bit to zero when this
register is written.
z Bit 4 – USART0
Setting this bit stops the clock to USART0. When this bit is cleared, the peripheral should be reinitialized to ensure proper
operation.
z Bit 3 – SPI: Serial Peripheral Interface
Setting this bit stops the clock to the SPI. When this bit is cleared, the peripheral should be reinitialized to ensure proper
operation.
z Bit 2 – HIRES: High-Resolution Extension
Setting this bit stops the clock to the high-resolution extension for the timer/counters. When this bit is cleared, the
peripheral should be reinitialized to ensure proper operation.
z Bit 1 – TC1: Timer/Counter 1
Setting this bit stops the clock to timer/counter 1. When this bit is cleared, the peripheral will continue like before the shut
down.
z Bit 0 – TC0: Timer/Counter 0
Setting this bit stops the clock to timer/counter 0. When this bit is cleared, the peripheral will continue like before the shut
down.
XMEGA B [MANUAL] 101
Atmel-8291C-AVR-XMEGA B -09/2014
8.8 Register Summary - Sleep
8.9 Register Summary - Power Reduction
Address Name Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 Page
+0x00 CTRL – – – – SMODE[2:0] SEN 98
Address Name Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 Page
+0x00 PRGEN LCD USB – AES – RTC EVSYS DMA 98
+0x01 PRPA – – – – – – ADC AC 99
+0x02 PRPB – – – – – – ADC AC 99
+0x03 PRPC – TWI – USART0 SPI HIRES TC1 TC0 99
+0x04 Reserved – – – – – – – –
+0x05 PRPE – – – USART0 – – – TC0 99
XMEGA B [MANUAL] 102
Atmel-8291C-AVR-XMEGA B -09/2014
9. Reset System
9.1 Features
z Reset the microcontroller and set it to initial state when a reset source goes active
z Multiple reset sources that cover different situations
z Power-on reset
z External reset
z Watchdog reset
z Brownout reset
z PDI reset
z Software reset
z Asynchronous operation
z No running system clock in the device is required for reset
z Reset status register for reading the reset source from the application code
9.2 Overview
The reset system issues a microcontroller reset and sets the device to its initial state. This is for situations where
operation should not start or continue, such as when the microcontroller operates below its power supply rating. If a reset
source goes active, the device enters and is kept in reset until all reset sources have released their reset. The I/O pins
are immediately tri-stated. The program counter is set to the reset vector location, and all I/O registers are set to their
initial values. The SRAM content is kept. However, if the device accesses the SRAM when a reset occurs, the content of
the accessed location can not be guaranteed.
After reset is released from all reset sources, the default oscillator is started and calibrated before the device starts
running from the reset vector address. By default, this is the lowest program memory address, 0, but it is possible to
move the reset vector to the lowest address in the boot section.
The reset functionality is asynchronous, and so no running system clock is required to reset the device. The software
reset feature makes it possible to issue a controlled system reset from the user software.
The reset status register has individual status flags for each reset source. It is cleared at power-on reset, and shows
which sources have issued a reset since the last power-on.
An overview of the reset system is shown in Figure 9-1 on page 103.
XMEGA B [MANUAL] 103
Atmel-8291C-AVR-XMEGA B -09/2014
Figure 9-1. Reset system overview.
9.3 Reset Sequence
A reset request from any reset source will immediately reset the device and keep it in reset as long as the request is
active. When all reset requests are released, the device will go through three stages before the device starts running
again:
z Reset counter delay
z Oscillator startup
z Oscillator calibration
If another reset requests occurs during this process, the reset sequence will start over again.
9.3.1 Reset Counter
The reset counter can delay reset release with a programmable period from when all reset requests are released. The
reset delay is timed from the 1kHz output of the ultra low power (ULP) internal oscillator, and in addition 24 System clock
(clkSYS) cycles are counted before reset is released. The reset delay is set by the STARTUPTIME fuse bits. The
selectable delays are shown in Table 9-1.
Table 9-1. Reset delay
MCU Status
Register (MCUSR)
Brown-out
BODLEVEL [2:0] Reset
Delay Counters TIMEOUT
PORF
BORF
EXTRF
WDRF
ULP
Oscillator
SPIKE
FILTER
Pull-up Resistor
JTRF
Watchdog
Reset
SUT[1:0]
Power-on Reset
Software
Reset
External
Reset
PDI
Reset
SUT[1:0] Number of 1kHz ULP Oscillator Clock Cycles Recommended Usage
00 64K ClkULP+ 24 ClkSYS Stable frequency at startup
01 4K ClkULP + 24 ClkSYS Slowly rising power
10 Reserved -
11 24 ClkSYS Fast rising power or BOD enabled
XMEGA B [MANUAL] 104
Atmel-8291C-AVR-XMEGA B -09/2014
Whenever a reset occurs, the clock system is reset and the internal 2MHz internal oscillator is chosen as the source for
ClkSYS.
9.3.2 Oscillator Startup
After the reset delay, the 2MHz internal oscillator clock is started, and its calibration values are automatically loaded from
the calibration row to the calibration registers.
9.4 Reset Sources
9.4.1 Power-on Reset
A power-on reset (POR) is generated by an on-chip detection circuit. The POR is activated when the VCC rises and
reaches the POR threshold voltage (VPOT), and this will start the reset sequence.
The POR is also activated to power down the device properly when the VCC falls and drops below the VPOT level.
The VPOT level is higher for falling VCCthan for rising VCC. Consult the datasheet for POR characteristics data.
Figure 9-2. MCU startup, RESET tied to VCC.
Figure 9-3. MCU startup, RESET extended externally,
9.4.2 Brownout Detection
The on-chip brownout detection (BOD) circuit monitors the VCC level during operation by comparing it to a fixed,
programmable level that is selected by the BODLEVEL fuses. If disabled, BOD is forced on at the lowest level during chip
erase and when the PDI is enabled.
When the BOD is enabled and VCC decreases to a value below the trigger level (VBOT- in Figure 9-4), the brownout reset
is immediately activated.
V
RESET
TIME-OUT
INTERNAL
RESET
t
TOUT
VPOT
VRST
CC
RESET
TIME-OUT
INTERNAL
RESET
t
TOUT
VPOT
VRST
VCC
XMEGA B [MANUAL] 105
Atmel-8291C-AVR-XMEGA B -09/2014
When VCC increases above the trigger level (VBOT+ in Figure 9-4), the reset counter starts the MCU after the timeout
period, tTOUT, has expired.
The trigger level has a hysteresis to ensure spike free brownout detection. The hysteresis on the detection level should
be interpreted as VBOT+= VBOT + VHYST/2 and VBOT- = VBOT - VHYST/2.
The BOD circuit will detect a drop in VCC only if the voltage stays below the trigger level for longer than tBOD.
Figure 9-4. Brownout detection reset.
For BOD characterization data consult the device datasheet. The programmable BODLEVEL setting is shown in Table 9-
2.
Table 9-2. Programmable BODLEVEL setting.
Notes: 1. The values are nominal values only. For accurate, actual numbers, consult the device datasheet.
2. Changing these fuse bits will have no effect until leaving programming mode.
The BOD circuit has three modes of operation:
z Disabled: In this mode, there is no monitoring of the VCC level.
z Enabled: In this mode, the VCC level is continuously monitored, and a drop in VCC below VBOT for a period of tBOD
will give a brownout reset
z Sampled: In this mode, the BOD circuit will sample the VCC level with a period identical to that of the 1kHz output
from the ultra low power (ULP) internal oscillator. Between each sample, the BOD is turned off. This mode will
BOD level Fuse BODLEVEL[2:0](2) VBOT(1) Unit
BOD level 0 111 1.6
V
BOD level 1 110 1.8
BOD level 2 101 2.0
BOD level 3 100 2.2
BOD level 4 011 2.4
BOD level 5 010 2.6
BOD level 6 001 2.8
BOD level 7 000 3.0
VCC
TIME-OUT
INTERNAL
RESET
VBOTVBOT+
t
TOUT
t
BOD
XMEGA B [MANUAL] 106
Atmel-8291C-AVR-XMEGA B -09/2014
reduce the power consumption compared to the enabled mode, but a fall in the VCC level between two positive
edges of the 1kHz ULP oscillator output will not be detected. If a brownout is detected in this mode, the BOD circuit
is set in enabled mode to ensure that the device is kept in reset until VCC is above VBOT again
The BODACT fuse determines the BOD setting for active mode and idle mode, while the BODPD fuse determines the
brownout detection setting for all sleep modes, except idle mode.
Table 9-3. BOD setting fuse decoding.
9.4.3 External Reset
The external reset circuit is connected to the external RESET pin. The external reset will trigger when the RESET pin is
driven below the RESET pin threshold voltage, VRST, for longer than the minimum pulse period, tEXT. The reset will be
held as long as the pin is kept low. The RESET pin includes an internal pull-up resistor.
Figure 9-5. External reset characteristics.
For external reset characterization data consult the device datasheet.
9.4.4 Watchdog Reset
The watchdog timer (WDT) is a system function for monitoring correct program operation. If the WDT is not reset from
the software within a programmable timout period, a watchdog reset will be given. The watchdog reset is active for one to
two clock cycles of the 2MHz internal oscillator.
BODACT[1:0]/ BODPD[1:0] Mode
00 Reserved
01 Sampled
10 Enabled
11 Disabled
CC
t
EXT
XMEGA B [MANUAL] 107
Atmel-8291C-AVR-XMEGA B -09/2014
Figure 9-6. Watchdog reset.
For information on configuration and use of the WDT, refer to the “WDT – Watchdog Timer” on page 110.
9.4.5 Software Reset
The software reset makes it possible to issue a system reset from software by writing to the software reset bit in the reset
control register.The reset will be issued within two CPU clock cycles after writing the bit. It is not possible to execute any
instruction from when a software reset is requested until it is issued.
Figure 9-7. Software reset.
9.4.6 Program and Debug Interface Reset
The program and debug interface reset contains a separate reset source that is used to reset the device during external
programming and debugging. This reset source is accessible only from external debuggers and programmers.
1-2 2MHz
CC
Cycles
1-2 2MHz
CC
Cycles
SOFTWARE
XMEGA B [MANUAL] 108
Atmel-8291C-AVR-XMEGA B -09/2014
9.5 Register Description
9.5.1 STATUS – Status register
z Bit 7:6 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 5 – SRF: Software Reset Flag
This flag is set if a software reset occurs. The flag will be cleared by a power-on reset or by writing a one to the bit
location.
z Bit 4 – PDIRF: Program and Debug Interface Reset Flag
This flag is set if a programming interface reset occurs. The flag will be cleared by a power-on reset or by writing a one to
the bit location.
z Bit 3 – WDRF: Watchdog Reset Flag
This flag is set if a watchdog reset occurs. The flag will be cleared by a power-on reset or by writing a one to the bit
location.
z Bit 2 – BORF: Brownout Reset Flag
This flag is set if a brownout reset occurs. The flag will be cleared by a power-on reset or by writing a one to the bit
location.
z Bit 1 – EXTRF: External Reset Flag
This flag is set if an external reset occurs. The flag will be cleared by a power-on reset or by writing a one to the bit
location.
z Bit 0 – PORF: Power On Reset Flag
This flag is set if a power-on reset occurs. Writing a one to the flag will clear the bit location.
9.5.2 CTRL – Control register
z Bit 7:1 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 0 – SWRST: Software Reset
Bit 7 6 5 4 3 2 1 0
+0x00 – – SRF PDIRF WDRF BORF EXTRF PORF
Read/Write R R R/W R/W R/W R/W R/W R/W
Initial Value - -------
Bit 7 6 5 4 3 2 1 0
+0x01 – – – – – – – SWRST
Read/Write R R R R R R R R/W
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 109
Atmel-8291C-AVR-XMEGA B -09/2014
When this bit is set, a software reset will occur. The bit is cleared when a reset is issued. This bit is protected by the
configuration change protection mechanism. For details, refer to “Configuration Change Protection” on page 13.
9.6 Register Summary
Address Name Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 Page
+0x00 STATUS – – SRF PDIRF WDRF BORF EXTRF PORF 108
+0x01 CTRL – – – – – – – SWRST 108
XMEGA B [MANUAL] 110
Atmel-8291C-AVR-XMEGA B -09/2014
10. WDT – Watchdog Timer
10.1 Features
z Issues a device reset if the timer is not reset before its timeout period
z Asynchronous operation from dedicated oscillator
z 1kHz output of the 32kHz ultra low power oscillator
z 11 selectable timeout periods, from 8ms to 8s.
z Two operation modes:
z Normal mode
z Window mode
z Configuration lock to prevent unwanted changes
10.2 Overview
The watchdog timer (WDT) is a system function for monitoring correct program operation. It makes it possible to recover
from error situations such as runaway or deadlocked code. The WDT is a timer, configured to a predefined timeout
period, and is constantly running when enabled. If the WDT is not reset within the timeout period, it will issue a
microcontroller reset. The WDT is reset by executing the WDR (watchdog timer reset) instruction from the application
code.
The window mode makes it possible to define a time slot or window inside the total timeout period during which WDT
must be reset. If the WDT is reset outside this window, either too early or too late, a system reset will be issued.
Compared to the normal mode, this can also catch situations where a code error causes constant WDR execution.
The WDT will run in active mode and all sleep modes, if enabled. It is asynchronous, runs from a CPU-independent clock
source, and will continue to operate to issue a system reset even if the main clocks fail.
The configuration change protection mechanism ensures that the WDT settings cannot be changed by accident. For
increased safety, a fuse for locking the WDT settings is also available.
10.3 Normal Mode Operation
In normal mode operation, a single timeout period is set for the WDT. If the WDT is not reset from the application code
before the timeout occurs, then the WDT will issue a system reset. There are 11 possible WDT timeout (TOWDT) periods,
selectable from 8ms to 8s, and the WDT can be reset at any time during the timeout period. A new WDT timeout period
will be started each time the WDT is reset by the WDR instruction. The default timeout period is controlled by fuses.
Normal mode operation is illustrated in Figure 10-1 on page 110.
Figure 10-1. Normal mode operation.
XMEGA B [MANUAL] 111
Atmel-8291C-AVR-XMEGA B -09/2014
10.4 Window Mode Operation
In window mode operation, the WDT uses two different timeout periods, a "closed" window timeout period (TOWDTW) and
the normal timeout period (TOWDT). The closed window timeout period defines a duration of from 8ms to 8s where the
WDT cannot be reset. If the WDT is reset during this period, the WDT will issue a system reset. The normal WDT timeout
period, which is also 8ms to 8s, defines the duration of the "open" period during which the WDT can (and should) be
reset. The open period will always follow the closed period, and so the total duration of the timeout period is the sum of
the closed window and the open window timeout periods. The default closed window timeout period is controlled by fuses
(both open and closed periods are controlled by fuses). The window mode operation is illustrated in Figure 10-2.
Figure 10-2. Window mode operation.
10.5 Watchdog Timer Clock
The WDT is clocked from the 1kHz output from the 32kHz ultra low power (ULP) internal oscillator. Due to the ultra low
power design, the oscillator is not very accurate, and so the exact timeout period may vary from device to device. When
designing software which uses the WDT, this device-to-device variation must be kept in mind to ensure that the timeout
periods used are valid for all devices. For more information on ULP oscillator accuracy, consult the device datasheet.
10.6 Configuration Protection and Lock
The WDT is designed with two security mechanisms to avoid unintentional changes to the WDT settings.
The first mechanism is the configuration change protection mechanism, employing a timed write procedure for changing
the WDT control registers. In addition, for the new configuration to be written to the control registers, the register’s
change enable bit must be written at the same time.
The second mechanism locks the configuration by setting the WDT lock fuse. When this fuse is set, the watchdog time
control register cannot be changed; hence, the WDT cannot be disabled from software. After system reset, the WDT will
resume at the configured operation. When the WDT lock fuse is programmed, the window mode timeout period cannot
be changed, but the window mode itself can still be enabled or disabled.
XMEGA B [MANUAL] 112
Atmel-8291C-AVR-XMEGA B -09/2014
10.7 Registers Description
10.7.1 CTRL – Control register
z Bits 7:6 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bits 5:2 – PER[3:0]: Timeout Period
These bits determine the watchdog timeout period as a number of 1kHz ULP oscillator cycles. In window mode
operation, these bits define the open window period. The different typical timeout periods are found in Table 10-1. The
initial values of these bits are set by the watchdog timeout period (WDP) fuses, which are loaded at power-on.
In order to change these bits, the CEN bit must be written to 1 at the same time. These bits are protected by the
configuration change protection mechanism. For a detailed description, refer to “Configuration Change Protection” on
page 13.
Table 10-1. Watchdog timeout periods
Note: Reserved settings will not give any timeout.
Bit 7 6 5 4 3 2 1 0
+0x00 – – PER[3:0] ENABLE CEN
Read/Write (unlocked) R R R/W R/W R/W R/W R/W R/W
Read/Write (locked) R RRRRRRR
Initial Value (x = fuse) 0 0 XXXXX0
PER[3:0] Group Configuration Typical Timeout Periods
0000 8CLK 8ms
0001 16CLK 16ms
0010 32CLK 32ms
0011 64CLK 64ms
0100 128CLK 0.128s
0101 256CLK 0.256s
0110 512CLK 0.512s
0111 1KCLK 1.0s
1000 2KCLK 2.0s
1001 4KCLK 4.0s
1010 8KCLK 8.0s
1011 – Reserved
1100 – Reserved
1101 – Reserved
1110 – Reserved
1111 – Reserved
XMEGA B [MANUAL] 113
Atmel-8291C-AVR-XMEGA B -09/2014
z Bit 1 – ENABLE: Enable
This bit enables the WDT. Clearing this bit disables the watchdog timer.
In order to change this bit, the CEN bit in “CTRL – Control register” on page 112 must be written to one at the same time.
This bit is protected by the configuration change protection mechanism, For a detailed description, refer to “Configuration
Change Protection” on page 13.
z Bit 0 – CEN: Change Enable
This bit enables the ability to change the configuration of the “CTRL – Control register” on page 112. When writing a new
value to this register, this bit must be written to one at the same time for the changes to take effect. This bit is protected
by the configuration change protection mechanism. For a detailed description, refer to “Configuration Change Protection”
on page 13.
10.7.2 WINCTRL – Window Mode Control register
z Bit 7:6 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 5:2 – WPER[3:0]: Window Mode Timeout Period
These bits determine the closed window period as a number of 1kHz ULP oscillator cycles in window mode operation.
The typical different closed window periods are found in Table 10-2. The initial values of these bits are set by the
watchdog window timeout period (WDWP) fuses, and are loaded at power-on. In normal mode these bits are not in use.
In order to change these bits, the WCEN bit must be written to one at the same time. These bits are protected by the
configuration change protection mechanism. For a detailed description, refer to “Configuration Change Protection” on
page 13.
Table 10-2. Watchdog closed window periods
Bit 7 6 5 4 3 2 1 0
+0x01 – – WPER[3:0] WEN WCEN
Read/Write (unlocked) R R R/W R/W R/W R/W R/W R/W
Read/Write (locked) R R R R R R R/W R/W
Initial Value (x = fuse) 0 0 XXXXX0
WPER[3:0] Group Configuration Typical Closed Window Periods
0000 8CLK 8ms
0001 16CLK 16ms
0010 32CLK 32ms
0011 64CLK 64ms
0100 128CLK 0.128s
0101 256CLK 0.256s
0110 512CLK 0.512s
0111 1KCLK 1.0s
1000 2KCLK 2.0s
1001 4KCLK 4.0s
XMEGA B [MANUAL] 114
Atmel-8291C-AVR-XMEGA B -09/2014
Note: Reserved settings will not give any timeout for the window.
z Bit 1 – WEN: Window Mode Enable
This bit enables the window mode. In order to change this bit, the WCEN bit in “WINCTRL – Window Mode Control
register” on page 113 must be written to one at the same time. This bit is protected by the configuration change
protection mechanism. For a detailed description, refer to “Configuration Change Protection” on page 13.
z Bit 0 – WCEN: Window Mode Change Enable
This bit enables the ability to change the configuration of the “WINCTRL – Window Mode Control register” on page 113.
When writing a new value to this register, this bit must be written to one at the same time for the changes to take effect.
This bit is protected by the configuration change protection mechanism, but not protected by the WDT lock fuse.
10.7.3 STATUS – Status register
z Bit 7:1 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 0 – SYNCBUSY: Synchronization Busy Flag
This flag is set after writing to the CTRL or WINCTRL registers and the data are being synchronized from the system
clock to the WDT clock domain. This bit is automatically cleared after the synchronization is finished. Synchronization will
take place only when the ENABLE bit for the Watchdog Timer is set.
10.8 Register Summary
1010 8KCLK 8.0s
1011 – Reserved
1100 – Reserved
1101 – Reserved
1110 – Reserved
1111 – Reserved
WPER[3:0] Group Configuration Typical Closed Window Periods
Bit 7 6 5 4 3 2 1 0
+0x02 – – – – – – – SYNCBUSY
Read/Write R R R R R R R R
Initial Value 0 0 0 0 0 0 0 0
Address Name Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 Page
+0x00 CTRL – – PER[3:0] ENABLE CEN 112
+0x01 WINCTRL – – WPER[3:0] WEN WCEN 113
+0x02 STATUS – – – – – – – SYNCBUSY 114
XMEGA B [MANUAL] 115
Atmel-8291C-AVR-XMEGA B -09/2014
11. Interrupts and Programmable Multilevel Interrupt Controller
11.1 Features
z Short and predictable interrupt response time
z Separate interrupt configuration and vector address for each interrupt
z Programmable multilevel interrupt controller
z Interrupt prioritizing according to level and vector address
z Three selectable interrupt levels for all interrupts: low, medium and high
z Selectable, round-robin priority scheme within low-level interrupts
z Non-maskable interrupts for critical functions
z Interrupt vectors optionally placed in the application section or the boot loader section
11.2 Overview
Interrupts signal a change of state in peripherals, and this can be used to alter program execution. Peripherals can have
one or more interrupts, and all are individually enabled and configured. When an interrupt is enabled and configured, it
will generate an interrupt request when the interrupt condition is present. The programmable multilevel interrupt
controller (PMIC) controls the handling and prioritizing of interrupt requests. When an interrupt request is acknowledged
by the PMIC, the program counter is set to point to the interrupt vector, and the interrupt handler can be executed.
All peripherals can select between three different priority levels for their interrupts: low, medium, and high. Interrupts are
prioritized according to their level and their interrupt vector address. Medium-level interrupts will interrupt low-level
interrupt handlers. High-level interrupts will interrupt both medium- and low-level interrupt handlers. Within each level, the
interrupt priority is decided from the interrupt vector address, where the lowest interrupt vector address has the highest
interrupt priority. Low-level interrupts have an optional round-robin scheduling scheme to ensure that all interrupts are
serviced within a certain amount of time.
Non-maskable interrupts (NMI) are also supported, and can be used for system critical functions.
11.3 Operation
Interrupts must be globally enabled for any interrupts to be generated. This is done by setting the global interrupt enable
( I ) bit in the CPU status register. The I bit will not be cleared when an interrupt is acknowledged. Each interrupt level
must also be enabled before interrupts with the corresponding level can be generated.
When an interrupt is enabled and the interrupt condition is present, the PMIC will receive the interrupt request. Based on
the interrupt level and interrupt priority of any ongoing interrupts, the interrupt is either acknowledged or kept pending
until it has priority. When the interrupt request is acknowledged, the program counter is updated to point to the interrupt
vector. The interrupt vector is normally a jump to the interrupt handler; the software routine that handles the interrupt.
After returning from the interrupt handler, program execution continues from where it was before the interrupt occurred.
One instruction is always executed before any pending interrupt is served.
The PMIC status register contains state information that ensures that the PMIC returns to the correct interrupt level when
the RETI (interrupt return) instruction is executed at the end of an interrupt handler. Returning from an interrupt will return
the PMIC to the state it had before entering the interrupt. The status register (SREG) is not saved automatically upon an
interrupt request. The RET (subroutine return) instruction cannot be used when returning from the interrupt handler
routine, as this will not return the PMIC to its correct state.
XMEGA B [MANUAL] 116
Atmel-8291C-AVR-XMEGA B -09/2014
Figure 11-1. Interrupt controller overview.
11.4 Interrupts
All interrupts and the reset vector each have a separate program vector address in the program memory space. The
lowest address in the program memory space is the reset vector. All interrupts are assigned individual control bits for
enabling and setting the interrupt level, and this is set in the control registers for each peripheral that can generate
interrupts. Details on each interrupt are described in the peripheral where the interrupt is available.
All interrupts have an interrupt flag associated with it. When the interrupt condition is present, the interrupt flag will be set,
even if the corresponding interrupt is not enabled. For most interrupts, the interrupt flag is automatically cleared when
executing the interrupt vector. Writing a logical one to the interrupt flag will also clear the flag. Some interrupt flags are
not cleared when executing the interrupt vector, and some are cleared automatically when an associated register is
accessed (read or written). This is described for each individual interrupt flag.
If an interrupt condition occurs while another, higher priority interrupt is executing or pending, the interrupt flag will be set
and remembered until the interrupt has priority. If an interrupt condition occurs while the corresponding interrupt is not
enabled, the interrupt flag will be set and remembered until the interrupt is enabled or the flag is cleared by software.
Similarly, if one or more interrupt conditions occur while global interrupts are disabled, the corresponding interrupt flag
will be set and remembered until global interrupts are enabled. All pending interrupts are then executed according to their
order of priority.
Interrupts can be blocked when executing code from a locked section; e.g., when the boot lock bits are programmed.
This feature improves software security. Refer to “Memory Programming” on page 375 for details on lock bit settings.
Interrupts are automatically disabled for up to four CPU clock cycles when the configuration change protection register is
written with the correct signature. Refer to “Configuration Change Protection” on page 13 for more details.
11.4.1 NMI – Non-Maskable Interrupts
Which interrupts represent NMI and which represent regular interrupts cannot be selected. Non-maskable interrupts
must be enabled before they can be used. Refer to the device datasheet for NMI present on each device.
An NMI will be executed regardless of the setting of the I bit, and it will never change the I bit. No other interrupts can
interrupt a NMI handler. If more than one NMI is requested at the same time, priority is static according to the interrupt
vector address, where the lowest address has highest priority.
11.4.2 Interrupt Response Time
The interrupt response time for all the enabled interrupts is three CPU clock cycles, minimum; one cycle to finish the
ongoing instruction and two cycles to store the program counter to the stack. After the program counter is pushed on the
stack, the program vector for the interrupt is executed. The jump to the interrupt handler takes three clock cycles.
Peripheral 1
Interrupt Controller
INT REQ
INT LEVEL
INT REQ
INT LEVEL CPU INT REQ
CTRL
LEVEL Enable
CPU.SREG
Global
Interrupt
Enable
Priority
decoder
STATUS
INTPRI
INT ACK
INT ACK
Peripheral n
INT LEVEL
INT REQ
INT ACK
CPU
CPU INT ACK
CPU ”RETI”
Sleep
Controller
Wake-up
XMEGA B [MANUAL] 117
Atmel-8291C-AVR-XMEGA B -09/2014
If an interrupt occurs during execution of a multicycle instruction, this instruction is completed before the interrupt is
served. See Figure 11-2 on page 117 for more details.
Figure 11-2. Interrupt execution of a multicycle instruction.
If an interrupt occurs when the device is in sleep mode, the interrupt execution response time is increased by five clock
cycles. In addition, the response time is increased by the start-up time from the selected sleep mode.
A return from an interrupt handling routine takes four to five clock cycles, depending on the size of the program counter.
During these clock cycles, the program counter is popped from the stack and the stack pointer is incremented.
XMEGA B [MANUAL] 118
Atmel-8291C-AVR-XMEGA B -09/2014
11.5 Interrupt level
The interrupt level is independently selected for each interrupt source. For any interrupt request, the PMIC also receives
the interrupt level for the interrupt. The interrupt levels and their corresponding bit values for the interrupt level
configuration of all interrupts is shown in Table 11-1.
Table 11-1. Interrupt levels
The interrupt level of an interrupt request is compared against the current level and status of the interrupt controller. An
interrupt request of a higher level will interrupt any ongoing interrupt handler from a lower level interrupt. When returning
from the higher level interrupt handler, the execution of the lower level interrupt handler will continue.
11.6 Interrupt priority
Within each interrupt level, all interrupts have a priority. When several interrupt requests are pending, the order in which
interrupts are acknowledged is decided both by the level and the priority of the interrupt request. Interrupts can be
organized in a static or dynamic (round-robin) priority scheme. High- and medium-level interrupts and the NMI will always
have static priority. For low-level interrupts, static or dynamic priority scheduling can be selected.
11.6.1 Static priority
Interrupt vectors (IVEC) are located at fixed addresses. For static priority, the interrupt vector address decides the priority
within one interrupt level, where the lowest interrupt vector address has the highest priority. Refer to the device datasheet
for the interrupt vector table with the base address for all modules and peripherals with interrupt capability. Refer to the
interrupt vector summary of each module and peripheral in this manual for a list of interrupts and their corresponding
offset address within the different modules and peripherals.
Interrupt Level Configuration Group Configuration Description
00 OFF Interrupt disabled.
01 LO Low-level interrupt
10 MED Medium-level interrupt
11 HI High-level interrupt
XMEGA B [MANUAL] 119
Atmel-8291C-AVR-XMEGA B -09/2014
Figure 11-3. Static priority.
11.6.2 Round-robin Scheduling
To avoid the possible starvation problem for low-level interrupts with static priority, where some interrupts might never be
served, the PMIC offers round-robin scheduling for low-level interrupts. When round-robin scheduling is enabled, the
interrupt vector address for the last acknowledged low-level interrupt will have the lowest priority the next time one or
more interrupts from the low level is requested.
Figure 11-4. Round-robin scheduling.
XMEGA B [MANUAL] 120
Atmel-8291C-AVR-XMEGA B -09/2014
11.7 Interrupt vector locations
Table 11-2 shows reset and Interrupt vectors placement for the various combinations of BOOTRST and IVSEL settings.
If the program never enables an interrupt source, the Interrupt Vectors are not used, and regular program code can be
placed at these locations. This is also the case if the Reset Vector is in the Application section while the Interrupt Vectors
are in the Boot section or vice versa.
Table 11-2. Reset and interrupt vectors placement
BOOTRST IVSEL Reset Address Interrupt Vectors Start Address
1 0 0x0000 0x0002
1 1 0x0000 Boot Reset Address + 0x0002
0 0 Boot Reset Address 0x0002
0 1 Boot Reset Address Boot Reset Address + 0x0002
XMEGA B [MANUAL] 121
Atmel-8291C-AVR-XMEGA B -09/2014
11.8 Register Description
11.8.1 STATUS – Status register
z Bit 7 – NMIEX: Non-Maskable Interrupt Executing
This flag is set if a non-maskable interrupt is executing. The flag will be cleared when returning (RETI) from the interrupt
handler.
z Bit 6:3 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 2 – HILVLEX: High-level Interrupt Executing
This flag is set when a high-level interrupt is executing or when the interrupt handler has been interrupted by an NMI. The
flag will be cleared when returning (RETI) from the interrupt handler.
z Bit 1 – MEDLVLEX: Medium-level Interrupt Executing
This flag is set when a medium-level interrupt is executing or when the interrupt handler has been interrupted by an
interrupt from higher level or an NMI. The flag will be cleared when returning (RETI) from the interrupt handler.
z Bit 0 – LOLVLEX: Low-level Interrupt Executing
This flag is set when a low-level interrupt is executing or when the interrupt handler has been interrupted by an interrupt
from higher level or an NMI. The flag will be cleared when returning (RETI) from the interrupt handler.
11.8.2 INTPRI – Interrupt priority register
z Bit 7:0 – INTPRI: Interrupt Priority
When round-robin scheduling is enabled, this register stores the interrupt vector of the last acknowledged low-level
interrupt. The stored interrupt vector will have the lowest priority the next time one or more low-level interrupts are
pending. The register is accessible from software to change the priority queue. This register is not reinitialized to its initial
value if round-robing scheduling is disabled, and so if default static priority is needed, the register must be written to zero.
Bit 7 6 5 4 3 2 1 0
+0x00 NMIEX – – – – HILVLEX MEDLVLEX LOLVLEX
Read/Write R R R R R R R R
Initial Value 0 0 0 0 0 0 0 0
Bit 7 6 5 4 3 2 1 0
+0x01 INTPRI[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 00000000
XMEGA B [MANUAL] 122
Atmel-8291C-AVR-XMEGA B -09/2014
11.8.3 CTRL – Control register
z Bit 7 – RREN: Round-robin Scheduling Enable
When the RREN bit is set, the round-robin scheduling scheme is enabled for low-level interrupts. When this bit is cleared,
the priority is static according to interrupt vector address, where the lowest address has the highest priority.
z Bit 6 – IVSEL: Interrupt Vector Select
When the IVSEL bit is cleared (zero), the interrupt vectors are placed at the start of the application section in flash. When
this bit is set (one), the interrupt vectors are placed in the beginning of the boot section of the flash. Refer to the device
datasheet for the absolute address.
This bit is protected by the configuration change protection mechanism. Refer to “Configuration Change Protection” on
page 13 for details.
z Bit 5:3 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 2 – HILVLEN: High-level Interrupt Enable (1)
When this bit is set, all high-level interrupts are enabled. If this bit is cleared, high-level interrupt requests will be ignored.
z Bit 1 – MEDLVLEN: Medium-level Interrupt Enable(1)
When this bit is set, all medium-level interrupts are enabled. If this bit is cleared, medium-level interrupt requests will be
ignored.
z Bit 0 – LOLVLEN: Low-level Interrupt Enable(1)
When this bit is set, all low-level interrupts are enabled. If this bit is cleared, low-level interrupt requests will be ignored.
Note: 1. Ignoring interrupts will be effective one cycle after the bit is cleared.
11.9 Register Summary
Bit 7 6 5 4 3 2 1 0
+0x02 RREN IVSEL – – – HILVLEN MEDLVLEN LOLVLEN
Read/Write R/W R/W R R R R/W R/W R/W
Initial Value 0 00000 0 0
Address Name Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 Page
+0x00 STATUS NMIEX – – – – HILVLEX MEDLVLEX LOLVLEX 121
+0x01 INTPRI INTPRI[7:0] 121
+0x02 CTRL RREN IVSEL – – – HILVLEN MEDLVLEN LOLVLEN 122
XMEGA B [MANUAL] 123
Atmel-8291C-AVR-XMEGA B -09/2014
12. I/O Ports
12.1 Features
z General purpose input and output pins with individual configuration
z Output driver with configurable driver and pull settings:
z Totem-pole
z Wired-AND
z Wired-OR
z Bus-keeper
z Inverted I/O
z Input with synchronous and/or asynchronous sensing with interrupts and events
z Sense both edges
z Sense rising edges
z Sense falling edges
z Sense low level
z Optional pull-up and pull-down resistor on input and Wired-OR/AND configurations
z Asynchronous pin change sensing that can wake the device from all sleep modes
z Two port interrupts with pin masking per I/O port
z Efficient and safe access to port pins
z Hardware read-modify-write through dedicated toggle/clear/set registers
z Configuration of multiple pins in a single operation
z Mapping of port registers into bit-accessible I/O memory space
z Peripheral clocks output on port pin
z Real-time counter clock output to port pin
z Event channels can be output on port pin
z Remapping of digital peripheral pin functions
z Selectable USART, SPI, and timer/counter input/output pin locations
12.2 Overview
AVR XMEGA microcontrollers have flexible general purpose I/O ports. One port consists of up to eight port pins: pin 0 to
7. Each port pin can be configured as input or output with configurable driver and pull settings. They also implement
synchronous and asynchronous input sensing with interrupts and events for selectable pin change conditions.
Asynchronous pin-change sensing means that a pin change can wake the device from all sleep modes, included the
modes where no clocks are running.
All functions are individual and configurable per pin, but several pins can be configured in a single operation. The pins
have hardware read-modify-write (RMW) functionality for safe and correct change of drive value and/or pull resistor
configuration. The direction of one port pin can be changed without unintentionally changing the direction of any other
pin.
The port pin configuration also controls input and output selection of other device functions. It is possible to have both the
peripheral clock and the real-time clock output to a port pin, and available for external use. The same applies to events
from the event system that can be used to synchronize and control external functions. Other digital peripherals, such as
USART, SPI, and timer/counters, can be remapped to selectable pin locations in order to optimize pin-out versus
application needs.
Figure 12-1 on page 124 shows the I/O pin functionality and the registers that are available for controlling a pin.
XMEGA B [MANUAL] 124
Atmel-8291C-AVR-XMEGA B -09/2014
Figure 12-1. General I/O pin functionality.
12.3 I/O Pin Use and Configuration
Each port has one data direction (DIR) register and one data output value (OUT) register that are used for port pin
control. The data input value (IN) register is used for reading the port pins. In addition, each pin has a pin configuration
(PINnCTRL) register for additional pin configuration.
Direction of the pin is decided by the DIRn bit in the DIR register. If DIRn is written to one, pin n is configured as an output
pin. If DIRn is written to zero, pin n is configured as an input pin.
When direction is set as output, the OUTn bit in OUT is used to set the value of the pin. If OUTn is written to one, pin n is
driven high. If OUTn is written to zero, pin n is driven low.
The IN register is used for reading pin values. A pin value can always be read regardless of whether the pin is configured
as input or output, except if digital input is disabled.
The I/O pins are tri-stated when a reset condition becomes active, even if no clocks are running.
The pin n configuration (PINnCTRL) register is used for additional I/O pin configuration. A pin can be set in a totem-pole,
wired-AND, or wired-OR configuration. It is also possible to enable inverted input and output for a pin.
A totem-pole output has four possible pull configurations: totem-pole (push-pull), pull-down, pull-up, and bus-keeper. The
bus-keeper is active in both directions. This is to avoid oscillation when disabling the output. The totem-pole
Q D
R
Q D
R
Synchronizer
D Q
R
D Q
R
DIRn
OUTn
PINnCTRL
INn
Pxn
D Q
R
C
o
n
t
r
o
l
L
o
g
i
c
Input Disable
Wired AND/OR
Digital Input Pin
Analog Input/Output
Inverted I/O
Pull Enable
Pull Keep
Pull Direction
XMEGA B [MANUAL] 125
Atmel-8291C-AVR-XMEGA B -09/2014
configurations with pull-up and pull-down have active resistors only when the pin is set as input. This feature eliminates
unnecessary power consumption. For wired-AND and wired-OR configuration, the optional pull-up and pull-down
resistors are active in both input and output directions.
Since pull configuration is configured through the pin configuration register, all intermediate port states during switching
of the pin direction and pin values are avoided.
The I/O pin configurations are summarized with simplified schematics in Figure 12-2 on page 125 to Figure 12-7 on page
127.
12.3.1 Totem-pole
In the totem-pole (push-pull) configuration, the pin is driven low or high according to the corresponding bit setting in the
OUT register. In this configuration, there is no current limitation for sink or source other than what the pin is capable of. If
the pin is configured for input, the pin will float if no external pull resistor is connected.
Figure 12-2. I/O pin configuration - Totem-pole (push-pull).
12.3.1.1 Totem-pole with Pull-down
In this mode, the configuration is the same as for totem-pole mode, expect the pin is configured with an internal pull-down
resistor when set as input.
Figure 12-3. I/O pin configuration - Totem-pole with pull-down (on input).
XMEGA B [MANUAL] 126
Atmel-8291C-AVR-XMEGA B -09/2014
12.3.1.2 Totem-pole with Pull-up
In this mode, the configuration is as for totem-pole, expect the pin is configured with internal pull-up when set as input.
Figure 12-4. I/O pin configuration - Totem-pole with pull-up (on input).
12.3.2 Bus-keeper
In the bus-keeper configuration, it provides a weak bus-keeper that will keep the pin at its logic level when the pin is no
longer driven to high or low. If the last level on the pin/bus was 1, the bus-keeper configuration will use the internal pull
resistor to keep the bus high. If the last logic level on the pin/bus was 0, the bus-keeper will use the internal pull resistor
to keep the bus low.
Figure 12-5. I/O pin configuration - Totem-pole with bus-keeper.
XMEGA B [MANUAL] 127
Atmel-8291C-AVR-XMEGA B -09/2014
12.3.3 Wired-OR
In the wired-OR configuration, the pin will be driven high when the corresponding bits in the OUT and DIR registers are
written to one. When the OUT register is set to zero, the pin is released, allowing the pin to be pulled low with the internal
or an external pull-resistor. If internal pull-down is used, this is also active if the pin is set as input.
Figure 12-6. Output configuration - Wired-OR with optional pull-down.
12.3.4 Wired-AND
In the wired-AND configuration, the pin will be driven low when the corresponding bits in the OUT and DIR registers are
written to zero. When the OUT register is set to one, the pin is released allowing the pin to be pulled high with the internal
or an external pull-resistor. If internal pull-up is used, this is also active if the pin is set as input.
Figure 12-7. Output configuration - Wired-AND with optional pull-up.
XMEGA B [MANUAL] 128
Atmel-8291C-AVR-XMEGA B -09/2014
12.4 Reading the Pin Value
Independent of the pin data direction, the pin value can be read from the IN register, as shown in Figure 12-1 on page
124. If the digital input is disabled, the pin value cannot be read. The IN register bit and the preceding flip-flop constitute
a synchronizer. The synchronizer introduces a delay on the internal signal line. Figure 12-8 on page 128 shows a timing
diagram of the synchronization when reading an externally applied pin value. The maximum and minimum propagation
delays are denoted as tpd,max and tpd,min, respectively.
Figure 12-8. Synchronization when reading a pin value.
XMEGA B [MANUAL] 129
Atmel-8291C-AVR-XMEGA B -09/2014
12.5 Input Sense Configuration
Input sensing is used to detect an edge or level on the I/O pin input. The different sense configurations that are available
for each pin are detection of a rising edge, falling edge, or any edge or detection of a low level. High level can be
detected by using the inverted input configuration. Input sensing can be used to trigger interrupt requests (IREQ) or
events when there is a change on the pin.
The I/O pins support synchronous and asynchronous input sensing. Synchronous sensing requires the presence of the
peripheral clock, while asynchronous sensing does not require any clock.
Figure 12-9. Input sensing.
12.6 Port Interrupt
Each port has two interrupt vectors, and it is configurable which pins on the port will trigger each interrupt. Port interrupts
must be enabled before they can be used. Which sense configurations can be used to generate interrupts is dependent
on whether synchronous or asynchronous input sensing is available for the selected pin.
For synchronous sensing, all sense configurations can be used to generate interrupts. For edge detection, the changed
pin value must be sampled once by the peripheral clock for an interrupt request to be generated.
For asynchronous sensing, only port pin 2 on each port has full asynchronous sense support. This means that for edge
detection, pin 2 will detect and latch any edge and it will always trigger an interrupt request. The other port pins have
limited asynchronous sense support. This means that for edge detection, the changed value must be held until the device
wakes up and a clock is present. If the pin value returns to its initial value before the end of the device wake-up time, the
device will still wake up, but no interrupt request will be generated.
A low level can always be detected by all pins, regardless of a peripheral clock being present or not. If a pin is configured
for low-level sensing, the interrupt will trigger as long as the pin is held low. In active mode, the low level must be held
until the completion of the currently executing instruction for an interrupt to be generated. In all sleep modes, the low level
must be kept until the end of the device wake-up time for an interrupt to be generated. If the low level disappears before
the end of the wake-up time, the device will still wake up, but no interrupt will be generated.
Table 12-1, Table 12-2, and Table 12-3 on page 130 summarize when interrupts can be triggered for the various input
sense configurations.
D Q
R
INVERTED I/O
Interrupt
Control
D Q
R
Pxn
Synchronizer
INn
EDGE
DETECT
Synchronous sensing
EDGE
DETECT
Asynchronous sensing
IRQ
Synchronous
Events
Asynchronous
Events
XMEGA B [MANUAL] 130
Atmel-8291C-AVR-XMEGA B -09/2014
Table 12-1. Synchronous sense support.
Table 12-2. Full asynchronous sense support.
Table 12-3. Limited asynchronous sense support.
12.7 Port Event
Port pins can generate an event when there is a change on the pin. The sense configurations decide the conditions for
each pin to generate events. Event generation requires the presence of a peripheral clock, and asynchronous event
generation is not possible. For edge sensing, the changed pin value must be sampled once by the peripheral clock for an
event to be generated.
For level sensing, a low-level pin value will not generate events, and a high-level pin value will continuously generate
events. For events to be generated on a low level, the pin configuration must be set to inverted I/O.
Table 12-4. Event sense support
Sense Settings Supported Interrupt Description
Rising edge Yes Always triggered
Falling edge Yes Always triggered
Any edge Yes Always triggered
Low level Yes Pin level must be kept unchanged during wake up
Sense Settings Supported Interrupt Description
Rising edge Yes Always triggered
Falling edge Yes Always triggered
Both edges Yes Always triggered
Low level Yes Pin level must be kept unchanged during wake up
Sense Settings Supported Interrupt Description
Rising edge No -
Falling edge No -
Any edge Yes Pin value must be kept unchanged during wake up
Low level Yes Pin level must be kept unchanged during wake up
Sense Settings Signal event Data event
Rising edge Rising edge Pin value
Falling edge Falling edge Pin value
Both edge Any edge Pin value
Low level Pin value Pin value
XMEGA B [MANUAL] 131
Atmel-8291C-AVR-XMEGA B -09/2014
12.8 Alternate Port Functions
Most port pins have alternate pin functions in addition to being a general purpose I/O pin. When an alternate function is
enabled, it might override the normal port pin function or pin value. This happens when other peripherals that require pins
are enabled or configured to use pins. If and how a peripheral will override and use pins is described in the section for
that peripheral.
The port override signals and related logic (grey) are shown in Figure 12-10 on page 131. These signals are not
accessible from software, but are internal signals between the overriding peripheral and the port pin.
Figure 12-10. Port override signals and related logic.
Q D
R
Q D
R
Synchronizer
D Q
R
D Q
R
DIRn
OUTn
PINnCTRL
INn
Pxn
D Q
R
C
o
n
t
r
o
l
L
o
g
i
c
Digital Input Disable (DID)
Wired AND/OR
Digital Input Pin
Analog Input/Output
Inverted I/O
Pull Enable
Pull Keep
Pull Direction
DID Override Enable
DID Override Value
OUT Override Enable
OUT Override Value
DIR Override Enable
DIR Override Value
XMEGA B [MANUAL] 132
Atmel-8291C-AVR-XMEGA B -09/2014
12.9 Clock and Event Output
It is possible to output the peripheral clock and event channel 0 events to a pin. This can be used to clock, control, and
synchronize external functions and hardware to internal device timing. The output port pin is selectable. If an event
occurs, it remains visible on the port pin as long as the event lasts; normally one peripheral clock cycle.
12.10 Multi-pin configuration
The multi-pin configuration function is used to configure multiple port pins using a single write operation to only one of the
port pin configuration registers. A mask register decides which port pin is configured when one port pin register is written,
while avoiding several pins being written the same way during identical write operations.
12.11 Virtual Ports
Virtual port registers allow the port registers to be mapped virtually in the bit-accessible I/O memory space. When this is
done, writing to the virtual port register will be the same as writing to the real port register. This enables the use of I/O
memory-specific instructions, such as bit-manipulation instructions, on a port register that normally resides in the
extended I/O memory space. There are four virtual ports, and so four ports can be mapped at the same time.
XMEGA B [MANUAL] 133
Atmel-8291C-AVR-XMEGA B -09/2014
12.12 Register Descriptions – Ports
12.12.1 DIR – Data Direction register
z Bit 7:0 – DIR[7:0]: Data Direction
This register sets the data direction for the individual pins of the port. If DIRn is written to one, pin n is configured as an
output pin. If DIRn is written to zero, pin n is configured as an input pin.
12.12.2 DIRSET – Data Direction Set Register
z Bit 7:0 – DIRSET[7:0]: Port Data Direction Set
This register can be used instead of a read-modify-write to set individual pins as output. Writing a one to a bit will set the
corresponding bit in the DIR register. Reading this register will return the value of the DIR register.
12.12.3 DIRCLR – Data Direction Clear register
z Bit 7:0 – DIRCLR[7:0]: Port Data Direction Clear
This register can be used instead of a read-modify-write to set individual pins as input. Writing a one to a bit will clear the
corresponding bit in the DIR register. Reading this register will return the value of the DIR register.
Bit 7 6 5 4 3 2 1 0
+0x00 DIR[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 00000000
Bit 7 6 5 4 3 2 1 0
+0x01 DIRSET[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0000000
Bit 7 6 5 4 3 2 1 0
+0x02 DIRCLR[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 134
Atmel-8291C-AVR-XMEGA B -09/2014
12.12.4 DIRTGL – Data Direction Toggle register
z Bit 7:0 – DIRTGL[7:0]: Port Data Direction Toggle
This register can be used instead of a read-modify-write to toggle the direction of individual pins. Writing a one to a bit will
toggle the corresponding bit in the DIR register. Reading this register will return the value of the DIR register.
12.12.5 OUT – Data Output Value register
z Bit 7:0 – OUT[7:0]: Port Data Output value
This register sets the data output value for the individual pins of the port. If OUTn is written to one, pin n is driven high. If
OUTn is written to zero, pin n is driven low. For this setting to have any effect, the pin direction must be set as output.
12.12.6 OUTSET – Data Output Value Set register
z Bit 7:0 – OUTSET[7:0]: Data Output Value Set
This register can be used instead of a read-modify-write to set the output value of individual pins to one. Writing a one to
a bit will set the corresponding bit in the OUT register. Reading this register will return the value in the OUT register.
12.12.7 OUTCLR – Data Output Value Clear register
z Bit 7:0 – OUTCLR[7:0]: Data Output Value Clear
This register can be used instead of a read-modify-write to set the output value of individual pins to zero. Writing a one to
a bit will clear the corresponding bit in the OUT register. Reading this register will return the value in the OUT register.
Bit 7 6 5 4 3 2 1 0
+0x03 DIRTGL[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 00000000
Bit 7 6 5 4 3 2 1 0
+0x04 OUT[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0000
Bit 7 6 5 4 3 2 1 0
+0x05 OUTSET[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
Bit 7 6 5 4 3 2 1 0
+0x06 OUTCLR[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 000000
XMEGA B [MANUAL] 135
Atmel-8291C-AVR-XMEGA B -09/2014
12.12.8 OUTTGL – Data Output Value Toggle register
z Bit 7:0 – OUTTGL[7:0]: Port Data Output Value Toggle
This register can be used instead of a read-modify-write to toggle the output value of individual pins. Writing a one to a bit
will toggle the corresponding bit in the OUT register. Reading this register will return the value in the OUT register.
12.12.9 IN – Data Input Value register
z Bit 7:0 – IN[7:0]: Data Input Value
This register shows the value present on the pins if the digital input driver is enabled. INn shows the value of pin n of the
port. The input is not sampled and cannot be read if the digital input buffers are disabled.
12.12.10INTCTRL – Interrupt Control register
z Bit 7:4 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 3:2/1:0 – INTnLVL[1:0]: Interrupt n Level
These bits enable port interrupt n and select the interrupt level as described in “Interrupts and Programmable Multilevel
Interrupt Controller” on page 115.
Bit 7 6 5 4 3 2 1 0
+0x07 OUTTGL[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
Bit 7 6 5 4 3 2 1 0
+0x08 IN[7:0]
Read/Write RRRRRRRR
Initial Value 0 0000000
Bit 7 6 5 4 3 2 1 0
+0x09 – – – – INT1LVL[1:0] INT0LVL[1:0]
Read/Write R R R R R/W R/W R/W R/W
Initial Value 0 0000000
XMEGA B [MANUAL] 136
Atmel-8291C-AVR-XMEGA B -09/2014
12.12.11INT0MASK – Interrupt 0 Mask register
z Bit 7:0 – INT0MSK[7:0]: Interrupt 0 Mask bits
These bits are used to mask which pins can be used as sources for port interrupt 0. If INT0MASKn is written to one, pin
n is used as source for port interrupt 0.The input sense configuration for each pin is decided by the PINnCTRL registers.
12.12.12INT1MASK – Interrupt 1 Mask register
z Bit 7:0 – INT1MASK[7:0]: Interrupt 1 Mask bits
These bits are used to mask which pins can be used as sources for port interrupt 1. If INT1MASKn is written to one, pin
n is used as source for port interrupt 1.The input sense configuration for each pin is decided by the PINnCTRL registers.
12.12.13INTFLAGS – Interrupt Flag register
z Bit 7:2 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 1:0 – INTnIF: Interrupt n Flag
The INTnIF flag is set when a pin change/state matches the pin's input sense configuration, and the pin is set as source
for port interrupt n. Writing a one to this flag's bit location will clear the flag. For enabling and executing the interrupt, refer
to the interrupt level description.
Bit 7 6 5 4 3 2 1 0
+0x0A INT0MSK[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
Bit 7 6 5 4 3 2 1 0
+0x0B INT1MSK[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0000000
Bit 7 6 5 4 3 2 1 0
+0x0C – – – – – – INT1IF INT0IF
Read/Write R R R R R R R/W R/W
Initial Value 00000000
XMEGA B [MANUAL] 137
Atmel-8291C-AVR-XMEGA B -09/2014
12.12.14REMAP – Pin Remap register
The pin remap functionality is available for PORTC - PORTF only.
z Bit 7:6 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 5 – SPI: SPI Remap
Setting this bit to one will swap the pin locations of the SCK and MOSI pins to have pin compatibility between SPI and
USART when the USART is operating as a SPI master.
z Bit 4 – USART0: USART0 Remap
Setting this bit to one will move the pin location of USART0 from Px[3:0] to Px[7:4].
z Bit 3 – TC0D: Timer/Counter 0 Output Compare D
Setting this bit will move the location of OC0D from Px3 to Px7.
z Bit 2 – TC0C: Timer/Counter 0 Output Compare C
Setting this bit will move the location of OC0C from Px2 to Px6.
z Bit 1 – TC0B: Timer/Counter 0 Output Compare B
Setting this bit will move the location of OC0B from Px1 to Px5. If this bit is set and PWM from both timer/counter 0 and
timer/counter 1 is enabled, the resulting PWM will be an OR-modulation between the two PWM outputs.
z Bit 0 – TC0A: Timer/Counter 0 Output Compare A
Setting this bit will move the location of OC0A from Px0 to Px4. If this bit is set and PWM from both timer/counter 0 and
timer/counter 1 is enabled, the resulting PWM will be an OR-modulation between the two PWM outputs. See Figure 12-
11.
Figure 12-11.I/O timer/counter.
Bit 7 6 5 4 3 2 1 0
+0x0E – – SPI USART0 TC0D TC0C TC0B TC0A
Read/Write R R R/W R/W R/W R/W R/W R/W
Initial Value 0 0000000
OC0A
OC1A
OCA
XMEGA B [MANUAL] 138
Atmel-8291C-AVR-XMEGA B -09/2014
12.12.15PINnCTRL – Pin n Configuration Register
z Bit 7 – Reserved
This bit is unused and reserved for future use. For compatibility with future devices, always write this bit to zero when this
register is written.
z Bit 6 – INVEN: Inverted I/O Enable
Setting this bit will enable inverted output and input data on pin n.
z Bit 5:3 – OPC: Output and Pull Configuration
These bits set the output/pull configuration on pin n according to Table 12-5.
Table 12-5. Output/pull configuration
z Bit 2:0 – ISC[2:0]: Input/Sense Configuration
These bits set the input and sense configuration on pin n according to Table 12-6 on page 138. The sense configuration
decides how the pin can trigger port interrupts and events. If the input buffer is not disabled, the input cannot be read in
the IN register.
Table 12-6. Input/sense configuration.
Bit 7 6 5 4 3 2 1 0
– INVEN OPC[2:0] ISC[2:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
OPC[2:0] Group Configuration
Description
Output Configuration Pull Configuration
000 TOTEM Totem-pole (N/A)
001 BUSKEEPER Totem-pole Bus-keeper
010 PULLDOWN Totem-pole Pull-down (on input)
011 PULLUP Totem-pole Pull-up (on input)
100 WIREDOR Wired-OR (N/A)
101 WIREDAND Wired-AND (N/A)
110 WIREDORPULL Wired-OR Pull-down
111 WIREDANDPULL Wired-AND Pull-up
ISC[2:0] Group Configuration Description
000 BOTHEDGES Sense both edges
001 RISING Sense rising edge
010 FALLING Sense falling edge
011 LEVEL Sense low level(1)
XMEGA B [MANUAL] 139
Atmel-8291C-AVR-XMEGA B -09/2014
Note: 1. A low-level pin value will not generate events, and a high-level pin value will continuously generate events.
2. Only PORTA - PORTF support the input buffer disable option. If the pin is used for analog functionality, such as AC or ADC, it is recommended to
configure the pin to INPUT_DISABLE.
100 – Reserved
101 – Reserved
110 – Reserved
111 INTPUT_DISABLE Digital input buffer disabled(2)
ISC[2:0] Group Configuration Description
XMEGA B [MANUAL] 140
Atmel-8291C-AVR-XMEGA B -09/2014
12.13 Register Descriptions – Port Configuration
12.13.1 MPCMASK – Multi-pin Configuration Mask register
z Bit 7:0 – MPCMASK[7:0]: Multi-pin Configuration Mask
The MPCMASK register enables configuration of several pins of a port at the same time. Writing a one to bit n makes pin
n part of the multi-pin configuration. When one or more bits in the MPCMASK register is set, writing any of the PINnCTRL
registers will update only the PINnCTRL registers matching the mask in the MPCMASK register for that port. The
MPCMASK register is automatically cleared after any PINnCTRL register is written.
12.13.2 VPCTRLA – Virtual Port-map Control register A
z Bit 7:4 – VP1MAP: Virtual Port 1 Mapping
These bits decide which ports should be mapped to Virtual Port 1. The registers DIR, OUT, IN, and INTFLAGS will be
mapped. Accessing the virtual port registers is equal to accessing the actual port registers. See Table 12-7 on page 141
for configuration.
z Bit 3:0 – VP0MAP: Virtual Port 0 Mapping
These bits decide which ports should be mapped to Virtual Port 0. The registers DIR, OUT, IN, and INTFLAGS will be
mapped. Accessing the virtual port registers is equal to accessing the actual port registers. See Table 12-7 on page 141
for configuration.
12.13.3 VPCTRLB – Virtual Port-map Control register B
z Bit 7:4 – VP3MAP: Virtual Port 3 Mapping
These bits decide which ports should be mapped to Virtual Port 3. The registers DIR, OUT, IN, and INTFLAGS will be
mapped. Accessing the virtual port registers is equal to accessing the actual port registers. See Table 12-7 on page 141
for configuration.
Bit 7 6 5 4 3 2 1 0
+0x00 MPCMASK[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
Bit 7 6 5 4 3 2 1 0
+0x02 VP1MAP[3:0] VP0MAP[3:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 000000
Bit 7 6 5 4 3 2 1 0
+0x03 VP3MAP[3:0] VP2MAP[3:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 141
Atmel-8291C-AVR-XMEGA B -09/2014
z Bit 3:0 – VP2MAP: Virtual Port 2 Mapping
These bits decide which ports should be mapped to Virtual Port 2. The registers DIR, OUT, IN, and INTFLAGS will be
mapped. Accessing the virtual port registers is equal to accessing the actual port registers. See Table 12-7 on page 141
for configuration.
Table 12-7. Virtual port mapping
12.13.4 CLKEVOUT – Clock and Event Out register
z Bit 7 – CLKEVPIN: Clock and Event Output Pin Select
Setting this pin enables output of clock and event pins on port pin 4 instead of port pin 7.
z Bit 6 – RTCOUT: RTC Clock Output Enable
Setting this bit enables output of the RTC clock source on PORTC pin 6.
z Bit 5:4 – EVOUT[1:0]: Event Output Port
These bits decide which port event channel 0 from the event system will be output to. Pin 7 on the selected port is the
default used, and the CLKOUT bits must be set differently from those of EVOUT. The port pin must be configured as
output for the event to be available on the pin.
VPnMAP[3:0] Group Configuration Description
0000 PORTA PORTA mapped to Virtual Port n
0001 PORTB PORTB mapped to Virtual Port n
0010 PORTC PORTC mapped to Virtual Port n
0011 PORTD PORTD mapped to Virtual Port n
0100 PORTE PORTE mapped to Virtual Port n
0101 PORTF PORTF mapped to Virtual Port n
0110 PORTG PORTG mapped to Virtual Port n
0111 PORTH PORTH mapped to Virtual Port n
1000 PORTJ PORTJ mapped to Virtual Port n
1001 PORTK PORTK mapped to Virtual Port n
1010 PORTL PORTL mapped to Virtual Port n
1011 PORTM PORTM mapped to Virtual Port n
1100 PORTN PORTN mapped to Virtual Port n
1101 PORTP PORTP mapped to Virtual Port n
1110 PORTQ PORTQ mapped to Virtual Port n
1111 PORTR PORTR mapped to Virtual Port n
Bit 7 6 5 4 3 2 1 0
+0x04 CLKEVPIN RTCOUT EVOUT[1:0] CLKOUTSEL[1:0] CLKOUT[1:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 142
Atmel-8291C-AVR-XMEGA B -09/2014
Table 12-8 on page 142 shows the possible configurations.
z Bits 3:2 – CLKOUTSEL[1:0]: Clock Output Select
These bits are used to select which of the peripheral clocks will be output to the port pin if CLKOUT is configured.
z Bit 1:0 – CLKOUT[1:0]: Clock Output Port
These bits decide which port the peripheral clock will be output to. Pin 7 on the selected port is the default used. The
CLKOUT setting will override the EVOUT setting. Thus, if both are enabled on the same port pin, the peripheral clock will
be visible. The port pin must be configured as output for the clock to be available on the pin.
Table 12-10 shows the possible configurations.
Table 12-8. Event output pin selection.
EVOUT[1:0] Group Configuration Description
00 OFF Event output disabled
01 PC Event channel 0 output on PORTC
10 PD Event channel 0 output on PORTD
11 PE Event channel 0 output on PORTE
Table 12-9. Clock output clock selection.
CLKOUTSEL[1:0] Group Configuration Description
00 CLK1X CLKPER output to pin
01 CLK2X CLKPER2 output to pin
10 CLK4X CLKPER4 output to pin
11 – (Reserved)
Table 12-10. Clock output port configurations.
CLKOUT[1:0] Group Configuration Description
00 OFF Clock output disabled
01 PC Clock output on PORTC
10 PD Clock output on PORTD
11 PE Clock output on PORTE
XMEGA B [MANUAL] 143
Atmel-8291C-AVR-XMEGA B -09/2014
12.13.5 EVCTRL – Event Control register
z Bit 7:3 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 2:0 – EVOUTSEL[2:0]: Event Channel Output Selection
These bits define which channel from the event system is output to the port pin. Table 12-11 shows the available
selections.
Bit 7 6 5 4 3 2 1 0
+0x06 – – – – – EVOUTSEL[2:0]
Read/Write R R R R R R/W R/W R/W
Initial Value 0 0 0 0 0 000
Table 12-11. Event channel output selection.
EVOUTSEL[2:0] Group Configuration Description
000 0 Event channel 0 output to pin
001 1 Event channel 1 output to pin
010 2 Event channel 2 output to pin
011 3 Event channel 3 output to pin
100 4 Event channel 4 output to pin
101 5 Event channel 5 output to pin
110 6 Event channel 6 output to pin
111 7 Event channel 7 output to pin
XMEGA B [MANUAL] 144
Atmel-8291C-AVR-XMEGA B -09/2014
12.14 Register Descriptions – Virtual Port
12.14.1 DIR – Data Direction register
z Bit 7:0 – DIR[7:0]: Data Direction
This register sets the data direction for the individual pins in the port mapped by VPCTRLA, virtual port-map control
register A or VPCTRLB, virtual port-map control register B. When a port is mapped as virtual, accessing this register is
identical to accessing the actual DIR register for the port.
12.14.2 OUT – Data Output Value register
z Bit 7:0 – OUT[7:0]: Data Output value
This register sets the data output value for the individual pins in the port mapped by VPCTRLA, virtual port-map control
register A or VPCTRLB, virtual port-map control register B. When a port is mapped as virtual, accessing this register is
identical to accessing the actual OUT register for the port.
12.14.3 IN – Data Input Value register
z Bit 7:0 – IN[7:0]: Data Input value
This register shows the value present on the pins if the digital input buffer is enabled. The configuration of VPCTRLA,
virtual port-map control register A or VPCTRLB, virtual port-map control register A, decides the value in the register.
When a port is mapped as virtual, accessing this register is identical to accessing the actual IN register for the port.
Bit 7 6 5 4 3 2 1 0
+0x00 DIR[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 00000000
Bit 7 6 5 4 3 2 1 0
+0x01 OUT[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0000000
Bit 7 6 5 4 3 2 1 0
+0x02 IN[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 145
Atmel-8291C-AVR-XMEGA B -09/2014
12.14.4 INTFLAGS – Interrupt Flag register
z Bit 7:2 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 1:0 – INTnIF: Interrupt n Flag
The INTnIF flag is set when a pin change/state matches the pin's input sense configuration, and the pin is set as source
for port interrupt n. Writing a one to this flag's bit location will clear the flag. For enabling and executing the interrupt, refer
to the interrupt level description. The configuration of VPCTRLA, virtual port-map control register A, or VPCTRLB, Virtual
Port-map Control Register B, decides which flags are mapped. When a port is mapped as virtual, accessing this register
is identical to accessing the actual INTFLAGS register for the port.
Bit 7 6 5 4 3 2 1 0
+0x03 – – – – – – INT1IF INT0IF
Read/Write R R R R R R R/W R/W
Initial Value 00000000
XMEGA B [MANUAL] 146
Atmel-8291C-AVR-XMEGA B -09/2014
12.15 Register Summary – Ports
12.16 Register Summary – Port Configuration
12.17 Register Summary – Virtual Ports
Address Name Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 Page
+0x00 DIR DIR[7:0] 133
+0x01 DIRSET DIRSET[7:0] 133
+0x02 DIRCLR DIRCLR[7:0] 133
+0x03 DIRTGL DIRTGL[7:0] 134
+0x04 OUT OUT[7:0] 134
+0x05 OUTSET OUTSET[7:0] 134
+0x06 OUTCLR OUTCLR[7:0] 134
+0x07 OUTTGL OUTTGL[7:0] 135
+0x08 IN IN[7:0] 135
+0x09 INTCTRL – – – – INT1LVL[1:0] INT0LVL[1:0] 135
+0x0A INT0MASK INT0MSK[7:0] 136
+0x0B INT1MASK INT1MSK[7:0] 136
+0x0C INTFLAGS – – – – – – INT1IF INT0IF 136
+0x0D Reserved – – – – – – – –
+0x0E REMAP – – SPI USART0 TC0D TC0C TC0B TC0A 137
+0x0F Reserved – – – – – – – –
+0x10 PIN0CTRL – INVEN OPC[2:0] ISC[2:0] 138
+0x11 PIN1CTRL – INVEN OPC[2:0] ISC[2:0] 138
+0x12 PIN2CTRL – INVEN OPC[2:0] ISC[2:0] 138
+0x13 PIN3CTRL – INVEN OPC[2:0] ISC[2:0] 138
+0x14 PIN4CTRL – INVEN OPC[2:0] ISC[2:0] 138
+0x15 PIN5CTRL – INVEN OPC[2:0] ISC[2:0] 138
+0x16 PIN6CTRL – INVEN OPC[2:0] ISC[2:0] 138
+0x17 PIN7CTRL – INVEN OPC[2:0] ISC[2:0] 138
+0x18 Reserved – – – – – – – –
+0x19 Reserved – – – – – – – –
+0x1A Reserved – – – – – – – –
+0x1B Reserved – – – – – – – –
+0x1C Reserved – – – – – – – –
+0x1D Reserved – – – – – – – –
+0x1E Reserved – – – – – – – –
+0x1F Reserved – – – – – – – –
Address Name Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 Page
+0x00 MPCMASK MPCMASK[7:0] 140
+0x01 Reserved – – – – – – – –
+0x02 VPCTRLA VP1MAP[3:0] VP0MAP[3:0] 140
+0x03 VPCTRLB VP3MAP[3:0] VP2MAP[3:0] 140
+0x04 CLKEVOU CLKEVPIN RTCOUT EVOUT[1:0] CLKOUTSEL CLKOUT[1:0] 141
+0x05 Reserved – – – – – – – –
+0x06 EVCTRL – – – – – EVCTRL[2:0] 143
+0x07 Reserved – – – – – – – –
Address Name Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 Page
+0x00 DIR DIR[7:0] 144
+0x01 OUT OUT[7:0] 144
+0x02 IN IN[7:0] 144
+0x03 INTFLAGS – – – – – – INT1IF INT0IF 145
XMEGA B [MANUAL] 147
Atmel-8291C-AVR-XMEGA B -09/2014
12.18 Interrupt Vector Summary – Ports
Offset Source Interrupt Description
0x00 INT0_vect Port interrupt vector 0 offset
0x02 INT1_vect Port interrupt vector 1 offset
XMEGA B [MANUAL] 148
Atmel-8291C-AVR-XMEGA B -09/2014
13. TC0/1 – 16-bit Timer/Counter Type 0 and 1
13.1 Features
z 16-bit timer/counter
z 32-bit timer/counter support by cascading two timer/counters
z Up to four compare or capture (CC) channels
z Four CC channels for timer/counters of type 0
z Two CC channels for timer/counters of type 1
z Double buffered timer period setting
z Double buffered capture or compare channels
z Waveform generation:
z Frequency generation
z Single-slope pulse width modulation
z Dual-slope pulse width modulation
z Input capture:
z Input capture with noise cancelling
z Frequency capture
z Pulse width capture
z 32-bit input capture
z Timer overflow and error interrupts/events
z One compare match or input capture interrupt/event per CC channel
z Can be used with event system for:
z Quadrature decoding
z Count and direction control
z Capture
z Can be used with DMA and to trigger DMA transactions
z High-resolution extension
z Increases frequency and waveform resolution by 4x (2-bit) or 8x (3-bit)
z Advanced waveform extension:
z Low- and high-side output with programmable dead-time insertion (DTI)
z Event controlled fault protection for safe disabling of drivers
13.2 Overview
Atmel AVR XMEGA devices have a set of flexible, 16-bit timer/counters (TC). Their capabilities include accurate program
execution timing, frequency and waveform generation, and input capture with time and frequency measurement of digital
signals. Two timer/counters can be cascaded to create a 32-bit timer/counter with optional 32-bit capture.
A timer/counter consists of a base counter and a set of compare or capture (CC) channels. The base counter can be
used to count clock cycles or events. It has direction control and period setting that can be used for timing. The CC
channels can be used together with the base counter to do compare match control, frequency generation, and pulse
width waveform modulation, as well as various input capture operations. A timer/counter can be configured for either
capture or compare functions, but cannot perform both at the same time.
A timer/counter can be clocked and timed from the peripheral clock with optional prescaling or from the event system.
The event system can also be used for direction control and capture trigger or to synchronize operations.
There are two differences between timer/counter type 0 and type 1. Timer/counter 0 has four CC channels, and
timer/counter 1 has two CC channels. All information related to CC channels 3 and 4 is valid only for timer/counter 0.
Only Timer/Counter 0 has the split mode feature that split it into two 8-bit Timer/Counters with four compare channels
each.
XMEGA B [MANUAL] 149
Atmel-8291C-AVR-XMEGA B -09/2014
Some timer/counters have extensions to enable more specialized waveform and frequency generation. The advanced
waveform extension (AWeX) is intended for motor control and other power control applications. It enables low- and highside
output with dead-time insertion, as well as fault protection for disabling and shutting down external drivers. It can
also generate a synchronized bit pattern across the port pins. The high-resolution (hi-res) extension can be used to
increase the waveform output resolution by four or eight times by using an internal clock source running up to four times
faster than the peripheral clock.
A block diagram of the 16-bit timer/counter with extensions and closely related peripheral modules (in grey) is shown in
Figure 13-1 on page 149.
Figure 13-1. 16-bit timer/counter and closely related peripherals.
13.2.1 Definitions
The following definitions are used throughout the documentation:
Table 13-1. Timer/counter definitions
In general, the term “timer” is used when the timer/counter clock control is handled by an internal source, and the term
“counter” is used when the clock control is handled externally (e.g. counting external events). When used for compare
operations, the CC channels are referred to as “compare channels.” When used for capture operations, the CC channels
are referred to as “capture channels.”
Name Description
BOTTOM The counter reaches BOTTOM when it becomes zero.
MAX The counter reaches MAXimum when it becomes all ones.
TOP
The counter reaches TOP when it becomes equal to the highest value in the count sequence. The TOP
value can be equal to the period (PER) or the compare channel A (CCA) register setting. This is selected
by the waveform generator mode.
UPDATE The timer/counter signals an update when it reaches BOTTOM or TOP, depending on the waveform
generator mode.
XMEGA B [MANUAL] 150
Atmel-8291C-AVR-XMEGA B -09/2014
13.3 Block Diagram
Figure 13-2 on page 150 shows a detailed block diagram of the timer/counter without the extensions.
Figure 13-2. Timer/counter block diagram.
The counter register (CNT), period registers with buffer (PER and PERBUF), and compare and capture registers with
buffers (CCx and CCxBUF) are 16-bit registers. All buffer register have a buffer valid (BV) flag that indicates when the
buffer contains a new value.
During normal operation, the counter value is continuously compared to zero and the period (PER) value to determine
whether the counter has reached TOP or BOTTOM.
The counter value is also compared to the CCx registers. These comparisons can be used to generate interrupt
requests, request DMA transactions or generate events for the event system. The waveform generator modes use these
comparisons to set the waveform period or pulse width.
A prescaled peripheral clock and events from the event system can be used to control the counter. The event system is
also used as a source to the input capture. Combined with the quadrature decoding functionality in the event system
(QDEC), the timer/counter can be used for quadrature decoding.
Base Counter
Compare/Capture
(Unit x = {A,B,C,D})
Counter
=
CCx
CCBUFx
Waveform
Generation
BV
=
PERBUF
PER
CNT
BV
= 0
"count"
"clear"
"direction"
"load" Control Logic
CTRLD
CTRLA
OVF/UNF
(INT/DMA Req.)
ERRIF
(INT Req.)
TOP
"match" CCxIF
(INT/DMA
Req.)
Control Logic
Clock Select "ev" UPDATE
BOTTOM
OCx Out
Event
Select
XMEGA B [MANUAL] 151
Atmel-8291C-AVR-XMEGA B -09/2014
13.4 Clock and Event Sources
The timer/counter can be clocked from the peripheral clock (clkPER) or the event system, and Figure 13-3 shows the clock
and event selection.
Figure 13-3. Clock and event selection.
The peripheral clock is fed into a common prescaler (common for all timer/counters in a device). Prescaler outputs from 1
to 1/1024 are directly available for selection by the timer/counter. In addition, the whole range of prescaling from 1 to 215
times is available through the event system.
Clock selection (CLKSEL) selects one of the prescaler outputs directly or an event channel as the counter (CNT) input.
This is referred to as normal operation of the counter. For details, refer to “Normal Operation” on page 152. By using the
event system, any event source, such as an external clock signal on any I/O pin, may be used as the clock input.
In addition, the timer/counter can be controlled via the event system. The event selection (EVSEL) and event action
(EVACT) settings are used to trigger an event action from one or more events. This is referred to as event action
controlled operation of the counter. For details, refer to “Event Action Controlled Operation” on page 153. When event
action controlled operation is used, the clock selection must be set to use an event channel as the counter input.
By default, no clock input is selected and the timer/counter is not running.
13.5 Double Buffering
The period register and the CC registers are all double buffered. Each buffer register has a buffer valid (BV) flag, which
indicates that the buffer register contains a valid, i.e. new, value that can be copied into the corresponding period or CC
register. When the period register and CC channels are used for a compare operation, the buffer valid flag is set when
data is written to the buffer register and cleared on an UPDATE condition. This is shown for a compare register in Figure
13-4 on page 152.
clkPER /
2{0,...,15}
CKSEL
CNT
EVACT
clkPER /
{1,2,4,8,64,256,1024}
Common
Prescaler clkPER
event channels
(Encoding)
Event System
EVSEL Control Logic
events
XMEGA B [MANUAL] 152
Atmel-8291C-AVR-XMEGA B -09/2014
Figure 13-4. Period and compare double buffering.
When the CC channels are used for a capture operation, a similar double buffering mechanism is used, but in this case
the buffer valid flag is set on the capture event, as shown in Figure 13-5. For capture, the buffer register and the
corresponding CCx register act like a FIFO. When the CC register is empty or read, any content in the buffer register is
passed to the CC register. The buffer valid flag is passed to set the CCx interrupt flag (IF) and generate the optional
interrupt.
Figure 13-5. Capture double buffering.
Both the CCx and CCxBUF registers are available as an I/O register. This allows initialization and bypassing of the buffer
register and the double buffering function.
13.6 Counter Operation
Depending on the mode of operation, the counter is cleared, reloaded, incremented, or decremented at each
timer/counter clock input.
13.6.1 Normal Operation
In normal operation, the counter will count in the direction set by the direction (DIR) bit for each clock until it reaches TOP
or BOTTOM. When up-counting and TOP is reached, the counter will be set to zero when the next clock is given. When
down-counting, the counter is reloaded with the period register value when BOTTOM is reached.
BV
UPDATE
"write enable" "data write"
=
CNT
"match"
CCxBUF
EN CCx
EN
BV
"capture"
IF
CNT
CCxBUF
EN CCx
EN
"INT/DMA
request" data read
XMEGA B [MANUAL] 153
Atmel-8291C-AVR-XMEGA B -09/2014
Figure 13-6. Normal operation.
As shown in Figure 13-6, it is possible to change the counter value when the counter is running. The write access has
higher priority than count, clear, or reload, and will be immediate. The direction of the counter can also be changed
during normal operation.
Normal operation must be used when using the counter as timer base for the capture channels.
13.6.2 Event Action Controlled Operation
The event selection and event action settings can be used to control the counter from the event system. For the counter,
the following event actions can be selected:
z Event system controlled up/down counting.
z Event n will be used as count enable.
z Event n+1 will be used to select between up (1) and down (0). The pin configuration must be set to low level
sensing.
z Event system controlled quadrature decode counting.
13.6.3 32-bit Operation
Two timer/counters can be used together to enable 32-bit counter operation. By using two timer/counters, the overflow
event from one timer/counter (least-significant timer) can be routed via the event system and used as the clock input for
another timer/counter (most-significant timer).
13.6.4 Changing the Period
The counter period is changed by writing a new TOP value to the period register. If double buffering is not used, any
period update is immediate, as shown in Figure 13-7 on page 153.
Figure 13-7. Changing the period without buffering.
CNT
BOTTOM
MAX
"update"
TOP
CNT written
DIR
CNT
MAX
New TOP written to
PER that is higher
than current CNT
Counter Wraparound
New TOP written to
PER that is lower
than current CNT
"update"
"write"
BOTTOM
XMEGA B [MANUAL] 154
Atmel-8291C-AVR-XMEGA B -09/2014
A counter wraparound can occur in any mode of operation when up-counting without buffering, as shown in Figure 13-8.
This due to the fact that CNT and PER are continuously compared, and if a new TOP value that is lower than current
CNT is written to PER, it will wrap before a compare match happen.
Figure 13-8. Unbuffered dual-slope operation.
When double buffering is used, the buffer can be written at any time and still maintain correct operation. The period
register is always updated on the UPDATE condition, as shown for dual-slope operation in Figure 13-9. This prevents
wraparound and the generation of odd waveforms.
Figure 13-9. Changing the period using buffering.
13.7 Capture Channel
The CC channels can be used as capture channels to capture external events and give them a timestamp. To use
capture, the counter must be set for normal operation.
Events are used to trigger the capture; i.e., any events from the event system, including pin change from any pin, can
trigger a capture operation. The event source select setting selects which event channel will trigger CC channel A. The
subsequent event channels then trigger events on subsequent CC channels, if configured. For example, setting the
event source select to event channel 2 results in CC channel A being triggered by event channel 2, CC channel B
triggered by event channel 3, and so on.
CNT
MAX
New TOP written to
PER that is higher
than current CNT
New TOP written to
PER that is lower
than current CNT
"update"
"write"
Counter Wraparound
BOTTOM
CNT
MAX
New Period written to
PERBUF that is higher
than current CNT
New Period written to
PERBUF that is lower
than current CNT
"update"
"write"
New PER is updated
with PERBUF value.
BOTTOM
XMEGA B [MANUAL] 155
Atmel-8291C-AVR-XMEGA B -09/2014
Figure 13-10.Event source selection for capture operation.
The event action setting in the timer/counter will determine the type of capture that is done.
The CC channels must be enabled individually before capture can be done. When the capture condition occur, the
timer/counter will time-stamp the event by copying the current CNT value in the count register into the enabled CC
channel register.
When an I/O pin is used as an event source for the capture, the pin must be configured for edge sensing. For details on
sense configuration on I/O pins, refer to “Input Sense Configuration” on page 129. If the period register value is lower
than 0x8000, the polarity of the I/O pin edge will be stored in the most-significant bit (msb) of the capture register. If the
msb of the capture register is zero, a falling edge generated the capture. If the msb is one, a rising edge generated the
capture.
13.7.1 Input Capture
Selecting the input capture event action makes the enabled capture channel perform an input capture on an event. The
interrupt flags will be set and indicate that there is a valid capture result in the corresponding CC register. At the same
time, the buffer valid flags indicate valid data in the buffer registers.
The counter will continuously count from BOTTOM to TOP, and then restart at BOTTOM, as shown in Figure 13-11. The
figure also shows four capture events for one capture channel.
Figure 13-11.Input capture timing.
13.7.2 Frequency Capture
Selecting the frequency capture event action makes the enabled capture channel perform an input capture and restart on
positive edge events. This enables the timer/counter to measure the period or frequency of a signal directly. The capture
result will be the time (T) from the previous timer/counter restart until the event occurred. This can be used to calculate
the frequency (f) of the signal:
Event System
CH0MUX
CH1MUX
CHnMUX
Rotate
Event channel n
Event Source Selection
CCA capture
CCB capture
CCC capture
CCD capture
Event channel 0
Event channel 1
events
CNT
TOP
BOTTOM
Capture 0 Capture 1 Capture 2 Capture 3
f 1
T = ---
XMEGA B [MANUAL] 156
Atmel-8291C-AVR-XMEGA B -09/2014
Figure 13-12 on page 156 shows an example where the period of an external signal is measured twice.
Figure 13-12.Frequency capture of an external signal.
Since all capture channels use the same counter (CNT), only one capture channel must be enabled at a time. If two
capture channels are used with different sources, the counter will be restarted on positive edge events from both input
sources, and the result will have no meaning.
13.7.3 Pulse Width Capture
Selecting the pulse width measure event action makes the enabled compare channel perform the input capture action on
falling edge events and the restart action on rising edge events. The counter will then restart on positive edge events,
and the input capture will be performed on the negative edge event. The event source must be an I/O pin, and the sense
configuration for the pin must be set to generate an event on both edges. Figure 13-13 on page 156 shows and example
where the pulse width is measured twice for an external signal.
Figure 13-13.Pulse width capture of an external signal.
Period (T)
external signal
events
CNT
MAX
BOTTOM
"capture"
Pulsewitdh (tp)
external signal
events
CNT
MAX
BOTTOM
"capture"
XMEGA B [MANUAL] 157
Atmel-8291C-AVR-XMEGA B -09/2014
13.7.4 32-bit Input Capture
Two timer/counters can be used together to enable true 32-bit input capture. In a typical 32-bit input capture setup, the
overflow event of the least-significant timer is connected via the event system and used as the clock input for the mostsignificant
timer.
The most-significant timer will be updated one peripheral clock period after an overflow occurs for the least-significant
timer. To compensate for this, the capture event for the most-significant timer must be equally delayed by setting the
event delay bit for this timer.
13.7.5 Capture Overflow
The timer/counter can detect buffer overflow of the input capture channels. When both the buffer valid flag and the
capture interrupt flag are set and a new capture event is detected, there is nowhere to store the new timestamp. If a
buffer overflow is detected, the new value is rejected, the error interrupt flag is set, and the optional interrupt is
generated.
13.8 Compare Channel
Each compare channel continuously compares the counter value (CNT) with the CCx register. If CNT equals CCx, the
comparator signals a match. The match will set the CC channel's interrupt flag at the next timer clock cycle, and the
event and optional interrupt are generated.
The compare buffer register provides double buffer capability equivalent to that for the period buffer. The double
buffering synchronizes the update of the CCx register with the buffer value to either the TOP or BOTTOM of the counting
sequence according to the UPDATE condition. The synchronization prevents the occurrence of odd-length, nonsymmetrical
pulses for glitch-free output.
13.8.1 Waveform Generation
The compare channels can be used for waveform generation on the corresponding port pins. To make the waveform
visible on the connected port pin, the following requirements must be fulfilled:
1. A waveform generation mode must be selected.
2. Event actions must be disabled.
3. The CC channels used must be enabled. This will override the corresponding port pin output register.
4. The direction for the associated port pin must be set to output.
Inverted waveform output is achieved by setting the invert output bit for the port pin.
13.8.2 Frequency (FRQ) Waveform Generation
For frequency generation the period time (T) is controlled by the CCA register instead of PER. The waveform generation
(WG) output is toggled on each compare match between the CNT and CCA registers, as shown in Figure 13-14 on page
158.
XMEGA B [MANUAL] 158
Atmel-8291C-AVR-XMEGA B -09/2014
Figure 13-14.Frequency waveform generation.
The waveform frequency (fFRQ) is defined by the following equation:
where N represents the prescaler divider used. The waveform generated will have a maximum frequency of half of the
peripheral clock frequency (fclkPER) when CCA is set to zero (0x0000) and no prescaling is used. This also applies when
using the hi-res extension, since this increases the resolution and not the frequency.
13.8.3 Single-slope PWM Generation
For single-slope PWM generation, the period (T) is controlled by PER, while CCx registers control the duty cycle of the
WG output. Figure 13-15 shows how the counter counts from BOTTOM to TOP and then restarts from BOTTOM. The
waveform generator (WG) output is set on the compare match between the CNT and CCx registers and cleared at TOP.
Figure 13-15.Single-slope pulse width modulation.
The PER register defines the PWM resolution. The minimum resolution is 2 bits (PER=0x0003), and the maximum
resolution is 16 bits (PER=MAX).
The following equation calculate the exact resolution for single-slope PWM (RPWM_SS):
The single-slope PWM frequency (fPWM_SS) depends on the period setting (PER) and the peripheral clock frequency
(fclkPER), and can be calculated by the following equation:
CNT
MAX
"update"
TOP
Period (T) Direction Change CNT written
BOTTOM
WG Output
f FRQ
fclkPER
2N CCA ( ) + 1 = ----------------------------------
CNT
MAX
TOP
Period (T) "match"
BOTTOM
WG Output
CCx=BOTTOM
CCx
CCx=TOP "update"
RPWM_SS
log( ) PER 1 +
log( ) 2 = ---------------------------------
XMEGA B [MANUAL] 159
Atmel-8291C-AVR-XMEGA B -09/2014
where N represents the prescaler divider used. The waveform generated will have a maximum frequency of half of the
peripheral clock frequency (fclkPER) when CCA is set to zero (0x0000) and no prescaling is used. This also applies when
using the hi-res extension, since this increases the resolution and not the frequency.
13.8.4 Dual-slope PWM
For dual-slope PWM generation, the period (T) is controlled by PER, while CCx registers control the duty cycle of the WG
output. Figure 13-16 shows how for dual-slope PWM the counter counts repeatedly from BOTTOM to TOP and then from
TOP to BOTTOM. The waveform generator output is set on BOTTOM, cleared on compare match when up-counting,
and set on compare match when down-counting.
Figure 13-16.Dual-slope pulse width modulation.
Using dual-slope PWM results in a lower maximum operation frequency compared to the single-slope PWM operation.
The period register (PER) defines the PWM resolution. The minimum resolution is 2 bits (PER=0x0003), and the
maximum resolution is 16 bits (PER=MAX).
The following equation calculate the exact resolution for dual-slope PWM (RPWM_DS):
The PWM frequency depends on the period setting (PER) and the peripheral clock frequency (fclkPER), and can be
calculated by the following equation:
N represents the prescaler divider used. The waveform generated will have a maximum frequency of half of the
peripheral clock frequency (fclkPER) when CCA is set to zero (0x0000) and no prescaling is used. This also applies when
using the hi-res extension, since this increases the resolution and not the frequency.
13.8.5 Port Override for Waveform Generation
To make the waveform generation available on the port pins, the corresponding port pin direction must be set as output.
The timer/counter will override the port pin values when the CC channel is enabled (CCENx) and a waveform generation
mode is selected.
f PWM_SS
fclkPER
N( ) PER 1 + = -----------------------------
CNT
MAX
TOP
Period (T)
BOTTOM
WG Output
CCx=BOTTOM
CCx
CCx=TOP "match"
"update"
RPWM_DS
log( ) PER 1 +
log( ) 2 = ---------------------------------
f PWM_DS
fclkPER
2NPER = --------------------
XMEGA B [MANUAL] 160
Atmel-8291C-AVR-XMEGA B -09/2014
Figure 13-17 on page 160 shows the port override for a timer/counter. The timer/counter CC channel will override the
port pin output value (OUT) on the corresponding port pin. Enabling inverted I/O on the port pin (INVEN) inverts the
corresponding WG output.
Figure 13-17.Port override for timer/counter 0 and 1.
13.9 Interrupts and events
The timer/counter can generate both interrupts and events. The counter can generate an interrupt on overflow/underflow,
and each CC channel has a separate interrupt that is used for compare or capture. In addition, an error interrupt can be
generated if any of the CC channels is used for capture and a buffer overflow condition occurs on a capture channel.
Events will be generated for all conditions that can generate interrupts. For details on event generation and available
events, refer to “Event System” on page 63.
13.10 DMA Support
The interrupt flags can be used to trigger DMA transactions. Table 13-2 lists the transfer triggers available from the
timer/counter and the DMA action that will clear the transfer trigger. For more details on using DMA, refer to “DMAC -
Direct Memory Access Controller” on page 47.
Table 13-2. DMA request sources
13.11 Timer/Counter Commands
A set of commands can be given to the timer/counter by software to immediately change the state of the module. These
commands give direct control of the UPDATE, RESTART, and RESET signals.
An update command has the same effect as when an update condition occurs. The update command is ignored if the
lock update bit is set.
The software can force a restart of the current waveform period by issuing a restart command. In this case the counter,
direction, and all compare outputs are set to zero.
A reset command will set all timer/counter registers to their initial values. A reset can be given only when the
timer/counter is not running (OFF).
OUT
CCExEN INVEN
OCx Waveform
Request Acknowledge Comment
OVFIF/UNFIF
DMA controller writes to CNT
DMA controller writes to PER
DMA controller writes to PERBUF
DMA controller writes to DTHSBUF or DTLSBUF in
AWeX when in Pattern Generation Mode
ERRIF N/A
CCxIF DMA controller access of CCx
DMA controller access of CCxBUF
Input capture operation
Output compare operation
XMEGA B [MANUAL] 161
Atmel-8291C-AVR-XMEGA B -09/2014
13.12 Register Description
13.12.1 CTRLA – Control register A
z Bit 7:4 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 3:0 – CLKSEL[3:0]: Clock Select
These bits select the clock source for the timer/counter according to Table 13-3.
CLKSEL=0001 must be set to ensure a correct output from the waveform generator when the hi-res extension is
enabled.
Table 13-3. Clock select options
13.12.2 CTRLB – Control register B
z Bit 7:4 – CCxEN: Compare or Capture Enable
Setting these bits in the FRQ or PWM waveform generation mode of operation will override the port output register for the
corresponding OCn output pin. When input capture operation is selected, the CCxEN bits enable the capture operation
for the corresponding CC channel.
Bit 7 6 5 4 3 2 1 0
+0x00 – – – – CLKSEL[3:0]
Read/Write R R R R R/W R/W R/W R/W
Initial Value 00000000
CLKSEL[3:0] Group Configuration Description
0000 OFF None (i.e, timer/counter in OFF state)
0001 DIV1 Prescaler: Clk
0010 DIV2 Prescaler: Clk/2
0011 DIV4 Prescaler: Clk/4
0100 DIV8 Prescaler: Clk/8
0101 DIV64 Prescaler: Clk/64
0110 DIV256 Prescaler: Clk/256
0111 DIV1024 Prescaler: Clk/1024
1nnn EVCHn Event channel n, n= [0,...,7]
Bit 7 6 5 4 3 2 1 0
+0x01 CCDEN CCCEN CCBEN CCAEN – WGMODE[2:0]
Read/Write R/W R/W R/W R/W R R/W R/W R/W
Initial Value 00000000
XMEGA B [MANUAL] 162
Atmel-8291C-AVR-XMEGA B -09/2014
z Bit 3 – Reserved
This bit is unused and reserved for future use. For compatibility with future devices, always write this bit to zero when this
register is written.
z Bit 2:0 – WGMODE[2:0]: Waveform Generation Mode
These bits select the waveform generation mode, and control the counting sequence of the counter, TOP value,
UPDATE condition, interrupt/event condition, and type of waveform that is generated according to Table 13-4.
No waveform generation is performed in the normal mode of operation. For all other modes, the result from the waveform
generator will only be directed to the port pins if the corresponding CCxEN bit has been set to enable this. The port pin
direction must be set as output.
Table 13-4. Timer waveform generation mode.
13.12.3 CTRLC – Control register C
z Bit 7:4 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 3:0 – CMPx: Compare Output Value x
These bits allow direct access to the waveform generator's output compare value when the timer/counter is set in the
OFF state. This is used to set or clear the WG output value when the timer/counter is not running.
WGMODE[2:0]
Group
Configuration
Mode of
Operation Top Update OVFIF/Event
000 NORMAL Normal PER TOP TOP
001 FRQ Frequency CCA TOP TOP
010 Reserved - - -
011 SINGLESLOPE Single-slope
PWM PER BOTTOM BOTTOM
100 Reserved - - -
101 DSTOP Dual-slope PWM PER BOTTOM TOP
110 DSBOTH Dual-slope PWM PER BOTTOM TOP and BOTTOM
111 DSBOTTOM Dual-slope PWM PER BOTTOM BOTTOM
Bit 7 6 5 4 3 2 1 0
+0x02 – – – – CMPD CMPC CMPB CMPA
Read/Write R R R R R/W R/W R/W R/W
Initial Value 0 0 0 0 0000
XMEGA B [MANUAL] 163
Atmel-8291C-AVR-XMEGA B -09/2014
13.12.4 CTRLD – Control register D
z Bit 7:5 – EVACT[2:0]: Event Action
These bits define the event action the timer will perform on an event according to Table 13-5 on page 163.
The EVSEL setting will decide which event source or sources have control in this case.
Table 13-5. Timer event action selection.
Selecting any of the capture event actions changes the behavior of the CCx registers and related status and control bits
to be used for capture. The error status flag (ERRIF) will indicate a buffer overflow in this configuration. See “Event
Action Controlled Operation” on page 153 for further details.
z Bit 4 – EVDLY: Timer Delay Event
When this bit is set, the selected event source is delayed by one peripheral clock cycle. This is intended for 32-bit input
capture operation. Adding the event delay is necessary to compensate for the carry propagation delay when cascading
two counters via the event system.
z Bit 3:0 – EVSEL[3:0]:Timer Event Source Select
These bits select the event channel source for the timer/counter. For the selected event channel to have any effect, the
event action bits (EVACT) must be set according to Table 13-6. When the event action is set to a capture operation, the
selected event channel n will be the event channel source for CC channel A, and event channel (n+1)%8, (n+2)%8, and
(n+3)%8 will be the event channel source for CC channel B, C, and D.
Table 13-6. Timer event source selection
Bit 7 6 5 4 3 2 1 0
+0x03 EVACT[2:0] EVDLY EVSEL[3:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
EVACT[2:0] Group Configuration Event Action
000 OFF None
001 CAPT Input capture
010 UPDOWN Externally controlled up/ down count
011 QDEC Quadrature decode
100 RESTART Restart waveform period
101 FRQ Frequency capture
110 PW Pulse width capture
111 Reserved
EVSEL[3:0] Group Configuration Event Source
0000 OFF None
0001 – Reserved
0010 – Reserved
0011 – Reserved
XMEGA B [MANUAL] 164
Atmel-8291C-AVR-XMEGA B -09/2014
13.12.5 CTRLE – Control register E
z Bit 7:2 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 1:0 – BYTEM[1:0]: Byte Mode
These bits select the timer/counter operation mode according to Table 13-7.
Table 13-7. Clock select
13.12.6 INTCTRLA – Interrupt Enable register A
z Bit 7:4 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
0100 – Reserved
0101 – Reserved
0110 – Reserved
0111 – Reserved
1nnn CHn Event channel n, n={0,...,7}
EVSEL[3:0] Group Configuration Event Source
Bit 7 6 5 4 3 2 1 0
+0x04 – – – – – – BYTEM[1:0]
Read/Write R R R R R R R R/W
Initial Value 00000000
BYTEM[1:0] Group Configuration Description
00 NORMAL Timer/counter is set to normal mode (timer/counter type 0)
01 BYTEMODE Upper byte of the counter (CNTH) will be set to zero after each counter
clock cycle
10 SPLITMODE Timer/counter 0 is split into two 8-bit timer/counters (timer/counter type 2)
11 – Reserved
Bit 7 6 5 4 3 2 1 0
+0x06 – – – – ERRINTLVL[1:0] OVFINTLVL[1:0]
Read/Write R R R R R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 165
Atmel-8291C-AVR-XMEGA B -09/2014
z Bit 3:2 – ERRINTLVL[1:0]:Timer Error Interrupt Level
These bits enable the timer error interrupt and select the interrupt level as described in “Interrupts and Programmable
Multilevel Interrupt Controller” on page 115.
z Bit 1:0 – OVFINTLVL[1:0]:Timer Overflow/Underflow Interrupt Level
These bits enable the timer overflow/underflow interrupt and select the interrupt level as described in “Interrupts and
Programmable Multilevel Interrupt Controller” on page 115.
13.12.7 INTCTRLB – Interrupt Enable register B
z Bit 7:0 – CCxINTLVL[7:0] - Compare or Capture x Interrupt Level
These bits enable the timer compare or capture interrupt for channel x and select the interrupt level as described in
“Interrupts and Programmable Multilevel Interrupt Controller” on page 115.
13.12.8 CTRLFCLR/CTRLFSET – Control register F Clear/Set
This register is mapped into two I/O memory locations, one for clearing (CTRLxCLR) and one for setting the register bits
(CTRLxSET) when written. Both memory locations will give the same result when read.
The individual status bit can be set by writing a one to its bit location in CTRLxSET, and cleared by writing a one to its bit
location in CTRLxCLR. This allows each bit to be set or cleared without use of a read-modify-write operation on a single
register.
13.12.8.1 CTRLFCLR
13.12.8.2 CTRLFSET
z Bit 7:4 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 3:2 – CMD[1:0]: Command
These bits can be used for software control of update, restart, and reset of the timer/counter. The command bits are
always read as zero.
Bit 7 6 5 4 3 2 1 0
+0x07 CCDINTLVL[1:0] CCCINTLVL[1:0] CCBINTLVL[1:0] CCAINTLVL[1:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0000000
Bit 7 6 5 4 3 2 1 0
+0x08 – – – – CMD[1:0] LUPD DIR
Read/Write R R R R R R R/W R/W
Initial Value 0 0 0 00000
Bit 7 6 5 4 3 2 1 0
+0x09 – – – – CMD[1:0] LUPD DIR
Read/Write R R R R R/W R/W R/W R/W
Initial Value 0 0 0 00000
XMEGA B [MANUAL] 166
Atmel-8291C-AVR-XMEGA B -09/2014
Table 13-8. Command selections
z Bit 1 – LUPD: Lock Update
When this bit is set, no update of the buffered registers is performed, even though an UPDATE condition has occurred.
Locking the update ensures that all buffers, including DTI buffers, are valid before an update is performed.
This bit has no effect when input capture operation is enabled.
z Bit 0 – DIR: Counter Direction
When zero, this bit indicates that the counter is counting up (incrementing). A one indicates that the counter is in the
down-counting (decrementing) state.
Normally this bit is controlled in hardware by the waveform generation mode or by event actions, but this bit can also be
changed from software.
13.12.9 CTRLGCLR/CTRLGSET – Control register G Clear/Set
Refer to “CTRLFCLR/CTRLFSET – Control register F Clear/Set” on page 165 for information on how to access this type
of status register.
z Bit 7:5 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 4:1 – CCxBV: Compare or Capture x Buffer Valid
These bits are set when a new value is written to the corresponding CCxBUF register. These bits are automatically
cleared on an UPDATE condition.
Note that when input capture operation is used, this bit is set on a capture event and cleared if the corresponding CCxIF
is cleared.
z Bit 0 – PERBV: Period Buffer Valid
This bit is set when a new value is written to the PERBUF register. This bit is automatically cleared on an UPDATE
condition.
CMD Group Configuration Command Action
00 NONE None
01 UPDATE Force update
10 RESTART Force restart
11 RESET Force hard reset (ignored if T/C is not in OFFstate)
Bit 7 6 5 4 3 2 1 0
+0x0A/ +0x0B – – – CCDBV CCCBV CCBBV CCABV PERBV
Read/Write R R R R/W R/W R/W R/W R/W
Initial Value 0 0 0 00000
XMEGA B [MANUAL] 167
Atmel-8291C-AVR-XMEGA B -09/2014
13.12.10INTFLAGS – Interrupt Flag register
z Bit 7:4 – CCxIF: Compare or Capture Channel x Interrupt Flag
The compare or capture interrupt flag (CCxIF) is set on a compare match or on an input capture event on the
corresponding CC channel.
For all modes of operation except for capture, the CCxIF will be set when a compare match occurs between the count
register (CNT) and the corresponding compare register (CCx). The CCxIF is automatically cleared when the
corresponding interrupt vector is executed.
For input capture operation, the CCxIF will be set if the corresponding compare buffer contains valid data (i.e., when
CCxBV is set). The flag will be cleared when the CCx register is read. Executing the interrupt vector in this mode of
operation will not clear the flag.
The flag can also be cleared by writing a one to its bit location.
The CCxIF can be used for requesting a DMA transfer. A DMA read or write access of the corresponding CCx or
CCxBUF will then clear the CCxIF and release the request.
z Bit 3:2 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 1 – ERRIF: Error Interrupt Flag
This flag is set on multiple occasions, depending on the mode of operation.
In the FRQ or PWM waveform generation mode of operation, ERRIF is set on a fault detect condition from the fault
protection feature in the AWeX extention. For timer/counters which do not have the AWeX extention available, this flag is
never set in FRQ or PWM waveform generation mode.
For capture operation, ERRIF is set if a buffer overflow occurs on any of the CC channels.
For event controlled QDEC operation, ERRIF is set when an incorrect index signal is given.
This flag is automatically cleared when the corresponding interrupt vector is executed. The flag can also be cleared by
writing a one to this location.
z Bit 0 – OVFIF: Overflow/Underflow Interrupt Flag
This flag is set either on a TOP (overflow) or BOTTOM (underflow) condition, depending on the WGMODE setting.
OVFIF is automatically cleared when the corresponding interrupt vector is executed. The flag can also be cleared by
writing a one to its bit location.
OVFIF can also be used for requesting a DMA transfer. A DMA write access of CNT, PER, or PERBUF will then clear the
OVFIF bit.
Bit 7 6 5 4 3 2 1 0
+0x0C CCDIF CCCIF CCBIF CCAIF – – ERRIF OVFIF
Read/Write R/W R/W R/W R/W R R R/W R/W
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 168
Atmel-8291C-AVR-XMEGA B -09/2014
13.12.11TEMP – Temporary bits for 16-bit Access
The TEMP register is used for single-cycle, 16-bit access to the 16-bit timer/counter registers by the CPU. The DMA
controller has a separate temporary storage register. There is one common TEMP register for all the 16-bit Timer/counter
registers.
For more details, refer to “Accessing 16-bit Registers” on page 13.
13.12.12CNTL – Counter register Low
The CNTH and CNTL register pair represents the 16-bit value, CNT. CNT contains the 16-bit counter value in the
timer/counter. CPU and DMA write access has priority over count, clear, or reload of the counter.
For more details on reading and writing 16-bit registers, refer to “Accessing 16-bit Registers” on page 13.
z Bit 7:0 – CNT[7:0]: Counter low byte
These bits hold the LSB of the 16-bit counter register.
13.12.13CNTH – Counter register High
z Bit 7:0 – CNT[15:8]: Counter high byte
These bits hold the MSB of the 16-bit counter register.
13.12.14PERL – Period register Low
The PERH and PERL register pair represents the 16-bit value, PER. PER contains the 16-bit TOP value in the
timer/counter.
z Bit 7:0 – PER[7:0]: Period low byte
These bits hold the LSB of the 16-bit period register.
Bit 7 6 5 4 3 2 1 0
+0x0F TEMP[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 00000
Bit 7 6 5 4 3 2 1 0
+0x20 CNT[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
Bit 7 6 5 4 3 2 1 0
+0x21 CNT[15:8]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 00000000
Bit 7 6 5 4 3 2 1 0
+0x26 PER[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 1 1 111111
XMEGA B [MANUAL] 169
Atmel-8291C-AVR-XMEGA B -09/2014
13.12.15PERH – Period register High
z Bit 7:0 – PER[15:8]: Period high byte
These bits hold the MSB of the 16-bit period register.
13.12.16CCxL – Compare or Capture x register Low
The CCxH and CCxL register pair represents the 16-bit value, CCx. These 16-bit register pairs have two functions,
depending of the mode of operation.
For capture operation, these registers constitute the second buffer level and access point for the CPU and DMA.
For compare operation, these registers are continuously compared to the counter value. Normally, the outputs form the
comparators are then used for generating waveforms.
CCx registers are updated with the buffer value from their corresponding CCxBUF register when an UPDATE condition
occurs.
z Bit 7:0 – CCx[7:0]: Compare or Capture x low byte
These bits hold the LSB of the 16-bit compare or capture register.
13.12.17CCxH – Compare or Capture x register High
z Bit 7:0 – CCx[15:8]: Compare or Capture x high byte
These bits hold the MSB of the 16-bit compare or capture register.
Bit 7 6 5 4 3 2 1 0
+0x27 PER[15:8]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 1 1 1 1 1 1 1 1
Bit 7 6 5 4 3 2 1 0
CCx[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
Bit 7 6 5 4 3 2 1 0
CCx[15:8]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 170
Atmel-8291C-AVR-XMEGA B -09/2014
13.12.18PERBUFL – Timer/Counter Period Buffer Low
The PERBUFH and PERBUFL register pair represents the 16-bit value, PERBUF. This 16-bit register serves as the
buffer for the period register (PER). Accessing this register using the CPU or DMA will affect the PERBUFV flag.
z Bit 7:0 – PERBUF[7:0]: Period Buffer low byte
These bits hold the LSB of the 16-bit period buffer register.
13.12.19PERBUFH – Timer/Counter Period Buffer High
z Bit 7:0 – PERBUF[15:8]: Period Buffer high byte
These bits hold the MSB of the 16-bit period buffer register.
13.12.20CCxBUFL – Compare or Capture x Buffer register Low
The CCxBUFH and CCxBUFL register pair represents the 16-bit value, CCxBUF. These 16-bit registers serve as the
buffer for the associated compare or capture registers (CCx). Accessing any of these registers using the CPU or DMA
will affect the corresponding CCxBV status bit.
z Bit 7:0 – CCxBUF[7:0]: Compare or Capture Buffer low byte
These bits hold the LSB of the 16-bit compare or capture buffer register.
Bit 7 6 5 4 3 2 1 0
+0x36 PERBUF[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 1 1111111
Bit 7 6 5 4 3 2 1 0
+0x37 PERBUF[15:8]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 1 1 1 1 1 1 1 1
Bit 7 6 5 4 3 2 1 0
CCxBUFx[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 00000000
XMEGA B [MANUAL] 171
Atmel-8291C-AVR-XMEGA B -09/2014
13.12.21CCxBUFH – Compare or Capture x Buffer register High
z Bit 7:0 – CCxBUF[15:8]: Compare or Capture Buffer high byte
These bits hold the MSB of the 16-bit compare or capture buffer register.
Bit 7 6 5 4 3 2 1 0
CCxBUF[15:8]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 172
Atmel-8291C-AVR-XMEGA B -09/2014
13.13 Register Summary
13.14 Interrupt Vector Summary
Note: 1. Available only on timer/counters with four compare or capture channels.
Address Name Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 Page
+0x00 CTRLA – – – – CLKSEL[3:0] 161
+0x01 CTRLB CCDEN CCCEN CCBEN CCAEN – WGMODE[2:0] 161
+0x02 CTRLC – – – – CMPD CMPC CMPB CMPA 162
+0x03 CTRLD EVACT[2:0] EVDLY EVSEL[3:0] 163
+0x04 CTRLE – – – – – – BYTEM 164
+0x05 Reserved – – – – – – – –
+0x06 INTCTRLA – – – – ERRINTLVL[1:0] OVINTLVL[1:0] 164
+0x07 INTCTRLB CCCINTLVL[1:0] CCCINTLVL[1:0] CCBINTLVL[1:0] CCAINTLVL[1:0] 164
+0x08 CTRLFCLR – – – – CMD[1:0] LUPD DIR 165
+0x09 CTRLFSET – – – – CMD[1:0] LUPD DIR 166
+0x0A CTRLGCLR – – – CCDBV CCCBV CCBBV CCABV PERBV 166
+0x0B CTRLGSET – – – CCDBV CCCBV CCBBV CCABV PERBV 166
+0x0C INTFLAGS CCDIF CCCIF CCBIF CCAIF – – ERRIF OVFIF 167
+0x0D Reserved – – – – – – – –
+0x0E Reserved – – – – – – – –
+0x0F TEMP TEMP[7:0] 168
+0x10 to Reserved – – – – – – – –
+0x20 CNTL CNT[7:0] 168
+0x21 CNTH CNT[15:8] 168
+0x22 to Reserved – – – – – – – –
+0x26 PERL PER[7:0] 168
+0x27 PERH PER[8:15] 169
+0x28 CCAL CCA[7:0] 169
+0x29 CCAH CCA[15:8] 169
+0x2A CCBL CCB[7:0] 169
+0x2B CCBH CCB[15:8] 169
+0x2C CCCL CCC[7:0] 169
+0x02D CCCH CCC[15:8] 169
+0x2E CCDL CCD[7:0] 169
+0x2F CCDH CCD[15:8] 169
+0x30 to Reserved – – – – – – – –
+0x36 PERBUFL PERBUF[7:0] 170
+0x37 PERBUFH PERBUF[15:8] 170
+0x38 CCABUFL CCABUF[7:0] 170
+0x39 CCABUFH CCABUF[15:8] 171
+0x3A CCBBUFL CCBBUF[7:0] 170
+0x3B CCBBUFH CCBBUF[15:8] 171
+0x3C CCCBUFL CCCBUF[7:0] 170
+0x3D CCCBUFH CCCBUF[15:8] 171
+0x3E CCDBUFL CCDBUF[7:0] 170
+0x3F CCDBUFH CCDBUF[15:8] 171
Offset Source Interrupt Description
0x00 OVF_vect Timer/counter overflow/underflow interrupt vector offset
0x02 ERR_vect Timer/counter error interrupt vector offset
0x04 CCA_vect Timer/counter compare or capture channel A interrupt vector offset
0x06 CCB_vect Timer/counter compare or capture channel B interrupt vector offset
0x08 CCC_vect(1) Timer/counter compare or capture channel C interrupt vector offset
0x0A CCD_vect(1) Timer/counter compare or capture channel D interrupt vector offset
XMEGA B [MANUAL] 173
Atmel-8291C-AVR-XMEGA B -09/2014
14. TC2 – 16-bit Timer/Counter Type 2
14.1 Features
z A system of two eight-bit timer/counters
z Low-byte timer/counter
z High-byte timer/counter
z Eight compare channels
z Four compare channels for the low-byte timer/counter
z Four compare channels for the high-byte timer/counter
z Waveform generation
z Single slope pulse width modulation
z Timer underflow interrupts/events
z One compare match interrupt/event per compare channel for the low-byte timer/counter
z Can be used with the event system for count control
z Can be used to trigger DMA transactions
14.2 Overview
A timer/counter 2 is realized when a timer/counter 0 is set in split mode. It is a system of two eight-bit
timer/counters, each with four compare channels. This results in eight configurable pulse width modulation (PWM)
channels with individually controlled duty cycles, and is intended for applications that require a high number of PWM
channels.
The two eight-bit timer/counters in this system are referred to as the low-byte timer/counter and high-byte timer/counter,
respectively. The difference between them is that only the low-byte timer/counter can be used to generate compare
match interrupts, events and DMA triggers.
The two eight-bit timer/counters have a shared clock source and separate period and compare settings. They can be
clocked and timed from the peripheral clock, with optional prescaling, or from the event system. The counters are always
counting down.
The timer/counter 2 is set back to timer/counter 0 by setting it in normal mode; hence, one timer/counter can exist only as
either type 0 or type 2.
A detailed block diagram of the timer/counter 2 showing the low-byte (L) and high-byte (H) timer/counter register split and
compare modules is shown in Figure 14-1 on page 174.
XMEGA B [MANUAL] 174
Atmel-8291C-AVR-XMEGA B -09/2014
14.3 Block Diagram
Figure 14-1. Block diagram of the 16-bit timer/counter 0 with split mode.
14.4 Clock Sources
The timer/counter can be clocked from the peripheral clock (clkPER) and from the event system. Figure 14-2 shows the
clock and event selection.
Figure 14-2. Clock selection.
Base Counter
Compare
(Unit x = {A,B,C,D})
Counter
HPER
= 0
Control Logic
CTRLA
HUNF
(INT/DMA Req.)
BOTTOML
LPER
Compare
(Unit x = {A,B,C,D})
Waveform
Generation
LCMPx
(INT/DMA
Req.)
OCLx Out
=
LCMPx
"match"
BOTTOMH
LCNT "count low"
"load low"
=
HCMPx
Waveform
Generation
"match"
OCHx Out
= 0
"count high"
"load high"
HCNT
Clock Select
LUNF
(INT/DMA Req.)
clkPER /
2{0,...,15}
CLKSEL
CNT
clkPER /
{1,2,4,8,64,256,1024}
Common
Prescaler clkPER
event channels
Event
System events
XMEGA B [MANUAL] 175
Atmel-8291C-AVR-XMEGA B -09/2014
The peripheral clock (clkPER) is fed into the common prescaler (common for all timer/counters in a device). A selection of
prescaler outputs from 1 to 1/1024 is directly available. In addition, the whole range of time prescalings from 1 to 215 is
available through the event system.
The clock selection (CLKSEL) selects one of the clock prescaler outputs or an event channel for the high-byte counter
(HCNT) and low-byte counter (LCNT). By using the event system, any event source, such as an external clock signal, on
any I/O pin can be used as the clock input.
By default, no clock input is selected, and the counters are not running.
14.5 Counter Operation
The counters will always count in single-slope mode. Each counter counts down for each clock cycle until it reaches
BOTTOM, and then reloads the counter with the period register value at the following clock cycle.
Figure 14-3. Counter operation.
As shown in Figure 14-3, the counter can change the counter value while running. The write access has higher priority
than the count clear, and reloads and will be immediate.
14.5.1 Changing the Period
The counter period is changed by writing a new TOP value to the period register. Since the counter is counting down, the
period register can be written at any time without affecting the current period, as shown in Figure 14-4 on page 175. This
prevents wraparound and generation of odd waveforms.
Figure 14-4. Changing the period.
14.6 Compare Channel
Each compare channel continuously compares the counter value with the CMPx register. If CNT equals CMPx, the
comparator signals a match. For the low-byte timer/counter, the match will set the compare channel's interrupt flag at the
next timer clock cycle, and the event and optional interrupt is generated. The high-byte timer/counter does not have
compare interrupt/event.
CNT
BOTTOM
MAX
"reload" TOP
CNT written
CNT
MAX
New TOP written to
PER that is higher
than current CNT
New TOP written to
PER that is lower
than current CNT
"reload"
"write"
BOTTOM
XMEGA B [MANUAL] 176
Atmel-8291C-AVR-XMEGA B -09/2014
14.6.1 Waveform Generation
The compare channels can be used for waveform generation on the corresponding port pins. To make the waveform
visible on the connected port pin, the following requirements must be fulfilled:
1. The compare channels to be used must be enabled. This will override the corresponding port pin output register.
2. The direction for the associated port pin must be set to output.
Inverted waveform output can be achieved by setting invert I/O on the port pin. Refer to “I/O Ports” on page 123 for more
details.
14.6.2 Single-slope PWM Generation
For PWM generation, the period (T) is controlled by the PER register, while the CMPx registers control the duty cycle of
the waveform generator (WG) output. Figure 14-5 on page 176 shows how the counter counts from TOP to BOTTOM,
and then restarts from TOP. The WG output is set on the compare match between the CNT and CMPx registers, and
cleared at BOTTOM.
Figure 14-5. Single-slope pulse width modulation.
The PER register defines the PWM resolution. The minimum resolution is two bits (PER=0x0003), and the maximum
resolution is eight bits (PER=MAX).
The following equation is used to calculate the exact resolution for a single-slope PWM (RPWM_SS) waveform:
The single, slow PWM frequency (fPWM_SS) depends on the period setting (PER) and the peripheral clock frequency
(fPER), and it is calculated by using the following equation:
where N represents the prescaler divider used (1, 2, 4, 8, 64, 256, 1024, or event channel n).
14.6.3 Port Override for Waveform Generation
To make the waveform generation available on the port pins, the corresponding port pin direction must be set as output.
The timer/counter will override the port pin values when the CMP channel is enabled (LCMPENx/HCMPENx).
Figure 14-6 on page 177 shows the port override for the low- and high-byte timer/counters. For the low-byte
timer/counter, CMP channels A to D will override the output value (OUTxn) of port pins 0 to 3 on the corresponding port
pins (Pxn). For the high-byte timer/counter, CMP channels E to H will override port pins 4 to 7. Enabling inverted I/O on
the port pin (INVENxn) inverts the corresponding WG output.
CNT
MAX
TOP
Period (T) "match"
BOTTOM
WG Output
CMPx=BOT
CMPx
CMPx=TOP
RPWM_SS
log( ) PER 1 +
log( ) 2 = ---------------------------------
f PWM_SS
f PER
N( ) PER 1 + = -----------------------------
XMEGA B [MANUAL] 177
Atmel-8291C-AVR-XMEGA B -09/2014
Figure 14-6. Port override for low- and high-byte timer/counters.
14.7 Interrupts and Events
The timer/counters can generate interrupts and events. The counter can generate an interrupt on underflow, and each
CMP channel for the low-byte counter has a separate compare interrupt.
Events will be generated for all conditions that can generate interrupts. For details on event generation and available
events, refer to “Event System” on page 63.
14.8 DMA Support
Timer/counter underflow and compare interrupt flags can trigger a DMA transaction. The acknowledge condition that
clears the flag/request is listed in Table 14-1.
Table 14-1. DMA request sources.
14.9 Timer/Counter Commands
A set of commands can be given to the timer/counter by software to immediately change the state of the module. These
commands give direct control of the update, restart, and reset signals.
The software can force a restart of the current waveform period by issuing a restart command. In this case the counter,
direction, and all compare outputs are set to zero.
A reset command will set all timer/counter registers to their initial values. A reset can only be given when the
timer/counter is not running (OFF).
OUT
LCMPENx /
HCMPENx
INVEN
OCx Waveform
Request Acknowledge Comment
LUNFIF DMAC writes to LCNT
DMAC writes to LPER
HUNFIF DMAC writes to HCNT
DMAC writes to HPER
CCIF{D,C,B,A} DMAC access of
LCMP{D,C,B,A}
Output compare operation
XMEGA B [MANUAL] 178
Atmel-8291C-AVR-XMEGA B -09/2014
14.10 Register Description
14.10.1 CTRLA – Control register A
z Bit 7:4 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 3:0 – CLKSEL[3:0]: Clock Select
These bits select clock source for the timer/counter according to Table 14-2. The clock select is identical for both highand
low-byte timer/counters.
Table 14-2. Clock select
14.10.2 CTRLB – Control register B
z Bit 7:0 – HCMPENx/LCMPENx: High/Low Byte Compare Enable x
Setting these bits will enable the compare output and override the port output register for the corresponding OCn output
pin.
Bit 7 6 5 4 3 2 1 0
+0x00 – – – – CLKSEL[3:0]
Read/Write R R R R R/W R/W R/W R/W
Initial Value 00000000
CLKSEL[3:0] Group Configuration Description
0000 OFF None (i.e., timer/counter in OFF state)
0001 DIV1 Prescaler: ClkPER
0010 DIV2 Prescaler: ClkPER/2
0011 DIV4 Prescaler: ClkPER/4
0100 DIV8 Prescaler: ClkPER/8
0101 DIV64 Prescaler: ClkPER/64
0110 DIV256 Prescaler: ClkPER/256
0111 DIV1024 Prescaler: ClkPER/1024
1nnn EVCHn Event channel n, n= [0,...,7]
Bit 7 6 5 4 3 2 1 0
+0x01 HCMPEND HCMPENC HCMPENB HCMPENA LCMPEND LCMPENC LCMPENB LCMPENA
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 000000
XMEGA B [MANUAL] 179
Atmel-8291C-AVR-XMEGA B -09/2014
14.10.3 CTRLC – Control register C
z Bit 7:0 – HCMPx/LCMPx: High/Low Compare x Output Value
These bits allow direct access to the waveform generator's output compare value when the timer/counter is OFF. This is
used to set or clear the WG output value when the timer/counter is not running.
14.10.4 CTRLE – Control register E
z Bit 7:2 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 0:1 – BYTEM[1:0]: Byte Mode
These bits select the timer/counter operation mode according to Table 14-3.
Table 14-3. Byte mode.
Bit 7 6 5 4 3 2 1 0
+0x02 HCMPD HCMPC HCMPB HCMPA LCMPD LCMPC LCMPB LCMPA
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0000
Bit 7 6 5 4 3 2 1 0
+0x04 – – – – – – BYTEM[1:0]
Read/Write R R R R R R R/W R/W
Initial Value 00000000
BYTEM[1:0] Group Configuration Description
00 NORMAL Timer/counter is set to normal mode (timer/counter type 0)
01 BYTEMODE Upper byte of the counter (HCNT) will be set to zero after each counter
clock.
10 SPLITMODE Timer/counter is split into two eight-bit timer/counters (timer/counter type
2)
11 — Reserved
XMEGA B [MANUAL] 180
Atmel-8291C-AVR-XMEGA B -09/2014
14.10.5 INTCTRLA – Interrupt Enable register A
z Bit 7:4 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 3:2 – HUNFINTLVL[1:0]: High-byte Timer Underflow Interrupt Level
These bits enable the high-byte timer underflow interrupt and select the interrupt level, as described in “Interrupts and
Programmable Multilevel Interrupt Controller” on page 115. The enabled interrupt will be triggered when HUNFIF in the
INTFLAGS register is set.
z Bit 1:0 – LUNFINTLVL[1:0]: Low-byte Timer Underflow Interrupt Level
These bits enable the low-byte timer underflow interrupt and select the interrupt level, as described in “Interrupts and
Programmable Multilevel Interrupt Controller” on page 115. The enabled interrupt will be triggered when LUNFIF in the
INTFLAGS register is set.
14.10.6 INTCTRLB – Interrupt Enable register B
z Bit 7:0 – LCMPxINTLVL[1:0]: Low-byte Compare x Interrupt Level
These bits enable the low-byte timer compare interrupt and select the interrupt level, as described in “Interrupts and
Programmable Multilevel Interrupt Controller” on page 115. The enabled interrupt will be triggered when LCMPxIF in the
INTFLAGS register is set.
14.10.7 CTRLF – Control register F
z Bit 7:4 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 3:2 – CMD[1:0]: Timer/Counter Command
These command bits are used for software control of timer/counter update, restart, and reset. The command bits are
always read as zero. The CMD bits must be used together with CMDEN.
Bit 7 6 5 4 3 2 1 0
+0x06 – – – – HUNFINTLVL[1:0] LUNFINTLVL[1:0]
Read/Write R R R R R/W R/W R/W R/W
Initial Value 0 0 0 0 0000
Bit 7 6 5 4 3 2 1 0
+0x07 LCMPDINTLVL[1:0] LCMPCINTLVL[1:0] LCMPBINTLVL[1:0] LCMPAINTLVL[1:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0000000
Bit 7 6 5 4 3 2 1 0
+0x08 – – – – CMD[1:0] CMDEN[1:0]
Read/Write R R R R R/W R/W R/W R/W
Initial Value 0 0 0 00000
XMEGA B [MANUAL] 181
Atmel-8291C-AVR-XMEGA B -09/2014
Table 14-4. Command selections.
z Bit 1:0 – CMDEN[1:0]: Command Enable
These bits are used to indicate for which timer/counter the command (CMD) is valid.
Table 14-5. Command enable selections.
14.10.8 INTFLAGS – Interrupt Flag register
z Bit 7:4 – LCMPxIF: Compare Channel x Interrupt Flag
The compare interrupt flag (LCMPxIF) is set on a compare match on the corresponding CMP channel.
For all modes of operation, LCMPxIF will be set when a compare match occurs between the count register (LCNT) and
the corresponding compare register (LCMPx). The LCMPxIF is automatically cleared when the corresponding interrupt
vector is executed. The flag can also be cleared by writing a one to its bit location.
z Bit 3:2 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 1 – HUNFIF: High-byte Timer Underflow Interrupt Flag
HUNFIF is set on a BOTTOM (underflow) condition. This flag is automatically cleared when the corresponding interrupt
vector is executed. The flag can also be cleared by writing a one to its bit location.
z Bit 0 – LUNFIF: Low-byte Timer Underflow Interrupt Flag
LUNFIF is set on a BOTTOM (underflow) condition. This flag is automatically cleared when the corresponding interrupt
vector is executed. The flag can also be cleared by writing a one to its bit location.
CMD Group Configuration Description
00 NONE None
01 — Reserved
10 RESTART Force restart
11 RESET Force hard reset (ignored if T/C is not in OFF state)
CMDEN Group Configuration Description
00 – Reserved
01 LOW Command valid for low-byte T/C
10 HIGH Command valid for high-byte T/C
11 BOTH Command valid for both low-byte and high-byte T/C
Bit 7 6 5 4 3 2 1 0
+0x0C LCMPDIF LCMPCIF LCMPBIF LCMPAIF – – HUNFIF LUNFIF
Read/Write R/W R/W R/W R/W R R R/W R/W
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 182
Atmel-8291C-AVR-XMEGA B -09/2014
14.10.9 LCNT – Low-byte Count register
z Bit 7:0 – LCNT[7:0]
LCNT contains the eight-bit counter value for the low-byte timer/counter. The CPU and DMA write accesses have priority
over count, clear, or reload of the counter.
14.10.10HCNT – High-byte Count register
z Bit 7:0 – HCNT[7:0]
HCNT contains the eight-bit counter value for the high-byte timer/counter. The CPU and DMA write accesses have
priority over count, clear, or reload of the counter.
14.10.11LPER – Low-byte Period register
z Bit 7:0 – LPER[7:0]
LPER contains the eight-bit period value for the low-byte timer/counter.
14.10.12HPER – High-byte Period register
z Bit 7:0 – HPER[7:0]
HPER contains the eight-bit period for the high-byte timer/counter.
Bit 7 6 5 4 3 2 1 0
+0x20 LCNT[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 00000000
Bit 7 6 5 4 3 2 1 0
+0x21 HCNT[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
Bit 7 6 5 4 3 2 1 0
+0x27 LPER[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
Bit 7 6 5 4 3 2 1 0
+0x26 HPER[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 000000
XMEGA B [MANUAL] 183
Atmel-8291C-AVR-XMEGA B -09/2014
14.10.13LCMPx – Low-byte Compare register x
z Bit 7:0 – LCMPx[7:0], x=[A, B, C, D]
LCMPx contains the eight-bit compare value for the low-byte timer/counter.
These registers are all continuously compared to the counter value. Normally, the outputs from the comparators are then
used for generating waveforms.
14.10.14HCMPx – High-byte Compare register x
z Bit 7:0 – HCMPx[7:0], x=[A, B, C, D]
HCMPx contains the eight-bit compare value for the high-byte timer/counter.
These registers are all continuously compared to the counter value. Normally the outputs from the comparators are then
used for generating waveforms.
Bit 7 6 5 4 3 2 1 0
LCMPx[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
Bit 7 6 5 4 3 2 1 0
HCMPx[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 184
Atmel-8291C-AVR-XMEGA B -09/2014
14.11 Register Summary
14.12 Interrupt Vector Summary
Address Name Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 Page
+0x00 CTRLA – – – – CLKSEL[3:0] 178
+0x01 CTRLB HCMPDEN HCMPCEN HCMPBEN HCMPAEN LCMPDEN LCMPCEN LCMPBEN LCMPAEN 178
+0x02 CTRLC HCMPD HCMPC HCMPB HCMPA LCMPD LCMPC LCMPB LCMPA 179
+0x03 Reserved – – – – – – – –
+0x04 CTRLE – – – – – – BYTEM[1:0] 179
+0x05 Reserved – – – – – – – –
+0x06 INTCTRLA – – – – HUNFINTLVL[1:0] LUNFINTLVL[1:0] 180
+0x07 INTCTRLB LCMPDINTLVL[1:0] LCMPCINTLVL[1:0] LCMPBINTLVL[1:0] LCMPAINTLVL[1:0] 180
+0x08 Reserved – – – – – – – –
+0x09 CTRLF – – – – CMD[1:0] CMDEN[1:0] 180
+0x0A Reserved – – – – – – – –
+0x0B Reserved – – – – – – – –
+0x0C INTFLAGS LCMPDIF LCMPCIF LCMPBIF LCMPAIF – – HUNFIF LUNFIF 181
+0x0D Reserved – – – – – – – –
+0x0E Reserved – – – – – – – –
+0x0F Reserved – – – – – – – –
+0x10 to Reserved – – – – – – – –
+0x20 LCNT Low-byte Timer/Counter Count Register 182
+0x21 HCNT High-byte Timer/Counter Count Register 182
+0x22 to Reserved – – – – – – – –
+0x26 LPER Low-byte Timer/Counter Period Register 182
+0x27 HPER High-byte Timer/Counter Period Register 183
+0x28 LCMPA Low-byte Compare Register A 183
+0x29 HCMPA High-byte Compare Register A 183
+0x2A LCMPB Low-byte Compare Register B 183
+0x2B HCMPB High-byte Compare Register B 183
+0x2C LCMPC Low-byte Compare Register C 183
+0x02D HCMPC High-byte Compare Register C 183
+0x2E LCMPD Low-byte Compare Register D 183
+0x2F HCMPD High-byte Compare Register D 183
+0x30 to Reserved – – – – – – – –
Offset Source Interrupt Description
0x00 LUNF_vect Low-byte Timer/counter underflow interrupt vector offset
0x02 HUNF_vect High-byte Timer/counter underflow interrupt vector offset
0x4 LCMPA_vect Low-byte Timer/counter compare channel A interrupt vector offset
0x6 LCMPB_vect Low-byte Timer/counter compare channel B interrupt vector offset
0x8 LCMPC_vect Low-byte Timer/counter compare channel C interrupt vector offset
0x0A LCMPD_vect Low-byte Timer/counter compare channel D interrupt vector offset
XMEGA B [MANUAL] 185
Atmel-8291C-AVR-XMEGA B -09/2014
15. AWeX – Advanced Waveform Extension
15.1 Features
z Waveform output with complementary output from each compare channel
z Four dead-time insertion (DTI) units
z 8-bit resolution
z Separate high and low side dead-time setting
z Double buffered dead time
z Optionally halts timer during dead-time insertion
z Pattern generation unit creating synchronised bit pattern across the port pins
z Double buffered pattern generation
z Optional distribution of one compare channel output across the port pins
z Event controlled fault protection for instant and predictable fault triggering
15.2 Overview
The advanced waveform extension (AWeX) provides extra functions to the timer/counter in waveform generation (WG)
modes. It is primarily intended for use with different types of motor control and other power control applications. It
enables low- and high side output with dead-time insertion and fault protection for disabling and shutting down external
drivers. It can also generate a synchronized bit pattern across the port pins.
Figure 15-1. Advanced waveform extention and closely related peripherals (grey).
As shown in Figure 15-1 on page 185, each of the waveform generator outputs from timer/counter 0 are split into a
complimentary pair of outputs when any AWeX features are enabled. These output pairs go through a dead-time
insertion (DTI) unit that generates the non-inverted low side (LS) and inverted high side (HS) of the WG output with deadtime
insertion between LS and HS switching. The DTI output will override the normal port value according to the port
Timer/Counter 0
AWeX
WG
Channel A
DTI
Channel A
WG
Channel B
DTI
Channel B
WG
Channel C
DTI
Channel C
WG
Channel D
DTI
Channel D
Port
Override
Pattern
Generation
Px0
Px1
Px2
Px3
Px4
Px5
Px6
Px7
Event
System
Fault
Protection
XMEGA B [MANUAL] 186
Atmel-8291C-AVR-XMEGA B -09/2014
override setting. Refer to “I/O Ports” on page 123 for more details.
The pattern generation unit can be used to generate a synchronized bit pattern on the port it is connected to. In addition,
the WG output from compare channel A can be distributed to and override all the port pins. When the pattern generator
unit is enabled, the DTI unit is bypassed.
The fault protection unit is connected to the event system, enabling any event to trigger a fault condition that will disable
the AWeX output. The event system ensures predictable and instant fault reaction, and gives flexibility in the selection of
fault triggers.
15.3 Port Override
The port override logic is common for all the timer/counter extensions. Figure 15-2 on page 187 shows a schematic
diagram of the port override logic. When the dead-time enable (DTIENx) bit is set, the timer/counter extension takes
control over the pin pair for the corresponding channel. Given this condition, the output override enable (OOE) bits take
control over the CCxEN bits.
XMEGA B [MANUAL] 187
Atmel-8291C-AVR-XMEGA B -09/2014
Figure 15-2. Timer/counter extensions and port override logic.
15.4 Dead-time Insertion
The dead-time insertion (DTI) unit generates OFF time where the non-inverted low side (LS) and inverted high side (HS)
of the WG output are both low. This OFF time is called dead time, and dead-time insertion ensures that the LS and HS
never switch simultaneously.
The DTI unit consists of four equal dead-time generators, one for each compare channel in timer/counter 0. Figure 15-3
on page 188 shows the block diagram of one DTI generator. The four channels have a common register that controls the
OUT0
OUTOVEN0
CCAEN
DTICCAEN
INVEN0
OUT1
OUTOVEN1
CCBEN INVEN1
Px0
Px1
Channel
A
DTI
LS
HS
OC0A
OC0B
OCALS
OCAHS
WG 0A
WG 0B
WG 0A
CWCM
OUT2
OUTOVEN2
CCCEN
DTICCBEN
INVEN2
OUT3
OUTOVEN3
CCDEN INVEN3
Px2
Px3
Channel
B
DTI
LS
HS
OC0C
OC0D
OCBLS
OCBHS
WG 0C
WG 0D
OUT4
OUTOVEN4
CCAEN
DTICCCEN
INVEN4
OUT5
OUTOVEN5
CCBEN INVEN5
Px4
Px5
Channel
C
DTI
LS
HS
OC1A
OC1B
OCCLS
OCCHS
WG 1A
WG 1B
OUT6
OUTOVEN6
DTICCDEN
INVEN6
OUT7
OUTOVEN7
INVEN7
Px6
Px7
Channel
D
DTI
LS
HS
OCDLS
OCDHS
WG 0B
WG 0D
WG 0C
"0"
"0"
XMEGA B [MANUAL] 188
Atmel-8291C-AVR-XMEGA B -09/2014
dead time. The high side and low side have independent dead-time setting, and the dead-time registers are double
buffered.
Figure 15-3. Dead-time generator block diagram.
As shown in Figure 15-4 on page 188, the 8-bit dead-time counter is decremented by one for each peripheral clock cycle,
until it reaches zero. A nonzero counter value will force both the low side and high side outputs into their OFF state.
When a change is detected on the WG output, the dead-time counter is reloaded according to the edge of the input. A
positive edge initiates a counter reload of the DTLS register, and a negative edge a reload of DTHS register.
Figure 15-4. Dead-time generator timing diagram.
15.5 Pattern Generation
The pattern generator unit reuses the DTI registers to produce a synchronized bit pattern across the port it is connected
to. In addition, the waveform generator output from compare channel A (CCA) can be distributed to and override all the
port pins. These features are primarily intended for handling the commutation sequence in brushless DC motor (BLDC)
and stepper motor applications. A block diagram of the pattern generator is shown in “Pattern generator block diagram.”
on page 189. For each port pin where the corresponding OOE bit is set, the multiplexer will output the waveform from
CCA.
Dead Time Generator
Edge Detect
BV BV
D Q
= 0
DTLSBUF
DTLS
DTHSBUF
DTHS
"DTLS"
(To PORT)
"DTHS"
(To PORT)
Counter EN
LOAD
WG output
"dti_cnt"
"WG output"
"DTLS"
"DTHS"
tDTILS tDTIHS
T
tP
XMEGA B [MANUAL] 189
Atmel-8291C-AVR-XMEGA B -09/2014
Figure 15-5. Pattern generator block diagram.
As with the other timer/counter double buffered registers, the register update is synchronized to the UPDATE condition
set by the waveform generation mode. If the synchronization provided is not required by the application, the application
code can simply access the DTIOE and PORTx registers directly.
The pin directions must be set for any output from the pattern generator to be visible on the port.
15.6 Fault Protection
The fault protection feature enables fast and deterministic action when a fault is detected. The fault protection is event
controlled. Thus, any event from the event system can be used to trigger a fault action, such as over-current indication
from analog comparator or ADC measurements.
When fault protection is enabled, an incoming event from any of the selected event channels can trigger the event action.
Each event channel can be separately enabled as a fault protection input, and the specified event channels will be ORed
together, allowing multiple event sources to be used for fault protection at the same time.
15.6.1 Fault Actions
When a fault is detected, the direction clear action will clear the direction (DIR) register in the associated port, setting all
port pins as tri-stated inputs.
The fault detection flag is set, the timer/counter’s error interrupt flag is set, and the optional interrupt is generated.
There is maximum of two peripheral clock cycles from when an event occurs in a peripheral until the fault protection
triggers the event action. Fault protection is fully independent of the CPU and DMA, but requires the peripheral clock to
run.
15.6.2 Fault Restore Modes
How the AWeX and timer/counter return from the fault state to normal operation after a fault, when the fault condition is
no longer active, can be selected from one of two different modes:
z In latched mode, the waveform output will remain in the fault state until the fault condition is no longer active and
the fault detect flag has been cleared by software. When both of these conditions are met, the waveform output will
return to normal operation at the next UPDATE condition.
z In cycle-by-cycle mode the waveform output will remain in the fault state until the fault condition is no longer active.
When this condition is met, the waveform output will return to normal operation at the next UPDATE condition.
Timer/Counter 0 (TCx0)
BV DTLSBUF BV
OUTOVEN
DTHSBUF
OUTx
UPDATE CCA WG output
EN EN
1 to 8
Expand
Px[7:0]
XMEGA B [MANUAL] 190
Atmel-8291C-AVR-XMEGA B -09/2014
When returning from a fault state the DIR[7:0] bits corresponding to the enabled DTI channels are restored. OUTOVEN is
unaffected by the fault except that writing to the register from software is blocked.
The UPDATE condition used to restore normal operation is the same as the one in the timer/counter.
15.6.3 Change Protection
To avoid unintentional changes in the fault protection setup, all the control registers in the AWeX extension can be
protected by writing the corresponding lock bit in the advanced waveform extension lock register. For more details, refer
to “I/O Memory Protection” on page 25 and “AWEXLOCK – Advanced Waveform Extension Lock register” on page 44.
When the lock bit is set, control register A, the output override enable register, and the fault detection event mask register
cannot be changed.
To avoid unintentional changes in the fault event setup, it is possible to lock the event system channel configuration by
writing the corresponding event system lock register. For more details, refer to “I/O Memory Protection” on page 25 and
“EVSYSLOCK – Event System Lock register” on page 43.
15.6.4 On-Chip Debug
When fault detection is enabled, an on-chip debug (OCD) system receives a break request from the debugger, which will
by default function as a fault source. When an OCD break request is received, the AWeX and corresponding
timer/counter will enter a fault state, and the specified fault action will be performed.
After the OCD exits from the break condition, normal operation will be started again. In cycle-by-cycle mode, the
waveform output will start on the first UPDATE condition after exit from break, while in latched mode, the fault condition
flag must be cleared in software before the output will be restored. This feature guarantees that the output waveform
enters a safe state during a break.
It is possible to disable this feature.
XMEGA B [MANUAL] 191
Atmel-8291C-AVR-XMEGA B -09/2014
15.7 Register Description
15.7.1 CTRL – Control register
z Bit 7:6 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 5 – PGM: Pattern Generation Mode
Setting this bit enables the pattern generation mode. This will override the DTI, and the pattern generation reuses the
dead-time registers for storing the pattern.
z Bit 4 – CWCM: Common Waveform Channel Mode
If this bit is set, the CC channel A waveform output will be used as input for all the dead-time generators. CC channel B,
C, and D waveforms will be ignored.
z Bit 3:0 – DTICCxEN: Dead-Time Insertion CCx Enable
Setting these bits enables the dead-time generator for the corresponding CC channel. This will override the timer/counter
waveform outputs.
15.7.2 FDEMASK – Fault Detect Event Mask register
z Bit 7:0 – FDEVMASK[7:0]: Fault Detect Event Mask
These bits enable the corresponding event channel as a fault condition input source. Events from all event channels will
be ORed together, allowing multiple sources to be used for fault detection at the same time. When a fault is detected, the
fault detect flag (FDF) is set and the fault detect action (FDACT) will be performed.
Bit 7 6 5 4 3 2 1 0
+0x00 – – PGM CWCM DTICCDEN DTICCCEN DTICCBEN DTICCAEN
Read/Write R R R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
Bit 7 6 5 4 3 2 1 0
+0x02 FDEVMASK[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 000000
XMEGA B [MANUAL] 192
Atmel-8291C-AVR-XMEGA B -09/2014
15.7.3 FDCTRL - Fault Detection Control register
z Bit 7:5 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 4 – FDDBD: Fault Detection on Debug Break Detection
By default, when this bit is cleared and fault protection is enabled, and OCD break request is treated as a fault. When this
bit is set, an OCD break request will not trigger a fault condition.
z Bit 3 – Reserved
This bit is unused and reserved for future use. For compatibility with future devices, always write this bit to zero when this
register is written.
z Bit 2 – FDMODE: Fault Detection Restart Mode
This bit sets the fault protection restart mode. When this bit is cleared, latched mode is used, and when it is set, cycle-bycycle
mode is used.
In latched mode, the waveform output will remain in the fault state until the fault condition is no longer active and the FDF
has been cleared by software. When both conditions are met, the waveform output will return to normal operation at the
next UPDATE condition.
In cycle-by-cycle mode, the waveform output will remain in the fault state until the fault condition is no longer active.
When this condition is met, the waveform output will return to normal operation at the next UPDATE condition.
z Bit 1:0 – FDACT[1:0]: Fault Detection Action
These bits define the action performed, according to Table 15-1, when a fault condition is detected.
Table 15-1. Fault action.
Bit 7 6 5 4 3 2 1 0
+0x03 – – – FDDBD – FDMODE FDACT[1:0]
Read/Write R R R R/W R R/W R/W R/W
Initial Value 00000000
FDACT[1:0] Group Configuration Description
00 NONE None (fault protection disabled)
01 – Reserved
10 – Reserved
11 CLEARDIR Clear all direction (DIR) bits which correspond to the enabled DTI
channel(s); i.e., tri-state the outputs
XMEGA B [MANUAL] 193
Atmel-8291C-AVR-XMEGA B -09/2014
15.7.4 STATUS – Status register
z Bit 7:3 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 2 – FDF: Fault Detect Flag
This flag is set when a fault detect condition is detected; i.e., when an event is detected on one of the event channels
enabled by FDEVMASK. This flag is cleared by writing a one to its bit location.
z Bit 1 – DTHSBUFV: Dead-time High Side Buffer Valid
If this bit is set, the corresponding DT buffer is written and contains valid data that will be copied into the DTLS register on
the next UPDATE condition. If this bit is zero, no action will be taken. The connected timer/counter unit’s lock update
(LUPD) flag also affects the update for dead-time buffers.
z Bit 0 – DTLSBUFV: Dead-time Low Side Buffer Valid
If this bit is set, the corresponding DT buffer is written and contains valid data that will be copied into the DTHS register
on the next UPDATE condition. If this bit is zero, no action will be taken. The connected timer/counter unit's lock update
(LUPD) flag also affects the update for dead-time buffers.
15.7.5 DTBOTH – Dead-time Concurrent Write to Both Sides
z Bit 7:0 – DTBOTH: Dead-time Both Sides
Writing to this register will update the DTHS and DTLS registers at the same time (i.e., at the same I/O write access).
15.7.6 DTBOTHBUF – Dead-time Concurrent Write to Both Sides Buffer register
z Bit 7:0 – DTBOTHBUF: Dead-time Both Sides Buffer
Writing to this memory location will update the DTHSBUF and DTLSBUF registers at the same time (i.e., at the same I/O
write access).
Bit 7 6 5 4 3 2 1 0
+0x04 – – – – – FDF DTHSBUFV DTLSBUFV
Read/Write R R R R R R/W R/W R/W
Initial Value 00000 0 0 0
Bit 7 6 5 4 3 2 1 0
+0x06 DTBOTH[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 00000000
Bit 7 6 5 4 3 2 1 0
+0x07 DTBOTHBUF[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 00000000
XMEGA B [MANUAL] 194
Atmel-8291C-AVR-XMEGA B -09/2014
15.7.7 DTLS – Dead-time Low Side register
z Bit 7:0 – DTLS: Dead-time Low Side
This register holds the number of peripheral clock cycles for the dead-time low side.
15.7.8 DTHS – Dead-time High Side register
z Bit 7:0 – DTHS: Dead-time High Side
This register holds the number of peripheral clock cycles for the dead-time high side.
15.7.9 DTLSBUF – Dead-time Low Side Buffer register
z Bit 7:0 – DTLSBUF: Dead-time Low Side Buffer
This register is the buffer for the DTLS register. If double buffering is used, valid content in this register is copied to the
DTLS register on an UPDATE condition.
15.7.10 DTHSBUF – Dead-time High Side Buffer register
z Bit 7:0 – DTHSBUF: Dead-time High Side Buffer
This register is the buffer for the DTHS register. If double buffering is used, valid content in this register is copied to the
DTHS register on an UPDATE condition.
Bit 7 6 5 4 3 2 1 0
+0x08 DTLS[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
Bit 7 6 5 4 3 2 1 0
+0x09 DTHS[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
Bit 7 6 5 4 3 2 1 0
+0x0A DTLSBUF[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 00000000
Bit 7 6 5 4 3 2 1 0
+0x0B DTHSBUF[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 00000000
XMEGA B [MANUAL] 195
Atmel-8291C-AVR-XMEGA B -09/2014
15.7.11 OUTOVEN – Output Override Enable register
Note: 1. Can be written only if the fault detect flag (FDF) is zero.
z Bit 7:0 – OUTOVEN[7:0]: Output Override Enable
These bits enable override of the corresponding port output register (i.e., one-to-one bit relation to pin position). The port
direction is not overridden.
15.8 Register Summary
Bit 7 6 5 4 3 2 1 0
+0x0C OUTOVEN[7:0]
Read/Write R/W(1) R/W(1) R/W(1) R/W(1) R/W(1) R/W(1) R/W(1) R/W(1)
Initial Value 0 0 0 0 0 0 0 0
Address Name Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 Pag
+0x00 CTRL – – PGM CWCM DTICDAE DTICCCE DTICCBEN DTICCAEN 191
+0x01 Reserved – – – – – – – –
+0x02 FDEMASK FDEVMASK[7:0] 191
+0x03 FDCTRL – – – FDDBD – FDMODE FDACT[1:0] 192
+0x04 STATUS – – – – – FDF DTBHSV DTBLSV 193
+0x05 Reserved – – – – – – – –
+0x06 DTBOTH DTBOTH[7:0] 193
+0x07 DTBOTHBUF DTBOTHBUF[7:0] 193
+0x08 DTLS DTLS[7:0] 194
+0x09 DTHS DTHS[7:0] 194
+0x0A DTLSBUF DTLSBUF[7:0] 194
+0x0B DTHSBUF DTHSBUF[7:0] 194
+0x0C OUTOVEN OUTOVEN[7:0] 195
XMEGA B [MANUAL] 196
Atmel-8291C-AVR-XMEGA B -09/2014
16. Hi-Res – High-Resolution Extension
16.1 Features
z Increases waveform generator resolution up to 8x (3 bits)
z Supports frequency, single-slope PWM, and dual-slope PWM generation
z Supports the AWeX when this is used for the same timer/counter
16.2 Overview
The high-resolution (hi-res) extension can be used to increase the resolution of the waveform generation output from a
timer/counter by four or eight. It can be used for a timer/counter doing frequency, single-slope PWM, or dual-slope PWM
generation. It can also be used with the AWeX if this is used for the same timer/counter.
The hi-res extension uses the peripheral 4x clock (ClkPER4). The system clock prescalers must be configured so the
peripheral 4x clock frequency is four times higher than the peripheral and CPU clock frequency when the hi-res extension
is enabled. Refer to “System Clock Selection and Prescalers” on page 79 for more details.
Figure 16-1. Timer/counter operation with hi-res extension enabled.
When the hi-res extension is enabled, the timer/counter must run from a non-prescaled peripheral clock. The
timer/counter will ignore its two least-significant bits (lsb) in the counter, and counts by four for each peripheral clock
cycle. Overflow/underflow and compare match of the 14 most-significant bits (msb) is done in the timer/counter. Count
and compare of the two lsb is handled and compared in the hi-res extension running from the peripheral 4x clock.
The two lsb of the timer/counter period register must be set to zero to ensure correct operation. If the count register is
read from the application code, the two lsb will always be read as zero, since the timer/counter run from the peripheral
clock. The two lsb are also ignored when generating events.
When the hi-res plus feature is enabled, the function is the same as with the hi-res extension, but the resolution will
increase by eight instead of four. This also means that the 3 lsb are handled by the hi-res extension instead of 2 lsb, as
when only hi-res is enabled. The extra resolution is achieved by counting on both edges of the peripheral 4x clock.
The hi-res extension will not output any pulse shorter than one peripheral clock cycle; i.e., a compare value lower than
four will have no visible output.
CNT[15:2]
HiRes
CCxBUF[15:0]
= 0 =
" match" =
PER[15:2] 0
Waveform
Generation
BOTTOM TOP
Time /Counter
CCx[15:2] [1:0]
2 2 2
0
AWeX
Fault
Protection
Dead - Time
Insertion
Pattern
Generation
clkPER clkPER4
Pxn
XMEGA B [MANUAL] 197
Atmel-8291C-AVR-XMEGA B -09/2014
16.3 Register Description
16.3.1 CTRLA – Control register A
z Bit 7:3 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 2 – HRPLUS: High Resolution Plus
Setting this bit enables high resolution plus. Hi-res plus is the same as hi-res, but will increase the resolution by eight (3
bits) instead of four.
The extra resolution is achieved by operating at both edges of the peripheral 4x clock.
z Bit 1:0 – HREN[1:0]: High Resolution Enable
These bits enables the high-resolution mode for a timer/counter according to Table 16-1.
Setting one or both HREN bits will enable high-resolution waveform generation output for the entire general purpose I/O
port. This means that both timer/counters connected to the same port must enable hi-res if both are used for generating
PWM or FRQ output on pins.
Table 16-1. High resolution enable.
16.4 Register Summary
Bit 7 6 5 4 3 2 1 0
+0x00 – – – – – HRPLUS HREN[1:0]
Read/Write R R R R R R/W R/W R/W
Initial Value 00000000
HREN[1:0] High Resolution Enabled
00 None
01 Timer/counter 0
10 Timer/counter 1
11 Both timer/counters
Address Name Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 Page
+0x00 CTRLA – – – – – HRPLUS HREN[1:0] 197
XMEGA B [MANUAL] 198
Atmel-8291C-AVR-XMEGA B -09/2014
17. RTC – Real-Time Counter
17.1 Features
z 16-bit resolution
z Selectable clock source
z 32.768kHz external crystal
z External clock
z 32.768kHz internal oscillator
z 32kHz internal ULP oscillator
z Programmable 10-bit clock prescaling
z One compare register
z One period register
z Clear counter on period overflow
z Optional interrupt/event on overflow and compare match
17.2 Overview
The 16-bit real-time counter (RTC) is a counter that typically runs continuously, including in low-power sleep modes, to
keep track of time. It can wake up the device from sleep modes and/or interrupt the device at regular intervals.
The reference clock is typically the 1.024kHz output from a high-accuracy crystal of 32.768kHz, and this is the
configuration most optimized for low power consumption. The faster 32.768kHz output can be selected if the RTC needs
a resolution higher than 1ms. The RTC can also be clocked from an external clock signal, the 32.768kHz internal
oscillator or the 32kHz internal ULP oscillator.
The RTC includes a 10-bit programmable prescaler that can scale down the reference clock before it reaches the
counter. A wide range of resolutions and time-out periods can be configured. With a 32.768kHz clock source, the
maximum resolution is 30.5μs, and time-out periods can range up to 2000 seconds. With a resolution of 1s, the
maximum timeout period is more than18 hours (65536 seconds). The RTC can give a compare interrupt and/or event
when the counter equals the compare register value, and an overflow interrupt and/or event when it equals the period
register value.
Figure 17-1. Real-time counter overview.
32.768kHz Crystal Osc
32.768kHz Int. Osc
TOSC1
TOSC2
External Clock
DIV32
DIV32
32kHz int ULP (DIV32)
RTCSRC
10-bit
prescaler
clkRTC
CNT
PER
COMP
=
=
”match”/
Compare
TOP/
Overflow
XMEGA B [MANUAL] 199
Atmel-8291C-AVR-XMEGA B -09/2014
17.2.1 Clock Domains
The RTC is asynchronous, operating from a different clock source independently of the main system clock and its
derivative clocks, such as the peripheral clock. For control and count register updates, it will take a number of RTC clock
and/or peripheral clock cycles before an updated register value is available in a register or until a configuration change
has effect on the RTC. This synchronization time is described for each register. Refer to “RTCCTRL – RTC Control
register” on page 85 for selecting the asynchronous clock source for the RTC.
17.2.2 Interrupts and Events
The RTC can generate both interrupts and events. The RTC will give a compare interrupt and/or event at the first count
after the counter value equals the Compare register value. The RTC will give an overflow interrupt request and/or event
at the first count after the counter value equals the Period register value. The overflow will also reset the counter value to
zero.
Due to the asynchronous clock domain, events will be generated only for every third overflow or compare match if the
period register is zero. If the period register is one, events will be generated only for every second overflow or compare
match. When the period register is equal to or above two, events will trigger at every overflow or compare match, just as
the interrupt request.
XMEGA B [MANUAL] 200
Atmel-8291C-AVR-XMEGA B -09/2014
17.3 Register Descriptions
17.3.1 CTRL – Control register
z Bit 7:3 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 2:0 – PRESCALER[2:0]: Clock Prescaling factor
These bits define the prescaling factor for the RTC clock according to Table 17-1.
Table 17-1. Real-time counter clock prescaling factor.
17.3.2 STATUS – Status register
z Bit 7:1 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 0 – SYNCBUSY: Synchronization Busy Flag
This flag is set when the CNT, CTRL, PER, or COMP register is busy synchronizing between the RTC clock and system
clock domains. THis flag is automatically cleared when the synchronisation is complete
Bit 7 6 5 4 3 2 1 0
+0x00 – – – – – PRESCALER[2:0]
Read/Write R R R R R R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
PRESCALER[2:0] Group Configuration RTC Clock Prescaling
000 OFF No clock source, RTC stopped
001 DIV1 RTC clock / 1 (no prescaling)
010 DIV2 RTC clock / 2
011 DIV8 RTC clock / 8
100 DIV16 RTC clock / 16
101 DIV64 RTC clock / 64
110 DIV256 RTC clock / 256
111 DIV1024 RTC clock / 1024
Bit 7 6 5 4 3 2 1 0
+0x01 – – – – – – – SYNCBUSY
Read/Write RRRRRRR R
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 201
Atmel-8291C-AVR-XMEGA B -09/2014
17.3.3 INTCTRL – Interrupt Control register
z Bit 7:4 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 3:2 – COMPINTLVL[1:0]: Compare Match Interrupt Enable
These bits enable the RTC compare match interrupt and select the interrupt level, as described in “Interrupts and
Programmable Multilevel Interrupt Controller” on page 115. The enabled interrupt will trigger when COMPIF in the
INTFLAGS register is set.
z Bit 1:0 – OVFINTLVL[1:0]: Overflow Interrupt Enable
These bits enable the RTC overflow interrupt and select the interrupt level, as described in “Interrupts and Programmable
Multilevel Interrupt Controller” on page 115. The enabled interrupt will trigger when OVFIF in the INTFLAGS register is
set.
17.3.4 INTFLAGS – Interrupt Flag register
z Bit 7:2 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 1 – COMPIF: Compare Match Interrupt Flag
This flag is set on the next count after a compare match condition occurs. It is cleared automatically when the RTC
compare match interrupt vector is executed. The flag can also be cleared by writing a one to its bit location.
z Bit 0 – OVFIF: Overflow Interrupt Flag
This flag is set on the next count after an overflow condition occurs. It is cleared automatically when the RTC overflow
interrupt vector is executed. The flag can also be cleared by writing a one to its bit location.
Bit 7 6 5 4 3 2 1 0
+0x02 – – – – COMPINTLVL[1:0] OVFINTLVL[1:0]
Read/Write R R R R R/W R/W R/W R/W
Initial Value 0 0000000
Bit 7 6 5 4 3 2 1 0
+0x03 – – – – – – COMPIF OVFIF
Read/Write R R R R R R R/W R/W
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 202
Atmel-8291C-AVR-XMEGA B -09/2014
17.3.5 TEMP – Temporary register
z Bit 7:0 – TEMP[7:0]: Temporary bits
This register is used for 16-bit access to the counter value, compare value, and TOP value registers. The low byte of the
16-bit register is stored here when it is written by the CPU. The high byte of the 16-bit register is stored when the low byte
is read by the CPU. For more details, refer to “Accessing 16-bit Registers” on page 13.
17.3.6 CNTL – Counter register Low
The CNTH and CNTL register pair represents the 16-bit value, CNT. CNT counts positive clock edges on the prescaled
RTC clock. Reading and writing 16-bit values requires special attention. Refer to “Accessing 16-bit Registers” on page 13
for details.
Due to synchronization between the RTC clock and system clock domains, there is a latency of two RTC clock cycles
from updating the register until this has an effect. Application software needs to check that the SYNCBUSY flag in the
“STATUS – Status register” on page 200 is cleared before writing to this register.
z Bit 7:0 – CNT[7:0]: Counter Value low byte
These bits hold the LSB of the 16-bit real-time counter value.
17.3.7 CNTH – Counter Register High
z Bit 7:0 – CNT[15:8]: Counter Value high byte
These bits hold the MSB of the 16-bit real-time counter value.
Bit 7 6 5 4 3 2 1 0
+0x04 TEMP[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
Bit 7 6 5 4 3 2 1 0
+0x08 CNT[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 000000
Bit 7 6 5 4 3 2 1 0
+0x09 CNT[15:8]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 203
Atmel-8291C-AVR-XMEGA B -09/2014
17.3.8 PERL – Period register Low
The PERH and PERL register pair represents the 16-bit value, PER. PER is constantly compared with the counter value
(CNT). A match will set OVFIF in the INTFLAGS register and clear CNT. Reading and writing 16-bit values requires
special attention. Refer to “Accessing 16-bit Registers” on page 13 for details.
Due to synchronization between the RTC clock and system clock domains, there is a latency of two RTC clock cycles
from updating the register until this has an effect. Application software needs to check that the SYNCBUSY flag in the
“STATUS – Status register” on page 200 is cleared before writing to this register.
z Bit 7:0 – PER[7:0]: Period low byte
These bits hold the LSB of the 16-bit RTC TOP value.
17.3.9 PERH – Period register High
z Bits 7:0 – PER[15:8]: Period high byte
These bits hold the MSB of the 16-bit RTC TOP value.
17.3.10 COMPL – Compare register Low
The COMPH and COMPL register pair represent the 16-bit value, COMP. COMP is constantly compared with the
counter value (CNT). A compare match will set COMPIF in the INTFLAGS register. Reading and writing 16-bit values
requires special attention. Refer “Accessing 16-bit Registers” on page 13 for details.
Due to synchronization between the RTC clock and system clock domains, there is a latency of two RTC clock cycles
from updating the register until this has an effect. Application software needs to check that the SYNCBUSY flag in the
“STATUS – Status register” on page 200 is cleared before writing to this register.
If the COMP value is higher than the PER value, no RTC compare match interrupt requests or events will ever be
generated.
z Bit 7:0 – COMP[7:0]: Compare value low byte
These bits hold the LSB of the 16-bit RTC compare value.
Bit 7 6 5 4 3 2 1 0
+0x0A PER[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 1 1 111111
Bit 7 6 5 4 3 2 1 0
+0x0B PER[15:8]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 1 1111111
Bit 7 6 5 4 3 2 1 0
+0x0C COMP[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 204
Atmel-8291C-AVR-XMEGA B -09/2014
17.3.11 COMPH – Compare register High
z Bit 7:0 – COMP[15:8]: Compare value high byte
These bits hold the MSB of the 16-bit RTC compare value.
Bit 76543210
+0x0D COMP[15:8]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 00000000
XMEGA B [MANUAL] 205
Atmel-8291C-AVR-XMEGA B -09/2014
17.4 Register Summary
17.5 Interrupt Vector Summary
Address Name Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 Page
+0x00 CTRL – – – – – PRESCALER[2:0] 200
+0x01 STATUS – – – – – – – SYNCBUSY 200
+0x02 INTCTRL – – – – COMPINTLVL[1:0] OVFINTLVL[1:0] 201
+0x03 INTFLAGS – – – – – – COMPIF OVFIF 201
+0x04 TEMP TEMP[7:0] 202
+0x08 CNTL CNT[7:0] 202
+0x09 CNTH CNT[15:8] 202
+0x0A PERL PER[7:0] 203
+0x0B PERH PER[15:8] 203
+0x0C COMPL COMP[7:0] 204
+0x0D COMPH COMP[15:8] 203
Offset Source Interrupt Description
0x00 OVF_vect Real-time counter overflow interrupt vector
0x02 COMP_vect Real-time counter compare match interrupt vector
XMEGA B [MANUAL] 206
Atmel-8291C-AVR-XMEGA B -09/2014
18. USB – Universal Serial Bus Interface
18.1 Features
z USB 2.0 full speed (12Mbps) and low speed (1.5Mbps) device compliant interface
z Integrated on-chip USB transceiver, no external components needed
z 16 endpoint addresses with full endpoint flexibility for up to 31 endpoints
z One input endpoint per endpoint address
z One output endpoint per endpoint address
z Endpoint address transfer type selectable to
z Control transfers
z Interrupt transfers
z Bulk transfers
z Isochronous transfers
z Configurable data payload size per endpoint, up to 1023 bytes
z Endpoint configuration and data buffers located in internal SRAM
z Configurable location for endpoint configuration data
z Configurable location for each endpoint's data buffer
z Built-in direct memory access (DMA) to internal SRAM for:
z Endpoint configurations
z Reading and writing endpoint data
z Ping-pong operation for higher throughput and double buffered operation
z Input and output endpoint data buffers used in a single direction
z CPU/DMA controller can update data buffer during transfer
z Multipacket transfer for reduced interrupt load and software intervention
z Data payload exceeding maximum packet size is transferred in one continuous transfer
z No interrupts or software interaction on packet transaction level
z Transaction complete FIFO for workflow management when using multiple endpoints
z Tracks all completed transactions in a first-come, first-served work queue
z Clock selection independent of system clock source and selection
z Minimum 1.5MHz CPU clock required for low speed USB operation
z Minimum 12MHz CPU clock required for full speed operation
z Connection to event system
z On chip debug possibilities during USB transactions
18.2 Overview
The USB module is a USB 2.0 full speed (12Mbps) and low speed (1.5Mbps) device compliant interface.
The USB supports 16 endpoint addresses. All endpoint addresses have one input and one output endpoint, for a total of
31 configurable endpoints and one control endpoint. Each endpoint address is fully configurable and can be configured
for any of the four transfer types: control, interrupt, bulk, or isochronous. The data payload size is also selectable, and it
supports data payloads up to 1023 bytes.
No dedicated memory is allocated for or included in the USB module. Internal SRAM is used to keep the configuration for
each endpoint address and the data buffer for each endpoint. The memory locations used for endpoint configurations
and data buffers are fully configurable. The amount of memory allocated is fully dynamic, according to the number of
endpoints in use and the configuration of these. The USB module has built-in direct memory access (DMA), and will
read/write data from/to the SRAM when a USB transaction takes place.
To maximize throughput, an endpoint address can be configured for ping-pong operation. When done, the input and
output endpoints are both used in the same direction. The CPU or DMA controller can then read/write one data buffer
while the USB module writes/reads the others, and vice versa. This gives double buffered communication.
XMEGA B [MANUAL] 207
Atmel-8291C-AVR-XMEGA B -09/2014
Multipacket transfer enables a data payload exceeding the maximum packet size of an endpoint to be transferred as
multiple packets without software intervention. This reduces the CPU intervention and the interrupts needed for USB
transfers.
For low-power operation, the USB module can put the microcontroller into any sleep mode when the USB bus is idle and
a suspend condition is given. Upon bus resumes, the USB module can wake up the microcontroller from any sleep
mode.
Figure 18-1. USB OUT transfer: data packet from host to USB device.
Figure 18-2. USB IN transfer: data packet from USB device to host after request from host.
18.3 Operation
This section gives an overview of the USB module operation during normal transactions. For general details on USB and
the USB protocol, please refer to http://www.usb.org and the USB specification documents.
Internal SRAM
USB
USB Endpoints
Configuration Table
USBEPPTR
USB
Buffers
ENDPOINT 1 DATA
ENDPOINT 2 DATA
ENDPOINT 3 DATA
D
A
T
A
0
D
A
T
A
0
D
A
T
A
0
D
A
T
A
1
D
A
T
A
0
D
A
T
A
1
D
A
T
A
0
D
A
T
A
1
D
A
T
A
0
D
A
T
A
1
D
A
T
A
0
BULK OUT
EPT 2
BULK OUT
EPT 3
BULK OUT
EPT 1
DP
DM
HOST
time
D
A
T
A
0
D
A
T
A
0
D
A
T
A
0
D
A
T
A
1
D
A
T
A
0
D
A
T
A
1
D
A
T
A
0
D
A
T
A
1
D
A
T
A
0
D
A
T
A
1
D
A
T
A
0
EPT 2 EPT 3 EPT 1
DP
DM
HOST
I
N
T
O
K
E
N
I
N
T
O
K
E
N
I
N
T
O
K
E
N
EPT 2 EPT 3 EPT 1
time
Internal SRAM
USB
USB Endpoints
Configuration Table
USBEPPTR
USB
Buffers
ENDPOINT 1 DATA
ENDPOINT 2 DATA
ENDPOINT 3 DATA
CPU
XMEGA B [MANUAL] 208
Atmel-8291C-AVR-XMEGA B -09/2014
18.3.1 Start of Frame
When a start of frame (SOF) token is detected and storing of the frame numbers is enabled, the frame number from the
token is stored in the frame number register (FRAMENUM) and the start of frame interrupt flag (SOFIF) in the interrupt
flag B clear/set register (INTFLAGSBCLR/SET) is set. If there was a CRC or bit-stuff error, the frame error (FRAMEERR)
flag in FRAMENUM is set.
18.3.2 SETUP
When a SETUP token is detected, the USB module fetches the endpoint control register (CTRL) from the addressed
output endpoint in the endpoint configuration table. If the endpoint type is not set to control, the USB module returns to
idle and waits for the next token packet.
Figure 18-3. SETUP transaction.
The USB module then fetches the endpoint data pointer register (DATAPTR) and waits for a DATA0 packet. If a PID
error or any other PID than DATA0 is detected, the USB module returns to idle and waits for the next token packet.
The incoming data are written to the data buffer pointed to by DATAPTR. If a bit-stuff error is detected in the incoming
data, the USB module returns to idle and waits for the next token packet. If the number of received data bytes exceeds
the endpoint's maximum data payload size, as specified by the data size (SIZE) in the endpoint CTRL register, the
remaining received data bytes are discarded. The packet will still be checked for bit-stuff and CRC errors. Software must
never report a maximum data payload size to the host that is greater than specified in SIZE. If there was a bit-stuff or
CRC error in the packet, the USB module returns to idle and waits for the next token packet.
If data was successfully received, an ACK handshake is returned to the host, and the number of received data bytes,
excluding the CRC, is written to the endpoint byte counter (CNT). If the number of received data bytes is the maximum
data payload specified by SIZE, no CRC data are written in the data buffer. If the number of received data bytes is the
maximum data payload specified by SIZE minus one, only the first CRC data byte is written in the data buffer. If the
number of received data bytes is equal or less than the data byte payload specified by SIZE minus two, the two CRC
data bytes are written in the data buffer.
Finally, the setup transaction complete flag (SETUP), data buffer 0 not acknowledge flag (NACK0), and data toggle flag
(TOGGLE) are set, while the remaining flags in the endpoint status register (STATUS) are cleared for the addressed
input and output endpoints. The setup transaction complete interrupt flag (SETUPIF) in INTFLAGSBCLR/SET is set. The
STALL flag in the endpoint CTRL register is cleared for the addressed input and output endpoints.
When a SETUP token is detected and the device address of the token packet does not match that of the endpoint, the
packet is discarded, and the USB module returns to idle and waits for the next token packet.
18.3.3 OUT
When an OUT token is detected, the USB module fetches the endpoint CTRL and STATUS register data from the
addressed output endpoint in its endpoint configuration table. If the endpoint is disabled, the USB module returns to idle
and waits for the next token packet.
SETUP
TOKEN ADDRESS ADDRESS
MATCH? ENDPOINT LEGAL
ENDPOINT?
EP TYPE
CTRL SET? PID PID OK?
DATA BIT STUFF BIT STUFF
OK? CRC OK? ACK
IDLE
No No No No
No No
READ
CONFIG
UPDATE
STATUS
STORE
DATA
Yes Yes
Yes Yes Yes Yes
CRC
XMEGA B [MANUAL] 209
Atmel-8291C-AVR-XMEGA B -09/2014
Figure 18-4. OUT transaction.
The USB module then fetches the endpoint DATAPTR register and waits for a DATA0 or DATA1 packet. If a PID error or
any other PID than DATA0 or DATA1 is detected, the USB module returns to idle and waits for the next token packet.
If the STALL flag in the endpoint CTRL register is set, the incoming data are discarded. If the endpoint is not
isochronous, and the bit stuffing and CRC of the received data are OK, a STALL handshake is returned to the host, and
the STALL interrupt flag is set.
For isochronous endpoints, data from both a DATA0 and DATA1 packet will be accepted. For other endpoint types, the
PID is checked against TOGGLE. If they don't match, the incoming data are discarded and a NAK handshake is returned
to the host. If BUSNACK0 is set, the incoming data are discarded. The overflow flag (OVF) in the endpoint STATUS
register and the overflow interrupt flag (OVFIF) in the INTFLAGSASET/CLR register are set. If the endpoint is not
isochronous, a NAK handshake is returned to the host.
The incoming data are written to the data buffer pointed to by DATAPTR. If a bit-stuff error is detected in the incoming
data, the USB module returns to idle and waits for the next token packet. If the number of received data bytes exceeds
the maximum data payload specified by SIZE, the remaining received data bytes are discarded. The packet will still be
checked for bit-stuff and CRC errors. If there was a bit-stuff or CRC error in the packet, the USB module returns to idle
and waits for the next token packet.
If the endpoint is isochronous and there was a bit-stuff or CRC error in the incoming data, the number of received data
bytes, excluding CRC, is written to the endpoint CNT register. Finally, CRC and BUSNACK0 in the endpoint and
STATUS and CRCIF in INTFLAGSASET/CLR are set.
If data was successfully received, an ACK handshake is returned to the host if the endpoint is not isochronous, and the
number of received data bytes, excluding CRC, is written to CNT. If the number of received data bytes is the maximum
data payload specified by SIZE no CRC data are written in the data buffer. If the number of received data bytes is the
maximum data payload specified by SIZE minus one, only the first CRC data byte is written in the data buffer If the
number of received data bytes is equal or less than the data payload specified by SIZE minus two, the two CRC data
bytes are written in the data buffer.
Finally, the transaction complete flag (TRNCOMPL0) and BUSNACK0 are set and TOGGLE is toggled if the endpoint is
not isochronous. The transaction complete interrupt flag (TRNIF) in INTFLAGSBCLR/SET is set. The endpoint's
configuration table address is written to the FIFO if the transaction complete FIFO mode is enabled.
OUT
TOKEN ADDRESS ADDRESS
MATCH? ENDPOINT LEGAL
ENDPOINT?
EP STATUS
ENABLED? PID PID OK?
DATA BIT STUFF BIT STUFF
OK? CRC OK? ACK
IDLE
No No No
No No
STALL &
ISO? STALL? STALL
ISO? DATA
No
BUSNACK0
SET? NAK
Yes No
No
No
READ
CONFIG
UPDATE
STATUS
STORE
DATA
STORE
DATA
No
Yes Yes Yes Yes
Yes
Yes
Yes
READ
CONFIG
PIDO/1
OK? NAK UPDATE
STATUS
No
Yes
DATA BIT STUFF CRC BIT STUFF
OK? CRC OK?
BUSNACK0
SET?
CRC
Yes No
Yes
Yes
No
Yes
No
Yes
XMEGA B [MANUAL] 210
Atmel-8291C-AVR-XMEGA B -09/2014
When an OUT token is detected and the device address of the token packet does not match that of the endpoint, the
packet is discarded and the USB module returns to idle and waits for the next token packet.
18.3.4 IN
If an IN token is detected the, the USB module fetches the endpoint CTRL and STATUS register data from the addressed
input endpoint in the endpoint configuration table. If the endpoint is disabled, the USB module returns to idle and waits for
the next token packet.
If the STALL flag in endpoint CTRL register is set, and the endpoint is not isochronous, a STALL handshake is returned
to the host, the STALL flag in the endpoint STATUS register and the STALL interrupt flag (STALLIF) in
INTFLAGSACLR/SET are set.
If BUSNACK0 is set, OVF in the endpoint STATUS register and OVFIF in the INTFLAGSACLR/SET register are set. If
the endpoint is not isochronous, a NAK handshake is returned to the host.
The data in the data buffer pointed to by the endpoint DATAPTR register are sent to the host in a DATA0 packet if the
endpoint is isochronous; otherwise, a DATA0 or DATA1 packet according to TOGGLE is sent. When the number of data
bytes specified in endpoint CNT is sent, the CRC is appended and sent to the host. If not, a ZLP handshake is returned
to the host.
For isochronous endpoints, BUSNACK0 and TRNCOMPL0 in the endpoint STATUS register are set. TRNIF is set, and
the endpoint's configuration table address is written to the FIFO if the transaction complete FIFO mode is enabled.
For all non-isochronous endpoints, the USB module waits for an ACK handshake from the host. If an ACK handshake is
not received within 16 USB clock cycles, the USB module returns to idle and waits for the next token packet. If an ACK
handshake was successfully received, BUSNACK0 and TRNCOMPL0 are set and TOGGLE is toggled. TRNIF is set and
the endpoint's configuration table address is written to the FIFO if the transaction complete FIFO mode is enabled.
When an IN token is detected and the device address of the token packet does not match that of the endpoint, the packet
is discarded and the USB module returns to idle and waits for the next token packet.
Figure 18-5. IN transaction.
IN
TOKEN ADDRESS ADDRESS
MATCH? ENDPOINT LEGAL
ENDPOINT?
EP STATUS
ENABLED?
DATA ACK PAYLOAD
OK?
IDLE
No No No
No
STALL &
NO ISO? STALL
NAK
No
READ
CONFIG
READ
DATA
READ
CONFIG
UPDATE
STATUS
Yes
Yes Yes Yes
Yes
BUSNACK0
SET? ISO? Yes No
ISO? ACK
SET?
Yes No
Yes Yes
No
No
ZLP
CRC
XMEGA B [MANUAL] 211
Atmel-8291C-AVR-XMEGA B -09/2014
18.4 SRAM Memory Mapping
The USB module uses internal SRAM to store the:
z Endpoint configuration table
z USB frame number
z Transaction complete FIFO
The endpoint pointer register (EPPTR) is used to set the SRAM address for the endpoint configuration table. The USB
frame number (FRAMENUM) and transaction complete FIFO (FIFO) locations are derived from this. The locations of
these areas are selectable inside the internal SRAM. Figure on page 211 gives the relative memory location of each
area.
Figure 18-6. SRAM memory mapping.
18.5 Clock Generation
The USB module requires a minimum 6MHz clock for USB low speed operation, and a minimum 48MHz clock for USB
full speed operation. It can be clocked from internal or external clock sources by using the internal PLL, or directly from
the 32MHz internal oscillator when it is tuned and calibrated to 48MHz. The CPU and peripherals clocks must run at a
minimum of 1.5MHz for low speed operation, and a minimum of 12MHz for full speed operation.
The USB module clock selection is independent of and separate from the main system clock selection. Selection and
setup are done using the main clock control settings. For details, refer to “System Clock and Clock Options” on page 75.
The Figure 18-7 on page 212 shows an overview of the USB module clock selection.
FIFO EP_ADDRH_MAX
EP_ADDRL_0
EP_ADDRH_0
(MAXEP+1) x 4 Bytes
Active when FIFOEN==1
ENDPOINT
DESCRIPTORS
TABLE
STATUS
CTRL
CNTL
CNTH
DATAPTRL
DATAPTRH
AUXDATAL
AUXDATAH
ENDPOINT
0 OUT
STATUS
CTRL
CNTL
CNTH
DATAPTRL
DATAPTRH
AUXDATAL
AUXDATAH
ENDPOINT
0 IN
STATUS
CTRL
CNTL
CNTH
DATAPTRL
DATAPTRH
AUXDATAL
AUXDATAH
ENDPOINT
MAXEP IN
(MAXEP+1) x 16 Bytes
FRAME
NUMBER
FRAMENUML
FRAMENUMH
2 Bytes
Active when
STFRNUM==1
0x00
0x01
0x02
0x03
0x04
0x05
0x06
0x07
(MAXEP+1)<<4
EPPTR
EPPTR +
(MAXEP+1)*16
SRAM
ADDRESS
XMEGA B [MANUAL] 212
Atmel-8291C-AVR-XMEGA B -09/2014
Figure 18-7. Clock generation configuration.
18.6 Ping-pong Operation
When an endpoint is configured for ping-pong operation, it uses the input and output data buffers to create a single,
double-buffered endpoint that can be set to input or output direction. This provides double-buffered communication, as
the CPU or DMA controller can access one of the buffers, while the other buffer is processing an ongoing transfer. Pingpong
operation is identical to the IN and OUT transactions described above, unless otherwise noted in this section. Pingpong
operation is not possible for control endpoints.
When ping-pong operation is enabled for an endpoint, the endpoint in the opposite direction must be disabled. The data
buffer, data pointer, byte counter, and auxiliary data from the enabled endpoint are used as bank 0, and,
correspondingly, bank 1 for the opposite endpoint direction.
The bank select (BANK) flag in the endpoint STATUS register indicates which data bank will be used in the next
transaction. It is updated after each transaction. The TRNCOMPL0/TRNCOMPL1, underflow/overflow (UDF/OVF), and
CRC flags in the STATUS register are set for either the enabled or the opposite endpoint direction according to the BANK
flag. The data toggle (TOGGLE), data buffer 0/1 not acknowledge (BUSNACK0 and BUSNACK1), and BANK flags are
updated for the enabled endpoint direction only.
Figure 18-8. Ping-pong operation overview.
USB module
48MHz full speed
6MHz for low speed
USBSRC
USB clock
prescaler
USBPSDIV
PLL
48MHz Internal Oscillator
Bank0
Available time for data processing by CPU to avoid NACK
Without Ping-Pong
With Ping-Pong
Bank1
Endpoint
single bank
Endpoint
Double bank
USB data packet
t
t
XMEGA B [MANUAL] 213
Atmel-8291C-AVR-XMEGA B -09/2014
18.7 Multipacket Transfers
Multipacket transfer enables a data payload exceeding the maximum data payload size of an endpoint to be transferred
as multiple packets without any software intervention. This reduces interrupts and software intervention to the higher
level USB transfer, and frees up significant CPU time. Multipacket transfer is identical to the IN and OUT transactions
described above, unless otherwise noted in this section.
The application software provides the size and address of the SRAM buffer to be processed by the USB module for a
specific endpoint, and the USB module will then split the buffer in the required USB data transfer.
Figure 18-9. Multipacket overview.
18.7.1 For Input Endpoints
The total number of data bytes to be sent is written to CNT, as for normal operation. The auxiliary data register
(AUXDATA) is used to store the number of bytes that will be sent, and must be written to zero for a new transfer.
When an IN token is received, the endpoint’s CNT and AUXDATA are fetched. If CNT minus AUXDATA is less than the
endpoint SIZE, endpoint CNT minus endpoint AUXDATA number bytes are transmitted; otherwise, SIZE number of bytes
are transmitted. If endpoint CNT is a multiple of SIZE and auto zero length packet (AZLP) is enabled, the last packet sent
will be zero length.
If a maximum payload size packet was sent (i.e., not the last transaction), AUXDATA is incremented by SIZE. TOGGLE
will be toggled after the transaction has completed if the endpoint is not isochronous. If a short packet was sent (i.e., the
last transaction), AUXDATA is incremented by the data payload. TOGGLE will be toggled if the endpoint is not
isochronous, and BUSNACK, TRNIF, and TRNCOMPL0 will be set.
18.7.2 For Output Endpoints
The number of data bytes received is stored in the endpoint’s CNT register, as for normal operation. Since the endpoint’s
CNT is updated after each transaction, it must be set to zero when setting up a new transfer. The total number of bytes to
be received must be written to AUXDATA. This value must be a multiple of SIZE, except for ISO 1023 bytes endpoints;
otherwise, excess data may be written to SRAM locations used by other parts of the application.
TOGGLE management is as for non-isochronous packets, and BUSNACK0/BUSNACK1 management is as for normal
operation.
If a maximum payload size packet is received, CNT is incremented by SIZE after the transaction has completed, and
TOGGLE toggles if the endpoint is not isochronous. If the updated endpoint CNT is equal to AUXDATA, then
BUSNACK0/BUSNACK1, TRNIF, and TRNCOMPL0/TRNCOMPL1 will be set.
If a short or oversized packet is received, the endpoint’s CNT register will be incremented by the data payload after the
transaction has completed. TOGGLE will be toggled if the endpoint is not isochronous, and BUSNACK0/BUSNACK1,
TRNIF, and TRNCOMPL0/TRNCOMPL1 will be set.
Transfer Complete Interrupt and data processing
Without multipacket
With multipacket
XMEGA B [MANUAL] 214
Atmel-8291C-AVR-XMEGA B -09/2014
18.8 Auto Zero Length Packet
Some IN transfer requires a zero length packet to be generated in order to signal end of transfer to the host. The auto
zero length packet (AZLP) function can be enabled to perform this generation automatically, thus removing the need for
application software or CPU intervention to perform this task.
18.9 Transaction Complete FIFO
The transaction complete FIFO provides a convenient way to keep track of the endpoints that have completed IN or OUT
transactions and need firmware intervention. It creates a first-come, first-served work queue for the application software.
The FIFO size is (MAXEP[3:0] + 1) × 4 bytes, and grows downward, starting from EPPTR - 1. This SRAM memory is
allocated only when the FIFO is enabled.
Figure 18-10.Transfer complete FIFO.
To manage the FIFO, a five-bit write pointer (FIFOWP) and five-bit read pointer (FIFORP) are used by the USB module
and application software, respectively. FIFORP and FIFOWP are one's complemented, and thus hold negative values.
The SRAM location of the data is the sum of EPPTR and the read or write pointer. The number of items in the FIFO is the
difference between FIFOWP and FIFORP. For the programmer, the FIFORP and FIFOWP values have to be cast to a
signed 8-bit integer, and then the offset into the FIFO from this signed integer must be deducted.
The transaction complete interrupt flag (TRNIF) in the INFLAGSB[CLR,SET] register is set to indicate a non-empty FIFO
when FIFORP != FIFOWP, cleared when they are equal, and also set when the FIFO is full.
Each time an endpoint IN or OUT transaction completes successfully, its endpoint configuration table address is stored in
the FIFO at the current write pointer position (i.e., EPPTR + 2 × FIFOWP) and FIFOWP is decremented. When the
pointer reaches the FIFO size, it wraps to zero. When application software reads FIFORP, this is decremented in the
same way. Reading the write pointer has no effect. The endpoint configuration table address can then be read directly
from (EPPTR + 2 × FIFORP).
Figure 18-11.USB transaction complete FIFO example.
USB_TC_ FIFO
TC_EP_ ADDRH_0
TC_EP_ ADDRL_0
TC_EP_ ADDRH_ MAX
ENDPOINT DESCRIPTOR TABLE
TC_EP_ ADDRH_1
TC_EP_ ADDRL_1
INTERNAL SRAM
TC_EP_ ADDRH_2
TC_EP_ ADDRH_2
FIFOWP
FIFORP
EPPTR
SRAM
ADDRESS
EPPTR –
4x( MAXEP+1)
Ep X EpY EpZ t
FIFO
X
Y
Z
FIFOWP
FIFORP
FIFO
X
Y
FIFOWP
FIFORP
FIFO
X
FIFOWP
FIFORP
FIFO
FIFOWP FIFORP
XMEGA B [MANUAL] 215
Atmel-8291C-AVR-XMEGA B -09/2014
18.10 Interrupts and Events
The USB module can generate interrupts and events. The module has 10 interrupt sources. These are split between two
interrupt vectors, the transaction complete (TRNCOMPL) interrupt and the bus event (BUSEVENT) interrupt. An interrupt
group is enabled by setting its interrupt level (INTLVL), while different interrupt sources are enabled individually or in
groups.
Figure 18-12 on page 215 summarizes the interrupts and event sources for the USB module, and shows how they are
enabled.
Figure 18-12.Interrupts and events scheme summary.
18.10.1 Transaction Complete Interrupt
The transaction complete interrupt is generated per endpoint. When an interrupt occurs, the associated endpoint number
is registered and optionally added to the FIFO. The following two interrupt sources use the interrupt vector:
SUSPENDIF SOFIE
RESUMEIF
RSTIF
CRCIF
UNFIF
OVFIF
STALLIF
BSEVIE
STALLIE
BUSSERRIE
SOFIF
SETUPIE
TRNIF
TRNIE
SETUPIF
Busevent
Interrupt request
Transaction Complete
Interrupt request
XMEGA B [MANUAL] 216
Atmel-8291C-AVR-XMEGA B -09/2014
Table 18-1. Transaction complete interrupt sources.
18.10.2 Bus Event Interrupt
The bus event (BUSEVENT) interrupt is used for all interrupts that signal various types of USB line events or error
conditions. These interrupts are related to the USB lines, and are generated for the USB module and per endpoint. The
following eight interrupts use the interrupt vector:
Table 18-2. Bus event interrupt source.
18.10.3 Events
The USB module can generate several events, and these are available to the event system, allowing latency-free
signaling to other peripherals or performance analysis of USB operation.
Table 18-3. Event sources.
18.11 VBUS Detection
Atmel AVR XMEGA devices can use any general purpose I/O pin to implement a VBUS detection function, and do not
use a dedicated VBUS detect pin.
Interrupt source Description
Transfer complete (TRNIF) An IN or OUT transaction is completed
Setup complete (SETUPIF) A SETUP transaction is completed
Interrupt source Description
Start of frame (SOFIF) A SOF token has been received
Suspend (SUSPENDIF) The bus has been idle for 3ms
Resume (RESUMEIF) A non-idle state is detected when the bus is suspended.
The interrupt is asynchronous and can wake the device from all sleep modes
Reset (RSTIF) A reset condition has been detected on the bus
Isochronous CRC error (CRCIF) A CRC or bit-stuff error has been detected in an incoming packet to an
isochronous endpoint
Underflow (UNFIF) An endpoint is unable to return data to the host
Overflow (OVFIF) An endpoint is unable to accept data from the host
STALL (STALLIF) A STALL handshake has been returned to the host
Event source Description
SETUP SETUPIF
Start of Frame SOFIF
CRC error CRCIF
Underflow/overflow UNFIF and OVFIF
XMEGA B [MANUAL] 217
Atmel-8291C-AVR-XMEGA B -09/2014
18.12 On-chip Debug
When a break point is reached during on-chip debug (OCD) sessions, the CPU clock can be below 12MHz. If this
happens, the USB module will behave as follows:
USB OCD break mode disabled: The USB module immediately acknowledges any OCD break request. The USB module
will not be able to follow up on transactions received from the USB host, and its behaviour from the host point of view is
not predictable.
USB OCD break mode enabled: The USB module will immediately acknowledge any OCD break request only if there are
no ongoing USB transactions. If there is an ongoing USB transaction, the USB module will acknowledge any OCD break
request only when the ongoing USB transaction has been completed. The USB module will NACK any further
transactions received from the USB host, whether they are SETUP, IN (ISO, BULK), or OUT (ISO, BULK).
XMEGA B [MANUAL] 218
Atmel-8291C-AVR-XMEGA B -09/2014
18.13 Register Description – USB
18.13.1 CTRLA – Control register A
z Bit 7 – ENABLE: USB Enable
Setting this bit enables the USB interface. Clearing this bit disables the USB interface and immediately aborts any
ongoing transactions.
z Bit 6 – SPEED: Speed Select
This bit selects between low and full speed operation. By default, this bit is zero, and low speed operation is selected.
Setting this bit enables full speed operation.
z Bit 5 – FIFOEN: USB FIFO Enable
Setting this bit enables the USB transaction complete FIFO, and the FIFO stores the endpoint configuration table
address of each endpoint that generates a transaction complete interrupt. Clearing this bit disables the FIFO and frees
the allocated SRAM memory.
z Bit 4 – STFRNUM: Store Frame Number Enable
Setting this bit enables storing of the last SOF token frame number in the frame number (FRAMENUM) register. Clearing
this bit disables the function.
z Bit 3:0 – MAXEP[3:0]: Maximum Endpoint Address
These bits select the number of endpoint addresses used by the USB module. Incoming packets with a higher endpoint
number than this address will be discarded. Packets with endpoint addresses lower than or equal to this address will
cause the USB module to look up the addressed endpoint in the endpoint configuration table.
18.13.2 CTRLB – Control register B
z Bit 7:5 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 4 – PULLRST: Pull during Reset
Setting this bit enables the pull-up on the USB lines to also be held when the device enters reset. The bit will be cleared
on a power-on reset.
z Bit 3 – Reserved
This bit is unused and reserved for future use. For compatibility with future devices, always write this bit to zero when this
register is written.
Bit 7 6 5 4 3 2 1 0
+0x00 ENABLE SPEED FIFOEN STFRNUM MAXEP[3:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 00000000
Bit 7 6 5 4 3 2 1 0
+0x01 – – – PULLRST – RWAKEUP GNACK ATTACH
Read/Write R R R R/W R R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 219
Atmel-8291C-AVR-XMEGA B -09/2014
z Bit 2 – RWAKEUP: Remote Wake-up
Setting this bit sends an upstream resume on the USB lines if the bus is in the suspend state for at least 5 ms.
z Bit 1 – GNACK: Global NACK
When this bit is set, the USB module will NACK all incoming transactions. Expect for a SETUP packet, this prevents the
USB module from performing any on-chip SRAM access, giving all SRAM bandwidth to the CPU and/or DMA controller.
z Bit 0 – ATTACH: Attach
Setting this bit enables the internal D+ or D- pull-up (depending on the USB speed selection), and attaches the device to
the USB lines. Clearing this bit disconnects the device from the USB lines.
18.13.3 STATUS – Status register
z Bit 7:4 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 3 – URESUME: Upstream Resume
This flag is set when an upstream resume is sent.
z Bit 2 – RESUME: Resume
This flag is set when a downstream resume is received.
z Bit 1 – SUSPEND: Bus Suspended
This flag is set when the USB lines are in the suspended state (the bus has been idle for at least 3ms).
z Bit 0 – BUSRST: Bus Reset
This flag is set when a reset condition has been detected (the bus has been driven to SE0 for at least 2.5μs).
18.13.4 ADDR – Address register
z Bit 7 – Reserved
This bit is unused and reserved for future use. For compatibility with future devices, always write this bit to zero when this
register is written.
z Bit 6:0 – ADDR[6:0]: Device Address
These bits contain the USB address the device will respond to.
Bit 7 6 5 4 3 2 1 0
+0x02 – – – – URESUME RESUME SUSPEND BUSRST
Read/Write RRRRRRRR
Initial Value 00000000
Bit 7 6 5 4 3 2 1 0
+0x03 – ADDR[6:0]
Read/Write R R/W R/W R/W R/W R/W R/W R/W
Initial Value 00000000
XMEGA B [MANUAL] 220
Atmel-8291C-AVR-XMEGA B -09/2014
18.13.5 FIFOWP – FIFO Write Pointer register
z Bit 7:5 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 4:0 – FIFOWP[4:0]: FIFO Write Pointer
These bits contain the transaction complete FIFO write pointer. This register must be read only by the CPU or DMA
controller. Writing this register will flush the FIFO write and read pointers.
18.13.6 FIFORP – FIFO Read Pointer register
z Bit 7:5 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 4:0 – FIFORP[4:0]: FIFO Read Pointer
These bits contain the transaction complete FIFO read pointer. This register must only be read by the CPU or DMA
controller. Writing this register will flush the FIFO write and read pointer.
18.13.7 EPPTRL – Endpoint Configuration Table Pointer Low
The EPPTRL and EPPTRH registers represent the 16-bit value, EPPTR, that contains the address to the endpoint
configuration table. The pointer to the endpoint configuration table must be aligned to a 16-bit word; i.e., EPPTR[0] must
be zero. Only the number of bits required to address the available internal SRAM memory is implemented for each
device. Unused bits will always be read as zero.
z Bit 7:0 – EPPTR[7:0]: Endpoint Configuration Table Pointer low byte
This register contains the eight lsbs of the endpoint configuration table pointer (EPPTR).
Bit 7 6 5 4 3 2 1 0
+0x04 – – – FIFOWP[4:0]
Read/Write R R R R/W R/W R/W R/W R/W
Initial Value 00000000
Bit 7 6 5 4 3 2 1 0
+0x05 – – – FIFORP[4:0]
Read/Write R R R R/W R/W R/W R/W R/W
Initial Value 00000000
Bit 7 6 5 4 3 2 1 0
+0x06 EPPTR[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 221
Atmel-8291C-AVR-XMEGA B -09/2014
18.13.8 EPPTRH – Endpoint Configuration Table Pointer High
z Bit 7:0 – EPPTR[15:8]: Endpoint Configuration Table Pointer high byte
This register contains the eight msbs of the endpoint configuration table pointer (EPPTR).
18.13.9 INTCTRLA – Interrupt Control register A
z Bit 7 – SOFIE: Start Of Frame Interrupt Enable
Setting this bit enables the start of frame (SOF) interrupt for the conditions that set the start of frame interrupt flag
(SOFIF) in the INTFLAGSACLR/ INTFLAGSASET register. The INTLVL bits must be nonzero for the interrupts to be
generated.
z Bit 6 – BUSEVIE: Bus Event Interrupt Enable
Setting this bit will enable the interrupt for the following three bus events:
1. Suspend: An interrupt will be generated for the conditions that set the suspend interrupt flag (SUSPENDIF) in the
INTFLAGSACLR/SET register.
2. Resume: An interrupt will be generated for the conditions that set the resume interrupt flag (RESUMEIF) in the
INTFLAGSACLR/SET register.
3. Reset: An interrupt will be generated for the conditions that set the reset interrupt flag (RESETIF) in the INTFLAGSACLR/SET
register.
The INTLVL bits must be nonzero for the interrupts to be generated.
z Bit 5 – BUSERRIE: Bus Error Interrupt Enable
Setting this bit will enable the interrupt for the following three bus error events:
1. Isochronous CRC Error: An interrupt will be generated for the conditions that set the CRC interrupt flag (CRCIF) in
the INTFLAGSACLR/SET register during isochronous transfers.
2. Underflow: An interrupt will be generated for the conditions that set the underflow interrupt flag (UNFIF) in the
INTFLAGSACLR/SET register.
3. Overflow: An interrupt will be generated for the conditions that set the overflow interrupt flag (OVFIF) in the
INTFLAGSACLR/SET register.
The INTLVL bits must be nonzero for the interrupts to be generated.
z Bit 4 – STALLIE: STALL Interrupt Enable
Setting this bit enables the STALL interrupt for the conditions that set the stall interrupt flag (STALLIF) in the
INTFLAGSACLR/SET register. The INTLVL bits must be nonzero for the interrupts to be generated.
Bit 7 6 5 4 3 2 1 0
+0x07 EPPTR[15:8]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
Bit 7 6 5 4 3 2 1 0
+0x06 SOFIE BUSEVIE BUSERRIE STALLIE – – INTLVL[1:0]
Read/Write R/W R/W R/W R/W R R R/W R/W
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 222
Atmel-8291C-AVR-XMEGA B -09/2014
z Bit 3:2 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 1:0 – INTLVL[1:0]: Interrupt Level
These bits enable the USB interrupts and select the interrupt level, as described in “Interrupts and Programmable
Multilevel Interrupt Controller” on page 115. In addition, each USB interrupt source must be separately enabled.
18.13.10INTCTRLB – Interrupt Control register B
z Bit 7:2 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 1 – TRNIE: Transaction Complete Interrupt Enable
Setting this bit enables the transaction complete interrupt for IN and OUT transactions. The INTLVL bits must be nonzero
for interrupts to be generated.
z Bit 0 – SETUPIE: SETUP Transaction Complete Interrupt Enable
Setting this bit enables the SETUP Transaction Complete Interrupt for SETUP transactions. The INTLVL bits must be
non-zero for the interrupts to be generated.
18.13.11INTFLAGSACLR/ INTFLAGSASET – Clear/ Set Interrupt Flag register A
This register is mapped into two I/O memory locations, one for clearing (INTFLAGSACLR) and one for setting
(INTFLAGSASET) the flags. The individual flags can be set by writing a one to their bit locations in INFLAGSASET, and
cleared by writing a one to their bit locations in INT-FLAGSACLR. Both memory locations will provide the same result
when read, and writing zero to any bit location has no effect.
z Bit 7 – SOFIF: Start Of Frame Interrupt Flag
This flag is set when a start of frame packet has been received.
z Bit 6 – SUSPENDIF: Suspend Interrupt Flag
This flag is set when the bus has been idle for 3ms.
z Bit 5 – RESUMEIF: Resume Interrupt Flag
This flag is set when a non-idle state has been detected on the bus while the USB module is in the suspend state. This
interrupt is asynchronous, and is able to wake the CPU from sleep modes where the system clock is stopped, such as
power-down and power-save sleep modes.
z Bit 4 – RSTIF: Reset Interrupt Flag
This flag is set when a reset condition has been detected on the bus.
Bit 7 6 5 4 3 2 1 0
+0x07 – – – – – – TRNIE SETUPIE
Read/Write R R R R R R R/W R/W
Initial Value 0 0 0 0 0 0 0 0
Bit 7 6 5 4 3 2 1 0
+0x0A/ +0x0B SOFIF SUSPENDIF RESUMEIF RESETIF CRCIF UNFIF OVFIF STALLIF
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 223
Atmel-8291C-AVR-XMEGA B -09/2014
z Bit 3 – CRCIF: Isochronous CRC Error Interrupt Flag
This flag is set when a CRC error has been detected in an incoming data packet to an isochronous endpoint.
z Bit 2 – UNFIF: Underflow Interrupt Flag
This flag is set when the addressed endpoint in an IN transaction does not have data to send to the host.
z Bit 1 – OVFIF: Overflow Interrupt Flag
This flag is set when the addressed endpoint in an OUT transaction is not ready to accept data from the host.
z Bit 0 – STALLIF: STALL Interrupt Flag
This flag is set when the USB module has responded with a STALL handshake to either an IN or an OUT transaction.
18.13.12INTFLAGSBCLR/INTFLAGSBSET – Clear/Set Interrupt Flag register B
This register is mapped into two I/O memory locations, one for clearing (INTFLAGSBCLR) and one for setting
(INTFLAGSBSET) the flags. The individual flags can be set by writing a one to their bit locations in INFLAGSBSET, and
cleared by writing a one to their bit locations in INTFLAGSBCLR. Both memory locations will provide the same result
when read, and writing zero to any bit location has no effect.
z Bit 7:2 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 1 – TRNIF: Transaction Complete Interrupt Flag
This flag is when there is a pending packet interrupt in the FIFO.
z Bit 0 – SETUPIF: SETUP Transaction Complete Interrupt Flag
This flag is set when a SETUP transaction has completed successfully.
18.13.13CALL – Calibration register Low
CALL and CALH hold the 16-bit value, CAL. The USB PADs (D- and D+) are calibrated during production to enable
operation without requiring external components on the USB lines. The calibration value is stored in the signature row of
the device, and must be read from there and written to the CAL registers from software.
z Bit 7:0 – CAL[7:0]: PAD Calibration low byte
This byte holds the eight lsbs of CAL.
Bit 7 6 5 4 3 2 1 0
+0x0C/ +0x0D – – – – – –- TRNIF SETUPIF
Read/Write R R R R R R R/W R/W
Initial Value 0 0 0 0 0 0 0 0
Bit 7 6 5 4 3 2 1 0
++0x3A CAL[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 224
Atmel-8291C-AVR-XMEGA B -09/2014
18.13.14CALH – Calibration register High
z Bit 7:0 – CAL[15:8]: PAD Calibration high byte
This byte holds the eight msbs of CAL.
Bit 7 6 5 4 3 2 1 0
+0x3B CAL[15:8]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 225
Atmel-8291C-AVR-XMEGA B -09/2014
18.14 Register Description – USB Endpoint
Each of the 16 endpoint addresses have one input and one output endpoint. Each endpoint has eight bytes of
configuration/status data located in internal SRAM.
The address to the first configuration byte is (EPPTR[15:0] + 16 × endpoint address) for output endpoints and
(EPPTR[15:0] + 16 × endpoint address + 8) for input endpoints.
Some bit locations have different functions, depending on endpoint configuration type or direction, and this is reflected by
using two different names for the bit locations.
18.14.1 STATUS – Status register
Note: 1. For isochronous endpoints.
z Bit 7 – STALL: STALL Flag
This flag is set when an IN or OUT transaction has been responded to with a STALL handshake. This flag is cleared by
writing a one to its bit location.
z Bit 7 – CRC: CRC Error Flag
This flag is set for isochronous output endpoints when a CRC error has been detected in an incoming data packet. This
flag is cleared by writing a one to its bit location.
z Bit 6 – UNF/OVF: Underflow/Overflow Flag
UNF: For input endpoints, the UNF flag is set when an input endpoint is not ready to send data to the host in response of
an IN token.
OVF: For output endpoints, the OVF flag is set when an output endpoint is not ready to accept data from the host
following an OUT token.
z Bit 5 – TRNCOMPL0: Transaction Complete Flag
This flag is set when an IN or OUT transaction has completed successfully. This flag is cleared by writing a one to its bit
location.
z Bit 4 – SETUP: SETUP Transaction Complete Flag
This flag is set when a SETUP, IN, or OUT transaction has completed successfully. This flag is cleared by writing a one
to its bit location.
z Bit 4 – TRNCOMPL1: Transaction Complete Flag
This flag is set when a SETUP, IN, or OUT transaction has completed successfully. This flag is cleared by writing a one
to its bit location.
z Bit 3 – BANK: Bank Select Flag
When ping-pong mode is enabled, this bit indicates which bank will be used for the next transaction. BANK is toggled
each time a transaction has completed successfully. This bit is not sed when ping-pong is disabled. This flag is cleared
by writing a one to its bit location.
z Bit 2 – BUSNACK1: Data Buffer 1 Not Acknowledge Flag
When this flag is set, the USB module will discard incoming data to data buffer 1 in an OUT transaction, and will not
return any data from data buffer 1 in an IN transaction. For control, bulk, and interrupt endpoints, a NAK handshake is
returned. This flag is cleared by writing a one to its bit location.
Bit 7 6 5 4 3 2 1 0
+0x00
STALL
UNF/ OVF TRNCOMPL0
SETUP
BANK BUSNACK1 BUSNACK0 TOGGLE
CRC(1) TRNCOMPL1
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 226
Atmel-8291C-AVR-XMEGA B -09/2014
z Bit 1 – BUSNACK0: Data Buffer 0 Not Acknowledge Flag
When this flag is set, the USB module will discard incoming data to data buffer 0 in an OUT transaction, and will not
return any data from data buffer 0 in an IN transaction. For control, bulk, and interrupt endpoints, a NAK handshake is
returned. This flag is cleared by writing a one to its bit location.
z Bit 0 – TOGGLE: Data Toggle Flag
This indicates if a DATA0 or DATA1 PID is expected in the next data packet for an output endpoint, and if a DATA0 or
DATA1 PID will be sent in the next transaction for an input endpoint. This bit has no effect for isochronous endpoints,
where both DATA0 and DATA1 PIDs are accepted for output endpoint, and only DATA0 PIDs are sent for input
endpoints.
18.14.2 CTRL – Control
Note: 1. For isochronous endpoints.
z Bit 7:6 – TYPE[1:0]: Endpoint Type
These bits are used to enable and select the endpoint type. If the endpoint is disabled, the remaining seven endpoint
configuration bytes are never read or written by the USB module, and their SRAM locations are free to use for other
application data.
Table 18-4. Endpoint type.
z Bit 5 – MULTIPKT: Multipacket Transfer Enable
Setting this bit enables multipacket transfers. Multipacket transfer enables a data payload exceeding the maximum
packet size of an endpoint to be transferred as multiple packets without interrupts or software intervention. See
“Multipacket Transfers” on page 213 for details on multipacket transfers.
z Bit 4 – PINGPONG: Ping-pong Enable
Setting this bit enables ping-pong operation. Ping-pong operation enables both endpoints (IN and OUT) with same
address to be used in the same direction to allow double buffering and maximize throughput. The endpoint in the
opposite direction must be disabled when ping-pong operation is enabled. Ping-pong operation is not possible for control
endpoints. See “Ping-pong Operation” on page 212 for details.
z Bit 3 – INTDSBL: Interrupt Disable
Setting this bit disables all enabled interrupts from the endpoint. Hence, only the interrupt flags in the STATUS register
are updated when interrupt conditions occur. The FIFO does not store this endpoint configuration table address upon
transaction complete for the endpoint when interrupts are disabled for an endpoint. Clearing this bit enables all previously
enables interrupts again.
Bit 7 6 5 4 3 2 1 0
+0x01 TYPE[1:0] MULTIPKT PINGPONG INTDSBL STALL SIZE[1:0]
SIZE[2:0](1)
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
TYPE[1:0] Group Configuration Description
00 DISABLE Endpoint enabled
01 CONTROL Control
10 BULK Bulk/interrupt
11 ISOCHRONOUS Isochronous
XMEGA B [MANUAL] 227
Atmel-8291C-AVR-XMEGA B -09/2014
z Bit 2 – STALL: Endpoint STALL
This bit controls the STALL behavior if the endpoint.
z Bit 1:0 – BUFSIZE[1:0]: Data Size
These bits configure the maximum data payload size for the endpoint. Incoming data bytes exceeding the maximum data
payload size are discarded.
z Bit 2:0 – BUFSIZE[2:0]: Data Size
These bits configure the maximum data payload size for the endpoint when configured for isochronous operation.
Table 18-5. BUFSIZE configuration
Note: 1. Setting only available for isochronous endpoints.
18.14.3 CNTL – Counter Low register
The CNTL and CNTH registers represent the 10-bit value, CNT, that contains the number of bytes received in the last
OUT or SETUP transaction for an OUT endpoint, or the number of bytes to be sent in the next IN transaction for an IN
endpoint.
z Bit 7:0 – CNT[7:0]: Endpoint Byte Counter
This byte contains the eight lsbs of the USB endpoint counter (CNT).
BUFSIZE[2:0] Group Configuration Description
000 8 8-byte buffer size
001 16 16-byte buffer size
010 32 32-byte buffer size
011 64 64-byte buffer size
100(1) 128 128-byte buffer size
101(1) 256 256-byte buffer size
110(1) 512 512-byte buffer size
111(1) 1023 1023-byte buffer size
Bit 7 6 5 4 3 2 1 0
+0x02 CNT[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value XXXXXXXX
XMEGA B [MANUAL] 228
Atmel-8291C-AVR-XMEGA B -09/2014
18.14.4 CNTH – Counter High register
z Bit 6 – AZLP: Automatic Zero Length Packet
When this bit is set, the USB module will manage the ZLP handshake by hardware. This applies to IN endpoints only.
When this bit is zero, the ZLP handshake must be managed by firmware.
z Bit 6:2 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 1:0 – CNT[9:8]: Endpoint Byte Counter
These bits contain the two msbs of the USB endpoint counter (CNT).
18.14.5 DATAPTRL – Data Pointer Low register
The DATAPTRL and DATAPTRH registers represent the 16-bit value, DATAPTR, that contains the SRAM address to the
endpoint data buffer.
z Bit 7:0 – DATAPTR[7:0]: Endpoint Data Pointer Low
This byte contains the eight lsbs of the endpoint data pointer (DATAPTR).
18.14.6 DATAPTRH – Data Pointer High register
z Bit 15:0 - DPTR[15:8]: Endpoint Data Pointer High
This byte contains the eight msbs of the endpoint data pointer (DATAPTR).
Bit 7 6 5 4 3 2 1 0
+0x03 AZLP – – – – – CNT[9:8]
Read/Write R/W R R R R R R/W R/W
Initial Value X X X X X X X X
Bit 7 6 5 4 3 2 1 0
+0x04 DATAPTR[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value X X X X X X X X
Bit 7 6 5 4 3 2 1 0
+0x05 DATAPTR[15:8]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value X X X X X X X X
XMEGA B [MANUAL] 229
Atmel-8291C-AVR-XMEGA B -09/2014
18.14.7 AUXDATAL – Auxiliary Data Low register
The AUXDATAL and AUXDATAH registers represent the 16-bit value, AUXDATA, that is used for multipacket transfers.
For IN endpoints, AUXDATA holds the total number of bytes sent. AUXDATA should be written to zero when setting up a
new transfer. For OUT endpoints, AUXDATA holds the total data size for the complete transfer. This value must be a
multiple of the maximum packet size, except for ISO 1023-byte endpoints.
See “Multipacket Transfers” on page 213 for more details on setting up and using multipacket transfers.
z Bit 7:0 – AUXDATA[7:0]: Auxiliary Data Low
This byte contains the eight lsbs of the auxiliary data (AUXDATA). When multipacket transfer is not used, this SRAM
location is free to use for other application data.
18.14.8 AUXDATAH – Auxiliary Data High register
z Bit 7:0 – AUXDATA[15:8]: Auxiliary Data High
This byte contains the eight msbs of the auxiliary data (AUXDATA). When multipacket transfer is not used, this SRAM
location is free to use for other application data.
Bit 7 6 5 4 3 2 1 0
+0x06 AUXDATA[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value X X X X X X X X
Bit 7 6 5 4 3 2 1 0
+0x07 AUXDATA[15:8]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value X X X X X X X X
XMEGA B [MANUAL] 230
Atmel-8291C-AVR-XMEGA B -09/2014
18.15 Register Description - Frame
18.15.1 FRAMENUML – Frame Number Low register
The FRAMENUML and FRAMENUMH registers represent the 11-bit value, FRAMENUM, that holds the frame number
from the most recently received start of frame packet.
z Bit 7:0 – FRAMENUM[7:0]: Frame Number
This byte contains the eight lsbs of the frame number (FRAMENUM).
18.15.2 FRAMENUMH – Frame Number High register
z Bit 7 – FRAMEERR: Frame Error
This flag is set if a CRC or bit-stuffing error was detected in the most recently received start of frame packet.
z Bit 6:3 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 2:0 – FRAMENUM[10:8]: Frame Number
This byte contains the three msbs of the frame number (FRAMENUM).
Bit 7 6 5 4 3 2 1 0
+0x00 FRAMENUM[7:0]
Read/Write R R R R R R R R
Initial Value 0 0 0 0 0 0 0 0
Bit 7 6 5 4 3 2 1 0
+0x01 FRAMEERR – – – – FRAMENUM[10:8]
Read/Write R R R R R R R R
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 231
Atmel-8291C-AVR-XMEGA B -09/2014
18.16 Register Summary – USB Module
18.17 Register Summary – USB Endpoint
The address to the first configuration byte is (EPPTR[15:0] + 16 × endpoint address) for OUT endpoints and
(EPPTR[15:0] + 16 × endpoint address + 8) for IN endpoints.
18.18 Register Summary – Frame
The address to the frame configuration byte is (MAXEP + 1) << 4. For instance with MAXEP = 3, the first address would
be located at offset address 0x40.
18.19 USB Interrupt Vector Summary
Address Name Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 Page
+0x00 CTRLA ENABLE SPEED FIFOEN STFRNUM MAXEP[3:0] 218
+0x01 CTRLB – – – PULLRST – RWAKEUP GNACK ATTACH 218
+0x02 STATUS – – – – UPRESUM RESUME SUSPEND BUSRST 219
+0x03 ADDR – ADDR[6:0] 219
+0x04 FIFOWP – – – FIFOWP[4:0] 220
+0x05 FIFORP – – – FIFORP[4:0] 220
+0x06 EPPTRL EPPTR[7:0] 220
+0x07 EPPTRH EPPTR[15:8] 221
+0x08 INTCTRLA SOFIE BUSEVIE BUSERRIE STALLIE – – INTLVL[1:0] 221
+0x09 INTCTRLB – – – – – – TRNIE SETUPIE 222
+0x0A INFLAGSACL SOFIF SUSPENDI RESUMEIF RSTIF CRCIF UNFIF OVFIF STALLIF 222
+0x0B INFLAGSASE SOFIF SUSPENDI RESUMEIF RSTIF CRCIF UNFIF OVFIF STALLIF 222
+0x0C INFLAGSBCL – – – – – – TRNIF SETUPIF 223
+0x0D INFLAGSBSE – – – – – – TRNIF SETUPIF 223
+0x0E Reserved – – – – – – – –
+0x0F Reserved – – – – – – – –
+0x10-0X39 Reserved – – – – – – – –
+0x3A CALL CAL[7:0] 223
+0x3B CALH CAL[15:8] 224
Address Name Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 Page
+0x00 STATUS STALL OVF/UNF TRNCOMP
L0
SETUP BANK BUSNACK1 BUSNACK0 TOGGLE 225
CRC TRNCOMP Isochronous
+0x01 CTRL TYPE[1:0] MULTIPKT PINGPONG INTDSB
L
STALL BUFSIZE[1:0] 226
BUFSIZE[2:0] Isochronous
+0x02 CNTL CNT[7:0] 227
+0x03 CNTH AZLP – – – – – CNT[9:8] 228
+0x04 DATAPTR DATAPTR[7:0] 228
+0x05 DATAPTR DATAPTR[15:8] 228
+0x06 AUXDATA AUXDATA[7:0] 229
+0x07 AUXDATA AUXDATA[15:8] 229
Address Name Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 Page
+0x00 FRAMENUM FRAMENUM[7:0] 230
+0x01 FRAMENUM FRAMEER – – – – FRAMENUM[10:8] 230
Offset Source Interrupt Description
0x00 BUSEVENT_vect SOF, suspend, resume, bus reset, CRC, underflow, overflow, and stall error interrupts
0x02 TRNCOMPL_vect Transaction complete interrupt
XMEGA B [MANUAL] 232
Atmel-8291C-AVR-XMEGA B -09/2014
19. TWI – Two-Wire Interface
19.1 Features
z Bidirectional, two-wire communication interface
z Phillips I2
C compatible
z System Management Bus (SMBus) compatible
z Bus master and slave operation supported
z Slave operation
z Single bus master operation
z Bus master in multi-master bus environment
z Multi-master arbitration
z Flexible slave address match functions
z 7-bit and general call address recognition in hardware
z 10-bit addressing supported
z Address mask register for dual address match or address range masking
z Optional software address recognition for unlimited number of addresses
z Slave can operate in all sleep modes, including power-down
z Slave address match can wake device from all sleep modes
z 100kHz and 400kHz bus frequency support
z Slew-rate limited output drivers
z Input filter for bus noise and spike suppression
z Support arbitration between start/repeated start and data bit (SMBus)
z Slave arbitration allows support for address resolve protocol (ARP) (SMBus)
19.2 Overview
The two-wire interface (TWI) is a bidirectional, two-wire communication interface. It is I2
C and System Management Bus
(SMBus) compatible. The only external hardware needed to implement the bus is one pull-up resistor on each bus line.
A device connected to the bus must act as a master or a slave. The master initiates a data transaction by addressing a
slave on the bus and telling whether it wants to transmit or receive data. One bus can have many slaves and one or
several masters that can take control of the bus. An arbitration process handles priority if more than one master tries to
transmit data at the same time. Mechanisms for resolving bus contention are inherent in the protocol.
The TWI module supports master and slave functionality. The master and slave functionality are separated from each
other, and can be enabled and configured separately. The master module supports multi-master bus operation and
arbitration. It contains the baud rate generator. Both 100kHz and 400kHz bus frequency is supported. Quick command
and smart mode can be enabled to auto-trigger operations and reduce software complexity.
The slave module implements 7-bit address match and general address call recognition in hardware. 10-bit addressing is
also supported. A dedicated address mask register can act as a second address match register or as a register for
address range masking. The slave continues to operate in all sleep modes, including power-down mode. This enables
the slave to wake up the device from all sleep modes on TWI address match. It is possible to disable the address
matching to let this be handled in software instead.
The TWI module will detect START and STOP conditions, bus collisions, and bus errors. Arbitration lost, errors, collision,
and clock hold on the bus are also detected and indicated in separate status flags available in both master and slave
modes.
It is possible to disable the TWI drivers in the device, and enable a four-wire digital interface for connecting to an external
TWI bus driver. This can be used for applications where the device operates from a different VCC voltage than used by
the TWI bus.
XMEGA B [MANUAL] 233
Atmel-8291C-AVR-XMEGA B -09/2014
19.3 General TWI Bus Concepts
The TWI provides a simple, bidirectional, two-wire communication bus consisting of a serial clock line (SCL) and a serial
data line (SDA). The two lines are open-collector lines (wired-AND), and pull-up resistors (Rp) are the only external
components needed to drive the bus. The pull-up resistors provide a high level on the lines when none of the connected
devices are driving the bus
The TWI bus is a simple and efficient method of interconnecting multiple devices on a serial bus. A device connected to
the bus can be a master or slave, where the master controls the bus and all communication.
Figure 19-1 on page 233 illustrates the TWI bus topology.
Figure 19-1. TWI bus topology.
A unique address is assigned to all slave devices connected to the bus, and the master will use this to address a slave
and initiate a data transaction.
Several masters can be connected to the same bus, called a multi-master environment. An arbitration mechanism is
provided for resolving bus ownership among masters, since only one master device may own the bus at any given time.
A device can contain both master and slave logic, and can emulate multiple slave devices by responding to more than
one address.
A master indicates the start of a transaction by issuing a START condition (S) on the bus. An address packet with a slave
address (ADDRESS) and an indication whether the master wishes to read or write data (R/W) are then sent. After all
data packets (DATA) are transferred, the master issues a STOP condition (P) on the bus to end the transaction. The
receiver must acknowledge (A) or not-acknowledge (A) each byte received.
Figure 19-2 on page 234 shows a TWI transaction.
TWI
DEVICE #1
RP RP
RS RS
SDA
SCL
VCC
TWI
DEVICE #2
RS RS
TWI
DEVICE #N
RS RS
Note: RS is optional
XMEGA B [MANUAL] 234
Atmel-8291C-AVR-XMEGA B -09/2014
Figure 19-2. Basic TWI transaction diagram topology for a 7-bit address bus.
The master provides the clock signal for the transaction, but a device connected to the bus is allowed to stretch the lowlevel
period of the clock to decrease the clock speed.
19.3.1 Electrical Characteristics
The TWI module in XMEGA devices follows the electrical specifications and timing of I2
C bus and SMBus. These
specifications are not 100% compliant, and so to ensure correct behavior, the inactive bus timeout period should be set
in TWI master mode. Refer to “TWI Master Operation” on page 239 for more details.
19.3.2 START and STOP Conditions
Two unique bus conditions are used for marking the beginning (START) and end (STOP) of a transaction. The master
issues a START condition (S) by indicating a high-to-low transition on the SDA line while the SCL line is kept high. The
master completes the transaction by issuing a STOP condition (P), indicated by a low-to-high transition on the SDA line
while SCL line is kept high.
Figure 19-3. START and STOP conditions.
Multiple START conditions can be issued during a single transaction. A START condition that is not directly following a
STOP condition is called a repeated START condition (Sr).
19.3.3 Bit Transfer
As illustrated by Figure 19-4, a bit transferred on the SDA line must be stable for the entire high period of the SCL line.
Consequently the SDA value can only be changed during the low period of the clock. This is ensured in hardware by the
TWI module.
S ADDRESS P
6 ... 0
R/W ACK ACK
7 ... 0
DATA ACK/NACK
7 ... 0
DATA
SDA
SCL
S ADDRESS R/W A DATA A DATA A/A P
Address Packet Data Packet #0
Transaction
Data Packet #1
Direction
The slave provides data on the bus
The master provides data on the bus
The master or slave can provide data on the bus
SDA
SCL
START
Condition
STOP
Condition
S P
XMEGA B [MANUAL] 235
Atmel-8291C-AVR-XMEGA B -09/2014
Figure 19-4. Data validity.
Combining bit transfers results in the formation of address and data packets. These packets consist of eight data bits
(one byte) with the most-significant bit transferred first, plus a single-bit not-acknowledge (NACK) or acknowledge (ACK)
response. The addressed device signals ACK by pulling the SCL line low during the ninth clock cycle, and signals NACK
by leaving the line SCL high.
19.3.4 Address Packet
After the START condition, a 7-bit address followed by a read/write (R/W) bit is sent. This is always transmitted by the
master. A slave recognizing its address will ACK the address by pulling the data line low for the next SCL cycle, while all
other slaves should keep the TWI lines released and wait for the next START and address. The address, R/W bit, and
acknowledge bit combined is the address packet. Only one address packet for each START condition is allowed, also
when 10-bit addressing is used.
The R/W bit specifies the direction of the transaction. If the R/W bit is low, it indicates a master write transaction, and the
master will transmit its data after the slave has acknowledged its address. If the R/W bit is high, it indicates a master read
transaction, and the slave will transmit its data after acknowledging its address.
19.3.5 Data Packet
An address packet is followed by one or more data packets. All data packets are nine bits long, consisting of one data
byte and an acknowledge bit. The direction bit in the previous address packet determines the direction in which the data
are transferred.
19.3.6 Transaction
A transaction is the complete transfer from a START to a STOP condition, including any repeated START conditions in
between. The TWI standard defines three fundamental transaction modes: Master write, master read, and a combined
transaction.
Figure 19-5 on page 235 illustrates the master write transaction. The master initiates the transaction by issuing a START
condition (S) followed by an address packet with the direction bit set to zero (ADDRESS+W).
Figure 19-5. Master write transaction.
Assuming the slave acknowledges the address, the master can start transmitting data (DATA) and the slave will ACK or
NACK (A/A) each byte. If no data packets are to be transmitted, the master terminates the transaction by issuing a STOP
condition (P) directly after the address packet. There are no limitations to the number of data packets that can be
SDA
SCL
DATA
Valid
Change
Allowed
S ADDRESS W A DATA A DATA A/A P
Address Packet Data Packet
Transaction
N data packets
XMEGA B [MANUAL] 236
Atmel-8291C-AVR-XMEGA B -09/2014
transferred. If the slave signals a NACK to the data, the master must assume that the slave cannot receive any more
data and terminate the transaction.
Figure 19-6 on page 236 illustrates the master read transaction. The master initiates the transaction by issuing a START
condition followed by an address packet with the direction bit set to one (ADDRESS+R). The addressed slave must
acknowledge the address for the master to be allowed to continue the transaction.
Figure 19-6. Master read transaction.
Assuming the slave acknowledges the address, the master can start receiving data from the slave. There are no
limitations to the number of data packets that can be transferred. The slave transmits the data while the master signals
ACK or NACK after each data byte. The master terminates the transfer with a NACK before issuing a STOP condition.
Figure 19-7 illustrates a combined transaction. A combined transaction consists of several read and write transactions
separated by repeated START conditions (Sr).
Figure 19-7. Combined Transaction.
19.3.7 Clock and Clock Stretching
All devices connected to the bus are allowed to stretch the low period of the clock to slow down the overall clock
frequency or to insert wait states while processing data. A device that needs to stretch the clock can do this by
holding/forcing the SCL line low after it detects a low level on the line.
Three types of clock stretching can be defined, as shown in Figure 19-8.
Figure 19-8. Clock stretching(1).
Note: 1. Clock stretching is not supported by all I2
C slaves and masters.
If a slave device is in sleep mode and a START condition is detected, the clock stretching normally works during the
wake-up period. For AVR XMEGA devices, the clock stretching will be either directly before or after the ACK/NACK bit,
as AVR XMEGA devices do not need to wake up for transactions that are not addressed to it.
A slave device can slow down the bus frequency by stretching the clock periodically on a bit level. This allows the slave
to run at a lower system clock frequency. However, the overall performance of the bus will be reduced accordingly. Both
S ADDRESS R A DATA A DATA A P
Transaction
Address Packet Data Packet
N data packets
S ADDRESS R/W A DATA A/A Sr ADDRESS R/W DATA A/A P
Transaction
Address Packet #1 N Data Packets Address Packet #2 M Data Packets
Direction Direction
A
SDA
SCL
S
bit 7 bit 6 bit 0 ACK/NACK
Periodic clock
stretching
Random clock
stretching
Wakeup clock
stretching
XMEGA B [MANUAL] 237
Atmel-8291C-AVR-XMEGA B -09/2014
the master and slave device can randomly stretch the clock on a byte level basis before and after the ACK/NACK bit.
This provides time to process incoming or prepare outgoing data, or perform other time-critical tasks.
In the case where the slave is stretching the clock, the master will be forced into a wait state until the slave is ready, and
vice versa.
19.3.8 Arbitration
A master can start a bus transaction only if it has detected that the bus is idle. As the TWI bus is a multi-master bus, it is
possible that two devices may initiate a transaction at the same time. This results in multiple masters owning the bus
simultaneously. This is solved using an arbitration scheme where the master loses control of the bus if it is not able to
transmit a high level on the SDA line. The masters who lose arbitration must then wait until the bus becomes idle (i.e.,
wait for a STOP condition) before attempting to reacquire bus ownership. Slave devices are not involved in the arbitration
procedure.
Figure 19-9. TWI arbitration.
Figure 19-9 shows an example where two TWI masters are contending for bus ownership. Both devices are able to issue
a START condition, but DEVICE1 loses arbitration when attempting to transmit a high level (bit 5) while DEVICE2 is
transmitting a low level.
Arbitration between a repeated START condition and a data bit, a STOP condition and a data bit, or a repeated START
condition and a STOP condition are not allowed and will require special handling by software.
19.3.9 Synchronization
A clock synchronization algorithm is necessary for solving situations where more than one master is trying to control the
SCL line at the same time. The algorithm is based on the same principles used for the clock stretching previously
described. Figure 19-10 shows an example where two masters are competing for control over the bus clock. The SCL
line is the wired-AND result of the two masters clock outputs.
DEVICE1_SDA
SDA
(wired-AND)
DEVICE2_SDA
SCL
S
bit 7 bit 6 bit 5 bit 4
DEVICE1 Loses arbitration
XMEGA B [MANUAL] 238
Atmel-8291C-AVR-XMEGA B -09/2014
Figure 19-10.Clock synchronization.
A high-to-low transition on the SCL line will force the line low for all masters on the bus, and they will start timing their low
clock period. The timing length of the low clock period can vary among the masters. When a master (DEVICE1 in this
case) has completed its low period, it releases the SCL line. However, the SCL line will not go high until all masters have
released it. Consequently, the SCL line will be held low by the device with the longest low period (DEVICE2). Devices
with shorter low periods must insert a wait state until the clock is released. All masters start their high period when the
SCL line is released by all devices and has gone high. The device which first completes its high period (DEVICE1) forces
the clock line low, and the procedure is then repeated. The result is that the device with the shortest clock period
determines the high period, while the low period of the clock is determined by the device with the longest clock period.
19.4 TWI Bus State Logic
The bus state logic continuously monitors the activity on the TWI bus lines when the master is enabled. It continues to
operate in all sleep modes, including power-down.
The bus state logic includes START and STOP condition detectors, collision detection, inactive bus timeout detection,
and a bit counter. These are used to determine the bus state. Software can get the current bus state by reading the bus
state bits in the master status register. The bus state can be unknown, idle, busy, or owner, and is determined according
to the state diagram shown in Figure 19-11. The values of the bus state bits according to state are shown in binary in the
figure.
DEVICE1_SCL
SCL
(wired-AND)
Wait
State
DEVICE2_SCL
High Period
Count
Low Period
Count
XMEGA B [MANUAL] 239
Atmel-8291C-AVR-XMEGA B -09/2014
Figure 19-11.Bus state, state diagram.
After a system reset and/or TWI master enable, the bus state is unknown. The bus state machine can be forced to enter
idle by writing to the bus state bits accordingly. If no state is set by application software, the bus state will become idle
when the first STOP condition is detected. If the master inactive bus timeout is enabled, the bus state will change to idle
on the occurrence of a timeout. After a known bus state is established, only a system reset or disabling of the TWI master
will set the state to unknown.
When the bus is idle, it is ready for a new transaction. If a START condition generated externally is detected, the bus
becomes busy until a STOP condition is detected. The STOP condition will change the bus state to idle. If the master
inactive bus timeout is enabled, the bus state will change from busy to idle on the occurrence of a timeout.
If a START condition is generated internally while in idle state, the owner state is entered. If the complete transaction was
performed without interference, i.e., no collisions are detected, the master will issue a STOP condition and the bus state
will change back to idle. If a collision is detected, the arbitration is assumed lost and the bus state becomes busy until a
STOP condition is detected. A repeated START condition will only change the bus state if arbitration is lost during the
issuing of the repeated START. Arbitration during repeated START can be lost only if the arbitration has been ongoing
since the first START condition. This happens if two masters send the exact same ADDRESS+DATA before one of the
masters issues a repeated START (Sr).
19.5 TWI Master Operation
The TWI master is byte-oriented, with an optional interrupt after each byte. There are separate interrupts for master write
and master read. Interrupt flags can also be used for polled operation. There are dedicated status flags for indicating
ACK/NACK received, bus error, arbitration lost, clock hold, and bus state.
When an interrupt flag is set, the SCL line is forced low. This will give the master time to respond or handle any data, and
will in most cases require software interaction. Figure 19-12 shows the TWI master operation. The diamond shaped
symbols (SW) indicate where software interaction is required. Clearing the interrupt flags releases the SCL line.
P + Timeout
Write ADDRESS
IDLE
(0b01)
S
BUSY
(0b11)
UNKNOWN
(0b00)
OWNER
(0b10)
Arbitration
Lost
Command P
Write
ADDRESS(Sr)
Sr
(S)
RESET
P + Timeout
XMEGA B [MANUAL] 240
Atmel-8291C-AVR-XMEGA B -09/2014
Figure 19-12.TWI master operation.
The number of interrupts generated is kept to a minimum by automatic handling of most conditions. Quick command and
smart mode can be enabled to auto-trigger operations and reduce software complexity.
19.5.1 Transmitting Address Packets
After issuing a START condition, the master starts performing a bus transaction when the master address register is
written with the 7-bit slave address and direction bit. If the bus is busy, the TWI master will wait until the bus becomes idle
before issuing the START condition.
Depending on arbitration and the R/W direction bit, one of four distinct cases (M1 to M4) arises following the address
packet. The different cases must be handled in software.
19.5.1.1 Case M1: Arbitration lost or bus error during address packet
If arbitration is lost during the sending of the address packet, the master write interrupt flag and arbitration lost flag are
both set. Serial data output to the SDA line is disabled, and the SCL line is released. The master is no longer allowed to
perform any operation on the bus until the bus state has changed back to idle.
A bus error will behave in the same way as an arbitration lost condition, but the error flag is set in addition to the write
interrupt and arbitration lost flags.
19.5.1.2 Case M2: Address packet transmit complete - Address not acknowledged by slave
If no slave device responds to the address, the master write interrupt flag and the master received acknowledge flag are
set. The clock hold is active at this point, preventing further activity on the bus.
19.5.1.3 Case M3: Address packet transmit complete - Direction bit cleared
If the master receives an ACK from the slave, the master write interrupt flag is set and the master received acknowledge
flag is cleared. The clock hold is active at this point, preventing further activity on the bus.
BUSY P IDLE S BUSY
Sr
P
M3
M3
M2
M2
M1
M1
R DATA
ADDRESS
W
DATA A/A
Wait for
IDLE
APPLICATION
SW
SW
Sr
P
M3
M2
SW A BUSY M4
A/A
A/A
A/A
M4
A
IDLE
IDLE
MASTER READ INTERRUPT + HOLD
MASTER WRITE INTERRUPT + HOLD
SW
SW
SW
R/W BUSY
SW Driver software
The master provides data
on the bus
Slave provides data on
the bus
A
A
R/W
BUSY M4
Bus state
Mn Diagram connections
XMEGA B [MANUAL] 241
Atmel-8291C-AVR-XMEGA B -09/2014
19.5.1.4 Case M4: Address packet transmit complete - Direction bit set
If the master receives an ACK from the slave, the master proceeds to receive the next byte of data from the slave. When
the first data byte is received, the master read interrupt flag is set and the master received acknowledge flag is cleared.
The clock hold is active at this point, preventing further activity on the bus.
19.5.2 Transmitting Data Packets
Assuming case M3 above, the master can start transmitting data by writing to the master data register. If the transfer was
successful, the slave will signal with ACK. The master write interrupt flag is set, the master received acknowledge flag is
cleared, and the master can prepare new data to send. During data transfer, the master is continuously monitoring the
bus for collisions.
The received acknowledge flag must be checked by software for each data packet transmitted before the next data
packet can be transferred. The master is not allowed to continue transmitting data if the slave signals a NACK.
If a collision is detected and the master loses arbitration during transfer, the arbitration lost flag is set.
19.5.3 Receiving Data Packets
Assuming case M4 above, the master has already received one byte from the slave. The master read interrupt flag is set,
and the master must prepare to receive new data. The master must respond to each byte with ACK or NACK. Indicating
a NACK might not be successfully executed, as arbitration can be lost during the transmission. If a collision is detected,
the master loses arbitration and the arbitration lost flag is set.
19.6 TWI Slave Operation
The TWI slave is byte-oriented with optional interrupts after each byte. There are separate slave data and address/stop
interrupts. Interrupt flags can also be used for polled operation. There are dedicated status flags for indicating
ACK/NACK received, clock hold, collision, bus error, and read/write direction.
When an interrupt flag is set, the SCL line is forced low. This will give the slave time to respond or handle data, and will in
most cases require software interaction. Figure 19-13. shows the TWI slave operation. The diamond shapes symbols
(SW) indicate where software interaction is required.
Figure 19-13.TWI slave operation.
The number of interrupts generated is kept to a minimum by automatic handling of most conditions. Quick command can
be enabled to auto-trigger operations and reduce software complexity.
Promiscuous mode can be enabled to allow the slave to respond to all received addresses.
S
S3
S2 ADDRESS A
S1
R
W
DATA A/A
DATA
P S2
Sr S3
P S2
Sr S3
SLAVE ADDRESS INTERRUPT SLAVE DATA INTERRUPT
A
Collision
(SMBus)
SW
SW SW
SW
A/A A/A
SW Release
Hold S1
A S1
SW Interrupt on STOP
Condition Enabled
S1
SW Driver software
The master provides data
on the bus
Slave provides data on
the bus
Sn Diagram connections
XMEGA B [MANUAL] 242
Atmel-8291C-AVR-XMEGA B -09/2014
19.6.1 Receiving Address Packets
When the TWI slave is properly configured, it will wait for a START condition to be detected. When this happens, the
successive address byte will be received and checked by the address match logic, and the slave will ACK a correct
address and store the address in the DATA register. If the received address is not a match, the slave will not
acknowledge and store address, and will wait for a new START condition.
The slave address/stop interrupt flag is set when a START condition succeeded by a valid address byte is detected. A
general call address will also set the interrupt flag.
A START condition immediately followed by a STOP condition is an illegal operation, and the bus error flag is set.
The R/W direction flag reflects the direction bit received with the address. This can be read by software to determine the
type of operation currently in progress.
Depending on the R/W direction bit and bus condition, one of four distinct cases (S1 to S4) arises following the address
packet. The different cases must be handled in software.
19.6.1.1 Case S1: Address packet accepted - Direction bit set
If the R/W direction flag is set, this indicates a master read operation. The SCL line is forced low by the slave, stretching
the bus clock. If ACK is sent by the slave, the slave hardware will set the data interrupt flag indicating data is needed for
transmit. Data, repeated START, or STOP can be received after this. If NACK is sent by the slave, the slave will wait for
a new START condition and address match.
19.6.1.2 Case S2: Address packet accepted - Direction bit cleared
If the R/W direction flag is cleared, this indicates a master write operation. The SCL line is forced low, stretching the bus
clock. If ACK is sent by the slave, the slave will wait for data to be received. Data, repeated START, or STOP can be
received after this. If NACK is sent, the slave will wait for a new START condition and address match.
19.6.1.3 Case S3: Collision
If the slave is not able to send a high level or NACK, the collision flag is set, and it will disable the data and acknowledge
output from the slave logic. The clock hold is released. A START or repeated START condition will be accepted.
19.6.1.4 Case S4: STOP condition received.
When the STOP condition is received, the slave address/stop flag will be set, indicating that a STOP condition, and not
an address match, occurred.
19.6.2 Receiving Data Packets
The slave will know when an address packet with R/W direction bit cleared has been successfully received. After
acknowledging this, the slave must be ready to receive data. When a data packet is received, the data interrupt flag is set
and the slave must indicate ACK or NACK. After indicating a NACK, the slave must expect a STOP or repeated START
condition.
19.6.3 Transmitting Data Packets
The slave will know when an address packet with R/W direction bit set has been successfully received. It can then start
sending data by writing to the slave data register. When a data packet transmission is completed, the data interrupt flag
is set. If the master indicates NACK, the slave must stop transmitting data and expect a STOP or repeated START
condition.
19.7 Enabling External Driver Interface
An external driver interface can be enabled. When this is done, the internal TWI drivers with input filtering and slew rate
control are bypassed. The normal I/O pin function is used, and the direction must be configured by the user software.
When this mode is enabled, an external TWI compliant tri-state driver is needed for connecting to a TWI bus.
By default, port pins 0 (Pn0) and 1 (Pn1) are used for SDA and SCL. The external driver interface uses port pins 0 to 3 for
the SDA_IN, SCL_IN, SDA_OUT, and SCL_OUT signals.
XMEGA B [MANUAL] 243
Atmel-8291C-AVR-XMEGA B -09/2014
19.8 Register Description – TWI
19.8.1 CTRL – Common Control Register
z Bit 7:3 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 2:1 – SDAHOLD[1:0]: SDA Hold Time Enable.
Setting these bits to one enables an internal hold time on SDA with respect to the negative edge of SCL.
Table 19-1. SDA hold time.
z Bit 0 – EDIEN: External Driver Interface Enable
Setting this bit enables the use of the external driver interface, and clearing this bit enables normal two-wire mode. See
Table 19-2 for details.
Table 19-2. External driver interface enable.
Bit 7 6 5 4 3 2 1 0
+0x00 – – – – – SDAHOLD[1:0] EDIEN
Read/Write R R R R R R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
SDAHOLD[1:0] Group Configuration Description
00 OFF SDA hold time off
01 50NS Typical 50ns hold time
10 300NS Typical 100ns hold time
11 400NS Typical 400ns hold time
EDIEN Mode Comment
0 Normal TWI Two-pin interface, slew rate control, and input filter.
1 External driver interface Four-pin interface, standard I/O, no slew rate control, and no input
filter.
XMEGA B [MANUAL] 244
Atmel-8291C-AVR-XMEGA B -09/2014
19.9 Register Description – TWI Master
19.9.1 CTRLA – Control register A
z Bit 7:6 – INTLVL[1:0]: Interrupt Level
These bits select the interrupt level for the TWI master interrupt, as described in “Interrupts and Programmable Multilevel
Interrupt Controller” on page 115.
z Bit 5 – RIEN: Read Interrupt Enable
Setting the read interrupt enable (RIEN) bit enables the read interrupt when the read interrupt flag (RIF) in the STATUS
register is set. In addition the INTLVL bits must be nonzero for TWI master interrupts to be generated.
z Bit 4 – WIEN: Write Interrupt Enable
Setting the write interrupt enable (WIEN) bit enables the write interrupt when the write interrupt flag (WIF) in the STATUS
register is set. In addition the INTLVL bits must be nonzero for TWI master interrupts to be generated.
z Bit 3 – ENABLE: Enable TWI Master
Setting the enable TWI master (ENABLE) bit enables the TWI master.
z Bit 2:0 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
19.9.2 CTRLB – Control register B
z Bit 7:4 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 3:2 – TIMEOUT[1:0]: Inactive Bus Timeout
Setting the inactive bus timeout (TIMEOUT) bits to a nonzero value will enable the inactive bus timeout supervisor. If the
bus is inactive for longer than the TIMEOUT setting, the bus state logic will enter the idle state.
Table 19-3 lists the timeout settings.
Bit 7 6 5 4 3 2 1 0
+0x00 INTLVL[1:0] RIEN WIEN ENABLE – – –
Read/Write R/W R/W R/W R/W R/W R R R
Initial Value 0 0 0 0 0 0 0 0
Bit 7 6 5 4 3 2 1 0
+0x01 – – – – TIMEOUT[1:0] QCEN SMEN
Read/Write R R R R R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 245
Atmel-8291C-AVR-XMEGA B -09/2014
Table 19-3. TWI master inactive bus timeout settings.
z Bit 1 – QCEN: Quick Command Enable
When quick command is enabled, the corresponding interrupt flag is set immediately after the slave acknowledges the
address (read or write interrupt). At this point, software can issue either a STOP or a repeated START condition.
z Bit 0 – SMEN: Smart Mode Enable
Setting this bit enables smart mode. When smart mode is enabled, the acknowledge action, as set by the ACKACT bit in
the CTRLC register, is sent immediately after reading the DATA register.
19.9.3 CTRLC – Control register C
z Bits 7:3 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 2 – ACKACT: Acknowledge Action
This bit defines the master's acknowledge behavior in master read mode. The acknowledge action is executed when a
command is written to the CMD bits. If SMEN in the CTRLB register is set, the acknowledge action is performed when
the DATA register is read.
Table 19-4 lists the acknowledge actions.
Table 19-4. ACKACT bit description.
z Bit 1:0 – CMD[1:0]: Command
Writing the command (CMD) bits triggers a master operation as defined by Table 19-5. The CMD bits are strobe bits, and
always read as zero. The acknowledge action is only valid in master read mode (R). In master write mode (W), a
command will only result in a repeated START or STOP condition. The ACKACT bit and the CMD bits can be written at
the same time, and then the acknowledge action will be updated before the command is triggered.
TIMEOUT[1:0] Group Configuration Description
00 DISABLED Disabled, normally used for I2
C
01 50US 50μs, normally used for SMBus at 100kHz
10 100US 100μs
11 200US 200μs
Bit 7 6 5 4 3 2 1 0
+0x02 – – – – – ACKACT CMD[1:0]
Read/Write R R R R R R/W R/W R/W
Initial Value 00000000
ACKACT Action
0 Send ACK
1 Send NACK
XMEGA B [MANUAL] 246
Atmel-8291C-AVR-XMEGA B -09/2014
Table 19-5. CMD bit description.
Writing a command to the CMD bits will clear the master interrupt flags and the CLKHOLD flag.
19.9.4 STATUS – Status register
z Bit 7 – RIF: Read Interrupt Flag
This flag is set when a byte is successfully received in master read mode; i.e., no arbitration was lost or bus error
occurred during the operation. Writing a one to this bit location will clear RIF. When this flag is set, the master forces the
SCL line low, stretching the TWI clock period. Clearing the interrupt flags will release the SCL line.
This flag is also cleared automatically when:
z Writing to the ADDR register
z Writing to the DATA register
z Reading the DATA register
z Writing a valid command to the CMD bits in the CTRLC register
z Bit 6 – WIF: Write Interrupt Flag
This flag is set when a byte is transmitted in master write mode. The flag is set regardless of the occurrence of a bus
error or an arbitration lost condition. WIF is also set if arbitration is lost during sending of a NACK in master read mode,
and if issuing a START condition when the bus state is unknown. Writing a one to this bit location will clear WIF. When
this flag is set, the master forces the SCL line low, stretching the TWI clock period. Clearing the interrupt flags will release
the SCL line.
The flag is also cleared automatically for the same conditions as RIF.
z Bit 5 – CLKHOLD: Clock Hold
This flag is set when the master is holding the SCL line low. This is a status flag and a read-only flag that is set when RIF
or WIF is set. Clearing the interrupt flags and releasing the SCL line will indirectly clear this flag.
The flag is also cleared automatically for the same conditions as RIF.
CMD[1:0] Group Configuration MODE Operation
00 NOACT X Reserved
01 START X Execute acknowledge action succeeded by
repeated START condition
10 BYTEREC
W No operation
R Execute acknowledge action succeeded by a byte
receive
11 STOP X Execute acknowledge action succeeded by issuing
a STOP condition
Bit 7 6 5 4 3 2 1 0
+0x03 RIF WIF CLKHOLD RXACK ARBLOST BUSERR BUSSTATE[1:0]
Read/Write R/W R/W R R R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 247
Atmel-8291C-AVR-XMEGA B -09/2014
z Bit 4 – RXACK: Received Acknowledge
This flag contains the most recently received acknowledge bit from the slave. This is a read-only flag. When read as zero,
the most recent acknowledge bit from the slave was ACK, and when read as one the most recent acknowledge bit was
NACK.
z Bit 3 – ARBLOST: Arbitration Lost
This flag is set if arbitration is lost while transmitting a high data bit or a NACK bit, or while issuing a START or repeated
START condition on the bus. Writing a one to this bit location will clear ARBLOST.
Writing the ADDR register will automatically clear ARBLOST.
z Bit 2 – BUSERR: Bus Error
This flag is set if an illegal bus condition has occurred. An illegal bus condition occurs if a repeated START or a STOP
condition is detected, and the number of received or transmitted bits from the previous START condition is not a multiple
of nine. Writing a one to this bit location will clear BUSERR.
Writing the ADDR register will automatically clear BUSERR.
z Bit 1:0 – BUSSTATE[1:0]: Bus State
These bits indicate the current TWI bus state as defined in Table 19-6. The change of bus state is dependent on bus
activity. Refer to the “TWI Bus State Logic” on page 238.
Table 19-6. TWI master bus state.
Writing 01 to the BUSSTATE bits forces the bus state logic into the idle state. The bus state logic cannot be forced into
any other state. When the master is disabled, and after reset, the bus state logic is disabled and the bus state is
unknown.
19.9.5 BAUD – Baud Rate register
The baud rate (BAUD) register defines the relation between the system clock and the TWI bus clock (SCL) frequency.
The frequency relation can be expressed by using the following equation:
[1]
The BAUD register must be set to a value that results in a TWI bus clock frequency (fTWI) equal or less than 100kHz or
400kHz, depending on which standard the application should comply with. The following equation [2] expresses equation
[1] solved for the BAUD value:
BUSSTATE[1:0] Group Configuration Description
00 UNKNOWN Unknown bus state
01 IDLE Idle bus state
10 OWNER Owner bus state
11 BUSY Busy bus state
Bit 7 6 5 4 3 2 1 0
+0x04 BAUD[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 00000
f TWI
f sys
2(5 + ( ) BAUD ) = ---------------------------------------[Hz]
XMEGA B [MANUAL] 248
Atmel-8291C-AVR-XMEGA B -09/2014
[2]
The BAUD register should be written only while the master is disabled.
19.9.6 ADDR – Address register
When the address (ADDR) register is written with a slave address and the R/W bit while the bus is idle, a START
condition is issued and the 7-bit slave address and the R/W bit are transmitted on the bus. If the bus is already owned
when ADDR is written, a repeated START is issued. If the previous transaction was a master read and no acknowledge
is sent yet, the acknowledge action is sent before the repeated START condition.
After completing the operation and the acknowledge bit from the slave is received, the SCL line is forced low if arbitration
was not lost. WIF is set.
If the bus state is unknown when ADDR is written, WIF is set and BUSERR is set.
All TWI master flags are automatically cleared when ADDR is written. This includes BUSERR, ARBLOST, RIF, and WIF.
The master ADDR can be read at any time without interfering with ongoing bus activity.
19.9.7 DATA – Data register
The data (DATA) register is used when transmitting and receiving data. During data transfer, data are shifted from/to the
DATA register and to/from the bus. This implies that the DATA register cannot be accessed during byte transfers, and
this is prevented by hardware. The DATA register can only be accessed when the SCL line is held low by the master; i.e.,
when CLKHOLD is set.
In master write mode, writing the DATA register will trigger a data byte transfer followed by the master receiving the
acknowledge bit from the slave. WIF and CLKHOLD are set.
In master read mode, RIF and CLKHOLD are set when one byte is received in the DATA register. If smart mode is
enabled, reading the DATA register will trigger the bus operation as set by the ACKACT bit. If a bus error occurs during
reception, WIF and BUSERR are set instead of RIF.
Accessing the DATA register will clear the master interrupt flags and CLKHOLD.
BAUD f sys
2 f TWI
= ---------------- – 5
Bit 7 6 5 4 3 2 1 0
+0x05 ADDR[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
Bit 7 6 5 4 3 2 1 0
+0x06 DATA[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 249
Atmel-8291C-AVR-XMEGA B -09/2014
19.10 Register Description – TWI Slave
19.10.1 CTRLA – Control register A
z Bit 7:6 – INTLVL[1:0]: Interrupt Level
These bits select the interrupt level for the TWI master interrupt, as described in “Interrupts and Programmable Multilevel
Interrupt Controller” on page 115.
z Bit 5 – DIEN: Data Interrupt Enable
Setting the data interrupt enable (DIEN) bit enables the data interrupt when the data interrupt flag (DIF) in the STATUS
register is set. The INTLVL bits must be nonzero for the interrupt to be generated.
z Bit 4 – APIEN: Address/Stop Interrupt Enable
Setting the address/stop interrupt enable (APIEN) bit enables the address/stop interrupt when the address/stop interrupt
flag (APIF) in the STATUS register is set. The INTLVL bits must be nonzero for interrupt to be generated.
z Bit 3 – ENABLE: Enable TWI Slave
Setting this bit enables the TWI slave.
z Bit 2 – PIEN: Stop Interrupt Enable
Setting the this bit will cause APIF in the STATUS register to be set when a STOP condition is detected.
z Bit 1 – PMEN: Promiscuous Mode Enable
By setting the this bit, the slave address match logic responds to all received addresses. If this bit is cleared, the address
match logic uses the ADDR register to determine which address to recognize as its own address.
z Bit 0 – SMEN: Smart Mode Enable
This bit enables smart mode. When Smart mode is enabled, the acknowledge action, as set by the ACKACT bit in the
CTRLB register, is sent immediately after reading the DATA register.
19.10.2 CTRLB – Control register B
z Bit 7:3 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 2 – ACKACT: Acknowledge Action
This bit defines the slave's acknowledge behavior after an address or data byte is received from the master. The
acknowledge action is executed when a command is written to the CMD bits. If the SMEN bit in the CTRLA register is
set, the acknowledge action is performed when the DATA register is read.
Table 19-7 lists the acknowledge actions.
Bit 7 6 5 4 3 2 1 0
+0x00 INTLVL[1:0] DIEN APIEN ENABLE PIEN PMEN SMEN
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0000 0 0
Bit 7 6 5 4 3 2 1 0
+0x01 – – – – – ACKACT CMD[1:0]
Read/Write R R R R R R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 250
Atmel-8291C-AVR-XMEGA B -09/2014
Table 19-7. TWI slave acknowledge actions.
z Bit 1:0 – CMD[1:0]: Command
Writing these bits trigger the slave operation as defined by Table 19-8. The CMD bits are strobe bits and always read as
zero. The operation is dependent on the slave interrupt flags, DIF and APIF. The acknowledge action is only executed
when the slave receives data bytes or address byte from the master.
Table 19-8. TWI slave command.
Writing the CMD bits will automatically clear the slave interrupt flags and CLKHOLD, and release the SCL line. The
ACKACT bit and CMD bits can be written at the same time, and then the acknowledge action will be updated before the
command is triggered.
ACKACT Action
0 Send ACK
1 Send NACK
CMD[1:0] Group Configuration DIR Operation
00 NOACT X No action
01 X Reserved
10 COMPLETE
Used to complete transaction
0 Execute acknowledge action succeeded by waiting for
any START (S/Sr) condition
1 Wait for any START (S/Sr) condition
11 RESPONSE
Used in response to an address byte (APIF is set)
0 Execute acknowledge action succeeded by reception
of next byte
1 Execute acknowledge action succeeded by DIF being
set
Used in response to a data byte (DIF is set)
0 Execute acknowledge action succeeded by waiting for
the next byte
1 No operation
XMEGA B [MANUAL] 251
Atmel-8291C-AVR-XMEGA B -09/2014
19.10.3 STATUS – Status register
z Bit 7 – DIF: Data Interrupt Flag
This flag is set when a data byte is successfully received; i.e., no bus error or collision occurred during the operation.
Writing a one to this bit location will clear DIF. When this flag is set, the slave forces the SCL line low, stretching the TWI
clock period. Clearing the interrupt flags will release the SCL line.
This flag is also cleared automatically when writing a valid command to the CMD bits in the CTRLB register
z Bit 6 – APIF: Address/Stop Interrupt Flag
This flag is set when the slave detects that a valid address has been received, or when a transmit collision is detected. If
the PIEN bit in the CTRLA register is set, a STOP condition on the bus will also set APIF. Writing a one to this bit location
will clear APIF. When set for an address interrupt, the slave forces the SCL line low, stretching the TWI clock period.
Clearing the interrupt flags will release the SCL line.
The flag is also cleared automatically for the same condition as DIF.
z Bit 5 – CLKHOLD: Clock Hold
This flag is set when the slave is holding the SCL line low.This is a status flag and a read-only bit that is set when DIF or
APIF is set. Clearing the interrupt flags and releasing the SCL line will indirectly clear this flag.
z Bit 4 – RXACK: Received Acknowledge
This flag contains the most recently received acknowledge bit from the master. This is a read-only flag. When read as
zero, the most recent acknowledge bit from the maser was ACK, and when read as one, the most recent acknowledge bit
was NACK.
z Bit 3 – COLL: Collision
This flag is set when a slave has not been able to transfer a high data bit or a NACK bit. If a collision is detected, the
slave will commence its normal operation, disable data, and acknowledge output, and no low values will be shifted out
onto the SDA line. Writing a one to this bit location will clear COLL.
The flag is also cleared automatically when a START or repeated START condition is detected.
z Bit 2 – BUSERR: TWI Slave Bus Error
This flag is set when an illegal bus condition occurs during a transfer. An illegal bus condition occurs if a repeated START
or a STOP condition is detected, and the number of bits from the previous START condition is not a multiple of nine.
Writing a one to this bit location will clear BUSERR.
For bus errors to be detected, the bus state logic must be enabled. This is done by enabling the TWI master.
z Bit 1 – DIR: Read/Write Direction
The R/W direction (DIR) flag reflects the direction bit from the last address packet received from a master. When this bit
is read as one, a master read operation is in progress. When read as zero, a master write operation is in progress.
z Bit 0 – AP: Slave Address or Stop
This flag indicates whether a valid address or a STOP condition caused the last setting of APIF in the STATUS register.
Table 19-9. TWI slave address or stop.
Bit 7 6 5 4 3 2 1 0
+0x02 DIF APIF CLKHOLD RXACK COLL BUSERR DIR AP
Read/Write R/W R/W R R R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
AP Description
0 A STOP condition generated the interrupt on APIF
1 Address detection generated the interrupt on APIF
XMEGA B [MANUAL] 252
Atmel-8291C-AVR-XMEGA B -09/2014
19.10.4 ADDR – Address register
The TWI slave address register should be loaded with the 7-bit slave address (in the seven most significant bits of
ADDR) to which the TWI will respond. The lsb of ADDR is used to enable recognition of the general call address (0x00).
z Bit 7:1 – ADDR[7:1]: TWI Slave Address
This register contains the TWI slave address used by the slave address match logic to determine if a master has
addressed the slave. The seven most-significant bits (ADDR[7:1]) represent the slave address.
When using 10-bit addressing, the address match logic only supports hardware address recognition of the first byte of a
10-bit address. By setting ADDR[7:1] = 0b11110nn, ”nn” represents bits 9 and 8 of the slave address. The next byte
received is bits 7 to 0 in the 10-bit address, and this must be handled by software.
When the address match logic detects that a valid address byte is received, APIF is set and the DIR flag is updated.
If the PMEN bit in CTRLA is set, the address match logic responds to all addresses transmitted on the TWI bus. The
ADDR register is not used in this mode.
z Bit 0 – ADDR: General Call Recognition Enable
When ADDR[0] is set, this enables general call address recognition logic so the device can respond to a general address
call that addresses all devices on the bus.
19.10.5 DATA – Data register
The data (DATA) register is used when transmitting and received data. During data transfer, data are shifted from/to the
DATA register and to/from the bus. This implies that the DATA register cannot be accessed during byte transfers, and
this is prevented by hardware. The DATA register can be accessed only when the SCL line is held low by the slave; i.e.,
when CLKHOLD is set.
When a master is reading data from the slave, data to send must be written to the DATA register. The byte transfer is
started when the master starts to clock the data byte from the slave, followed by the slave receiving the acknowledge bit
from the master. DIF and CLKHOLD are set.
When a master writes data to the slave, DIF and CLKHOLD are set when one byte has been received in the DATA
register. If smart mode is enabled, reading the DATA register will trigger the bus operation as set by the ACKACT bit.
Accessing the DATA register will clear the slave interrupt flags and CLKHOLD. When an address match occurs, the
received address will be stored in the DATA register.
Bit 7 6 5 4 3 2 1 0
+0x03 ADDR[7:1] ADDR[0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 000000
Bit 7 6 5 4 3 2 1 0
+0x04 DATA[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 253
Atmel-8291C-AVR-XMEGA B -09/2014
19.10.6 ADDRMASK – Address Mask register
z Bit 7:1 – ADDRMASK[7:1]: Address Mask
These bits can act as a second address match register or as an address mask register, depending on the ADDREN
setting.
If ADDREN is set to zero, ADDRMASK can be loaded with a 7-bit slave address mask. Each bit in ADDRMASK can
mask (disable) the corresponding address bit in the ADDR register. If the mask bit is one, the address match between the
incoming address bit and the corresponding bit in ADDR is ignored; i.e., masked bits will always match.
If ADDREN is set to one, ADDRMASK can be loaded with a second slave address in addition to the ADDR register. In
this mode, the slave will match on two unique addresses, one in ADDR and the other in ADDRMASK.
z Bit 0 – ADDREN: Address Enable
By default, this bit is zero, and the ADDRMASK bits acts as an address mask to the ADDR register. If this bit is set to
one, the slave address match logic responds to the two unique addresses in ADDR and ADDRMASK.
Bit 7 6 5 4 3 2 1 0
+0x05 ADDRMASK[7:1] ADDREN
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 254
Atmel-8291C-AVR-XMEGA B -09/2014
19.11 Register Summary - TWI
19.12 Register Summary - TWI Master
19.13 Register Summary - TWI Slave
19.14 Interrupt Vector Summary
Address Name Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 Page
+0x00 CTRL – – – – – SDAHOLD[1:0] EDIEN 243
+0x01 MASTER Offset address for TWI Master
+0x08 SLAVE Offset address for TWI Slave
Address Name Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 Page
+0x00 CTRLA INTLVL[1:0] RIEN WIEN ENABLE – – – 244
+0x01 CTRLB – – – – TIMEOUT[1:0] QCEN SMEN 244
+0x02 CTRLC – – – – – ACKACT CMD[1:0] 245
+0x03 STATUS RIF WIF CLKHOLD RXACK ARBLOST BUSERR BUSSTATE[1:0] 246
+0x04 BAUD BAUD[7:0] 247
+0x05 ADDR ADDR[7:0] 248
+0x06 DATA DATA[7:0] 248
Address Name Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 Page
+0x00 CTRLA INTLVL[1:0] DIEN APIEN ENABLE PIEN TPMEN SMEN 249
+0x01 CTRLB – – – – – ACKACT CMD[1:0] 249
+0x02 STATUS DIF APIF CLKHOLD RXACK COLL BUSERR DIR AP 251
+0x03 ADDR ADDR[7:0] 252
+0x04 DATA DATA[7:0] 252
+0x05 ADDRMAS ADDRMASK[7:1] ADDREN 253
Offset Source Interrupt Description
0x00 SLAVE_vect TWI slave interrupt vector
0x02 MASTER_vect TWI master interrupt vector
XMEGA B [MANUAL] 255
8291C–AVR–09/2014
20. SPI – Serial Peripheral Interface
20.1 Features
z Full-duplex, three-wire synchronous data transfer
z Master or slave operation
z Lsb first or msb first data transfer
z Eight programmable bit rates
z Interrupt flag at the end of transmission
z Write collision flag to indicate data collision
z Wake up from idle sleep mode
z Double speed master mode
20.2 Overview
The Serial Peripheral Interface (SPI) is a high-speed synchronous data transfer interface using three or four pins. It
allows fast communication between an XMEGA device and peripheral devices or between several microcontrollers. The
SPI supports full-duplex communication.
A device connected to the bus must act as a master or slave.The master initiates and controls all data transactions. The
interconnection between master and slave devices with SPI is shown in Figure 20-1 on page 255. The system consists of
two shift registers and a master clock generator. The SPI master initiates the communication cycle by pulling the slave
select (SS) signal low for the desired slave. Master and slave prepare the data to be sent in their respective shift
registers, and the master generates the required clock pulses on the SCK line to interchange data. Data are always
shifted from master to slave on the master output, slave input (MOSI) line, and from slave to master on the master input,
slave output (MISO) line. After each data packet, the master can synchronize the slave by pulling the SS line high.
Figure 20-1. SPI master-slave interconnection.
The SPI module is unbuffered in the transmit direction and single buffered in the receive direction. This means that bytes
to be transmitted cannot be written to the SPI DATA register before the entire shift cycle is completed. When receiving
data, a received character must be read from the DATA register before the next character has been completely shifted in.
Otherwise, the first byte will be lost.
In SPI slave mode, the control logic will sample the incoming signal on the SCK pin. To ensure correct sampling of this
clock signal, the minimum low and high periods must each be longer than two CPU clock cycles.
When the SPI module is enabled, the data direction of the MOSI, MISO, SCK, and SS pins is overridden according to
Table 20-1. The pins with user-defined direction must be configured from software to have the correct direction according
to the application.
SHIFT
ENABLE
XMEGA B [MANUAL] 256
8291C–AVR–09/2014
Table 20-1. SPI pin override and directions.
20.3 Master Mode
In master mode, the SPI interface has no automatic control of the SS line. If the SS pin is used, it must be configured as
output and controlled by user software. If the bus consists of several SPI slaves and/or masters, a SPI master can use
general purpose I/O pins to control the SS line to each of the slaves on the bus.
Writing a byte to the DATA register starts the SPI clock generator and the hardware shifts the eight bits into the selected
slave. After shifting one byte, the SPI clock generator stops and the SPI interrupt flag is set. The master may continue to
shift the next byte by writing new data to the DATA register, or can signal the end of the transfer by pulling the SS line
high. The last incoming byte will be kept in the buffer register.
If the SS pin is not used and is configured as input, it must be held high to ensure master operation. If the SS pin is set as
input and is being driven low, the SPI module will interpret this as another master trying to take control of the bus. To
avoid bus contention, the master will take the following action:
1. The master enters slave mode.
2. The SPI interrupt flag is set.
20.4 Slave Mode
In slave mode, the SPI module will remain sleeping with the MISO line tri-stated as long as the SS pin is driven high. In
this state, software may update the contents of the DATA register, but the data will not be shifted out by incoming clock
pulses on the SCK pin until the SS pin is driven low. If SS is driven low, the slave will start to shift out data on the first
SCK clock pulse. When one byte has been completely shifted, the SPI interrupt flag is set. The slave may continue
placing new data to be sent into the DATA register before reading the incoming data. The last incoming byte will be kept
in the buffer register.
When SS is driven high, the SPI logic is reset, and the SPI slave will not receive any new data. Any partially received
packet in the shift register will be dropped.
As the SS pin is used to signal the start and end of a transfer, it is also useful for doing packet/byte synchronization,
keeping the slave bit counter synchronous with the master clock generator.
20.5 Data Modes
There are four combinations of SCK phase and polarity with respect to serial data. The SPI data transfer formats are
shown in Figure 20-2. Data bits are shifted out and latched in on opposite edges of the SCK signal, ensuring sufficient
time for data signals to stabilize.
The leading edge is the first clock edge of a clock cycle. The trailing edge is the last clock edge of a clock cycle.
Pin Master Mode Slave Mode
MOSI User defined Input
MISO Input User defined
SCK User defined Input
SS User defined Input
XMEGA B [MANUAL] 257
8291C–AVR–09/2014
Figure 20-2. SPI transfer modes.
20.6 DMA Support
DMA support on the SPI module is available only in slave mode. The SPI slave can trigger a DMA transfer as one byte
has been shifted into the DATA register. It is possible, however, to use the XMEGA USART in SPI mode and then have
DMA support in master mode. For details, refer to “USART in Master SPI Mode” on page 273.
Bit 1
Bit 6
LSB
MSB
Mode 0
SAMPLE I
MOSI/MISO
CHANGE 0
MOSI PIN
CHANGE 0
MISO PIN
Mode 2
SS
MSB
LSB
Bit 6
Bit 1
Bit 5
Bit 2
Bit 4
Bit 3
Bit 3
Bit 4
Bit 2
Bit 5
MSB first (DORD = 0)
LSB first (DORD = 1)
Mode 1
SAMPLE I
MOSI/MISO
CHANGE 0
MOSI PIN
CHANGE 0
MISO PIN
Mode 3
SS
MSB
LSB
Bit 6
Bit 1
Bit 5
Bit 2
Bit 4
Bit 3
Bit 3
Bit 4
Bit 2
Bit 5
Bit 1
Bit 6
LSB
MSB
MSB first (DORD = 0)
LSB first (DORD = 1)
XMEGA B [MANUAL] 258
8291C–AVR–09/2014
20.7 Register Description
20.7.1 CTRL – Control register
z Bit 7 – CLK2X: Clock Double
When this bit is set, the SPI speed (SCK frequency) will be doubled in master mode (see Table 20-3 on page 259).
z Bit 6 – ENABLE: Enable
Setting this bit enables the SPI module. This bit must be set to enable any SPI operations.
z Bit 5 – DORD: Data Order
DORD decides the data order when a byte is shifted out from the DATA register. When DORD is written to one, the leastsignificant
bit (lsb) of the data byte is transmitted first, and when DORD is written to zero, the most-significant bit (msb) of
the data byte is transmitted first.
z Bit 4 – MASTER: Master Select
This bit selects master mode when written to one, and slave mode when written to zero. If SS is configured as an input
and driven low while master mode is set, master mode will be cleared.
z Bit 3:2 – MODE[1:0]: Transfer Mode
These bits select the transfer mode. The four combinations of SCK phase and polarity with respect to the serial data are
shown in Table 20-2. These bits decide whether the first edge of a clock cycle (leading edge) is rising or falling, and
whether data setup and sample occur on the leading or trailing edge.
When the leading edge is rising, the SCK signal is low when idle, and when the leading edge is falling, the SCK signal is
high when idle.
Table 20-2. SPI transfer mode
z Bits 1:0 – PRESCALER[1:0]: Clock Prescaler
These two bits control the SPI clock rate configured in master mode. These bits have no effect in slave mode. The
relationship between SCK and the peripheral clock frequency ( clkPER) is shown in Table 20-3.
Bit 7 6 5 4 3 2 1 0
+0x00 CLK2X ENABLE DORD MASTER MODE[1:0] PRESCALER[1:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
MODE[1:0] Group Configuration Leading Edge Trailing Edge
00 0 Rising, sample Falling, setup
01 1 Rising, setup Falling, sample
10 2 Falling, sample Rising, setup
11 3 Falling, setup Rising, sample
XMEGA B [MANUAL] 259
8291C–AVR–09/2014
Table 20-3. Relationship between SCK and the peripheral clock (ClkPER) frequency.
20.7.2 INTCTRL – Interrupt Control register
z Bit 7:2 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 1:0 – INTLVL[1:0]: Interrupt Level
These bits enable the SPI interrupt and select the interrupt level, as described in “Interrupts and Programmable Multilevel
Interrupt Controller” on page 115. The enabled interrupt will be triggered when IF in the STATUS register is set.
20.7.3 STATUS – Status register
z Bit 7 – IF: Interrupt Flag
This flag is set when a serial transfer is complete and one byte is completely shifted in/out of the DATA register. If SS is
configured as input and is driven low when the SPI is in master mode, this will also set this flag. IF is cleared by hardware
when executing the corresponding interrupt vector. Alternatively, the IF flag can be cleared by first reading the STATUS
register when IF is set, and then accessing the DATA register.
z Bit 6 – WRCOL: Write Collision Flag
The WRCOL flag is set if the DATA register is written during a data transfer. This flag is cleared by first reading the
STATUS register when WRCOL is set, and then accessing the DATA register.
z Bit 5:0 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
CLK2X PRESCALER[1:0] SCK Frequency
0 00 ClkPER/4
0 01 ClkPER/16
0 10 ClkPER/64
0 11 ClkPER/128
1 00 ClkPER/2
1 01 ClkPER/8
1 10 ClkPER/32
1 11 ClkPER/64
Bit 7 6 5 4 3 2 1 0
+0x01 – – – – – – INTLVL[1:0]
Read/Write R R R R R R R/W R/W
Initial Value 0 0 0 0 0 0 0 0
Bit 7 6 5 4 3 2 1 0
+0x02 IF WRCOL – – – – – –
Read/Write R R R R R R R R
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 260
8291C–AVR–09/2014
20.7.4 DATA – Data register
The DATA register is used for sending and receiving data. Writing to the register initiates the data transmission, and the
byte written to the register will be shifted out on the SPI output line. Reading the register causes the shift register receive
buffer to be read, returning the last byte successfully received.
20.8 Register Summary
20.9 Interrupt vector Summary
Bit 7 6 5 4 3 2 1 0
+0x03 DATA[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
Address Name Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 Page
+0x00 CTRL CLK2X ENABLE DORD MASTER MODE[1:0] PRESCALER[1:0] 258
+0x01 INTCTRL – – – – – – INTLVL[1:0] 259
+0x02 STATUS IF WRCOL – – – – – – 259
+0x03 DATA DATA[7:0] 260
Offset Source Interrupt Description
0x00 SPI_vect SPI interrupt vector
XMEGA B [MANUAL] 261
8291C–AVR–09/2014
21. USART
21.1 Features
z Full-duplex operation
z Asynchronous or synchronous operation
z Synchronous clock rates up to 1/2 of the device clock frequency
z Asynchronous clock rates up to 1/8 of the device clock frequency
z Supports serial frames with 5, 6, 7, 8, or 9 data bits and 1 or 2 stop bits
z Fractional baud rate generator
z Can generate desired baud rate from any system clock frequency
z No need for external oscillator with certain frequencies
z Built-in error detection and correction schemes
z Odd or even parity generation and parity check
z Data overrun and framing error detection
z Noise filtering includes false start bit detection and digital low-pass filter
z Separate interrupts for
z Transmit complete
z Transmit data register empty
z Receive complete
z Multiprocessor communication mode
z Addressing scheme to address a specific devices on a multi-device bus
z Enable unaddressed devices to automatically ignore all frames
z Master SPI mode
z Double buffered operation
z Configurable data order
z Operation up to 1/2 of the peripheral clock frequency
z IRCOM module for IrDA compliant pulse modulation/demodulation
21.2 Overview
The universal synchronous and asynchronous serial receiver and transmitter (USART) is a fast and flexible serial
communication module. The USART supports full-duplex communication and asynchronous and synchronous operation.
The USART can be configured to operate in SPI master mode and used for SPI communication.
Communication is frame based, and the frame format can be customized to support a wide range of standards. The
USART is buffered in both directions, enabling continued data transmission without any delay between frames. Separate
interrupts for receive and transmit complete enable fully interrupt driven communication. Frame error and buffer overflow
are detected in hardware and indicated with separate status flags. Even or odd parity generation and parity check can
also be enabled.
A block diagram of the USART is shown in Figure 21-1 on page 262. The main functional blocks are the clock generator,
the transmitter, and the receiver, which are indicated in dashed boxes.
XMEGA B [MANUAL] 262
8291C–AVR–09/2014
Figure 21-1. USART block diagram.
The clock generator includes a fractional baud rate generator that is able to generate a wide range of USART baud rates
from any system clock frequencies. This removes the need to use an external crystal oscillator with a specific frequency
to achieve a required baud rate. It also supports external clock input in synchronous slave operation.
The transmitter consists of a single write buffer (DATA), a shift register, and a parity generator. The write buffer allows
continuous data transmission without any delay between frames.
The receiver consists of a two-level receive buffer (DATA) and a shift register. Data and clock recovery units ensure
robust synchronization and noise filtering during asynchronous data reception. It includes frame error, buffer overflow,
and parity error detection.
When the USART is set in master SPI mode, all USART-specific logic is disabled, leaving the transmit and receive
buffers, shift registers, and baud rate generator enabled. Pin control and interrupt generation are identical in both modes.
The registers are used in both modes, but their functionality differs for some control settings.
An IRCOM module can be enabled for one USART to support IrDA 1.4 physical compliant pulse modulation and
demodulation for baud rates up to 115.2kbps. For details, refer to “IRCOM - IR Communication Module” on page 282.
21.3 Clock Generation
The clock used for baud rate generation and for shifting and sampling data bits is generated internally by the fractional
baud rate generator or externally from the transfer clock (XCK) pin. Five modes of clock generation are supported:
normal and double-speed asynchronous mode, master and slave synchronous mode, and master SPI mode.
PARITY
GENERATOR
BSEL [H:L]
DATA (Transmit)
CTRLA CTRLB CTRLC
BAUD RATE GENERATOR
FRACTIONAL DIVIDE
TRANSMIT SHIFT REGISTER
RECEIVE SHIFT REGISTER RxD
TxD PIN
CONTROL
DATA (Receive)
PIN
CONTROL
XCK
DATA
RECOVERY
CLOCK
RECOVERY
PIN
CONTROL
TX
CONTROL
RX
CONTROL
PARITY
CHECKER
DATA BUS
OSC
SYNC LOGIC
Clock Generator
Transmitter
Receiver
XMEGA B [MANUAL] 263
8291C–AVR–09/2014
Figure 21-2. Clock generation logic, block diagram.
21.3.1 Internal Clock Generation - The Fractional Baud Rate Generator
The fractional baud rate generator is used for internal clock generation for asynchronous modes, synchronous master
mode, and master SPI mode operation. The output frequency generated (fBAUD) is determined by the period setting
(BSEL), an optional scale setting (BSCALE), and the peripheral clock frequency (fPER). Table 21-1 contains equations for
calculating the baud rate (in bits per second) and for calculating the BSEL value for each mode of operation. It also
shows the maximum baud rate versus peripheral clock frequency. BSEL can be set to any value between 0 and 4095.
BSCALE can be set to any value between -7 and +7, and increases or decreases the baud rate slightly to provide the
fractional baud rate scaling of the baud rate generator.
When BSEL is 0, BSCALE must also be 0. Also, the value 2ABS(BSCALE) must at most be one half of the minimum number
of clock cycles a frame requires. For more details, see “Fractional Baud Rate Generation” on page 271.
Table 21-1. Equations for calculating baud rate register settings.
Note: 1. The baud rate is defined to be the transfer rate in bits per second (bps)
Baud Rate
Generator /2
BSEL
/4 /2
Sync
Register
fOSC
XCK
Pin
txclk
CLK2X
UMSEL [1]
DDR_XCK
0
1
0
1
xcki
xcko
DDR_XCK rxclk 0
1
1
0
Edge
Detector
PORT_INV
fBAUD
Operating Mode Conditions Baud Rate(1) Calculation BSEL Value Calculation
Asynchronous normal
speed mode (CLK2X = 0)
BSCALE ≥ 0
BSCALE < 0
Asynchronous double
speed mode (CLK2X = 1)
BSCALE ≥ 0
BSCALE < 0
Synchronous and master
SPI mode
f BAUD
f PER
16
≤ ------------- f BAUD
f PER
2
BSCALE ⋅ 16(BSEL + 1)
= ------------------------------------------------------------ BSEL f PER
2
BSCALE ⋅ 16 f BAUD
= -------------------------------------------------- – 1
f BAUD
f PER
16
≤ ------------- f BAUD
f PER
16((2BSCALE ⋅ BSEL ) + 1)
= ------------------------------------------------------------------ BSEL 1
2
BSCALE
--------------------- f PER
16 f BAUD
----------------------- – 1 ⎝ ⎠ ⎛ ⎞ =
f BAUD
f PER
8
≤ ------------- f BAUD
f PER
2
BSCALE ⋅ ⋅ 8 ( ) BSEL + 1
= -------------------------------------------------------------- BSEL f PER
2
BSCALE ⋅ 8 f BAUD
= ----------------------------------------------- – 1
f BAUD
f PER
8
≤ ------------- f BAUD
f PER
8((2BSCALE ⋅ BSEL ) + 1)
= --------------------------------------------------------------- BSEL 1
2
BSCALE
--------------------- f PER
8 f BAUD
-------------------- – 1 ⎝ ⎠ ⎛ ⎞ =
f BAUD
f PER
2
< ------------- f BAUD
f PER
2 ⋅ ( ) BSEL + 1 = ------------------------------------ BSEL f PER
2 f BAUD
= -------------------- – 1
XMEGA B [MANUAL] 264
8291C–AVR–09/2014
For BSEL=0, all baud rates must be achieved by changing BSEL instead of setting BSCALE:
BSEL = (2 BSCALE-1)
21.3.2 External Clock
External clock (XCK) is used in synchronous slave mode operation. The XCK clock input is sampled on the peripheral
clock frequency (fPER), and the maximum XCK clock frequency (fXCK)is limited by the following:
For each high and low period, XCK clock cycles must be sampled twice by the peripheral clock. If the XCK clock has
jitter, or if the high/low period duty cycle is not 50/50, the maximum XCK clock speed must be reduced or the peripheral
clock must be increased accordingly.
21.3.3 Double Speed Operation
Double speed operation allows for higher baud rates under asynchronous operation with lower peripheral clock
frequencies. When this is enabled, the baud rate for a given asynchronous baud rate setting shown in Table 21-1 on
page 263 will be doubled. In this mode, the receiver will use half the number of samples (reduced from 16 to 8) for data
sampling and clock recovery. Due to the reduced sampling, a more accurate baud rate setting and peripheral clock are
required. See “Asynchronous Data Reception” on page 268 for more details.
21.3.4 Synchronous Clock Operation
When synchronous mode is used, the XCK pin controls whether the transmission clock is input (slave mode) or output
(master mode). The corresponding port pin must be set to output for master mode or to input for slave mode. The normal
port operation of the XCK pin will be overridden. The dependency between the clock edges and data sampling or data
change is the same. Data input (on RxD) is sampled at the XCK clock edge which is opposite the edge where data output
(TxD) is changed.
BSCALE BSEL BSCALE BSEL
1 0 → 0 1
2 0 → 0 3
3 0 → 0 7
4 0 → 0 15
5 0 → 0 31
6 0 → 0 63
7 0 → 0 127
f XCK
f PER
4
< -------------
XMEGA B [MANUAL] 265
8291C–AVR–09/2014
Figure 21-3. Synchronous mode XCK timing.
Using the inverted I/O (INVEN) setting for the corresponding XCK port pin, the XCK clock edges used for data sampling
and data change can be selected. If inverted I/O is disabled (INVEN=0), data will be changed at the rising XCK clock
edge and sampled at the falling XCK clock edge. If inverted I/O is enabled (INVEN=1), data will be changed at the falling
XCK clock edge and sampled at the rising XCK clock edge. For more details, see “I/O Ports” on page 123.
21.3.5 Master SPI Mode Clock Generation
For master SPI mode operation, only internal clock generation is supported. This is identical to the USART synchronous
master mode, and the baud rate or BSEL setting is calculated using the same equations (see Table 21-1 on page 263).
There are four combinations of the SPI clock (SCK) phase and polarity with respect to the serial data, and these are
determined by the clock phase (UCPHA) control bit and the inverted I/O pin (INVEN) settings. The data transfer timing
diagrams are shown in Figure 21-4 on page 266. Data bits are shifted out and latched in on opposite edges of the XCK
signal, ensuring sufficient time for data signals to stabilize. The UCPHA and INVEN settings are summarized in Table 21-
2. Changing the setting of any of these bits during transmission will corrupt both the receiver and transmitter
Table 21-2. INVEN and UCPHA functionality.
The leading edge is the first clock edge of a clock cycle. The trailing edge is the last clock edge of a clock cycle.
RxD / TxD
XCK
RxD / TxD
UCPOL = 0 XCK
UCPOL = 1
Sample
Sample
SPI Mode INVEN UCPHA Leading Edge Trailing Edge
0 0 0 Rising, sample Falling, setup
1 0 1 Rising, setup Falling, sample
2 1 0 Falling, sample Rising, setup
3 1 1 Falling, setup Rising, sample
XMEGA B [MANUAL] 266
8291C–AVR–09/2014
Figure 21-4. UCPHA and INVEN data transfer timing diagrams.
21.4 Frame Formats
Data transfer is frame based, where a serial frame consists of one character of data bits with synchronization bits (start
and stop bits) and an optional parity bit for error checking. Note that this does not apply to master SPI operation (See
“SPI Frame Formats” on page 267). The USART accepts all combinations of the following as valid frame formats:
z 1 start bit
z 5, 6, 7, 8, or 9 data bits
z no, even, or odd parity bit
z 1 or 2 stop bits
A frame starts with the start bit, followed by all the data bits (least-significant bit first and most-significant bit last). If
enabled, the parity bit is inserted after the data bits, before the first stop bit. One frame can be directly followed by a start
bit and a new frame, or the communication line can return to the idle (high) state. Figure 21-5 on page 266 illustrates the
possible combinations of frame formats. Bits inside brackets are optional.
Figure 21-5. Frame formats.
21.4.1 Parity Bit Calculation
Even or odd parity can be selected for error checking. If even parity is selected, the parity bit is set to one if the number of
logical one data bits is odd (making the total number of ones even). If odd parity is selected, the parity bit is set to one if
the number of logical one data bits is even (making the total number of ones odd).
XCK
Data setup (TXD)
Data sample (RXD)
XCK
Data setup (TXD)
Data sample (RXD)
XCK
Data setup (TXD)
Data sample (RXD)
XCK
Data setup (TXD)
Data sample (RXD)
UCPOL=0 UCPOL=1
UCPHA=0 UCPHA=1
St Start bit, always low.
(n) Data bits (0 to 8).
P Parity bit, may be odd or even.
Sp Stop bit, always high.
IDLE No transfers on the communication line (RxD or TxD). The IDLE state is always high.
(IDLE) St Sp1 [Sp2] 0 2 3 4 [5] [6] [7] [8] [P] 1 (St / IDLE)
FRAME
XMEGA B [MANUAL] 267
8291C–AVR–09/2014
21.4.2 SPI Frame Formats
The serial frame in SPI mode is defined to be one character of eight data bits. The USART in master SPI mode has two
selectable frame formats:
z 8-bit data, msb first
z 8-bit data, lsb first
After a complete, 8-bit frame is transmitted, a new frame can directly follow it, or the communication line can return to the
idle (high) state.
21.5 USART Initialization
USART initialization should use the following sequence:
1. Set the TxD pin value high, and optionally set the XCK pin low.
2. Set the TxD and optionally the XCK pin as output.
3. Set the baud rate and frame format.
4. Set the mode of operation (enables XCK pin output in synchronous mode).
5. Enable the transmitter or the receiver, depending on the usage.
For interrupt-driven USART operation, global interrupts should be disabled during the initialization.
Before doing a re-initialization with a changed baud rate or frame format, be sure that there are no ongoing transmissions
while the registers are changed.
21.6 Data Transmission - The USART Transmitter
When the transmitter has been enabled, the normal port operation of the TxD pin is overridden by the USART and given
the function as the transmitter's serial output. The direction of the pin must be set as output using the direction register for
the corresponding port. For details on port pin control and output configuration, refer to “I/O Ports” on page 123.
21.6.1 Sending Frames
A data transmission is initiated by loading the transmit buffer (DATA) with the data to be sent. The data in the transmit
buffer are moved to the shift register when the shift register is empty and ready to send a new frame. The shift register is
loaded if it is in idle state (no ongoing transmission) or immediately after the last stop bit of the previous frame is
transmitted. When the shift register is loaded with data, it will transfer one complete frame.
The transmit complete interrupt flag (TXCIF) is set and the optional interrupt is generated when the entire frame in the
shift register has been shifted out and there are no new data present in the transmit buffer.
The transmit data register (DATA) can only be written when the data register empty flag (DREIF) is set, indicating that the
register is empty and ready for new data.
When using frames with fewer than eight bits, the most-significant bits written to DATA are ignored. If 9-bit characters are
used, the ninth bit must be written to the TXB8 bit before the low byte of the character is written to DATA.
21.6.2 Disabling the Transmitter
A disabling of the transmitter will not become effective until ongoing and pending transmissions are completed; i.e., when
the transmit shift register and transmit buffer register do not contain data to be transmitted. When the transmitter is
disabled, it will no longer override the TxDn pin, and the pin direction is set as input automatically by hardware, even if it
was configured as output by the user.
21.7 Data Reception - The USART Receiver
When the receiver is enabled, the RxD pin functions as the receiver's serial input. The direction of the pin must be set as
input, which is the default pin setting.
XMEGA B [MANUAL] 268
8291C–AVR–09/2014
21.7.1 Receiving Frames
The receiver starts data reception when it detects a valid start bit. Each bit that follows the start bit will be sampled at the
baud rate or XCK clock and shifted into the receive shift register until the first stop bit of a frame is received. A second
stop bit will be ignored by the receiver. When the first stop bit is received and a complete serial frame is present in the
receive shift register, the contents of the shift register will be moved into the receive buffer. The receive complete
interrupt flag (RXCIF) is set, and the optional interrupt is generated.
The receiver buffer can be read by reading the data register (DATA) location. DATA should not be read unless the
receive complete interrupt flag is set. When using frames with fewer than eight bits, the unused most-significant bits are
read as zero. If 9-bit characters are used, the ninth bit must be read from the RXB8 bit before the low byte of the
character is read from DATA.
21.7.2 Receiver Error Flags
The USART receiver has three error flags. The frame error (FERR), buffer overflow (BUFOVF) and parity error (PERR)
flags are accessible from the status register. The error flags are located in the receive FIFO buffer together with their
corresponding frame. Due to the buffering of the error flags, the status register must be read before the receive buffer
(DATA), since reading the DATA location changes the FIFO buffer.
21.7.3 Parity Checker
When enabled, the parity checker calculates the parity of the data bits in incoming frames and compares the result with
the parity bit of the corresponding frame. If a parity error is detected, the parity error flag is set.
21.7.4 Disabling the Receiver
A disabling of the receiver will be immediate. The receiver buffer will be flushed, and data from ongoing receptions will be
lost.
21.7.5 Flushing the Receive Buffer
If the receive buffer has to be flushed during normal operation, read the DATA location until the receive complete
interrupt flag is cleared.
21.8 Asynchronous Data Reception
The USART includes a clock recovery and a data recovery unit for handling asynchronous data reception. The clock
recovery unit is used for synchronizing the incoming asynchronous serial frames at the RxD pin to the internally
generated baud rate clock. It samples and low-pass filters each incoming bit, thereby improving the noise immunity of the
receiver. The asynchronous reception operational range depends on the accuracy of the internal baud rate clock, the
rate of the incoming frames, and the frame size in number of bits.
21.8.1 Asynchronous Clock Recovery
The clock recovery unit synchronizes the internal clock to the incoming serial frames. Figure 21-6 on page 269 illustrates
the sampling process for the start bit of an incoming frame. The sample rate is 16 times the baud rate for normal mode,
and eight times the baud rate for double speed mode. The horizontal arrows illustrate the synchronization variation due
to the sampling process. Note the larger time variation when using the double speed mode of operation. Samples
denoted as zero are samples done when the RxD line is idle; i.e., when there is no communication activity.
XMEGA B [MANUAL] 269
8291C–AVR–09/2014
Figure 21-6. Start bit sampling.
When the clock recovery logic detects a high (idle) to low (start) transition on the RxD line, the start bit detection
sequence is initiated. Sample 1 denotes the first zero-sample, as shown in the figure. The clock recovery logic then uses
samples 8, 9, and 10 for normal mode and samples 4, 5, and 6 for double speed mode to decide if a valid start bit is
received. If two or three samples have a low level, the start bit is accepted. The clock recovery unit is synchronized, and
the data recovery can begin. If two or three samples have a high level, the start bit is rejected as a noise spike, and the
receiver looks for the next high-to-low transition. The process is repeated for each start bit.
21.8.2 Asynchronous Data Recovery
The data recovery unit uses sixteen samples in normal mode and eight samples in double speed mode for each bit.
Figure 21-7 on page 269 shows the sampling process of data and parity bits.
Figure 21-7. Sampling of data and parity bits.
As for start bit detection, an identical majority voting technique is used on the three center samples for deciding of the
logic level of the received bit. The process is repeated for each bit until a complete frame is received. It includes the first
stop bit, but excludes additional ones. If the sampled stop bit is a 0 value, the frame error (FERR) flag will be set.
Figure 21-8 on page 269 shows the sampling of the stop bit in relation to the earliest possible beginning of the next
frame's start bit.
Figure 21-8. Stop bit and next start bit sampling.
A new high-to-low transition indicating the start bit of a new frame can come right after the last of the bits used for
majority voting. For normal speed mode, the first low level sample can be at the point marked (A) in Stop Bit Sampling
and Next Start Bit Sampling. For double speed mode, the first low level must be delayed to point (B). Point (C) marks a
stop bit of full length at nominal baud rate. The early start bit detection influences the operational range of the receiver.
1234567 8 9 10 11 12 13 14 15 16 1 2
IDLE START
0 0
BIT 0
3
0 123 4 5 678 1 2
RxD
Sample
(U2X = 0)
Sample
(U2X = 1)
1234567 8 9 10 11 12 13 14 15 16 1
BIT n
123 4 5 678 1
RxD
Sample
(CLK2X = 0)
Sample
(CLK2X = 1)
1234567 8 9 10 0/1 0/1 0/1
STOP 1
123 4 5 6 0/1
RxD
Sample
(CLK2X = 0)
Sample
(CLK2X = 1)
(A) (B) (C)
XMEGA B [MANUAL] 270
8291C–AVR–09/2014
21.8.3 Asynchronous Operational Range
The operational range of the receiver is dependent on the mismatch between the received bit rate and the internally
generated baud rate. If an external transmitter is sending using bit rates that are too fast or too slow, or if the internally
generated baud rate of the receiver does not match the external source’s base frequency, the receiver will not be able to
synchronize the frames to the start bit.
The following equations can be used to calculate the ratio of the incoming data rate and internal receiver baud rate.
Table 21-3 and Table 21-4 on page 270 list the maximum receiver baud rate error that can be tolerated. Normal speed
mode has higher tolerance of baud rate variations.
Table 21-3. Recommended maximum receiver baud rate error for normal speed mode.
Table 21-4. Recommended maximum receiver baud rate error for double speed mode.
D Sum of character size and parity size (D = 5 to 10 bits).
S Samples per bit. S = 16 for normal speed mode and S = 8 for double speed mode.
SF First sample number used for majority voting. SF = 8 for normal speed mode and SF = 4 for double speed
mode.
SM Middle sample number used for majority voting. SM = 9 for normal speed mode and SM = 5 for double speed
mode.
Rslow The ratio of the slowest incoming data rate that can be accepted in relation to the receiver baud rate.
Rfast The ratio of the fastest incoming data rate that can be accepted in relation to the receiver baud rate.
D
#(Data + Parity Bit) Rslow [%] Rfast [%] Max Total Error [%]
Recommended Max
Receiver Error [%]
5 93.20 106.67 +6.67/-6.80 ± 3.0
6 94.12 105.79 +5.79/-5.88 ± 2.5
7 94.81 105.11 +5.11/-5.19 ± 2.0
8 95.36 104.58 +4.58/-4.54 ± 2.0
9 95.81 104.14 +4.14/-4.19 ± 1.5
10 96.17 103.78 +3.78/-3.83 ± 1.5
D
#(Data + Parity Bit) Rslow [%] Rfast [%] Max Total Error [%]
Recommended Max
Receiver Error [%]
5 94.12 105.66 +5.66/-5.88 ± 2.5
6 94.92 104.92 +4.92/-5.08 ± 2.0
7 95.52 104.35 +4.35/-4.48 ± 1.5
Rslow
( ) D + 1 S
S – 1 D S⋅ SF + + = ------------------------------------------- R fast
( ) D + 2 S
( ) D + 1 S SM + = ------------------------------------
XMEGA B [MANUAL] 271
8291C–AVR–09/2014
The recommendations for the maximum receiver baud rate error assume that the receiver and transmitter equally divide
the maximum total error.
21.9 Fractional Baud Rate Generation
Fractional baud rate generation is possible for asynchronous operation due to the relatively high number of clock cycles
for each frame. Each bit is sampled sixteen times, but only the three middle samples are of importance. The total number
of samples for one frame is also relatively high. Given a 1-start, 8-data, no-parity, and 1-stop-bit frame format, and
assuming that normal speed mode is used, the total number of samples for a frame is (1+8+1)×16 or 160. As stated
earlier, the UART can tolerate some variation in clock cycles for each sample. The critical factor is the time from the
falling edge of the start bit (i.e., the clock synchronization) until the last bit's (i.e., the first stop bit’s) value is recovered.
Standard baud rate generators have the unwanted property of having large frequency steps between high baud rate
settings. The worst case is found between the BSEL values 0x000 and 0x001. Going from a BSEL value of 0x000, which
has a 10-bit frame of 160 clock cycles, to a BSEL value of 0x001, with 320 clock cycles, gives a 50% change in
frequency. Ideally, the step size should be small even between the fastest baud rates. This is where the advantage of the
fractional baud rate generator emerges.
In principle, the fractional baud rate generator works by doing uneven counting and then distributing the error evenly over
the entire frame. A typical count sequence for an ordinary baud rate generator is:
2, 1, 0, 2, 1, 0, 2, 1, 0, 2, …
which has an even period time. A baud rate clock ticks each time the counter reaches zero, and a sample of the signal
received on RxD is taken for every 16th baud rate clock tick.
For the fractional baud rate generator, the count sequence can have an uneven period:
2, 1, 0, 2, 1-1, 0, 2, 1, 0, 2, 1-1, 0,...
In this example, an extra cycle is added to every second baud clock. This gives a baud rate clock tick jitter, but the
average period has been increased by a fraction of 0.5 clock cycles.
Figure 21-9 on page 272 shows an example of how BSEL and BSCALE can be used to achieve baud rates in between
what is possible by just changing BSEL.
The impact of fractional baud rate generation is that the step size between baud rate settings has been reduced. Given a
scale factor of -1, the worst-case step then becomes from 160 to 240 clock cycles per 10-bit frame, compared to the
previous step of from 160 to 320. A higher negative scale factor gives even finer granularity. There is a limit, however, to
how high the scale factor can be. The value 2|BSCALE| must be at most half the minimum number of clock cycles of a
frame. For instance, for 10-bit frames, the minimum number of clock cycles is 160. This means that the highest
applicable scale factor is -6 (2I-6I = 64 < (160/2) = 80).
For higher BSEL settings, the scale factor can be increased.
Table 21-5 on page 272 shows BSEL and BSCALE settings when using the internal oscillators to generate the most
commonly used baud rates for asynchronous operation and how reducing the BSCALE can be used to reduce the baud
rate error even further.
8 96.00 103.90 +3.90/-4.00 ± 1.5
9 96.39 103.53 +3.53/-3.61 ± 1.5
10 96.70 103.23 +3.23/-3.30 ± 1.0
D
#(Data + Parity Bit) Rslow [%] Rfast [%] Max Total Error [%]
Recommended Max
Receiver Error [%]
XMEGA B [MANUAL] 272
8291C–AVR–09/2014
Figure 21-9. Fractional baud rate example.
Table 21-5. USART baud rate.
BSEL=0
BSCALE=0
fBAUD=fPER/8
clkBAUD8
clkBAUD8
BSEL=3
BSCALE=-6
fBAUD=fPER/8.375
clkBAUD8
BSEL=3
BSCALE=-4
fBAUD=fPER/9.5
Extra clock cycle added
Baud fOSC = 32.0000MHz
rate
(bps)
CLK2X = 0 CLK2X = 1
BSEL BSCALE Error [%] BSEL BSCALE Error [%]
2400 12 6 0.2 12 7 0.2
4800 12 5 0.2 12 6 0.2
9600 12 4 0.2 12 5 0.2
14.4k
34 2 0.8 34 3 0.8
138 0 -0.1 138 1 -0.1
19.2k 12 3 0.2 12 4 0.2
28.8k
34 1 -0.8 34 2 -0.8
137 -1 -0.1 138 0 -0.1
38.4k 12 2 0.2 12 3 0.2
57.6k
34 0 -0.8 34 1 -0.8
135 -2 -0.1 137 -1 -0.1
76.8k 12 1 0.2 12 2 0.2
115.2k
33 -1 -0.8 34 0 -0.8
131 -3 -0.1 135 -2 -0.1
230.4k
31 -2 -0.8 33 -1 -0.8
123 -4 -0.1 131 -3 -0.1
460.8k
27 -3 -0.8 31 -2 -0.8
107 -5 -0.1 123 -4 -0.1
XMEGA B [MANUAL] 273
8291C–AVR–09/2014
21.10 USART in Master SPI Mode
Using the USART in master SPI mode requires the transmitter to be enabled. The receiver can optionally be enabled to
serve as the serial input. The XCK pin will be used as the transfer clock.
As for the USART, a data transfer is initiated by writing to the DATA register. This is the case for both sending and
receiving data, since the transmitter controls the transfer clock. The data written to DATA are moved from the transmit
buffer to the shift register when the shift register is ready to send a new frame.
The transmitter and receiver interrupt flags and corresponding USART interrupts used in master SPI mode are identical
in function to their use in normal USART operation. The receiver error status flags are not in use and are always read as
zero.
Disabling of the USART transmitter or receiver in master SPI mode is identical to their disabling in normal USART
operation.
21.11 USART SPI vs. SPI
The USART in master SPI mode is fully compatible with the standalone SPI module in that:
z Timing diagrams are the same
z UCPHA bit functionality is identical to that of the SPI CPHA bit
z UDORD bit functionality is identical to that of the SPI DORD bit
When the USART is set in master SPI mode, configuration and use are in some cases different from those of the
standalone SPI module. In addition, the following differences exist:
921.6k
19 -4 -0.8 27 -3 -0.8
75 -6 -0.1 107 -5 -0.1
1.382M
7 -4 0.6 15 -3 0.6
57 -7 0.1 121 -6 0.1
1.843M
3 -5 -0.8 19 -4 -0.8
11 -7 -0.1 75 -6 -0.1
2.00M 0 0 0.0 1 0 0.0
2.304M – – –
3 -2 -0.8
47 -6 -0.1
2.5M – – –
19 -4 0.4
77 -7 -0.1
3.0M – – –
11 -5 -0.8
43 -7 -0.2
4.0M – – – 0 0 0.0
Max 2.0Mbps 4.0Mbps
Baud fOSC = 32.0000MHz
rate
(bps)
CLK2X = 0 CLK2X = 1
BSEL BSCALE Error [%] BSEL BSCALE Error [%]
XMEGA B [MANUAL] 274
8291C–AVR–09/2014
z The USART transmitter in master SPI mode includes buffering, but the SPI module has no transmit buffer
z The USART receiver in master SPI mode includes an additional buffer level
z The USART in master SPI mode does not include the SPI write collision feature
z The USART in master SPI mode does not include the SPI double speed mode feature, but this can be achieved by
configuring the baud rate generator accordingly
z Interrupt timing is not compatible
z Pin control differs due to the master-only operation of the USART in SPI master mode
A comparison of the USART in master SPI mode and the SPI pins is shown Table 21-6.
Table 21-6. Comparison of USART in master SPI mode and SPI pins.
21.12 Multiprocessor Communication Mode
The multiprocessor communication mode effectively reduces the number of incoming frames that have to be handled by
the receiver in a system with multiple microcontrollers communicating via the same serial bus. In this mode, a dedicated
bit in the frames is used to indicate whether the frame is an address or data frame type.
If the receiver is set up to receive frames that contain five to eight data bits, the first stop bit is used to indicate the frame
type. If the receiver is set up for frames with nine data bits, the ninth bit is used. When the frame type bit is one, the frame
contains an address. When the frame type bit is zero, the frame is a data frame. If 5-bit to 8-bit character frames are
used, the transmitter must be set to use two stop bits, since the first stop bit is used for indicating the frame type.
If a particular slave MCU has been addressed, it will receive the following data frames as usual, while the other slave
MCUs will ignore the frames until another address frame is received.
21.12.1 Using Multiprocessor Communication Mode
The following procedure should be used to exchange data in multiprocessor communication mode (MPCM):
1. All slave MCUs are in multiprocessor communication mode.
2. The master MCU sends an address frame, and all slaves receive and read this frame.
3. Each slave MCU determines if it has been selected.
4. The addressed MCU will disable MPCM and receive all data frames. The other slave MCUs will ignore the data
frames.
5. When the addressed MCU has received the last data frame, it must enable MPCM again and wait for a new
address frame from the master.
The process then repeats from step 2.
Using any of the 5-bit to 8-bit character frame formats is impractical, as the receiver must change between using n and
n+1 character frame formats. This makes full-duplex operation difficult, since the transmitter and receiver must use the
same character size setting.
USART SPI Comment
TxD MOSI Master out only
RxD MISO Master in only
XCK SCK Functionally identical
N/A SS Not supported by USART in master SPI mode
XMEGA B [MANUAL] 275
8291C–AVR–09/2014
21.13 IRCOM Mode of Operation
IRCOM mode can be enabled to use the IRCOM module with the USART. This enables IrDA 1.4 compliant modulation
and demodulation for baud rates up to 115.2kbps. When IRCOM mode is enabled, double speed mode cannot be used
for the USART.
For devices with more than one USART, IRCOM mode can be enabled for only one USART at a time. For details, refer to
“IRCOM - IR Communication Module” on page 282.
21.14 DMA Support
DMA support is available on UART, USRT, and master SPI mode peripherals. For details on different USART DMA
transfer triggers, refer to “Transfer Triggers” on page 49.
XMEGA B [MANUAL] 276
8291C–AVR–09/2014
21.15 Register Description
21.15.1 DATA – Data register
The USART transmit data buffer register (TXB) and USART receive data buffer register (RXB) share the same I/O
address and is referred to as USART data register (DATA). The TXB register is the destination for data written to the
DATA register location. Reading the DATA register location returns the contents of the RXB register.
For 5-bit, 6-bit, or 7-bit characters, the upper unused bits will be ignored by the transmitter and set to zero by the receiver.
The transmit buffer can be written only when DREIF in the STATUS register is set. Data written to the DATA register
when DREIF is not set will be ignored by the USART transmitter. When data are written to the transmit buffer and the
transmitter is enabled, the transmitter will load the data into the transmit shift register when the shift register is empty.
The data are then transmitted on the TxD pin.
The receive buffer consists of a two-level FIFO. Always read STATUS before DATA in order to get the correct status of
the receive buffer.
21.15.2 STATUS – Status register
z Bit 7 – RXCIF: Receive Complete Interrupt Flag
This flag is set when there are unread data in the receive buffer and cleared when the receive buffer is empty (i.e., does
not contain any unread data). When the receiver is disabled, the receive buffer will be flushed, and consequently RXCIF
will become zero.
When interrupt-driven data reception is used, the receive complete interrupt routine must read the received data from
DATA in order to clear RXCIF. If not, a new interrupt will occur directly after the return from the current interrupt. This flag
can also be cleared by writing a one to its bit location.
z Bit 6 – TXCIF: Transmit Complete Interrupt Flag
This flag is set when the entire frame in the transmit shift register has been shifted out and there are no new data in the
transmit buffer (DATA). TXCIF is automatically cleared when the transmit complete interrupt vector is executed. The flag
can also be cleared by writing a one to its bit location.
z Bit 5 – DREIF: Data Register Empty Flag
This flag indicates whether the transmit buffer (DATA) is ready to receive new data. The flag is one when the transmit
buffer is empty and zero when the transmit buffer contains data to be transmitted that has not yet been moved into the
shift register. DREIF is set after a reset to indicate that the transmitter is ready. Always write this bit to zero when writing
the STATUS register.
DREIF is cleared by writing DATA. When interrupt-driven data transmission is used, the data register empty interrupt
routine must either write new data to DATA in order to clear DREIF or disable the data register empty interrupt. If not, a
new interrupt will occur directly after the return from the current interrupt.
Bit 7 6 5 4 3 2 1 0
+0x00 RXB[[7:0]
TXB[[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 00000000
Bit 7 6 5 4 3 2 1 0
+0x01 RXCIF TXCIF DREIF FERR BUFOVF PERR – RXB8
Read/Write R R/W R R R R R R/W
Initial Value 0 0 1 0 0 0 0 0
XMEGA B [MANUAL] 277
8291C–AVR–09/2014
z Bit 4 – FERR: Frame Error
The FERR flag indicates the state of the first stop bit of the next readable frame stored in the receive buffer. The bit is set
if the received character had a frame error, i.e., the first stop bit was zero, and cleared when the stop bit of the received
data is one. This bit is valid until the receive buffer (DATA) is read. FERR is not affected by setting the number of stop
bits used, as it always uses only the first stop bit. Always write this bit location to zero when writing the STATUS register.
This flag is not used in master SPI mode operation.
z Bit 3 – BUFOVF: Buffer Overflow
This flag indicates data loss due to a receiver buffer full condition. This flag is set if a buffer overflow condition is
detected. A buffer overflow occurs when the receive buffer is full (two characters) with a new character waiting in the
receive shift register and a new start bit is detected. This flag is valid until the receive buffer (DATA) is read. Always write
this bit location to zero when writing the STATUS register.
This flag is not used in master SPI mode operation.
z Bit 2 – PERR: Parity Error
If parity checking is enabled and the next character in the receive buffer has a parity error, this flag is set. If parity check
is not enabled, this flag will always be read as zero. This bit is valid until the receive buffer (DATA) is read. Always write
this bit location to zero when writing the STATUS register. For details on parity calculation, refer to “Parity Bit Calculation”
on page 266.
This flag is not used in master SPI mode operation.
z Bit 1 – Reserved
This bit is unused and reserved for future use. For compatibility with future devices, always write this bit to zero when this
register is written.
z Bit 0 – RXB8: Receive Bit 8
RXB8 is the ninth data bit of the received character when operating with serial frames with nine data bits. When used,
this bit must be read before reading the low bits from DATA.
This bit is unused in master SPI mode operation.
21.15.3 CTRLA – Control register A
z Bit 7:6 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 5:4 – RXCINTLVL[1:0]: Receive Complete Interrupt Level
These bits enable the receive complete interrupt and select the interrupt level, as described in “Interrupts and
Programmable Multilevel Interrupt Controller” on page 115. The enabled interrupt will be triggered when the RXCIF flag
in the STATUS register is set.
z Bit 3:2 – TXCINTLVL[1:0]: Transmit Complete Interrupt Level
These bits enable the transmit complete interrupt and select the interrupt level, as described in “Interrupts and
Programmable Multilevel Interrupt Controller” on page 115. The enabled interrupt will be triggered when the TXCIF flag
in the STATUS register is set.
z Bit 1:0 – DREINTLVL[1:0]: Data Register Empty Interrupt Level
These bits enable the data register empty interrupt and select the interrupt level, as described in “Interrupts and
Programmable Multilevel Interrupt Controller” on page 115. The enabled interrupt will be triggered when the DREIF flag
in the STATUS register is set.
Bit 7 6 5 4 3 2 1 0
+0x03 – – RXCINTLVL[1:0] TXCINTLVL[1:0] DREINTLVL[1:0]
Read/Write R R R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 00000
XMEGA B [MANUAL] 278
8291C–AVR–09/2014
21.15.4 CTRLB – Control register B
z Bit 7:5 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 4 – RXEN: Receiver Enable
Setting this bit enables the USART receiver. The receiver will override normal port operation for the RxD pin, when
enabled. Disabling the receiver will flush the receive buffer, invalidating the FERR, BUFOVF, and PERR flags.
z Bit 3 – TXEN: Transmitter Enable
Setting this bit enables the USART transmitter. The transmitter will override normal port operation for the TxD pin, when
enabled. Disabling the transmitter (writing TXEN to zero) will not become effective until ongoing and pending
transmissions are completed; i.e., when the transmit shift register and transmit buffer register do not contain data to be
transmitted. When disabled, the transmitter will no longer override the TxD port.
z Bit 2 – CLK2X: Double Transmission Speed
Setting this bit will reduce the divisor of the baud rate divider from16 to 8, effectively doubling the transfer rate for
asynchronous communication modes. For synchronous operation, this bit has no effect and should always be written to
zero. This bit must be zero when the USART communication mode is configured to IRCOM.
This bit is unused in master SPI mode operation.
z Bit 1 – MPCM: Multiprocessor Communication Mode
This bit enables the multiprocessor communication mode. When the MPCM bit is written to one, the USART receiver
ignores all the incoming frames that do not contain address information. The transmitter is unaffected by the MPCM
setting. For more detailed information, see “Multiprocessor Communication Mode” on page 274.
This bit is unused in master SPI mode operation.
z Bit 0 – TXB8: Transmit Bit 8
TXB8 is the ninth data bit in the character to be transmitted when operating with serial frames with nine data bits. When
used, this bit must be written before writing the low bits to DATA.
This bit is unused in master SPI mode operation.
21.15.5 CTRLC – Control register C
Note: 1. Master SPI mode.
z Bits 7:6 – CMODE[1:0]: Communication Mode
These bits select the mode of operation of the USART as shown in Table 21-7.
Bit 7 6 5 4 3 2 1 0
+0x04 – – – RXEN TXEN CLK2X MPCM TXB8
Read/Write R R R R/W R/W R/W R/W R/W
Initial Value 0 0 0 00000
Bit 7 6 5 4 3 2 1 0
+0x05 CMODE[1:0] PMODE[1:0] SBMODE CHSIZE[2:0]
+0x05(1) CMODE[1:0] – – – UDORD UCPHA –
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0000110
XMEGA B [MANUAL] 279
8291C–AVR–09/2014
Table 21-7. CMODE bit settings.
Notes: 1. See “IRCOM - IR Communication Module” on page 282 for full description on using IRCOM mode.
2. See “USART in Master SPI Mode” on page 273 for full description of the master SPI operation.
z Bits 5:4 – PMODE[1:0]: Parity Mode
These bits enable and set the type of parity generation according to Table 21-8. When enabled, the transmitter will
automatically generate and send the parity of the transmitted data bits within each frame. The receiver will generate a
parity value for the incoming data and compare it to the PMODE setting, and if a mismatch is detected, the PERR flag in
STATUS will be set.
These bits are unused in master SPI mode operation.
Table 21-8. PMODE bit settings.
z Bit 3 – SBMODE: Stop Bit Mode
This bit selects the number of stop bits to be inserted by the transmitter according to Table 21-9. The receiver ignores
this setting.
This bit is unused in master SPI mode operation.
Table 21-9. SBODE bit settings.
z Bit 2:0 – CHSIZE[2:0]: Character Size
The CHSIZE[2:0] bits set the number of data bits in a frame according to Table 21-10 on page 280. The receiver and
transmitter use the same setting.
CMODE[1:0] Group Configuration Mode
00 ASYNCHRONOUS Asynchronous USART
01 SYNCHRONOUS Synchronous USART
10 IRCOM IRCOM(1)
11 MSPI Master SPI(2)
PMODE[1:0] Group Configuration Parity Mode
00 DISABLED Disabled
01 Reserved
10 EVEN Enabled, even parity
11 ODD Enabled, odd parity
SBMODE Stop Bit(s)
0 1
1 2
XMEGA B [MANUAL] 280
8291C–AVR–09/2014
Table 21-10. CHSIZE bit settings.
z Bit 2 – UDORD: Data Order
This bit is only for master SPI mode, and this bit sets the frame format. When written to one, the lsb of the data word is
transmitted first. When written to zero, the msb of the data word is transmitted first. The receiver and transmitter use the
same setting. Changing the setting of UDORD will corrupt all ongoing communication for both receiver and transmitter.
z Bit 1 – UCPHA: Clock Phase
This bit is only for master SPI mode, and the bit determine whether data are sampled on the leading (first) edge or tailing
(last) edge of XCKn. Refer to the “Master SPI Mode Clock Generation” on page 265 for details.
21.15.6 BAUDCTRLA – Baud Rate register A
z Bit 7:0 – BSEL[7:0]: Baud Rate bits
These are the lower 8 bits of the 12-bit BSEL value used for USART baud rate setting. BAUDCTRLB contains the four
most-significant bits. Ongoing transmissions by the transmitter and receiver will be corrupted if the baud rate is changed.
Writing BSEL will trigger an immediate update of the baud rate prescaler. See the equations in Table 21-1 on page 263.
21.15.7 BAUDCTRLB – Baud Rate register B
z Bit 7:4 – BSCALE[3:0]: Baud Rate Scale factor
These bits select the baud rate generator scale factor. The scale factor is given in two's complement form from -7
(0b1001) to +7 (0b0111). The -8 (0b1000) setting is reserved. See the equations in Table 21-1 on page 263.
z Bit 3:0 – BSEL[11:8]: Baud Rate bits
These are the upper 4 bits of the 12-bit value used for USART baud rate setting. BAUDCTRLA contains the eight leastsignificant
bits. Ongoing transmissions by the transmitter and receiver will be corrupted if the baud rate is changed.
Writing BAUDCTRLA will trigger an immediate update of the baud rate prescaler.
CHSIZE[2:0] Group Configuration Character Size
000 5BIT 5-bit
001 6BIT 6-bit
010 7BIT 7-bit
011 8BIT 8-bit
100 Reserved
101 Reserved
110 Reserved
111 9BIT 9-bit
Bit 7 6 5 4 3 2 1 0
+0x06 BSEL[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
Bit 7 6 5 4 3 2 1 0
+0x07 BSCALE[3:0] BSEL[11:8]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 281
8291C–AVR–09/2014
21.16 Register Summary
21.16.1 Register Description - USART
21.16.2 Register Description - USART in SPI Master Mode
21.17 Interrupt Vector Summary
Address Name Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 Page
+0x00 DATA DATA[7:0] 276
+0x01 STATUS RXCIF TXCIF DREIF FERR BUFOVF PERR – RXB8 276
+0x02 Reserved – – – – – – – –
+0x03 CTRLA – – RXCINTLVL[1:0] TXCINTLVL[1:0] DREINTLVL[1:0] 277
+0x04 CTRLB – – – RXEN TXEN CLK2X MPCM TXB8 278
+0x05 CTRLC CMODE[1:0] PMODE[1:0] SBMODE CHSIZE[2:0] 278
+0x06 BAUDCTRL BSEL[7:0] 280
+0x07 BAUDCTRL BSCALE[3:0] BSEL[11:8] 280
Address Name Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 Page
+0x00 DATA DATA[7:0] 276
+0x01 STATUS RXCIF TXCIF DREIF – – – – – 276
+0x02 Reserved – – – – – – – –
+0x03 CTRLA – – RXCINTLVL[1:0] TXCINTLVL[1:0] DREINTLVL[1:0] 277
+0x04 CTRLB – – – RXEN TXEN – – – 278
+0x05 CTRLC CMODE[1:0] – – – UDORD UCPHA – 278
+0x06 BAUDCTRL BSEL[7:0] 280
+0x07 BAUDCTRL BSCALE[3:0] BSEL[11:8] 280
Offset Source Interrupt Description
0x00 RXC_vect USART receive complete interrupt vector
0x02 DRE_vect USART data register empty interrupt vector
0x04 TXC_vect USART transmit complete interrupt vector
XMEGA B [MANUAL] 282
8291C–AVR–09/2014
22. IRCOM - IR Communication Module
22.1 Features
z Pulse modulation/demodulation for infrared communication
z IrDA compatible for baud rates up to 115.2kbps
z Selectable pulse modulation scheme
z 3/16 of the baud rate period
z Fixed pulse period, 8-bit programmable
z Pulse modulation disabled
z Built-in filtering
z Can be connected to and used by any USART
22.2 Overview
XMEGA devices contain an infrared communication module (IRCOM) that is IrDA compatible for baud rates up to
115.2kbps. It can be connected to any USART to enable infrared pulse encoding/decoding for that USART.
Figure 22-1. IRCOM connection to USARTs and associated port pins.
The IRCOM is automatically enabled when a USART is set in IRCOM mode. The signals between the USART and the
RX/TX pins are then routed through the module as shown in Figure 22-1 on page 282. The data on the TX/RX pins are
the inverted value of the transmitted/received infrared pulse. It is also possible to select an event channel from the event
system as input for the IRCOM receiver. This will disable the RX input from the USART pin.
For transmission, three pulse modulation schemes are available:
z 3/16 of the baud rate period
z Fixed programmable pulse time based on the peripheral clock frequency
z Pulse modulation disabled
IRCOM
Pulse
Decoding
DIF
Event System
RXDxn
TXDxn
USARTxn
....
USARTD0
USARTC0
RXDD0
TXDD0
RXDC0
TXDC0
Pulse
Encoding
decoded RXD
encoded TXD
encoded RXD
RXD...
TXD...
decoded TXD
events
XMEGA B [MANUAL] 283
8291C–AVR–09/2014
For reception, a fixed programmable minimum high-level pulse width for the pulse to be decoded as a logical 0 is used.
Shorter pulses will then be discarded, and the bit will be decoded to logical 1 as if no pulse was received.
The module can only be used in combination with one USART at a time. Thus, IRCOM mode must not be set for more
than one USART at a time. This must be ensured in the user software.
22.2.1 Event System Filtering
The event system can be used as the receiver input. This enables IRCOM or USART input from I/O pins or sources other
than the corresponding RX pin. If event system input is enabled, input from the USART's RX pin is automatically
disabled. The event system has a digital input filter (DIF) on the event channels that can be used for filtering. Refer to
“Event System” on page 63” for details on using the event system.
XMEGA B [MANUAL] 284
8291C–AVR–09/2014
22.3 Registers Description
22.3.1 TXPLCTRL – Transmitter Pulse Length Control Register
z Bit 7:0 – TXPLCTRL[7:0]: Transmitter Pulse Length Control
This 8-bit value sets the pulse modulation scheme for the transmitter. Setting this register will have no effect if IRCOM
mode is not selected by a USART.
By leaving this register value to zero, 3/16 of the baud rate period pulse modulation is used.
Setting this value from 1 to 254 will give a fixed pulse length coding. The 8-bit value sets the number of system clock
periods for the pulse. The start of the pulse will be synchronized with the rising edge of the baud rate clock.
Setting the value to 255 (0xFF) will disable pulse coding, letting the RX and TX signals pass through the IRCOM module
unaltered. This enables other features through the IRCOM module, such as half-duplex USART, loop-back testing, and
USART RX input from an event channel.
TXPCTRL must be configured before the USART transmitter is enabled (TXEN).
22.3.2 RXPLCTRL – Receiver Pulse Length Control Register
z Bit 7:0 – RXPLCTRL[7:0]: Receiver Pulse Length Control
This 8-bit value sets the filter coefficient for the IRCOM transceiver. Setting this register will have no effect if IRCOM
mode is not selected by a USART.
By leaving this register value at zero, filtering is disabled. Setting this value between 1 and 255 will enable filtering, where
x+1 equal samples are required for the pulse to be accepted.
RXPCTRL must be configured before the USART receiver is enabled (RXEN).
22.3.3 CTRL – Control Register
z Bit 7:4 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 3:0 – EVSEL [3:0]: Event Channel Selection
These bits select the event channel source for the IRCOM receiver according to Table 22-1. If event input is selected for
the IRCOM receiver, the input from the USART’s RX pin is automatically disabled.
Bit 7 6 5 4 3 2 1 0
+0x01 TXPLCTRL[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
Bit 7 6 5 4 3 2 1 0
+0x02 RXPLCTRL[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
Bit 7 6 5 4 3 2 1 0
+0x00 – – – – EVSEL[3:0]
Read/Write R R R R R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 285
8291C–AVR–09/2014
Table 22-1. Event channel selection.
22.4 Register Summary
EVSEL[3:0] Group Configuration Event Source
0000 – None
0001 – (Reserved)
0010 – (Reserved)
0011 – (Reserved)
0100 – (Reserved)
0101 – (Reserved)
0110 – (Reserved)
0111 – (Reserved)
1nnn CHn Event system channel n; n = {0, …,7}
Address Name Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 Page
+0x00 CTRL – – – – EVSEL[3:0] 284
+0x01 TXPLCTRL TXPLCTRL[7:0] 284
+0x02 RXPLCTRL RXPLCTRL[7:0] 284
XMEGA B [MANUAL] 286
8291C–AVR–09/2014
23. AES and DES Crypto Engines
23.1 Features
z Data Encryption Standard (DES) CPU instruction
z Advanced Encryption Standard (AES) crypto module
z DES Instruction
z Encryption and decryption
z DES supported
z Encryption/decryption in 16 CPU clock cycles per 8-byte block
z AES crypto module
z Encryption and decryption
z Supports 128-bit keys
z Supports XOR data load mode to the state memory
z Encryption/decryption in 375 clock cycles per 16-byte block
23.2 Overview
The Advanced Encryption Standard (AES) and Data Encryption Standard (DES) are two commonly used standards for
cryptography. These are supported through an AES peripheral module and a DES CPU instruction, and the
communication interfaces and the CPU can use these for fast, encrypted communication and secure data storage.
DES is supported by an instruction in the AVR CPU. The 8-byte key and 8-byte data blocks must be loaded into the
register file, and then the DES instruction must be executed 16 times to encrypt/decrypt the data block.
The AES crypto module encrypts and decrypts 128-bit data blocks with the use of a 128-bit key. The key and data must
be loaded into the key and state memory in the module before encryption/decryption is started. It takes 375 peripheral
clock cycles before the encryption/decryption is done. The encrypted/encrypted data can then be read out, and an
optional interrupt can be generated. The AES crypto module also has DMA support with transfer triggers when
encryption/decryption is done and optional auto-start of encryption/decryption when the state memory is fully loaded.
23.3 DES Instruction
The DES instruction is a single cycle instruction. In order to decrypt or encrypt a 64-bit (8-byte) data block, the instruction
has to be executed 16 times.
The data and key blocks must be loaded into the register file before encryption/decryption is started. The 64-bit data
block (plaintext or ciphertext) is placed in registers R0-R7, where the LSB of data is placed in R0 and the MSB of data is
placed in R7. The full 64-bit key (including parity bits) is placed in registers R8-R15, with the LSB of the key in R8 and the
MSB of the key in R15.
XMEGA B [MANUAL] 287
8291C–AVR–09/2014
Figure 23-1. Register file usage during DES encryption/decryption.
Executing one DES instruction performs one round in the DES algorithm. Sixteen rounds must be executed in increasing
order to form the correct DES ciphertext or plaintext. Intermediate results are stored in the register file (R0-R15) after
each DES instruction. After sixteen rounds, the key is located in R8-R16 and the encrypted/decrypted ciphertext/plaintext
is located in R0-R7. The instruction's operand (K) determines which round is executed, and the half carry flag (H) in the
CPU status register determines whether encryption or decryption is performed. If the half carry flag is set, decryption is
performed, and if the flag is cleared, encryption is performed.
For more details on the DES instruction, refer to the AVR instruction set manual.
23.4 AES Crypto Module
The AES crypto module performs encryption and decryption according to the Advanced Encryption Standard (FIPS-197).
The 128-bit key block and 128-bit data block (plaintext or ciphertext) must be loaded into the key and state memories in
the AES crypto module. This is done by writing the AES KEY register and STATE register sequentially with 16 bytes.
It is software selectable whether the module should perform encryption or decryption. It is also possible to enable XOR
mode, where all new data loaded to the state key is XORed with the current data in the state memory.
The AES module uses 375 clock cycles before the encrypted/decrypted plaintext/ciphertext is available for readout in the
state memory.
The following setup and use procedure is recommended:
1. Enable the AES interrupt (optional).
2. Select the AES direction to encryption or decryption.
3. Load the key data block into the AES key memory.
4. Load the data block into the AES state memory.
5. Start the encryption/decryption operation.
If more than one block is to be encrypted or decrypted, repeat the procedure from step 3.
When the encryption/decryption procedure is complete, the AES interrupt flag is set and an optional interrupt is
generated.
Register File
R0
R1
R2
R3
R4
R5
R6
R7
R8
R9
R10
R11
R12
R13
R14
R15
R16
...
R31
data0
data1
data2
data3
data4
data5
data6
data7
key0
key1
key2
key3
key4
key5
key6
key7
data key
XMEGA B [MANUAL] 288
8291C–AVR–09/2014
23.4.1 Key and State Memory
The AES key and state memory are both 16 x 8-bit memories that are accessible through the KEY and STATE registers,
respectively.
Each memory has two 4-bit address pointers used to address the memory for read and write, respectively. The initial
value of the pointers is zero. After a read or write operation to the STATE or KEY register, the appropriate pointer is
automatically incremented. Accessing (read or write) the control register (CTRL) will reset all pointers to zero. A pointer
overflow (a sequential read or write done more than 16 times) will also set the affected pointer to zero. The pointers are
not accessible from software. Read and write memory pointers are both incremented during write operations in XOR
mode.
Access to the KEY and STATE registers is possible only when encryption/decryption is not in progress.
Figure 23-2. The state memory with pointers and register.
The state memory contains the AES state throughout the encryption/decryption process. The initial value of the state is
the initial data (i.e., plaintext in the encryption mode, and ciphertext in the decryption mode). The last value of the state is
the encrypted/decrypted data.
Figure 23-3. The key memory with pointers and register.
In the AES crypto module, the following definition of the key is used:
z In encryption mode, the key is the one defined in the AES standard.
4-bit state write
address pointer
1
-
14
15
STATE
0 4-bit state read
address pointer
Reset pointer
Reset pointer
reset or access
to AES Control
reset or access
to AES Control
STATE[read pointer]
xor
XOR
I/O Data Bus
4-bit key write
address pointer
1
-
14
15
KEY
0 4-bit key read
address pointer
Reset pointer
Reset pointer
reset or
access to CTRL
reset or
access to CTRL
XMEGA B [MANUAL] 289
8291C–AVR–09/2014
z In decryption mode, the key is the last subkey of the expanded key defined in the AES standard.
In decryption mode, the key expansion procedure must be executed by software before operation with the AES crypto
module so that the last subkey is ready to be loaded through the KEY register. Alternatively, this procedure can be run in
hardware by using the AES crypto module to process a dummy data block in encryption mode using the same key. After
the end of the encryption, reading from the key memory allows the last subkey to be obtained; i.e., get the result of the
key expansion procedure. Table 23-1 shows the results of reading the key, depending on the mode (encryption or
decryption) and status of the AES crypto module.
Table 23-1. The result of reading the key memory at different stages.
23.4.2 DMA Support
The AES module can trigger a DMA transfer when the encryption/decryption procedure is complete. For more details on
DMA transfer triggers, refer to “Transfer Triggers” on page 49.
Encryption Decryption
Before data processing After data processing Before data processing After Data Processing
Same key as loaded The last subkey generated from the
loaded key Same key as loaded The initial key generated from the
last loaded subkey
XMEGA B [MANUAL] 290
8291C–AVR–09/2014
23.5 Register Description – AES
23.5.1 CTRL – Control register
z Bit 7 – START: Start/Run
Setting this bit starts the encryption/decryption procedure, and this bit remains set while the encryption/decryption is
ongoing. Writing this bit to zero will stop/abort any ongoing encryption/decryption process. This bit is automatically
cleared if the SRIF or the ERROR flags in STATUS are set.
z Bit 6 – AUTO: Auto Start Trigger
Setting this bit enables the auto-start mode. In auto-start mode, the START bit will trigger automatically and start the
encryption/decryption when all of the following conditions are met:
z The AUTO bit is set before the state memory is loaded
z All memory pointers (state read/write and key read/write) are zero
z State memory is fully loaded
If all of these conditions are not met, the encryption/decryption will be started with an incorrect key.
z Bit 5 – RESET: Software Reset
Setting this bit will reset the AES crypto module to its initial status on the next positive edge of the peripheral clock. All
registers, pointers, and memories in the module are set to their initial value. When written to one, the bit stays high for
one clock cycle before it is reset to zero by hardware.
z Bit 4 – DECRYPT: Decryption / Direction
This bit sets the direction for the AES crypto module. Writing this bit to zero will set the module in encryption mode.
Writing one to this bit sets the module in decryption mode.
z Bit 3 – Reserved
This bit is unused and reserved for future use. For compatibility with future devices, always write this bit to zero when this
register is written.
z Bit 2 – XOR: State XOR Load Enable
Setting this bit enables a XOR data load to the state memory. When this bit is set, the data loaded to the state memory
are bitwise XORed with the data currently in the state memory. Writing this bit to zero disables XOR load mode, and new
data written to the state memory will overwrite the current data.
z Bit 1:0 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
Bit 7 6 5 4 3 2 1 0
+0x00 START AUTO RESET DECRYPT – XOR – –
Read/Write R/W R/W R/W R/W R R/W R R
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 291
8291C–AVR–09/2014
23.5.2 STATUS – AES Status register
z Bit 7 – ERROR: Error
The ERROR flag indicates an illegal handling of the AES crypto module. The flag is set in the following cases:
z Setting START in the control register while the state memory and/or key memory are not fully loaded or read. This
error occurs when the total number of read/write operations from/to the STATE and KEY registers is not a multiple
of 16 before an AES start.
z Accessing (read or write) the control register while the START bit is one.
This flag can be cleared by software by writing one to its bit location.
z Bit 6:1 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 0 – SRIF: State Ready Interrupt flag
This flag is the interrupt/DMA request flag, and is set when the encryption/decryption procedure is completed and the
state memory contains valid data. As long as the flag is zero, this indicates that there is no valid encrypted/decrypted
data in the state memory.
The flag is cleared by hardware when a read access is made to the state memory (the first byte is read). Alternatively, the
bit can be cleared by writing a one to its bit location.
23.5.3 STATE – AES State register
The STATE register is used to access the state memory. Before encryption/decryption can take place, the state memory
must be written sequentially, byte-by-byte, through the STATE register. After encryption/decryption is done, the
ciphertext/plaintext can be read sequentially, byte-by-byte, through the STATE register.
Loading the initial data to the STATE register should be done after setting the appropriate AES mode and direction. This
register can not be accessed during encryption/decryption.
23.5.4 KEY – Key register
The KEY register is used to access the key memory. Before encryption/decryption can take place, the key memory must
be written sequentially, byte-by-byte, through the KEY register. After encryption/decryption is done, the last subkey can
be read sequentially, byte-by-byte, through the KEY register.
Loading the initial data to the KEY register should be done after setting the appropriate AES mode and direction.
Bit 7 6 5 4 3 2 1 0
+0x01 ERROR – – – – – – SRIF
Read/Write R/W R R R R R R R/W
Initial Value 00000000
Bit 7 6 5 4 3 2 1 0
+0x02 STATE[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0000
Bit 7 6 5 4 3 2 1 0
+0x03 KEY[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 292
8291C–AVR–09/2014
23.5.5 INTCTRL – Interrupt Control register
z Bit 7:2 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 1:0 – INTLVL[1:0]: Interrupt priority and enable
These bits enable the AES interrupt and select the interrupt level, as described in “Interrupts and Programmable
Multilevel Interrupt Controller” on page 115. The enabled interrupt will be triggered when the SRIF in the STATUS
register is set.
23.6 Register summary – AES
23.7 Interrupt vector summary
Table 23-2. AES interrupt vector and its offset word address.
Bit 7 6 5 4 3 2 1 0
+0x04 – – – – – – INTLVL[1:0]
Read/Write R R R R R R R/W R/W
Initial Value 0 0 0 0 0 0 0 0
Address Name Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 bit 0 Page
+0x00 CTRL START AUTO RESET DECRYPT – XOR – – 290
+0x01 STATUS ERROR – – – – – – SRIF 291
+0x02 STATE STATE[7:0] 291
+0x03 KEY KEY[7:0] 291
+0x04 INTCTRL – – – – – – INTLVL[1:0] 292
+0x05 Reserved – – – – – – – –
+0x06 Reserved – – – – – – – –
+0x07 Reserved – – – – – – – –
Offset Source Interrupt Description
0x00 AES_vect AES interrupt vector
XMEGA B [MANUAL] 293
8291C–AVR–09/2014
24. CRC – Cyclic Redundancy Check Generator
24.1 Features
z Cyclic redundancy check (CRC) generation and checking for
z Communication data
z Program or data in flash memory
z Data in SRAM and I/O memory space
z Integrated with flash memory, DMA controller and CPU
z Continuous CRC on data going through a DMA channel
z Automatic CRC of the complete or a selectable range of the flash memory
z CPU can load data to the CRC generator through the I/O interface
z CRC polynomial software selectable to
z CRC-16 (CRC-CCITT)
z CRC-32 (IEEE 802.3)
z Zero remainder detection
24.2 Overview
A cyclic redundancy check (CRC) is an error detection technique test algorithm used to find accidental errors in data, and
it is commonly used to determine the correctness of a data transmission, and data present in the data and program
memories. A CRC takes a data stream or a block of data as input and generates a 16- or 32-bit output that can be
appended to the data and used as a checksum. When the same data are later received or read, the device or application
repeats the calculation. If the new CRC result does not match the one calculated earlier, the block contains a data error.
The application will then detect this and may take a corrective action, such as requesting the data to be sent again or
simply not using the incorrect data.
Typically, an n-bit CRC applied to a data block of arbitrary length will detect any single error burst not longer than n bits
(any single alteration that spans no more than n bits of the data), and will detect the fraction 1-2-n of all longer error
bursts. The CRC module in XMEGA devices supports two commonly used CRC polynomials; CRC-16 (CRC-CCITT) and
CRC-32 (IEEE 802.3).
z CRC-16:
z CRC-32:
Polynomial: x16+x12+x5
+1
Hex value: 0x1021
Polynomial: x32+x26+x23+x22+x16+x12+x11+x10+x8
+x7
+x5
+x4
+x2
+x+1
Hex value: 0x04C11DB7
XMEGA B [MANUAL] 294
8291C–AVR–09/2014
24.3 Operation
The data source for the CRC module must be selected in software as either flash memory, the DMA channels, or the I/O
interface. The CRC module then takes data input from the selected source and generates a checksum based on these
data. The checksum is available in the CHECKSUM registers in the CRC module. When CRC-32 polynomial is used, the
final checksum read is bit reversed and complemented (see Figure 24-1).
For the I/O interface or DMA controller, which CRC polynomial is used is software selectable, but the default setting is
CRC-16. CRC-32 is automatically used if Flash Memory is selected as the source. The CRC module operates on bytes
only.
Figure 24-1. CRC generator block diagram.
24.4 CRC on Flash memory
A CRC-32 calculation can be performed on the entire flash memory, on only the application section, on only the boot
section, or on a software selectable range of the flash memory. Other than selecting the flash as the source, all further
control and setup are done from the NVM controller. This means that the NVM controller configures the memory range to
perform the CRC on, and the CRC is started using NVM commands. Once completed, the result is available in the
checksum registers in the CRC module. For further details on setting up and performing CRC on flash memory, refer to
“Memory Programming” on page 375.
24.5 CRC on DMA Data
CRC-16 or CRC-32 calculations can be performed on data passing through any DMA channel. Once a DMA channel is
selected as the source, the CRC module will continuously generate the CRC on the data passing through the DMA
channel. The checksum is available for readout once the DMA transaction is completed or aborted. A CRC can be
DATAIN
CTRL
Flash
Memory
DMA
Controller
CRC-16 CRC-32
CHECKSUM
bit-reverse +
complement
8 16 8 32
Checksum read
crc32
XMEGA B [MANUAL] 295
8291C–AVR–09/2014
performed not only on communication data, but also on data in SRAM or I/O memory by passing these data through a
DMA channel. If the latter is done, the destination register for the DMA data can be the data input (DATAIN) register in
the CRC module.
24.6 CRC using the I/O Interface
CRC can be performed on any data by loading them into the CRC module using the CPU and writing the data to the
DATAIN register. Using this method, an arbitrary number of bytes can be written to the register by the CPU, and CRC is
done continuously for each byte. New data can be written for each cycle. The CRC complete is signaled by writing the
BUSY bit in the STATUS register.
XMEGA B [MANUAL] 296
8291C–AVR–09/2014
24.7 Register Description
24.7.1 CTRL – Control register
z Bit 7:6 – RESET[1:0]: Reset
These bits are used to reset the CRC module, and they will always be read as zero. The CRC registers will be reset one
peripheral clock cycle after the RESET[1] bit is set
Table 24-1. CRC reset.
z Bit 5 – CRC32: CRC-32 Enable
Setting this bit will enable CRC-32 instead of the default CRC-16. It cannot be changed while the BUSY flag is set.
z Bit 4 – Reserved
This bit is unused and reserved for future use. For compatibility with future devices, always write this bit to zero when this
register is written.
z Bit 3:0 – SOURCE[3:0]: Input Source
These bits select the input source for generating the CRC. The selected source is locked until either the CRC generation
is completed or the CRC module is reset. CRC generation complete is generated and signaled from the selected source
when used with the DMA controller or flash memory.
Table 24-2. CRC source select.
Bit 7 6 5 4 3 2 1 0
+0x00 RESET[1:0] CRC32 – SOURCE[3:0]
Read/Write R/W R/W R/W R R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
RESET[1:0] Group configuration Description
00 NO No reset
01 – Reserved
10 RESET0 Reset CRC with CHECKSUM to all zeros
11 RESET1 Reset CRC with CHECKSUM to all ones
SOURCE[3:0] Group configuration Description
0000 DISABLE CRC disabled
0001 IO I/O interface
0010 FLASH Flash
0011 – Reserved for future use
0100 DMACH0 DMA controller channel 0
0101 DMACH1 DMA controller channel 1
0110 DMACH2 DMA controller channel 2
0111 DMACH3 DMA controller channel 3
1xxx – Reserved for future use
XMEGA B [MANUAL] 297
8291C–AVR–09/2014
24.7.2 STATUS – Status register
z Bit 7:2 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 1 – ZERO: Checksum Zero
This flag is set if the CHECKSUM is zero when the CRC generation is complete. It is automatically cleared when a new
CRC source is selected.
When running CRC-32 and appending the checksum at the end of the packet (as little endian), the final checksum should
be 0x2144df1c, and not zero. However, if the checksum is complemented before it is appended (as little endian) to the
data, the final result in the checksum register will be zero.
See the description of CHECKSUM to read out different versions of the CHECKSUM.
z Bit 0 – BUSY: Busy
This flag is read as one when a source configuration is selected and as long as the source is using the CRC module. If
the I/O interface is selected as the source, the flag can be cleared by writing a one this location. If a DMA channel if
selected as the source, the flag is cleared when the DMA channel transaction is completed or aborted. If flash memory is
selected as the source, the flag is cleared when the CRC generation is completed.
24.7.3 DATAIN – Data Input register
z Bit 7:0 – DATAIN[7:0]: Data Input
This register is used to store the data for which the CRC checksum is computed. A new CHECKSUM is ready one clock
cycle after the DATAIN register is written.
24.7.4 CHECKSUM0 – Checksum register 0
CHECKSUM0, CHECKSUM1, CHECKSUM2, and CHECKSUM3 represent the 16- or 32-bit CHECKSUM value and the
generated CRC. The registers are reset to zero by default, but it is possible to write RESET to reset all bits to one. It is
possible to write these registers only when the CRC module is disabled. If NVM is selected as the source, reading
CHECKSUM will return a zero value until the BUSY flag is cleared. If CRC-32 is selected and the BUSY flag is cleared
(i.e., CRC generation is completed or aborted), the bit reversed (bit 31 is swapped with bit 0, bit 30 with bit 1, etc.) and
complemented result will be read from CHECKSUM. If CRC-16 is selected or the BUSY flag is set (i.e., CRC generation
is ongoing), CHECKSUM will contain the actual content.
z Bit 7:0 – CHECKSUM[7:0]: Checksum byte 0
These bits hold byte 0 of the generated CRC.
Bit 7 6 5 4 3 2 1 0
+0x02 – – – – – – ZERO BUSY
Read/Write R R R R R R R R/W
Initial Value 0 0 0 0 0 0 0 0
Bit 7 6 5 4 3 2 1 0
+0x03 DATAIN[7:0]
Read/Write WWWWWWWW
Initial Value 0 0 0 0 0 0 0 0
Bit 7 6 5 4 3 2 1 0
+0x04 CHECKSUM[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 298
8291C–AVR–09/2014
24.7.5 CHECKSUM1 – Checksum register 1
z Bit 7:0 – CHECKSUM[15:8]: Checksum byte 1
These bits hold byte 1 of the generated CRC.
24.7.6 CHECKSUM2 – Checksum register 2
z Bit 7:0 – CHECKSUM[23:16]: Checksum byte 2
These bits hold byte 2 of the generated CRC when CRC-32 is used.
24.7.7 CHECKSUM3 – CRC Checksum register 3
z Bit 7:0 – CHECKSUM[31:24]: Checksum byte 3
These bits hold byte 3 of the generated CRC when CRC-32 is used.
24.8 Register Summary
Bit 7 6 5 4 3 2 1 0
+0x05 CHECKSUM[15:8]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
Bit 7 6 5 4 3 2 1 0
+0x06 CHECKSUM[23:16]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
Bit 7 6 5 4 3 2 1 0
+0x07 CHECKSUM[31:24]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
Address Name Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 Page
+0x00 CTRL RESET[1:0] CRC32 – SOURCE[3:0] 296
+0x01 STATUS – – – – – – ZERO BUSY 297
+0x02 Reserved – – – – – – – –
+0x03 DATAIN DATAIN[7:0] 297
+0x04 CHECKSU CHECKSUM[7:0] 298
+0x05 CHECKSU CHECKSUM[15:8] 298
+0x06 CHECKSU CHECKSUM[23:16] 298
+0x07 CHECKSU CHECKSUM[31:24] 298
XMEGA B [MANUAL] 299
8291C–AVR–09/2014
25. LCD – Liquid Crystal Display
25.1 Features
z Display Capacity up to 40 Segment and up to 4 Common Terminals
z Supports up to 16 GPIO's
z Shadow Display Memory Gives Full Freedom in Segment Update
z ASCII Character Mapping
z Swap Capability Option on Common and/or Segment Terminal Buses
z Supports from Static up to 1/4 Duty
z Supports Static and 1/3 Bias
z LCD Driver Active in Power Save Mode for Low Power Operation
z Software Selectable Low Power Waveform
z Flexible Selection of Frame Frequency
z Programmable Blink Mode and Frequency
z Blink on two Segment Terminals
z Uses Only 32kHz RTC Clock Source
z On-chip LCD Power Supply
z Software Contrast Adjustment Control
z Equal Source and Sink Capability to Increase LCD Life Time
z Extended Interrupt Mode for Display Update or Wake-up from Sleep Mode
25.2 Overview
An LCD display is made of several segments (pixels or complete symbols) which can be visible or invisible. A segment
has two electrodes with liquid crystal between them. These electrodes are the common terminal (COM pin) and the
segment terminal (SEG pin). When a voltage above a threshold voltage is applied across the liquid crystal, the segment
becomes visible. The voltage must alternate to avoid an electrophoresis effect in the liquid crystal, this effect degrades
the display. Hence the voltage waveform across a segment must not have a DC-component.
The LCD controller is intended for monochrome passive liquid crystal display (LCD) with up to 4 Common terminals and
up to 40 Segments terminals. If the application does not need all the LCD segments available on the XMEGA, up to 16 of
the unused LCD pins can be used as general purpose I/O pins.
The LCD controller can be clocked by an internal or an external asynchronous 32kHz clock source. This 32kHz oscillator
source selection is the same as for the Real Time Counter (RTC).
Dedicated Low Power Waveform, Contrast Control, Extended Interrupt Mode, Selectable Frame Frequency and Blink
functionality are supported to offload the CPU, reduce interrupts and reduce power consumption.
To reduce hardware design complexity, the LCD includes integrated LCD buffers, an integrated power supply voltage
and an innovative SWAP mode. Using SWAP mode, the hardware designers have more flexibility during board layout as
they can rearrange the pin sequence on Segment and/or Common Terminal Buses.
XMEGA B [MANUAL] 300
8291C–AVR–09/2014
25.2.1 Definitions
Several terms are used when describing LCD. The definitions in Table 25-1 are used throughout this document.
Table 25-1. LCD definitions.
Figure 25-1. LCD Typical Connections
25.2.2 LCD Clock Sources
The LCD controller can be clocked by an internal or an external asynchronous 32kHz clock source. This 32kHz oscillator
source selection is the same as for the Real Time Counter, RTCSRC bit-field in RTC control register (see Table 7-4 on
page 87).
The clock source must be stable to obtain accurate LCD timing and hence minimize DC voltage offset across LCD
segments.
25.2.3 LCD Prescaler
The prescaler consists of a 3-bit ripple counter and a 1 to 8-clock divider (see Figure 25-2 on page 301). The PRESC bit
selects clk LCD divided by 8 or 16 from the ripple counter.
If a finer resolution in frame rate is required, the CLKDIV bit-field can be used to divide the clock further by 1 to 8.
Output from the clock divider clk LCD_PS is used as clock source for the LCD timing.
25.2.4 LCD Display Memory
The Display Memory is available through I/O registers grouped for each common terminal.
A start of new frame triggers an update of the Shadow Display Memory. The content of Display Memory is saved into the
Shadow Display Memory. A Display Memory refresh is possible without affecting data that is sent to the panel.
LCD A passive display panel with terminals leading directly to a segment
Segment (or pixel) A LCD panel active area within the display which can be turned “ON or “OFF”. This can be a single
segment of a 7-segment character or a specific symbol (icon).
COM Common terminal
SEG Segment terminal
1 / Duty 1 / Number of common terminals on an actual LCD display
1 / Bias 1 / Number of voltage levels used driving a LCD display -1
Frame Rate Number of times the LCD segments are energized per second
Segment 0
Segment 1
Segment 2
Segment 4
Segment 5
Segment 6
SEG0
Segment 3
Segment 7
Common
Terminal 0 COM0
Common
Terminal 1 COM1
Segment
Terminal 0
SEG1
Segment
Terminal 1
SEG2
Segment
Terminal 2
SEG3
Segment
Terminal 3
XMEGA B [MANUAL] 301
8291C–AVR–09/2014
When a bit in the Display Memory is written to one, the corresponding segment will be energized (“ON”), and deenergized
(“OFF”) when this bit is written to zero.
To energize a segment, an absolute voltage above a certain threshold must be applied. This is done by setting the SEG
pin to opposite phase when the corresponding COM pin is active. For a display with more than one common terminal,
two (1/3 bias) additional voltage levels must be applied. Otherwise, non-energized segments on COM0 would be
energized for all non-selected common terminals.
Addressing COM0 starts a frame by driving an opposite phase with large amplitude on COM0 as against non addressed
COM lines. Non-energized segments are in phase with the addressed COM0, and energized segments have opposite
phase and large amplitude. For waveform figures refer to “Mode of Operation” on page 302.
DATA4 - DATA0 from Shadow Display Memory is multiplexed into the decoder. The decoder is controlled from the LCD
timing and sets up signals controlling the analog switches to produce an output waveform.
Next, COM1 is addressed, and DATA9 - DATA5 from Shadow Display Memory is input to the decoder. Addressing
continues until all COM lines are addressed according to the number of selected common terminals (duty).
25.2.5 Minimizing Power Consumption
The power consumption of the LCD controller can be minimized by:
1. Using the lowest acceptable frame rate - Refer to the LCD glass technical characteristics.
2. Using the low power waveform - “Low Power Waveform” on page 303
3. Programming the lowest possible contrast value - “CTRLF – Control register F” on page 313.
25.3 Block Diagram
Figure 25-2. LCD Controller Block Diagram
COMy
VLCD
BIAS1
CTRLF BIAS2
Analog
Switch
Array
Shadow
Display
Memory
LCD Power
Supply
Timing Control & Swap
CTRLD CTRLC
CTRLB CTRLA
Character
Mapping
CTRLH
CTRLG
CTRLE
CAPH CAPL
SEGx
INT
DATAn
DATA1
:
DATA0
Display
Memory
XMEGA B [MANUAL] 302
8291C–AVR–09/2014
25.4 Mode of Operation
25.4.1 Static Duty and Static Bias
If all segments on an LCD have one common electrode, then, each segment must have a unique segment terminal. This
kind of display is driven with the waveform shown in Figure 25-3 on page 302. SEG0-COM0 is the voltage across a
segment that is “ON”, and SEG1-COM0 is the voltage across a segment that is “OFF”.
Figure 25-3. Driving an LCD With One Common Terminal
25.4.2 1/2 Duty and 1/3 Bias
For an LCD with two common terminals (1/2 duty) a more complex waveform must be used to individually control
segments. The waveform is shown in Figure 25-4 on page 302. SEG0-COM0 is the voltage across a segment that is
“ON”, and SEG0-COM1 is the voltage across a segment that is “OFF”.
Figure 25-4. Driving an LCD With Two Common Terminals
25.4.3 1/3 Duty and 1/3 Bias
1/3 bias is usually recommended for an LCD with three common terminals (1/3 duty). The waveform is shown in Figure
25-5 on page 303. SEG0-COM0 is the voltage across a segment that is “ON” and SEG0-COM1 is the voltage across a
segment that is “OFF”.
XMEGA B [MANUAL] 303
8291C–AVR–09/2014
Figure 25-5. Driving an LCD With Three Common Terminals
25.4.4 1/4 Duty and 1/3 Bias
1/3 bias is optimal for an LCD displays with four common terminals (1/4 duty). The waveform is shown in Figure 25-6 on
page 303. SEG0-COM0 is the voltage across a segment that is ON” and SEG0-COM1 is the voltage across a segment
that is “OFF”.
Figure 25-6. Driving an LCD With Four Common Terminals
25.4.5 Low Power Waveform
To reduce toggle activity and hence power consumption, a low power waveform (LPWAV=1) can be selected. The low
power waveform requires two subsequent frames with the same display data to obtain zero DC voltage. Consequently,
the interrupt flag is only set every two frames. Default and the low power waveform is shown in Figure 25-7 on page 304
for 1/3 duty and 1/3 bias. For other selections of duty and bias, the effect is similar.
SEG0-COM0
Frame Frame
VLCD
SEG0
COM0
2/3 VLCD
GND
1/3 VLCD
VLCD
2/3 VLCD
GND
1/3 VLCD
VLCD
2/3 VLCD
GND
1/3 VLCD
-1/3 VLCD
-2/3 VLCD
- VLCD
Frame Frame
VLCD
SEG0
COM1
2/3 VLCD
GND
1/3 VLCD
VLCD
2/3 VLCD
GND
1/3 VLCD
VLCD
2/3 VLCD
GND
1/3 VLCD
-1/3 VLCD
-2/3 VLCD
- VLCD
SEG0-COM1
XMEGA B [MANUAL] 304
8291C–AVR–09/2014
Figure 25-7. Low Power Waveform With Three Common Terminals
25.4.6 Operation in Sleep Modes
The LCD will continue to operate in Idle mode, in Power-save mode and in Extended Standby mode (blinking included).
25.4.7 ASCII Character Mapping
The LCD controller can automatically handle ASCII characters. Instead of setting and clearing segments of the digit, the
user enters the ASCII code and the Digit Decoder updates itself the corresponding segment values in the Display
Memory.
Up to 4 types of character mapping are supported.
Figure 25-8. ASCII Character Mapping
Character mapping saves execution time and allows a fast return to Power-save or Extended Standby mode after display
updates.
25.4.8 Display Blanking
When BLANK is written to one, the LCD is blanked after the completion of the current frame. All segment and common
pins are driven to GND, discharging the LCD. Data in the Display Memory is preserved. Display blanking should be used
before disabling the LCD to avoid DC voltage across the segments, and a slowly fading image.
This mode differs from the one enabled by SEGON = 0 (in CTRLA register) where the segment and common pins are
always driven by the programmed waveform and where all the segments are “OFF”.
7-Segment
- 4 COM term.
- 2 SEG term.
7-Segment
- 3 COM term.
- 3 SEG term.
16-Segment
- 3 COM term.
- 6 SEG term.
14-Segment
- 4 COM term.
- 4 SEG term.
XMEGA B [MANUAL] 305
8291C–AVR–09/2014
25.4.9 Display Blinking
There are two ways to blink the display, controlled from software and controlled automatically by hardware.
25.4.9.1 Software Blinking
Setting / clearing segment(s) in the Display Memory allows software blinking. To blink simultaneously all enabled
segments, SEGON bit in CRTLA register can be used. The blink rate is software dependant.
25.4.9.2 Hardware Blinking
Up to eight segments (pixels) can be configured to automatically blink. These segments must be connected to the
segment terminal SEG1 and/or SEG0. This mode is enabled by setting the BLINKEN bit in the CTRLD register and
defining the associated common terminal(s) in the CTRLE register.The blink rate frequency is configured by using the
BLINKRATE bit-field in the CTRLD register. A segment will blink if its corresponding bit is set in the Display Memory,
otherwise it will remain “OFF”.
If all bits in the CTRLE register are set to zero, then blinking is applied to all enabled segments.
The BLINK command will come into operation at the beginning of the next LCD frame.
Table 25-2. Blinking modes.
Notes: 1. SEGON bit in CTRLA register.
25.4.10 Extended Interrupt Mode
In standard interrupt mode (XIME[4:0]=0), the LCD controller can provide an interrupt every frames. When the extended
interrupt mode is enabled, the LCD controller can provide the interrupt every XIME[4:0]+1 frames.
This mode provides an embedded time base for user. This time base can be used by the software in charge of display
updates (i.e. scrolling text, progress bar, ...).
The extended interrupt mode saves real time resources and allows the application to stay longer in Power-save or
Extended Standby mode.
25.4.11 LCD Power Supply
The LCD power supply manages all voltages for LCD buffers. The XBIAS bit in the CTRLA register defines the source of
V LCD. If XBIAS is cleared, V LCD sources voltages from the Bandgap Reference. Otherwise, V LCD must be powered
externally.
Note that when using external V LCD, the fine contrast controlled by FCONT[5:0] bits of the CRTLG register is inoperative.
SEGON(1) BLINKEN BPS1[3:0] | BPS0[3:0] Comment
0 x 0b xxxx xxxx All segments are “OFF”
1 0 0b xxxx xxxx All segments are driven by the corresponding data registers
1 1
0b 0000 0000 All segments are blinking at the blink frequency
Not equal to zero Blinking only the selected segment(s) at the blink frequency
XMEGA B [MANUAL] 306
8291C–AVR–09/2014
Table 25-3. LCD power supply pins behavior.
Notes: 1. ENABLE and XBIAS bits of the CTRLA register.
Figure 25-9. LCD Power Supply Block Diagram
Different application schemes for bias generation are shown in Figure 25-10 on page 306.
Figure 25-10.Analog Connections vs. Internal or External Bias Generation
ENABLE(1) XBIAS(1) VLCD (pin) BIAS2 BIAS1 CAPH / CAPL
0 x H.Z. H.Z. H.Z. H.Z.
1
0 VLCD
2
/3 VLCD
(also in static mode)
1
/3 VLCD
(also in static mode) Pump voltage
1 Input for VLCD
- Input for BIAS2
- H.Z. if static bias
- Input for BIAS1
- H.Z. if static bias H.Z.
BIAS1
BIAS2
VLCD
CAPL
CAPH
COMy
SEGx XBIAS
x3
x2
x1 BANDGAP
Reference
Pump
Contrast
100 nF
(1)
Internal Generation
Static or 1/3 Bias
ATxmegaB Device
CAPH
CAPL
VCC
VLCD
BIAS2
BIAS1
GND
VCC
100 nF (1)
100 nF (1)
100 nF (1)
ATxmegaB Device
CAPH
CAPL
VCC
VLCD
BIAS2
BIAS1
GND
External Generation
Static
VCC ATxmegaB Device VCC
External Generation (example)
1/3 Bias
Notes :
1: These values are provided for design guidance only. They should be optimized for the application by the designer based on actual LCD specifications.
2: Bias generation can be provided by other sources of voltage than a division resistor.
Ext.VLCD
(2)
(2)
(2)
(2)
Decoupling Decoupling
capacitors capacitors
Decoupling Decoupling
capacitor capacitor
Ext.VLCD
CAPH
CAPL
VCC
VLCD
BIAS2
BIAS1
GND
XMEGA B [MANUAL] 307
8291C–AVR–09/2014
25.4.12 Segment and Common Buses Swapping(1)
Segment and/or common buses can be swapped (mirrored) to give more flexibility for LCD interconnects. The first
segment (or common) terminal pin becomes the last one, and so on.
It is very useful in Chip on Glass (CoG), Chip on Film (CoF) or Chip on Board (CoB) technologies.
SEGSWP bit and COMSWP bit in the CRTLA register control the order of the respective terminal buses.
Note: 1. Refer to specific device datasheet for availability of this feature.
25.4.13 Port Mask
For LCD panels that do not use all the available segment terminals of the device, it is possible to mask some of the
unused pins. PMSK bit-field in the CTRLC register defines the number of segment terminals used in the application. Up
to 16 unused segment terminal pins can be used as standard GPIO pins. They are always placed at the end of the
segment terminal bus. The 8 last pins of this bus will become PG[0:7] - Port G - and the following 8 pins will become
PM[0:7] - Port M.
The GPIO functions on LCD pins are enabled if the corresponding segment terminal is masked or if the LCD controller is
disabled. A pure segment terminal - not shared with GPIO - is grounded via a pull-down resistor if it is masked or if the
LCD controller is disabled.
Note: SEGSWP bit, which reverses the segment terminal indexing, will be active even if the LCD controller is disabled
(ENABLE bit in the CRTLA register) and will thus also modify the GPIO pin mapping.
Examples of a 40-segment LCD controller:
z If 30 segments are used:
Segment terminals [39:32] = PG[0:7] , Port G (GPIO functions)
Segment terminals [31:30] = PM[0:1] , Port M (GPIO functions)
Segment terminals [29:0] = SEG[29:0] , LCD (LCD functions)
z If 20 segments are used:
Segment terminals [39:32] = PG[0:7] , Port G (GPIO functions)
Segment terminals [31:24] = PM[0:7] , Port M (GPIO functions)
Segment terminals [23:20] = GND (pull down)
Segment terminals [19:0] = SEG[19:0] , LCD (LCD functions)
XMEGA B [MANUAL] 308
8291C–AVR–09/2014
25.5 Register Description – LCD
25.5.1 CTRLA – Control register A
z Bit 7 – ENABLE: LCD Enable
Writing this bit to one enables the LCD. By writing it to zero, the LCD is turned “OFF” immediately. Turning the LCD
“OFF” while driving a display, drives the output to ground to discharge the display (apart from segment terminals which
will be controlled by GPIO settings).
z Bit 6 – XBIAS: External Bias Generation
When this bit is set, the LCD buffers which drive the intermediate voltage levels are turned “OFF”. When XBIAS is “OFF”,
an external source for V LCD is necessary.
z Bit 5 – DATLCK: Data Register Lock
Writing this bit to one freezes the Shadow Display Memory. If the Display Memory is modified, the Shadow Display
Memory is locked and the display remains unchanged. When the bit is cleared, the Shadow Display Memory is updated
when a new frame starts (see Figure 25-2 on page 301).
z Bit 4 – COMSWP: Common Terminal Bus Swap(1)
Writing this bit to one inverts the order of the common terminal bus (COM[3:0]). The common terminals disabled by
DUTY[1:0] are also affected (see Table 25-4).
Table 25-4. Common terminal bus reverse.
Note: 1. Refer to specific device datasheet for availability of this feature.
z Bit 3 – SEGSWP: Segment Terminal Bus Swap(1)
Writing this bit to one inverts completely the order of the segment terminal bus (SEG[39:0]). The segment terminals unselected
by PMSK[5:0] are also affected (see Table 25-5 on page 309).
Bit 7 6 5 4 3 2 1 0
+0x00 ENABLE XBIAS DATLCK COMSWP SEGSWP CLRDT SEGON BLANK
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
DUTY[1:0] Number of COM COMSWP = 0 COMSWP = 1
00 4 COM3,COM2,COM1,COM0 COM0,COM1,COM2,COM3
01 1 –, –, –, COM0 COM0, –, –, –
10 2 –, –, COM1, COM0 COM0, COM1, –, –
11 3 –, COM2, COM1, COM0 COM0, COM1, COM2, –
XMEGA B [MANUAL] 309
8291C–AVR–09/2014
Table 25-5. Segment terminal bus reverse (examples)
Note: 1. Refer to specific device datasheet for availability of this feature.
z Bit 2 – CLRDT: Clear Data Register
Writing this bit to one clears immediately the Display Memory (but not the control registers). The display will be blanked
after completion of a frame. This bit is automatically reset once the Display Memory is cleared.
z Bit 1 – SEGON: Segments “ON”.
Writing this bit to one enables all segments and the contents of the Display Memory is output on the LCD. Writing it to
zero, turns “OFF” all LCD segments.
This bit can be used to flash the LCD, leaving the LCD timing generator enabled.
z Bit 0 – BLANK: Blanking Display Mode
When this bit is written to one, the display will be blanked after completion of a frame. All segment and common terminals
will be driven to ground. (For more details see “Display Blanking” on page 304). This function does not modify the Display
Memory.
25.5.2 CTRLB – Control register B
z Bit 7 – PRESC: LCD Prescaler Select
The PRESC bit selects a tap point from a ripple counter. The ripple counter output can be further divided by setting the
Clock Divider (CLKDIV[2:0]). The different selections are shown in Table 25-6. Together they define the prescaler LCD
clock (clk LCD_PS), which is clocking the LCD controller.
Table 25-6. LCD prescaler selection.
PMSK[5:0] Number of SEG SEGSWP = 0 SEGSWP = 1
000100 4 (SEG [39:4] unused), SEG[3:0] SEG[0:3], (SEG[4:39] unused)
001000 8 (SEG[39:8] unused), SEG[7:0] SEG[0:7], (SEG[8:39] unused)
010000 16 (SEG[39:16] unused), SEG[15:0] SEG[0:15], (SEG[16:39] unused)
101000 40 SEG[39:0] SEG[0:39]
Bit 7 6 5 4 3 2 1 0
+0x01 PRESC CLKDIV[2:0] LPWAV – DUTY[1:0]
Read/Write R/W R/W R/W R/W R/W R R/W R/W
Initial Value 0000 0 0 0 0
PRESC
Output From Ripple Counter
clk LCD / N
Frame Rates (CLKDIV[2:0] = 0, DUTY = 1
/4 )
F(clk LCD) = 32kHz F(clk LCD) = 32768Hz
0 clk LCD / 8 500 Hz 512 Hz
1 clk LCD / 16 250 Hz 256 Hz
XMEGA B [MANUAL] 310
8291C–AVR–09/2014
z Bit 6:4 – CLKDIV[2:0]: LCD Clock Division
The CLKDIV bit-field defines the division ratio in the clock divider. The various selections are shown in Table 25-7. This
Clock Divider gives extra flexibility in frame rate setting.
Frame rate equation:
Where:
N = prescaler divider (8 or 16).
K = 8 for 1/4, 1/2 and static duty.
K = 6 for 1/3 duty.
Table 25-7. LCD clock divider (1/4 dyty).
Note that when using 1/3 duty, the frame rate is increased by 33% compared to the values listed above.
Table 25-8. Example of frame rate calculation.
z Bit 3 – LPWAV: Low Power Waveform
When LPWAV is written to one, the low power waveform is outputted on LCD pins, otherwise the standard waveform is
outputted. If this bit is modified during display operation the change takes place at the beginning of the next frame. (For
more details see “Low Power Waveform” on page 303).
z Bit 2 – Reserved
This bit is unused and reserved for future use. For compatibility with future devices, always write this bit to zero when this
register is written.
CLKDIV[2:0] Divided by
Frame Rate (1/4 Duty)
F(clk LCD) = 32 kHz F(clk LCD) = 32768 Hz
N=8 N=16 N=8 N=16
000 1 500 Hz 250 Hz 512 Hz 256 Hz
001 2 250 Hz 125 Hz 256 Hz 128 Hz
010 3 166.667 Hz 83.333 Hz 170.667 Hz 85.333 Hz
011 4 125 Hz 62.5 Hz 128 Hz 64 Hz
100 5 100 Hz 50 Hz 102.4 Hz 51.2 Hz
101 6 83.333 Hz 41.667 Hz 85.333 Hz 42.667 Hz
110 7 71.429 Hz 35.714 Hz 73.143 Hz 36.671 Hz
111 8 62.5 Hz 31.25 Hz 64 Hz 32 Hz
clk LCD Duty K PRESC N CLKDIV[2:0] Frame rate
32.768kHz Static 8 1 16 4 32768 / ( 8 x 16 x ( 1 + 4 ) ) = 51.2Hz
32.768kHz 1/2 8 1 16 4 32768 / ( 8 x 16 x ( 1 + 4 ) ) = 51.2Hz
32.768kHz 1/3 6 1 16 4 32768 / ( 6 x 16 x ( 1 + 4 ) ) = 68.267Hz
32.768kHz 1/4 8 1 16 4 32768 / ( 8 x 16 x ( 1 + 4 ) ) = 51.2Hz
FrameRate
F clkLCD ( )
(K N× × ( ) 1 + CLKDIV ) = ----------------------------------------------------------------
XMEGA B [MANUAL] 311
8291C–AVR–09/2014
z Bits 1:0 – DUTY[1:0]: Duty Select(1)
The DUTY bit-field defines the duty cycle. Common pins that are not used will be driven to ground. The different duty
selections are shown in Table 25-9.
Table 25-9. Duty cycle.
Note: 1. Refer to specific device datasheet for duty cycles availability (linked to the number of available common terminals).
25.5.3 CTRLC – Control register C
z Bits 7:6 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bits 5:0 – PMSK[5:0]: LCD Port Mask
The PMSK bit-field defines the number of port pins to be used as segment drivers. The unused pins will be driven to
ground except the 16 highest pins which become GPIO's.
25.5.4 INTCTRL – Interrupt Control register
z Bits 7:3 – XIME[4:0]: eXtended Interrupt Mode Enable
XIME bit-field defines the number of frames to be completed for one interrupt period.
Interrupt Period = ( ( XIME[4:0] + 1 ) x 2LPWAV ) frames
z For default waveforms, the FCIF flag is generated every XIME[4:0] + 1 frames. The range is 1 up to 32 frames.
z For low power waveforms requiring 2 subsequent frames, the FCIF flag is generated every
2 x ( XIME[4:0] + 1 ) frames. The range is 2 up to 64 frames.
Note: This extended interrupt mode generates a stable time base from the frame rate.
z Bit 2 – Reserved
This bit is unused and reserved for future use. For compatibility with future devices, always write this bit to zero when this
register is written.
DUTY[1:0] Duty Bias COM pins Used
0 0 1/4 1/3 COM[0:3]
0 1 Static Static COM0
1 0 1/2 1/3 COM[0:1]
1 1 1/3 1/3 COM[0:2]
Bit 7 6 5 4 3 2 1 0
+0x02 – – PMSK[5:0]
Read/Write R R R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
Bit 7 6 5 4 3 2 1 0
+0x03 XIME[4:0] – FCINTLVL[1:0]
Read/Write R/W R/W R/W R/W R/W R R/W R/W
Initial Value 0 0 000000
XMEGA B [MANUAL] 312
8291C–AVR–09/2014
z Bits 1:0 – FCINTLVL[1:0]: Interrupt Level
This bit-field enables the LCD frame completed interrupt and selects the interrupt level as described in “Interrupts and
Programmable Multilevel Interrupt Controller” on page 121. The enabled interrupt will be triggered when the FCIF flag in
the INTFLAGS register is set.
25.5.5 INTFLAGS – Interrupt Flag register
z Bits 7:1 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 0 – FCIF: LCD Frames Completed Interrupt Flag
The generation of this flag depends on the XIME value in the INTCTRL register.
This bit is set by hardware at the beginning of a frame. FCIF is cleared by hardware when executing the corresponding
interrupt handling routine. Alternatively, writing a logical one to the flag clears FCIF.
25.5.6 CTRLD – Control register D
z Bits 7:4 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 3 – BLINKEN: Blink Enable
Writing this bit to one, the blink mode starts at the frequency specified by LCD blink rate (BLINKRATE). By writing it to
zero, the LCD blink module stops. This BLINKEN bit takes effect at the beginning of the next LCD frame. (For more
details see “Display Blinking” on page 305).
z Bit 2 – Reserved
This bit is unused and reserved for future use. For compatibility with future devices, always write this bit to zero when this
register is written.
z Bits 1:0 – BLINKRATE[1:0]: LCD Blink Rate
The BLINKRATE bit-field defines the frequency of the hardware Display Blinking when the BLINKEN bit is set. Blink
frequencies are shown in Table 25-10.
Table 25-10. Blink frequencies.
Bit 7 6 5 4 3 2 1 0
+0x04 – – – – – – – FCIF
Read/Write R R R R R R R R/W
Initial Value 0 0 0 0 0 0 0 0
Bit 7 6 5 4 3 2 1 0
+0x05 – – – – BLINKEN – BLINKRATE[1:0]
Read/Write R R R R R/W R R/W R/W
Initial Value 0 0 0 0 0 0 0 0
BLINKRATE[1:0] Blink frequency
00 4Hz
01 2Hz
10 1Hz
11 0.5Hz
XMEGA B [MANUAL] 313
8291C–AVR–09/2014
25.5.7 CTRLE – Control register E
z Bits 7:4 – BPS1[3:0]: Blink Segment Selection 1
This bit-field defines the segment which is connected on SEG1 for blinking. Each bit of BPS1[3:0] corresponds to one of
the common terminals.
z Bits 3:0 – BPS0[3:0]: Blink Segment Selection 0
This bit-field defines the segment which is connected on SEG0 for blinking. Each bit of BPS0[3:0] corresponds to one of
the common terminals.
Note: If no segment to blink is selected (BPS1[3:0] = BPS1[3:0] = 0) and if the BLINKEN bit is set, then the full display is
blinking.
25.5.8 CTRLF – Control register F
z Bits 7:6 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bits 5:0 – FCONT[5:0]: Fine Contrast
FCONT bit-field defines the maximum voltage clk LCD on segment and common pins. FCONT is a signed number (two's
complement). New values take effect at the beginning of each frame.
VLCD = 3.0 V + ( FCONT[5:0] x 0.016 V )
25.5.9 CTRLG – Control register G
z Bits 7:6 – TDG[1:0]: Type of Digit(1)
This bit-field specifies the number of segments and segment/common connections used to display a digit. See Table 25-
11 and Figure 25-11 on page 314.
Bit 7 6 5 4 3 2 1 0
+0x06 BPS1[3:0] BPS0[3:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
Bit 7 6 5 4 3 2 1 0
+0x07 – – FCONT[5:0]
Read/Write R R R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
Bit 7 6 5 4 3 2 1 0
+0x08 TDG[1:0] STSEG[5:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 00000000
XMEGA B [MANUAL] 314
8291C–AVR–09/2014
Table 25-11. Type of digits.
Note: 1. Refer to specific device datasheet for “Type of Digit” availability.
z Bits 5:0 – STSEG[5:0]: Start Segment
STSEG bit-field defines the first segment terminal used to write the decoded display. This bit-field is automatically
incremented or decremented (according to the DEC value of CTRLH register) by the number of segment terminals used
in the digit.
Figure 25-11.Segment and Common Terminal Connections for Digit
25.5.10 CTRLH – Control register H
z Bit 7 – DEC: Decrement of Start Segment
Writing this bit to one automatically decrements the STSEG bit-field of CTRLG register by the number of segment
terminals used by the digit. If this bit is written to zero, the STSEG bit-field is incremented by the number of segment
terminals used by the digit. This action takes place once the digit decoding is finished and prepares the next call to the
Digit Decoder.
z Bits 6:0 – DCODE[6:0]: Display Code
DCODE bit-field will be computed by the Digit Decoder, and converted to display codes, and then automatically written
into the Display Memory according to the STSEG value. This Digit Decoder can be used when the LCD panel is defined
with one or more of the configurations above in Figure 25-11 on page 314.
TDG[1:0] Digit Type
00 7-segment with 3 common terminals, COM[2:0]
01 7-segment with 4 common terminals, COM[3:0]
10 14-segment with 4 common terminals, COM[3:0]
11 16-segment with 3 common terminals, COM[2:0]
a
e
f
d
g
b
c
SEGn : a, b, c
SEGn+1 : d, e, f, g
COM0 : a, f
COM1 : b, g
COM2 : c, e
COM3 : d
a 7-segment with 4 COM
e
f
d
g
b
c
SEGn : b, c
SEGn+1 : a, d, g
SEGn+2 : e, f
COM0 : a, b, f
COM1 : c, e, g
COM2 : d
7-segment with 3 COM
SEGn : h, i, k, n
SEGn+1 : d, e, f
SEGn+2 : a, b, c
SEGn+3 : g, j, l, m
COM0 : a, g, h
COM1 : b, i, j, f
COM2 : c, e, k, l
COM3 : d, m, n
a 14-segment with 4 COM
e
f
d
j
b
c
k
g i
l n m
h SEGn : h, g, n
SEGn+1 : a, i, l
SEGn+2 : b, k, m
SEGn+3 : c, d, e
SEGn+4 : j, o, p
SEGn+5 : f
COM0 : h, a, b, c, j
COM1 : g, i, k, d, o
COM2 : n, l, m, p, e, f
16-segment with 3 COM
f e
a b
g
h
l
c
d
m
i k
n p o
j
Bit 7 6 5 4 3 2 1 0
+0x09 DEC DCODE[6:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0000000
XMEGA B [MANUAL] 315
8291C–AVR–09/2014
The Table 25-12 on page 315, Table 25-13 on page 316 and Table 25-14 on page 317 show the DCODE[6:0] and
display pattern.
The table entry code, DCODE [6:0], is the 7-bit ASCII code of the digit.
Table 25-12. 7-segments Character Table.
XMEGA B [MANUAL] 316
8291C–AVR–09/2014
Table 25-13. 14-segments Character Table.
XMEGA B [MANUAL] 317
8291C–AVR–09/2014
Table 25-14. 16-segments Character Table.
XMEGA B [MANUAL] 318
8291C–AVR–09/2014
25.5.11 DATA – LCD Data Memory Mapping
The Display Memory provides access to control the “ON/OFF” state for segments.
Data Memory register offset versus segment (pixel) coordinates (pixel_COM, pixel_SEG):
z LCD_offset = 0x10 + ( pixel_COM x ⎣(Max_SEG + 7 ) / 8⎦ ) + ⎣pixel_SEG / 8⎦
Where: . 0x10 is the hexadecimal offset of DATA0 register,
. Max_SEG is the maximal number of SEG terminals of the device,
.⎣xxx⎦ means the integer part of xxx.
Bit position of the segment (pixel) in the Data Memory register (between 0 and 7):
z bit_position = pixel_SEG % 8
Where: . % is the modulo operation.
Bit 76543210
+0x23 PIX159 PIX158 PIX157 PIX156 PIX155 PIX154 PIX153 PIX152 DATA19
+0x22 PIX[151:144] DATA18
+0x21 PIX[143:136] DATA17
+0x20 PIX[135:128] DATA16
+0x1F PIX[127:120] DATA15
+0x1E PIX[119:112] DATA14
+0x1D PIX[111:104] DATA13
+0x1C PIX[103:96] DATA12
+0x1B PIX[95:88] DATA11
+0x1A PIX[87:80] DATA10
+0x19 PIX[79:72] DATA9
+0x18 PIX[71:64] DATA8
+0x17 PIX[63:56] DATA7
+0x16 PIX[55:48] DATA6
+0x15 PIX[47:40] DATA5
+0x14 PIX[39:32] DATA4
+0x13 PIX[31:24] DATA3
+0x12 PIX[23:16] DATA2
+0x11 PIX[15:8] DATA1
+0x10 PIX7 PIX6 PIX5 PIX4 PIX3 PIX2 PIX1 PIX0 DATA0
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial
Value 00000000
XMEGA B [MANUAL] 319
8291C–AVR–09/2014
25.6 Register Summary – LCD
25.7 Interrupt Vector Summary
Address Name Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 Page
+0x24 to Reserved – – – – – – – –
+0x23 DATA19 PIX[159:152] 318
+0x22 DATA18 PIX[151:144] 318
+0x21 DATA17 PIX[143:136] 318
+0x20 DATA16 PIX[135:128] 318
+0x1F DATA15 PIX[127:120] 318
+0x1E DATA14 PIX[119:112] 318
+0x1D DATA13 PIX[111:104] 318
+0x1C DATA12 PIX[103:96] 318
+0x1B DATA11 PIX[95:88] 318
+0x1A DATA10 PIX[87:80] 318
+0x19 DATA9 PIX[79:72] 318
+0x18 DATA8 PIX[71:64] 318
+0x17 DATA7 PIX[63:56] 318
+0x16 DATA6 PIX[55:48] 318
+0x15 DATA5 PIX[47:40] 318
+0x14 DATA4 PIX[39:32] 318
+0x13 DATA3 PIX[31:24] 318
+0x12 DATA2 PIX[23:16] 318
+0x11 DATA1 PIX[15:8] 318
+0x10 DATA0 PIX[7:0] 318
+0x0A to Reserved – – – – – – – –
+0x09 CTRLH DEC DCODE[6:0] 314
+0x08 CTRLG TDG[1:0] STSEG[5:0] 313
+0x07 CTRLF – – FCONT[5:0] 313
+0x06 CTRLE BPS1[3:0] BPS0[3:0] 313
+0x05 CTRLD – – – – BLINKEN – BLINKRATE[1:0] 312
+0x04 INTFLAGS – – – – – – – FCIF 312
+0x03 INTCTRL XIME[4:0] – FCINTLVL[1:0] 311
+0x02 CTRLC – – PMSK[5:0] 311
+0x01 CTRLB PRESC CLKDIV[2:0] LPWAV – DUTY[1:0] 309
+0x00 CTRLA ENABLE XBIAS DATLCK COMSWP SEGSWP CLRDT SEGON BLANK 308
Offset Source Interrupt Description
0x00 LCD_vect LCD Interrupt vector
XMEGA B [MANUAL] 320
Atmel-8291C-AVR-XMEGA B -09/2014
26. ADC – Analog-to-Digital Converter
26.1 Features
z 12-bit resolution
z Up to 300 thousand samples per second
z Down to 2.3μs conversion time with 8-bit resolution
z Down to 3.35μs conversion time with 12-bit resolution
z Differential and single-ended input
z Up to 16 single-ended inputs
z Up to 16x4 differential inputs without gain
z 8x4 differential input with gain
z Built-in differential gain stage
z 1/2x, 1x, 2x, 4x, 8x, 16x, 32x, and 64x gain options
z Single, continuous and scan conversion options
z Three internal inputs
z Internal temperature sensor
z AVCC voltage divided by 10
z 1.1V bandgap voltage
z Internal and external reference options
z Compare function for accurate monitoring of user defined thresholds
z Optional DMA transfer of conversion results
z Optional event triggered conversion for accurate timing
z Optional interrupt/event on compare result
26.2 Overview
The ADC converts analog signals to digital values. The ADC has 12-bit resolution and is capable of converting up to 300
thousand samples per second (ksps). The input selection is flexible, and both single-ended and differential
measurements can be done. For differential measurements, an optional gain stage is available to increase the dynamic
range. In addition, several internal signal inputs are available. The ADC can provide both signed and unsigned results.
The ADC measurements can either be started by application software or an incoming event from another peripheral in
the device. The ADC measurements can be started with predictable timing, and without software intervention. It is
possible to use DMA to move ADC results directly to memory or peripherals when conversions are done.
Both internal and external reference voltages can be used. An integrated temperature sensor is available for use with the
ADC. The AVCC/10 and the bandgap voltage can also be measured by the ADC.
The ADC has a compare function for accurate monitoring of user defined thresholds with minimum software intervention
required.
XMEGA B [MANUAL] 321
Atmel-8291C-AVR-XMEGA B -09/2014
Figure 26-1. ADC overview.
26.3 Input Sources
Input sources are the voltage inputs that the ADC can measure and convert. Four types of measurements can be
selected:
z Differential input
z Differential input with gain
z Single-ended input
z Internal input
The input pins are used for single-ended and differential input, while the internal inputs are directly available inside the
device. In devices with two ADCs, PORTA pins can be input to ADCA and PORTB pins can be input to ADCB. For the
devices with only one ADC, input pins may be available for ADCA on both PORTA and PORTB.
The ADC is differential, and so for single-ended measurements the negative input is connected to a fixed internal value.
The four types of measurements and their corresponding input options are shown in Figure 26-2 on page 322 to Figure
26-6 on page 324.
26.3.1 Differential Input
When differential input is enabled, all input pins can be selected as positive input, and input pins 0 to 3 can be selected
as negative input. The ADC must be in signed mode when differential input is used.
CH0 Result
Compare
Register
<
> Threshold
(Int Req)
Internal 1.00V
Internal AVCC/1.6V
AREFA
AREFB
VINP
VINN
Internal
signals
S&H Σ
ADC DAC
2x
2 bits
VIN VOUT
Internal AVCC/2
ADC0
ADC15
•
•
•
ADC0
ADC7
•
•
•
Reference
Voltage
Stage
1
Stage
2
Digital Correction Logic
2 2
clkADC
CH0.CTRL REFCTRL
CH0.MUXCTRL
CTRLA EVCTRL
CTRLB
Enable
Start
Mode
Resolution
Action
Select
XMEGA B [MANUAL] 322
Atmel-8291C-AVR-XMEGA B -09/2014
Figure 26-2. Differential measurement without gain.
26.3.2 Differential Input with Gain
When differential input with gain is enabled, all input pins can be selected as positive input, and input pins 4 to 7 can be
selected as negative input. When gain is enabled, the differential input is first sampled and amplified by the gain stage
before the result is converted. The ADC must be in signed mode when differential input with gain is used.
The gain is selectable to 1/2x, 1x, 2x, 4x, 8x, 16x, 32x, and 64x gain.
Figure 26-3. Differential measurement with gain.
26.3.3 Single-ended Input
For single-ended measurements, all input pins can be used as inputs. Single-ended measurements can be done in both
signed and unsigned mode.
The negative input is connected to internal ground in signed mode.
+
- ADC0
ADC3
ADC0
ADC15
•
•
•
•
•
•
GND
INTGND
+
- ADC4
ADC7
ADC0
ADC7
•
•
•
•
•
•
GND
INTGND
½x - 64x
XMEGA B [MANUAL] 323
Atmel-8291C-AVR-XMEGA B -09/2014
Figure 26-4. Single-ended measurement in signed mode.
In unsigned mode, the negative input is connected to half of the voltage reference (VREF) voltage minus a fixed offset.
The nominal value for the offset is:
Since the ADC is differential, the input range is VREF to zero for the positive single-ended input. The offset enables the
ADC to measure zero crossing in unsigned mode, and allows for calibration of any positive offset when the internal
ground in the device is higher than the external ground. See Figure 26-11 on page 326 for details.
Figure 26-5. Single-ended measurement in unsigned mode.
26.3.4 Internal Inputs
These internal signals can be measured or used by the ADC.
z Temperature sensor
z Bandgap voltage
z AVCC scaled
z Pad and Internal Ground
The temperature sensor gives an output voltage that increases linearly with the internal temperature of the device. One
or more calibration points are needed to compute the temperature from a measurement of the temperature sensor. The
temperature sensor is calibrated at one point in production test, and the result is stored to TEMPESENSE0 and
TEMPSENSE1 in the production signature row. For more calibration condition details, refer to the device datasheet.
The bandgap voltage is an accurate internal voltage reference.
VCC can be measured directly by scaling it down by a factor of 10 before the ADC input. Thus, a VCC of 1.8V will be
measured as 0.18V, and VCC of 3.6V will be measured as 0.36V. This enables easy measurement of the VCC voltage.
The internal signals need to be enabled before they can be measured. Refer to their manual sections for Bandgap for
details of how to enable these. The sample rate for the internal signals is lower than that of the ADC. Refer to the ADC
characteristics in the device datasheets for details.
For differential measurement Pad Ground (Gnd) and Internal Gnd can be selected as negative input. Pad Gnd is the gnd
level on the pin and identical or very close to the external gnd. Internal Gnd is the internal device gnd level.
Internal Gnd is used as the negative input when other internal signals are measured in single-ended signed mode.
• +
ADC -
ADC0
ADC15
•
•
ΔV VREF = × 0.05
•
• +
ADC -
ADC0
ADC15
−ΔV VREF
____
2
•
XMEGA B [MANUAL] 324
Atmel-8291C-AVR-XMEGA B -09/2014
Figure 26-6. Internal measurements in single-ended signed mode.
To measure the internal signals in unsigned mode, the negative input is connected to a fixed value given by the formula
below, which is half of the voltage reference (VREF) minus a fixed offset, as it is for single-ended unsigned input. Refer to
Figure 26-11 on page 326 for details.
VINN = VREF/2 - ΔV
Figure 26-7. Internal measurements in unsigned mode.
26.4 Sampling Time Control
To support applications with high source output resistance, the sampling time can be increased by steps of one half ADC
clock cycle up to 64 ADC clock cycles.
26.5 Voltage Reference Selection
The following voltages can be used as the reference voltage (VREF) for the ADC:
z Accurate internal 1.00V voltage generated from the bandgap
z Internal AVCC/1.6V voltage
z Internal AVCC/2V voltage
z External voltage applied to AREF pin on PORTA
z External voltage applied to AREF pin on PORTB
Figure 26-8. ADC voltage reference selection
+
ADC -
TEMP REF
AVCC SCALED
BANDGAP REF
+
ADC -
TEMP REF
AVCC SCALED
BANDGAP REF
−ΔV VREF
____
2
Internal 1.00V
AREFB
AREFA
Internal AVCC/1.6V
Internal AVCC/2.0V VREF
XMEGA B [MANUAL] 325
Atmel-8291C-AVR-XMEGA B -09/2014
26.6 Conversion Result
The result of the analog-to-digital conversion is written to the channel result register. The ADC is either in signed or
unsigned mode. This setting is global for the ADC and for the ADC channel.
In signed mode, negative and positive results are generated. Signed mode must be used when the ADC channel is set
up for differential measurements. In unsigned mode, only single-ended or internal signals can be measured. With 12-bit
resolution, the TOP value of a signed result is 2047, and the results will be in the range -2048 to +2047 (0xF800 -
0x07FF).
The ADC transfer function can be written as:
VINP and VINN are the positive and negative inputs to the ADC.
For differential measurements, GAIN is 1/2 to 64. For single-ended and internal measurements, GAIN is always 1 and
VINP is the internal ground.
In unsigned mode, only positive results are generated. The TOP value of an unsigned result is 4095, and the results will
be in the range 0 to +4095 (0x0 - 0x0FFF).
The ADC transfer functions can be written as:
VINP is the single-ended or internal input.
The ADC can be configured to generate either an 8-bit or a 12-bit result. A result with lower resolution will be available
faster. See the “ADC Clock and Conversion Timing” on page 326 for a description on the propagation delay.
The result register is 16 bits wide, and data are stored as right adjusted 16-bit values. Right adjusted means that the
eight least-significant bits (lsb) are found in the low byte. A 12-bit result can be represented either left or right adjusted.
Left adjusted means that the eight most-significant bits (msb) are found in the high byte.
When the ADC is in signed mode, the msb represents the sign bit. In 12-bit right adjusted mode, the sign bit (bit 11) is
padded to bits 12-15 to create a signed 16-bit number directly. In 8-bit mode, the sign bit (bit 7) is padded to the entire
high byte.
Figure 26-9 on page 325 to Figure 26-11 on page 326 show the different input options, the signal input range, and the
result representation with 12-bit right adjusted mode.
Figure 26-9. Signed differential input (with gain), input range, and result representation.
RES VINP - VINN
VREF = --------------------------------- GAIN TOP +1 ⋅ ⋅ ( )
RES VINP - (-ΔV )
VREF = ---------------------------------- ⋅ ( ) TOP +1
2047
2046
2045
...
3
2
1
0
-1
...
-2045
-2046
-2047
-2048
7FF
7FE
7FD
...
3
2
1
0
FFF
FFE
...
803
802
801
800
Dec Hex
0111 1111 1111
0111 1111 1110
0111 1111 1101
...
0000 0000 0011
0000 0000 0010
0000 0000 0001
0000 0000 0000
1111 1111 1111
1111 1111 1110
...
1000 0000 0011
1000 0000 0010
1000 0000 0001
1000 0000 0000
Binary
0000 0111 1111 1111
0000 0111 1111 1110
0000 0111 1111 1101
...
0000 0000 0000 0011
0000 0000 0000 0010
0000 0000 0000 0001
0000 0000 0000 0000
1111 1111 1111 1111
1111 1111 1111 1110
...
1111 1000 0000 0011
1111 1000 0000 0010
1111 1000 0000 0001
1111 1000 0000 0000
VREF 16-bit result register
GAIN
-VREF
GAIN
0 V
VINN
RES
VINP
-2
XMEGA B [MANUAL] 326
Atmel-8291C-AVR-XMEGA B -09/2014
Figure 26-10.Signed single-ended and internal input, input range, and result representation.
Figure 26-11.Unsigned single-ended and internal input, input range, and result representation.
26.7 Compare Function
The ADC has a built-in 12-bit compare function. The ADC compare register can hold a 12-bit value that represents a
threshold voltage. The ADC channel can be configured to automatically compare its result with this compare value to
give an interrupt or event only when the result is above or below the threshold.
26.8 Starting a Conversion
Before a conversion is started, the input source must be selected. An ADC conversion can be started either by the
application software writing to the start conversion bit or from any events in the event system.
26.8.1 Input Source Scan
It is possible to select a range of consecutive input sources that is automatically scanned and measured when a
conversion is started. This is done by setting the first (lowest) positive ADC channel input using the MUX control register,
and a number of consecutive positive input sources. When a conversion is started, the first selected input source is
measured and converted, then the positive input source selection is incremented after each conversion until it reaches
the specified number of sources to scan.
26.9 ADC Clock and Conversion Timing
The ADC is clocked from the peripheral clock. The ADC can prescale the peripheral clock to provide an ADC Clock
(clkADC) that matches the application requirements and is within the operating range of the ADC.
2047
2046
2045
...
3
2
1
0
-1
-2
...
-2045
-2046
-2047
-2048
7FF
7FE
7FD
...
3
2
1
0
FFF
FFE
...
803
802
801
800
Dec Hex
0111 1111 1111
0111 1111 1110
0111 1111 1101
...
0000 0000 0011
0000 0000 0010
0000 0000 0001
0000 0000 0000
1111 1111 1111
1111 1111 1110
...
1000 0000 0011
1000 0000 0010
1000 0000 0001
1000 0000 0000
Binary
0000 0111 1111 1111
0000 0111 1111 1110
0000 0111 1111 1101
...
0000 0000 0000 0011
0000 0000 0000 0010
0000 0000 0000 0001
0000 0000 0000 0000
1111 1111 1111 1111
1111 1111 1111 1110
...
1111 1000 0000 0011
1111 1000 0000 0010
1111 1000 0000 0001
1111 1000 0000 0000
16-bit result register VREF
-VREF
0 V
VINP
VINN = GND
4095
4094
4093
...
203
202
201
200
FFF
FFE
FFD
...
0CB
0CA
0C9
0C8
Dec Hex
1111 1111 1111
1111 1111 1110
1111 1111 1101
...
0000 1100 1011
0000 1100 1010
0000 1100 1001
0000 1100 1000
Binary
0000 1111 1111 1111
0000 1111 1111 1110
0000 1111 1111 1101
...
0000 0000 1100 1011
0000 0000 1100 1010
0000 0000 1100 1001
0000 0000 1100 1000
16-bit result register
V VREF VINN = − Δ
2 GND
VREF − ΔV
VINP
...
0 0 0000 0000 0000 0000 0000 0000 0000
XMEGA B [MANUAL] 327
Atmel-8291C-AVR-XMEGA B -09/2014
Figure 26-12.ADC prescaler.
The propagation delay of an ADC measurement is given by:
RESOLUTION is the resolution, 8 or 12 bits. The propagation delay will increase by extra ADC clock cycles if the gain
stage (GAIN) is used. A new ADC conversion can start as soon as the previous is completed.
The most-significant bit (msb) of the result is converted first, and the rest of the bits are converted during the next three
(for 8-bit results) or five (for 12-bit results) ADC clock cycles. Converting one bit takes a half ADC clock period. During the
last cycle, the result is prepared before the interrupt flag is set and the result is available in the result register for readout.
26.9.1 Single Conversion without Gain
Figure 26-13 on page 327 shows the ADC timing for a single conversion without gain. The writing of the start conversion
bit, or the event triggering the conversion (START), must occur at least one peripheral clock cycle before the ADC clock
cycle on which the conversion starts (indicated with the grey slope of the START trigger).
The input source is sampled in the first half of the first cycle.
Figure 26-13.ADC timing for one single conversion without gain.
9-bit ADC Prescaler
ClkADC
PRESCALER[2:0]
CLK/4
CLK/8
CLK/16
CLK/32
CLK/64
CLK/128
ClkPER
CLK/256
CLK/512
Propagation Delay =
1 RESOLUTION + 1
2
+ + ------------------------------------------------ GAIN
f ADC
--------------------------------------------------------------------------------
clkADC
START
ADC SAMPLE
IF
CONVERTING BIT 10 9 8 7 6 5 4 3 2 1 lsb
12345678
msb
9
XMEGA B [MANUAL] 328
Atmel-8291C-AVR-XMEGA B -09/2014
Figure 26-14.ADC timing for one single conversion with increased sampling time (SAMPVAL = 6).
26.9.2 Single Conversion with Gain
Figure 26-15 on page 328 to Figure 26-17 on page 329 show the ADC timing for one single conversion with various gain
settings. As seen in the “Overview” on page 320, the gain stage is built into the ADC. Gain is achieved by running the
signal through a pipeline stage without converting. Compared to a conversion without gain, each gain multiplication of 2
adds one half ADC clock cycle propagation delay.
Figure 26-15.ADC timing for one single conversion with 2x gain.
Figure 26-16.ADC timing for one single conversion with 8x gain.
CONVERTING BIT
START
IF
ADC SAMPLE
msb 10 9 8 7 6 5 4 3 2 1 lsb
clkADC
123456789
CONVERTING BIT
START
IF
ADC SAMPLE
AMPLIFY
msb 10 9 8 7 6 5 4 3 2 1 lsb
clkADC
123456789
CONVERTING BIT
START
IF
ADC SAMPLE
AMPLIFY
msb 10 9 8 7 6 5 4 3 2 1 lsb
clkADC
123456789
XMEGA B [MANUAL] 329
Atmel-8291C-AVR-XMEGA B -09/2014
Figure 26-17.ADC timing for one single conversion with 64x gain.
26.10 ADC Input Model
The voltage input must charge the sample and hold (S/H) capacitor in the ADC in order to achieve maximum accuracy.
Seen externally, the ADC input consists of an input resistance (Rin = Rchannel + Rswitch) and the S/H capacitor (Csample).
Figure 26-18 on page 329 and Figure 26-19 on page 329 show the ADC input channel.
Figure 26-18.ADC input for single-ended measurements.
Figure 26-19.ADC input for differential measurements and differential measurements with gain.
In order to achieve n bits of accuracy, the source output resistance, Rsource, must be less than the ADC input resistance
on a pin:
where the ADC sample time, TS is one-half the ADC clock cycle given by:
For details on Rchannel, Rswitch, and Csample, refer to the ADC electrical characteristic in the device datasheet.
CONVERTING BIT
START
IF
ADC SAMPLE
AMPLIFY
msb 10 9 8 7 6 5 4 3 2 1 lsb
clkADC
123456789 10
Rsource
Ts
Csample 2
n + 1 ⋅ ln( )
---------------------------------------------- Rchannel – Rswitch ≤ –
Ts
1
2 ⋅ f ADC
≤ ---------------------
XMEGA B [MANUAL] 330
Atmel-8291C-AVR-XMEGA B -09/2014
26.11 DMA Transfer
The DMA controller can be used to transfer ADC conversion results to memory or other peripherals. A new conversion
result can trigger a DMA transaction. Refer to “DMAC - Direct Memory Access Controller” on page 47 for more details on
DMA transfers.
26.12 Interrupts and Events
The ADC can generate interrupt requests and events. The ADC channel has individual interrupt settings and interrupt
vectors. Interrupt requests and events can be generated when an ADC conversion is complete or when an ADC
measurement is above or below the ADC compare register value.
26.13 Calibration
The ADC has built-in linearity calibration. The value from the production test calibration must be loaded from the
signature row and into the ADC calibration register from software to achieve specified accuracy. User calibration of the
linearity is not needed, hence not possible. Offset and gain calibration must be done in software.
26.14 Synchronous Sampling
Starting an ADC conversion can cause an unknown delay between the start trigger or event and the actual conversion
since the peripheral clock is faster than the ADC clock. To start an ADC conversion immediately on an incoming event, it
is possible to flush the ADC of all measurements, reset the ADC clock, and start the conversion at the next peripheral
clock cycle (which then will also be the next ADC clock cycle). If this is done, the ongoing conversions in the ADC will be
lost.
The ADC can be flushed from software, or an incoming event can do this automatically. When this function is used, the
time between each conversion start trigger must be longer than the ADC propagation delay to ensure that one
conversion is finished before the ADC is flushed and the next conversion is started.
It is also important to clear pending events or start ADC conversion commands before doing a flush. If not, pending
conversions will start immediately after the flush.
XMEGA B [MANUAL] 331
Atmel-8291C-AVR-XMEGA B -09/2014
26.15 Register Description – ADC
26.15.1 CTRLA – Control register A TBD TPUBSXMEGA-116
z Bit 7:3 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 2 – CH0START: Channel Start Single Conversion
Setting this bit will start an ADC conversion. Bit is cleared by hardware when the conversion has started. Writing this bit
is equivalent to writing the START bits inside the ADC channel register.
z Bit 1 – FLUSH: Pipeline Flush
Setting this bit will flush the ADC. When this is done, the ADC clock is restarted on the next peripheral clock edge, and
the conversion in progress is aborted and lost.
After the flush and the ADC clock restart, the ADC will resume where it left off; i.e., if any conversions were pending,
these will enter the ADC and complete.
z Bit 0 – ENABLE: Enable
Setting this bit enables the ADC.
26.15.2 CTRLB – ADC Control register B
z Bit 7 – Reserved
This bit is unused and reserved for future use. For compatibility with future devices, always write this bit to zero when this
register is written.
z Bit 6:5 – CURRLIMIT[1:0]: Current Limitation
These bits can be used to limit the current consumption of the ADC by reducing the maximum ADC sample rate. The
available settings are shown in Table 26-1. The indicated current limitations are nominal values. Refer to the device
datasheet for actual current limitation for each setting.
Table 26-1. ADC current limitations.
Bit 7 6 5 4 3 2 1 0
+0x00 – – – – – CH0START FLUSH ENABLE
Read/Write R R R R R R/W R/W R/W
Initial Value 0 0000 0 00
Bit 7 6 5 4 3 2 1 0
+0x01 – CURRLIMIT[1:0] CONVMODE FREERUN RESOLUTION[1:0] –
Read/Write R R/W R/W R/W R/W R/W R/W R
Initial Value 0 0 0 0 0 0 0 0
CURRLIMIT[1:0] Group Configuration Description
00 NO No limit
01 LOW Low current limit, max. sampling rate 225kSPS
10 MED Medium current limit, max. sampling rate 150kSPS
11 HIGH High current limit, max. sampling rate 75kSPS
XMEGA B [MANUAL] 332
Atmel-8291C-AVR-XMEGA B -09/2014
z Bit 4 – CONVMODE: Conversion Mode
This bit controls whether the ADC will work in signed or unsigned mode. By default, this bit is cleared and the ADC is
configured for unsigned mode. When this bit is set, the ADC is configured for signed mode.
z Bit 3 – FREERUN: Free Running Mode
This bit controls the free running mode for the ADC. Once a conversion is finished, the next input will be sampled and
converted.
z Bit 2:1 – RESOLUTION[1:0]: Conversion Result Resolution
These bits define whether the ADC completes the conversion at 12- or 8-bit result resolution. They also define whether
the 12-bit result is left or right adjusted within the 16-bit result registers. See Table 26-2 for possible settings.
Table 26-2. ADC conversion result resolution.
z Bit 0 – Reserved
This bit is unused and reserved for future use. For compatibility with future devices, always write this bit to zero when this
register is written.
26.15.3 REFCTRL – Reference Control register
z Bit 7 – Reserved
This bit is unused and reserved for future use. For compatibility with future devices, always write this bit to zero when this
register is written.
z Bits 6:4 – REFSEL[2:0]: Reference Selection
These bits selects the reference for the ADC according to Table 26-3.
Table 26-3. ADC reference selection.
RESOLUTION[1:0] Group Configuration Description
00 12BIT 12-bit result, right adjusted
01 – Reserved
10 8BIT 8-bit result, right adjusted
11 LEFT12BIT 12-bit result, left adjusted
Bit 7 6 5 4 3 2 1 0
+0x02 – REFSEL[2:0] – – BANDGAP TEMPREF
Read/Write R R/W R/W R/W R R R/W R/W
Initial Value 0 0 0 0 0 0 0 0
REFSEL[2:0] Group Configuration Description
000 INT1V 10/11 of bandgap (1.0V)
001 INTVCC VCC/1.6
010 AREFA External reference from AREF pin on PORT A
011 AREFB External reference from AREF pin on PORT B
100 INTVCC2 VCC/2
101 - 111 – Reserved
XMEGA B [MANUAL] 333
Atmel-8291C-AVR-XMEGA B -09/2014
z Bit 3:2 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 1 – BANDGAP: Bandgap Enable
Setting this bit enables the bandgap for ADC measurement. Note that if any other functions are already using the
bandgap, this bit does not need to be set when the internal 1.00V reference is used for another ADC or if the brownout
detector is enabled.
z Bit 0 – TEMPREF: Temperature Reference Enable
Setting this bit enables the temperature sensor for ADC measurement.
26.15.4 EVCTRL – Event Control register
z Bit 7:5 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 4:3 – EVSEL[1:0]: Event Channel Input Select
These bits select which event channel will trigger the ADC channel. Each setting defines a group of event channels,
where the event channel with the lowest number will trigger ADC channel 0, the next event channel will trigger ADC
channel 1, and so on. See Table 26-4.
Table 26-4. ADC event channel select.
z Bit 2:0 – EVACT[2:0]: Event Mode
These bits select and limit how many of the selected event input channel are used, and also further limit the ADC
channels triggers. They also define more special event triggers as defined in Table 26-5.
Table 26-5. ADC event mode select.
Bit 7 6 5 4 3 2 1 0
+0x03 – – – EVSEL[1:0] EVACT[2:0]
Read/Write R R R R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
EVSEL[1:0] Group Configuration Selected Event Lines
00 0 Event channel 0 selected inputs
01 1 Event channel 1 selected inputs
10 2 Event channel 2 selected inputs
11 3 Event channel 3 selected inputs
EVACT[2:0] Group Configuration Event Input Operation Mode
000 NONE No event inputs
001 CH0 Event channel with the lowest number defined by EVSEL
triggers conversion on ADC channel
010 – Reserved
011 – Reserved
100 – Reserved
XMEGA B [MANUAL] 334
Atmel-8291C-AVR-XMEGA B -09/2014
26.15.5 PRESCALER – Clock Prescaler register
z Bit 7:3 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 2:0 – PRESCALER[2:0]: Prescaler Configuration
These bits define the ADC clock relative to the peripheral clock according to Table 26-6.
Table 26-6. ADC prescaler settings.
26.15.6 INTFLAGS – Interrupt Flag register
z Bit 7:1 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 0 – CH0IF: Interrupt Flags
This flag is set when the ADC conversion is complete. If the ADC is configured for compare mode, the interrupt flag will
be set if the compare condition is met. CH0IF is automatically cleared when the ADC interrupt vector is executed. The
flag can also be cleared by writing a one to its bit location.
101 – Reserved
110 SYNCSWEEP The ADC is flushed and restarted for accurate timing
111 – Reserved
EVACT[2:0] Group Configuration Event Input Operation Mode
Bit 7 6 5 4 3 2 1 0
+0x04 – – – – – PRESCALER[2:0]
Read/Write R R R R R R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
PRESCALER[2:0] Group Configuration Peripheral Clock Division Factor
000 DIV4 4
001 DIV8 8
010 DIV16 16
011 DIV32 32
100 DIV64 64
101 DIV128 128
110 DIV256 256
111 DIV512 512
Bit 7 6 5 4 3 2 1 0
+0x06 – – – – – – – CH0IF
Read/Write R R R R R R R R/W
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 335
Atmel-8291C-AVR-XMEGA B -09/2014
26.15.7 TEMP – Temporary register
z Bit 7:0 – TEMP[7:0]: Temporary bits
This register is used when reading 16-bit registers in the ADC controller. The high byte of the 16-bit register is stored
here when the low byte is read by the CPU. This register can also be read and written from the user software.
For more details on 16-bit register access, refer to “Accessing 16-bit Registers” on page 13.
26.15.8 SAMPCTRL – Sampling time control register
z Bit 7:6 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 5:0 – SAMPVAL[5:0]: sampling time control register
These bits control the ADC sampling time in number of half ADC prescaled clock cycles (depends of ADC_PRESCALER
value), thus controlling the ADC input impedance. Sampling time is set according to the formula:
Sampling time = (SAMPVAL + 1)*(ClkADC /2)
26.15.9 CALL – Calibration Value register Low
The CALL and CALH register pair hold the 12-bit calibration value. The ADC is calibrated during production
programming, and the calibration value must be read from the signature row and written to the CAL register from
software.
z Bit 7:0 – CAL[7:0]: ADC Calibration value
These are the eight lsbs of the 12-bit CAL value.
26.15.10CALH – Calibration Value register High
z Bit 3:0 – CAL[11:8]: Calibration value
These are the four msbs of the 12-bit CAL value.
Bit 7 6 5 4 3 2 1 0
+0x07 TEMP[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0000000
Bit 7 6 5 4 3 2 1 0
+0x08 – – SAMPVAL[5:0]
Read/Write R R R/W R/W R/W R/W R/W R/W
Initial Value 00000000
Bit 7 6 5 4 3 2 1 0
+0x0C CAL[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
Bit 7 6 5 4 3 2 1 0
+0x0D – – – – CAL[11:8]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 336
Atmel-8291C-AVR-XMEGA B -09/2014
26.15.11CH0RESH – Channel 0 Result register High
The CH0RESL and CH0RESH register pair represents the 16-bit value, CH0RES. For details on reading 16-bit registers,
refer to “Accessing 16-bit Registers” on page 13.
26.15.11.1 12-bit Mode, Left Adjusted
z Bit 7:0 – CHRES[11:4]: Channel Result High byte
These are the eight msbs of the 12-bit ADC result.
26.15.11.2 12-bit Mode, Right Adjusted
z Bit 7:4 – Reserved
These bits will in practice be the extension of the sign bit, CHRES11, when the ADC works in differential mode, and set
to zero when the ADC works in signed mode.
z Bit 3:0 – CHRES[11:8]: Channel Result High byte
These are the four msbs of the 12-bit ADC result.
26.15.11.3 8-bit Mode
z Bit 7:0 – Reserved
These bits will in practice be the extension of the sign bit, CHRES7, when the ADC works in signed mode, and set to zero
when the ADC works in single-ended mode.
26.15.12 CH0RESL – Channel 0 Result register Low
26.15.12.1 12-/8-bit Mode
z Bit 7:0 – CHRES[7:0]: Channel Result Low byte
These are the eight lsbs of the ADC result.
26.15.12.2 12-bit Mode, Left Adjusted
z Bit 7:4 – CHRES[3:0]: Channel Result Low byte
These are the four lsbs of the 12-bit ADC result.
z Bit 3:0 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
Bit 7 6 5 4 3 2 1 0
12-bit, left CHRES[11:4]
12-bit, right – – – – CHRES[11:8]
8-bit – – – – – – – –
Read/Write R R R R R R R R
Initial Value 0 0 0 0 0 0 0 0
Bit 7 6 5 4 3 2 1 0
12-/8-bit,
right CHRES[7:0]
12-bit, left CHRES[3:0] – – – –
Read/Write R R R R R R R R
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 337
Atmel-8291C-AVR-XMEGA B -09/2014
26.15.13 CMPH – Compare register High
The CMPH and CMPL register pair represents the 16-bit value, CMP. For details on reading and writing 16-bit registers,
refer to “Accessing 16-bit Registers” on page 13.
z Bit 7:0 – CMP[15:0]: Compare Value High byte
These are the eight msbs of the 16-bit ADC compare value. In signed mode, the number representation is 2's
complement, and the msb is the sign bit.
26.15.14 CMPL – Compare register Low
z Bit 7:0 – CMP[7:0]: Compare Value Low byte
These are the eight lsbs of the 16-bit ADC compare value. In signed mode, the number representation is 2's
complement.
26.16 Register Description - ADC Channel
26.16.1 CTRL – Control Register
z Bit 7 – START: START Conversion on Channel
Setting this bit will start a conversion on the channel. The bit is cleared by hardware when the conversion has started.
Setting this bit when it already is set will have no effect. Writing or reading this bit is equivalent to writing the
CH[3:0]START bits in “CTRLA – Control register A TBD TPUBSXMEGA-116” on page 331.
z Bit 6:5 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 4:2 – GAIN[2:0]: Gain Factor
These bits define the gain factor for the ADC gain stage.
See Table 26-7 on page 338. Gain is valid only with certain MUX settings. See “MUXCTRL – MUX Control registers” on
page 338.
Bit 7 6 5 4 3 2 1 0
+0x19 CMP[15:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 000000
Bit 7 6 5 4 3 2 1 0
+0x18 CMP[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 00000000
Bit 7 6 5 4 3 2 1 0
+0x00 START – – GAIN[2:0] INPUTMODE[1:0]
Read/Write R/W R R R/W R/W R/W R/W R/W
Initial Value 0 0 000000
XMEGA B [MANUAL] 338
Atmel-8291C-AVR-XMEGA B -09/2014
Table 26-7. ADC gain factor
z Bit 1:0 – INPUTMODE[1:0]: Channel Input Mode
These bits define the channel mode.
Table 26-8. Channel input modes, CONVMODE=0 (unsigned mode).
Table 26-9. Channel input modes, CONVMODE=1 (singed mode).
26.16.2 MUXCTRL – MUX Control registers
The MUXCTRL register defines the input source for the channel.
z Bit 7 – Reserved
This bit is unused and reserved for future use. For compatibility with future devices, always write this bit to zero when this
register is written.
GAIN[2:0] Group Configuration Gain Factor
000 1X 1x
001 2X 2x
010 4X 4x
011 8X 8x
100 16X 16x
101 32X 32x
110 64X 64x
111 DIV2 ½x
INPUTMODE[1:0] Group Configuration Description
00 INTERNAL Internal positive input signal
01 SINGLEENDED Single-ended positive input signal
10 – Reserved
11 – Reserved
INPUTMODE[1:0] Group Configuration Description
00 INTERNAL Internal positive input signal
01 SINGLEENDED Single-ended positive input signal
10 DIFF Differential input signal
11 DIFFWGAIN Differential input signal with gain
Bit 7 6 5 4 3 2 1 0
+0x01 – MUXPOS[3:0] MUXNEG[2:0]
Read/Write R R/W R/W R/W R/W R R/W R/W
Initial Value 0 0000000
XMEGA B [MANUAL] 339
Atmel-8291C-AVR-XMEGA B -09/2014
z Bit 6:3 – MUXPOS[3:0]: MUX Selection on Positive ADC Input
These bits define the MUX selection for the positive ADC input. Table 26-10 and Table 26-11 show the possible input
selection for the different input modes.
Table 26-10. ADC MUXPOS configuration when INPUTMODE[1:0] = 00 (internal) is used.
Table 26-11. ADC MUXPOS configuration when INPUTMODE[1:0] = 01 (single-ended) or INPUTMODE[1:0] = 10 (differential)
is used.
Table 26-12. ADC MUXPOS configuration when INPUTMODE[1:0] = 11 (differential with gain) is used.
MUXPOS[3:0] Group Configuration Description
0000 TEMP Temperature reference
0001 BANDGAP Bandgap voltage
0010 SCALEDVCC 1/10 scaled VCC
0011 – Reserved
0100-1111 – Reserved
MUXPOS[3:0] Group Configuration Description
0000 PIN0 ADC0 pin
0001 PIN1 ADC1 pin
0010 PIN2 ADC2 pin
0011 PIN3 ADC3 pin
0100 PIN4 ADC4 pin
0101 PIN5 ADC5 pin
0110 PIN6 ADC6 pin
0111 PIN7 ADC7 pin
1000 PIN8 ADC8 pin
1001 PIN9 ADC9 pin
1010 PIN10 ADC10 pin
1011 PIN11 ADC11 pin
1100 PIN12 ADC12 pin
1101 PIN13 ADC13 pin
1110 PIN14 ADC14 pin
1111 PIN15 ADC15 pin
MUXPOS[3:0] Group Configuration Description
0000 PIN0 ADC0 pin
0001 PIN1 ADC1 pin
0010 PIN2 ADC2 pin
XMEGA B [MANUAL] 340
Atmel-8291C-AVR-XMEGA B -09/2014
Depending on the device pin count and feature configuration, the actual number of analog input pins may be less than
16. Refer to the device datasheet and pin-out description for details.
z Bit 2:0 – MUXNEG[2:0]: MUX Selection on Negative ADC Input
These bits define the MUX selection for the negative ADC input when differential measurements are done. For internal or
single-ended measurements, these bits are not used.
Table 26-13 and Table 26-14 show the possible input sections.
Table 26-13. ADC MUXNEG configuration, INPUTMODE[1:0] = 10, differential without gain.
Table 26-14. ADC MUXNEG configuration, INPUTMODE[1:0] = 11, differential with gain.
0011 PIN3 ADC3 pin
0100 PIN4 ADC4 pin
0101 PIN5 ADC5 pin
0110 PIN6 ADC6 pin
0111 PIN7 ADC7 pin
1XXX – Reserved
MUXNEG[2:0] Group Configuration Analog Input
000 PIN0 ADC0 pin
001 PIN1 ADC1 pin
010 PIN2 ADC2 pin
011 PIN3 ADC3 pin
100 – Reserved
101 GND PAD ground
110 – Reserved
111 INTGND Internal ground
MUXNEG[2:0] Group Configuration Analog Input
000 PIN4 ADC4 pin
001 PIN5 ADC5 pin
010 PIN6 ADC6 pin
011 PIN7 ADC7 pin
100 INTGND Internal ground
101 – Reserved
110 – Reserved
111 GND PAD ground
MUXPOS[3:0] Group Configuration Description
XMEGA B [MANUAL] 341
Atmel-8291C-AVR-XMEGA B -09/2014
26.16.3 INTCTRL – Interrupt Control registers
z Bits 7:4 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 3:2 – INTMODE: Interrupt Mode
These bits select the interrupt mode for the channel according to Table 26-5.
Table 26-15. ADC interrupt mode.
z Bits 1:0 – INTLVL[1:0]: Interrupt Priority Level and Enable
These bits enable the ADC channel interrupt and select the interrupt level, as described in “Interrupts and Programmable
Multilevel Interrupt Controller” on page 115. The enabled interrupt will be triggered for conditions when the IF bit in the
INTFLAGS register is set.
26.16.4 INTFLAGS – Interrupt Flag registers
z Bit 7:1 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 0 – IF: Interrupt Flag
The interrupt flag is set when the ADC conversion is complete. If the channel is configured for compare mode, the flag
will be set if the compare condition is met. IF is automatically cleared when the ADC channel interrupt vector is executed.
The bit can also be cleared by writing a one to the bit location.
Bit 7 6 5 4 3 2 1 0
+0x02 – – – – INTMODE[1:0} INTLVL[1:0]
Read/Write R R R R R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
INTMODE[1:0] Group Configuration Interrupt Mode
00 COMPLETE Conversion complete
01 BELOW Compare result below threshold
10 – Reserved
11 ABOVE Compare result above threshold
Bit 7 6 5 4 3 2 1 0
+0x03 – – – – – – – IF
Read/Write R R R R R R R R/W
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 342
Atmel-8291C-AVR-XMEGA B -09/2014
26.16.5 RESH – Result register High
For all result registers and with any ADC result resolution, a signed number is represented in 2’s complement form, and
the msb represents the sign bit.
The RESL and RESH register pair represents the 16-bit value, ADCRESULT. Reading and writing 16-bit values require
special attention. Refer to “Accessing 16-bit Registers” on page 13 for details.
26.16.5.1 12-bit Mode, Left Adjusted
z Bit 7:0 – RES[11:4]: Channel Result High byte
These are the eight msbs of the 12-bit ADC result.
26.16.5.2 12-bit Mode, Right Adjusted
z Bit 7:4 – Reserved
These bits will in practice be the extension of the sign bit, CHRES11, when the ADC works in differential mode, and set
to zero when the ADC works in signed mode.
z Bits 3:0 – RES[11:8]: Channel Result High bits
These are the four msbs of the 12-bit ADC result.
26.16.5.3 8-bit Mode
z Bit 7:0 – Reserved
These bits will in practice be the extension of the sign bit, CHRES7, when the ADC works in signed mode, and set to zero
when the ADC works in single-ended mode.
26.16.6 RESL – Result register Low
26.16.6.1 12-/8-bit Mode
z Bit 7:0 – RES[7:0]: Result Low byte
These are the eight lsbs of the ADC result.
26.16.6.2 12-bit Mode, Left Adjusted
z Bit 7:4 – RES[3:0]: Result Low bits
These are the four lsbs of the 12-bit ADC result.
z Bit 3:0 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
Bit 7 6 5 4 3 2 1 0
12-bit, left.
+0x05
RES[11:4]
12-bit, right – – – – RES[11:8]
8-bit – – – – – – – –
Read/Write R R R R R R R R
Initial Value 0 0 0 0 0 0 0 0
Bit 7 6 5 4 3 2 1 0
12-/8-bit,
right +0x04 RES[7:0]
12-bit, left. RES[3:0] – – – –
Read/Write R R R R R R R R
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 343
Atmel-8291C-AVR-XMEGA B -09/2014
26.16.7 SCAN – Input Channel Scan register
Scan is enabled when COUNT is set differently than 0.
z Bit 7:4 – OFFSET[3:0]: Positive MUX Setting Offset
The channel scan is enabled when COUNT != 0 and this register contains the offset for the next input source to be
converted on ADC channel. The actual MUX setting for positive input equals MUXPOS + OFFSET. The value is
incremented after each conversion until it reaches the maximum value given by COUNT. When OFFSET is equal to
COUNT, OFFSET will be cleared on the next conversion.
z Bit 3:0 – COUNT[3:0]: Number of Input Channels Included in Scan
This register gives the number of input sources included in the channel scan. The number of input sources included is
COUNT + 1. The input channels included are the range from MUXPOS to MUXPOS + COUNT.
Bit 7 6 5 4 3 2 1 0
+0x06 OFFSET[3:0] COUNT[3:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 344
Atmel-8291C-AVR-XMEGA B -09/2014
26.17 Register Summary – ADC
This is the register summary when the ADC is configured to give standard 12-bit results. The register summaries for 8-bit and 12-
bit left adjusted will be similar, but with some changes in the result registers, CH0RESH and CH0RESL.
26.18 Register Summary – ADC Channel
26.19 Interrupt vector Summary
Address Name Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 Page
+0x00 CTRLA – – – – – CH0STAR FLUSH ENABLE 331
+0x01 CTRLB – CURRLIMIT[1:0] CONVMO FREERUN RESOLUTION[1:0] – 331
+0x02 REFCTRL – REFSEL[2:0] – – BANDGAP TEMPREF 332
+0x03 EVCTRL – – – EVSEL[1:0] EVACT[2:0] 333
+0x04 PRESCALER – – – – – PRESCALER[2:0] 334
+0x05 Reserved – – – – – – – –
+0x06 INTFLAGS – – – – – – – CH0IF 334
+0x07 TEMP TEMP[7:0] 335
+0x08 SAMPCTRL – – SAMPVAL[5:0] 335
+0x09 Reserved – – – – – – – –
+0x0A Reserved – – – – – – – –
+0x0B Reserved – – – – – – – –
+0x0C CALL CAL[7:0] 335
+0x0D CALH – – – – CAL[11:8]
+0x0E Reserved – – – – – – – –
+0x0F Reserved – – – – – – – –
+0x10 CH0RESL CH0RES[7:0] 336
+0x11 CH0RESH CH0RES[15:8] 336
+0x12 Reserved – – – – – – – –
+0x13 Reserved – – – – – – – –
+0x14 Reserved – – – – – – – –
+0x15 Reserved – – – – – – – –
+0x16 Reserved – – – – – – – –
+0x17 Reserved – – – – – – – –
+0x18 CMPL CMP[7:0] 337
+0x19 CMPH CMP[15:8] 337
+0x1A Reserved – – – – – – – –
+0x1B Reserved – – – – – – – –
+0x1C Reserved – – – – – – – –
+0x1D Reserved – – – – – – – –
+0x1E Reserved – – – – – – – –
+0x1F Reserved – – – – – – – –
+0x20 CH0 Offset Offset address for ADC channel
+0x28 Reserved – – – – – – – –
+0x30 Reserved – – – – – – – –
+0x38 Reserved – – – – – – – –
Address Name Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 Page
+0x00 CTRL START – – GAIN[2:0] INPUTMODE[1:0] 337
+0x01 MUXCTRL – MUXPOS[3:0] MUXNEG[2:0] 338
+0x02 INTCTRL – – – – INTMODE[1:0] INTLVL[1:0] 341
+0x03 INTFLAGS – – – – – – – IF 341
+0x04 RESL RES[7:0] 342
+0x05 RESH RES[15:8] 342
+0x06 SCAN OFFSET COUNT 342
+0x07 Reserved – – – – – – – –
Offset Source Interrupt Description
0x00 CH0 Analog-to-digital converter channel 0 interrupt vector
XMEGA B [MANUAL] 345
Atmel-8291C-AVR-XMEGA B -09/2014
27. AC – Analog Comparator
27.1 Features
z Selectable hysteresis
z None
z Small
z Large
z Analog comparator output available on pin
z Flexible input selection
z All pins on the port
z Bandgap reference voltage
z A 64-level programmable voltage scaler of the internal AVCC voltage
z Interrupt and event generation on:
z Rising edge
z Falling edge
z Toggle
z Window function interrupt and event generation on:
z Signal above window
z Signal inside window
z Signal below window
z Constant current source with configurable output pin selection
27.2 Overview
The analog comparator (AC) compares the voltage levels on two inputs and gives a digital output based on this
comparison. The analog comparator may be configured to generate interrupt requests and/or events upon several
different combinations of input change.
The analog comparator hysteresis can be adjusted in order to achieve the optimal operation for each application.
The input selection includes analog port pins, several internal signals, and a 64-level programmable voltage scaler. The
analog comparator output state can also be output on a pin for use by external devices.
A constant current source can be enabled and output on a selectable pin. This can be used to replace, for example,
external resistors used to charge capacitors in capacitive touch sensing applications.
The analog comparators are always grouped in pairs on each port. These are called analog comparator 0 (AC0) and
analog comparator 1 (AC1). They have identical behavior, but separate control registers. Used as pair, they can be set in
window mode to compare a signal to a voltage range instead of a voltage level.
XMEGA B [MANUAL] 346
Atmel-8291C-AVR-XMEGA B -09/2014
Figure 27-1. Analog comparator overview.
27.3 Input Sources
Each analog comparator has one positive and one negative input. Each input may be chosen from a selection of analog
input pins and internal inputs such as a AVCC voltage scaler. The digital output from the analog comparator is one when
the difference between the positive and the negative input voltage is positive, and zero otherwise.
27.3.1 Pin Inputs
Any of analog input pins on the port can be selected as input to the analog comparator.
27.3.2 Internal Inputs
Two internal inputs are available for the analog comparator:
z Bandgap reference voltage
z Voltage scaler, which provides a 64-level scaling of the internal AVCC voltage
27.4 Signal Compare
In order to start a signal comparison, the analog comparator must be configured with the preferred properties and inputs
before the module is enabled. The result of the comparison is continuously updated and available for application
software and the event system.
27.5 Interrupts and Events
The analog comparator can be configured to generate interrupts when the output toggles, when the output changes from
zero to one (rising edge), or when the output changes from one to zero (falling edge). Events are generated at all times
for the same condition as the interrupt, regardless of whether the interrupt is enabled or not.
ACnMUXCTRL ACnCTRL
Interrupt
Mode
Enable
Enable
Hysteresis
Hysteresis
AC1OUT
WINCTRL
Interrupt
Sensititivity
Control
&
Window
Function
Events
Interrupts
AC0OUT
Pin Input
Pin Input
Pin Input
Pin Input
Voltage
Scaler
Bandgap
+
AC0
-
+
AC1
-
XMEGA B [MANUAL] 347
Atmel-8291C-AVR-XMEGA B -09/2014
27.6 Window Mode
Two analog comparators on the same port can be configured to work together in window mode. In this mode, a voltage
range is defined, and the analog comparators give information about whether an input signal is within this range or not.
Figure 27-2. The Analog comparators in window mode.
27.7 Input Hysteresis
Application software can select between no-, low-, and high hysteresis for the comparison. Applying a hysteresis will help
prevent constant toggling of the output that can be caused by noise when the input signals are close to each other.
AC0
+
-
AC1
+
-
Input signal
Upper limit of window
Lower limit of window
Interrupt
sensitivity
control
Interrupts
Events
XMEGA B [MANUAL] 348
Atmel-8291C-AVR-XMEGA B -09/2014
27.8 Register Description
27.8.1 ACnCTRL – Analog Comparator n Control register
z Bit 7:6 – INTMODE[1:0]: Interrupt Modes
These bits configure the interrupt mode for analog comparator n according to Table 27-1.
Table 27-1. Interrupt settings.
z Bit 5:4 – INTLVL[1:0]: Interrupt Level
These bits enable the analog comparator n interrupt and select the interrupt level, as described in “Interrupts and
Programmable Multilevel Interrupt Controller” on page 115. The enabled interrupt will trigger according to the INTMODE
setting.
z Bit 3 – Reserved
This bit is unused and reserved for future use. For compatibility with future devices, always write this bit to zero when this
register is written.
z Bit 2:1 – HYSMODE[1:0]: Hysteresis Mode Select
These bits select the hysteresis mode according to Table 27-2. For details on actual hysteresis levels, refer to the device
datasheet.
Table 27-2. Hysteresis settings.
z Bit 0 – ENABLE: Enable
Setting this bit enables analog comparator n.
Bit 7 6 5 4 3 2 1 0
+0x00 / +0x01 INTMODE[1:0] INTLVL[1:0] – HYSMODE[2:0] ENABLE
Read/Write R/W R/W R/W R/W R R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
INTMODE[1:0] Group Configuration Description
00 BOTHEDGES Comparator interrupt or event on output toggle
01 – Reserved
10 FALLING Comparator interrupt or event on falling output edge
11 RISING Comparator interrupt or event on rising output edge
HYSMODE[1:0] Group Configuration Description
00 NO No hysteresis
01 SMALL Small hysteresis
10 LARGE Large hysteresis
11 – Reserved
XMEGA B [MANUAL] 349
Atmel-8291C-AVR-XMEGA B -09/2014
27.8.2 ACnMUXCTRL – Analog Comparator n Mux Control register
z Bit 7:6 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 5:3 – MUXPOS[2:0]: Positive Input MUX Selection
These bits select which input will be connected to the positive input of analog comparator n according to Table 27-3.
Table 27-3. Positive input MUX selection.
z Bit 2:0 – MUXNEG[2:0]: Negative Input MUX Selection
These bits select which input will be connected to the negative input of analog comparator n according to Table 27-4.
Table 27-4. Negative input MUX selection.
Bit 7 6 5 4 3 2 1 0
+0x02 / +0x03 – – MUXPOS[2:0] MUXNEG[2:0]
Read/Write R R R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
MUXPOS[2:0] Group Configuration Description
000 PIN0 Pin 0
001 PIN1 Pin 1
010 PIN2 Pin 2
011 PIN3 Pin 3
100 PIN4 Pin 4
101 PIN5 Pin 5
110 PIN6 Pin 6
111 – Reserved
MUXNEG[2:0] Group Configuration Negative Input MUX Selection
000 PIN0 Pin 0
001 PIN1 Pin 1
010 PIN3 Pin 3
011 PIN5 Pin 5
100 PIN7 Pin 7
101 – Reserved
110 BANDGAP Internal bandgap voltage
111 SCALER AVCC voltage scaler
XMEGA B [MANUAL] 350
Atmel-8291C-AVR-XMEGA B -09/2014
27.8.3 CTRLA – Control register A
z Bit 7:2 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 1 – AC1OUT: Analog Comparator 1 Output
Setting this bit makes the output of AC1 available on pin 6 of the port.
z Bit 0 – AC0OUT: Analog Comparator 0 Output
Setting this bit makes the output of AC0 available on pin 7 of the port.
27.8.4 CTRLB – Control register B
z Bit 7:6 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 5:0 – SCALEFAC[5:0]: Voltage Scaling Factor
These bits define the scaling factor for the AVcc voltage scaler. The input to the analog comparator, VSCALE, is:
27.8.5 WINCTRL – Window Function Control register
z Bit 7:5 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 4 – WEN: Window Mode Enable
Setting this bit enables the analog comparator window mode.
z Bits 3:2 – WINTMODE[1:0]: Window Interrupt Mode Settings
These bits configure the interrupt mode for the analog comparator window mode according to Table 27-5.
Bit 7 6 5 4 3 2 1 0
+0x04 – – – – – – AC1OUT AC0OUT
Read/Write R R R R R R R/W R/W
Initial Value 0 0 000000
Bit 7 6 5 4 3 2 1 0
+0x05 – – SCALEFAC[5:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 00000000
VSCALE
V CC ⋅ ( ) SCALEFAC + 1
64 = -------------------------------------------------------------
Bit 7 6 5 4 3 2 1 0
+0x06 – – – WEN WINTMODE[1:0] WINTLVL[1:0]
Read/Write R R R R/W R/W R/W R/W R/W
Initial Value 0 0 000000
XMEGA B [MANUAL] 351
Atmel-8291C-AVR-XMEGA B -09/2014
Table 27-5. Window mode interrupt settings.
z Bits 1:0 – WINTLVL[1:0]: Window Interrupt Enable
These bits enable the analog comparator window mode interrupt and select the interrupt level, as described in “Interrupts
and Programmable Multilevel Interrupt Controller” on page 115. The enabled interrupt will trigger according to the
WINTMODE setting.
27.8.6 STATUS – Status register
z Bits 7:6 – WSTATE[1:0]: Window Mode Current State
These bits show the current state of the signal if window mode is enabled according to Table 27-6.
Table 27-6. Window mode current state.
z Bit 5 – AC1STATE: Analog Comparator 1 Current State
This bit shows the current state of the output signal from AC1.
z Bit 4 – AC0STATE: Analog Comparator 0 Current State
This bit shows the current state of the output signal fromAC0.
z Bit 3 – Reserved
This bit is unused and reserved for future use. For compatibility with future devices, always write this bit to zero when this
register is written.
z Bit 2 – WIF: Analog Comparator Window Interrupt Flag
This is the interrupt flag for the window mode. WIF is set according to the WINTMODE setting in the “WINCTRL –
Window Function Control register” on page 350.
This flag is automatically cleared when the analog comparator window interrupt vector is executed. The flag can also be
cleared by writing a one to its bit location.
z Bit 1 – AC1IF: Analog Comparator 1 Interrupt Flag
This is the interrupt flag for AC1. AC1IF is set according to the INTMODE setting in the corresponding “ACnCTRL –
Analog Comparator n Control register” on page 348.
WINTMODE[1:0] Group Configuration Description
00 ABOVE Interrupt on signal above window
01 INSIDE Interrupt on signal inside window
10 BELOW Interrupt on signal below window
11 OUTSIDE Interrupt on signal outside window
Bit 7 6 5 4 3 2 1 0
+0x07 WSTATE[1:0] AC1STATE AC0STATE – WIF AC1IF AC0IF
Read/Write R/W R/W R/W R/W R R/W R/W R/W
Initial Value 0 0 000000
WSTATE[1:0] Group Configuration Description
00 ABOVE Signal is above window
01 INSIDE Signal is inside window
10 BELOW Signal is below window
11 OUTSIDE Signa is outside window
XMEGA B [MANUAL] 352
Atmel-8291C-AVR-XMEGA B -09/2014
This flag is automatically cleared when the analog comparator 1 interrupt vector is executed. The flag can also be
cleared by writing a one to its bit location.
z Bit 0 – AC0IF: Analog Comparator 0 Interrupt Flag
This is the interrupt flag for AC0. AC0IF is set according to the INTMODE setting in the corresponding “ACnCTRL –
Analog Comparator n Control register” on page 348.
This flag is automatically cleared when the analog comparator 0 interrupt vector is executed. The flag can also be
cleared by writing a one to its bit location.
27.8.7 CURRCTRL – Current Source Control register
z Bit 7 – CURRENT: Current Source Enable
Setting this bit to one will enable the constant current source.
z Bit 6:2 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 1 – AC1CURR: AC1 Current Source Output Enable
Setting this bit to one will enable the constant current source output on the pin selected by MUXNEG in AC1MUXTRL.
z Bit 0 – AC0CURR: AC0 Current Source Output Enable
Setting this bit to one will enable the constant current source output on the pin selected by MUXNEG in AC0MUXTRL.
27.8.8 CURRCALIB – Current Source Calibration register
z Bits 7:4 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits to zero
when this register is written.
z Bit 3:0 – CALIB[3:0]: Current Source Calibration
The constant current source is calibrated during production. A calibration value can be read from the signature row and
written to the CURRCALIB register from software. Refer to device data sheet for default calibration values and user
calibration range.
Bit 7 6 5 4 3 2 1 0
+0x08 CURRENT – – – – – AC1CURR AC0CURR
Read/Write R/W R R R R R R/W R/W
Initial Value 0 0 0000 0 0
Bit 7 6 5 4 3 2 1 0
+0x09 – – – – CALIB[3:0]
Read/Write R R R R R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
XMEGA B [MANUAL] 353
Atmel-8291C-AVR-XMEGA B -09/2014
27.9 Register Summary
27.10 Interrupt vector Summary
Address Name Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 Page
+0x00 AC0CTRL INTMODE[1:0] INTLVL[1:0] – HYSMODE[1:0] ENABLE 348
+0x01 AC1CTRL INTMODE[1:0] INTLVL[1:0] – HYSMODE[1:0] ENABLE 348
+0x02 AC0MUXCTR – – MUXPOS[2:0] MUXNEG[2:0] 349
+0x03 AC1MUXCTR – – MUXPOS[2:0] MUXNEG[2:0] 349
+0x04 CTRLA – – – – – – AC1OUT ACOOUT 350
+0x05 CTRLB – – SCALEFAC5:0] 350
+0x06 WINCTRL – – – WEN WINTMODE[1:0] WINTLVL[1:0] 350
+0x07 STATUS WSTATE[1:0] AC1STATE AC0STATE – WIF AC1IF AC0IF 351
+0x08 CURRCTRL CURRENT – – – – – AC1CURR AC0CURR 352
+0x09 CURRCALIB – – – – CALIB[3:0] 352
Offset Source Interrupt Description
0x00 COMP0_vect Analog comparator 0 interrupt vector
0x02 COMP1_vect Analog comparator 1 interrupt vector
0x04 WINDOW_vect Analog comparator window interrupt vector
XMEGA B [MANUAL] 354
Atmel-8291C-AVR-XMEGA B -09/2014
28. IEEE 1149.1 JTAG Boundary Scan Interface
28.1 Features
• JTAG (IEEE Std. 1149.1-2001 compliant) interface
• Boundary scan capabilities according to the JTAG standard
• Full scan of all I/O pins
• Supports the mandatory SAMPLE, IDCODE, PRELOAD, EXTEST, and BYPASS instructions
• Supports the optional HIGHZ and CLAMP instructions
• Supports the AVR-specific PDICOM instruction for accessing the PDI
28.2 Overview
The JTAG interface is mainly intended for testing PCBs by using the JTAG boundary scan capability. Secondarily, the
JTAG interface is used to access the Program and Debug Interface (PDI) in its optional JTAG mode.
The boundary scan chain has the capability of driving and observing the logic levels on I/O pins. At the system level, all
microcontroller or board components having JTAG capabilities are connected serially by the TDI/TDO signals to form a
long shift register. An external controller sets up the devices to drive values at their output pins, and observes the input
values received from other devices. The controller compares the received data with the expected result. In this way,
boundary scan method provides a mechanism for testing the interconnections and integrity of components on printed
circuit boards by using only the four test access port (TAP) signals.
The IEEE Std. 1149.1-2001 defined mandatory JTAG instructions, IDCODE, BYPASS, SAMPLE/ PRELOAD, and
EXTEST, together with the optional CLAMP and HIGHZ instructions can be used for testing the printed circuit board.
Alternatively, the HIGHZ instruction can be used to place all I/O pins in an inactive drive state, while bypassing the
boundary scan register chain of the chip.
The AVR-specific PDICOM instruction makes it possible to use the PDI data register as an interface for accessing the
PDI for programming and debugging. This provides an alternative way to access internal programming and debugging
resources by using the JTAG interface. For more details on PDI, programming, and on-chip debugging, refer to “Program
and Debug Interface” on page 393.
The JTAGEN fuse must be programmed and the JTAGD bit in the MCUCR register must be cleared to enable the JTAG
interface and TAP. See “FUSEBYTE4 – Fuse Byte4” on page 31, and “MCUCR – Control register” on page 45 for more
details.
When using the JTAG interface for boundary scan, the JTAG TCK clock frequency can be higher than the internal device
frequency. A system clock in the device is not required for boundary scan.
28.3 TAP - Test Access Port
The JTAG interface requires and uses four device I/O pins. In JTAG terminology, these pins constitute the test access
port, or TAP. These pins are:
z TMS: Test mode select. The pin is used for navigating through the TAP-controller state machine
z TCK: Test clock. This is the JTAG clock signal, and all operation is synchronous to TCK
z TDI: Test data in. Serial input data to be shifted in to the instruction register or data register (scan chains)
z TDO: Test data out. Serial output data from the instruction register or data register
The IEEE Std. 1149.1-2001 also specifies an optional test reset signal, TRST. This signal is not available.
When the JTAGEN fuse is unprogrammed or the JTAG disable bit is set, the JTAG interface is disabled. The four TAP
pins are normal port pins, and the TAP controller is in reset. When enabled, the input TAP signals are internally pulled
high and JTAG is enabled for boundary scan operations.
XMEGA B [MANUAL] 355
Atmel-8291C-AVR-XMEGA B -09/2014
Figure 28-1. TAP controller state diagram.
The TAP controller is a 16-state, finite state machine that controls the operation of the boundary scan circuitry. The state
transitions shown in Figure 28-1 depend on the signal present on TMS (shown adjacent to each state transition) at the
time of the rising edge on TCK. The initial state after a power-on reset is the test logic reset state.
Assuming the present state is run test/idle, a typical scenario for using the JTAG interface is:
z At the TMS input, apply the sequence 1, 1, 0, 0 at the rising edges of TCK to enter the shift instruction register, or
shift IR, state. While in this state, shift the four bits of the JTAG instruction into the JTAG instruction register from
the TDI input at the rising edge of TCK. The TMS input must be held low during input of the 3 lsbs in order to
remain in the shift IR state. The msb of the instruction is shifted in when this state is left by setting TMS high. While
the instruction is shifted in from the TDI pin, the captured IR state, 0x01, is shifted out on the TDO pin. The JTAG
instruction selects a particular data register as the path between TDI and TDO and controls the circuitry
surrounding the selected data register
z Apply the TMS sequence 1, 1, 0 to reenter the run test/idle state. The instruction is latched onto the parallel output
from the shift register path in the update IR state. The exit IR, pause IR, and exit2 IR states are used only for
navigating the state machine
z At the TMS input, apply the sequence 1, 0, 0 at the rising edges of TCK to enter the shift data register, or shift DR,
state. While in this state, upload the selected data register (selected by the present JTAG instruction in the JTAG
instruction register) from the TDI input at the rising edge of TCK. In order to remain in the shift DR state, the TMS
input must be held low during the input of all bits except the msb. The msb of the data is shifted in when this state
is left by setting TMS high. While the data register is shifted in from the TDI pin, the parallel inputs to the data
register captured in the capture DR state are shifted out on the TDO pin
z Apply the TMS sequence 1, 1, 0 to reenter the run test/idle state. If the selected data register has a latched parallel
output, the latching takes place in the update DR state. The exit DR, pause DR, and exit2 DR states are used only
for navigating the state machine.
XMEGA B [MANUAL] 356
Atmel-8291C-AVR-XMEGA B -09/2014
As shown in the state diagram, the run test/idle state need not be entered between selecting JTAG instructions and using
data registers.
Note: Independently of the initial state of the TAP controller, the test logic reset state can always be entered by holding
TMS high for five TCK clock periods.
28.4 JTAG Instructions
The instruction register is four bits wide. Listed below are the JTAG instructions for boundary scan operation and the
PDICOM instruction used for accessing the PDI in JTAG mode.
The lsb is shifted in and out first for all shift registers.
The opcode for each instruction is shown beside the instruction name in hex format. The text describes which data
register is selected as the path between TDI and TDO for each instruction.
28.4.1 EXTEST; 0x1
EXTEST is the instruction for selecting the boundary scan chain as the data register for testing circuitry external to the
AVR XMEGA device package. The instruction is used for sampling external pins and loading output pins with data. For
the I/O port pins, both output control (DIR) and output data (OUT) are controllable via the scan chain, while the output
control and actual pin value are observable. The contents of the latched outputs of the boundary scan chain are driven
out as soon as the JTAG instruction register is loaded with the EXTEST instruction.
The active states are:
z Capture DR: Data on the external pins are sampled into the boundary scan chain
z Shift DR: Data in the Boundary-scan Chain are shifted by the TCK input
z Update DR: Data from the scan chain are applied to output pins
28.4.2 IDCODE; 0x3
IDCODE is the instruction for selecting the 32-bit ID register as the data register. The ID register consists of a version
number, a device number, and the manufacturer code chosen by the Joint Electron Devices Engineering Council
(JEDEC). This is the default instruction after power up.
The active states are:
z Capture DR: Data in the IDCODE register are sampled into the device identification register
z Shift DR: The IDCODE scan chain is shifted by the TCK input
28.4.3 SAMPLE/PRELOAD; 0x2
SAMPLE/PRELOAD is the instruction for preloading the output latches and taking a snapshot of the input/output pins
without affecting system operation. However, the output latches are not connected to the pins. The boundary scan chain
is selected as the data register. Since each of the SAMPLE and PRELOAD instructions implements the functionality of
the other, they share a common binary value, and can be treated as a single, merged instruction.
The active states are:
z Capture DR: Data on the external pins are sampled into the boundary scan chain
z Shift DR: The boundary scan chain is shifted by the TCK input
z Update DR: Data from the boundary scan chain are applied to the output latches, but the output latches are not
connected to the pins
28.4.4 BYPASS; 0xf
BYPASS is the instruction for selecting the bypass register for the data register. This instruction can be issued to make
the shortest possible scan chain through the device.
XMEGA B [MANUAL] 357
Atmel-8291C-AVR-XMEGA B -09/2014
The active states are:
z Capture DR: Loads a zero into the bypass register
z Shift DR: The bypass register cell between TDI and TDO is shifted
28.4.5 CLAMP; 0x4
CLAMP is an optional instruction that allows the state of the input/output pins to be determined from the preloaded output
latches. The instruction allows static pin values to be applied via the boundary scan registers while bypassing these
registers in the scan path, efficiently shortening the total length of the serial test path. The bypass register is selected as
the data register.
The active states are:
z Capture DR: Loads a zero into the bypass register
z Shift DR: The bypass register cell between TDI and TDO is shifted
28.4.6 HIGHZ; 0x5
HIGHZ is an optional instruction for putting all outputs in an inactive drive state (e.g., high impedance). The bypass
register is selected as the data register.
The active states are:
z Capture DR: Loads a zero into the bypass register
z Shift DR: The bypass register cell between TDI and TDO is shifted
28.4.7 PDICOM; 0x7
PDICOM is an AVR XMEGA specific instruction for using the JTAG TAP as an alternative interface to the PDI.
The active states are:
z Capture DR: Parallel data from the PDI are sampled into the PDICOM data register
z Shift DR: The PDICOM data register is shifted by the TCK input
z Update DR: Commands or operands are parallel-latched from the PDICOM data register into the PDI
28.5 Boundary Scan Chain
The boundary scan chain has the capability of driving and observing the logic levels on the I/O pins. To ensure a
predictable device behavior during and after the EXTEST, CLAMP, and HIGHZ instructions, the device is automatically
put in reset. During active reset, the external oscillators, analog modules, and non-default port pin settings (like pullup/down,
bus-keeper, wired-AND/OR) are disabled. It should be noted that the current device and port pin state are
unaffected by the SAMPLE and PRELOAD instructions.
28.5.1 Scanning the Port Pins
Figure 28-2 on page 358 shows the boundary scan cell used for all the bidirectional port pins. This cell is able to control
and observe both pin direction and pin value via a two-stage shift register. When no alternate port function is present,
output control corresponds to the DIR register value, output data corresponds to the OUT register value, and input data
corresponds to the IN register value (tapped before the input inverter and input synchronizer). Mode represents either an
active CLAMP or EXTEST instruction, while shift DR is set when the TAP controller is in its shift DR state.
XMEGA B [MANUAL] 358
Atmel-8291C-AVR-XMEGA B -09/2014
Figure 28-2. Boundary scan cell for bi-directional port pin.
28.5.2 Scanning the PDI Pins
Two observe-only cells are inserted to make the combined RESET and PDI_CLK pin and the PDI_DATA pin observable.
Even though the PDI_DATA pin is bidirectional, it is only made observable in order to avoid any extra logic on the
PDI_DATA output path.
Figure 28-3. An observe-only input cell.
Q D
D Q D Q
D Q
Input Data
(IN)
Output Data
(IN)
Output Control
(DIR)
Mode
Pn
Shift DR To next cell
From last cell Clock DR Update DR
0
1
0
1
0
0
1
1
En
D Q
From last
cell
Clock DR
To next cell
To system
logic
From system
pin
Shift DR
1
0
XMEGA B [MANUAL] 359
Atmel-8291C-AVR-XMEGA B -09/2014
28.6 Data Registers
The supported data registers that can be connected between TDI and TDO are:
z Bypass register (Ref: register A in Figure 28-4 on page 359).
z Device identification register (Ref: register C in Figure 28-4 on page 359).
z Boundary scan chain (Ref: register D in Figure 28-4 on page 359).
z PDICOM data register (Ref: register B in Figure 28-4 on page 359)
Figure 28-4. JTAG data register overview.
28.6.1 Bypass Register
The bypass register consists of a single shift register stage. When the bypass register is selected as the path between
TDI and TDO, the register is reset to 0 when leaving the capture DR controller state. The bypass register can be used to
shorten the scan chain on a system when the other devices are to be tested.
28.6.2 Device Identification Register
28.6.2.1 Version
Version is a 4-bit number identifying the revision of the device. The JTAG version number follows the revision of the
device. Revision A is 0x0, revision B is 0x1, and so on.
28.6.2.2 Part Number
The part number is a 16-bit code identifying the device. Refer to the device data sheets to find the correct number.
28.6.2.3 Manufacturer ID
The manufacturer ID is an 11-bit code identifying the manufacturer. For Atmel, this code is 0x01F.
D
D
TDI
A
B B B
C C C C
TDO
TMS
D
D
D
D
D
D
D D D
I/O PORTS
PDI JTAG
TCK to all TCK
registers
Internal registers
JTAG Boundary-scan chain
TAP
CTRL
MSB LSB
Bit 31 28 27 12 11 1 0
Device ID Version Part Number Manufacturer ID 1
4 bits 16 bits 11 bits 1 bit
XMEGA B [MANUAL] 360
Atmel-8291C-AVR-XMEGA B -09/2014
28.6.3 Boundary Scan Chain
The boundary scan chain has the capability of driving and observing the logic levels on all I/O pins. Refer to “Boundary
Scan Chain” on page 357 for a complete description.
28.6.4 PDICOM Data Register
The PDICOM data register is a 9-bit wide register used for serial-to-parallel and parallel-to-serial conversions of data
between the JTAG TAP and the PDI. For details, refer to “Program and Debug Interface” on page 393.
Document Footer Title [PRELIMINARY DATASHEET] 361
Atmel-8291C-AVR-XMEGA B -09/2014
29. Program and Debug Interface
29.1 Features
z Programming
̶ External programming through PDI or JTAG interfaces
z Minimal protocol overhead for fast operation
z Built-in error detection and handling for reliable operation
̶ Boot loader support for programming through any communication interface
z Debugging
̶ Nonintrusive, real-time, on-chip debug system
̶ No software or hardware resources required from device except pin connection
̶ Program flow control
z Go, Stop, Reset, Step Into, Step Over, Step Out, Run-to-Cursor
̶ Unlimited number of user program breakpoints
̶ Unlimited number of user data breakpoints, break on:
z Data location read, write, or both read and write
z Data location content equal or not equal to a value
z Data location content is greater or smaller than a value
z Data location content is within or outside a range
̶ No limitation on device clock frequency
z Program and Debug Interface (PDI)
̶ Two-pin interface for external programming and debugging
̶ Uses the Reset pin and a dedicated pin
̶ No I/O pins required during programming or debugging
z JTAG interface
̶ Four-pin, IEEE Std. 1149.1 compliant interface for programming and debugging
̶ Boundary scan capabilities according to IEEE Std. 1149.1 (JTAG)
29.2 Overview
The Program and Debug Interface (PDI) is an Atmel proprietary interface for external programming and on-chip
debugging of a device.
The PDI supports fast programming of nonvolatile memory (NVM) spaces; flash, EEPOM, fuses, lock bits, and the
user signature row. This is done by accessing the NVM controller and executing NVM controller commands, as
described in “Memory Programming” on page 407.
Debug is supported through an on-chip debug system that offers nonintrusive, real-time debug. It does not require any
software or hardware resources except for the device pin connection. Using the Atmel tool chain, it offers complete
program flow control and support for an unlimited number of program and complex data breakpoints. Application
debug can be done from a C or other high-level language source code level, as well as from an assembler and
disassembler level.
Programming and debugging can be done through two physical interfaces. The primary one is the PDI physical layer,
which is available on all devices. This is a two-pin interface that uses the Reset pin for the clock input (PDI_CLK) and
one other dedicated pin for data input and output (PDI_DATA). A JTAG interface is also available on most devices,
and this can be used for programming and debugging through the four-pin JTAG interface. The JTAG interface is
IEEE Std. 1149.1 compliant, and supports boundary scan. Any external programmer or on-chip debugger/emulator
can be directly connected to either of these interfaces. Unless otherwise stated, all references to the PDI assume
access through the PDI physical layer.
Document Footer Title [PRELIMINARY DATASHEET] 362
Atmel-8291C-AVR-XMEGA B -09/2014
Figure 29-1. The PDI with JTAG and PDI physical layers and closely related modules (grey).
29.3 PDI Physical
The PDI physical layer handles the low-level serial communication. It uses a bidirectional, half-duplex, synchronous
serial receiver and transmitter (just as a USART in USRT mode). The physical layer includes start-of-frame detection,
frame error detection, parity generation, parity error detection, and collision detection.
In addition to PDI_CLK and PDI_DATA, the PDI_DATA pin has an internal pull resistor, VCC and GND must be
connected between the External Programmer/debugger and the device. Figure 29-2 on page 362 shows a typical
connection.
Figure 29-2. PDI connection.
The remainder of this section is intended for use only by third parties developing programmers or programming
support for Atmel AVR XMEGA devices.
29.3.1 Enabling
The PDI physical layer must be enabled before use. This is done by first forcing the PDI_DATA line high for a period
longer than the equivalent external reset minimum pulse width (refer to device datasheet for external reset pulse width
data). This will disable the RESET functionality of the Reset pin, if not already disabled by the fuse settings.
Next, continue to keep the PDI_DATA line high for 16 PDI_CLK cycles. The first PDI_CLK cycle must start no later
than 100μs after the RESET functionality of the Reset pin is disabled. If this does not occur in time, the enabling
procedure must start over again. The enable sequence is shown in Figure 29-3 on page 363.
PDI
Controller
JTAG Physical
(physical layer)
PDI Physical
(physical layer)
OCD
NVM
Controller
Program and Debug Interface (PDI)
PDI_CLK
PDI_DATA
TDO
TCK
TMI
TDI
NVM
Memories
PDIBUS Internal Interfaces
PDI Connector
GND
VCC
PDI_CLK
PDI_DATA
Document Footer Title [PRELIMINARY DATASHEET] 363
Atmel-8291C-AVR-XMEGA B -09/2014
Figure 29-3. PDI physical layer enable sequence.
The Reset pin is sampled when the PDI interface is enabled. The reset register is then set according to the state of the
Reset pin, preventing the device from running code after the reset functionality of this pin is disabled.
29.3.2 Disabling
If the clock frequency on PDI_CLK is lower than approximately 10kHz, this is regarded as inactivity on the clock line.
This will automatically disable the PDI. If not disabled by a fuse, the reset function of the Reset (PDI_CLK) pin is
enabled again. This also means that the minimum programming frequency is approximately 10kHz.
29.3.3 Frame Format and Characters
The PDI physical layer uses a frame format defined as one character of eight data bits, with a start bit, a parity bit, and
two stop bits.
Figure 29-4. PDI serial frame format.
Three different characters are used, DATA, BREAK, and IDLE. The BREAK character is equal to a 12-bit length of low
level. The IDLE character is equal to a 12- bit length of high level. The BREAK and IDLE characters can be extended
beyond the 12-bit length.
Figure 29-5. Characters and timing for the PDI physical layer.
Disable RESET function on Reset (PDI_CLK) pin Activate PDI
PDI_DATA
PDI_CLK
St Start bit, always low
(0-7) Data bits (0 to 7)
P Parity bit, even parity used
Sp1 Stop bit 1, always high
Sp2 Stop bit 2, always high
St 012 3 4567P Sp1
FRAME
(IDLE) Sp2 (St/IDLE)
START 012 3 4567P STOP
1 IDLE character
BREAK
IDLE
1 DATA character
1 BREAK character
Document Footer Title [PRELIMINARY DATASHEET] 364
Atmel-8291C-AVR-XMEGA B -09/2014
29.3.4 Serial Transmission and Reception
The PDI physical layer is either in transmit (TX) or receive (RX) mode. By default, it is in RX mode, waiting for a start
bit.
The programmer and the PDI operate synchronously on the PDI_CLK provided by the programmer. The dependency
between the clock edges and data sampling or data change is fixed. As illustrated in Figure 29-6 on page 364, output
data (either from the programmer or the PDI) is always set up (changed) on the falling edge of PDI_CLK and sampled
on the rising edge of PDI_CLK.
Figure 29-6. Changing and sampling of data.
29.3.5 Serial Transmission
When a data transmission is initiated, by the PDI controller, the transmitter simply shifts out the start bit, data bits,
parity bit, and the two stop bits on the PDI_DATA line. The transmission speed is dictated by the PDI_CLK signal.
While in transmission mode, IDLE bits (high bits) are automatically transmitted to fill possible gaps between
successive DATA characters. If a collision is detected during transmission, the output driver is disabled, and the
interface is put into RX mode waiting for a BREAK character.
29.3.6 Serial Reception
When a start bit is detected, the receiver starts to collect the eight data bits. If the parity bit does not correspond to the
parity of the data bits, a parity error has occurred. If one or both of the stop bits are low, a frame error has occurred. If
the parity bit is correct, and no frame error is detected, the received data bits are available for the PDI controller.
When the PDI is in TX mode, a BREAK character signaled by the programmer will not be interpreted as a BREAK, but
will instead cause a generic data collision. When the PDI is in RX mode, a BREAK character will be recognized as a
BREAK. By transmitting two successive BREAK characters (which must be separated by one or more high bits), the
last BREAK character will always be recognized as a BREAK, regardless of whether the PDI was in TX or RX mode
initially. This is because in TX mode the first BREAK is seen as a collision. The PDI then shifts to RX mode and sees
the second BREAK as break.
29.3.7 Direction Change
In order to ensure correct timing for half-duplex operation, a guard time mechanism is used. When the PDI changes
from RX mode to TX mode, a configurable number of IDLE bits are inserted before the start bit is transmitted. The
minimum transition time between RX and TX mode is two IDLE cycles, and these are always inserted. The default
guard time value is 128 bits.
Figure 29-7. PDI direction change by inserting IDLE bits.
PDI_CLK
PDI_DATA
Sample Sample Sample
St P Sp1
1 DATA character
Sp2 IDLE bits St P
1 DATA character
Sp1 Sp2
Dir. change
PDI DATA Receive (RX) PDI DATA Transmit (TX)
Data from
PDI interface
to Programmer
Data from
Programmer to
PDI interface
Guard time
# IDLE bits
inserted
Document Footer Title [PRELIMINARY DATASHEET] 365
Atmel-8291C-AVR-XMEGA B -09/2014
The external programmer will loose control of the PDI_DATA line at the point where the PDI changes from RX to TX
mode. The guard time relaxes this critical phase of the communication. When the programmer changes from RX
mode to TX mode, a single IDLE bit, at minimum, should be inserted before the start bit is transmitted.
29.3.8 Drive Contention and Collision Detection
In order to reduce the effect of drive contention (the PDI and the programmer driving the PDI_DATA line at the same
time), a mechanism for collision detection is used. The mechanism is based on the way the PDI drives data out on the
PDI_DATA line. As shown in Figure 29-8 on page 365, the PDI output driver is active only when the output value
changes (from 0-1 or 1-0). Hence, if two or more successive bit values are the same, the value is actively driven only
on the first clock cycle. After this point, the PDI output driver is automatically tri-stated, and the PDI_DATA pin has a
bus keeper responsible for keeping the pin value unchanged until the output driver is reenabled due to a change in the
bit value.
Figure 29-8. Driving data out on the PDI_DATA using a bus keeper.
If the programmer and the PDI both drive the PDI_DATA line at the same time, drive contention will occur, as
illustrated in Figure 29-9 on page 365. Every time a bit value is kept for two or more clock cycles, the PDI is able to
verify that the correct bit value is driven on the PDI_DATA line. If the programmer is driving the PDI_DATA line to the
opposite bit value to what the PDI expects, a collision is detected.
Figure 29-9. Drive contention and collision detection on the PDI_DATA line.
As long as the PDI transmits alternating ones and zeros, collisions cannot be detected, because the PDI output driver
will be active all the time, preventing polling of the PDI_DATA line. However, the two stop bits should always be
transmitted as ones within a single frame, enabling collision detection at least once per frame.
1011 0
Output enable
PDI_CLK
PDI Output
0 1
PDI_DATA
PDI_CLK
PDI Output
PDI_DATA
1 0 X 1 1
Programmer
output
X 1
Collision detect
= Collision
Document Footer Title [PRELIMINARY DATASHEET] 366
Atmel-8291C-AVR-XMEGA B -09/2014
29.4 JTAG Physical
The JTAG physical layer handles the basic low-level serial communication over four I/O lines, TMS, TCK, TDI, and
TDO. The JTAG physical layer includes BREAK detection, parity error detection, and parity generation. For all generic
JTAG details, refer to “IEEE 1149.1 JTAG Boundary Scan Interface” on page 386.
29.4.1 Enabling
The JTAGEN fuse must be programmed and the JTAG disable bit in the MCU control register must be cleared to
enable the JTAG interface. This is done by default. When the JTAG PDICOM instruction is shifted into the JTAG
instruction register, the JTAG interface can be used to access the PDI for external programming and on-chip
debugging.
29.4.2 Disabling
The JTAG interface can be disabled by unprogramming the JTAGEN fuse or by setting the JTAG disable bit in the
MCU control register from the application code.
29.4.3 JTAG Instruction Set
The Atmel XMEGA specific JTAG instruction set consist of eight instructions related to boundary scan and PDI access
for programming. For more details on JTAG and the general JTAG instruction set, refer to “JTAG Instructions” on
page 388.
29.4.3.1 The PDICOM Instruction
When the PDICOM instruction is shifted into the JTAG instruction register, the 9-bit PDI communication register is
selected as the data register. Commands are shifted into the register as results from previous commands are shifted
out from the register. The active TAP controller states are (see “TAP - Test Access Port” on page 386):
̶ Capture DR: Parallel data from the PDI controller is sampled into the PDI communication register
̶ Shift DR: The PDI communication register is shifted by the TCK input
̶ Update DR: Commands or operands are parallel-latched into registers in the PDI controller
29.4.4 Frame Format and Characters
The JTAG physical layer supports a fixed frame format. A serial frame is defined to be one character of eight data bits
followed by one parity bit.
Figure 29-10. JTAG serial frame format
Three special data characters are used. Common among these is that the parity bit is inverted in order to force a
parity error upon reception. The BREAK character (0xBB+P1) is used by the external programmer to force the PDI to
abort any ongoing operation and bring the PDI controller into a known state. The DELAY character (0xDB+P1) is used
by the PDI to tell the programmer that it has no data ready. The EMPTY character (0xEB+P1) is used by the PDI to tell
the programmer that it has no transmission pending (i.e., the PDI is in RX-mode).
(0-7) Data/command bits, least-significant bit sent first (0 to 7)
P Parity bit, even parity used
Document Footer Title [PRELIMINARY DATASHEET] 367
Atmel-8291C-AVR-XMEGA B -09/2014
Figure 29-11. Special data characters.
29.4.5 Serial transmission and reception
The JTAG interface supports full-duplex communication. At the same time as input data is shifted in on the TDI pin,
output data is shifted out on the TDO pin. However, PDI communication relies on half-duplex data transfer. Due to
this, the JTAG physical layer operates only in either transmit (TX) or receive (RX) mode. The available JTAG bit
channel is used for control and status signalling.
The programmer and the JTAG interface operate synchronously on the TCK clock provided by the programmer. The
dependency between the clock edges and data sampling or data change is fixed. As illustrated in Figure 29-12 on
page 367, TDI and TDO is always set up (change) on the falling edge of TCK, while data always should be sampled
on the rising edge of TCK.
Figure 29-12. Changing and sampling data.
29.4.6 Serial Transmission
When data transmission is initiated, a data byte is loaded into the shift register and then out on TDO. The parity bit is
generated and appended to the data byte during transmission. The transmission speed is given by the TCK signal.
If the PDI is in TX mode (as a response to an LD instruction), and a transmission request from the PDI controller is
pending when the TAP controller enters the capture DR state, valid data will be parallel-loaded into the shift register,
and a correct parity bit will be generated and transmitted along with the data byte in the shift DR state.
If the PDI is in RX mode when the TAP controller enters the capture DR state, an EMPTY byte will be loaded into the
shift register, and the parity bit will be set (forcing a parity error) when data is shifted out in the shift DR state. This
situation occurs during normal PDI command and operand reception.
If the PDI is in TX- mode (as a response to an LD instruction), but no transmission request from the PDI controller is
pending when the TAP controller enters the capture DR state, a DELAY byte (0xDB) will be loaded into the shift
register, and the parity bit will be set (forcing a parity error) when data is shifted out in the shift DR state. This situation
occurs during data transmission if the data to be transmitted is not yet available.
Figure 29-13 on page 368 shows an uninterrupted flow of data frames from the PDI as a response to the repeated
indirect LD instruction. In this example, the device is not able to return data bytes faster than one valid byte per two
transmitted frames. Thus, intermediate DELAY characters are inserted.
Document Footer Title [PRELIMINARY DATASHEET] 368
Atmel-8291C-AVR-XMEGA B -09/2014
Figure 29-13. Data not ready marking.
If a DELAY data frame is transmitted as a response to an LD instruction, the programmer should interpret this as if the
JTAG interface had no data ready for transmission in the previous capture DR state. The programmer must initiate
repeated transfers until a valid data byte is received. The LD instruction is defined to return a specified number of valid
frames, not just a number of frames. Hence, if the programmer detects a DELAY character after transmitting an LD
instruction, the LD instruction should not be retransmitted, because the first LD response would still be pending.
29.4.7 Serial Reception
During reception, the PDI collects the eight data bits and the parity bit from TDI and shifts them into the shift register.
Every time a valid frame is received, the data is latched in to the update DR state.
The parity checker calculates the parity (even mode) of the data bits in incoming frames and compares the result with
the parity bit from the serial frame. In case of a parity error, the PDI controller is signaled.
The parity checker is active in both TX and RX modes. If a parity error is detected, the received data byte is evaluated
and compared with the BREAK character (which will always generate a parity error). In case the BREAK character is
recognized, the PDI controller is signaled.
29.5 PDI Controller
The PDI controller performs data transmission/reception on a byte level, command decoding, high-level direction
control, control and status register access, exception handling, and clock switching (PDI_CLK or TCK). The
interaction between an external programmer and the PDI controller is based on a scheme where the programmer
transmits various types of requests to the PDI controller, which in turn responds according to the specific request. A
programmer request comes in the form of an instruction, which may be followed by one or more byte operands. The
PDI controller response may be silent (e.g., a data byte is stored to a location within the device), or it may involve data
being returned to the programmer (e.g., a data byte is read from a location within the device).
29.5.1 Switching between PDI and JTAG modes
The PDI controller uses either the JTAG or PDI physical layer for establishing a connection to the programmer. Based
on this, the PDI is in either JTAG or PDI mode. When one of the modes is entered, the PDI controller registers will be
initialized, and the correct clock source will be selected. The PDI mode has higher priority than the JTAG mode.
Hence, if the PDI mode is enabled while the PDI controller is already in JTAG mode, the access layer will
automatically switch over to PDI mode. If switching physical layer without powering on/off the device, the active layer
should be disabled before the alternative physical layer is enabled.
29.5.2 Accessing Internal Interfaces
After an external programmer has established communication with the PDI, the internal interfaces are not accessible,
by default. To get access to the NVM controller and the nonvolatile memories for programming, a unique key must be
signaled by using the KEY instruction. The internal interfaces are accessed as one linear address space using a
dedicated bus (PDIBUS) between the PDI and the internal interfaces. The PDIBUS address space is shown in
Table 33-3 on page 421. The NVM controller must be enabled for the PDI controller to have any access to the NVM
interface. The PDI controller can access the NVM and NVM controller in programming mode only. The PDI controller
does not need to access the NVM controller's data or address registers when reading or writing NVM.
Document Footer Title [PRELIMINARY DATASHEET] 369
Atmel-8291C-AVR-XMEGA B -09/2014
29.5.3 NVM Programming Key
The key that must be sent using the KEY instruction is 64 bits long. The key that will enable NVM programming is:
0x1289AB45CDD888FF
29.5.4 Exception Handling
There are several situations that are considered exceptions from normal operation. The exceptions depend on
whether the PDI is in RX or TX mode and whether PDI or JTAG mode is used.
While the PDI is in RX mode, the exceptions are:
z PDI:
̶ The physical layer detects a parity error
̶ The physical layer detects a frame error
̶ The physical layer recognizes a BREAK character (also detected as a frame error)
z JTAG:
̶ The physical layer detects a parity error
̶ The physical layer recognizes a BREAK character (also detected as a parity error)
While the PDI is in TX mode, the exceptions are:
z PDI:
̶ The physical layer detects a data collision
z JTAG:
̶ The physical layer detects a parity error (on the dummy data shifted in on TDI)
̶ The physical layer recognizes a BREAK character
Exceptions are signaled to the PDI controller. All ongoing operations are then aborted, and the PDI is put in ERROR
state. The PDI will remain in ERROR state until a BREAK is sent from the external programmer, and this will bring the
PDI back to its default RX state.
Due to this mechanism, the programmer can always synchronize the protocol by transmitting two successive BREAK
characters.
29.5.5 Reset Signalling
Through the reset register, the programmer can issue a reset and force the device into reset. After clearing the reset
register, reset is released, unless some other reset source is active.
29.5.6 Instruction Set
The PDI has a small instruction set used for accessing both the PDI itself and the internal interfaces. All instructions
are byte instructions. The instructions allow an external programmer to access the PDI controller, the NVM controller
and the nonvolatile memories.
29.5.6.1 LDS - Load Data from PDIBUS Data Space using Direct Addressing
The LDS instruction is used to load data from the PDIBUS data space for read out. The LDS instruction is based on
direct addressing, which means that the address must be given as an argument to the instruction. Even though the
protocol is based on byte-wise communication, the LDS instruction supports multiple-byte addresses and data
access. Four different address/data sizes are supported: single-byte, word (two bytes), three-byte, and long (four
bytes). Multiple-byte access is broken down internally into repeated single-byte accesses, but this reduces protocol
overhead. When using the LDS instruction, the address byte(s) must be transmitted before the data transfer.
29.5.6.2 STS - Store Data to PDIBUS Data Space using Direct Addressing
The STS instruction is used to store data that are serially shifted into the physical layer shift register to locations within
the PDIBUS data space. The STS instruction is based on direct addressing, which means that the address must be
given as an argument to the instruction. Even though the protocol is based on byte-wise communication, the ST
Document Footer Title [PRELIMINARY DATASHEET] 370
Atmel-8291C-AVR-XMEGA B -09/2014
instruction supports multiple-bytes addresses and data access. Four different address/data sizes are supported:
single-byte, word (two bytes), three-byte, and long (four bytes). Multiple-byte access is broken down internally into
repeated single-byte accesses, but this reduces protocol overhead. When using the STS instruction, the address
byte(s) must be transmitted before the data transfer.
29.5.6.3 LD - Load Data from PDIBUS Data Space using Indirect Addressing
The LD instruction is used to load data from the PDIBUS data space into the physical layer shift register for serial read
out. The LD instruction is based on indirect addressing (pointer access), which means that the address must be stored
in the pointer register prior to the data access. Indirect addressing can be combined with pointer increment. In addition
to reading data from the PDIBUS data space, the LD instruction can read the pointer register. Even though the
protocol is based on byte-wise communication, the LD instruction supports multiple-byte addresses and data access.
Four different address/data sizes are supported: single-byte, word (two bytes), three-byte, and long (four bytes).
Multiple-byte access is broken down internally into repeated single-byte accesses, but this reduces the protocol
overhead.
29.5.6.4 ST - Store Data to PDIBUS Data Space using Indirect Addressing
The ST instruction is used to store data that is serially shifted into the physical layer shift register to locations within
the PDIBUS data space. The ST instruction is based on indirect addressing (pointer access), which means that the
address must be stored in the pointer register prior to the data access. Indirect addressing can be combined with
pointer increment. In addition to writing data to the PDIBUS data space, the ST instruction can write the pointer
register. Even though the protocol is based on byte-wise communication, the ST instruction supports multiple-bytes
address - and data access. Four different address/data sizes are supported; byte, word, 3 bytes, and long (4 bytes).
Multiple-bytes access is internally broken down to repeated single-byte accesses, but it reduces the protocol
overhead.
29.5.6.5 LDCS - Load Data from PDI Control and Status Register Space
The LDCS instruction is used to load data from the PDI control and status registers into the physical layer shift register
for serial read out. The LDCS instruction supports only direct addressing and single-byte access.
29.5.6.6 STCS - Store Data to PDI Control and Status Register Space
The STCS instruction is used to store data that are serially shifted into the physical layer shift register to locations
within the PDI control and status registers. The STCS instruction supports only direct addressing and single-byte
access.
29.5.6.7 KEY - Set Activation Key
The KEY instruction is used to communicate the activation key bytes required for activating the NVM interfaces.
29.5.6.8 REPEAT - Set Instruction Repeat Counter
The REPEAT instruction is used to store count values that are serially shifted into the physical layer shift register to
the repeat counter register. The instruction that is loaded directly after the REPEAT instruction operand(s) will be
repeated a number of times according to the specified repeat counter register value. Hence, the initial repeat counter
value plus one gives the total number of times the instruction will be executed. Setting the repeat counter register to
zero makes the following instruction run once without being repeated.
The REPEAT instruction cannot be repeated. The KEY instruction cannot be repeated, and will override the current
value of the repeat counter register.
29.5.7 Instruction Set Summary
The PDI instruction set summary is shown in Figure 29-14 on page 371.
Document Footer Title [PRELIMINARY DATASHEET] 371
Atmel-8291C-AVR-XMEGA B -09/2014
Figure 29-14. PDI instruction set summary.
29.6 Register Description – PDI Instruction and Addressing Registers
The PDI instruction and addressing registers are internal registers utilized for instruction decoding and PDIBUS
addressing. None of these registers are accessible as registers in a register space.
29.6.1 Instruction Register
When an instruction is successfully shifted into the physical layer shift register, it is copied into the instruction register.
The instruction is retained until another instruction is loaded. The reason for this is that the REPEAT command may
force the same instruction to be run repeatedly, requiring command decoding to be performed several times on the
same instruction.
29.6.2 Pointer Register
The pointer register is used to store an address value that specifies locations within the PDIBUS address space.
During direct data access, the pointer register is updated by the specified number of address bytes given as operand
bytes to an instruction. During indirect data access, addressing is based on an address already stored in the pointer
register prior to the access itself. Indirect data access can be optionally combined with pointer register post-increment.
LDS 0 0 0
Cmd Size A Size B
STS 0 1 0
LDCS 1 0 0
CS Address
STCS 1 1 0
KEY 1 1 1 0 0 0
REPEAT 1 0 1 0 0 0
Size B
LDS
STS
ST
0
0 1
0
0
1
1 1
LD
0
0
0
0
Cmd
LDCS (LDS Control/Status)
STCS (STS Control/Status)
KEY
0 1
1 0
1 1
REPEAT
1
1
1
1
0 0
Size B - Data size
Byte
3 Bytes
Long (4 Bytes)
0
0 1
0
0
1
1 1
Word (2 Bytes)
CS Address (CS - Control/Status reg.)
0 0 0 Register 0
Register 2
Reserved
Register 1
0
0 0 0 1
0 0 1 0
0 0 1 1
1 1 1 1 Reserved
......
0
0
Size A - Address size (direct access)
Byte
3 Bytes
Long (4 Bytes)
0
0 1
0
0
1
1 1
Word (2 Bytes)
LD 0 0 1
Cmd Ptr Size A/B
ST 0 1 1 0
0
0
0
Ptr - Pointer access (indirect access)
*(ptr)
ptr
ptr++ - Reserved
0
0 1
0
0
1
1 1
*(ptr++)
0 0
Document Footer Title [PRELIMINARY DATASHEET] 372
Atmel-8291C-AVR-XMEGA B -09/2014
The indirect access mode has an option that makes it possible to load or read the pointer register without accessing
any other registers. Any register update is performed in a little-endian fashion. Hence, loading a single byte of the
address register will always update the LSB while the most-significant bytes are left unchanged.
The pointer register is not involved in addressing registers in the PDI control and status register space (CSRS space).
29.6.3 Repeat Counter Register
The REPEAT instruction is always accompanied by one or more operand bytes that define the number of times the
next instruction should be repeated. These operand bytes are copied into the repeat counter register upon reception.
During the repeated executions of the instruction immediately following the REPEAT instruction and its operands, the
repeat counter register is decremented until it reaches zero, indicating that all repetitions have completed. The repeat
counter is also involved in key reception.
29.6.4 Operand Count Register
Immediately after an instruction (except the LDCS and STCS instructions) a specified number of operands or data
bytes (given by the size parts of the instruction) are expected. The operand count register is used to keep track of how
many bytes have been transferred.
Document Footer Title [PRELIMINARY DATASHEET] 373
Atmel-8291C-AVR-XMEGA B -09/2014
29.7 Register Description – PDI Control and Status Registers
The PDI control and status registers are accessible in the PDI control and status register space (CSRS) using the
LDCS and STCS instructions. The CSRS contains registers directly involved in configuration and status monitoring of
the PDI itself.
29.7.1 STATUS – Status register
z Bit 7:2 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits
to zero when this register is written.
z Bit 1 – NVMEN: Nonvolatile Memory Enable
This status bit is set when the key signalling enables the NVM programming interface. The external
programmer can poll this bit to verify successful enabling. Writing the NVMEN bit disables the NVM interface.
z Bit 0 – Reserved
This bit is unused and reserved for future use. For compatibility with future devices, always write this bit to zero
when this register is written.
29.7.2 RESET – Reset register
z Bit 7:0 – RESET[7:0]: Reset Signature
When the reset signature, 0x59, is written to RESET, the device is forced into reset. The device is kept in reset
until RESET is written with a data value different from the reset signature. Reading the lsb will return the status
of the reset. The seven msbs will always return the value 0x00, regardless of whether the device is in reset or
not.
29.7.3 CTRL – Control register
z Bit 7:3 – Reserved
These bits are unused and reserved for future use. For compatibility with future devices, always write these bits
to zero when this register is written.
z Bit 2:0 – GUARDTIME[2:0]: Guard Time
These bits specify the number of IDLE bits of guard time that are inserted in between PDI reception and
transmission direction changes. The default guard time is 128 IDLE bits, and the available settings are shown in
Table 29-1 on page 374. In order to speed up the communication, the guard time should be set to the lowest
safe configuration accepted. No guard time is inserted when switching from TX to RX mode.
Bit 7 6 5 4 3 2 1 0
+0x00 – – – – – – NVMEN –
Read/Write R R R R R R R/W R
Initial Value 00000000
Bit 7 6 5 4 3 2 1 0
+0x01 RESET[7:0]
Read/Write R/W R/W R/W R/W R/W R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
Bit 7 6 5 4 3 2 1 0
+0x02 – – – – – GUARDTIME[2:0]
Read/Write R R R R R R/W R/W R/W
Initial Value 0 0 0 0 0 0 0 0
Document Footer Title [PRELIMINARY DATASHEET] 374
Atmel-8291C-AVR-XMEGA B -09/2014
Table 29-1. Guard time settings.
29.8 Register Summary
GUARDTIME Number of IDLE Bits
000 128
001 64
010 32
011 16
100 8
101 4
110 2
111 2
Address Name Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 Page
+0x00 STATUS – – – – – – NVMEN – 373
+0x01 RESET RESET[7:0] 373
+0x02 CTRL – – – – – GUARDTIME[2:0] 373
+0x03 Reserved – – – – – – – –
XMEGA B [MANUAL] 375
Atmel-8291C-AVR-XMEGA B -09/2014
30. Memory Programming
30.1 Features
z Read and write access to all memory spaces from
z External programmers
z Application software self-programming
z Self-programming and boot loader support
z Read-while-write self-programming
z CPU can run and execute code while flash is being programmed
z Any communication interface can be used for program upload/download
z External programming
z Support for in-system and production programming
z Programming through serial PDI or JTAG interface
z High security with separate boot lock bits for:
z External programming access
z Boot loader section access
z Application section access
z Application table access
z Reset fuse to select reset vector address to the start of the
z Application section, or
z Boot loader section
30.2 Overview
This section describes how to program the nonvolatile memory (NVM) in Atmel AVR XMEGA devices, and covers both
self-programming and external programming. The NVM consists of the flash program memory, user signature and
production signature rows, fuses and lock bits, and EEPROM data memory. For details on the actual memories, how
they are organized, and the register description for the NVM controller used to access the memories, refer to “Memories”
on page 20.
The NVM can be accessed for read and write from application software through self-programming and from an external
programmer. Accessing the NVM is done through the NVM controller, and the two methods of programming are similar.
Memory access is done by loading address and/or data to the selected memory or NVM controller and using a set of
commands and triggers that make the NVM controller perform specific tasks on the nonvolatile memory.
From external programming, all memory spaces can be read and written, except for the production signature row, which
can only be read. The device can be programmed in-system and is accessed through the PDI using the PDI or JTAG
physical interfaces. “External Programming” on page 388 describes PDI and JTAG in detail.
Self-programming and boot loader support allows application software in the device to read and write the flash, user
signature row and EEPROM, write the lock bits to a more secure setting, and read the production signature row and
fuses. The flash allows read-while-write self-programming, meaning that the CPU can continue to operate and execute
code while the flash is being programmed. “Self-programming and Boot Loader Support” on page 379 describes this in
detail.
For both self-programming and external programming, it is possible to run a CRC check on the flash or a section of the
flash to verify its content after programming.
The device can be locked to prevent reading and/or writing of the NVM. There are separate lock bits for external
programming access and self-programming access to the boot loader section, application section, and application table
section.
XMEGA B [MANUAL] 376
Atmel-8291C-AVR-XMEGA B -09/2014
30.3 NVM Controller
Access to the nonvolatile memories is done through the NVM controller. It controls NVM timing and access privileges,
and holds the status of the NVM, and is the common NVM interface for both external programming and selfprogramming.
For more details, refer to “Register Description” on page 393.
30.4 NVM Commands
The NVM controller has a set of commands used to perform tasks on the NVM. This is done by writing the selected
command to the NVM command register. In addition, data and addresses must be read/written from/to the NVM data and
address registers for memory read/write operations.
When a selected command is loaded and address and data are set up for the operation, each command has a trigger
that will start the operation. Based on these triggers, there are three main types of commands.
30.4.1 Action-triggered Commands
Action-triggered commands are triggered when the command execute (CMDEX) bit in the NVM control register A
(CTRLA) is written. Action-triggered commands typically are used for operations which do not read or write the NVM,
such as the CRC check.
30.4.2 NVM Read-triggered Commands
NVM read-triggered commands are triggered when the NVM is read, and this is typically used for NVM read operations.
30.4.3 NVM Write-triggered Commands
NVM write-triggered commands are triggered when the NVM is written, and this is typically used for NVM write
operations.
30.4.4 Write/Execute Protection
Most command triggers are protected from accidental modification/execution during self-programming. This is done
using the configuration change protection (CCP) feature, which requires a special write or execute sequence in order to
change a bit or execute an instruction. For details on the CCP, refer to “Configuration Change Protection” on page 13.
30.5 NVM Controller Busy Status
When the NVM controller is busy performing an operation, the busy flag in the NVM status register is set and the
following registers are blocked for write access:
z NVM command register
z NVM control A register
z NVM control B register
z NVM address registers
z NVM data registers
This ensures that the given command is executed and the operations finished before the start of a new operation. The
external programmer or application software must ensure that the NVM is not addressed when it is busy with a
programming operation.
Programming any part of the NVM will automatically block:
z All programming to other parts of the NVM
z All loading/erasing of the flash and EEPROM page buffers
z All NVM reads from external programmers
z All NVM reads from the application section
During self-programming, interrupts must be disabled or the interrupt vector table must be moved to the boot loader
sections, as described in “Interrupts and Programmable Multilevel Interrupt Controller” on page 115.
XMEGA B [MANUAL] 377
Atmel-8291C-AVR-XMEGA B -09/2014
30.6 Flash and EEPROM Page Buffers
The flash memory is updated page by page. The EEPROM can be updated on a byte-by-byte and page-by-page basis.
flash and EEPROM page programming is done by first filling the associated page buffer, and then writing the entire page
buffer to a selected page in flash or EEPROM.
The size of the page and page buffers depends on the flash and EEPROM size in each device, and details are described
in the device datasheet.
30.6.1 Flash Page Buffer
The flash page buffer is filled one word at a time, and it must be erased before it can be loaded. When loading the page
buffer with new content, the result is a binary AND between the existing content of the page buffer location and the new
value. If the page buffer is already loaded once after erase the location will most likely be corrupted.
Page buffer locations that are not loaded will have the value 0xFFFF, and this value will then be programmed into the
corresponding flash page locations.
The page buffer is automatically erased after:
z A device reset
z Executing the write flash page command
z Executing the erase and write flash page command
z Executing the signature row write command
z Executing the write lock bit command
30.6.2 EEPROM Page Buffer
The EEPROM page buffer is filled one byte at a time, and it must be erased before it can be loaded. When loading the
page buffer with new content, the result is a binary AND between the existing content of the page buffer location and the
new value. If the EEPROM page buffer is already loaded once after erase the location will most likely be corrupted.
EEPROM page buffer locations that are loaded will get tagged by the NVM controller. During a page write or page erase,
only targed locations will be written or erased. Locations that are not targed will not be written or erased, and the
corresponding EEPROM location will remain unchanged. This means that before an EEPROM page erase, data must be
loaded to the selected page buffer location to tag them. When performing an EEPROM page erase, the actual value of
the tagged location does not matter.
The EEPROM page buffer is automatically erased after:
z A system reset
z Executing the write EEPROM page command
z Executing the erase and write EEPROM page command
z Executing the write lock bit and write fuse commands
30.7 Flash and EEPROM Programming Sequences
For page programming, filling the page buffers and writing the page buffer into flash or EEPROM are two separate
operations. The sequence is same for both self-programming and external programming.
30.7.1 Flash Programming Sequence
Before programming a flash page with the data in the flash page buffer, the flash page must be erased. Programming an
un-erased flash page will corrupt its content.
The flash page buffer can be filled either before the erase flash Page operation or between a erase flash page and a
write flash page operation:
XMEGA B [MANUAL] 378
Atmel-8291C-AVR-XMEGA B -09/2014
Alternative 1:
z Fill the flash page buffer
z Perform a flash page erase
z Perform a flash page write
Alternative 2:
z Fill the flash page buffer
z Perform an atomic page erase and write
Alternative 3, fill the buffer after a page erase:
z Perform a flash page erase
z Fill the flash page buffer
z Perform a flash page write
The NVM command set supports both atomic erase and write operations, and split page erase and page write
commands. This split commands enable shorter programming time for each command, and the erase operations can be
done during non-time-critical programming execution. When using alternative 1 or 2 above for self-programming, the
boot loader provides an effective read-modify-write feature, which allows the software to first read the page, do the
necessary changes, and then write back the modified data. If alternative 3 is used, it is not possible to read the old data
while loading, since the page is already erased. The page address must be the same for both page erase and page write
operations when using alternative 1 or 3.
30.7.2 EEPROM Programming Sequence
Before programming an EEPROM page with the tagged data bytes stored in the EEPROM page buffer, the selected
locations in the EEPROM page must be erased. Programming an unerased EEPROM page will corrupt its content. The
EEPROM page buffer must be loaded before any page erase or page write operations:
Alternative 1:
z Fill the EEPROM page buffer with the selected number of bytes
z Perform a EEPROM page erase
z Perform a EEPROM page write
Alternative 2:
z Fill the EEPROM page buffer with the selected number of bytes
z Perform an atomic EEPROM page erase and write
30.8 Protection of NVM
To protect the flash and EEPROM memories from write and/or read, lock bits can be set to restrict access from external
programmers and the application software. Refer to “LOCKBITS – Lock Bit register” on page 29 for details on the
available lock bit settings and how to use them.
30.9 Preventing NVM Corruption
During periods when the VCC voltage is below the minimum operating voltage for the device, the result from a flash
memory write can be corrupt, as supply voltage is too low for the CPU and the flash to operate properly.To ensure that
the voltage is sufficient enough during a complete programming sequence of the flash memory, a voltage detector using
the POR threshold (VPOT+) level is enabled. During chip erase and when the PDI is enabled the brownout detector (BOD)
is automatically enabled at its configured level.
XMEGA B [MANUAL] 379
Atmel-8291C-AVR-XMEGA B -09/2014
Depending on the programming operation, if any of these VCC voltage levels are reached, the programming sequence
will be aborted immediately. If this happens, the NVM programming should be restarted when the power is sufficient
again, in case the write sequence failed or only partly succeeded.
30.10 CRC Functionality
It is possible to run an automatic cyclic redundancy check (CRC) on the flash program memory. When NVM is used to
control the CRC module, an even number of bytes are read, at least in the flash range mode. If the user selects a range
with an odd number of bytes, an extra byte will be read, and the checksum will not correspond to the selected range.
Refer to “CRC – Cyclic Redundancy Check Generator” on page 293 for more details.
30.11 Self-programming and Boot Loader Support
Reading and writing the EEPROM and flash memory from the application software in the device is referred to as selfprogramming.
A boot loader (application code located in the boot loader section of the flash) can both read and write the
flash program memory, user signature row, and EEPROM, and write the lock bits to a more secure setting. Application
code in the application section can read from the flash, user signature row, production signature row, and fuses, and read
and write the EEPROM.
30.11.1 Flash Programming
The boot loader support provides a real read-while-write self-programming mechanism for uploading new program code
by the device itself. This feature allows flexible application software updates controlled by the device using a boot loader
application that reside in the boot loader section in the flash. The boot loader can use any available communication
interface and associated protocol to read code and write (program) that code into the flash memory, or read out the
program memory code. It has the capability to write into the entire flash, including the boot loader section. The boot
loader can thus modify itself, and it can also erase itself from the flash if the feature is not needed anymore.
30.11.1.1 Application and Boot Loader Sections
The application and boot loader sections in the flash are different when it comes to self-programming.
z When erasing or writing a page located inside the application section, the boot loader section can be read
during the operation, and thus the CPU can run and execute code from the boot loader section
z When erasing or writing a page located inside the boot loader section, the CPU is halted during the entire
operation, and code cannot execute
The user signature row section has the same properties as the boot loader section.
Table 30-1. Summary of self-programming functionality.
30.11.1.2 Addressing the Flash
The Z-pointer is used to hold the flash memory address for read and write access. For more details on the Z-pointer,
refer to “The X-, Y-, and Z- Registers” on page 11.
Since the flash is word accessed and organized in pages, the Z-pointer can be treated as having two sections. The leastsignificant
bits address the words within a page, while the most-significant bits address the page within the flash. This is
shown in Figure 30-1 on page 380. The word address in the page (FWORD) is held by the bits [WORDMSB:1] in the Zpointer.
The remaining bits [PAGEMSB:WORDMSB+1] in the Z-pointer hold the flash page address (FPAGE). Together
FWORD and FPAGE holds an absolute address to a word in the flash.
Section being Addressed during Programming Section that can be Read during Programming CPU halted?
Application section Boot loader section No
Boot loader section None Yes
User signature row section None Yes
XMEGA B [MANUAL] 380
Atmel-8291C-AVR-XMEGA B -09/2014
For flash read operations (ELPM and LPM), one byte is read at a time. For this, the least-significant bit (bit 0) in the Zpointer
is used to select the low byte or high byte in the word address. If this bit is 0, the low byte is read, and if this bit is
1 the high byte is read.
The size of FWORD and FPAGE will depend on the page and flash size in the device. Refer to each device’s datasheet
for details.
Once a programming operation is initiated, the address is latched and the Z-pointer can be updated and used for other
operations.
Figure 30-1. Flash addressing for self-programming.
30.11.2 NVM Flash Commands
The NVM commands that can be used for accessing the flash program memory, signature row and production signature
row are listed in Table 30-2.
For self-programming of the flash, the trigger for action-triggered commands is to set the CMDEX bit in the NVM CTRLA
register (CMDEX). The read-triggered commands are triggered by executing the (E)LPM instruction (LPM). The writetriggered
commands are triggered by executing the SPM instruction (SPM).
The Change Protected column indicates whether the trigger is protected by the configuration change protection (CCP) or
not. This is a special sequence to write/execute the trigger during self-programming. For more details, refer to
“Configuration Change Protection” on page 13. CCP is not required for external programming. The two last columns
show the address pointer used for addressing and the source/destination data register.
Section 30.11.1.1 on page 379 through Section 30.11.2.14 on page 384 explain in detail the algorithm for each NVM
operation.
FPAGE FWORD 0/1
BIT
Z-Pointer
P 1 AGEMSB WORDMSB 0
PAGE INSTRUCTION WORD
PROGRAM MEMORY PAGE
WORD ADDRESS
WITHIN A PAGE
PAGE ADDRESS
WITHIN THE FLASH
FWORD
00
01
02
PAGEEND
00
01
02
FLASHEND
FPAGE
Low/High Byte select for (E)LPM
XMEGA B [MANUAL] 381
Atmel-8291C-AVR-XMEGA B -09/2014
Table 30-2. Flash self-programming commands.
Notes: 1. The flash range CRC command used byte addressing of the flash.
2. Will depend on the flash section (application or boot loader) that is actually addressed.
3. This command is qualified with the lock bits, and requires that the boot lock bits are unprogrammed.
4. When using a command that changes the normal behavior of the LPM command; READ_USER_SIG_ROW and READ_CALIB_ROW; it is recommended to
disable interrupts to ensure correct execution of the LPM instruction.
5. For consistency the name Calibration Row has been renamed to Production Signature Row throughout the document.
30.11.2.1 Read Flash
The (E)LPM instruction is used to read one byte from the flash memory.
1. Load the Z-pointer with the byte address to read.
2. Load the NVM command register (NVM CMD) with the no operation command.
3. Execute the LPM instruction.
The destination register will be loaded during the execution of the LPM instruction.
CMD[6:0] Group Configuration Description Trigger
CPU
Halted
NVM
Busy
Change
Protected
Address
Pointer
Data
Register
0x00 NO_OPERATION No operation / read flash -/(E)LPM -/N N -/N -/ Z-pointer -/Rd
Flash Page Buffer
0x23 LOAD_FLASH_BUFFER Load flash page buffer SPM N N N Z-pointer R1:R0
0x26 ERASE_FLASH_BUFFER Erase flash page buffer CMDEX N Y Y Z-pointer -
Flash
0x2B ERASE_FLASH_PAGE Erase flash page SPM N/Y(2) Y Y Z-pointer -
0x02E WRITE_FLASH_PAGE Write flash page SPM N/Y(2) Y Y Z-pointer -
0x2F ERASE_WRITE_FLASH_PAGE Erase and write flash page SPM N/Y(2) Y Y Z-pointer -
0x3A FLASH_RANGE_CRC(3) Flash range CRC CMDEX Y Y Y DATA/ADDR(1) DATA
Application Section
0x20 ERASE_APP Erase application section SPM Y Y Y Z-pointer -
0x22 ERASE_APP_PAGE Erase application section page SPM N Y Y Z-pointer -
0x24 WRITE_APP_PAGE Write application section page SPM N Y Y Z-pointer -
0x25 ERASE_WRITE_APP_PAGE Erase and write application section page SPM N Y Y Z-pointer -
0x38 APP_CRC Application section CRC CMDEX Y Y Y - DATA
Boot Loader Section
0x2A ERASE_BOOT_PAGE Erase boot loader section page SPM Y Y Y Z-pointer -
0x2C WRITE_BOOT_PAGE Write boot loader section page SPM Y Y Y Z-pointer -
0x2D ERASE_WRITE_BOOT_PAGE Erase and write boot loader section page SPM Y Y Y Z-pointer -
0x39 BOOT_CRC Boot loader section CRC CMDEX Y Y Y - DATA
User Signature Row
0x01(4) READ_USER_SIG_ROW Read user signature row LPM N N N Z-pointer Rd
0x18 ERASE_USER_SIG_ROW Erase user signature row SPM Y Y Y - -
0x1A WRITE_USER_SIG_ROW Write user signature row SPM Y Y Y - -
Production Signature (Calibration) Row(5)
0x02(4) READ_CALIB_ROW Read calibration row LPM N N N Z-pointer Rd
XMEGA B [MANUAL] 382
Atmel-8291C-AVR-XMEGA B -09/2014
30.11.2.2 Erase Flash Page Buffer
The erase flash page buffer command is used to erase the flash page buffer.
1. Load the NVM CMD with the erase flash page buffer command.
2. Set the command execute bit (NVMEX) in the NVM control register A (NVM CTRLA). This requires the timed CCP
sequence during self-programming.
The NVM busy (BUSY) flag in the NVM status register (NVM STATUS) will be set until the page buffer is erased.
30.11.2.3 Load Flash Page Buffer
The load flash page buffer command is used to load one word of data into the flash page buffer.
1. Load the NVM CMD register with the load flash page buffer command.
2. Load the Z-pointer with the word address to write.
3. Load the data word to be written into the R1:R0 registers.
4. Execute the SPM instruction. The SPM instruction is not protected when performing a flash page buffer load.
Repeat step 2-4 until the complete flash page buffer is loaded. Unloaded locations will have the value 0xFFFF.
30.11.2.4 Erase Flash Page
The erase flash page command is used to erase one page in the flash.
1. Load the Z-pointer with the flash page address to erase. The page address must be written to FPAGE. Other bits
in the Z-pointer will be ignored during this operation.
2. Load the NVM CMD register with the erase flash page command.
3. Execute the SPM instruction. This requires the timed CCP sequence during self-programming.
The BUSY flag in the NVM STATUS register will be set until the erase operation is finished. The flash section busy
(FBUSY) flag is set as long the flash is busy, and the application section cannot be accessed.
30.11.2.5 Write Flash Page
The write flash page command is used to write the flash page buffer into one flash page in the flash.
1. Load the Z-pointer with the flash page to write. The page address must be written to FPAGE. Other bits in the Zpointer
will be ignored during this operation.
2. Load the NVM CMD register with the write flash page command.
3. Execute the SPM instruction. This requires the timed CCP sequence during self-programming.
The BUSY flag in the NVM STATUS register will be set until the write operation is finished. The FBUSY flag is set as long
the flash is busy, and the application section cannot be accessed.
30.11.2.6 Flash Range CRC
The flash range CRC command can be used to verify the content in an address range in flash after a self-programming.
1. Load the NVM CMD register with the flash range CRC command.
2. Load the start byte address in the NVM address register (NVM ADDR).
3. Load the end byte address in NVM data register (NVM DATA).
4. Set the CMDEX bit in the NVM CTRLA register. This requires the timed CCP sequence during self-programming.
The BUSY flag in the NVM STATUS register will be set, and the CPU is halted during the execution of the command.
The CRC checksum will be available in the NVM DATA register.
In order to use the flash range CRC command, all the boot lock bits must be unprogrammed (no locks). The command
execution will be aborted if the boot lock bits for an accessed location are set.
30.11.2.7 Erase Application Section
The erase application command is used to erase the complete application section.
1. Load the Z-pointer to point anywhere in the application section.
2. Load the NVM CMD register with the erase application section command
XMEGA B [MANUAL] 383
Atmel-8291C-AVR-XMEGA B -09/2014
3. Execute the SPM instruction. This requires the timed CCP sequence during self-programming.
The BUSY flag in the STATUS register will be set until the operation is finished. The CPU will be halted during the
complete execution of the command.
30.11.2.8 Erase Application Section / Boot Loader Section Page
The erase application section page erase and erase boot loader section page commands are used to erase one page in
the application section or boot loader section.
1. Load the Z-pointer with the flash page address to erase. The page address must be written to ZPAGE. Other bits
in the Z-pointer will be ignored during this operation.
2. Load the NVM CMD register with the erase application/boot section page command.
3. Execute the SPM instruction. This requires the timed CCP sequence during self-programming.
The BUSY flag in the NVM STATUS register will be set until the erase operation is finished. The FBUSY flag is set as
long the flash is busy, and the application section cannot be accessed.
30.11.2.9 Application Section / Boot Loader Section Page Write
The write application section page and write boot loader section page commands are used to write the flash page buffer
into one flash page in the application section or boot loader section.
1. Load the Z-pointer with the flash page to write. The page address must be written to FPAGE. Other bits in the Zpointer
will be ignored during this operation.
2. Load the NVM CMD register with the write application section/boot loader section page command.
3. Execute the SPM instruction. This requires the timed CCP sequence during self-programming.
The BUSY flag in the NVM STATUS register will be set until the write operation is finished. The FBUSY flag is set as long
the flash is busy, and the application section cannot be accessed.
An invalid page address in the Z-pointer will abort the NVM command. The erase application section page command
requires that the Z-pointer addresses the application section, and the erase boot section page command requires that
the Z-pointer addresses the boot loader section.
30.11.2.10 Erase and Write Application Section / Boot Loader Section Page
The erase and write application section page and erase and write boot loader section page commands are used to erase
one flash page and then write the flash page buffer into that flash page in the application section or boot loader section in
one atomic operation.
1. Load the Z-pointer with the flash page to write. The page address must be written to FPAGE. Other bits in the Zpointer
will be ignored during this operation.
2. Load the NVM CMD register with the erase and write application section/boot loader section page command.
3. Execute the SPM instruction. This requires the timed CCP sequence during self-programming.
The BUSY flag in the NVM STATUS register will be set until the operation is finished. The FBUSY flag is set as long as
the flash is busy, and the application section cannot be accessed.
An invalid page address in the Z-pointer will abort the NVM command. The erase and write application section command
requires that the Z-pointer addresses the application section, and the erase and write boot section page command
requires that the Z-pointer addresses the boot loader section.
30.11.2.11 Application Section / Boot Loader Section CRC
The application section CRC and boot loader section CRC commands can be used to verify the application section and
boot loader section content after self-programming.
1. Load the NVM CMD register with the application section/ boot load section CRC command.
2. Set the CMDEX bit in the NVM CTRLA register. This requires the timed CCP sequence during self-programming.
The BUSY flag in the NVM STATUS register will be set, and the CPU is halted during the execution of the CRC
command. The CRC checksum will be available in the NVM data registers.
XMEGA B [MANUAL] 384
Atmel-8291C-AVR-XMEGA B -09/2014
30.11.2.12 Erase User Signature Row
The erase user signature row command is used to erase the user signature row.
1. Load the NVM CMD register with the erase user signature row command.
2. Execute the SPM instruction. This requires the timed CCP sequence during self-programming.
The BUSY flag in the NVM STATUS register will be set, and the CPU will be halted until the erase operation is finished.
The user signature row is NRWW.
30.11.2.13 Write User Signature Row
The write signature row command is used to write the flash page buffer into the user signature row.
1. Set up the NVM CMD register to write user signature row command.
2. Execute the SPM instruction. This requires the timed CCP sequence during self-programming.
The BUSY flag in the NVM STATUS register will be set until the operation is finished, and the CPU will be halted during
the write operation. The flash page buffer will be cleared during the command execution after the write operation, but the
CPU is not halted during this stage.
30.11.2.14 Read User Signature Row / Production Signature Row
The read user signature row and read calibration row commands are used to read one byte from the user signature row
or production signature (calibration) row.
1. Load the Z-pointer with the byte address to read.
2. Load the NVM CMD register with the read user signature row / production signature (calibration) row command
3. Execute the LPM instruction.
The destination register will be loaded during the execution of the LPM instruction.
To ensure that LPM for reading flash will be executed correctly it is advised to disable interrupt while using either of these
commands.
30.11.3 NVM Fuse and Lock Bit Commands
The NVM flash commands that can be used for accessing the fuses and lock bits are listed in Table 30-3.
For self-programming of the fuses and lock bits, the trigger for action-triggered commands is to set the CMDEX bit in the
NVM CTRLA register (CMDEX). The read-triggered commands are triggered by executing the (E)LPM instruction (LPM).
The write-triggered commands are triggered by a executing the SPM instruction (SPM).
The Change Protected column indicates whether the trigger is protected by the configuration change protection (CCP)
during self-programming or not. The last two columns show the address pointer used for addressing and the
source/destination data register.
Section 30.11.3.1 on page 385 through Section 30.11.3.2 on page 385 explain in detail the algorithm for each NVM
operation.
Table 30-3. Fuse and lock bit commands.
CMD[6:0] Group Configuration Description Trigger
CPU
Halted
Change
Protected
NVM
Busy
Address
Pointer
Data
Register
0x00 NO_OPERATION No operation - - - - - -
Fuses and Lock Bits
0x07 READ_FUSES Read fuses CMDEX Y N Y ADDR DATA
0x08 WRITE_LOCK_BITS Write lock bits CMDEX N Y Y ADDR -
XMEGA B [MANUAL] 385
Atmel-8291C-AVR-XMEGA B -09/2014
30.11.3.1 Write Lock Bits
The write lock bits command is used to program the boot lock bits to a more secure settings from software.
1. Load the NVM DATA0 register with the new lock bit value.
2. Load the NVM CMD register with the write lock bit command.
3. Set the CMDEX bit in the NVM CTRLA register. This requires the timed CCP sequence during self-programming.
The BUSY flag in the NVM STATUS register will be set until the command is finished. The CPU is halted during the
complete execution of the command.
This command can be executed from both the boot loader section and the application section. The EEPROM and flash
page buffers are automatically erased when the lock bits are written.
30.11.3.2 Read Fuses
The read fuses command is used to read the fuses from software.
1. Load the NVM ADDR register with the address of the fuse byte to read.
2. Load the NVM CMD register with the read fuses command.
3. Set the CMDEX bit in the NVM CTRLA register. This requires the timed CCP sequence during self-programming.
The result will be available in the NVM DATA0 register. The CPU is halted during the complete execution of the
command.
30.11.4 EEPROM Programming
The EEPROM can be read and written from application code in any part of the flash. Its is both byte and page accessible.
This means that either one byte or one page can be written to the EEPROM at once. One byte is read from the EEPROM
during a read.
30.11.4.1 Addressing the EEPROM
The EEPROM can be accessed through the NVM controller (I/O mapped), similar to accessing the flash program
memory, or it can be memory mapped into the data memory space to be accessed similar to SRAM.
When accessing the EEPROM through the NVM controller, the NVM address (ADDR) register is used to address the
EEPROM, while the NVM data (DATA) register is used to store or load EEPROM data.
For EEPROM page programming, the ADDR register can be treated as having two sections. The least-significant bits
address the bytes within a page, while the most-significant bits address the page within the EEPROM. This is shown in
Figure 30-2 on page 386. The byte address in the page (E2BYTE) is held by the bits [BYTEMSB:0] in the ADDR register.
The remaining bits [PAGEMSB:BYTEMSB+1] in the ADDR register hold the EEPROM page address (E2PAGE).
Together E2BYTE and E2PAGE hold an absolute address to a byte in the EEPROM. The size of E2WORD and E2PAGE
will depend on the page and flash size in the device. Refer to the device datasheet for details on this.
XMEGA B [MANUAL] 386
Atmel-8291C-AVR-XMEGA B -09/2014
Figure 30-2. I/O mapped EEPROM addressing.
When EEPROM memory mapping is enabled, loading a data byte into the EEPROM page buffer can be performed
through direct or indirect store instructions. Only the least-significant bits of the EEPROM address are used to determine
locations within the page buffer, but the complete memory mapped EEPROM address is always required to ensure
correct address mapping. Reading from the EEPROM can be done directly using direct or indirect load instructions.
When a memory mapped EEPROM page buffer load operation is performed, the CPU is halted for two cycles before the
next instruction is executed.
When the EEPROM is memory mapped, the EEPROM page buffer load and EEPROM read functionality from the NVM
controller are disabled.
30.11.5 NVM EEPROM Commands
The NVM flash commands that can be used for accessing the EEPROM through the NVM controller are listed in Table
30-4.
For self-programming of the EEPROM, the trigger for action-triggered commands is to set the CMDEX bit in the NVM
CTRLA register (CMDEX). The read-triggered command is triggered by reading the NVM DATA0 register (DATA0).
The Change Protected column indicates whether the trigger is protected by the configuration change protection (CCP)
during self-programming or not. CCP is not required for external programming. The last two columns show the address
pointer used for addressing and the source/destination data register.
Section 30.11.5.1 on page 387 through Section 30.11.5.7 on page 388 explain in detail the algorithm for each EEPROM
operation.
Table 30-4. EEPROM self-programming commands.
E2PAGE E2BYTE
BIT
NVM ADDR
PAGEMSB BYTEMSB 0
PAGE DATA BYTE
EEPROM MEMORY PAGE
BYTE ADDRESS
WITHIN A PAGE
PAGE ADDRESS
WITHIN THE EEPROM
E2BYTE
00
01
02
E2PAGEEND
E2PAGE
00
01
02
E2END
CMD[6:0] Group Configuration Description Trigger
CPU
Halted
Change
Protected
NVM
Busy
Address
Pointer
Data
Register
0x00 NO_OPERATION No operation - - - - - -
EEPROM Page Buffer
0x33 LOAD_EEPROM_BUFFER Load EEPROM page buffer DATA0 N Y N ADDR DATA0
0x36 ERASE_EEPROM _BUFFER Erase EEPROM page buffer CMDEX N Y Y - -
XMEGA B [MANUAL] 387
Atmel-8291C-AVR-XMEGA B -09/2014
30.11.5.1 Load EEPROM Page Buffer
The load EEPROM page buffer command is used to load one byte into the EEPROM page buffer.
1. Load the NVM CMD register with the load EEPROM page buffer command.
2. Load the NVM ADDR0 register with the address to write.
3. Load the NVM DATA0 register with the data to write. This will trigger the command.
Repeat steps 2-3 until the arbitrary number of bytes are loaded into the page buffer.
30.11.5.2 Erase EEPROM Page Buffer
The erase EEPROM page buffer command is used to erase the EEPROM page buffer.
1. Load the NVM CMD register with the erase EEPROM buffer command.
2. Set the CMDEX bit in the NVM CTRLA register. This requires the timed CCP sequence during self-programming.
The BUSY flag in the NVM STATUS register will be set until the operation is finished.
30.11.5.3 Erase EEPROM Page
The erase EEPROM page command is used to erase one EEPROM page.
1. Set up the NVM CMD register to the erase EEPROM page command.
2. Load the NVM ADDR register with the address of the EEPROM page to erase.
3. Set the CMDEX bit in the NVM CTRLA register. This requires the timed CCP sequence during self-programming.
The BUSY flag in the NVM STATUS register will be set until the operation is finished.
The page erase commands will only erase the locations that are loaded and tagged in the EEPROM page buffer.
30.11.5.4 Write EEPROM Page
The write EEPROM page command is used to write all locations loaded in the EEPROM page buffer into one page in
EEPROM. Only the locations that are loaded and tagged in the EEPROM page buffer will be written.
1. Load the NVM CMD register with the write EEPROM page command.
2. Load the NVM ADDR register with the address of the EEPROM page to write.
3. Set the CMDEX bit in the NVM CTRLA register. This requires the timed CCP sequence during self-programming.
The BUSY flag in the NVM STATUS register will be set until the operation is finished.
30.11.5.5 Erase and Write EEPROM Page
The erase and write EEPROM page command is used to first erase an EEPROM page and then write the EEPROM
page buffer into that page in EEPROM in one atomic operation.
1. Load the NVM CMD register with the erase and write EEPROM page command.
2. Load the NVM ADDR register with the address of the EEPROM page to write.
3. Set the CMDEX bit in the NVM CTRLA register. This requires the timed CCP sequence during self-programming.
The BUSY flag in the NVM STATUS register will be set until the operation is finished.
EEPROM
0x32 ERASE_EEPROM_PAGE Erase EEPROM page CMDEX N Y Y ADDR -
0x34 WRITE_EEPROM_PAGE Write EEPROM page CMDEX N Y Y ADDR -
0x35 ERASE_WRITE_EEPROM_PAGE Erase and write EEPROM page CMDEX N Y Y ADDR -
0x30 ERASE_EEPROM Erase EEPROM CMDEX N Y Y - -
0x06 READ_EEPROM Read EEPROM CMDEX N Y N ADDR DATA0
CMD[6:0] Group Configuration Description Trigger
CPU
Halted
Change
Protected
NVM
Busy
Address
Pointer
Data
Register
XMEGA B [MANUAL] 388
Atmel-8291C-AVR-XMEGA B -09/2014
30.11.5.6 Erase EEPROM
The erase EEPROM command is used to erase all locations in all EEPROM pages that are loaded and tagged in the
EEPROM page buffer.
1. Set up the NVM CMD register to the erase EPPROM command.
2. Set the CMDEX bit in the NVM CTRLA register. This requires the timed CCP sequence during self-programming.
The BUSY flag in the NVM STATUS register will be set until the operation is finished.
30.11.5.7 Read EEPROM
The read EEPROM command is used to read one byte from the EEPROM.
1. Load the NVM CMD register with the read EEPROM command.
2. Load the NVM ADDR register with the address to read.
3. Set the CMDEX bit in the NVM CTRLA register. This requires the timed CCP sequence during self-programming.
The data byte read will be available in the NVM DATA0 register.
30.12 External Programming
External programming is the method for programming code and nonvolatile data into the device from an external
programmer or debugger. This can be done by both in-system or in mass production programming.
For external programming, the device is accessed through the PDI and PDI controller, and using either the JTAG or PDI
physical connection. For details on PDI and JTAG and how to enable and use the physical interface, refer to “Program
and Debug Interface” on page 361. The remainder of this section assumes that the correct physical connection to the
PDI is enabled. Doing this all data and program memory spaces are mapped into the linear PDI memory space. Figure
30-3 on page 389 shows the PDI memory space and the base address for each memory space in the device.
XMEGA B [MANUAL] 389
Atmel-8291C-AVR-XMEGA B -09/2014
Figure 30-3. Memory map for PDI accessing the data and program memories.
30.12.1 Enabling External Programming Interface
NVM programming from the PDI requires enabling using the following steps:
1. Load the RESET register in the PDI with 0x59.
2. Load the NVM key in the PDI.
3. Poll NVMEN in the PDI status register (PDI STATUS) until NVMEN is set.
When the NVMEN bit in the PDI STATUS register is set, the NVM interface is enabled and active from the PDI.
30.12.2 NVM Programming
When the PDI NVM interface is enabled, all memories in the device are memory mapped in the PDI address space. The
PDI controller does not need to access the NVM controller's address or data registers, but the NVM controller must be
loaded with the correct command (i.e., to read from any NVM, the controller must be loaded with the NVM read command
FLASH_BASE = 0x0800000
EPPROM_BASE = 0x08C0000
FUSE_BASE = 0x08F0020
DATAMEM_BASE = 0x1000000
APP_BASE = FLASH_BASE
BOOT_BASE = FLASH_BASE + SIZE_APPL
PROD_SIGNATURE_BASE = 0x008E0200
USER_SIGNATURE_BASE = 0x008E0400
0x0000000
FUSES
APPLICATION
SECTION
16 MB
BOOT SECTION
0x0800000
0x08F0020
TOP=0x1FFFFFF
EEPROM
0x08E0200 SIGNATURE ROW
0x08C0000
0x08C1000
DATAMEM
(mapped IO/SRAM) 16 MB
0x1000000
1 BYTE
XMEGA B [MANUAL] 390
Atmel-8291C-AVR-XMEGA B -09/2014
before loading data from the PDIBUS address space). For the reminder of this section, all references to reading and
writing data or program memory addresses from the PDI refer to the memory map shown in Figure 30-3 on page 389.
The PDI uses byte addressing, and hence all memory addresses must be byte addresses. When filling the flash or
EEPROM page buffers, only the least-significant bits of the address are used to determine locations within the page
buffer. Still, the complete memory mapped address for the flash or EEPROM page is required to ensure correct address
mapping.
During programming (page erase and page write) when the NVM is busy, the NVM is blocked for reading.
30.12.3 NVM Commands
The NVM commands that can be used for accessing the NVM memories from external programming are listed in Table
30-5 on page 390. This is a superset of the commands available for self-programming.
For external programming, the trigger for action-triggered commands is to set the CMDEX bit in the NVM CTRLA register
(CMDEX). The read-triggered commands are triggered by a direct or indirect load instruction (LDS or LD) from the PDI
(PDI read). The write-triggered commands are triggered by a direct or indirect store instruction (STS or ST) from the PDI
(PDI write).
“ Chip Erase” on page 391 through “ Write Fuse/ Lock Bit” on page 393 explain in detail the algorithm for each NVM
operation. The commands are protected by the lock bits, and if read and write lock is set, only the chip erase and flash
CRC commands are available.
Table 30-5. NVM commands available for external programming.
CMD[6:0] Commands / Operation Trigger
Change
Protected NVM Busy
0x00 No operation - - -
0x40 Chip erase(1) CMDEX Y Y
0x43 Read NVM PDI Read N N
Flash Page Buffer
0x23 Load flash page buffer PDI Write N N
0x26 Erase flash page buffer CMDEX Y Y
Flash
0x2B Erase flash page PDI write N Y
0x2E Write flash page PDI write N Y
0x2F Erase and write flash page PDI write N Y
0x78 Flash CRC CMDEX Y Y
Application Section
0x20 Erase application section PDI write N Y
0x22 Erase application section page PDI write N Y
0x24 Write application section page PDI write N Y
0x25 Erase and write application section page PDI write N Y
0x38 Application section CRC CMDEX Y Y
Boot Loader Section
0x68 Erase boot section PDI write N Y
0x2A Erase boot loader section page PDI write N Y
0x2C Write boot loader section page PDI write N Y
XMEGA B [MANUAL] 391
Atmel-8291C-AVR-XMEGA B -09/2014
Notes: 1. If the EESAVE fuse is programmed, the EEPROM is preserved during chip erase.
2. For consistency the name Calibration Row has been renamed to Production Signature Row throughout the document.
30.12.3.1 Chip Erase
The chip erase command is used to erase the flash program memory, EEPROM and lock bits. Erasing of the EEPROM
depends on EESAVE fuse setting. Refer to “FUSEBYTE5 – Fuse Byte 5” on page 32 for details. The user signature row,
production signature (calibration) row, and fuses are not affected.
1. Load the NVM CMD register with the chip erase command.
2. Set the CMDEX bit in the NVM CTRLA register. This requires the timed CCP sequence during self-programming.
Once this operation starts, the PDI bus between the PDI controller and the NVM is disabled, and the NVMEN bit in the
PDI STATUS register is cleared until the operation is finished. Poll the NVMEN bit until this is set, indicating that the PDI
bus is enabled.
The BUSY flag in the NVM STATUS register will be set until the operation is finished.
30.12.3.2 Read NVM
The read NVM command is used to read the flash, EEPROM, fuses, and signature and production signature (calibration)
row sections.
1. Load the NVM CMD register with the read NVM command.
2. Read the selected memory address by executing a PDI read operation.
0x2D Erase and write boot loader section page PDI write N Y
0x39 Boot loader section CRC NVMAA Y Y
Production Signature (Calibration)(2) and User Signature Sections
0x01 Read user signature row PDI read N N
0x18 Erase user signature row PDI write N Y
0x1A Write user signature row PDI write N Y
0x02 Read calibration row PDI read N N
Fuses and Lock Bits
0x07 Read fuse PDI read N N
0x4C Write fuse PDI write N Y
0x08 Write lock bits CMDEX Y Y
EEPROM Page Buffer
0x33 Load EEPROM page buffer PDI write N N
0x36 Erase EEPROM page buffer CMDEX Y Y
EEPROM
0x30 Erase EEPROM CMDEX Y Y
0x32 Erase EEPROM page PDI write N Y
0x34 Write EEPROM page PDI write N Y
0x35 Erase and write EEPROM page PDI write N Y
0x06 Read EEPROM PDI read N N
CMD[6:0] Commands / Operation Trigger
Change
Protected NVM Busy
XMEGA B [MANUAL] 392
Atmel-8291C-AVR-XMEGA B -09/2014
Dedicated read EEPROM, read fuse, read signature row, and read production signature (calibration) row commands are
also available for the various memory sections. The algorithm for these commands are the same as for the read NVM
command.
30.12.3.3 Erase Page Buffer
The erase flash page buffer and erase EEPROM page buffer commands are used to erase the flash and EEPROM page
buffers.
1. Load the NVM CMD register with the erase flash/EEPROM page buffer command.
2. Set the CMDEX bit in the NVM CTRLA register.
The BUSY flag in the NVM STATUS register will be set until the operation is completed.
30.12.3.4 Load Page Buffer
The load flash page buffer and load EEPROM page buffer commands are used to load one byte of data into the flash and
EEPROM page buffers.
1. Load the NVM CMD register with the load flash/EEPROM page buffer command.
2. Write the selected memory address by doing a PDI write operation.
Since the flash page buffer is word accessed and the PDI uses byte addressing, the PDI must write the flash page buffer
in the correct order. For the write operation, the low byte of the word location must be written before the high byte. The
low byte is then written into the temporary register. The PDI then writes the high byte of the word location, and the low
byte is then written into the word location page buffer in the same clock cycle.
The PDI interface is automatically halted before the next PDI instruction can be executed.
30.12.3.5 Erase Page
The erase application section page, erase boot loader section page, erase user signature row, and erase EEPROM page
commands are used to erase one page in the selected memory space.
1. Load the NVM CMD register with erase application section/boot loader section/user signature row/EEPROM page
command.
2. Set the CMDEX bit in the NVM CTRLA register.
The BUSY flag in the NVM STATUS register will be set until the operation is finished.
30.12.3.6 Write Page
The write application section page, write boot loader section page, write user signature row, and write EEPROM page
commands are used to write a loaded flash/EEPROM page buffer into the selected memory space.
1. Load the NVM CMD register with write application section/boot loader section/user signature row/EEPROM page
command.
2. Write the selected page by doing a PDI write. The page is written by addressing any byte location within the page.
The BUSY flag in the NVM STATUS register will be set until the operation is finished.
30.12.3.7 Erase and Write Page
The erase and write application section page, erase and write boot loader section page, and erase and write EEPROM
page commands are used to erase one page and then write a loaded flash/EEPROM page buffer into that page in the
selected memory space in one atomic operation.
1. Load the NVM CMD register with erase and write application section/boot loader section/user signature
row/EEPROM page command.
2. Write the selected page by doing a PDI write. The page is written by addressing any byte location within the page.
The BUSY flag in the NVM STATUS register will be set until the operation is finished.
30.12.3.8 Erase Application/ Boot Loader/ EEPROM Section
The erase application section, erase boot loader section, and erase EEPROM section commands are used to erase the
complete selected section.
XMEGA B [MANUAL] 393
Atmel-8291C-AVR-XMEGA B -09/2014
1. Load the NVM CMD register with Erase Application/ Boot/ EEPROM Section command
2. Set the CMDEX bit in the NVM CTRLA register.
The BUSY flag in the NVM STATUS register will be set until the operation is finished.
30.12.3.9 Application / Boot Section CRC
The application section CRC and boot loader section CRC commands can be used to verify the content of the selected
section after programming.
1. Load the NVM CMD register with application/ boot loader section CRC command.
2. Set the CMDEX bit in the NVM CTRLA register. This requires the timed CCP sequence during self-programming.
The BUSY flag in the NVM STATUS register will be set until the operation is finished. The CRC checksum will be
available in the NVM DATA register.
30.12.3.10 Flash CRC
The flash CRC command can be used to verify the content of the flash program memory after programming. The
command can be executed independently of the lock bit state.
1. Load the NVM CMD register with flash CRC command.
2. Set the CMDEX bit in the NVM CTRLA register.
Once this operation starts, the PDI bus between the PDI controller and the NVM is disabled, and the NVMEN bit in the
PDI STATUS register is cleared until the operation is finished. Poll the NVMEN bit until this is set again, indicting the PDI
bus is enabled.
The BUSY flag in the NVM STATUS register will be set until the operation is finished. The CRC checksum will be
available in the NVM DATA register.
30.12.3.11 Write Fuse/ Lock Bit
The write fuse and write lock bit commands are used to write the fuses and the lock bits to a more secure setting.
1. Load the NVM CMD register with the write fuse/ lock bit command.
2. Write the selected fuse or lock bits by doing a PDI write operation.
The BUSY flag in the NVM STATUS register will be set until the command is finished.
For lock bit write, the lock bit write command can also be used.
30.13 Register Description
Refer to “Register Description – NVM Controller” on page 26 for a complete register description of the NVM controller.
Refer to “Register Description – PDI Control and Status Registers” on page 373 for a complete register description of the
PDI.
30.14 Register Summary
Refer to “Register Description – NVM Controller” on page 26 for a complete register summary of the NVM controller.
Refer to “Register Summary” on page 374 for a complete register summary of the PDI.
XMEGA B [MANUAL] 394
Atmel-8291C-AVR-XMEGA B -09/2014
31. Peripheral Module Address Map
The address maps show the base address for each peripheral and module in XMEGA. All peripherals and modules are
not present in all XMEGA devices, refer to device data sheet for the peripherals module address map for a specific
device.
Base Address Name Description Page
0x0000 GPIO General Purpose IO Registers page 42
0x0010 VPORT0 Virtual Port 0 page 132
0x0014 VPORT1 Virtual Port 1
0x0018 VPORT2 Virtual Port 2
0x001C VPORT3 Virtual Port 3
0x0030 CPU CPU page 19
0x0040 CLK Clock Control page 96
0x0048 SLEEP Sleep Controller page 101
0x0050 OSC Oscillator Control page 96
0x0060 DFLLRC32M DFLL for the 32 MHz Internal RC Oscillator page 96
0x0068 DFLLRC2M DFLL for the 2 MHz RC Oscillator
0x0070 PR Power Reduction page 98
0x0078 RST Reset Controller page 109
0x0080 WDT Watch-Dog Timer page 114
0x0090 MCU MCU Control page 42
0x00A0 PMIC Programmable Multilevel Interrupt Controller page 122
0x00B0 PORTCFG Port Configuration page 146
0x00C0 AES AES Module page 292
0x0100 DMA DMA Controller page 62
0x0180 EVSYS Event System page 74
0x01C0 NVM Non Volatile Memory (NVM) Controller page 46
0x0200 ADCA Analog to Digital Converter on port A page 344
0x0240 ADCB Analog to Digital Converter on port B
0x0380 ACA Analog Comparator pair on port A page 353
0x0390 ACB Analog Comparator pair on port B
0x0400 RTC Real Time Counter page 205
0x0480 TWIC Two Wire Interface on port C page 254
0x04C0 USB Universal Serial Bus Interface page 281
0x0600 PORTA Port A page 146
0x0620 PORTB Port B
0x0640 PORTC Port C
0x0660 PORTD Port D
0x0680 PORTE Port E
0x06C0 PORTG Port G
0x0760 PORTM Port M
0x07E0 PORTR Port R
0x0800 TCC0 Timer/Counter 0 on port C page 172
0x0840 TCC1 Timer/Counter 1 on port C
0x0880 AWEXC Advanced Waveform Extension on port C page 195
0x0890 HIRESC High Resolution Extension on port C page 197
0x08A0 USARTC0 USART 0 on port C page 281
0x08C0 SPIC Serial Peripheral Interface on port C page 260
0x08F0 IRCOM Infrared Communication Module page 285
0x0A00 TCE0 Timer/Counter 0 on port E page 172
0x0AA0 USARTE0 USART 0 on port E page 281
0x0D00 LCD LCD - Liquid Crystal Display page 319
Atmel-8291C-AVR-XMEGA B -09/2014 395
32. Instruction Set Summary
Mnemonics Operands Description Operation Flags #Clocks
Arithmetic and Logic Instructions
ADD Rd, Rr Add without Carry Rd ← Rd + Rr Z,C,N,V,S,H 1
ADC Rd, Rr Add with Carry Rd ← Rd + Rr + C Z,C,N,V,S,H 1
ADIW Rd, K Add Immediate to Word Rd ← Rd + 1:Rd + K Z,C,N,V,S 2
SUB Rd, Rr Subtract without Carry Rd ← Rd - Rr Z,C,N,V,S,H 1
SUBI Rd, K Subtract Immediate Rd ← Rd - K Z,C,N,V,S,H 1
SBC Rd, Rr Subtract with Carry Rd ← Rd - Rr - C Z,C,N,V,S,H 1
SBCI Rd, K Subtract Immediate with Carry Rd ← Rd - K - C Z,C,N,V,S,H 1
SBIW Rd, K Subtract Immediate from Word Rd + 1:Rd ← Rd + 1:Rd - K Z,C,N,V,S 2
AND Rd, Rr Logical AND Rd ← Rd • Rr Z,N,V,S 1
ANDI Rd, K Logical AND with Immediate Rd ← Rd • K Z,N,V,S 1
OR Rd, Rr Logical OR Rd ← Rd v Rr Z,N,V,S 1
ORI Rd, K Logical OR with Immediate Rd ← Rd v K Z,N,V,S 1
EOR Rd, Rr Exclusive OR Rd ← Rd ⊕ Rr Z,N,V,S 1
COM Rd One’s Complement Rd ← $FF - Rd Z,C,N,V,S 1
NEG Rd Two’s Complement Rd ← $00 - Rd Z,C,N,V,S,H 1
SBR Rd,K Set Bit(s) in Register Rd ← Rd v K Z,N,V,S 1
CBR Rd,K Clear Bit(s) in Register Rd ← Rd • ($FFh - K) Z,N,V,S 1
INC Rd Increment Rd ← Rd + 1 Z,N,V,S 1
DEC Rd Decrement Rd ← Rd - 1 Z,N,V,S 1
TST Rd Test for Zero or Minus Rd ← Rd • Rd Z,N,V,S 1
CLR Rd Clear Register Rd ← Rd ⊕ Rd Z,N,V,S 1
SER Rd Set Register Rd ← $FF None 1
MUL Rd,Rr Multiply Unsigned R1:R0 ← Rd x Rr (UU) Z,C 2
MULS Rd,Rr Multiply Signed R1:R0 ← Rd x Rr (SS) Z,C 2
MULSU Rd,Rr Multiply Signed with Unsigned R1:R0 ← Rd x Rr (SU) Z,C 2
FMUL Rd,Rr Fractional Multiply Unsigned R1:R0 ← Rd x Rr<<1 (UU) Z,C 2
FMULS Rd,Rr Fractional Multiply Signed R1:R0 ← Rd x Rr<<1 (SS) Z,C 2
FMULSU Rd,Rr Fractional Multiply Signed with Unsigned R1:R0 ← Rd x Rr<<1 (SU) Z,C 2
DES K Data Encryption if (H = 0) then R15:R0
else if (H = 1) then
R15:R0
←
←
Encrypt(R15:R0, K)
Decrypt(R15:R0, K)
1/2
Branch instructions
RJMP k Relative Jump PC ← PC + k + 1 None 2
IJMP Indirect Jump to (Z) PC(15:0)
PC(21:16)
←
←
Z,
0
None 2
EIJMP Extended Indirect Jump to (Z) PC(15:0)
PC(21:16)
←
←
Z,
EIND
None 2
JMP k Jump PC ← k None 3
Atmel-8291C-AVR-XMEGA B -09/2014 396
RCALL k Relative Call Subroutine PC ← PC + k + 1 None 2 / 3(1)
ICALL Indirect Call to (Z) PC(15:0)
PC(21:16)
←
←
Z,
0
None 2 / 3(1)
EICALL Extended Indirect Call to (Z) PC(15:0)
PC(21:16)
←
←
Z,
EIND
None 3(1)
CALL k call Subroutine PC ← k None 3 / 4(1)
RET Subroutine Return PC ← STACK None 4 / 5(1)
RETI Interrupt Return PC ← STACK I 4 / 5(1)
CPSE Rd,Rr Compare, Skip if Equal if (Rd = Rr) PC ← PC + 2 or 3 None 1 / 2 / 3
CP Rd,Rr Compare Rd - Rr Z,C,N,V,S,H 1
CPC Rd,Rr Compare with Carry Rd - Rr - C Z,C,N,V,S,H 1
CPI Rd,K Compare with Immediate Rd - K Z,C,N,V,S,H 1
SBRC Rr, b Skip if Bit in Register Cleared if (Rr(b) = 0) PC ← PC + 2 or 3 None 1 / 2 / 3
SBRS Rr, b Skip if Bit in Register Set if (Rr(b) = 1) PC ← PC + 2 or 3 None 1 / 2 / 3
SBIC A, b Skip if Bit in I/O Register Cleared if (I/O(A,b) = 0) PC ← PC + 2 or 3 None 2 / 3 / 4
SBIS A, b Skip if Bit in I/O Register Set If (I/O(A,b) =1) PC ← PC + 2 or 3 None 2 / 3 / 4
BRBS s, k Branch if Status Flag Set if (SREG(s) = 1) then PC ← PC + k + 1 None 1 / 2
BRBC s, k Branch if Status Flag Cleared if (SREG(s) = 0) then PC ← PC + k + 1 None 1 / 2
BREQ k Branch if Equal if (Z = 1) then PC ← PC + k + 1 None 1 / 2
BRNE k Branch if Not Equal if (Z = 0) then PC ← PC + k + 1 None 1 / 2
BRCS k Branch if Carry Set if (C = 1) then PC ← PC + k + 1 None 1 / 2
BRCC k Branch if Carry Cleared if (C = 0) then PC ← PC + k + 1 None 1 / 2
BRSH k Branch if Same or Higher if (C = 0) then PC ← PC + k + 1 None 1 / 2
BRLO k Branch if Lower if (C = 1) then PC ← PC + k + 1 None 1 / 2
BRMI k Branch if Minus if (N = 1) then PC ← PC + k + 1 None 1 / 2
BRPL k Branch if Plus if (N = 0) then PC ← PC + k + 1 None 1 / 2
BRGE k Branch if Greater or Equal, Signed if (N ⊕ V= 0) then PC ← PC + k + 1 None 1 / 2
BRLT k Branch if Less Than, Signed if (N ⊕ V= 1) then PC ← PC + k + 1 None 1 / 2
BRHS k Branch if Half Carry Flag Set if (H = 1) then PC ← PC + k + 1 None 1 / 2
BRHC k Branch if Half Carry Flag Cleared if (H = 0) then PC ← PC + k + 1 None 1 / 2
BRTS k Branch if T Flag Set if (T = 1) then PC ← PC + k + 1 None 1 / 2
BRTC k Branch if T Flag Cleared if (T = 0) then PC ← PC + k + 1 None 1 / 2
BRVS k Branch if Overflow Flag is Set if (V = 1) then PC ← PC + k + 1 None 1 / 2
BRVC k Branch if Overflow Flag is Cleared if (V = 0) then PC ← PC + k + 1 None 1 / 2
BRIE k Branch if Interrupt Enabled if (I = 1) then PC ← PC + k + 1 None 1 / 2
BRID k Branch if Interrupt Disabled if (I = 0) then PC ← PC + k + 1 None 1 / 2
Data transfer instructions
MOV Rd, Rr Copy Register Rd ← Rr None 1
MOVW Rd, Rr Copy Register Pair Rd+1:Rd ← Rr+1:Rr None 1
Mnemonics Operands Description Operation Flags #Clocks
Atmel-8291C-AVR-XMEGA B -09/2014 397
LDI Rd, K Load Immediate Rd ← K None 1
LDS Rd, k Load Direct from data space Rd ← (k) None 2(1)(2)
LD Rd, X Load Indirect Rd ← (X) None 1(1)(2)
LD Rd, X+ Load Indirect and Post-Increment Rd
X
←
←
(X)
X + 1
None 1(1)(2)
LD Rd, -X Load Indirect and Pre-Decrement X ← X - 1,
Rd ← (X)
←
←
X - 1
(X)
None 2(1)(2)
LD Rd, Y Load Indirect Rd ← (Y) ← (Y) None 1(1)(2)
LD Rd, Y+ Load Indirect and Post-Increment Rd
Y
←
←
(Y)
Y + 1
None 1(1)(2)
LD Rd, -Y Load Indirect and Pre-Decrement Y
Rd
←
←
Y - 1
(Y)
None 2(1)(2)
LDD Rd, Y+q Load Indirect with Displacement Rd ← (Y + q) None 2(1)(2)
LD Rd, Z Load Indirect Rd ← (Z) None 1(1)(2)
LD Rd, Z+ Load Indirect and Post-Increment Rd
Z
←
←
(Z),
Z+1
None 1(1)(2)
LD Rd, -Z Load Indirect and Pre-Decrement Z
Rd
←
←
Z - 1,
(Z)
None 2(1)(2)
LDD Rd, Z+q Load Indirect with Displacement Rd ← (Z + q) None 2(1)(2)
STS k, Rr Store Direct to Data Space (k) ← Rd None 2(1)
ST X, Rr Store Indirect (X) ← Rr None 1(1)
ST X+, Rr Store Indirect and Post-Increment (X)
X
←
←
Rr,
X + 1
None 1(1)
ST -X, Rr Store Indirect and Pre-Decrement X
(X)
←
←
X - 1,
Rr
None 2(1)
ST Y, Rr Store Indirect (Y) ← Rr None 1(1)
ST Y+, Rr Store Indirect and Post-Increment (Y)
Y
←
←
Rr,
Y + 1
None 1(1)
ST -Y, Rr Store Indirect and Pre-Decrement Y
(Y)
←
←
Y - 1,
Rr
None 2(1)
STD Y+q, Rr Store Indirect with Displacement (Y + q) ← Rr None 2(1)
ST Z, Rr Store Indirect (Z) ← Rr None 1(1)
ST Z+, Rr Store Indirect and Post-Increment (Z)
Z
←
←
Rr
Z + 1
None 1(1)
ST -Z, Rr Store Indirect and Pre-Decrement Z ← Z - 1 None 2(1)
STD Z+q,Rr Store Indirect with Displacement (Z + q) ← Rr None 2(1)
LPM Load Program Memory R0 ← (Z) None 3
LPM Rd, Z Load Program Memory Rd ← (Z) None 3
LPM Rd, Z+ Load Program Memory and PostIncrement
Rd
Z
←
←
(Z),
Z + 1
None 3
ELPM Extended Load Program Memory R0 ← (RAMPZ:Z) None 3
ELPM Rd, Z Extended Load Program Memory Rd ← (RAMPZ:Z) None 3
ELPM Rd, Z+ Extended Load Program Memory and
Post-Increment
Rd
Z
←
←
(RAMPZ:Z),
Z + 1
None 3
SPM Store Program Memory (RAMPZ:Z) ← R1:R0 None -
Mnemonics Operands Description Operation Flags #Clocks
Atmel-8291C-AVR-XMEGA B -09/2014 398
SPM Z+ Store Program Memory and PostIncrement
by 2
(RAMPZ:Z)
Z
←
←
R1:R0,
Z + 2
None -
IN Rd, A In From I/O Location Rd ← I/O(A) None 1
OUT A, Rr Out To I/O Location I/O(A) ← Rr None 1
PUSH Rr Push Register on Stack STACK ← Rr None 1(1)
POP Rd Pop Register from Stack Rd ← STACK None 2(1)
XCH Z, Rd Exchange RAM location Temp
Rd
(Z)
←
←
←
Rd,
(Z),
Temp
None 2
LAS Z, Rd Load and Set RAM location Temp
Rd
(Z)
←
←
←
Rd,
(Z),
Temp v (Z)
None 2
LAC Z, Rd Load and Clear RAM location Temp
Rd
(Z)
←
←
←
Rd,
(Z),
($FFh – Rd) • (Z)
None 2
LAT Z, Rd Load and Toggle RAM location Temp
Rd
(Z)
←
←
←
Rd,
(Z),
Temp ⊕ (Z)
None 2
Bit and bit-test instructions
LSL Rd Logical Shift Left Rd(n+1)
Rd(0)
C
←
←
←
Rd(n),
0,
Rd(7)
Z,C,N,V,H 1
LSR Rd Logical Shift Right Rd(n)
Rd(7)
C
←
←
←
Rd(n+1),
0,
Rd(0)
Z,C,N,V 1
ROL Rd Rotate Left Through Carry Rd(0)
Rd(n+1)
C
←
←
←
C,
Rd(n),
Rd(7)
Z,C,N,V,H 1
ROR Rd Rotate Right Through Carry Rd(7)
Rd(n)
C
←
←
←
C,
Rd(n+1),
Rd(0)
Z,C,N,V 1
ASR Rd Arithmetic Shift Right Rd(n) ← Rd(n+1), n=0..6 Z,C,N,V 1
SWAP Rd Swap Nibbles Rd(3..0) ↔ Rd(7..4) None 1
BSET s Flag Set SREG(s) ← 1 SREG(s) 1
BCLR s Flag Clear SREG(s) ← 0 SREG(s) 1
SBI A, b Set Bit in I/O Register I/O(A, b) ← 1 None 1
CBI A, b Clear Bit in I/O Register I/O(A, b) ← 0 None 1
BST Rr, b Bit Store from Register to T T ← Rr(b) T 1
BLD Rd, b Bit load from T to Register Rd(b) ← T None 1
SEC Set Carry C ← 1 C 1
CLC Clear Carry C ← 0 C 1
SEN Set Negative Flag N ← 1 N 1
CLN Clear Negative Flag N ← 0 N 1
SEZ Set Zero Flag Z ← 1 Z 1
CLZ Clear Zero Flag Z ← 0 Z 1
SEI Global Interrupt Enable I ← 1 I 1
CLI Global Interrupt Disable I ← 0 I 1
Mnemonics Operands Description Operation Flags #Clocks
Atmel-8291C-AVR-XMEGA B -09/2014 399
Notes: 1. Cycle times for data memory accesses assume internal memory accesses, and are not valid for accesses via the external RAM interface.
2. One extra cycle must be added when accessing Internal SRAM.
SES Set Signed Test Flag S ← 1 S 1
CLS Clear Signed Test Flag S ← 0 S 1
SEV Set Two’s Complement Overflow V ← 1 V 1
CLV Clear Two’s Complement Overflow V ← 0 V 1
SET Set T in SREG T ← 1 T 1
CLT Clear T in SREG T ← 0 T 1
SEH Set Half Carry Flag in SREG H ← 1 H 1
CLH Clear Half Carry Flag in SREG H ← 0 H 1
MCU control instructions
BREAK Break (See specific descr. for BREAK) None 1
NOP No Operation None 1
SLEEP Sleep (see specific descr. for Sleep) None 1
WDR Watchdog Reset (see specific descr. for WDR) None 1
Mnemonics Operands Description Operation Flags #Clocks
XMEGA B [MANUAL] 400
Atmel-8291C-AVR-XMEGA B -09/2014
33. Datasheet Revision History
Please note that the referring page numbers in this section are referring to this document. The referring revision in this
section are referring to the document revision.
33.1 8291C – 06/2014
33.2 8291B – 01/2013
1. Replaced RCOSC48M with USBRCOSC in Section 4.15.19 on page 40 and in Section 4.20 on page 45.
2. Changed VCC to AVCC in the section “AC – Analog Comparator” on page 345 and onwards, and in “Voltage
Reference Selection” on page 324.
3. Updated last page and footers from template of May 5 2014.
1. Added XMEGA B feature overview inTable 2-1 on page 5.
2. References to Calibration Row updated to Production Signature Row for consistency.
3. Added reference to “NVM Flash Commands” on page 380 in “Production Signature Row” on page 22.
4. Updated “LOCKBITS – Lock Bits register” on page 30. Description of Bit[1:0] updated and added a table note.
5. Title of Table 4-12 on page 35 changed to “Lock bit protection mode.”
6. Updated “TRIGSRC – Trigger Source” on page 57. The description Bit[7:0] updated.
7 Updated description of “CHnCTRL – Event Channel n Control register” on page 72.
8. Updated the formula of COMP register in “DFLL 2MHz and DFLL 32MHz” on page 82.
9. Updated Table 9-2 on page 105, the “Programmable BODLEVEL setting.”
10. Table note added to the Table 10-1 on page 112.
11. Table note added to the Table 10-2 on page 113.
12. Updated “Port Interrupt” on page 129.
13. Updated Table 12-3 on page 130. “Both edge” replaced by “Any edge”.
14. Updated “Port Event” on page 130.
15. Updated Table 12-10 on page 142, and Table 12-11 on page 143.
16. Updated “Event Action Controlled Operation” on page 153.
17. Updated Figure 13-10 on page 155. CH7MUX changed to CHnMUX.
18 Updated Table 13-2 in “DMA Support” on page 160.
19. Updated Table 14-3 on page 179. CMD changed to BYTEM[1:0]
20. Updated “Clock Domains” on page 199.
21. Updated description in “For Output Endpoints” on page 213.
22. Updated both formula of “BAUD – Baud Rate register” on page 247
23. Updated “DATA – Data register” on page 248. Added the description of ADDR[7:1] and ADDR[0]
XMEGA B [MANUAL] 401
Atmel-8291C-AVR-XMEGA B -09/2014
33.3 8291A – 07/2011
24. Updated the formula in “Fractional Baud Rate Generation” on page 271.
25. Updated Figure 21-9 on page 272, the “Fractional baud rate example.”
26. Added Table 21-5 on page 272, the “USART baud rate.”
27. Updated “ADC Input Model” on page 329.
26. Updated “Synchronous Sampling” on page 330.
27 Updated description of “Bit 3:0 – COUNT[3:0]: Number of Input Channels Included in Scan” in “SCAN – Input
Channel Scan register” on page 343
28. Updated Analog Comparator overview block diagram in Figure 27-1 on page 346.
1. Initial revision edited from XMEGA AU Manual rev A 07/11
XMEGA B [MANUAL] 402
Atmel-8291C-AVR-XMEGA B -09/2014
Table of Contents
1. About the Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Reading the Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Resources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Recommended Reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Atmel AVR CPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3 Architectural Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.4 ALU - Arithmetic Logic Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.5 Program Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.6 Instruction Execution Timing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.7 Status Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.8 Stack and Stack Pointer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.9 Register File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.10 RAMP and Extended Indirect Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.11 Accessing 16-bit Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.12 Configuration Change Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.13 Fuse Lock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.14 Register Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.15 Register Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4. Memories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.3 Flash Program Memory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.4 Fuses and Lockbits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.5 Data Memory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.6 Internal SRAM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.7 EEPROM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.8 I/O Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.9 Data Memory and Bus Arbitration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.10 Memory Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.11 Device ID and Revision. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.12 I/O Memory Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.13 Register Description – NVM Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.14 Register Descriptions – Fuses and Lock Bits . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.15 Register Description – Production Signature Row . . . . . . . . . . . . . . . . . . . . . 36
4.16 Register Description – General Purpose I/O Memory. . . . . . . . . . . . . . . . . . . 42
4.17 Register Descriptions – MCU Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.18 Register Summary - NVM Controller. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.19 Register Summary - Fuses and Lock Bits. . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.20 Register Summary - Production Signature Row . . . . . . . . . . . . . . . . . . . . . . . 45
4.21 Register Summary – General Purpose I/O Registers . . . . . . . . . . . . . . . . . . . 46
4.22 Register Summary – MCU Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.23 Interrupt Vector Summary – NVM Controller . . . . . . . . . . . . . . . . . . . . . . . . . 46
XMEGA B [MANUAL] 403
Atmel-8291C-AVR-XMEGA B -09/2014
5. DMAC - Direct Memory Access Controller . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.3 DMA Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.4 Transfer Triggers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.5 Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.6 Priority Between Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.7 Double Buffering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.8 Transfer Buffers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.9 Error detection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.10 Software Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.11 Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.12 Interrupts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.13 Register Description – DMA Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.14 Register Description – DMA Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.15 Register Summary – DMA Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.16 Register Summary – DMA Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.17 DMA Interrupt Vector Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6. Event System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.3 Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.4 Event Routing Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.5 Event Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.6 Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.7 Quadrature Decoder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.8 Register Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
6.9 Register Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
7. System Clock and Clock Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
7.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
7.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
7.3 Clock Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
7.4 Clock Sources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
7.5 System Clock Selection and Prescalers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
7.6 PLL with 1x-31x Multiplication Factor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
7.7 DFLL 2MHz and DFLL 32MHz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
7.8 PLL and External Clock Source Failure Monitor . . . . . . . . . . . . . . . . . . . . . . . 82
7.9 Register Description – Clock. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
7.10 Register Description – Oscillator. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
7.11 Register Description – DFLL32M/DFLL2M . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
7.12 Register Summary - Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
7.13 Register Summary - Oscillator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
7.14 Register Summary - DFLL32M/DFLL2M. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
7.15 Oscillator Failure Interrupt Vector Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 94
8. Power Management and Sleep Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
8.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
8.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
8.3 Sleep Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
XMEGA B [MANUAL] 404
Atmel-8291C-AVR-XMEGA B -09/2014
8.4 Power Reduction Registers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
8.5 Minimizing Power Consumption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
8.6 Register Description – Sleep. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
8.7 Register Description – Power Reduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
8.8 Register Summary - Sleep . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
8.9 Register Summary - Power Reduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
9. Reset System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
9.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
9.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
9.3 Reset Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
9.4 Reset Sources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
9.5 Register Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
9.6 Register Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
10. WDT – Watchdog Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
10.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
10.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
10.3 Normal Mode Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
10.4 Window Mode Operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
10.5 Watchdog Timer Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
10.6 Configuration Protection and Lock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
10.7 Registers Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
10.8 Register Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
11. Interrupts and Programmable Multilevel Interrupt Controller . . . . . . . 115
11.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
11.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
11.3 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
11.4 Interrupts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
11.5 Interrupt level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
11.6 Interrupt priority. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
11.7 Interrupt vector locations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
11.8 Register Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
11.9 Register Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
12. I/O Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
12.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
12.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
12.3 I/O Pin Use and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
12.4 Reading the Pin Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
12.5 Input Sense Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
12.6 Port Interrupt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
12.7 Port Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
12.8 Alternate Port Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
12.9 Clock and Event Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
12.10 Multi-pin configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
12.11 Virtual Ports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
12.12 Register Descriptions – Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
12.13 Register Descriptions – Port Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 140
12.14 Register Descriptions – Virtual Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
12.15 Register Summary – Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
XMEGA B [MANUAL] 405
Atmel-8291C-AVR-XMEGA B -09/2014
12.16 Register Summary – Port Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
12.17 Register Summary – Virtual Ports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
12.18 Interrupt Vector Summary – Ports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
13. TC0/1 – 16-bit Timer/Counter Type 0 and 1 . . . . . . . . . . . . . . . . . . . . . . 148
13.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
13.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
13.3 Block Diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
13.4 Clock and Event Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
13.5 Double Buffering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
13.6 Counter Operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
13.7 Capture Channel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
13.8 Compare Channel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
13.9 Interrupts and events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
13.10 DMA Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
13.11 Timer/Counter Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
13.12 Register Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
13.13 Register Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
13.14 Interrupt Vector Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
14. TC2 – 16-bit Timer/Counter Type 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
14.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
14.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
14.3 Block Diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
14.4 Clock Sources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
14.5 Counter Operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
14.6 Compare Channel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
14.7 Interrupts and Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
14.8 DMA Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
14.9 Timer/Counter Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
14.10 Register Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
14.11 Register Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
14.12 Interrupt Vector Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
15. AWeX – Advanced Waveform Extension . . . . . . . . . . . . . . . . . . . . . . . . . 185
15.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
15.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
15.3 Port Override. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
15.4 Dead-time Insertion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
15.5 Pattern Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
15.6 Fault Protection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
15.7 Register Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
15.8 Register Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
16. Hi-Res – High-Resolution Extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
16.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
16.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
16.3 Register Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
16.4 Register Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
17. RTC – Real-Time Counter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
17.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
XMEGA B [MANUAL] 406
Atmel-8291C-AVR-XMEGA B -09/2014
17.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
17.3 Register Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
17.4 Register Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
17.5 Interrupt Vector Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
18. USB – Universal Serial Bus Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
18.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
18.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
18.3 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
18.4 SRAM Memory Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
18.5 Clock Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
18.6 Ping-pong Operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
18.7 Multipacket Transfers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
18.8 Auto Zero Length Packet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
18.9 Transaction Complete FIFO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
18.10 Interrupts and Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
18.11 VBUS Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
18.12 On-chip Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
18.13 Register Description – USB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
18.14 Register Description – USB Endpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
18.15 Register Description - Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
18.16 Register Summary – USB Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
18.17 Register Summary – USB Endpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
18.18 Register Summary – Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
18.19 USB Interrupt Vector Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
19. TWI – Two-Wire Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
19.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
19.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
19.3 General TWI Bus Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
19.4 TWI Bus State Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
19.5 TWI Master Operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
19.6 TWI Slave Operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
19.7 Enabling External Driver Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
19.8 Register Description – TWI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
19.9 Register Description – TWI Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
19.10 Register Description – TWI Slave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
19.11 Register Summary - TWI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
19.12 Register Summary - TWI Master. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
19.13 Register Summary - TWI Slave. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
19.14 Interrupt Vector Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
20. SPI – Serial Peripheral Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
20.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
20.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
20.3 Master Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
20.4 Slave Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
20.5 Data Modes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
20.6 DMA Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
20.7 Register Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
20.8 Register Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
20.9 Interrupt vector Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
XMEGA B [MANUAL] 407
Atmel-8291C-AVR-XMEGA B -09/2014
21. USART . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
21.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
21.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
21.3 Clock Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
21.4 Frame Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
21.5 USART Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
21.6 Data Transmission - The USART Transmitter . . . . . . . . . . . . . . . . . . . . . . . 267
21.7 Data Reception - The USART Receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
21.8 Asynchronous Data Reception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
21.9 Fractional Baud Rate Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
21.10 USART in Master SPI Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
21.11 USART SPI vs. SPI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
21.12 Multiprocessor Communication Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
21.13 IRCOM Mode of Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
21.14 DMA Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
21.15 Register Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
21.16 Register Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
21.17 Interrupt Vector Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
22. IRCOM - IR Communication Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
22.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
22.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
22.3 Registers Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
22.4 Register Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
23. AES and DES Crypto Engines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
23.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
23.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
23.3 DES Instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
23.4 AES Crypto Module. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
23.5 Register Description – AES. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
23.6 Register summary – AES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
23.7 Interrupt vector summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
24. CRC – Cyclic Redundancy Check Generator . . . . . . . . . . . . . . . . . . . . . 293
24.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
24.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
24.3 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
24.4 CRC on Flash memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
24.5 CRC on DMA Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
24.6 CRC using the I/O Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
24.7 Register Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
24.8 Register Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
25. LCD – Liquid Crystal Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
25.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
25.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
25.3 Block Diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
25.4 Mode of Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
25.5 Register Description – LCD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
25.6 Register Summary – LCD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
25.7 Interrupt Vector Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
XMEGA B [MANUAL] 408
Atmel-8291C-AVR-XMEGA B -09/2014
26. ADC – Analog-to-Digital Converter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
26.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
26.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
26.3 Input Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
26.4 Sampling Time Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
26.5 Voltage Reference Selection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
26.6 Conversion Result. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
26.7 Compare Function. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
26.8 Starting a Conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
26.9 ADC Clock and Conversion Timing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
26.10 ADC Input Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
26.11 DMA Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
26.12 Interrupts and Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
26.13 Calibration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
26.14 Synchronous Sampling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
26.15 Register Description – ADC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
26.16 Register Description - ADC Channel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
26.17 Register Summary – ADC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
26.18 Register Summary – ADC Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
26.19 Interrupt vector Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
27. AC – Analog Comparator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
27.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
27.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
27.3 Input Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
27.4 Signal Compare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
27.5 Interrupts and Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
27.6 Window Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
27.7 Input Hysteresis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
27.8 Register Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
27.9 Register Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
27.10 Interrupt vector Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
28. IEEE 1149.1 JTAG Boundary Scan Interface . . . . . . . . . . . . . . . . . . . . . 354
28.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
28.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
28.3 TAP - Test Access Port. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
28.4 JTAG Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
28.5 Boundary Scan Chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
28.6 Data Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
29. Program and Debug Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
29.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
29.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
29.3 PDI Physical . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
29.4 JTAG Physical. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
29.5 PDI Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368
29.6 Register Description – PDI Instruction and Addressing Registers . . . . . . . . 371
29.7 Register Description – PDI Control and Status Registers. . . . . . . . . . . . . . . 373
29.8 Register Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
XMEGA B [MANUAL] 409
Atmel-8291C-AVR-XMEGA B -09/2014
30. Memory Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
30.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
30.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
30.3 NVM Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
30.4 NVM Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
30.5 NVM Controller Busy Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
30.6 Flash and EEPROM Page Buffers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
30.7 Flash and EEPROM Programming Sequences . . . . . . . . . . . . . . . . . . . . . . 377
30.8 Protection of NVM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
30.9 Preventing NVM Corruption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
30.10 CRC Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
30.11 Self-programming and Boot Loader Support . . . . . . . . . . . . . . . . . . . . . . . . 379
30.12 External Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
30.13 Register Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
30.14 Register Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
31. Peripheral Module Address Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
32. Instruction Set Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
33. Datasheet Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
33.1 8291C – 06/2014. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
33.2 8291B – 01/2013. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
33.3 8291A – 07/2011. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
Atmel Corporation 1600 Technology Drive, San Jose, CA 95110 USA T: (+1)(408) 441.0311 F: (+1)(408) 436.4200 | www.atmel.com
© 2014 Atmel Corporation. All rights reserved. / Rev.: 8291C–AVR–XMEGA B –Manual–09/2014
Atmel®, Atmel logo and combinations thereof, Enabling Unlimited Possibilities®, and others are registered trademarks or trademarks of Atmel Corporation or its
subsidiaries. Other terms and product names may be trademarks of others.
DISCLAIMER: The information in this document is provided in connection with Atmel products. No license, express or implied, by estoppel or otherwise, to any intellectual property right is
granted by this document or in connection with the sale of Atmel products. EXCEPT AS SET FORTH IN THE ATMEL TERMS AND CONDITIONS OF SALES LOCATED ON THE ATMEL
WEBSITE, ATMEL ASSUMES NO LIABILITY WHATSOEVER AND DISCLAIMS ANY EXPRESS, IMPLIED OR STATUTORY WARRANTY RELATING TO ITS PRODUCTS INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. IN NO EVENT SHALL ATMEL BE LIABLE FOR ANY
DIRECT, INDIRECT, CONSEQUENTIAL, PUNITIVE, SPECIAL OR INCIDENTAL DAMAGES (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS AND PROFITS, BUSINESS
INTERRUPTION, OR LOSS OF INFORMATION) ARISING OUT OF THE USE OR INABILITY TO USE THIS DOCUMENT, EVEN IF ATMEL HAS BEEN ADVISED OF THE POSSIBILITY OF
SUCH DAMAGES. Atmel makes no representations or warranties with respect to the accuracy or completeness of the contents of this document and reserves the right to make changes to
specifications and products descriptions at any time without notice. Atmel does not make any commitment to update the information contained herein. Unless specifically provided otherwise,
Atmel products are not suitable for, and shall not be used in, automotive applications. Atmel products are not intended, authorized, or warranted for use as components in applications intended
to support or sustain life.
SAFETY-CRITICAL, MILITARY, AND AUTOMOTIVE APPLICATIONS DISCLAIMER: Atmel products are not designed for and will not be used in connection with any applications where the failure
of such products would reasonably be expected to result in significant personal injury or death (“Safety-Critical Applications”) without an Atmel officer's specific written consent. Safety-Critical
Applications include, without limitation, life support devices and systems, equipment or systems for the operation of nuclear facilities and weapons systems. Atmel products are not designed nor
intended for use in military or aerospace applications or environments unless specifically designated by Atmel as military-grade. Atmel products are not designed nor intended for use in
automotive applications unless specifically designated by Atmel as automotive-grade.
Features
• High-performance, Low-power 32-bit Atmel® AVR® Microcontroller
– Compact Single-cycle RISC Instruction Set Including DSP Instructions
– Read-modify-write Instructions and Atomic Bit Manipulation
– Performance
• Up to 64DMIPS Running at 50MHz from Flash (1 Flash Wait State)
• Up to 36DMIPS Running at 25MHz from Flash (0 Flash Wait State)
– Memory Protection Unit (MPU)
• Secure Access Unit (SAU) providing User-defined Peripheral Protection
• picoPower® Technology for Ultra-low Power Consumption
• Multi-hierarchy Bus System
– High-performance Data Transfers on Separate Buses for Increased Performance
– 12 Peripheral DMA Channels improve Speed for Peripheral Communication
• Internal High-speed Flash
– 256Kbytes, 128Kbytes, and 64Kbytes Versions
– Single-cycle Access up to 25MHz
– FlashVault Technology Allows Pre-programmed Secure Library Support for End
User Applications
– Prefetch Buffer Optimizing Instruction Execution at Maximum Speed
– 100,000 Write Cycles, 15-year Data Retention Capability
– Flash Security Locks and User-defined Configuration Area
• Internal High-speed SRAM, Single-cycle Access at Full Speed
– 32Kbytes (256Kbytes and 128Kbytes Flash) and 16Kbytes (64Kbytes Flash)
• Interrupt Controller (INTC)
– Autovectored Low-latency Interrupt Service with Programmable Priority
• External Interrupt Controller (EIC)
• Peripheral Event System for Direct Peripheral to Peripheral Communication
• System Functions
– Power and Clock Manager
– SleepWalking Power Saving Control
– Internal System RC Oscillator (RCSYS)
– 32 KHz Oscillator
– Multipurpose Oscillator, Phase Locked Loop (PLL), and Digital Frequency Locked
Loop (DFLL)
• Windowed Watchdog Timer (WDT)
• Asynchronous Timer (AST) with Real-time Clock Capability
– Counter or Calendar Mode Supported
• Frequency Meter (FREQM) for Accurate Measuring of Clock Frequency
• Universal Serial Bus (USBC)
– Full Speed and Low Speed USB Device Support
– Multi-packet Ping-pong Mode
• Six 16-bit Timer/Counter (TC) Channels
– External Clock Inputs, PWM, Capture, and Various Counting Capabilities
• 36 PWM Channels (PWMA)
– 12-bit PWM with a Source Clock up to 150MHz
• Four Universal Synchronous/Asynchronous Receiver/Transmitters (USART)
– Independent Baudrate Generator, Support for SPI
– Support for Hardware Handshaking
32142D–06/2013
32-bit Atmel
AVR
Microcontroller
ATUC256L3U
ATUC128L3U
ATUC64L3U
ATUC256L4U
ATUC128L4U
ATUC64L4U
2
32142D–06/2013
ATUC64/128/256L3/4U
• One Master/Slave Serial Peripheral Interface (SPI) with Chip Select Signals
– Up to 15 SPI Slaves can be Addressed
• Two Master and Two Slave Two-wire Interfaces (TWI), 400kbit/s I2
C-compatible
• One 8-channel Analog-to-digital Converter (ADC) with up to 12 Bits Resolution
– Internal Temperature Sensor
• Eight Analog Comparators (AC) with Optional Window Detection
• Capacitive Touch (CAT) Module
– Hardware-assisted Atmel® AVR® QTouch® and Atmel® AVR® QMatrix Touch Acquisition
– Supports QTouch and QMatrix Capture from Capacitive Touch Sensors
• QTouch Library Support
– Capacitive Touch Buttons, Sliders, and Wheels
– QTouch and QMatrix Acquisition
• Audio Bitstream DAC (ABDACB) Suitable for Stereo Audio
• Inter-IC Sound (IISC) Controller
– Compliant with Inter-IC Sound (I2
S) Specification
• On-chip Non-intrusive Debug System
– Nexus Class 2+, Runtime Control, Non-intrusive Data and Program Trace
– aWire Single-pin Programming Trace and Debug Interface, Muxed with Reset Pin
– NanoTrace Provides Trace Capabilities through JTAG or aWire Interface
• 64-pin TQFP/QFN (51 GPIO Pins), 48-pin TQFP/QFN/TLLGA (36 GPIO Pins)
• Six High-drive I/O Pins (64-pin Packages), Four High-drive I/O Pins (48-pin Packages)
• Single 1.62-3.6V Power Supply
3
32142D–06/2013
ATUC64/128/256L3/4U
1. Description
The Atmel® AVR® ATUC64/128/256L3/4U is a complete system-on-chip microcontroller based
on the AVR32 UC RISC processor running at frequencies up to 50MHz. AVR32 UC is a highperformance
32-bit RISC microprocessor core, designed for cost-sensitive embedded applications,
with particular emphasis on low power consumption, high code density, and high
performance.
The processor implements a Memory Protection Unit (MPU) and a fast and flexible interrupt controller
for supporting modern and real-time operating systems. The Secure Access Unit (SAU) is
used together with the MPU to provide the required security and integrity.
Higher computation capability is achieved using a rich set of DSP instructions.
The ATUC64/128/256L3/4U embeds state-of-the-art picoPower technology for ultra-low power
consumption. Combined power control techniques are used to bring active current consumption
down to 174µA/MHz, and leakage down to 220nA while still retaining a bank of backup registers.
The device allows a wide range of trade-offs between functionality and power consumption,
giving the user the ability to reach the lowest possible power consumption with the feature set
required for the application.
The Peripheral Direct Memory Access (DMA) controller enables data transfers between peripherals
and memories without processor involvement. The Peripheral DMA controller drastically
reduces processing overhead when transferring continuous and large data streams.
The ATUC64/128/256L3/4U incorporates on-chip Flash and SRAM memories for secure and
fast access. The FlashVault technology allows secure libraries to be programmed into the
device. The secure libraries can be executed while the CPU is in Secure State, but not read by
non-secure software in the device. The device can thus be shipped to end customers, who will
be able to program their own code into the device to access the secure libraries, but without risk
of compromising the proprietary secure code.
The External Interrupt Controller (EIC) allows pins to be configured as external interrupts. Each
external interrupt has its own interrupt request and can be individually masked.
The Peripheral Event System allows peripherals to receive, react to, and send peripheral events
without CPU intervention. Asynchronous interrupts allow advanced peripheral operation in low
power sleep modes.
The Power Manager (PM) improves design flexibility and security. The Power Manager supports
SleepWalking functionality, by which a module can be selectively activated based on peripheral
events, even in sleep modes where the module clock is stopped. Power monitoring is supported
by on-chip Power-on Reset (POR), Brown-out Detector (BOD), and Supply Monitor (SM). The
device features several oscillators, such as Phase Locked Loop (PLL), Digital Frequency
Locked Loop (DFLL), Oscillator 0 (OSC0), and system RC oscillator (RCSYS). Either of these
oscillators can be used as source for the system clock. The DFLL is a programmable internal
oscillator from 20 to 150MHz. It can be tuned to a high accuracy if an accurate reference clock is
running, e.g. the 32KHz crystal oscillator.
The Watchdog Timer (WDT) will reset the device unless it is periodically serviced by the software.
This allows the device to recover from a condition that has caused the system to be
unstable.
The Asynchronous Timer (AST) combined with the 32KHz crystal oscillator supports powerful
real-time clock capabilities, with a maximum timeout of up to 136 years. The AST can operate in
counter or calendar mode.
4
32142D–06/2013
ATUC64/128/256L3/4U
The Frequency Meter (FREQM) allows accurate measuring of a clock frequency by comparing it
to a known reference clock.
The Full-speed USB 2.0 device interface (USBC) supports several USB classes at the same
time, thanks to the rich end-point configuration.
The device includes six identical 16-bit Timer/Counter (TC) channels. Each channel can be independently
programmed to perform frequency measurement, event counting, interval
measurement, pulse generation, delay timing, and pulse width modulation.
The Pulse Width Modulation controller (PWMA) provides 12-bit PWM channels which can be
synchronized and controlled from a common timer. 36 PWM channels are available, enabling
applications that require multiple PWM outputs, such as LCD backlight control. The PWM channels
can operate independently, with duty cycles set individually, or in interlinked mode, with
multiple channels changed at the same time.
The ATUC64/128/256L3/4U also features many communication interfaces, like USART, SPI,
and TWI, for communication intensive applications. The USART supports different communication
modes, like SPI Mode and LIN Mode.
A general purpose 8-channel ADC is provided, as well as eight analog comparators (AC). The
ADC can operate in 10-bit mode at full speed or in enhanced mode at reduced speed, offering
up to 12-bit resolution. The ADC also provides an internal temperature sensor input channel.
The analog comparators can be paired to detect when the sensing voltage is within or outside
the defined reference window.
The Capacitive Touch (CAT) module senses touch on external capacitive touch sensors, using
the QTouch technology. Capacitive touch sensors use no external mechanical components,
unlike normal push buttons, and therefore demand less maintenance in the user application.
The CAT module allows up to 17 touch sensors, or up to 16 by 8 matrix sensors to be interfaced.
All touch sensors can be configured to operate autonomously without software interaction,
allowing wakeup from sleep modes when activated.
Atmel offers the QTouch library for embedding capacitive touch buttons, sliders, and wheels
functionality into AVR microcontrollers. The patented charge-transfer signal acquisition offers
robust sensing and includes fully debounced reporting of touch keys as well as Adjacent Key
Suppression® (AKS®) technology for unambiguous detection of key events. The easy-to-use
QTouch Suite toolchain allows you to explore, develop, and debug your own touch applications.
The Audio Bitstream DAC (ABDACB) converts a 16-bit sample value to a digital bitstream with
an average value proportional to the sample value. Two channels are supported, making the
ABDAC particularly suitable for stereo audio.
The Inter-IC Sound Controller (IISC) provides a 5-bit wide, bidirectional, synchronous, digital
audio link with external audio devices. The controller is compliant with the Inter-IC Sound (I2S)
bus specification.
The ATUC64/128/256L3/4U integrates a class 2+ Nexus 2.0 On-chip Debug (OCD) System,
with non-intrusive real-time trace and full-speed read/write memory access, in addition to basic
runtime control. The NanoTrace interface enables trace feature for aWire- or JTAG-based
debuggers. The single-pin aWire interface allows all features available through the JTAG interface
to be accessed through the RESET pin, allowing the JTAG pins to be used for GPIO or
peripherals.
5
32142D–06/2013
ATUC64/128/256L3/4U
2. Overview
2.1 Block Diagram
Figure 2-1. Block Diagram
INTERRUPT
CONTROLLER
ASYNCHRONOUS
TIMER
PERIPHERAL
DMA
CONTROLLER
HSB-PB
BRIDGE B
HSB-PB
BRIDGE A
S
MM M
S
S
M
EXTERNAL INTERRUPT
CONTROLLER
HIGH SPEED
BUS MATRIX
GENERALPURPOSE I/Os
GENERAL PURPOSE I/Os
PA
PB
EXTINT[5..1]
NMI
PA
PB
SPI
DMA
MISO, MOSI
NPCS[3..0]
USART0
USART1
USART2
USART3
DMA
RXD
TXD
CLK
RTS, CTS
WATCHDOG
TIMER
SCK
JTAG
INTERFACE
MCKO
MDO[5..0]
MSEO[1..0]
EVTI_N
TDO
TDI
TMS
CONFIGURATION REGISTERS BUS
256/128/64
KB S FLASH
FLASH
CONTROLLER
EVTO_N
AVR32UC CPU
NEXUS
CLASS 2+
OCD
INSTR
INTERFACE
DATA
INTERFACE
MEMORY INTERFACE
LOCAL BUS
32/16 KB
SRAM
MEMORY PROTECTION UNIT
LOCAL BUS
INTERFACE
FREQUENCY METER
PWMA[35..0] PWM CONTROLLER
TWI MASTER 0
DMA
TWI MASTER 1
TWI SLAVE 0
DMA
TWI SLAVE 1
8-CHANNEL ADC
DMA
INTERFACE
POWER MANAGER
RESET
CONTROLLER
SLEEP
CONTROLLER
CLOCK
CONTROLLER
TCK
RESET_N aWire
CAPACITIVE TOUCH
DMA
MODULE
AC INTERFACE
ACREFN
ACAN[3..0]
ACBN[3..0]
ACBP[3..0]
ACAP[3..0]
TWCK
TWD
TWALM
TWCK
TWD
TWALM
GLUE LOGIC
CONTROLLER IN[7..0]
OUT[1..0]
USB 2.0
Interface 8EP
DMA
INTER-IC SOUND
CONTROLLER
TIMER/COUNTER 0
TIMER/COUNTER 1
A[2..0]
B[2..0]
AUDIO BITSTREAM
DMA
DAC DAC0, DAC1
DACN0, DACN1
ISCK
IWS
ISDI
ISDO
IMCK
CLK
SAU S/M
S
DM
DP
SYSTEM CONTROL
INTERFACE
GCLK[9..0]
XIN32
XOUT32 OSC32K
RCSYS
XIN0
XOUT0 OSC0
DFLL
RC32K
RC120M
RC32OUT
PLL
GCLK_IN[2..0]
CSB[16:0]
SMP
CSA[16:0]
SYNC
VDIVEN
DIS
TRIGGER
ADP[1..0]
AD[8..0]
DATAOUT
ADVREFP
CLK[2..0]
6
32142D–06/2013
ATUC64/128/256L3/4U
2.2 Configuration Summary
Table 2-1. Configuration Summary
Feature ATUC256L3U ATUC128L3U ATUC64L3U ATUC256L4U ATUC128L4U ATUC64L4U
Flash 256KB 128KB 64KB 256KB 128KB 64KB
SRAM 32KB 16KB 32KB 16KB
GPIO 51 36
High-drive pins 6 4
External Interrupts 6
TWI 2
USART 4
Peripheral DMA Channels 12
Peripheral Event System 1
SPI 1
Asynchronous Timers 1
Timer/Counter Channels 6
PWM channels 36
Frequency Meter 1
Watchdog Timer 1
Power Manager 1
Secure Access Unit 1
Glue Logic Controller 1
Oscillators
Digital Frequency Locked Loop 20-150MHz (DFLL)
Phase Locked Loop 40-240MHz (PLL)
Crystal Oscillator 0.45-16MHz (OSC0)
Crystal Oscillator 32KHz (OSC32K)
RC Oscillator 120MHz (RC120M)
RC Oscillator 115kHz (RCSYS)
RC Oscillator 32kHz (RC32K)
ADC 8-channel 12-bit
Temperature Sensor 1
Analog Comparators 8
Capacitive Touch Module 1
JTAG 1
aWire 1
USB 1
Audio Bitstream DAC 1 0
IIS Controller 1 0
Max Frequency 50MHz
Packages TQFP64/QFN64 TQFP48/QFN48/TLLGA48
7
32142D–06/2013
ATUC64/128/256L3/4U
3. Package and Pinout
3.1 Package
The device pins are multiplexed with peripheral functions as described in Section .
Figure 3-1. ATUC64/128/256L4U TQFP48/QFN48 Pinout GND 1 PA09
2
PA08
3
PA03
4
PB12
5
PB00
6
PB02
7
PB03
8
PA22
9
PA06 10
PA00 11
PA05 12
13 PA02
14 PA01
15 PB13
16 PB14
17 VDDIN
18 VDDCORE
19 GND
20 PB05
21 PB04
22 RESET_N
23 PB10
24 PA21
PA14 36
VDDANA 35
ADVREFP 34
GNDANA 33
PB08 32
PB07 31
PB06 30
PB09 29
PA04 28
PA11 27
PA13 26
PA20 25
PA15 37
PA16 38
PA17 39
PA19 40
PA18 41
VDDIO 42
GND 43
PB11 44
GND 45
PA10 46
PA12 47
VDDIO 48
8
32142D–06/2013
ATUC64/128/256L3/4U
Figure 3-2. ATUC64/128/256L4U TLLGA48 Pinout GND 1 PA09
2
PA08
3
PA03
4
PB12
5
PB00
6
PB02
7
PB03
8
PA22
9
PA06 10
PA00 11
PA05 12
PA02 13
14 PA01
15 PB13
16 PB14
17 VDDIN
18 VDDCORE
19 GND
20 PB05
21 PB04
22 RESET_N
23 PB10
24 PA21
PA14 36
VDDANA 35
ADVREFP 34
GNDANA 33
PB08 32
PB07 31
PB06 30
PB09 29
PA04 28
PA11 27
PA13 26
PA20 25
PA15 37
PA16 38
PA17 39
PA19 40
PA18 41
VDDIO 42
GND 43
PB11 44
GND 45
PA10 46
PA12 47
VDDIO 48
9
32142D–06/2013
ATUC64/128/256L3/4U
Figure 3-3. ATUC64/128/256L3U TQFP64/QFN64 Pinout GND 1 PA09
2
PA08
3
PB19
4
PB20
5
PA03
6
PB12
7
PB00
8
PB02
9
PB03 10
VDDIO 11
GND 12
PA22 13
PA06 14
PA00 15
PA05 16
17 PA02
18 PA01
19 PA07
20 PB01
21 PB26
22 PB13
23 PB14
24 PB27
PB08 44
PB07 43
PB06 42
PB22 41
PB21 40
PB09 39
PA04 38
VDDIO 37
GND 36
PA11 35
PA13 34
PA20 33
PA15 49
PA16 50
PA17 51
PA19 52
PA18 53
PB23 54
PB24 55
PB11 56
PB15 57
PB16 58
PB17 59
PB18 60
25 VDDIN
26
27 GND
28 PB05
29 PB04
30
31 PB10
32 PA21
PA14 48
VDDANA 47
ADVREFP 46
GNDANA 45
PB25 61
PA10 62
PA12 63
VDDIO 64
VDDCORE
RESET_N
10
32142D–06/2013
ATUC64/128/256L3/4U
Peripheral Multiplexing on I/O lines
3.1.1 Multiplexed Signals
Each GPIO line can be assigned to one of the peripheral functions. The following table
describes the peripheral signals multiplexed to the GPIO lines.
Table 3-1. GPIO Controller Function Multiplexing
48-
pin
64-
pin
Pin
Name
G
PI
O Supply
Pad
Type
GPIO Function
ABCDE F GH
11 15 PA00 0 VDDIO Normal
I/O
USART0-
TXD
USART1-
RTS
SPINPCS[2]
PWMAPWMA[0]
SCIFGCLK[0]
CATCSA[2]
14 18 PA01 1 VDDIO Normal
I/O
USART0-
RXD
USART1-
CTS
SPINPCS[3]
USART1-
CLK
PWMAPWMA[1]
ACIFBACAP[0]
TWIMS0-
TWALM
CATCSA[1]
13 17 PA02 2 VDDIO Highdrive
I/O
USART0-
RTS
ADCIFBTRIGGER
USART2-
TXD TC0-A0 PWMAPWMA[2]
ACIFBACBP[0]
USART0-
CLK
CATCSA[3]
4 6 PA03 3 VDDIO Normal
I/O
USART0-
CTS
SPINPCS[1]
USART2-
TXD TC0-B0 PWMAPWMA[3]
ACIFBACBN[3]
USART0-
CLK
CATCSB[3]
28 38 PA04 4 VDDIO Normal
I/O SPI-MISO TWIMS0-
TWCK
USART1-
RXD TC0-B1 PWMAPWMA[4]
ACIFBACBP[1]
CATCSA[7]
12 16 PA05 5 VDDIO Normal
I/O (TWI) SPI-MOSI TWIMS1-
TWCK
USART1-
TXD TC0-A1 PWMAPWMA[5]
ACIFBACBN[0]
TWIMS0-
TWD
CATCSB[7]
10 14 PA06 6 VDDIO
Highdrive
I/O,
5V
tolerant
SPI-SCK USART2-
TXD
USART1-
CLK TC0-B0 PWMAPWMA[6]
EICEXTINT[2]
SCIFGCLK[1]
CATCSB[1]
19 PA07 7 VDDIO Normal
I/O (TWI)
SPINPCS[0]
USART2-
RXD
TWIMS1-
TWALM
TWIMS0-
TWCK
PWMAPWMA[7]
ACIFBACAN[0]
EICNMI
(EXTINT[0])
CATCSB[2]
3 3 PA08 8 VDDIO Highdrive
I/O
USART1-
TXD
SPINPCS[2]
TC0-A2 ADCIFBADP[0]
PWMAPWMA[8]
CATCSA[4]
2 2 PA09 9 VDDIO Highdrive
I/O
USART1-
RXD
SPINPCS[3]
TC0-B2 ADCIFBADP[1]
PWMAPWMA[9]
SCIFGCLK[2]
EICEXTINT[1]
CATCSB[4]
46 62 PA10 10 VDDIO Normal
I/O
TWIMS0-
TWD TC0-A0 PWMAPWMA[10]
ACIFBACAP[1]
SCIFGCLK[2]
CATCSA[5]
27 35 PA11 11 VDDIN Normal
I/O
PWMAPWMA[11]
47 63 PA12 12 VDDIO Normal
I/O
USART2-
CLK TC0-CLK1 CAT-SMP PWMAPWMA[12]
ACIFBACAN[1]
SCIFGCLK[3]
CATCSB[5]
26 34 PA13 13 VDDIN Normal
I/O
GLOCOUT[0]
GLOCIN[7]
TC0-A0 SCIFGCLK[2]
PWMAPWMA[13]
CAT-SMP EICEXTINT[2]
CATCSA[0]
36 48 PA14 14 VDDIO Normal
I/O
ADCIFBAD[0]
TC0-CLK2 USART2-
RTS CAT-SMP PWMAPWMA[14]
SCIFGCLK[4]
CATCSA[6]
37 49 PA15 15 VDDIO Normal
I/O
ADCIFBAD[1]
TC0-CLK1 GLOCIN[6]
PWMAPWMA[15]
CATSYNC
EICEXTINT[3]
CATCSB[6]
38 50 PA16 16 VDDIO Normal
I/O
ADCIFBAD[2]
TC0-CLK0 GLOCIN[5]
PWMAPWMA[16]
ACIFBACREFN
EICEXTINT[4]
CATCSA[8]
11
32142D–06/2013
ATUC64/128/256L3/4U
39 51 PA17 17 VDDIO Normal
I/O (TWI) TC0-A1 USART2-
CTS
TWIMS1-
TWD
PWMAPWMA[17]
CAT-SMP CAT-DIS CATCSB[8]
41 53 PA18 18 VDDIO Normal
I/O
ADCIFBAD[4]
TC0-B1 GLOCIN[4]
PWMAPWMA[18]
CATSYNC
EICEXTINT[5]
CATCSB[0]
40 52 PA19 19 VDDIO Normal
I/O
ADCIFBAD[5]
TC0-A2 TWIMS1-
TWALM
PWMAPWMA[19]
SCIFGCLK_IN[
0]
CAT-SYNC CATCSA[10]
25 33 PA20 20 VDDIN Normal
I/O
USART2-
TXD TC0-A1 GLOCIN[3]
PWMAPWMA[20]
SCIFRC32OUT
CATCSA[12]
24 32 PA21 21 VDDIN
Normal
I/O (TWI,
5V
tolerant,
SMBus)
USART2-
RXD
TWIMS0-
TWD TC0-B1 ADCIFBTRIGGER
PWMAPWMA[21]
PWMAPWMAOD
[21]
SCIFGCLK[0]
CATSMP
9 13 PA22 22 VDDIO Normal
I/O
USART0-
CTS
USART2-
CLK TC0-B2 CAT-SMP PWMAPWMA[22]
ACIFBACBN[2]
CATCSB[10]
6 8 PB00 32 VDDIO Normal
I/O
USART3-
TXD
ADCIFBADP[0]
SPINPCS[0]
TC0-A1 PWMAPWMA[23]
ACIFBACAP[2]
TC1-A0 CATCSA[9]
20 PB01 33 VDDIO Highdrive
I/O
USART3-
RXD
ADCIFBADP[1]
SPI-SCK TC0-B1 PWMAPWMA[24]
TC1-A1 CATCSB[9]
7 9 PB02 34 VDDIO Normal
I/O
USART3-
RTS
USART3-
CLK SPI-MISO TC0-A2 PWMAPWMA[25]
ACIFBACAN[2]
SCIFGCLK[1]
CATCSB[11]
8 10 PB03 35 VDDIO Normal
I/O
USART3-
CTS
USART3-
CLK SPI-MOSI TC0-B2 PWMAPWMA[26]
ACIFBACBP[2]
TC1-A2 CATCSA[11]
21 29 PB04 36 VDDIN
Normal
I/O (TWI,
5V
tolerant,
SMBus)
TC1-A0 USART1-
RTS
USART1-
CLK
TWIMS0-
TWALM
PWMAPWMA[27]
PWMAPWMAOD
[27]
TWIMS1-
TWCK
CATCSA[14]
20 28 PB05 37 VDDIN
Normal
I/O (TWI,
5V
tolerant,
SMBus)
TC1-B0 USART1-
CTS
USART1-
CLK
TWIMS0-
TWCK
PWMAPWMA[28]
PWMAPWMAOD
[28]
SCIFGCLK[3]
CATCSB[14]
30 42 PB06 38 VDDIO Normal
I/O TC1-A1 USART3-
TXD
ADCIFBAD[6]
GLOCIN[2]
PWMAPWMA[29]
ACIFBACAN[3]
EICNMI
(EXTINT[0])
CATCSB[13]
31 43 PB07 39 VDDIO Normal
I/O TC1-B1 USART3-
RXD
ADCIFBAD[7]
GLOCIN[1]
PWMAPWMA[30]
ACIFBACAP[3]
EICEXTINT[1]
CATCSA[13]
32 44 PB08 40 VDDIO Normal
I/O TC1-A2 USART3-
RTS
ADCIFBAD[8]
GLOCIN[0]
PWMAPWMA[31]
CATSYNC
EICEXTINT[2]
CATCSB[12]
29 39 PB09 41 VDDIO Normal
I/O TC1-B2 USART3-
CTS
USART3-
CLK
PWMAPWMA[32]
ACIFBACBN[1]
EICEXTINT[3]
CATCSB[15]
23 31 PB10 42 VDDIN Normal
I/O TC1-CLK0 USART1-
TXD
USART3-
CLK
GLOCOUT[1]
PWMAPWMA[33]
SCIFGCLK_IN[
1]
EICEXTINT[4]
CATCSB[16]
44 56 PB11 43 VDDIO Normal
I/O TC1-CLK1 USART1-
RXD
ADCIFBTRIGGER
PWMAPWMA[34]
CATVDIVEN
EICEXTINT[5]
CATCSA[16]
5 7 PB12 44 VDDIO Normal
I/O TC1-CLK2 TWIMS1-
TWALM
CATSYNC
PWMAPWMA[35]
ACIFBACBP[3]
SCIFGCLK[4]
CATCSA[15]
15 22 PB13 45 VDDIN USB I/O USBC-DM USART3-
TXD TC1-A1 PWMAPWMA[7]
ADCIFBADP[1]
SCIFGCLK[5]
CATCSB[2]
16 23 PB14 46 VDDIN USB I/O USBC-DP USART3-
RXD TC1-B1 PWMAPWMA[24]
SCIFGCLK[5]
CATCSB[9]
Table 3-1. GPIO Controller Function Multiplexing
12
32142D–06/2013
ATUC64/128/256L3/4U
3.2 See Section 3.3 for a description of the various peripheral signals.
Refer to ”Electrical Characteristics” on page 897 for a description of the electrical properties of
the pin types used.
3.2.1 TWI, 5V Tolerant, and SMBUS Pins
Some normal I/O pins offer TWI, 5V tolerance, and SMBUS features. These features are only
available when either of the TWI functions or the PWMAOD function in the PWMA are selected
for these pins.
Refer to the ”Electrical Characteristics” on page 897 for a description of the electrical properties
of the TWI, 5V tolerance, and SMBUS pins.
57 PB15 47 VDDIO Highdrive
I/O
ABDACBCLK
IISCIMCK
SPI-SCK TC0-CLK2 PWMAPWMA[8]
SCIFGCLK[3]
CATCSB[4]
58 PB16 48 VDDIO Normal
I/O
ABDACBDAC[0]
IISC-ISCK USART0-
TXD
PWMAPWMA[9]
SCIFGCLK[2]
CATCSA[5]
59 PB17 49 VDDIO Normal
I/O
ABDACBDAC[1]
IISC-IWS USART0-
RXD
PWMAPWMA[10]
CATCSB[5]
60 PB18 50 VDDIO Normal
I/O
ABDACBDACN[0]
IISC-ISDI USART0-
RTS
PWMAPWMA[12]
CATCSA[0]
4 PB19 51 VDDIO Normal
I/O
ABDACBDACN[1]
IISC-ISDO USART0-
CTS
PWMAPWMA[20]
EICEXTINT[1]
CATCSA[12]
5 PB20 52 VDDIO Normal
I/O
TWIMS1-
TWD
USART2-
RXD
SPINPCS[1]
TC0-A0 PWMAPWMA[21]
USART1-
RTS
USART1-
CLK
CATCSA[14]
40 PB21 53 VDDIO Normal
I/O
TWIMS1-
TWCK
USART2-
TXD
SPINPCS[2]
TC0-B0 PWMAPWMA[28]
USART1-
CTS
USART1-
CLK
CATCSB[14]
41 PB22 54 VDDIO Normal
I/O
TWIMS1-
TWALM
SPINPCS[3]
TC0-CLK0 PWMAPWMA[27]
ADCIFBTRIGGER
SCIFGCLK[0]
CATCSA[8]
54 PB23 55 VDDIO Normal
I/O SPI-MISO USART2-
RTS
USART2-
CLK TC0-A2 PWMAPWMA[0]
CAT-SMP SCIFGCLK[6]
CATCSA[4]
55 PB24 56 VDDIO Normal
I/O SPI-MOSI USART2-
CTS
USART2-
CLK TC0-B2 PWMAPWMA[1]
ADCIFBADP[1]
SCIFGCLK[7]
CATCSA[2]
61 PB25 57 VDDIO Normal
I/O
SPINPCS[0]
USART1-
RXD TC0-A1 PWMAPWMA[2]
SCIFGCLK_IN[
2]
SCIFGCLK[8]
CATCSA[3]
21 PB26 58 VDDIO Normal
I/O SPI-SCK USART1-
TXD TC0-B1 PWMAPWMA[3]
ADCIFBADP[0]
SCIFGCLK[9]
CATCSB[3]
24 PB27 59 VDDIN Normal
I/O
USART1-
RXD TC0-CLK1 PWMAPWMA[4]
ADCIFBADP[1]
EICNMI
(EXTINT[0])
CATCSA[9]
Table 3-1. GPIO Controller Function Multiplexing
13
32142D–06/2013
ATUC64/128/256L3/4U
3.2.2 Peripheral Functions
Each GPIO line can be assigned to one of several peripheral functions. The following table
describes how the various peripheral functions are selected. The last listed function has priority
in case multiple functions are enabled on the same pin.
3.2.3 JTAG Port Connections
If the JTAG is enabled, the JTAG will take control over a number of pins, irrespectively of the I/O
Controller configuration.
3.2.4 Nexus OCD AUX Port Connections
If the OCD trace system is enabled, the trace system will take control over a number of pins, irrespectively
of the I/O Controller configuration. Two different OCD trace pin mappings are
possible, depending on the configuration of the OCD AXS register. For details, see the AVR32
UC Technical Reference Manual.
Table 3-2. Peripheral Functions
Function Description
GPIO Controller Function multiplexing GPIO and GPIO peripheral selection A to H
Nexus OCD AUX port connections OCD trace system
aWire DATAOUT aWire output in two-pin mode
JTAG port connections JTAG debug port
Oscillators OSC0, OSC32
Table 3-3. JTAG Pinout
48-pin 64-pin Pin name JTAG pin
11 15 PA00 TCK
14 18 PA01 TMS
13 17 PA02 TDO
4 6 PA03 TDI
Table 3-4. Nexus OCD AUX Port Connections
Pin AXS=1 AXS=0
EVTI_N PA05 PB08
MDO[5] PA10 PB00
MDO[4] PA18 PB04
MDO[3] PA17 PB05
MDO[2] PA16 PB03
MDO[1] PA15 PB02
MDO[0] PA14 PB09
14
32142D–06/2013
ATUC64/128/256L3/4U
3.2.5 Oscillator Pinout
The oscillators are not mapped to the normal GPIO functions and their muxings are controlled
by registers in the System Control Interface (SCIF). Please refer to the SCIF chapter for more
information about this.
3.2.6 Other Functions
The functions listed in Table 3-6 are not mapped to the normal GPIO functions. The aWire DATA
pin will only be active after the aWire is enabled. The aWire DATAOUT pin will only be active
after the aWire is enabled and the 2_PIN_MODE command has been sent. The WAKE_N pin is
always enabled. Please refer to Section 6.1.4.2 on page 44 for constraints on the WAKE_N pin.
EVTO_N PA04 PA04
MCKO PA06 PB01
MSEO[1] PA07 PB11
MSEO[0] PA11 PB12
Table 3-4. Nexus OCD AUX Port Connections
Pin AXS=1 AXS=0
Table 3-5. Oscillator Pinout
48-pin 64-pin Pin Name Oscillator Pin
3 3 PA08 XIN0
46 62 PA10 XIN32
26 34 PA13 XIN32_2
2 2 PA09 XOUT0
47 63 PA12 XOUT32
25 33 PA20 XOUT32_2
Table 3-6. Other Functions
48-pin 64-pin Pin Name Function
27 35 PA11 WAKE_N
22 30 RESET_N aWire DATA
11 15 PA00 aWire DATAOUT
15
32142D–06/2013
ATUC64/128/256L3/4U
3.3 Signal Descriptions
The following table gives details on signal name classified by peripheral.
Table 3-7. Signal Descriptions List
Signal Name Function Type
Active
Level Comments
Audio Bitstream DAC - ABDACB
CLK D/A Clock out Output
DAC1 - DAC0 D/A Bitstream out Output
DACN1 - DACN0 D/A Inverted bitstream out Output
Analog Comparator Interface - ACIFB
ACAN3 - ACAN0 Negative inputs for comparators "A" Analog
ACAP3 - ACAP0 Positive inputs for comparators "A" Analog
ACBN3 - ACBN0 Negative inputs for comparators "B" Analog
ACBP3 - ACBP0 Positive inputs for comparators "B" Analog
ACREFN Common negative reference Analog
ADC Interface - ADCIFB
AD8 - AD0 Analog Signal Analog
ADP1 - ADP0 Drive Pin for resistive touch screen Output
TRIGGER External trigger Input
aWire - AW
DATA aWire data I/O
DATAOUT aWire data output for 2-pin mode I/O
Capacitive Touch Module - CAT
CSA16 - CSA0 Capacitive Sense A I/O
CSB16 - CSB0 Capacitive Sense B I/O
DIS Discharge current control Analog
SMP SMP signal Output
SYNC Synchronize signal Input
VDIVEN Voltage divider enable Output
External Interrupt Controller - EIC
NMI (EXTINT0) Non-Maskable Interrupt Input
EXTINT5 - EXTINT1 External interrupt Input
Glue Logic Controller - GLOC
IN7 - IN0 Inputs to lookup tables Input
OUT1 - OUT0 Outputs from lookup tables Output
Inter-IC Sound (I2S) Controller - IISC
16
32142D–06/2013
ATUC64/128/256L3/4U
IMCK I2S Master Clock Output
ISCK I2S Serial Clock I/O
ISDI I2S Serial Data In Input
ISDO I2S Serial Data Out Output
IWS I2S Word Select I/O
JTAG module - JTAG
TCK Test Clock Input
TDI Test Data In Input
TDO Test Data Out Output
TMS Test Mode Select Input
Power Manager - PM
RESET_N Reset Input Low
Pulse Width Modulation Controller - PWMA
PWMA35 - PWMA0 PWMA channel waveforms Output
PWMAOD35 -
PWMAOD0
PWMA channel waveforms, open drain
mode Output Not all channels support open
drain mode
System Control Interface - SCIF
GCLK9 - GCLK0 Generic Clock Output Output
GCLK_IN2 - GCLK_IN0 Generic Clock Input Input
RC32OUT RC32K output at startup Output
XIN0 Crystal 0 Input Analog/
Digital
XIN32 Crystal 32 Input (primary location) Analog/
Digital
XIN32_2 Crystal 32 Input (secondary location) Analog/
Digital
XOUT0 Crystal 0 Output Analog
XOUT32 Crystal 32 Output (primary location) Analog
XOUT32_2 Crystal 32 Output (secondary location) Analog
Serial Peripheral Interface - SPI
MISO Master In Slave Out I/O
MOSI Master Out Slave In I/O
NPCS3 - NPCS0 SPI Peripheral Chip Select I/O Low
SCK Clock I/O
Timer/Counter - TC0, TC1
A0 Channel 0 Line A I/O
A1 Channel 1 Line A I/O
A2 Channel 2 Line A I/O
Table 3-7. Signal Descriptions List
17
32142D–06/2013
ATUC64/128/256L3/4U
Note: 1. ADCIFB: AD3 does not exist.
B0 Channel 0 Line B I/O
B1 Channel 1 Line B I/O
B2 Channel 2 Line B I/O
CLK0 Channel 0 External Clock Input Input
CLK1 Channel 1 External Clock Input Input
CLK2 Channel 2 External Clock Input Input
Two-wire Interface - TWIMS0, TWIMS1
TWALM SMBus SMBALERT I/O Low
TWCK Two-wire Serial Clock I/O
TWD Two-wire Serial Data I/O
Universal Synchronous Asynchronous Receiver Transmitter - USART0, USART1, USART2, USART3
CLK Clock I/O
CTS Clear To Send Input Low
RTS Request To Send Output Low
RXD Receive Data Input
TXD Transmit Data Output
Table 3-7. Signal Descriptions List
Table 3-8. Signal Description List, Continued
Signal Name Function Type
Active
Level Comments
Power
VDDCORE Core Power Supply / Voltage Regulator Output Power
Input/Output 1.62V to 1.98V
VDDIO I/O Power Supply Power Input
1.62V to 3.6V. VDDIO should
always be equal to or lower than
VDDIN.
VDDANA Analog Power Supply Power Input 1.62V to 1.98V
ADVREFP Analog Reference Voltage Power Input 1.62V to 1.98V
VDDIN Voltage Regulator Input Power Input 1.62V to 3.6V(1)
GNDANA Analog Ground Ground
GND Ground Ground
Auxiliary Port - AUX
MCKO Trace Data Output Clock Output
MDO5 - MDO0 Trace Data Output Output
18
32142D–06/2013
ATUC64/128/256L3/4U
Note: 1. See Section 6. on page 39
3.4 I/O Line Considerations
3.4.1 JTAG Pins
The JTAG is enabled if TCK is low while the RESET_N pin is released. The TCK, TMS, and TDI
pins have pull-up resistors when JTAG is enabled. The TCK pin always has pull-up enabled during
reset. The TDO pin is an output, driven at VDDIO, and has no pull-up resistor. The JTAG
pins can be used as GPIO pins and multiplexed with peripherals when the JTAG is disabled.
Please refer to Section 3.2.3 on page 13 for the JTAG port connections.
3.4.2 PA00
Note that PA00 is multiplexed with TCK. PA00 GPIO function must only be used as output in the
application.
3.4.3 RESET_N Pin
The RESET_N pin is a schmitt input and integrates a permanent pull-up resistor to VDDIN. As
the product integrates a power-on reset detector, the RESET_N pin can be left unconnected in
case no reset from the system needs to be applied to the product.
The RESET_N pin is also used for the aWire debug protocol. When the pin is used for debugging,
it must not be driven by external circuitry.
3.4.4 TWI Pins PA21/PB04/PB05
When these pins are used for TWI, the pins are open-drain outputs with slew-rate limitation and
inputs with spike filtering. When used as GPIO pins or used for other peripherals, the pins have
the same characteristics as other GPIO pins. Selected pins are also SMBus compliant (refer to
Section on page 10). As required by the SMBus specification, these pins provide no leakage
path to ground when the ATUC64/128/256L3/4U is powered down. This allows other devices on
the SMBus to continue communicating even though the ATUC64/128/256L3/4U is not powered.
After reset a TWI function is selected on these pins instead of the GPIO. Please refer to the
GPIO Module Configuration chapter for details.
MSEO1 - MSEO0 Trace Frame Control Output
EVTI_N Event In Input Low
EVTO_N Event Out Output Low
General Purpose I/O pin
PA22 - PA00 Parallel I/O Controller I/O Port 0 I/O
PB27 - PB00 Parallel I/O Controller I/O Port 1 I/O
Table 3-8. Signal Description List, Continued
Signal Name Function Type
Active
Level Comments
19
32142D–06/2013
ATUC64/128/256L3/4U
3.4.5 TWI Pins PA05/PA07/PA17
When these pins are used for TWI, the pins are open-drain outputs with slew-rate limitation and
inputs with spike filtering. When used as GPIO pins or used for other peripherals, the pins have
the same characteristics as other GPIO pins.
After reset a TWI function is selected on these pins instead of the GPIO. Please refer to the
GPIO Module Configuration chapter for details.
3.4.6 GPIO Pins
All the I/O lines integrate a pull-up resistor Programming of this pull-up resistor is performed
independently for each I/O line through the GPIO Controllers. After reset, I/O lines default as
inputs with pull-up resistors disabled, except PA00 which has the pull-up resistor enabled. PA20
selects SCIF-RC32OUT (GPIO Function F) as default enabled after reset.
3.4.7 High-drive Pins
The six pins PA02, PA06, PA08, PA09, PB01, and PB15 have high-drive output capabilities.
Refer to Section 35. on page 897 for electrical characteristics.
3.4.8 USB Pins PB13/PB14
When these pins are used for USB, the pins are behaving according to the USB specification.
When used as GPIO pins or used for other peripherals, the pins have the same behaviour as
other normal I/O pins, but the characteristics are different. Refer to Section 35. on page 897 for
electrical characteristics.
To be able to use the USB I/O the VDDIN power supply must be 3.3V nominal.
3.4.9 RC32OUT Pin
3.4.9.1 Clock output at startup
After power-up, the clock generated by the 32kHz RC oscillator (RC32K) will be output on PA20,
even when the device is still reset by the Power-On Reset Circuitry. This clock can be used by
the system to start other devices or to clock a switching regulator to rise the power supply voltage
up to an acceptable value.
The clock will be available on PA20, but will be disabled if one of the following conditions are
true:
• PA20 is configured to use a GPIO function other than F (SCIF-RC32OUT)
• PA20 is configured as a General Purpose Input/Output (GPIO)
• The bit FRC32 in the Power Manager PPCR register is written to zero (refer to the Power
Manager chapter)
The maximum amplitude of the clock signal will be defined by VDDIN.
Once the RC32K output on PA20 is disabled it can never be enabled again.
3.4.9.2 XOUT32_2 function
PA20 selects RC32OUT as default enabled after reset. This function is not automatically disabled
when the user enables the XOUT32_2 function on PA20. This disturbs the oscillator and
may result in the wrong frequency. To avoid this, RC32OUT must be disabled when XOUT32_2
is enabled.
20
32142D–06/2013
ATUC64/128/256L3/4U
3.4.10 ADC Input Pins
These pins are regular I/O pins powered from the VDDIO. However, when these pins are used
for ADC inputs, the voltage applied to the pin must not exceed 1.98V. Internal circuitry ensures
that the pin cannot be used as an analog input pin when the I/O drives to VDD. When the pins
are not used for ADC inputs, the pins may be driven to the full I/O voltage range.
21
32142D–06/2013
ATUC64/128/256L3/4U
4. Processor and Architecture
Rev: 2.1.2.0
This chapter gives an overview of the AVR32UC CPU. AVR32UC is an implementation of the
AVR32 architecture. A summary of the programming model, instruction set, and MPU is presented.
For further details, see the AVR32 Architecture Manual and the AVR32UC Technical
Reference Manual.
4.1 Features
• 32-bit load/store AVR32A RISC architecture
– 15 general-purpose 32-bit registers
– 32-bit Stack Pointer, Program Counter and Link Register reside in register file
– Fully orthogonal instruction set
– Privileged and unprivileged modes enabling efficient and secure operating systems
– Innovative instruction set together with variable instruction length ensuring industry leading
code density
– DSP extension with saturating arithmetic, and a wide variety of multiply instructions
• 3-stage pipeline allowing one instruction per clock cycle for most instructions
– Byte, halfword, word, and double word memory access
– Multiple interrupt priority levels
• MPU allows for operating systems with memory protection
• Secure State for supporting FlashVault technology
4.2 AVR32 Architecture
AVR32 is a new, high-performance 32-bit RISC microprocessor architecture, designed for costsensitive
embedded applications, with particular emphasis on low power consumption and high
code density. In addition, the instruction set architecture has been tuned to allow a variety of
microarchitectures, enabling the AVR32 to be implemented as low-, mid-, or high-performance
processors. AVR32 extends the AVR family into the world of 32- and 64-bit applications.
Through a quantitative approach, a large set of industry recognized benchmarks has been compiled
and analyzed to achieve the best code density in its class. In addition to lowering the
memory requirements, a compact code size also contributes to the core’s low power characteristics.
The processor supports byte and halfword data types without penalty in code size and
performance.
Memory load and store operations are provided for byte, halfword, word, and double word data
with automatic sign- or zero extension of halfword and byte data. The C-compiler is closely
linked to the architecture and is able to exploit code optimization features, both for size and
speed.
In order to reduce code size to a minimum, some instructions have multiple addressing modes.
As an example, instructions with immediates often have a compact format with a smaller immediate,
and an extended format with a larger immediate. In this way, the compiler is able to use
the format giving the smallest code size.
Another feature of the instruction set is that frequently used instructions, like add, have a compact
format with two operands as well as an extended format with three operands. The larger
format increases performance, allowing an addition and a data move in the same instruction in a
22
32142D–06/2013
ATUC64/128/256L3/4U
single cycle. Load and store instructions have several different formats in order to reduce code
size and speed up execution.
The register file is organized as sixteen 32-bit registers and includes the Program Counter, the
Link Register, and the Stack Pointer. In addition, register R12 is designed to hold return values
from function calls and is used implicitly by some instructions.
4.3 The AVR32UC CPU
The AVR32UC CPU targets low- and medium-performance applications, and provides an
advanced On-Chip Debug (OCD) system, no caches, and a Memory Protection Unit (MPU).
Java acceleration hardware is not implemented.
AVR32UC provides three memory interfaces, one High Speed Bus master for instruction fetch,
one High Speed Bus master for data access, and one High Speed Bus slave interface allowing
other bus masters to access data RAMs internal to the CPU. Keeping data RAMs internal to the
CPU allows fast access to the RAMs, reduces latency, and guarantees deterministic timing.
Also, power consumption is reduced by not needing a full High Speed Bus access for memory
accesses. A dedicated data RAM interface is provided for communicating with the internal data
RAMs.
A local bus interface is provided for connecting the CPU to device-specific high-speed systems,
such as floating-point units and I/O controller ports. This local bus has to be enabled by writing a
one to the LOCEN bit in the CPUCR system register. The local bus is able to transfer data
between the CPU and the local bus slave in a single clock cycle. The local bus has a dedicated
memory range allocated to it, and data transfers are performed using regular load and store
instructions. Details on which devices that are mapped into the local bus space is given in the
CPU Local Bus section in the Memories chapter.
Figure 4-1 on page 23 displays the contents of AVR32UC.
23
32142D–06/2013
ATUC64/128/256L3/4U
Figure 4-1. Overview of the AVR32UC CPU
4.3.1 Pipeline Overview
AVR32UC has three pipeline stages, Instruction Fetch (IF), Instruction Decode (ID), and Instruction
Execute (EX). The EX stage is split into three parallel subsections, one arithmetic/logic
(ALU) section, one multiply (MUL) section, and one load/store (LS) section.
Instructions are issued and complete in order. Certain operations require several clock cycles to
complete, and in this case, the instruction resides in the ID and EX stages for the required number
of clock cycles. Since there is only three pipeline stages, no internal data forwarding is
required, and no data dependencies can arise in the pipeline.
Figure 4-2 on page 24 shows an overview of the AVR32UC pipeline stages.
AVR32UC CPU pipeline
Instruction memory controller
MPU
High Speed Bus
High Speed Bus
OCD
systemOCD interface
Interrupt controller interface
High
Speed
Bus slave High Speed Bus
High Speed Bus master
Power/
Reset
control Reset interface
CPU Local
Bus
master CPU Local Bus
Data memory controller
CPU RAM High Speed
Bus master
24
32142D–06/2013
ATUC64/128/256L3/4U
Figure 4-2. The AVR32UC Pipeline
4.3.2 AVR32A Microarchitecture Compliance
AVR32UC implements an AVR32A microarchitecture. The AVR32A microarchitecture is targeted
at cost-sensitive, lower-end applications like smaller microcontrollers. This
microarchitecture does not provide dedicated hardware registers for shadowing of register file
registers in interrupt contexts. Additionally, it does not provide hardware registers for the return
address registers and return status registers. Instead, all this information is stored on the system
stack. This saves chip area at the expense of slower interrupt handling.
4.3.2.1 Interrupt Handling
Upon interrupt initiation, registers R8-R12 are automatically pushed to the system stack. These
registers are pushed regardless of the priority level of the pending interrupt. The return address
and status register are also automatically pushed to stack. The interrupt handler can therefore
use R8-R12 freely. Upon interrupt completion, the old R8-R12 registers and status register are
restored, and execution continues at the return address stored popped from stack.
The stack is also used to store the status register and return address for exceptions and scall.
Executing the rete or rets instruction at the completion of an exception or system call will pop
this status register and continue execution at the popped return address.
4.3.2.2 Java Support
AVR32UC does not provide Java hardware acceleration.
4.3.2.3 Memory Protection
The MPU allows the user to check all memory accesses for privilege violations. If an access is
attempted to an illegal memory address, the access is aborted and an exception is taken. The
MPU in AVR32UC is specified in the AVR32UC Technical Reference manual.
4.3.2.4 Unaligned Reference Handling
AVR32UC does not support unaligned accesses, except for doubleword accesses. AVR32UC is
able to perform word-aligned st.d and ld.d. Any other unaligned memory access will cause an
IF ID ALU
MUL
Regfile
write
Prefetch unit Decode unit
ALU unit
Multiply unit
Load-store
unit LS
Regfile
Read
25
32142D–06/2013
ATUC64/128/256L3/4U
address exception. Doubleword-sized accesses with word-aligned pointers will automatically be
performed as two word-sized accesses.
The following table shows the instructions with support for unaligned addresses. All other
instructions require aligned addresses.
4.3.2.5 Unimplemented Instructions
The following instructions are unimplemented in AVR32UC, and will cause an Unimplemented
Instruction Exception if executed:
• All SIMD instructions
• All coprocessor instructions if no coprocessors are present
• retj, incjosp, popjc, pushjc
• tlbr, tlbs, tlbw
• cache
4.3.2.6 CPU and Architecture Revision
Three major revisions of the AVR32UC CPU currently exist. The device described in this
datasheet uses CPU revision 3.
The Architecture Revision field in the CONFIG0 system register identifies which architecture
revision is implemented in a specific device.
AVR32UC CPU revision 3 is fully backward-compatible with revisions 1 and 2, ie. code compiled
for revision 1 or 2 is binary-compatible with revision 3 CPUs.
Table 4-1. Instructions with Unaligned Reference Support
Instruction Supported Alignment
ld.d Word
st.d Word
26
32142D–06/2013
ATUC64/128/256L3/4U
4.4 Programming Model
4.4.1 Register File Configuration
The AVR32UC register file is shown below.
Figure 4-3. The AVR32UC Register File
4.4.2 Status Register Configuration
The Status Register (SR) is split into two halfwords, one upper and one lower, see Figure 4-4
and Figure 4-5. The lower word contains the C, Z, N, V, and Q condition code flags and the R, T,
and L bits, while the upper halfword contains information about the mode and state the processor
executes in. Refer to the AVR32 Architecture Manual for details.
Figure 4-4. The Status Register High Halfword
Application
Bit 0
Supervisor
Bit 31
PC
SR
INT0PC
FINTPC
INT1PC
SMPC
R7
R5
R6
R4
R3
R1
R2
R0
Bit 31 Bit 0
PC
SR
R12
INT0PC
FINTPC
INT1PC
SMPC
R7
R5
R6
R4
R11
R9
R10
R8
R3
R1
R2
R0
INT0
SP_APP SP_SYS
R12
R11
R9
R10
R8
INT1 INT2 INT3 Exception NMI
LR LR
Bit 31 Bit 0
PC
SR
R12
INT0PC
FINTPC
INT1PC
SMPC
R7
R5
R6
R4
R11
R9
R10
R8
R3
R1
R2
R0
SP_SYS
LR
Bit 31 Bit 0
PC
SR
R12
INT0PC
FINTPC
INT1PC
SMPC
R7
R5
R6
R4
R11
R9
R10
R8
R3
R1
R2
R0
SP_SYS
LR
Bit 31 Bit 0
PC
SR
R12
INT0PC
FINTPC
INT1PC
SMPC
R7
R5
R6
R4
R11
R9
R10
R8
R3
R1
R2
R0
SP_SYS
LR
Bit 31 Bit 0
PC
SR
R12
INT0PC
FINTPC
INT1PC
SMPC
R7
R5
R6
R4
R11
R9
R10
R8
R3
R1
R2
R0
SP_SYS
LR
Bit 31 Bit 0
PC
SR
R12
INT0PC
FINTPC
INT1PC
SMPC
R7
R5
R6
R4
R11
R9
R10
R8
R3
R1
R2
R0
SP_SYS
LR
Bit 31 Bit 0
PC
SR
R12
INT0PC
FINTPC
INT1PC
SMPC
R7
R5
R6
R4
R11
R9
R10
R8
R3
R1
R2
R0
SP_SYS
LR
Secure
Bit 31 Bit 0
PC
SR
R12
INT0PC
FINTPC
INT1PC
SMPC
R7
R5
R6
R4
R11
R9
R10
R8
R3
R1
R2
R0
SP_SEC
LR
SS_STATUS
SS_ADRF
SS_ADRR
SS_ADR0
SS_ADR1
SS_SP_SYS
SS_SP_APP
SS_RAR
SS_RSR
Bit 31
0 0 0
Bit 16
Interrupt Level 0 Mask
Interrupt Level 1 Mask
Interrupt Level 3 Mask
Interrupt Level 2 Mask
0 0 0 0 0 0 1 1 0 0 0 0 1
- DM D - M2 M1 M0 EM I2MFE I0M GM LC
1 SS
Initial value
I1M Bit name
Mode Bit 0
Mode Bit 1
-
Mode Bit 2
Reserved
Debug State
- I3M
Reserved
Exception Mask
Global Interrupt Mask
Debug State Mask
Secure State
27
32142D–06/2013
ATUC64/128/256L3/4U
Figure 4-5. The Status Register Low Halfword
4.4.3 Processor States
4.4.3.1 Normal RISC State
The AVR32 processor supports several different execution contexts as shown in Table 4-2.
Mode changes can be made under software control, or can be caused by external interrupts or
exception processing. A mode can be interrupted by a higher priority mode, but never by one
with lower priority. Nested exceptions can be supported with a minimal software overhead.
When running an operating system on the AVR32, user processes will typically execute in the
application mode. The programs executed in this mode are restricted from executing certain
instructions. Furthermore, most system registers together with the upper halfword of the status
register cannot be accessed. Protected memory areas are also not available. All other operating
modes are privileged and are collectively called System Modes. They have full access to all privileged
and unprivileged resources. After a reset, the processor will be in supervisor mode.
4.4.3.2 Debug State
The AVR32 can be set in a debug state, which allows implementation of software monitor routines
that can read out and alter system information for use during application development. This
implies that all system and application registers, including the status registers and program
counters, are accessible in debug state. The privileged instructions are also available.
All interrupt levels are by default disabled when debug state is entered, but they can individually
be switched on by the monitor routine by clearing the respective mask bit in the status register.
Bit 15 Bit 0
Reserved
Carry
Zero
Sign
0 0 0 0 0 0 0 0 0 0 0 0 0 0
- T - - - - Bit name
0 0 Initial value
- L Q V N Z C
Overflow
Saturation
- - -
Lock
Reserved
Scratch
Table 4-2. Overview of Execution Modes, their Priorities and Privilege Levels.
Priority Mode Security Description
1 Non Maskable Interrupt Privileged Non Maskable high priority interrupt mode
2 Exception Privileged Execute exceptions
3 Interrupt 3 Privileged General purpose interrupt mode
4 Interrupt 2 Privileged General purpose interrupt mode
5 Interrupt 1 Privileged General purpose interrupt mode
6 Interrupt 0 Privileged General purpose interrupt mode
N/A Supervisor Privileged Runs supervisor calls
N/A Application Unprivileged Normal program execution mode
28
32142D–06/2013
ATUC64/128/256L3/4U
Debug state can be entered as described in the AVR32UC Technical Reference Manual.
Debug state is exited by the retd instruction.
4.4.3.3 Secure State
The AVR32 can be set in a secure state, that allows a part of the code to execute in a state with
higher security levels. The rest of the code can not access resources reserved for this secure
code. Secure State is used to implement FlashVault technology. Refer to the AVR32UC Technical
Reference Manual for details.
4.4.4 System Registers
The system registers are placed outside of the virtual memory space, and are only accessible
using the privileged mfsr and mtsr instructions. The table below lists the system registers specified
in the AVR32 architecture, some of which are unused in AVR32UC. The programmer is
responsible for maintaining correct sequencing of any instructions following a mtsr instruction.
For detail on the system registers, refer to the AVR32UC Technical Reference Manual.
Table 4-3. System Registers
Reg # Address Name Function
0 0 SR Status Register
1 4 EVBA Exception Vector Base Address
2 8 ACBA Application Call Base Address
3 12 CPUCR CPU Control Register
4 16 ECR Exception Cause Register
5 20 RSR_SUP Unused in AVR32UC
6 24 RSR_INT0 Unused in AVR32UC
7 28 RSR_INT1 Unused in AVR32UC
8 32 RSR_INT2 Unused in AVR32UC
9 36 RSR_INT3 Unused in AVR32UC
10 40 RSR_EX Unused in AVR32UC
11 44 RSR_NMI Unused in AVR32UC
12 48 RSR_DBG Return Status Register for Debug mode
13 52 RAR_SUP Unused in AVR32UC
14 56 RAR_INT0 Unused in AVR32UC
15 60 RAR_INT1 Unused in AVR32UC
16 64 RAR_INT2 Unused in AVR32UC
17 68 RAR_INT3 Unused in AVR32UC
18 72 RAR_EX Unused in AVR32UC
19 76 RAR_NMI Unused in AVR32UC
20 80 RAR_DBG Return Address Register for Debug mode
21 84 JECR Unused in AVR32UC
22 88 JOSP Unused in AVR32UC
23 92 JAVA_LV0 Unused in AVR32UC
29
32142D–06/2013
ATUC64/128/256L3/4U
24 96 JAVA_LV1 Unused in AVR32UC
25 100 JAVA_LV2 Unused in AVR32UC
26 104 JAVA_LV3 Unused in AVR32UC
27 108 JAVA_LV4 Unused in AVR32UC
28 112 JAVA_LV5 Unused in AVR32UC
29 116 JAVA_LV6 Unused in AVR32UC
30 120 JAVA_LV7 Unused in AVR32UC
31 124 JTBA Unused in AVR32UC
32 128 JBCR Unused in AVR32UC
33-63 132-252 Reserved Reserved for future use
64 256 CONFIG0 Configuration register 0
65 260 CONFIG1 Configuration register 1
66 264 COUNT Cycle Counter register
67 268 COMPARE Compare register
68 272 TLBEHI Unused in AVR32UC
69 276 TLBELO Unused in AVR32UC
70 280 PTBR Unused in AVR32UC
71 284 TLBEAR Unused in AVR32UC
72 288 MMUCR Unused in AVR32UC
73 292 TLBARLO Unused in AVR32UC
74 296 TLBARHI Unused in AVR32UC
75 300 PCCNT Unused in AVR32UC
76 304 PCNT0 Unused in AVR32UC
77 308 PCNT1 Unused in AVR32UC
78 312 PCCR Unused in AVR32UC
79 316 BEAR Bus Error Address Register
80 320 MPUAR0 MPU Address Register region 0
81 324 MPUAR1 MPU Address Register region 1
82 328 MPUAR2 MPU Address Register region 2
83 332 MPUAR3 MPU Address Register region 3
84 336 MPUAR4 MPU Address Register region 4
85 340 MPUAR5 MPU Address Register region 5
86 344 MPUAR6 MPU Address Register region 6
87 348 MPUAR7 MPU Address Register region 7
88 352 MPUPSR0 MPU Privilege Select Register region 0
89 356 MPUPSR1 MPU Privilege Select Register region 1
Table 4-3. System Registers (Continued)
Reg # Address Name Function
30
32142D–06/2013
ATUC64/128/256L3/4U
4.5 Exceptions and Interrupts
In the AVR32 architecture, events are used as a common term for exceptions and interrupts.
AVR32UC incorporates a powerful event handling scheme. The different event sources, like Illegal
Op-code and interrupt requests, have different priority levels, ensuring a well-defined
behavior when multiple events are received simultaneously. Additionally, pending events of a
higher priority class may preempt handling of ongoing events of a lower priority class.
When an event occurs, the execution of the instruction stream is halted, and execution is passed
to an event handler at an address specified in Table 4-4 on page 34. Most of the handlers are
placed sequentially in the code space starting at the address specified by EVBA, with four bytes
between each handler. This gives ample space for a jump instruction to be placed there, jumping
to the event routine itself. A few critical handlers have larger spacing between them, allowing
the entire event routine to be placed directly at the address specified by the EVBA-relative offset
generated by hardware. All interrupt sources have autovectored interrupt service routine (ISR)
addresses. This allows the interrupt controller to directly specify the ISR address as an address
90 360 MPUPSR2 MPU Privilege Select Register region 2
91 364 MPUPSR3 MPU Privilege Select Register region 3
92 368 MPUPSR4 MPU Privilege Select Register region 4
93 372 MPUPSR5 MPU Privilege Select Register region 5
94 376 MPUPSR6 MPU Privilege Select Register region 6
95 380 MPUPSR7 MPU Privilege Select Register region 7
96 384 MPUCRA Unused in this version of AVR32UC
97 388 MPUCRB Unused in this version of AVR32UC
98 392 MPUBRA Unused in this version of AVR32UC
99 396 MPUBRB Unused in this version of AVR32UC
100 400 MPUAPRA MPU Access Permission Register A
101 404 MPUAPRB MPU Access Permission Register B
102 408 MPUCR MPU Control Register
103 412 SS_STATUS Secure State Status Register
104 416 SS_ADRF Secure State Address Flash Register
105 420 SS_ADRR Secure State Address RAM Register
106 424 SS_ADR0 Secure State Address 0 Register
107 428 SS_ADR1 Secure State Address 1 Register
108 432 SS_SP_SYS Secure State Stack Pointer System Register
109 436 SS_SP_APP Secure State Stack Pointer Application Register
110 440 SS_RAR Secure State Return Address Register
111 444 SS_RSR Secure State Return Status Register
112-191 448-764 Reserved Reserved for future use
192-255 768-1020 IMPL IMPLEMENTATION DEFINED
Table 4-3. System Registers (Continued)
Reg # Address Name Function
31
32142D–06/2013
ATUC64/128/256L3/4U
relative to EVBA. The autovector offset has 14 address bits, giving an offset of maximum 16384
bytes. The target address of the event handler is calculated as (EVBA | event_handler_offset),
not (EVBA + event_handler_offset), so EVBA and exception code segments must be set up
appropriately. The same mechanisms are used to service all different types of events, including
interrupt requests, yielding a uniform event handling scheme.
An interrupt controller does the priority handling of the interrupts and provides the autovector offset
to the CPU.
4.5.1 System Stack Issues
Event handling in AVR32UC uses the system stack pointed to by the system stack pointer,
SP_SYS, for pushing and popping R8-R12, LR, status register, and return address. Since event
code may be timing-critical, SP_SYS should point to memory addresses in the IRAM section,
since the timing of accesses to this memory section is both fast and deterministic.
The user must also make sure that the system stack is large enough so that any event is able to
push the required registers to stack. If the system stack is full, and an event occurs, the system
will enter an UNDEFINED state.
4.5.2 Exceptions and Interrupt Requests
When an event other than scall or debug request is received by the core, the following actions
are performed atomically:
1. The pending event will not be accepted if it is masked. The I3M, I2M, I1M, I0M, EM, and
GM bits in the Status Register are used to mask different events. Not all events can be
masked. A few critical events (NMI, Unrecoverable Exception, TLB Multiple Hit, and
Bus Error) can not be masked. When an event is accepted, hardware automatically
sets the mask bits corresponding to all sources with equal or lower priority. This inhibits
acceptance of other events of the same or lower priority, except for the critical events
listed above. Software may choose to clear some or all of these bits after saving the
necessary state if other priority schemes are desired. It is the event source’s responsability
to ensure that their events are left pending until accepted by the CPU.
2. When a request is accepted, the Status Register and Program Counter of the current
context is stored to the system stack. If the event is an INT0, INT1, INT2, or INT3, registers
R8-R12 and LR are also automatically stored to stack. Storing the Status
Register ensures that the core is returned to the previous execution mode when the
current event handling is completed. When exceptions occur, both the EM and GM bits
are set, and the application may manually enable nested exceptions if desired by clearing
the appropriate bit. Each exception handler has a dedicated handler address, and
this address uniquely identifies the exception source.
3. The Mode bits are set to reflect the priority of the accepted event, and the correct register
file bank is selected. The address of the event handler, as shown in Table 4-4 on
page 34, is loaded into the Program Counter.
The execution of the event handler routine then continues from the effective address calculated.
The rete instruction signals the end of the event. When encountered, the Return Status Register
and Return Address Register are popped from the system stack and restored to the Status Register
and Program Counter. If the rete instruction returns from INT0, INT1, INT2, or INT3,
registers R8-R12 and LR are also popped from the system stack. The restored Status Register
contains information allowing the core to resume operation in the previous execution mode. This
concludes the event handling.
32
32142D–06/2013
ATUC64/128/256L3/4U
4.5.3 Supervisor Calls
The AVR32 instruction set provides a supervisor mode call instruction. The scall instruction is
designed so that privileged routines can be called from any context. This facilitates sharing of
code between different execution modes. The scall mechanism is designed so that a minimal
execution cycle overhead is experienced when performing supervisor routine calls from timecritical
event handlers.
The scall instruction behaves differently depending on which mode it is called from. The behaviour
is detailed in the instruction set reference. In order to allow the scall routine to return to the
correct context, a return from supervisor call instruction, rets, is implemented. In the AVR32UC
CPU, scall and rets uses the system stack to store the return address and the status register.
4.5.4 Debug Requests
The AVR32 architecture defines a dedicated Debug mode. When a debug request is received by
the core, Debug mode is entered. Entry into Debug mode can be masked by the DM bit in the
status register. Upon entry into Debug mode, hardware sets the SR.D bit and jumps to the
Debug Exception handler. By default, Debug mode executes in the exception context, but with
dedicated Return Address Register and Return Status Register. These dedicated registers
remove the need for storing this data to the system stack, thereby improving debuggability. The
Mode bits in the Status Register can freely be manipulated in Debug mode, to observe registers
in all contexts, while retaining full privileges.
Debug mode is exited by executing the retd instruction. This returns to the previous context.
4.5.5 Entry Points for Events
Several different event handler entry points exist. In AVR32UC, the reset address is
0x80000000. This places the reset address in the boot flash memory area.
TLB miss exceptions and scall have a dedicated space relative to EVBA where their event handler
can be placed. This speeds up execution by removing the need for a jump instruction placed
at the program address jumped to by the event hardware. All other exceptions have a dedicated
event routine entry point located relative to EVBA. The handler routine address identifies the
exception source directly.
AVR32UC uses the ITLB and DTLB protection exceptions to signal a MPU protection violation.
ITLB and DTLB miss exceptions are used to signal that an access address did not map to any of
the entries in the MPU. TLB multiple hit exception indicates that an access address did map to
multiple TLB entries, signalling an error.
All interrupt requests have entry points located at an offset relative to EVBA. This autovector offset
is specified by an interrupt controller. The programmer must make sure that none of the
autovector offsets interfere with the placement of other code. The autovector offset has 14
address bits, giving an offset of maximum 16384 bytes.
Special considerations should be made when loading EVBA with a pointer. Due to security considerations,
the event handlers should be located in non-writeable flash memory, or optionally in
a privileged memory protection region if an MPU is present.
If several events occur on the same instruction, they are handled in a prioritized way. The priority
ordering is presented in Table 4-4 on page 34. If events occur on several instructions at different
locations in the pipeline, the events on the oldest instruction are always handled before any
events on any younger instruction, even if the younger instruction has events of higher priority
33
32142D–06/2013
ATUC64/128/256L3/4U
than the oldest instruction. An instruction B is younger than an instruction A if it was sent down
the pipeline later than A.
The addresses and priority of simultaneous events are shown in Table 4-4 on page 34. Some of
the exceptions are unused in AVR32UC since it has no MMU, coprocessor interface, or floatingpoint
unit.
34
32142D–06/2013
ATUC64/128/256L3/4U
Table 4-4. Priority and Handler Addresses for Events
Priority Handler Address Name Event source Stored Return Address
1 0x80000000 Reset External input Undefined
2 Provided by OCD system OCD Stop CPU OCD system First non-completed instruction
3 EVBA+0x00 Unrecoverable exception Internal PC of offending instruction
4 EVBA+0x04 TLB multiple hit MPU PC of offending instruction
5 EVBA+0x08 Bus error data fetch Data bus First non-completed instruction
6 EVBA+0x0C Bus error instruction fetch Data bus First non-completed instruction
7 EVBA+0x10 NMI External input First non-completed instruction
8 Autovectored Interrupt 3 request External input First non-completed instruction
9 Autovectored Interrupt 2 request External input First non-completed instruction
10 Autovectored Interrupt 1 request External input First non-completed instruction
11 Autovectored Interrupt 0 request External input First non-completed instruction
12 EVBA+0x14 Instruction Address CPU PC of offending instruction
13 EVBA+0x50 ITLB Miss MPU PC of offending instruction
14 EVBA+0x18 ITLB Protection MPU PC of offending instruction
15 EVBA+0x1C Breakpoint OCD system First non-completed instruction
16 EVBA+0x20 Illegal Opcode Instruction PC of offending instruction
17 EVBA+0x24 Unimplemented instruction Instruction PC of offending instruction
18 EVBA+0x28 Privilege violation Instruction PC of offending instruction
19 EVBA+0x2C Floating-point UNUSED
20 EVBA+0x30 Coprocessor absent Instruction PC of offending instruction
21 EVBA+0x100 Supervisor call Instruction PC(Supervisor Call) +2
22 EVBA+0x34 Data Address (Read) CPU PC of offending instruction
23 EVBA+0x38 Data Address (Write) CPU PC of offending instruction
24 EVBA+0x60 DTLB Miss (Read) MPU PC of offending instruction
25 EVBA+0x70 DTLB Miss (Write) MPU PC of offending instruction
26 EVBA+0x3C DTLB Protection (Read) MPU PC of offending instruction
27 EVBA+0x40 DTLB Protection (Write) MPU PC of offending instruction
28 EVBA+0x44 DTLB Modified UNUSED
35
32142D–06/2013
ATUC64/128/256L3/4U
5. Memories
5.1 Embedded Memories
• Internal high-speed flash
– 256Kbytes (ATUC256L3U, ATUC256L4U)
– 128Kbytes (ATUC128L3U, ATUC128L4U)
– 64Kbytes (ATUC64L3U, ATUC64L4U)
• 0 wait state access at up to 25MHz in worst case conditions
• 1 wait state access at up to 50MHz in worst case conditions
• Pipelined flash architecture, allowing burst reads from sequential flash locations, hiding
penalty of 1 wait state access
• Pipelined flash architecture typically reduces the cycle penalty of 1 wait state operation
to only 8% compared to 0 wait state operation
• 100 000 write cycles, 15-year data retention capability
• Sector lock capabilities, bootloader protection, security bit
• 32 fuses, erased during chip erase
• User page for data to be preserved during chip erase
• Internal high-speed SRAM, single-cycle access at full speed
– 32Kbytes (ATUC256L3U, ATUC256L4U, ATUC128L3U, ATUC128L4U)
– 16Kbytes (ATUC64L3U, ATUC64L4U)
5.2 Physical Memory Map
The system bus is implemented as a bus matrix. All system bus addresses are fixed, and they
are never remapped in any way, not even during boot. Note that AVR32 UC CPU uses unsegmented
translation, as described in the AVR32 Architecture Manual. The 32-bit physical address
space is mapped as follows:
Table 5-1. ATUC64/128/256L3/4U Physical Memory Map
Memory Start Address
Size
ATUC256L3U, ATUC256L4U ATUC128L3U, ATUC128L4U ATUC64L3U, ATUC64L4U
Embedded SRAM 0x00000000 32Kbytes 32Kbytes 16Kbytes
Embedded Flash 0x80000000 256Kbytes 128Kbytes 64Kbytes
SAU Channels 0x90000000 256 bytes 256 bytes 256 bytes
HSB-PB Bridge B 0xFFFE0000 64Kbytes 64Kbytes 64Kbytes
HSB-PB Bridge A 0xFFFF0000 64Kbytes 64Kbytes 64Kbytes
Table 5-2. Flash Memory Parameters
Device Flash Size (FLASH_PW) Number of Pages (FLASH_P) Page Size (FLASH_W)
ATUC256L3U,
ATUC256L4U 256Kbytes 512 512 bytes
ATUC128L3U,
ATUC128L4U 128Kbytes 256 512 bytes
ATUC64L3U,
ATUC64L4U 64Kbytes 128 512 bytes
36
32142D–06/2013
ATUC64/128/256L3/4U
5.3 Peripheral Address Map
Table 5-3. Peripheral Address Mapping
Address Peripheral Name
0xFFFE0000
FLASHCDW Flash Controller - FLASHCDW
0xFFFE0400
HMATRIX HSB Matrix - HMATRIX
0xFFFE0800
SAU Secure Access Unit - SAU
0xFFFE1000
USBC USB 2.0 Interface - USBC
0xFFFF0000
PDCA Peripheral DMA Controller - PDCA
0xFFFF1000
INTC Interrupt controller - INTC
0xFFFF1400
PM Power Manager - PM
0xFFFF1800
SCIF System Control Interface - SCIF
0xFFFF1C00
AST Asynchronous Timer - AST
0xFFFF2000
WDT Watchdog Timer - WDT
0xFFFF2400
EIC External Interrupt Controller - EIC
0xFFFF2800
FREQM Frequency Meter - FREQM
0xFFFF2C00
GPIO General-Purpose Input/Output Controller - GPIO
0xFFFF3000
USART0 Universal Synchronous Asynchronous Receiver
Transmitter - USART0
0xFFFF3400
USART1 Universal Synchronous Asynchronous Receiver
Transmitter - USART1
0xFFFF3800
USART2 Universal Synchronous Asynchronous Receiver
Transmitter - USART2
0xFFFF3C00
USART3 Universal Synchronous Asynchronous Receiver
Transmitter - USART3
0xFFFF4000
SPI Serial Peripheral Interface - SPI
37
32142D–06/2013
ATUC64/128/256L3/4U
5.4 CPU Local Bus Mapping
Some of the registers in the GPIO module are mapped onto the CPU local bus, in addition to
being mapped on the Peripheral Bus. These registers can therefore be reached both by
accesses on the Peripheral Bus, and by accesses on the local bus.
Mapping these registers on the local bus allows cycle-deterministic toggling of GPIO pins since
the CPU and GPIO are the only modules connected to this bus. Also, since the local bus runs at
CPU speed, one write or read operation can be performed per clock cycle to the local busmapped
GPIO registers.
0xFFFF4400
TWIM0 Two-wire Master Interface - TWIM0
0xFFFF4800
TWIM1 Two-wire Master Interface - TWIM1
0xFFFF4C00
TWIS0 Two-wire Slave Interface - TWIS0
0xFFFF5000
TWIS1 Two-wire Slave Interface - TWIS1
0xFFFF5400
PWMA Pulse Width Modulation Controller - PWMA
0xFFFF5800
TC0 Timer/Counter - TC0
0xFFFF5C00
TC1 Timer/Counter - TC1
0xFFFF6000
ADCIFB ADC Interface - ADCIFB
0xFFFF6400
ACIFB Analog Comparator Interface - ACIFB
0xFFFF6800
CAT Capacitive Touch Module - CAT
0xFFFF6C00
GLOC Glue Logic Controller - GLOC
0xFFFF7000
AW aWire - AW
0xFFFF7400
ABDACB Audio Bitstream DAC - ABDACB
0xFFFF7800
IISC Inter-IC Sound (I2S) Controller - IISC
Table 5-3. Peripheral Address Mapping
38
32142D–06/2013
ATUC64/128/256L3/4U
The following GPIO registers are mapped on the local bus:
Table 5-4. Local Bus Mapped GPIO Registers
Port Register Mode
Local Bus
Address Access
0 Output Driver Enable Register (ODER) WRITE 0x40000040 Write-only
SET 0x40000044 Write-only
CLEAR 0x40000048 Write-only
TOGGLE 0x4000004C Write-only
Output Value Register (OVR) WRITE 0x40000050 Write-only
SET 0x40000054 Write-only
CLEAR 0x40000058 Write-only
TOGGLE 0x4000005C Write-only
Pin Value Register (PVR) - 0x40000060 Read-only
1 Output Driver Enable Register (ODER) WRITE 0x40000140 Write-only
SET 0x40000144 Write-only
CLEAR 0x40000148 Write-only
TOGGLE 0x4000014C Write-only
Output Value Register (OVR) WRITE 0x40000150 Write-only
SET 0x40000154 Write-only
CLEAR 0x40000158 Write-only
TOGGLE 0x4000015C Write-only
Pin Value Register (PVR) - 0x40000160 Read-only
39
32142D–06/2013
ATUC64/128/256L3/4U
6. Supply and Startup Considerations
6.1 Supply Considerations
6.1.1 Power Supplies
The ATUC64/128/256L3/4U has several types of power supply pins:
• VDDIO: Powers I/O lines. Voltage is 1.8 to 3.3V nominal.
• VDDIN: Powers I/O lines, the USB pins, and the internal regulator. Voltage is 1.8 to 3.3V
nominal if USB is not used, and 3.3V nominal when USB is used.
• VDDANA: Powers the ADC. Voltage is 1.8V nominal.
• VDDCORE: Powers the core, memories, and peripherals. Voltage is 1.8V nominal.
The ground pins GND are common to VDDCORE, VDDIO, and VDDIN. The ground pin for
VDDANA is GNDANA.
When VDDCORE is not connected to VDDIN, the VDDIN voltage must be higher than 1.98V.
Refer to Section 35. on page 897 for power consumption on the various supply pins.
For decoupling recommendations for the different power supplies, please refer to the schematic
checklist.
Refer to Section on page 10 for power supply connections for I/O pins.
6.1.2 Voltage Regulator
The ATUC64/128/256L3/4U embeds a voltage regulator that converts from 3.3V nominal to
1.8V with a load of up to 60 mA. The regulator supplies the output voltage on VDDCORE. The
regulator may only be used to drive internal circuitry in the device. VDDCORE should be externally
connected to the 1.8V domains. See Section 6.1.3 for regulator connection figures.
Adequate output supply decoupling is mandatory for VDDCORE to reduce ripple and avoid
oscillations. The best way to achieve this is to use two capacitors in parallel between VDDCORE
and GND as close to the device as possible. Please refer to Section 35.8 on page 911 for
decoupling capacitors values and regulator characteristics.
Figure 6-1. Supply Decoupling.
The voltage regulator can be turned off in the shutdown mode to power down the core logic and
keep a small part of the system powered in order to reduce power consumption. To enter this
mode the 3.3V supply mode, with 1.8V regulated I/O lines power supply configuration must be
used.
3.3V
1.8V
VDDIN
VDDCORE
1.8V
Regulator
CIN1
COUT1 COUT2
C IN3 IN2 C
40
32142D–06/2013
ATUC64/128/256L3/4U
6.1.3 Regulator Connection
The ATUC64/128/256L3/4U supports three power supply configurations:
• 3.3V single supply mode
– Shutdown mode is not available
• 1.8V single supply mode
– Shutdown mode is not available
• 3.3V supply mode, with 1.8V regulated I/O lines
– Shutdown mode is available
41
32142D–06/2013
ATUC64/128/256L3/4U
6.1.3.1 3.3V Single Supply Mode
In 3.3V single supply mode the internal regulator is connected to the 3.3V source (VDDIN pin)
and its output feeds VDDCORE. Figure 6-2 shows the power schematics to be used for 3.3V
single supply mode. All I/O lines will be powered by the same power (VDDIN=VDDIO).
Figure 6-2. 3.3V Single Supply Mode
VDDIO
VDDCORE
+
- 1.98-3.6V
VDDANA ADC
VDDIN GND
GNDANA
CPU,
Peripherals,
Memories,
SCIF, BOD,
RCSYS,
DFLL, PLL
OSC32K,
RC32K,
POR33,
SM33
I/O Pins I/O Pins
OSC32K_2,
AST, Wake,
Regulator
control
Linear
regulator
42
32142D–06/2013
ATUC64/128/256L3/4U
6.1.3.2 1.8V Single Supply Mode
In 1.8V single supply mode the internal regulator is not used, and VDDIO and VDDCORE are
powered by a single 1.8V supply as shown in Figure 6-3. All I/O lines will be powered by the
same power (VDDIN = VDDIO = VDDCORE).
Figure 6-3. 1.8V Single Supply Mode
VDDIO
VDDCORE
+
-
1.62-1.98V
VDDANA ADC
VDDIN GND
GNDANA
CPU,
Peripherals,
Memories,
SCIF, BOD,
RCSYS,
DFLL, PLL
OSC32K,
RC32K,
POR33,
SM33
I/O Pins I/O Pins
OSC32K_2,
AST, Wake,
Regulator
control
43
32142D–06/2013
ATUC64/128/256L3/4U
6.1.3.3 3.3V Supply Mode with 1.8V Regulated I/O Lines
In this mode, the internal regulator is connected to the 3.3V source and its output is connected
to both VDDCORE and VDDIO as shown in Figure 6-4. This configuration is required in order to
use Shutdown mode.
Figure 6-4. 3.3V Supply Mode with 1.8V Regulated I/O Lines
In this mode, some I/O lines are powered by VDDIN while other I/O lines are powered by VDDIO.
Refer to Section on page 10 for description of power supply for each I/O line.
Refer to the Power Manager chapter for a description of what parts of the system are powered in
Shutdown mode.
Important note: As the regulator has a maximum output current of 60 mA, this mode can only be
used in applications where the maximum I/O current is known and compatible with the core and
peripheral power consumption. Typically, great care must be used to ensure that only a few I/O
lines are toggling at the same time and drive very small loads.
VDDIO
VDDCORE
+
- 1.98-3.6V
VDDANA ADC
VDDIN GND
GNDANA
CPU,
Peripherals,
Memories,
SCIF, BOD,
RCSYS,
DFLL, PLL
OSC32K,
RC32K,
POR33,
SM33
I/O Pins I/O Pins
OSC32K_2,
AST, Wake,
Regulator
control
Linear
regulator
44
32142D–06/2013
ATUC64/128/256L3/4U
6.1.4 Power-up Sequence
6.1.4.1 Maximum Rise Rate
To avoid risk of latch-up, the rise rate of the power supplies must not exceed the values
described in Table 35-3 on page 898.
Recommended order for power supplies is also described in this chapter.
6.1.4.2 Minimum Rise Rate
The integrated Power-on Reset (POR33) circuitry monitoring the VDDIN powering supply
requires a minimum rise rate for the VDDIN power supply.
See Table 35-3 on page 898 for the minimum rise rate value.
If the application can not ensure that the minimum rise rate condition for the VDDIN power supply
is met, one of the following configurations can be used:
• A logic “0” value is applied during power-up on pin PA11 (WAKE_N) until VDDIN rises above
1.2V.
• A logic “0” value is applied during power-up on pin RESET_N until VDDIN rises above 1.2V.
6.2 Startup Considerations
This chapter summarizes the boot sequence of the ATUC64/128/256L3/4U. The behavior after
power-up is controlled by the Power Manager. For specific details, refer to the Power Manager
chapter.
6.2.1 Starting of Clocks
After power-up, the device will be held in a reset state by the Power-on Reset (POR18 and
POR33) circuitry for a short time to allow the power to stabilize throughout the device. After
reset, the device will use the System RC Oscillator (RCSYS) as clock source. Please refer to
Table 35-17 on page 910 for the frequency for this oscillator.
On system start-up, all high-speed clocks are disabled. All clocks to all modules are running. No
clocks have a divided frequency; all parts of the system receive a clock with the same frequency
as the System RC Oscillator.
When powering up the device, there may be a delay before the voltage has stabilized, depending
on the rise time of the supply used. The CPU can start executing code as soon as the supply
is above the POR18 and POR33 thresholds, and before the supply is stable. Before switching to
a high-speed clock source, the user should use the BOD to make sure the VDDCORE is above
the minimum level (1.62V).
6.2.2 Fetching of Initial Instructions
After reset has been released, the AVR32 UC CPU starts fetching instructions from the reset
address, which is 0x80000000. This address points to the first address in the internal Flash.
The code read from the internal flash is free to configure the clock system and clock sources.
Please refer to the PM and SCIF chapters for more details.
45
32142D–06/2013
ATUC64/128/256L3/4U
7. Peripheral DMA Controller (PDCA)
Rev: 1.2.3.1
7.1 Features
• Multiple channels
• Generates transfers between memories and peripherals such as USART and SPI
• Two address pointers/counters per channel allowing double buffering
• Performance monitors to measure average and maximum transfer latency
• Optional synchronizing of data transfers with extenal peripheral events
• Ring buffer functionality
7.2 Overview
The Peripheral DMA Controller (PDCA) transfers data between on-chip peripheral modules such
as USART, SPI and memories (those memories may be on- and off-chip memories). Using the
PDCA avoids CPU intervention for data transfers, improving the performance of the microcontroller.
The PDCA can transfer data from memory to a peripheral or from a peripheral to memory.
The PDCA consists of multiple DMA channels. Each channel has:
• A Peripheral Select Register
• A 32-bit memory pointer
• A 16-bit transfer counter
• A 32-bit memory pointer reload value
• A 16-bit transfer counter reload value
The PDCA communicates with the peripheral modules over a set of handshake interfaces. The
peripheral signals the PDCA when it is ready to receive or transmit data. The PDCA acknowledges
the request when the transmission has started.
When a transmit buffer is empty or a receive buffer is full, an optional interrupt request can be
generated.
46
32142D–06/2013
ATUC64/128/256L3/4U
7.3 Block Diagram
Figure 7-1. PDCA Block Diagram
7.4 Product Dependencies
In order to use this module, other parts of the system must be configured correctly, as described
below.
7.4.1 Power Management
If the CPU enters a sleep mode that disables the PDCA clocks, the PDCA will stop functioning
and resume operation after the system wakes up from sleep mode.
7.4.2 Clocks
The PDCA has two bus clocks connected: One High Speed Bus clock (CLK_PDCA_HSB) and
one Peripheral Bus clock (CLK_PDCA_PB). These clocks are generated by the Power Manager.
Both clocks are enabled at reset, and can be disabled in the Power Manager. It is
recommended to disable the PDCA before disabling the clocks, to avoid freezing the PDCA in
an undefined state.
7.4.3 Interrupts
The PDCA interrupt request lines are connected to the interrupt controller. Using the PDCA
interrupts requires the interrupt controller to be programmed first.
HSB to PB
Bridge
Peripheral DMA
Controller
(PDCA)
Peripheral
0
High Speed
Bus Matrix
Handshake Interfaces Peripheral Bus
IRQ
HSB
HSB
Interrupt
Controller
Peripheral
1
Peripheral
2
Peripheral
(n-1) ...
Memory
HSB
47
32142D–06/2013
ATUC64/128/256L3/4U
7.4.4 Peripheral Events
The PDCA peripheral events are connected via the Peripheral Event System. Refer to the
Peripheral Event System chapter for details.
7.5 Functional Description
7.5.1 Basic Operation
The PDCA consists of multiple independent PDCA channels, each capable of handling DMA
requests in parallel. Each PDCA channels contains a set of configuration registers which must
be configured to start a DMA transfer.
In this section the steps necessary to configure one PDCA channel is outlined.
The peripheral to transfer data to or from must be configured correctly in the Peripheral Select
Register (PSR). This is performed by writing the Peripheral Identity (PID) value for the corresponding
peripheral to the PID field in the PSR register. The PID also encodes the transfer
direction, i.e. memory to peripheral or peripheral to memory. See Section 7.5.6.
The transfer size must be written to the Transfer Size field in the Mode Register (MR.SIZE). The
size must match the data size produced or consumed by the selected peripheral. See Section
7.5.7.
The memory address to transfer to or from, depending on the PSR, must be written to the Memory
Address Register (MAR). For each transfer the memory address is increased by either a
one, two or four, depending on the size set in MR. See Section 7.5.2.
The number of data items to transfer is written to the TCR register. If the PDCA channel is
enabled, a transfer will start immediately after writing a non-zero value to TCR or the reload version
of TCR, TCRR. After each transfer the TCR value is decreased by one. Both MAR and TCR
can be read while the PDCA channel is active to monitor the DMA progress. See Section 7.5.3.
The channel must be enabled for a transfer to start. A channel is enable by writing a one to the
EN bit in the Control Register (CR).
7.5.2 Memory Pointer
Each channel has a 32-bit Memory Address Register (MAR). This register holds the memory
address for the next transfer to be performed. The register is automatically updated after each
transfer. The address will be increased by either one, two or four depending on the size of the
DMA transfer (byte, halfword or word). The MAR can be read at any time during transfer.
7.5.3 Transfer Counter
Each channel has a 16-bit Transfer Counter Register (TCR). This register must be written with
the number of transfers to be performed. The TCR register should contain the number of data
items to be transferred independently of the transfer size. The TCR can be read at any time during
transfer to see the number of remaining transfers.
7.5.4 Reload Registers
Both the MAR and the TCR have a reload register, respectively Memory Address Reload Register
(MARR) and Transfer Counter Reload Register (TCRR). These registers provide the
possibility for the PDCA to work on two memory buffers for each channel. When one buffer has
completed, MAR and TCR will be reloaded with the values in MARR and TCRR. The reload logic
is always enabled and will trigger if the TCR reaches zero while TCRR holds a non-zero value.
After reload, the MARR and TCRR registers are cleared.
48
32142D–06/2013
ATUC64/128/256L3/4U
If TCR is zero when writing to TCRR, the TCR and MAR are automatically updated with the
value written in TCRR and MARR.
7.5.5 Ring Buffer
When Ring Buffer mode is enabled the TCRR and MARR registers will not be cleared when
TCR and MAR registers reload. This allows the PDCA to read or write to the same memory
region over and over again until the transfer is actively stopped by the user. Ring Buffer mode is
enabled by writing a one to the Ring Buffer bit in the Mode Register (MR.RING).
7.5.6 Peripheral Selection
The Peripheral Select Register (PSR) decides which peripheral should be connected to the
PDCA channel. A peripheral is selected by writing the corresponding Peripheral Identity (PID) to
the PID field in the PSR register. Writing the PID will both select the direction of the transfer
(memory to peripheral or peripheral to memory), which handshake interface to use, and the
address of the peripheral holding register. Refer to the Peripheral Identity (PID) table in the Module
Configuration section for the peripheral PID values.
7.5.7 Transfer Size
The transfer size can be set individually for each channel to be either byte, halfword or word (8-
bit, 16-bit or 32-bit respectively). Transfer size is set by writing the desired value to the Transfer
Size field in the Mode Register (MR.SIZE).
When the PDCA moves data between peripherals and memory, data is automatically sized and
aligned. When memory is accessed, the size specified in MR.SIZE and system alignment is
used. When a peripheral register is accessed the data to be transferred is converted to a word
where bit n in the data corresponds to bit n in the peripheral register. If the transfer size is byte or
halfword, bits greater than 8 and16 respectively are set to zero.
Refer to the Module Configuration section for information regarding what peripheral registers are
used for the different peripherals and then to the peripheral specific chapter for information
about the size option available for the different registers.
7.5.8 Enabling and Disabling
Each DMA channel is enabled by writing a one to the Transfer Enable bit in the Control Register
(CR.TEN) and disabled by writing a one to the Transfer Disable bit (CR.TDIS). The current status
can be read from the Status Register (SR).
While the PDCA channel is enabled all DMA request will be handled as long the TCR and TCRR
is not zero.
7.5.9 Interrupts
Interrupts can be enabled by writing a one to the corresponding bit in the Interrupt Enable Register
(IER) and disabled by writing a one to the corresponding bit in the Interrupt Disable Register
(IDR). The Interrupt Mask Register (IMR) can be read to see whether an interrupt is enabled or
not. The current status of an interrupt source can be read through the Interrupt Status Register
(ISR).
The PDCA has three interrupt sources:
• Reload Counter Zero - The TCRR register is zero.
• Transfer Finished - Both the TCR and TCRR registers are zero.
• Transfer Error - An error has occurred in accessing memory.
49
32142D–06/2013
ATUC64/128/256L3/4U
7.5.10 Priority
If more than one PDCA channel is requesting transfer at a given time, the PDCA channels are
prioritized by their channel number. Channels with lower numbers have priority over channels
with higher numbers, giving channel zero the highest priority.
7.5.11 Error Handling
If the Memory Address Register (MAR) is set to point to an invalid location in memory, an error
will occur when the PDCA tries to perform a transfer. When an error occurs, the Transfer Error
bit in the Interrupt Status Register (ISR.TERR) will be set and the DMA channel that caused the
error will be stopped. In order to restart the channel, the user must program the Memory
Address Register to a valid address and then write a one to the Error Clear bit in the Control
Register (CR.ECLR). If the Transfer Error interrupt is enabled, an interrupt request will be generated
when a transfer error occurs.
7.5.12 Peripheral Event Trigger
Peripheral events can be used to trigger PDCA channel transfers. Peripheral Event synchronizations
are enabled by writing a one to the Event Trigger bit in the Mode Register (MR.ETRIG).
When set, all DMA requests will be blocked until a peripheral event is received. For each peripheral
event received, only one data item is transferred. If no DMA requests are pending when a
peripheral event is received, the PDCA will start a transfer as soon as a peripheral event is
detected. If multiple events are received while the PDCA channel is busy transferring data, an
overflow condition will be signaled in the Peripheral Event System. Refer to the Peripheral Event
System chapter for more information.
7.6 Performance Monitors
Up to two performance monitors allow the user to measure the activity and stall cycles for PDCA
transfers. To monitor a PDCA channel, the corresponding channel number must be written to
one of the MON0/1CH fields in the Performance Control Register (PCONTROL) and a one must
be written to the corresponding CH0/1EN bit in the same register.
Due to performance monitor hardware resource sharing, the two monitor channels should NOT
be programmed to monitor the same PDCA channel. This may result in UNDEFINED performance
monitor behavior.
7.6.1 Measuring mechanisms
Three different parameters can be measured by each channel:
• The number of data transfer cycles since last channel reset, both for read and write
• The number of stall cycles since last channel reset, both for read and write
• The maximum latency since last channel reset, both for read and write
These measurements can be extracted by software and used to generate indicators for bus
latency, bus load, and maximum bus latency.
Each of the counters has a fixed width, and may therefore overflow. When an overflow is
encountered in either the Performance Channel Data Read/Write Cycle registers (PRDATA0/1
and PWDATA0/1) or the Performance Channel Read/Write Stall Cycles registers (PRSTALL0/1
and PWSTALL0/1) of a channel, all registers in the channel are reset. This behavior is altered if
the Channel Overflow Freeze bit is one in the Performance Control register (PCONTROL.CH0/1OVF).
If this bit is one, the channel registers are frozen when either DATA or
STALL reaches its maximum value. This simplifies one-shot readout of the counter values.
50
32142D–06/2013
ATUC64/128/256L3/4U
The registers can also be manually reset by writing a one to the Channel Reset bit in the PCONTROL
register (PCONTROL.CH0/1RES). The Performance Channel Read/Write Latency
registers (PRLAT0/1 and PWLAT0/1) are saturating when their maximum count value is
reached. The PRLAT0/1 and PWLAT0/1 registers can only be reset by writing a one to the corresponding
reset bit in PCONTROL (PCONTROL.CH0/1RES).
A counter is enabled by writing a one to the Channel Enable bit in the Performance Control Register
(PCONTROL.CH0/1EN).
51
32142D–06/2013
ATUC64/128/256L3/4U
7.7 User Interface
7.7.1 Memory Map Overview
The channels are mapped as shown in Table 7-1. Each channel has a set of configuration registers,
shown in Table 7-2, where n is the channel number.
7.7.2 Channel Memory Map
Note: 1. The reset values are device specific. Please refer to the Module Configuration section at the
end of this chapter.
Table 7-1. PDCA Register Memory Map
Address Range Contents
0x000 - 0x03F DMA channel 0 configuration registers
0x040 - 0x07F DMA channel 1 configuration registers
... ...
(0x000 - 0x03F)+m*0x040 DMA channel m configuration registers
0x800-0x830 Performance Monitor registers
0x834 Version register
Table 7-2. PDCA Channel Configuration Registers
Offset Register Register Name Access Reset
0x000 + n*0x040 Memory Address Register MAR Read/Write 0x00000000
0x004 + n*0x040 Peripheral Select Register PSR Read/Write - (1)
0x008 + n*0x040 Transfer Counter Register TCR Read/Write 0x00000000
0x00C + n*0x040 Memory Address Reload Register MARR Read/Write 0x00000000
0x010 + n*0x040 Transfer Counter Reload Register TCRR Read/Write 0x00000000
0x014 + n*0x040 Control Register CR Write-only 0x00000000
0x018 + n*0x040 Mode Register MR Read/Write 0x00000000
0x01C + n*0x040 Status Register SR Read-only 0x00000000
0x020 + n*0x040 Interrupt Enable Register IER Write-only 0x00000000
0x024 + n*0x040 Interrupt Disable Register IDR Write-only 0x00000000
0x028 + n*0x040 Interrupt Mask Register IMR Read-only 0x00000000
0x02C + n*0x040 Interrupt Status Register ISR Read-only 0x00000000
52
32142D–06/2013
ATUC64/128/256L3/4U
7.7.3 Performance Monitor Memory Map
Note: 1. The number of performance monitors is device specific. If the device has only one performance
monitor, the Channel1 registers are not available. Please refer to the Module
Configuration section at the end of this chapter for the number of performance monitors on this
device.
7.7.4 Version Register Memory Map
Note: 1. The reset values are device specific. Please refer to the Module Configuration section at the end of this chapter.
Table 7-3. PDCA Performance Monitor Registers(1)
Offset Register Register Name Access Reset
0x800 Performance Control Register PCONTROL Read/Write 0x00000000
0x804 Channel0 Read Data Cycles PRDATA0 Read-only 0x00000000
0x808 Channel0 Read Stall Cycles PRSTALL0 Read-only 0x00000000
0x80C Channel0 Read Max Latency PRLAT0 Read-only 0x00000000
0x810 Channel0 Write Data Cycles PWDATA0 Read-only 0x00000000
0x814 Channel0 Write Stall Cycles PWSTALL0 Read-only 0x00000000
0x818 Channel0 Write Max Latency PWLAT0 Read-only 0x00000000
0x81C Channel1 Read Data Cycles PRDATA1 Read-only 0x00000000
0x820 Channel1 Read Stall Cycles PRSTALL1 Read-only 0x00000000
0x824 Channel1 Read Max Latency PRLAT1 Read-only 0x00000000
0x828 Channel1 Write Data Cycles PWDATA1 Read-only 0x00000000
0x82C Channel1 Write Stall Cycles PWSTALL1 Read-only 0x00000000
0x830 Channel1 Write Max Latency PWLAT1 Read-only 0x00000000
Table 7-4. PDCA Version Register Memory Map
Offset Register Register Name Access Reset
0x834 Version Register VERSION Read-only - (1)
53
32142D–06/2013
ATUC64/128/256L3/4U
7.7.5 Memory Address Register
Name: MAR
Access Type: Read/Write
Offset: 0x000 + n*0x040
Reset Value: 0x00000000
• MADDR: Memory Address
Address of memory buffer. MADDR should be programmed to point to the start of the memory buffer when configuring the
PDCA. During transfer, MADDR will point to the next memory location to be read/written.
31 30 29 28 27 26 25 24
MADDR[31:24]
23 22 21 20 19 18 17 16
MADDR[23:16]
15 14 13 12 11 10 9 8
MADDR[15:8]
76543210
MADDR[7:0]
54
32142D–06/2013
ATUC64/128/256L3/4U
7.7.6 Peripheral Select Register
Name: PSR
Access Type: Read/Write
Offset: 0x004 + n*0x040
Reset Value: -
• PID: Peripheral Identifier
The Peripheral Identifier selects which peripheral should be connected to the DMA channel. Writing a PID will select both which
handshake interface to use, the direction of the transfer and also the address of the Receive/Transfer Holding Register for the
peripheral. See the Module Configuration section of PDCA for details. The width of the PID field is device specific and
dependent on the number of peripheral modules in the device.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
PID
55
32142D–06/2013
ATUC64/128/256L3/4U
7.7.7 Transfer Counter Register
Name: TCR
Access Type: Read/Write
Offset: 0x008 + n*0x040
Reset Value: 0x00000000
• TCV: Transfer Counter Value
Number of data items to be transferred by the PDCA. TCV must be programmed with the total number of transfers to be made.
During transfer, TCV contains the number of remaining transfers to be done.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
TCV[15:8]
76543210
TCV[7:0]
56
32142D–06/2013
ATUC64/128/256L3/4U
7.7.8 Memory Address Reload Register
Name: MARR
Access Type: Read/Write
Offset: 0x00C + n*0x040
Reset Value: 0x00000000
• MARV: Memory Address Reload Value
Reload Value for the MAR register. This value will be loaded into MAR when TCR reaches zero if the TCRR register has a nonzero
value.
31 30 29 28 27 26 25 24
MARV[31:24]
23 22 21 20 19 18 17 16
MARV[23:16]
15 14 13 12 11 10 9 8
MARV[15:8]
76543210
MARV[7:0]
57
32142D–06/2013
ATUC64/128/256L3/4U
7.7.9 Transfer Counter Reload Register
Name: TCRR
Access Type: Read/Write
Offset: 0x010 + n*0x040
Reset Value: 0x00000000
• TCRV: Transfer Counter Reload Value
Reload value for the TCR register. When TCR reaches zero, it will be reloaded with TCRV if TCRV has a positive value. If TCRV
is zero, no more transfers will be performed for the channel. When TCR is reloaded, the TCRR register is cleared.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
TCRV[15:8]
76543210
TCRV[7:0]
58
32142D–06/2013
ATUC64/128/256L3/4U
7.7.10 Control Register
Name: CR
Access Type: Write-only
Offset: 0x014 + n*0x040
Reset Value: 0x00000000
• ECLR: Transfer Error Clear
Writing a zero to this bit has no effect.
Writing a one to this bit will clear the Transfer Error bit in the Status Register (SR.TERR). Clearing the SR.TERR bit will allow the
channel to transmit data. The memory address must first be set to point to a valid location.
• TDIS: Transfer Disable
Writing a zero to this bit has no effect.
Writing a one to this bit will disable transfer for the DMA channel.
• TEN: Transfer Enable
Writing a zero to this bit has no effect.
Writing a one to this bit will enable transfer for the DMA channel.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
- - - - - - - ECLR
76543210
- - - - - - TDIS TEN
59
32142D–06/2013
ATUC64/128/256L3/4U
7.7.11 Mode Register
Name: MR
Access Type: Read/Write
Offset: 0x018 + n*0x040
Reset Value: 0x00000000
• RING: Ring Buffer
0:The Ring buffer functionality is disabled.
1:The Ring buffer functionality is enabled. When enabled, the reload registers, MARR and TCRR will not be cleared after reload.
• ETRIG: Event Trigger
0:Start transfer when the peripheral selected in Peripheral Select Register (PSR) requests a transfer.
1:Start transfer only when or after a peripheral event is received.
• SIZE: Size of Transfer
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
- - - - RING ETRIG SIZE
Table 7-5. Size of Transfer
SIZE Size of Transfer
0 Byte
1 Halfword
2 Word
3 Reserved
60
32142D–06/2013
ATUC64/128/256L3/4U
7.7.12 Status Register
Name: SR
Access Type: Read-only
Offset: 0x01C + n*0x040
Reset Value: 0x00000000
• TEN: Transfer Enabled
This bit is cleared when the TDIS bit in CR is written to one.
This bit is set when the TEN bit in CR is written to one.
0: Transfer is disabled for the DMA channel.
1: Transfer is enabled for the DMA channel.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
- - - - - - - TEN
61
32142D–06/2013
ATUC64/128/256L3/4U
7.7.13 Interrupt Enable Register
Name: IER
Access Type: Write-only
Offset: 0x020 + n*0x040
Reset Value: 0x00000000
Writing a zero to a bit in this register has no effect.
Writing a one to a bit in this register will set the corresponding bit in IMR.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
- - - - - TERR TRC RCZ
62
32142D–06/2013
ATUC64/128/256L3/4U
7.7.14 Interrupt Disable Register
Name: IDR
Access Type: Write-only
Offset: 0x024 + n*0x040
Reset Value: 0x00000000
Writing a zero to a bit in this register has no effect.
Writing a one to a bit in this register will clear the corresponding bit in IMR.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
- - - - - TERR TRC RCZ
63
32142D–06/2013
ATUC64/128/256L3/4U
7.7.15 Interrupt Mask Register
Name: IMR
Access Type: Read-only
Offset: 0x028 + n*0x040
Reset Value: 0x00000000
0: The corresponding interrupt is disabled.
1: The corresponding interrupt is enabled.
A bit in this register is cleared when the corresponding bit in IDR is written to one.
A bit in this register is set when the corresponding bit in IER is written to one.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
- - - - - TERR TRC RCZ
64
32142D–06/2013
ATUC64/128/256L3/4U
7.7.16 Interrupt Status Register
Name: ISR
Access Type: Read-only
Offset: 0x02C + n*0x040
Reset Value: 0x00000000
• TERR: Transfer Error
This bit is cleared when no transfer errors have occurred since the last write to CR.ECLR.
This bit is set when one or more transfer errors has occurred since reset or the last write to CR.ECLR.
• TRC: Transfer Complete
This bit is cleared when the TCR and/or the TCRR holds a non-zero value.
This bit is set when both the TCR and the TCRR are zero.
• RCZ: Reload Counter Zero
This bit is cleared when the TCRR holds a non-zero value.
This bit is set when TCRR is zero.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
- - - - - TERR TRC RCZ
65
32142D–06/2013
ATUC64/128/256L3/4U
7.7.17 Performance Control Register
Name: PCONTROL
Access Type: Read/Write
Offset: 0x800
Reset Value: 0x00000000
• MON1CH: Performance Monitor Channel 1
• MON0CH: Performance Monitor Channel 0
The PDCA channel number to monitor with counter n
Due to performance monitor hardware resource sharing, the two performance monitor channels should NOT be programmed to
monitor the same PDCA channel. This may result in UNDEFINED monitor behavior.
• CH1RES: Performance Channel 1 Counter Reset
Writing a zero to this bit has no effect.
Writing a one to this bit will reset the counter in the channel specified in MON1CH.
This bit always reads as zero.
• CH0RES: Performance Channel 0 Counter Reset
Writing a zero to this bit has no effect.
Writing a one to this bit will reset the counter in the channel specified in MON0CH.
This bit always reads as zero.
• CH1OF: Channel 1 Overflow Freeze
0: The performance channel registers are reset if DATA or STALL overflows.
1: All performance channel registers are frozen just before DATA or STALL overflows.
• CH1OF: Channel 0 Overflow Freeze
0: The performance channel registers are reset if DATA or STALL overflows.
1: All performance channel registers are frozen just before DATA or STALL overflows.
• CH1EN: Performance Channel 1 Enable
0: Performance channel 1 is disabled.
1: Performance channel 1 is enabled.
• CH0EN: Performance Channel 0 Enable
0: Performance channel 0 is disabled.
1: Performance channel 0 is enabled.
31 30 29 28 27 26 25 24
- - MON1CH
23 22 21 20 19 18 17 16
- - MON0CH
15 14 13 12 11 10 9 8
- - - - - - CH1RES CH0RES
76543210
- - CH1OF CH0OF - - CH1EN CH0EN
66
32142D–06/2013
ATUC64/128/256L3/4U
7.7.18 Performance Channel 0 Read Data Cycles
Name: PRDATA0
Access Type: Read-only
Offset: 0x804
Reset Value: 0x00000000
• DATA: Data Cycles Counted Since Last Reset
Clock cycles are counted using the CLK_PDCA_HSB clock
31 30 29 28 27 26 25 24
DATA[31:24]
23 22 21 20 19 18 17 16
DATA[23:16]
15 14 13 12 11 10 9 8
DATA[15:8]
76543210
DATA[7:0]
67
32142D–06/2013
ATUC64/128/256L3/4U
7.7.19 Performance Channel 0 Read Stall Cycles
Name: PRSTALL0
Access Type: Read-only
Offset: 0x808
Reset Value: 0x00000000
• STALL: Stall Cycles Counted Since Last Reset
Clock cycles are counted using the CLK_PDCA_HSB clock
31 30 29 28 27 26 25 24
STALL[31:24]
23 22 21 20 19 18 17 16
STALL[23:16]
15 14 13 12 11 10 9 8
STALL[15:8]
76543210
STALL[7:0]
68
32142D–06/2013
ATUC64/128/256L3/4U
7.7.20 Performance Channel 0 Read Max Latency
Name: PRLAT0
Access Type: Read/Write
Offset: 0x80C
Reset Value: 0x00000000
• LAT: Maximum Transfer Initiation Cycles Counted Since Last Reset
Clock cycles are counted using the CLK_PDCA_HSB clock
This counter is saturating. The register is reset only when PCONTROL.CH0RES is written to one.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
LAT[15:8]
76543210
LAT[7:0]
69
32142D–06/2013
ATUC64/128/256L3/4U
7.7.21 Performance Channel 0 Write Data Cycles
Name: PWDATA0
Access Type: Read-only
Offset: 0x810
Reset Value: 0x00000000
• DATA: Data Cycles Counted Since Last Reset
Clock cycles are counted using the CLK_PDCA_HSB clock
31 30 29 28 27 26 25 24
DATA[31:24]
23 22 21 20 19 18 17 16
DATA[23:16]
15 14 13 12 11 10 9 8
DATA[15:8]
76543210
DATA[7:0]
70
32142D–06/2013
ATUC64/128/256L3/4U
7.7.22 Performance Channel 0 Write Stall Cycles
Name: PWSTALL0
Access Type: Read-only
Offset: 0x814
Reset Value: 0x00000000
• STALL: Stall Cycles Counted Since Last Reset
Clock cycles are counted using the CLK_PDCA_HSB clock
31 30 29 28 27 26 25 24
STALL[31:24]
23 22 21 20 19 18 17 16
STALL[23:16]
15 14 13 12 11 10 9 8
STALL[15:8]
76543210
STALL[7:0]
71
32142D–06/2013
ATUC64/128/256L3/4U
7.7.23 Performance Channel 0 Write Max Latency
Name: PWLAT0
Access Type: Read/Write
Offset: 0x818
Reset Value: 0x00000000
• LAT: Maximum Transfer Initiation Cycles Counted Since Last Reset
Clock cycles are counted using the CLK_PDCA_HSB clock
This counter is saturating. The register is reset only when PCONTROL.CH0RES is written to one.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
LAT[15:8]
76543210
LAT[7:0]
72
32142D–06/2013
ATUC64/128/256L3/4U
7.7.24 Performance Channel 1 Read Data Cycles
Name: PRDATA1
Access Type: Read-only
Offset: 0x81C
Reset Value: 0x00000000
• DATA: Data Cycles Counted Since Last Reset
Clock cycles are counted using the CLK_PDCA_HSB clock
31 30 29 28 27 26 25 24
DATA[31:24]
23 22 21 20 19 18 17 16
DATA[23:16]
15 14 13 12 11 10 9 8
DATA[15:8]
76543210
DATA[7:0]
73
32142D–06/2013
ATUC64/128/256L3/4U
7.7.25 Performance Channel 1 Read Stall Cycles
Name: PRSTALL1
Access Type: Read-only
Offset: 0x820
Reset Value: 0x00000000
• STALL: Stall Cycles Counted Since Last Reset
Clock cycles are counted using the CLK_PDCA_HSB clock
31 30 29 28 27 26 25 24
STALL[31:24]
23 22 21 20 19 18 17 16
STALL[23:16]
15 14 13 12 11 10 9 8
STALL[15:8]
76543210
STALL[7:0]
74
32142D–06/2013
ATUC64/128/256L3/4U
7.7.26 Performance Channel 1 Read Max Latency
Name: PRLAT1
Access Type: Read/Write
Offset: 0x824
Reset Value: 0x00000000
• LAT: Maximum Transfer Initiation Cycles Counted Since Last Reset
Clock cycles are counted using the CLK_PDCA_HSB clock
This counter is saturating. The register is reset only when PCONTROL.CH1RES is written to one.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
LAT[15:8]
76543210
LAT[7:0]
75
32142D–06/2013
ATUC64/128/256L3/4U
7.7.27 Performance Channel 1 Write Data Cycles
Name: PWDATA1
Access Type: Read-only
Offset: 0x828
Reset Value: 0x00000000
• DATA: Data Cycles Counted Since Last Reset
Clock cycles are counted using the CLK_PDCA_HSB clock
31 30 29 28 27 26 25 24
DATA[31:24]
23 22 21 20 19 18 17 16
DATA[23:16]
15 14 13 12 11 10 9 8
DATA[15:8]
76543210
DATA[7:0]
76
32142D–06/2013
ATUC64/128/256L3/4U
7.7.28 Performance Channel 1 Write Stall Cycles
Name: PWSTALL1
Access Type: Read-only
Offset: 0x82C
Reset Value: 0x00000000
• STALL: Stall Cycles Counted Since Last Reset
Clock cycles are counted using the CLK_PDCA_HSB clock
31 30 29 28 27 26 25 24
STALL[31:24]
23 22 21 20 19 18 17 16
STALL[23:16]
15 14 13 12 11 10 9 8
STALL[15:8]
76543210
STALL[7:0]
77
32142D–06/2013
ATUC64/128/256L3/4U
7.7.29 Performance Channel 1 Write Max Latency
Name: PWLAT1
Access Type: Read/Write
Offset: 0x830
Reset Value: 0x00000000
• LAT: Maximum Transfer Initiation Cycles Counted Since Last Reset
Clock cycles are counted using the CLK_PDCA_HSB clock
This counter is saturating. The register is reset only when PCONTROL.CH1RES is written to one.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
LAT[15:8]
76543210
LAT[7:0]
78
32142D–06/2013
ATUC64/128/256L3/4U
7.7.30 PDCA Version Register
Name: VERSION
Access Type: Read-only
Offset: 0x834
Reset Value: -
• VARIANT: Variant Number
Reserved. No functionality associated.
• VERSION: Version Number
Version number of the module. No functionality associated.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
- - - - VARIANT
15 14 13 12 11 10 9 8
- - - - VERSION[11:8]
76543210
VERSION[7:0]
79
32142D–06/2013
ATUC64/128/256L3/4U
7.8 Module Configuration
The specific configuration for each PDCA instance is listed in the following tables.The module
bus clocks listed here are connected to the system bus clocks. Please refer to the Power Manager
chapter for details.
The PDCA and the peripheral modules communicate through a set of handshake signals. The
following table defines the valid settings for the Peripheral Identifier (PID) in the PDCA Peripheral
Select Register (PSR). The direction is specified as observed from the memory, so RX
means transfers from peripheral to memory, and TX means from memory to peripheral.
Table 7-6. PDCA Configuration
Feature PDCA
Number of channels 12
Number of performance monitors 1
Table 7-7. PDCA Clocks
Clock Name Description
CLK_PDCA_HSB Clock for the PDCA HSB interface
CLK_PDCA_PB Clock for the PDCA PB interface
Table 7-8. Register Reset Values
Register Reset Value
PSR CH 0 0
PSR CH 1 1
PSR CH 2 2
PSR CH 3 3
PSR CH 4 4
PSR CH 5 5
PSR CH 6 6
PSR CH 7 7
PSR CH 8 8
PSR CH 9 9
PSR CH 10 10
PSR CH 11 11
VERSION 123
Table 7-9. Peripheral Identity Values
PID Direction Peripheral Instance Peripheral Register
0 RX USART0 RHR
1 RX USART1 RHR
2 RX USART2 RHR
80
32142D–06/2013
ATUC64/128/256L3/4U
3 RX USART3 RHR
4 RX SPI RDR
5 RX TWIM0 RHR
6 RX TWIM1 RHR
7 RX TWIS0 RHR
8 RX TWIS1 RHR
9 RX ADCIFB LCDR
10 RX AW RHR
11 RX CAT ACOUNT
12 TX USART0 THR
13 TX USART1 THR
14 TX USART2 THR
15 TX USART3 THR
16 TX SPI TDR
17 TX TWIM0 THR
18 TX TWIM1 THR
19 TX TWIS0 THR
20 TX TWIS1 THR
21 TX AW THR
22 TX CAT MBLEN
23 TX ABDACB SDR0
24 TX ABDACB SDR1
25 RX IISC RHR (CH0)
26 RX IISC RHR (CH1)
27 TX IISC THR (CH0)
28 TX IISC THR (CH1)
29 RX CAT DMATSR
30 TX CAT DMATSW
Table 7-9. Peripheral Identity Values
PID Direction Peripheral Instance Peripheral Register
81
32142D–06/2013
ATUC64/128/256L3/4U
8. USB Interface (USBC)
Rev: 2.0.0.15
8.1 Features
• Compatible with the USB 2.0 specification
• Supports full (12Mbit/s) and low (1.5Mbit/s) speed communication
• Seven physical pipes/endpoints in ping-pong mode
• Flexible pipe/endpoint configuration and reallocation of data buffers in embedded RAM
• Up to two memory banks per pipe/endpoint
• Built-in DMA with multi-packet support through ping-pong mode
• On-chip transceivers with built-in pull-ups and pull-downs
8.2 Overview
The Universal Serial Bus interface (USBC) module complies with the Universal Serial Bus (USB)
2.0 specification.
Each pipe/endpoint can be configured into one of several transfer types. It can be associated
with one or more memory banks (located inside the embedded system or CPU RAM) used to
store the current data payload. If two banks are used (“ping-pong” mode), then one bank is read
or written by the CPU (or any other HSB master) while the other is read or written by the USBC
core.
Table 8-1 describes the hardware configuration of the USBC module.
8.3 Block Diagram
The USBC interfaces a USB link with a data flow stored in the embedded ram (CPU or HSB).
The USBC requires a 48MHz ± 0.25% reference clock, which is the USB generic clock. For
more details see ”Clocks” on page 84. The 48MHz clock is used to generate either a 12MHz fullspeed
or a 1.5MHz low-speed bit clock from the received USB differential data, and to transmit
data according to full- or low-speed USB device tolerances. Clock recovery is achieved by a digital
phase-locked loop (a DPLL, not represented) in the USBC module, which complies with the
USB jitter specifications.
The USBC module consists of:
• HSB master interface
Table 8-1. Description of USB pipes/endpoints
pipe/endpoint Mnemonic Max. size
Number of
available banks Type
0 PEP0 1023 bytes 1 Control/Isochronous/Bulk/Interrupt
1 PEP1 1023 bytes 2 Control/Isochronous/Bulk/Interrupt
2 PEP2 1023 bytes 2 Control/Isochronous/Bulk/Interrupt
... ... ... ... ...
6 PEP6 1023 bytes 2 Control/Isochronous/Bulk/Interrupt
82
32142D–06/2013
ATUC64/128/256L3/4U
• User interface
• USB Core
• Transceiver pads
Figure 8-1. USBC Block Diagram
Note: in the block diagram is symbolic, it is mapped to a GPIO pin (See Section “8.5.1” on page 84.).
The VBUS detection (rising edge detection on the GPIO pin) should be handled by software.
Interrupt
Controller
USB interrupts
DM
USB_VBUS (1)
USB
DP
User interface
SCIF GCLK_USBC @ 48 MHz
PB
USB 2.0
Core
USB clock
domain
System clock
domain
HSB
HSB Master
83
32142D–06/2013
ATUC64/128/256L3/4U
8.4 I/O Lines Description
Table 8-2. I/O Lines Description
PIn Name Pin Description Type Active Level
DM Data -: Differential Data Line - Port Input/Output
DP Data +: Differential Data Line + Port Input/Output
84
32142D–06/2013
ATUC64/128/256L3/4U
8.5 Product Dependencies
In order to use this module, other parts of the system must be configured correctly, as described
below.
8.5.1 I/O Lines
The USBC pins may be multiplexed with the I/O Controller lines. The user must first configure
the I/O Controller to assign the desired USBC pins to their peripheral functions.
The USB VBUS line should be connected to a GPIO pin and the user should monitor this with
software.
8.5.2 Power Management
If the CPU enters a sleep mode that disables clocks used by the USBC, the USBC will stop functioning
and resume operation after the system wakes up from sleep mode.
8.5.3 Clocks
The USBC has two bus clocks connected: One High Speed Bus clock (CLK_USBC_HSB) and
one Peripheral Bus clock (CLK_USBC_PB). These clocks are generated by the Power Manager.
Both clocks are enabled at reset, and can be disabled by the Power Manager. It is
recommended to disable the USBC before disabling the clocks, to avoid freezing the USBC in
an undefined state.
The 48MHz USB clock is generated by a dedicated generic clock from the SCIF module. Before
using the USB, the user must ensure that the USB generic clock (GCLK_USBC) is enabled at
48MHz in the SCIF module.
8.5.4 Interrupts
The USBC interrupt request line is connected to the interrupt controller. Using the USBC interrupt
requires the interrupt controller to be programmed first.
The USBC asynchronous interrupt can wake the CPU from any sleep mode:
• The Wakeup Interrupt (WAKEUP)
85
32142D–06/2013
ATUC64/128/256L3/4U
8.6 Functional Description
8.6.1 USB General Operation
8.6.1.1 Initialization
After a hardware reset, the USBC is in the Reset state. In this state:
• The module is disabled. The USBC Enable bit in the General Control register
(USBCON.USBE) is reset.
• The module clock is stopped in order to minimize power consumption. The Freeze USB Clock
bit in USBCON (USBCON.FRZCLK) is set.
• The USB pad is in suspend mode.
• The internal states and registers of the device are reset.
• The Freeze USB Clock (FRZCLK), USBC Enable (USBE), in USBCON and the Low-Speed
mode bit in the Device General Control register (UDCON.LS) can be written to by software,
so that the user can configure pads and speed before enabling the module. These values are
only taken into account once the module has been enabled and unfrozen.
After writing a one to USBCON.USBE, the USBC enters device mode in idle state.
Refer to Section 8.6.2 for the basic operation of the device mode.
The USBC can be disabled at any time by writing a zero to USBCON.USBE, this acts as a hardware
reset, except that the FRZCLK,bit in USBCON, and the LS bits in UDCON are not reset.
8.6.1.2 Interrupts
One interrupt vector is assigned to the USBC.
See Section 8.6.2.18 for further details about device interrupts.
See Section 8.5.4 for asynchronous interrupts.
8.6.1.3 Frozen clock
When the USB clock is frozen, it is still possible to access the following bits: FRZCLK, and USBE
in the USBCON register, and LS in the UDCON register.
When FRZCLK is set, only the asynchronous interrupt can trigger a USB interrupt (see Section
8.5.4).
8.6.1.4 Speed control
• Device mode
When the USBC interface is in device mode, the speed selection is done by the UDCON.LS bit,
connecting an internal pull-up resistor to either DP (full-speed mode) or DM (low-speed mode).
The LS bit shall be written before attaching the device, which can be simulated by clearing the
UDCON.DETACH bit.
86
32142D–06/2013
ATUC64/128/256L3/4U
Figure 8-2. Speed Selection in device mode
8.6.1.5 Data management
Endpoints and pipe buffers can be allocated anywhere in the embedded memory (CPU RAM or
HSB RAM).
See ”RAM management” on page 90.
8.6.1.6 Pad Suspend
Figure 8-3 illustrates the behavior of the USB pad in device mode.
Figure 8-3. Pad Behavior
• In Idle state, the pad is in low power consumption mode.
• In Active state, the pad is working.
Figure 8-4 illustrates the pad events leading to a PAD state change.
RPU
UDCON.DETACH
DP
DM
UDCON.LS
VBUS
Idle
Active
USBE = 1
& DETACH = 0
& Suspend
USBE = 0
| DETACH = 1
| Suspend
87
32142D–06/2013
ATUC64/128/256L3/4U
Figure 8-4. Pad events
The Suspend Interrupt bit in the Device Global Interrupt register (UDINT.SUSP) is set and the
Wakeup Interrupt (UDINT.WAKEUP) bit is cleared when a USB Suspend state has been
detected on the USB bus. This event automatically puts the USB pad in the Idle state. The
detection of a non-idle event sets WAKEUP, clears SUSP, and wakes the USB pad.
The pad goes to the Idle state if the module is disabled or if UDCON.DETACH is written to one.
It returns to the Active state when USBCON.USBE is written to one and DETACH is written to
zero.
SUSP Suspend detected Cleared on Wakeup
WAKEUP Wakeup detected Cleared by software to acknowledge the interrupt
PAD state
Active Idle Active
88
32142D–06/2013
ATUC64/128/256L3/4U
8.6.2 USBC Device Mode Operation
8.6.2.1 Device Enabling
In device mode, the USBC supports full- and low-speed data transfers.
Including the default control endpoint, a total of seven endpoints are provided. They can be configured
as isochronous, bulk or interrupt types, as described in Table 8-1 on page 81
After a hardware reset, the USBC device mode is in the reset state (see Section 8.6.1.1). In this
state, the endpoint banks are disabled and neither DP nor DM are pulled up (DETACH is one).
DP or DM will be pulled up according to the selected speed as soon as the DETACH bit is written
to zero. See “Device mode” for further details.
When the USBC is enabled (USBE is one) in device mode, it enters the Idle state, minimizing
power consumption. Being in Idle state does not require the USB clocks to be activated.
The USBC device mode can be disabled or reset at any time by disabling the USBC (by writing
a zero to USBE).
8.6.2.2 USB reset
The USB bus reset is initiated by a connected host and managed by hardware.
When a USB reset state is detected on the USB bus, the following operations are performed by
the controller:
• UDCON register is reset except for the DETACH and SPDCONF bits.
• Device Frame Number Register (UDFNUM), Endpoint n Configuration Register (UECFGn),
and Endpoint n Control Register (UECONn) registers are cleared.
• The data toggle sequencing in all the endpoints are cleared.
• At the end of the reset process, the End of Reset (EORST) bit in the UDINT register is set.
8.6.2.3 Endpoint activation
When an endpoint is disabled (UERST.EPENn = 0) the data toggle sequence, Endpoint n Status
Set (UESTAn), and UECONn registers will be reset. The controller ignores all transactions to
this endpoint as long as it is inactive.
To complete an endpoint activation, the user should fill out the endpoint descriptor: see Figure 8-
5 on page 91.
8.6.2.4 Data toggle sequence
In order to respond to a CLEAR_FEATURE USB request without disabling the endpoint, the
user can clear the data toggle sequence by writing a one to the Reset Data Toggle Set bit in the
Endpoint n Control Set register (UECONnSET.RSTDTS)
8.6.2.5 Busy bank enable
In order to make an endpoint bank look busy regardless of its actual state, the user can write a
one to the Busy Bank Enable bit in the Endpoint n Control Register (UECONnSET.BUSY0/1ES).
If a BUSYnE bit is set, any transaction to this bank will be rejected with a NAK reply.
8.6.2.6 Address setup
The USB device address is set up according to the USB protocol.
89
32142D–06/2013
ATUC64/128/256L3/4U
• After all kinds of resets, the USB device address is 0.
• The host starts a SETUP transaction with a SET_ADDRESS(addr) request.
• The user writes this address to the USB Address field (UDCON.UADD), and writes a zero to
the Address Enable bit (UDCON.ADDEN), resulting in the address remaining zero.
• The user sends a zero-length IN packet from the control endpoint.
• The user enables the stored USB device address by writing a one to ADDEN.
Once the USB device address is configured, the controller filters the packets to only accept
those targeting the address stored in UADD.
UADD and ADDEN should not be written to simultaneously. They should be written sequentially,
UADD field first.
If UADD or ADDEN is cleared, the default device address 0 is used. UADD and ADDEN are
cleared:
• On a hardware reset.
• When the USBC is disabled (USBE written to zero).
• When a USB reset is detected.
8.6.2.7 Suspend and Wakeup
When an idle USB bus state has been detected for 3 ms, the controller sets the Suspend
(SUSP) interrupt bit in UDINT. In this case, the transceiver is suspended, reducing power
consumption.
To further reduce power consumption it is recommended to freeze the USB clock by writing a
one to the Freeze USB Clock (FRZCLK) bit in USBCON when the USB bus is in suspend mode.
The MCU can also enter the idle or frozen sleep mode to further lower power consumption.
To recover from the suspend mode, the user shall wait for the Wakeup (WAKEUP) interrupt bit,
which is set when a non-idle event is detected, and then write a zero to FRZCLK.
As the WAKEUP interrupt bit in UDINT is set when a non-idle event is detected, it can occur
regardless of whether the controller is in the suspend mode or not. The SUSP and WAKEUP
interrupts are thus independent of each other except for that one bit is cleared when the other is
set.
8.6.2.8 Detach
The reset value of the DETACH bit located in the UDCON register, is one.
It is possible to initiate a device re-enumeration simply by writing a one and then a zero to
DETACH.
DETACH acts on the pull-up connections of the DP and DM pads. See “Device mode” for further
details.
8.6.2.9 Remote wakeup
The remote wakeup request (also known as upstream resume) is the only request the device
may send on its own initiative. This should be preceded by a DEVICE_REMOTE_WAKEUP
request from the host.
• First, the USBC must have detected a “Suspend” state on the bus, i.e. the remote wakeup
request can only be sent after a SUSP interrupt has been set.
90
32142D–06/2013
ATUC64/128/256L3/4U
• The user may then write a one to the remote wakeup (RMWKUP) bit in UDCON to send an
Upstream Resume to the host initiating the wakeup. This will automatically be done by the
controller after 5ms of inactivity on the USB bus.
• When the controller sends the Upstream Resume, the Upstream Resume (UPRSM) interrupt
is set and SUSP is cleared.
• RMWKUP is cleared at the end of the transmitting Upstream Resume.
• In case of a rebroadcast resume initiated by the host, the End of Resume (EORSM) interrupt
is set when the rebroadcast resume is completed.
8.6.2.10 RAM management
Endpoint data can be physically allocated anywhere in the embedded RAM. The USBC controller
accesses these endpoints directly through the HSB master (built-in DMA).
The USBC controller reads the USBC descriptors to know where each endpoint is located. The
base address of the USBC descriptor (UDESC.UDESCA) needs to be written by the user. The
descriptors can also be allocated anywhere in the embedded RAM.
Before using an endpoint, the user should setup the endpoint address for each bank. Depending
on the direction, the type, and the packet-mode (single or multi-packet), the user should also initialize
the endpoint packet size, and the endpoint control and status fields, so that the USBC
controller does not compute random values from the RAM.
When using an endpoint the user should read the UESTAX.CURRBK field to know which bank
is currently being processed.
91
32142D–06/2013
ATUC64/128/256L3/4U
Figure 8-5. Memory organization
Each descriptor of an endpoint n consists of four words.
• The address of the endpoint and the bank used (EPn_ADDR_BK0/1).
• The packet size information for the endpoint and bank (EPn_PCKSIZE_BK0/1):
Table 8-3. EPn_PCKSIZE_BK0/1 structure
– AUTO_ZLP: Auto zero length packet, see ”Multi packet mode for IN endpoints” on
page 96.
– MULTI_PACKET_SIZE: see ”Multi packet mode and single packet mode.” on page
93.
– BYTE_COUNT: see ”Multi packet mode and single packet mode.” on page 93.
31 30:16 15 14:0
AUTO_ZLP MULTI_PACKET_SIZE - BYTE_COUNT
EPn BK0
EP0_CTR_STA_BK0
E P 0 _ P C K S IZ E _ B K 0
EP0_ADDR_BK0 UDESCA
Growing Memory Addresses
Descriptor EP0
R e se rve d
EP0_CTR _STA_BK1
E P 0 _ P C K S IZ E _ B K 1
EP0_ADDR_BK1
R e se rve d
Bank0
Bank1
+0x000
+0x004
+0x008
+0x00C
+0x010
+0x014
+0x018
+0x01C
EP1_CTR_STA_BK0
E P 1 _ P C K S IZ E _ B K 0
EP1_ADDR_BK0
Descriptor EP1
R e se rve d
EP1_CTR _STA_BK1
E P 1 _ P C K S IZ E _ B K 1
EP1_ADDR_BK1
R e se rve d
Bank0
Bank1
+0x020
+0x024
+0x028
+0x02C
+0x030
+0x034
+0x038
+0x03C
EPn_CTR_STA_BK0
E P n _ P C K S IZ E _ B K 0
EPn_ADDR_BK0
R e se rve d
EPn_CTR _STA_BK1
E P n _ P C K S IZ E _ B K 1
EPn_ADDR_BK1
R e se rve d
Bank0
Bank1
Descriptor EPn
EPn BK1
U S B d e s c rip to rs
U S B B u ffe rs
92
32142D–06/2013
ATUC64/128/256L3/4U
• The control and status fields for the endpoint and bank (EPn_CTR_STA_BK0/1):
Table 8-4. EPn_CTR_STA_BK0/1 structure
– UNDERF: Underflow status for isochronous IN transfer. See ”Data flow error” on
page 99.
– OVERF: Overflow status for isochronous OUT transfer. See ”Data flow error” on
page 99.
– CRCERR: CRC error status for isochronous OUT transfer. See ”CRC error” on page
99.
– STALLRQ_NEXT: Stall request for the next transfer. See ”STALL request” on page
92.
8.6.2.11 STALL request
For each endpoint, the STALL management is performed using:
• The STALL Request (STALLRQ) bit in UECONn is set to initiate a STALL request.
• The STALLed Interrupt (STALLEDI) bit in UESTAn is set when a STALL handshake has been
sent.
To answer requests with a STALL handshake, STALLRQ has to be set by writing a one to the
STALL Request Set (STALLRQS) bit. All following requests will be discarded (RXOUTI, etc. will
not be set) and handshaked with a STALL until the STALLRQ bit is cleared, by receiving a new
SETUP packet (for control endpoints) or by writing a one to the STALL Request Clear (STALLRQC)
bit.
Each time a STALL handshake is sent, the STALLEDI bit is set by the USBC and the EPnINT
interrupt is set.
The user can use the descriptor to manage STALL requests. The USBC controller reads the
EPn_CTR_STA_BK0/1.STALLRQ_NEXT bit after successful transactions and if it is one the
USBC controller will set UECON.STALLRQ. The STALL_NEXT bit will be cleared upon receiving
a SETUP transaction and the USBC controller will then clear the STALLRQ bit.
• Special considerations for control endpoints
If a SETUP packet is received at a control endpoint where a STALL request is active, the
Received SETUP Interrupt (RXSTPI) bit in UESTAn is set, and the STALLRQ and STALLEDI
bits are cleared. It allows the SETUP to be always ACKed as required by the USB standard.
This management simplifies the enumeration process management. If a command is not supported
or contains an error, the user requests a STALL and can return to the main task, waiting
for the next SETUP request.
• STALL handshake and retry mechanism
The retry mechanism has priority over the STALL handshake. A STALL handshake is sent if the
STALLRQ bit is set and if there is no retry required.
31:19 18 17 16 15:1 0
Status elements Control elements
- UNDERF OVERF CRCERR - STALLRQ_NEXT
93
32142D–06/2013
ATUC64/128/256L3/4U
8.6.2.12 Multi packet mode and single packet mode.
Single packet mode is the default mode where one USB packet is managed per bank.
The multi-packet mode allows the user to manage data exceeding the maximum endpoint size
(UECFGn.EPSIZE) for an endpoint bank across multiple packets without software intervention.
This mode can also be coupled with the ping-pong mode.
• For an OUT endpoint, the EPn_PCKSIZE_BK0/1.MULTI_PACKET_SIZE field should be
configured correctly to enable the multi-packet mode. See ”Multi packet mode for OUT
endpoints” on page 98. For single packet mode, the MULTI_PACKET_SIZE should be
initialized to 0.
• For an IN endpoint, the EPn_PCKSIZE_BK0/1.BYTE_COUNT field should be configured
correctly to enable the multi-packet mode. See”Multi packet mode for IN endpoints” on page
96. For single packet mode, the BYTE_COUNT should be less than EPSIZE.
8.6.2.13 Management of control endpoints
• Overview
A SETUP request is always ACKed. When a new SETUP packet is received, the RXSTPI is set,
but not the Received OUT Data Interrupt (RXOUTI) bit.
The FIFO Control (FIFOCON) bit in UECONn is irrelevant for control endpoints. The user should
therefore never use it for these endpoints. When read, this value is always zero.
Control endpoints are managed using:
• The RXSTPI bit: is set when a new SETUP packet is received. This has to be cleared by
firmware in order to acknowledge the packet and to free the bank.
• The RXOUTI bit: is set when a new OUT packet is received. This has to be cleared by
firmware in order to acknowledge the packet and to free the bank.
• The Transmitted IN Data Interrupt (TXINI) bit: is set when the current bank is ready to accept
a new IN packet. This has to be cleared by firmware in order to send the packet.
• Control write
Figure 8-6 on page 94 shows a control write transaction. During the status stage, the controller
will not necessarily send a NAK on the first IN token:
• If the user knows the exact number of descriptor bytes that will be read, the status stage can
be predicted, and a zero-length packet can be sent after the next IN token.
• Alternatively the bytes can be read until the NAKed IN Interrupt (NAKINI) is triggered,
notifying that all bytes are sent by the host and that the transaction is now in the status stage.
94
32142D–06/2013
ATUC64/128/256L3/4U
Figure 8-6. Control Write
• Control read
Figure 8-7 on page 94 shows a control read transaction. The USBC has to manage the simultaneous
write requests from the CPU and USB host.
Figure 8-7. Control Read
A NAK handshake is always generated as the first status stage command. The UESTAn.NAKINI
bit is set. It allows the user to know that the host aborts the IN data stage. As a consequence,
the user should stop processing the IN data stage and should prepare to receive the OUT status
stage by checking the UESTAn.RXOUTI bit.
The OUT retry is always ACKed. This OUT reception sets RXOUTI. Handle this with the following
software algorithm:
// process the IN data stage
set TXINI
wait for RXOUTI (rising) OR TXINI (falling)
if RXOUTI is high, then process the OUT status stage
if TXINI is low, then return to process the IN data stage
Once the OUT status stage has been received, the USBC waits for a SETUP request. The
SETUP request has priority over all other requests and will be ACKed.
SETUP
RXSTPI
RXOUTI
TXINI
USB Bus
HW SW
OUT
HW SW
OUT
HW SW
IN IN
NAK
SW
SETUP STATUS DATA
SETUP
RXSTPI
RXOUTI
TXINI
USB Bus
HW SW
IN
HW SW
IN OUT OUT
NAK
SW
SW
HW
Wr Enable
HOST
Wr Enable
CPU
SETUP STATUS DATA
95
32142D–06/2013
ATUC64/128/256L3/4U
8.6.2.14 Management of IN endpoints
• Overview
IN packets are sent by the USBC device controller upon IN requests from the host.
The endpoint and its descriptor in RAM must be pre configured (see section ”RAM management”
on page 90 for more details).
When the current bank is clear, the TXINI and FIFO Control (UECONn.FIFOCON) bits will be set
simultaneously. This triggers an EPnINT interrupt if the Transmitted IN Data Interrupt Enable
(TXINE) bit in UECONn is one.
TXINI shall be cleared by software (by writing a one to the Transmitted IN Data Interrupt Enable
Clear bit in the Endpoint n Control Clear register (UECONnCLR.TXINIC)) to acknowledge the
interrupt. This has no effect on the endpoint FIFO.
The user writes the IN data to the bank referenced by the EPn descriptor and allows the USBC
to send the data by writing a one to the FIFO Control Clear (UECONnCLR.FIFOCONC) bit. This
will also cause a switch to the next bank if the IN endpoint is composed of multiple banks. The
TXINI and FIFOCON bits will be updated accordingly.
TXINI should always be cleared before clearing FIFOCON to avoid missing an TXINI event.
Figure 8-8. Example of an IN endpoint with one data bank
Figure 8-9. Example of an IN endpoint with two data banks
IN DATA
(bank 0) ACK
TXINI
FIFOCON
HW
write data to CPU
BANK 0
SW
SW SW
SW
IN
NAK
write data to CPU
BANK 0
IN DATA
(bank 0) ACK
TXINI
FIFOCON write data to CPU
BANK 0
SW
SW SW
SW
IN DATA
(bank 1) ACK
write data to CPU
BANK 1
SW
HW
write data to CPU
BANK0
96
32142D–06/2013
ATUC64/128/256L3/4U
• Detailed description
The data is written according to this sequence:
• When the bank is empty, TXINI and FIFOCON are set, which triggers an EPnINT interrupt if
TXINE is one.
• The user acknowledges the interrupt by clearing TXINI.
• The user reads the UESTAX.CURRBK field to see which the current bank is.
• The user writes the data to the current bank, located in RAM as described by its descriptor:
EPn_ADDR_BK0/1.
• The user should write the size of the IN packet into the USB descriptor:
EPn_PCKSIZE_BK0/1.BYTE_COUNT.
• The user allows the controller to send the bank contents and switches to the next bank (if
any) by clearing FIFOCON.
If the endpoint uses several banks, the current one can be written while the previous one is
being read by the host. When the user clears FIFOCON, the next current bank may already be
clear and TXINI is set immediately.
An “Abort” stage can be produced when a zero-length OUT packet is received during an IN
stage of a control or isochronous IN transaction. The Kill IN Bank (KILLBK) bit in UECONn is
used to kill the last written bank. The best way to manage this abort is to apply the algorithm represented
on Figure 8-10 on page 96. See ”Endpoint n Control Register” on page 130 for more
details about the KILLBK bit.
Figure 8-10. Abort Algorithm
• Multi packet mode for IN endpoints
In multi packet mode, the user can prepare n USB packets in the bank to be sent on a multiple
IN transaction. The packet sizes will equal UECFGn.EPSIZE unless the AUTO_ZLP option is
Endpoint
Abort
Abort Done
Abort is based on the fact
that no bank is busy, i.e.,
that nothing has to be sent
Disable the TXINI interrupt.
EPRSTn = 1
NBUSYBK
== 0?
Yes
TXINEC = 1
No
KILLBKS = 1
KILLBK
Yes == 1?
Kill the last written bank.
Wait for the end of the
procedure
No
97
32142D–06/2013
ATUC64/128/256L3/4U
set, or if the total byte count is not an integral multiple of EPSIZE, whereby the last packet
should be short.
To enable the multi packet mode, the user should configure the endpoint descriptor
(EPn_PCKSIZE_BK0/1.BYTE_COUNT) to the total size of the multi packet, which should be
larger than the endpoint size (EPSIZE).
Since the EPn_PCKSIZE_BK0/1.MULTI_PACKET_SIZE is incremented (by the transmitted
packet size) after each successful transaction, it should be set to zero when setting up a new
multi packet transfer.
The EPn_PCKSIZE_BK0/1.MULTI_PACKET_SIZE is cleared by hardware when all the bank
contents have been sent. The bank is considered as ready and the TX_IN flag is set when:
• A short packet (smaller than EPSIZE) has been transmitted.
• A packet has been successfully transmitted, the updated MULTI_PACKET_SIZE equals the
BYTE_COUNT, and the AUTO_ZLP field is not set.
• An extra zero length packet has been automatically sent for the last transfer of the current
bank, if BYTE_COUNT is a multiple of EPSIZE and AUTO_ZLP is set.
8.6.2.15 Management of OUT endpoints
• Overview
The endpoint and its descriptor in RAM must be pre configured, see section ”RAM management”
on page 90 for more details.
When the current bank is full, the RXOUTI and FIFO Control (UECONn.FIFOCON) bits will be
set simultaneously. This triggers an EPnINT interrupt if the Received OUT Data Interrupt Enable
(RXOUTE) bit in UECONn is one.
RXOUTI shall be cleared by software (by writing a one to the Received OUT Data Interrupt Clear
(RXOUTIC) bit) to acknowledge the interrupt. This has no effect on the endpoint FIFO.
The user reads the OUT data from the RAM and clears the FIFOCON bit to free the bank. This
will also cause a switch to the next bank if the OUT endpoint is composed of multiple banks.
RXOUTI should always be cleared before clearing FIFOCON to avoid missing an RXOUTI
event.
Figure 8-11. Example of an OUT endpoint with one data bank
OUT DATA
(bank 0) ACK
RXOUTI
FIFOCON
HW
OUT DATA
(bank 0) ACK
HW
SW
SW
SW
read data from CPU
BANK 0
read data from CPU
BANK 0
NAK
98
32142D–06/2013
ATUC64/128/256L3/4U
Figure 8-12. Example of an OUT endpoint with two data banks
• Detailed description
Before using the OUT endpoint, one should properly initialize its descriptor for each bank. See
Figure 8-5 on page 91.
The data is read, according to this sequence:
• When the bank is full, RXOUTI and FIFOCON are set, which triggers an EPnINT interrupt if
RXOUTE is one.
• The user acknowledges the interrupt by writing a one to RXOUTIC in order to clear RXOUTI.
• The user reads the UESTAX.CURRBK field to know the current bank number.
• The user reads the byte count of the current bank from the descriptor in RAM
(EPn_PCKSIZE_BK0/1.BYTE_COUNT) to know how many bytes to read.
• The user reads the data in the current bank, located in RAM as described by its descriptor:
EPn_ADDR_BK0/1.
• The user frees the bank and switches to the next bank (if any) by clearing FIFOCON.
If the endpoint uses several banks, the current one can be read while the next is being written by
the host. When the user clears FIFOCON, the following bank may already be ready and RXOUTI
will be immediately set.
• Multi packet mode for OUT endpoints
In multi packet mode, the user can extend the size of the bank allowing the storage of n USB
packets in the bank.
To enable the multi packet mode, the user should configure the endpoint descriptor
(EPn_PCKSIZE_BK0/1.MULTI_PACKET_SIZE) to match the size of the multi packet.This value
should be a multiple of the endpoint size (UECFGn.EPSIZE).
Since the EPn_PCKSIZE_BK0/1.BYTE_COUNT is incremented (by the received packet size)
after each successful transaction, it should be set to zero when setting up a new multi packet
transfer.
As for single packet mode, the number of received data bytes is stored in the BYTE_CNT field.
The bank is considered as “valid” and the RX_OUT flag is set when:
OUT DATA
(bank 0)
ACK
RXOUTI
FIFOCON
HW
OUT DATA
(bank 1) ACK
SW
read data from CPU SW
BANK 0
HW
SW
read data from CPU
BANK 1
99
32142D–06/2013
ATUC64/128/256L3/4U
• A packet has been successfully received and the updated BYTE_COUNT equals the
MULTI_PACKET_SIZE.
• A short packet (smaller than EPSIZE) has been received.
8.6.2.16 Data flow error
This error exists only for isochronous IN/OUT endpoints. It sets the Errorflow Interrupt
(ERRORFI) bit in UESTAn, which triggers an EPnINT interrupt if the Errorflow Interrupt Enable
(ERRORFE) bit is one. The user can check the EPn_CTR_STA_BK0/1.UNDERF and OVERF
bits in the endpoint descriptor to see which current bank has been affected.
• An underflow can occur during IN stage if the host attempts to read from an empty bank. A
zero-length packet is then automatically sent by the USBC. The endpoint descriptor
EPn_CTR_STA_BK0/1.UNDERF points out the bank from which the IN data should have
originated. If a new successful transaction occurs, the UNDERF bit is overwritten to 0 only if
the UESTAn.ERRORFI is cleared.
• An overflow can occur during the OUT stage if the host tries to send a packet while the bank
is full. Typically this occurs when a CPU is not fast enough. The packet data is not written to
the bank and is lost. The endpoint descriptor EPn_CTR_STA_BK0/1.OVERF points out
which bank the OUT data was destined to. If the UESTAn.ERRORFI bit is cleared and a new
transaction is successful, the OVERF bit will be overwritten to zero.
8.6.2.17 CRC error
This error exists only for isochronous OUT endpoints. It sets the CRC Error Interrupt (CRCERRI)
bit in UESTAn, which triggers an EPnINT interrupt if the CRC Error Interrupt Enable
(CRCERRE) bit is one.
A CRC error can occur during an isochronous OUT stage if the USBC detects a corrupted
received packet. The OUT packet is stored in the bank as if no CRC error had occurred
(RXOUTI is set).
The user can also check the endpoint descriptor to see which current bank is impacted by the
CRC error by reading EPn_CTR_STA_BK0/1.CRCERR.
8.6.2.18 Interrupts
There are two kinds of device interrupts: processing, i.e. their generation is part of the normal
processing, and exception, i.e. errors not related to CPU exceptions.
• Global interrupts
The processing device global interrupts are:
• The Suspend (SUSP) interrupt
• The Start of Frame (SOF) interrupt with no frame number CRC error (the Frame Number
CRC Error (FNCERR) bit in the Device Frame Number (UDFNUM) register is zero)
• The End of Reset (EORST) interrupt
• The Wakeup (WAKEUP) interrupt
• The End of Resume (EORSM) interrupt
• The Upstream Resume (UPRSM) interrupt
• The Endpoint n (EPnINT) interrupt
The exception device global interrupts are:
100
32142D–06/2013
ATUC64/128/256L3/4U
• The Start of Frame (SOF) interrupt with a frame number CRC error (FNCERR is one)
• Endpoint interrupts
The processing device endpoint interrupts are:
• The Transmitted IN Data Interrupt (TXINI)
• The Received OUT Data Interrupt (RXOUTI)
• The Received SETUP Interrupt (RXSTPI)
• The Number of Busy Banks (NBUSYBK) interrupt
The exception device endpoint interrupts are:
• The Errorflow Interrupt (ERRORFI)
• The NAKed OUT Interrupt (NAKOUTI)
• The NAKed IN Interrupt (NAKINI)
• The STALLed Interrupt (STALLEDI)
• The CRC Error Interrupt (CRCERRI)
101
32142D–06/2013
ATUC64/128/256L3/4U
8.7 User Interface
Note: 1. The reset values are device specific. Please refer to the Module Configuration section at the end of this chapter.
Table 8-5. USBC Register Memory Map
Offset Register Name Access Reset Value
0x0000 Device General Control Register UDCON Read/Write 0x00000100
0x0004 Device Global Interrupt Register UDINT Read-Only 0x00000000
0x0008 Device Global Interrupt Clear Register UDINTCLR Write-Only 0x00000000
0x000C Device Global Interrupt Set Register UDINTSET Write-Only 0x00000000
0x0010 Device Global Interrupt Enable Register UDINTE Read-Only 0x00000000
0x0014 Device Global Interrupt Enable Clear Register UDINTECLR Write-Only 0x00000000
0x0018 Device Global Interrupt Enable Set Register UDINTESET Write-Only 0x00000000
0x001C Endpoint Enable/Reset Register UERST Read/Write 0x00000000
0x0020 Device Frame Number Register UDFNUM Read-Only 0x00000000
0x0100 + n*4 Endpoint n Configuration Register UECFGn Read/Write 0x00000000
0x0130 + n*4 Endpoint n Status Register UESTAn Read-Only 0x00000100
0x0160 + n*4 Endpoint n Status Clear Register UESTAnCLR Write-Only 0x00000000
0x0190 + n*4 Endpoint n Status Set Register UESTAnSET Write-Only 0x00000000
0x01C0 + n*4 Endpoint n Control Register UECONn Read-Only 0x00000000
0x01F0 + n*4 Endpoint n Control Set Register UECONnSET Write-Only 0x00000000
0x0220 + n*4 Endpoint n Control Clear Register UECONnCLR Write-Only 0x00000000
0x0800 General Control Register USBCON Read/Write 0x00004000
0x0804 General Status Register USBSTA Read-Only 0x00000000
0x0808 General Status Clear Register USBSTACLR Write-Only 0x00000000
0x080C General Status Set Register USBSTASET Write-Only 0x00000000
0x0818 IP Version Register UVERS Read-Only -(1)
0x081C IP Features Register UFEATURES Read-Only -(1)
0x0820 IP PB Address Size Register UADDRSIZE Read-Only -(1)
0x0824 IP Name Register 1 UNAME1 Read-Only -(1)
0x0828 IP Name Register 2 UNAME2 Read-Only -(1)
0x082C USB Finite State Machine Status Register USBFSM Read-Only 0x00000009
0x0830 USB Descriptor address UDESC Read/Write 0x00000000
102
32142D–06/2013
ATUC64/128/256L3/4U
8.7.1 USB General Registers
8.7.1.1 General Control Register
Name: USBCON
Access Type: Read/Write
Offset: 0x0800
Reset Value: 0x00004000
• USBE: USBC Enable
Writing a zero to this bit will disable the USBC, USB transceiver, and USB clock inputs. This will over-ride FRZCLK settings but
not affect the value. Unless explicitly stated, all registers will become reset and read-only.
Writing a one to this bit will enable the USBC.
0: The USBC is disabled.
1: The USBC is enabled.
This bit can be written to even if FRZCLK is one.
• FRZCLK: Freeze USB Clock
Writing a zero to this bit will enable USB clock inputs.
Writing a one to this bit will disable USB clock inputs. The resume detection will remain active. Unless explicitly stated, all
registers will become read-only.
0: The clock inputs are enabled.
1: The clock inputs are disabled.
This bit can be written to even if USBE is zero.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
-- - -- -
15 14 13 12 11 10 9 8
USBE FRZCLK - - - - - -
76543210
--------
103
32142D–06/2013
ATUC64/128/256L3/4U
8.7.1.2 General Status Register
Register Name: USBSTA
Access Type: Read-Only
Offset: 0x0804
Reset Value: 0x00000000
• CLKUSABLE: Generic Clock Usable
This bit is cleared when the USB generic clock is not usable.
This bit is set when the USB generic clock (that should be 48 Mhz) is usable.
• SPEED: Speed Status
This field is set according to the controller speed mode.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
- CLKUSABLE SPEED - - - -
76543210
--------
SPEED Speed Status
00 full-speed mode
01 Reserved
10 low-speed mode
11 Reserved
104
32142D–06/2013
ATUC64/128/256L3/4U
8.7.1.3 General Status Clear Register
Register Name: USBSTACLR
Access Type: Write-Only
Offset: 0x0808
Reset Value: 0x00000000
Writing a zero to a bit in this register has no effect.
Writing a one to a bit in this register will clear the corresponding bit in USBSTA.
These bits always read as zero.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
--------
105
32142D–06/2013
ATUC64/128/256L3/4U
8.7.1.4 General Status Set Register
Register Name: USBSTASET
Access Type: Write-Only
Offset: 0x080C
Reset Value: 0x00000000
Writing a zero to a bit in this register has no effect.
Writing a one to a bit in this register will set the corresponding bit in USBSTA.
These bits always read as zero.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
--------
106
32142D–06/2013
ATUC64/128/256L3/4U
8.7.1.5 Version Register
Register Name: UVERS
Access Type: Read-Only
Offset: 0x0818
Reset Value: -
• VARIANT: Variant Number
Reserved. No functionality associated.
• VERSION: Version Number
Version number of the module. No functionality associated.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
- - - - VARIANT
15 14 13 12 11 10 9 8
- - - - VERSION[11:8]
76543210
VERSION[7:0]
107
32142D–06/2013
ATUC64/128/256L3/4U
8.7.1.6 Features Register
Register Name: UFEATURES
Access Type: Read-Only
Offset: 0x081C
Reset Value: -
• EPTNBRMAX: Maximal Number of pipes/endpoints
This field indicates the number of hardware-implemented pipes/endpoints:
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
- - - - EPTNBRMAX
108
32142D–06/2013
ATUC64/128/256L3/4U
8.7.1.7 Address Size Register
Register Name: UADDRSIZE
Access Type: Read-Only
Offset: 0x0820
Reset Value: -
• UADDRSIZE: IP PB Address Size
This field indicates the size of the PB address space reserved for the USBC IP interface.
31 30 29 28 27 26 25 24
UADDRSIZE[31:24]
23 22 21 20 19 18 17 16
UADDRSIZE[23:16]
15 14 13 12 11 10 9 8
UADDRSIZE[15:8]
76543210
UADDRSIZE[7:0]
109
32142D–06/2013
ATUC64/128/256L3/4U
8.7.1.8 IP Name Register 1
Register Name: UNAME1
Access Type: Read-Only
Offset: 0x0824
Reset Value: -
• UNAME1: IP Name Part One
This field indicates the first part of the ASCII-encoded name of the USBC IP.
31 30 29 28 27 26 25 24
UNAME1[31:24]
23 22 21 20 19 18 17 16
UNAME1[23:16]
15 14 13 12 11 10 9 8
UNAME1[15:8]
76543210
UNAME1[7:0]
110
32142D–06/2013
ATUC64/128/256L3/4U
8.7.1.9 IP Name Register 2
Register Name: UNAME2
Access Type: Read-Only
Offset: 0x0828
Reset Value:
• UNAME2: IP Name Part Two
This field indicates the second part of the ASCII-encoded name of the USBC IP.
31 30 29 28 27 26 25 24
UNAME2[31:24]
23 22 21 20 19 18 17 16
UNAME2[23:16]
15 14 13 12 11 10 9 8
UNAME2[15:8]
76543210
UNAME2[7:0]
111
32142D–06/2013
ATUC64/128/256L3/4U
8.7.1.10 Finite State Machine Status Register
Register Name: USBFSM
Access Type: Read-Only
Offset: 0x082C
Reset Value: 0x00000009
• DRDSTATE: Dual Role Device State
This field indicates the state of the USBC.
For Device mode it should always read 9.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
- - - - DRDSTATE
112
32142D–06/2013
ATUC64/128/256L3/4U
8.7.1.11 USB Descriptor Address
Register Name: UDESC
Access Type: Read-Write
Offset: 0x0830
Reset Value: -
• UDESCA: USB Descriptor Address
This field contains the address of the USB descriptor. The three least significant bits are always zero.
31 30 29 28 27 26 25 24
UDESCA[31:24]
23 22 21 20 19 18 17 16
UDESCA[23:16]
15 14 13 12 11 10 9 8
UDESCA[15:8]
76543210
UDESCA[7:0]
113
32142D–06/2013
ATUC64/128/256L3/4U
8.7.2 USB Device Registers
8.7.2.1 Device General Control Register
Register Name: UDCON
Access Type: Read/Write
Offset: 0x0000
Reset Value: 0x00000100
• GNAK: Global NAK
0: Normal mode.
1: A NAK handshake is answered for each USB transaction regardless of the current endpoint memory bank status.
• LS: low-speed mode force
0: The full-speed mode is active.
1: The low-speed mode is active.
This bit can be written to even if USBE is zero or FRZCLK is one. Disabling the USBC (by writing a zero to the USBE bit) does
not reset this bit.
• RMWKUP: Remote wakeup
Writing a zero to this bit has no effect.
Writing a one to this bit will send an upstream resume to the host for a remote wakeup.
This bit is cleared when the USBC receives a USB reset or once the upstream resume has been sent.
• DETACH: Detach
Writing a zero to this bit will reconnect the device.
Writing a one to this bit will physically detach the device (disconnect internal pull-up resistor from DP and DM).
• ADDEN: Address Enable
Writing a zero to this bit has no effect.
Writing a one to this bit will activate the UADD field (USB address).
This bit is cleared when a USB reset is received.
• UADD: USB Address
This field contains the device address.
This field is cleared when a USB reset is received.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
- - - - - - GNAK -
15 14 13 12 11 10 9 8
- - - LS - - RMWKUP DETACH
76543210
ADDEN UADD
114
32142D–06/2013
ATUC64/128/256L3/4U
8.7.2.2 Device Global Interrupt Register
Register Name: UDINT
Access Type: Read-Only
Offset: 0x0004
Reset Value: 0x00000000
Note: 1. EPnINT bits are within the range from EP0INT to EP6INT.
• EPnINT: Endpoint n Interrupt
This bit is cleared when the interrupt source is serviced.
This bit is set when an interrupt is triggered by the endpoint n (UESTAn, UECONn). This triggers a USB interrupt if EPnINTE is
one.
• UPRSM: Upstream Resume Interrupt
This bit is cleared when the UDINTCLR.UPRSMC bit is written to one to acknowledge the interrupt (USB clock inputs must be
enabled before).
This bit is set when the USBC sends a resume signal called “Upstream Resume”. This triggers a USB interrupt if UPRSME is
one.
• EORSM: End of Resume Interrupt
This bit is cleared when the UDINTCLR.EORSMC bit is written to one to acknowledge the interrupt.
This bit is set when the USBC detects a valid “End of Resume” signal initiated by the host. This triggers a USB interrupt if
EORSME is one.
• WAKEUP: Wakeup Interrupt
This bit is cleared when the UDINTCLR.WAKEUPC bit is written to one to acknowledge the interrupt (USB clock inputs must be
enabled before) or when the Suspend (SUSP) interrupt bit is set.
This bit is set when the USBC is reactivated by a filtered non-idle signal from the lines (not by an upstream resume). This
triggers an interrupt if WAKEUPE is one.
This interrupt is generated even if the clock is frozen by the FRZCLK bit.
• EORST: End of Reset Interrupt
This bit is cleared when the UDINTCLR.EORSTC bit is written to one to acknowledge the interrupt.
This bit is set when a USB “End of Reset” has been detected. This triggers a USB interrupt if EORSTE is one.
• SOF: Start of Frame Interrupt
This bit is cleared when the UDINTCLR.SOFC bit is written to one to acknowledge the interrupt.
This bit is set when a USB “Start of Frame” PID (SOF) has been detected (every 1 ms). This triggers a USB interrupt if SOFE is
one. The FNUM field is updated.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
- - - EP8INT(1) EP7INT(1) EP6INT(1) EP5INT(1) EP4INT(1)
15 14 13 12 11 10 9 8
EP3INT(1) EP2INT(1) EP1INT(1) EP0INT - - - -
76543210
- UPRSM EORSM WAKEUP EORST SOF - SUSP
115
32142D–06/2013
ATUC64/128/256L3/4U
• SUSP: Suspend Interrupt
This bit is cleared when the UDINTCLR.SUSPC bit is written to one to acknowledge the interrupt or when the Wakeup
(WAKEUP) interrupt bit is set.
This bit is set when a USB “Suspend” idle bus state has been detected for 3 frame periods (J state for 3 ms). This triggers a
USB interrupt if SUSPE is one.
116
32142D–06/2013
ATUC64/128/256L3/4U
8.7.2.3 Device Global Interrupt Clear Register
Register Name: UDINTCLR
Access Type: Write-Only
Offset: 0x0008
Reset Value: 0x00000000
Writing a zero to a bit in this register has no effect.
Writing a one to a bit in this register will clear the corresponding bit in UDINT.
These bits always read as zero.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
- UPRSMC EORSMC WAKEUPC EORSTC SOFC - SUSPC
117
32142D–06/2013
ATUC64/128/256L3/4U
8.7.2.4 Device Global Interrupt Set Register
Register Name: UDINTSET
Access Type: Write-Only
Offset: 0x000C
Reset Value: 0x00000000
Writing a zero to a bit in this register has no effect.
Writing a one to a bit in this register will set the corresponding bit in UDINT, which may be useful for test or debug purposes.
These bits always read as zero.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
- UPRSMS EORSMS WAKEUPS EORSTS SOFS - SUSPS
118
32142D–06/2013
ATUC64/128/256L3/4U
8.7.2.5 Device Global Interrupt Enable Register
Register Name: UDINTE
Access Type: Read-Only
Offset: 0x0010
Reset Value: 0x00000000
Note: 1. EPnINTE bits are within the range from EP0INTE to EP6INTE.
0: The corresponding interrupt is disabled.
1: The corresponding interrupt is enabled.
A bit in this register is cleared when the corresponding bit in UDINTECLR is written to one.
A bit in this register is set when the corresponding bit in UDINTESET is written to one.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
- - - EP8INTE(1) EP7INTE(1) EP6INTE(1) EP5INTE(1) EP4INTE(1)
15 14 13 12 11 10 9 8
EP3INTE(1) EP2INTE(1) EP1INTE(1) EP0INTE - - - -
76543210
- UPRSME EORSME WAKEUPE EORSTE SOFE - SUSPE
119
32142D–06/2013
ATUC64/128/256L3/4U
8.7.2.6 Device Global Interrupt Enable Clear Register
Register Name: UDINTECLR
Access Type: Write-Only
Offset: 0x0014
Reset Value: 0x00000000
Note: 1. EPnINTEC bits are within the range from EP0INTEC to EP6INTEC.
Writing a zero to a bit in this register has no effect.
Writing a one to a bit in this register will clear the corresponding bit in UDINTE.
These bits always read as zero.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
- - - EP8INTEC(1) EP7INTEC(1) EP6INTEC(1) EP5INTEC(1) EP4INTEC(1)
15 14 13 12 11 10 9 8
EP3INTEC(1) EP2INTEC(1) EP1INTEC(1) EP0INTEC - - - -
76543210
- UPRSMEC EORSMEC WAKEUPEC EORSTEC SOFEC - SUSPEC
120
32142D–06/2013
ATUC64/128/256L3/4U
8.7.2.7 Device Global Interrupt Enable Set Register
Register Name: UDINTESET
Access Type: Write-Only
Offset: 0x0018
Reset Value: 0x00000000
Note: 1. EPnINTES bits are within the range from EP0INTES to EP6INTES.
Writing a zero to a bit in this register has no effect.
Writing a one to a bit in this register will set the corresponding bit in UDINTE.
These bits always read as zero.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
- - - EP8INTES(1) EP7INTES(1) EP6INTES(1) EP5INTES(1) EP4INTES(1)
15 14 13 12 11 10 9 8
EP3INTES(1) EP2INTES(1) EP1INTES(1) EP0INTES - - - -
76543210
- UPRSMES EORSMES WAKEUPES EORSTES SOFES - SUSPES
121
32142D–06/2013
ATUC64/128/256L3/4U
8.7.2.8 Endpoint Enable/Reset Register
Register Name: UERST
Access Type: Read/Write
Offset: 0x001C
Reset Value: 0x00000000
• EPENn: Endpoint n Enable
Note: 1. EPENn bits are within the range from EPEN0 to EPEN6.
Writing a zero to this bit will disable the endpoint n (USB requests will be ignored), and resets the endpoints registers (UECFGn,
UESTAn, UECONn), but not the endpoint configuration (EPBK, EPSIZE, EPDIR, EPTYPE).
Writing a one to this bit will enable the endpoint n.
0: The endpoint n is disabled.
1: The endpoint n is enabled.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
- - - - - - - EPEN8(1)
76543210
EPEN7(1) EPEN6(1) EPEN5(1) EPEN4(1) EPEN3(1) EPEN2(1) EPEN1(1) EPEN0
122
32142D–06/2013
ATUC64/128/256L3/4U
8.7.2.9 Device Frame Number Register
Register Name: UDFNUM
Access Type: Read-Only
Offset: 0x0020
Reset Value: 0x00000000
• FNCERR: Frame Number CRC Error
This bit is cleared upon receiving a USB reset.
This bit is set when a corrupted frame number is received. This bit and the SOF interrupt bit are updated at the same time.
• FNUM: Frame Number
This field is cleared upon receiving a USB reset.
This field contains the 11-bit frame number information, as provided from the last SOF packet.
FNUM is updated even if a corrupted SOF is received.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
FNCERR - FNUM[10:5]
76543210
FNUM[4:0] - - -
123
32142D–06/2013
ATUC64/128/256L3/4U
8.7.2.10 Endpoint n Configuration Register
Register Name: UECFGn, n in [0..6]
Access Type: Read/Write
Offset: 0x0100 + (n * 0x04)
Reset Value: 0x00000000
• EPTYPE: Endpoint Type
This field selects the endpoint type:
This field is cleared upon receiving a USB reset.
• EPDIR: Endpoint Direction
0: The endpoint direction is OUT.
1: The endpoint direction is IN (nor for control endpoints).
This bit is cleared upon receiving a USB reset.
• EPSIZE: Endpoint Size
This field determines the size of each endpoint bank:
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
- - - EPTYPE - - EPDIR
76543210
- EPSIZE - EPBK - -
EPTYPE Endpoint Type
0 0 Control
0 1 Isochronous
1 0 Bulk
1 1 Interrupt
EPSIZE Endpoint Size
0 0 0 8 bytes
0 0 1 16 bytes
0 1 0 32 bytes
0 1 1 64 bytes
1 0 0 128 bytes
124
32142D–06/2013
ATUC64/128/256L3/4U
This field is cleared upon receiving a USB reset (except for the endpoint 0).
• EPBK: Endpoint Banks
This bit selects the number of banks for the endpoint:
0: single-bank endpoint
1: double-bank endpoint
For control endpoints, a single-bank endpoint shall be selected.
This field is cleared upon receiving a USB reset (except for the endpoint 0).
1 0 1 256 bytes
1 1 0 512 bytes
1 1 1 1024 bytes
EPSIZE Endpoint Size
125
32142D–06/2013
ATUC64/128/256L3/4U
8.7.2.11 Endpoint n Status Register
Register Name: UESTAn, n in [0..6]
Access Type: Read-Only 0x0100
Offset: 0x0130 + (n * 0x04)
Reset Value: 0x00000000
• CTRLDIR: Control Direction
Writing a zero or a one to this bit has no effect.
This bit is cleared after a SETUP packet to indicate that the following packet is an OUT packet.
This bit is set after a SETUP packet to indicate that the following packet is an IN packet.
• CURRBK: Current Bank
This bit is set for non-control endpoints, indicating the current bank:
This field may be updated one clock cycle after the RWALL bit changes, so the user should not poll this field as an interrupt bit.
• NBUSYBK: Number of Busy Banks
This field is set to indicate the number of busy banks:
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
- - - - - - CTRLDIR -
15 14 13 12 11 10 9 8
CURRBK NBUSYBK RAMACERI - DTSEQ
76543210
- STALLEDI/
CRCERRI - NAKINI NAKOUTI RXSTPI/
ERRORFI RXOUTI TXINI
CURRBK Current Bank
0 0 Bank0
0 1 Bank1
1 0 Reserved
1 1 Reserved
NBUSYBK Number of Busy Banks
0 0 0 (all banks free)
0 11
1 02
1 1 Reserved
126
32142D–06/2013
ATUC64/128/256L3/4U
For IN endpoints, this indicates the number of banks filled by the user and ready for IN transfers. When all banks are free an
EPnINT interrupt will be triggered if NBUSYBKE is one.
For OUT endpoints, this indicates the number of banks filled by OUT transactions from the host. When all banks are busy an
EPnINT interrupt will be triggered if NBUSYBKE is one.
• RAMACERI: Ram Access Error Interrupt
This bit is cleared when the RAMACERIC bit is written to one, acknowledging the interrupt.
This bit is set when a RAM access underflow error occurs during an IN data stage.
• DTSEQ: Data Toggle Sequence
This field is set to indicate the PID of the current bank:
For IN transfers, this indicates the data toggle sequence that will be used for the next packet to be sent.
For OUT transfers, this value indicates the data toggle sequence of the data received in the current bank.
• STALLEDI: STALLed Interrupt
This bit is cleared when the STALLEDIC bit is written to one, acknowledging the interrupt.
This bit is set when a STALL handshake has been sent and triggers an EPnINT interrupt if STALLEDE is one.
• CRCERRI: CRC Error Interrupt
This bit is cleared when the CRCERRIC bit is written to one, acknowledging the interrupt.
This bit is set when a CRC error has been detected in an isochronous OUT endpoint bank, and triggers an EPnINT interrupt if
CRCERRE is one.
• NAKINI: NAKed IN Interrupt
This bit is cleared when the NAKINIC bit is written to one, acknowledging the interrupt.
This bit is set when a NAK handshake has been sent in response to an IN request from the host, and triggers an EPnINT
interrupt if NAKINE is one.
• NAKOUTI: NAKed OUT Interrupt
This bit is cleared when the NAKOUTIC bit is written to one, acknowledging the interrupt.
This bit is set when a NAK handshake has been sent in response to an OUT request from the host, and triggers an EPnINT
interrupt if NAKOUTE is one.
• ERRORFI: Isochronous Error flow Interrupt
This bit is cleared when the ERRORFIC bit is written to one, acknowledging the interrupt.
This bit is set, for isochronous IN/OUT endpoints, when an errorflow (underflow or overflow) error occurs, and triggers an
EPnINT interrupt if ERRORFE is one.
An underflow can occur during IN stage if the host attempts to read from an empty bank. A zero-length packet is then
automatically sent by the USBC.
An overflow can also occur during OUT stage if the host sends a packet while the bank is already full, resulting in the packet
being lost. This is typically due to a CPU not being fast enough.
This bit is inactive (cleared) for bulk and interrupt IN/OUT endpoints and it means RXSTPI for control endpoints.
• RXSTPI: Received SETUP Interrupt
This bit is cleared when the RXSTPIC bit is written to one, acknowledging the interrupt and freeing the bank.
This bit is set, for control endpoints, to signal that the current bank contains a new valid SETUP packet, and triggers an EPnINT
interrupt if RXSTPE is one.
This bit is inactive (cleared) for bulk and interrupt IN/OUT endpoints and it means UNDERFI for isochronous IN/OUT endpoints.
• RXOUTI: Received OUT Data Interrupt
This bit is cleared when the RXOUTIC bit is written to one, acknowledging the interrupt. For control endpoints, it releases the
bank. For other endpoint types, the user should clear the FIFOCON bit to free the bank. RXOUTI shall always be cleared before
clearing FIFOCON to avoid missing an interrupt.
DTSEQ Data Toggle Sequence
0 0 Data0
0 1 Data1
1 X Reserved
127
32142D–06/2013
ATUC64/128/256L3/4U
This bit is set, for control endpoints, when the current bank contains a bulk OUT packet (data or status stage). This triggers an
EPnINT interrupt if RXOUTE is one.
This bit is set for isochronous, bulk and, interrupt OUT endpoints, at the same time as FIFOCON when the current bank is full.
This triggers an EPnINT interrupt if RXOUTE is one.
This bit is inactive (cleared) for isochronous, bulk and interrupt IN endpoints.
• TXINI: Transmitted IN Data Interrupt
This bit is cleared when the TXINIC bit is written to one, acknowledging the interrupt. For control endpoints, this will send the
packet. For other endpoint types, the user should clear the FIFOCON to allow the USBC to send the data. TXINI shall always be
cleared before clearing FIFOCON to avoid missing an interrupt.
This bit is set for control endpoints, when the current bank is ready to accept a new IN packet. This triggers an EPnINT interrupt
if TXINE is one.
This bit is set for isochronous, bulk and interrupt IN endpoints, at the same time as FIFOCON when the current bank is free.
This triggers an EPnINT interrupt if TXINE is one.
This bit is inactive (cleared) for isochronous, bulk and interrupt OUT endpoints.
128
32142D–06/2013
ATUC64/128/256L3/4U
8.7.2.12 Endpoint n Status Clear Register
Register Name: UESTAnCLR, n in [0..6]
Access Type: Write-Only
Offset: 0x0160 + (n * 0x04)
Reset Value: 0x00000000
Writing a zero to a bit in this register has no effect.
Writing a one to a bit in this register will clear the corresponding bit in UESTA.
These bits always read as zero.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
- - - - RAMACERIC - - -
76543210
- STALLEDIC/
CRCERRIC - NAKINIC NAKOUTIC RXSTPIC/
ERRORFIC RXOUTIC TXINIC
129
32142D–06/2013
ATUC64/128/256L3/4U
8.7.2.13 Endpoint n Status Set Register
Register Name: UESTAnSET, n in [0..6]
Access Type: Write-Only
Offset: 0x0190 + (n * 0x04)
Reset Value: 0x00000000
Writing a zero to a bit in this register has no effect.
Writing a one to a bit in this register will set the corresponding bit in UESTA.
These bits always read as zero.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
- - - NBUSYBKS RAMACERIS - -
76543210
- STALLEDIS/
CRCERRIS - NAKINIS NAKOUTIS RXSTPIS/
ERRORFIS RXOUTIS TXINIS
130
32142D–06/2013
ATUC64/128/256L3/4U
8.7.2.14 Endpoint n Control Register
Register Name: UECONn, n in [0..6]
Access Type: Read-Only
Offset: 0x01C0 + (n * 0x04)
Reset Value: 0x00000000
• BUSY0E: Busy Bank0 Enable
This bit is cleared when the BUSY0C bit is written to one.
This bit is set when the BUSY0ES bit is written to one. This will set the bank 0 as “busy”. All transactions, except SETUP,
destined to this bank will be rejected (i.e: NAK token will be answered).
• BUSY1E: Busy Bank1 Enable
This bit is cleared when the BUSY1C bit is written to one.
This bit is set when the BUSY1ES bit is written to one. This will set the bank 1 as “busy”. All transactions, except SETUP,
destined to this bank will be rejected (i.e: NAK token will be answered).
• STALLRQ: STALL Request
This bit is cleared when a new SETUP packet is received or when the STALLRQC bit is written to zero.
This bit is set when the STALLRQS bit is written to one, requesting a STALL handshake to be sent to the host.
• RSTDT: Reset Data Toggle
The data toggle sequence is cleared when the RSTDTS bit is written to one (i.e., Data0 data toggle sequence will be selected
for the next sent (IN endpoints) or received (OUT endpoints) packet.
This bit is always read as zero.
• FIFOCON: FIFO Control
For control endpoints:
The FIFOCON and RWALL bits are irrelevant. The software shall therefore never use them for these endpoints. When read,
their value is always 0.
For IN endpoints:
This bit is cleared when the FIFOCONC bit is written to one, sending the FIFO data and switching to the next bank.
This bit is set simultaneously to TXINI, when the current bank is free.
For OUT endpoints:
This bit is cleared when the FIFOCONC bit is written to one, freeing the current bank and switching to the next.
This bit is set simultaneously to RXINI, when the current bank is full.
31 30 29 28 27 26 25 24
- - - - - - BUSY1E BUSY0E
23 22 21 20 19 18 17 16
- - - - STALLRQ RSTDT - -
15 14 13 12 11 10 9 8
- FIFOCON KILLBK NBUSYBKE RAMACERE - -
76543210
- STALLEDE/
CRCERRE - NAKINE NAKOUTE RXSTPE/
ERRORFE RXOUTE TXINE
131
32142D–06/2013
ATUC64/128/256L3/4U
• KILLBK: Kill IN Bank
This bit is cleared by hardware after the completion of the “kill packet procedure”.
This bit is set when the KILLBKS bit is written to one, killing the last written bank.
The user shall wait for this bit to be cleared before trying to process another IN packet.
Caution: The bank is cleared when the “kill packet” procedure is completed by the USBC core:
If the bank is really killed, the NBUSYBK field is decremented.
If the bank sent instead of killed (IN transfer), the NBUSYBK field is decremented and the TXINI flag is set. This specific case
can occur if an IN token comes while the user tries to kill the bank.
Note: If two banks are ready to be sent, the above specific case will not occur, since the first bank is sent (IN transfer) while the
last bank is killed.
• NBUSYBKE: Number of Busy Banks Interrupt Enable
This bit is cleared when the NBUSYBKEC bit is written to zero, disabling the Number of Busy Banks interrupt (NBUSYBK).
This bit is set when the NBUSYBKES bit is written to one, enabling the Number of Busy Banks interrupt (NBUSYBK).
• RAMACERE: RAMACER Interrupt Enable
This bit is cleared when the RAMACEREC bit is written to one, disabling the RAMACER interrupt (RAMACERI).
This bit is set when the RAMACERES bit is written to one, enabling the RAMACER interrupt (RAMACERI).
• STALLEDE: STALLed Interrupt Enable
This bit is cleared when the STALLEDEC bit is written to one, disabling the STALLed interrupt (STALLEDI).
This bit is set when the STALLEDES bit is written to one, enabling the STALLed interrupt (STALLEDI).
• CRCERRE: CRC Error Interrupt Enable
This bit is cleared when the CRCERREC bit is written to one, disabling the CRC Error interrupt (CRCERRI).
This bit is set when the CRCERRES bit is written to one, enabling the CRC Error interrupt (CRCERRI).
• NAKINE: NAKed IN Interrupt Enable
This bit is cleared when the NAKINEC bit is written to one, disabling the NAKed IN interrupt (NAKINI).
This bit is set when the NAKINES bit is written to one, enabling the NAKed IN interrupt (NAKINI).
• NAKOUTE: NAKed OUT Interrupt Enable
This bit is cleared when the NAKOUTEC bit is written to one, disabling the NAKed OUT interrupt (NAKOUTI).
This bit is set when the NAKOUTES bit is written to one, enabling the NAKed OUT interrupt (NAKOUTI).
• RXSTPE: Received SETUP Interrupt Enable
This bit is cleared when the RXSTPEC bit is written to one, disabling the Received SETUP interrupt (RXSTPI).
This bit is set when the RXSTPES bit is written to one, enabling the Received SETUP interrupt (RXSTPI).
• ERRORFE: Errorflow Interrupt Enable
This bit is cleared when the ERRORFEC bit is written to one, disabling the Underflow interrupt (ERRORFI).
This bit is set when the ERRORFES bit is written to one, enabling the Underflow interrupt (ERRORFI).
• RXOUTE: Received OUT Data Interrupt Enable
This bit is cleared when the RXOUTEC bit is written to one, disabling the Received OUT Data interrupt (RXOUT).
This bit is set when the RXOUTES bit is written to one, enabling the Received OUT Data interrupt (RXOUT).
• TXINE: Transmitted IN Data Interrupt Enable
This bit is cleared when the TXINEC bit is written to one, disabling the Transmitted IN Data interrupt (TXINI).
This bit is set when the TXINES bit is written to one, enabling the Transmitted IN Data interrupt (TXINI).
132
32142D–06/2013
ATUC64/128/256L3/4U
8.7.2.15 Endpoint n Control Clear Register
Register Name: UECONnCLR, n in [0..6]
Access Type: Write-Only
Offset: 0x0220 + (n * 0x04)
Reset Value: 0x00000000
Writing a zero to a bit in this register has no effect.
Writing a one to a bit in this register will clear the corresponding bit in UECONn.
These bits always read as zero.
31 30 29 28 27 26 25 24
- - - - - - BUSY1EC BUSY0EC
23 22 21 20 19 18 17 16
- - - - STALLRQC - - -
15 14 13 12 11 10 9 8
- FIFOCONC - NBUSYBKEC RAMACEREC - - -
76543210
- STALLEDEC/
CRCERREC - NAKINEC NAKOUTEC RXSTPEC/
ERRORFEC RXOUTEC TXINEC
133
32142D–06/2013
ATUC64/128/256L3/4U
8.7.2.16 Endpoint n Control Set Register
Register Name: UECONnSET, n in [0..6]
Access Type: Write-Only
Offset: 0x01F0 + (n * 0x04)
Reset Value: 0x00000000
Writing a zero to a bit in this register has no effect.
Writing a one to a bit in this register will set the corresponding bit in UECONn.
These bits always read as zero.
•
•
31 30 29 28 27 26 25 24
- - - - - - BUSY1ES BUSY0ES
23 22 21 20 19 18 17 16
- - - - STALLRQS RSTDTS - -
15 14 13 12 11 10 9 8
- - KILLBKS NBUSYBKES RAMACERES ---
76543210
- STALLEDES/
CRCERRES - NAKINES NAKOUTES RXSTPES/
ERRORFES RXOUTES TXINES
134
32142D–06/2013
ATUC64/128/256L3/4U
8.8 Module Configuration
The specific configuration for each USBC instance is listed in the following tables. The module
bus clocks listed here are connected to the system bus clocks. Please refer to the Power Manager
chapter for details.
Table 8-6. USBC Clocks
Clock Name Description
CLK_USBC_PB Clock for the USBC PB interface
CLK_USBC_HSB Clock for the USBC HSB interface
GCLK_USBC The generic clock used for the USBC is GCLK7
Table 8-7. Register Reset Values
Register Reset Value
UVERS 0x00000200
UFEATURES 0x00000007
UADDRSIZE 0x00001000
UNAME1 0x48555342
UNAME2 0x00000000
135
32142D–06/2013
ATUC64/128/256L3/4U
9. Flash Controller (FLASHCDW)
Rev: 1.2.0.0
9.1 Features
• Controls on-chip flash memory
• Supports 0 and 1 wait state bus access
• Buffers reducing penalty of wait state in sequential code or loops
• Allows interleaved burst reads for systems with one wait state, outputting one 32-bit word per
clock cycle for sequential reads
• Secure State for supporting FlashVault technology
• 32-bit HSB interface for reads from flash and writes to page buffer
• 32-bit PB interface for issuing commands to and configuration of the controller
• Flash memory is divided into 16 regions can be individually protected or unprotected
• Additional protection of the Boot Loader pages
• Supports reads and writes of general-purpose Non Volatile Memory (NVM) bits
• Supports reads and writes of additional NVM pages
• Supports device protection through a security bit
• Dedicated command for chip-erase, first erasing all on-chip volatile memories before erasing
flash and clearing security bit
9.2 Overview
The Flash Controller (FLASHCDW) interfaces the on-chip flash memory with the 32-bit internal
HSB bus. The controller manages the reading, writing, erasing, locking, and unlocking
sequences.
9.3 Product Dependencies
In order to use this module, other parts of the system must be configured correctly, as described
below.
9.3.1 Power Management
If the CPU enters a sleep mode that disables clocks used by the FLASHCDW, the FLASHCDW
will stop functioning and resume operation after the system wakes up from sleep mode.
9.3.2 Clocks
The FLASHCDW has two bus clocks connected: One High Speed Bus clock
(CLK_FLASHCDW_HSB) and one Peripheral Bus clock (CLK_FLASHCDW_PB). These clocks
are generated by the Power Manager. Both clocks are enabled at reset, and can be disabled by
writing to the Power Manager. The user has to ensure that CLK_FLASHCDW_HSB is not turned
off before reading the flash or writing the pagebuffer and that CLK_FLASHCDW_PB is not
turned off before accessing the FLASHCDW configuration and control registers. Failing to do so
may deadlock the bus.
9.3.3 Interrupts
The FLASHCDW interrupt request lines are connected to the interrupt controller. Using the
FLASHCDW interrupts requires the interrupt controller to be programmed first.
136
32142D–06/2013
ATUC64/128/256L3/4U
9.3.4 Debug Operation
When an external debugger forces the CPU into debug mode, the FLASHCDW continues normal
operation. If the FLASHCDW is configured in a way that requires it to be periodically
serviced by the CPU through interrupts or similar, improper operation or data loss may result
during debugging.
9.4 Functional Description
9.4.1 Bus Interfaces
The FLASHCDW has two bus interfaces, one High Speed Bus (HSB) interface for reads from the
flash memory and writes to the page buffer, and one Peripheral Bus (PB) interface for issuing
commands and reading status from the controller.
9.4.2 Memory Organization
The flash memory is divided into a set of pages. A page is the basic unit addressed when programming
the flash. A page consists of several words. The pages are grouped into 16 regions of
equal size. Each of these regions can be locked by a dedicated fuse bit, protecting it from accidental
modification.
• p pages (FLASH_P)
• w bytes in each page and in the page buffer (FLASH_W)
• pw bytes in total (FLASH_PW)
• f general-purpose fuse bits (FLASH_F), used as region lock bits and for other device-specific
purposes
• 1 security fuse bit
• 1 User page
9.4.3 User Page
The User page is an additional page, outside the regular flash array, that can be used to store
various data, such as calibration data and serial numbers. This page is not erased by regular
chip erase. The User page can only be written and erased by a special set of commands. Read
accesses to the User page are performed just as any other read accesses to the flash. The
address map of the User page is given in Figure 9-1 on page 138.
9.4.4 Read Operations
The on-chip flash memory is typically used for storing instructions to be executed by the CPU.
The CPU will address instructions using the HSB bus, and the FLASHCDW will access the flash
memory and return the addressed 32-bit word.
In systems where the HSB clock period is slower than the access time of the flash memory, the
FLASHCDW can operate in 0 wait state mode, and output one 32-bit word on the bus per clock
cycle. If the clock frequency allows, the user should use 0 wait state mode, because this gives
the highest performance as no stall cycles are encountered.
The FLASHCDW can also operate in systems where the HSB bus clock period is faster than the
access speed of the flash memory. Wait state support and a read granularity of 64 bits ensure
efficiency in such systems.
Performance for systems with high clock frequency is increased since the internal read word
width of the flash memory is 64 bits. When a 32-bit word is to be addressed, the word itself and
137
32142D–06/2013
ATUC64/128/256L3/4U
also the other word in the same 64-bit location is read. The first word is output on the bus, and
the other word is put into an internal buffer. If a read to a sequential address is to be performed
in the next cycle, the buffered word is output on the bus, while the next 64-bit location is read
from the flash memory. Thus, latency in 1 wait state mode is hidden for sequential fetches.
The programmer can select the wait states required by writing to the FWS field in the Flash Control
Register (FCR). It is the responsibility of the programmer to select a number of wait states
compatible with the clock frequency and timing characteristics of the flash memory.
In 0ws mode, no wait states are encountered on any flash read operations. In 1 ws mode, one
stall cycle is encountered on the first access in a single or burst transfer. In 1 ws mode, if the first
access in a burst access is to an address that is not 64-bit aligned, an additional stall cycle is
also encountered when reading the second word in the burst. All subsequent words in the burst
are accessed without any stall cycles.
The Flash Controller provides two sets of buffers that can be enabled in order to speed up
instruction fetching. These buffers can be enabled by writing a one to the FCR.SEQBUF and
FCR.BRBUF bits. The SEQBUF bit enables buffering hardware optimizing sequential instruction
fetches. The BRBUF bit enables buffering hardware optimizing tight inner loops. These buffers
are never used when the flash is in 0 wait state mode. Usually, both these buffers should be
enabled when operating in 1 wait state mode. Some users requiring absolute cycle determinism
may want to keep the buffers disabled.
The Flash Controller address space is displayed in Figure 9-1. The memory space between
address pw and the User page is reserved, and reading addresses in this space returns an
undefined result. The User page is permanently mapped to an offset of 0x00800000 from the
start address of the flash memory.
Table 9-1. User Page Addresses
Memory type Start address, byte sized Size
Main array 0 pw bytes
User 0x00800000 w bytes
138
32142D–06/2013
ATUC64/128/256L3/4U
Figure 9-1. Memory Map for the Flash Memories
9.4.5 High Speed Read Mode
The flash provides a High Speed Read Mode, offering slightly higher flash read speed at the
cost of higher power consumption. Two dedicated commands, High Speed Read Mode Enable
(HSEN) and High Speed Read Mode Disable (HSDIS) control the speed mode. The High Speed
Mode (HSMODE) bit in the Flash Status Register (FSR) shows which mode the flash is in. After
reset, the High Speed Mode is disabled, and must be manually enabled if the user wants to.
Refer to the Electrical Characteristics chapter at the end of this datasheet for details on the maximum
clock frequencies in Normal and High Speed Read Mode.
0
pw
Reserved Flash data array
Reserved User Page
Flash with User Page
0x0080 0000
All addresses are byte addresses
Flash base address
Offset from
base address
139
32142D–06/2013
ATUC64/128/256L3/4U
Figure 9-2. High Speed Mode
9.4.6 Quick Page Read
A dedicated command, Quick Page Read (QPR), is provided to read all words in an addressed
page. All bits in all words in this page are AND’ed together, returning a 1-bit result. This result is
placed in the Quick Page Read Result (QPRR) bit in Flash Status Register (FSR). The QPR
command is useful to check that a page is in an erased state. The QPR instruction is much
faster than performing the erased-page check using a regular software subroutine.
9.4.7 Quick User Page Read
A dedicated command, Quick User Page Read (QPRUP), is provided to read all words in the
user page. All bits in all words in this page are AND’ed together, returning a 1-bit result. This
result is placed in the Quick Page Read Result (QPRR) bit in Flash Status Register (FSR). The
QPRUP command is useful to check that a page is in an erased state. The QPRUP instruction is
much faster than performing the erased-page check using a regular software subroutine.
9.4.8 Page Buffer Operations
The flash memory has a write and erase granularity of one page; data is written and erased in
chunks of one page. When programming a page, the user must first write the new data into the
Page Buffer. The contents of the entire Page Buffer is copied into the desired page in flash
memory when the user issues the Write Page command, Refer to Section 9.5.1 on page 141.
In order to program data into flash page Y, write the desired data to locations Y0 to Y31 in the
regular flash memory map. Writing to an address A in the flash memory map will not update the
flash memory, but will instead update location A%32 in the page buffer. The PAGEN field in the
Flash Command (FCMD) register will at the same time be updated with the value A/32.
Frequency
Frequency limit
for 0 wait state
operation
Normal
High
Speed mode
1 wait state
0 wait state
140
32142D–06/2013
ATUC64/128/256L3/4U
Figure 9-3. Mapping from Page Buffer to Flash
Internally, the flash memory stores data in 64-bit doublewords. Therefore, the native data size of
the Page Buffer is also a 64-bit doubleword. All locations shown in Figure 9-3 are therefore doubleword
locations. Since the HSB bus only has a 32-bit data width, two 32-bit HSB transfers
must be performed to write a 64-bit doubleword into the Page Buffer. The FLASHCDW has logic
to combine two 32-bit HSB transfers into a 64-bit data before writing this 64-bit data into the
Page Buffer. This logic requires the word with the low address to be written to the HSB bus
before the word with the high address. To exemplify, to write a 64-bit value to doubleword X0
residing in page X, first write a 32-bit word to the byte address pointing to address X0, thereafter
write a word to the byte address pointing to address (X0+4).
The page buffer is word-addressable and should only be written with aligned word transfers,
never with byte or halfword transfers. The page buffer can not be read.
The page buffer is also used for writes to the User page.
Page buffer write operations are performed with 4 wait states. Any accesses attempted to the
FLASHCDW on the HSB bus during these cycles will be automatically stalled.
Writing to the page buffer can only change page buffer bits from one to zero, i.e. writing
0xAAAAAAAA to a page buffer location that has the value 0x00000000 will not change the page
buffer value. The only way to change a bit from zero to one is to erase the entire page buffer with
the Clear Page Buffer command.
Z3 Z2 Z1 Z0
Z7 Z6 Z5 Z4
Z11 Z10 Z9 Z8
Z15 Z14 Z13 Z12
Z19 Z18 Z17 Z16
Z23 Z22 Z21 Z20
Z27 Z26 Z25 Z24
Z31 Z30 Z29 Z28
Y3 Y2 Y1 Y0
Y7 Y6 Y5 Y4
Y11 Y10 Y9 Y8
Y15 Y14 Y13 Y12
Y19 Y18 Y17 Y16
Y23 Y22 Y21 Y20
Y27 Y26 Y25 Y24
Y31 Y30 Y29 Y28
X3 X2 X1 X0
X7 X6 X5 X4
X11 X10 X9 X8
X15 X14 X13 X12
X19 X18 X17 X16
X23 X22 X21 X20
X27 X26 X25 X24
X31 X30 X29 X28
3 2 1 0
7 6 5 4
11 10 9 8
15 14 13 12
19 18 17 16
23 22 21 20
27 26 25 24
31 30 29 28
Page X
Page Y
Page Z
Page Buffer
64-bit data
Flash
All locations are doubleword locations
141
32142D–06/2013
ATUC64/128/256L3/4U
The page buffer is not automatically reset after a page write. The programmer should do this
manually by issuing the Clear Page Buffer flash command. This can be done after a page write,
or before the page buffer is loaded with data to be stored to the flash page.
9.5 Flash Commands
The FLASHCDW offers a command set to manage programming of the flash memory, locking
and unlocking of regions, and full flash erasing. See Section 9.8.2 for a complete list of
commands.
To run a command, the CMD field in the Flash Command Register (FCMD) has to be written
with the command number. As soon as the FCMD register is written, the FRDY bit in the Flash
Status Register (FSR) is automatically cleared. Once the current command is complete, the
FSR.FRDY bit is automatically set. If an interrupt has been enabled by writing a one to
FCR.FRDY, the interrupt request line of the Flash Controller is activated. All flash commands
except for Quick Page Read (QPR) and Quick User Page Read (QPRUP) will generate an interrupt
request upon completion if FCR.FRDY is one.
Any HSB bus transfers attempting to read flash memory when the FLASHCDW is busy executing
a flash command will be stalled, and allowed to continue when the flash command is
complete.
After a command has been written to FCMD, the programming algorithm should wait until the
command has been executed before attempting to read instructions or data from the flash or
writing to the page buffer, as the flash will be busy. The waiting can be performed either by polling
the Flash Status Register (FSR) or by waiting for the flash ready interrupt. The command
written to FCMD is initiated on the first clock cycle where the HSB bus interface in FLASHCDW
is IDLE. The user must make sure that the access pattern to the FLASHCDW HSB interface
contains an IDLE cycle so that the command is allowed to start. Make sure that no bus masters
such as DMA controllers are performing endless burst transfers from the flash. Also, make sure
that the CPU does not perform endless burst transfers from flash. This is done by letting the
CPU enter sleep mode after writing to FCMD, or by polling FSR for command completion. This
polling will result in an access pattern with IDLE HSB cycles.
All the commands are protected by the same keyword, which has to be written in the eight highest
bits of the FCMD register. Writing FCMD with data that does not contain the correct key
and/or with an invalid command has no effect on the flash memory; however, the PROGE bit is
set in the Flash Status Register (FSR). This bit is automatically cleared by a read access to the
FSR register.
Writing a command to FCMD while another command is being executed has no effect on the
flash memory; however, the PROGE bit is set in the Flash Status Register (FSR). This bit is
automatically cleared by a read access to the FSR register.
If the current command writes or erases a page in a locked region, or a page protected by the
BOOTPROT fuses, the command has no effect on the flash memory; however, the LOCKE bit is
set in the FSR register. This bit is automatically cleared by a read access to the FSR register.
9.5.1 Write/Erase Page Operation
Flash technology requires that an erase must be done before programming. The entire flash can
be erased by an Erase All command. Alternatively, pages can be individually erased by the
Erase Page command.
The User page can be written and erased using the mechanisms described in this chapter.
142
32142D–06/2013
ATUC64/128/256L3/4U
After programming, the page can be locked to prevent miscellaneous write or erase sequences.
Locking is performed on a per-region basis, so locking a region locks all pages inside the region.
Additional protection is provided for the lowermost address space of the flash. This address
space is allocated for the Boot Loader, and is protected both by the lock bit(s) corresponding to
this address space, and the BOOTPROT[2:0] fuses.
Data to be written is stored in an internal buffer called the page buffer. The page buffer contains
w words. The page buffer wraps around within the internal memory area address space and
appears to be repeated by the number of pages in it. Writing of 8-bit and 16-bit data to the page
buffer is not allowed and may lead to unpredictable data corruption.
Data must be written to the page buffer before the programming command is written to the Flash
Command Register (FCMD). The sequence is as follows:
• Reset the page buffer with the Clear Page Buffer command.
• Fill the page buffer with the desired contents as described in Section 9.4.8 on page 139.
• Programming starts as soon as the programming key and the programming command are
written to the Flash Command Register. The PAGEN field in the Flash Command Register
(FCMD) must contain the address of the page to write. PAGEN is automatically updated
when writing to the page buffer, but can also be written to directly. The FRDY bit in the Flash
Status Register (FSR) is automatically cleared when the page write operation starts.
• When programming is completed, the FRDY bit in the Flash Status Register (FSR) is set. If
an interrupt was enabled by writing FCR.FRDY to one, an interrupt request is generated.
Two errors can be detected in the FSR register after a programming sequence:
• Programming Error: A bad keyword and/or an invalid command have been written in the
FCMD register.
• Lock Error: Can have two different causes:
– The page to be programmed belongs to a locked region. A command must be
executed to unlock the corresponding region before programming can start.
– A bus master without secure status attempted to program a page requiring secure
privileges.
9.5.2 Erase All Operation
The entire memory is erased if the Erase All command (EA) is written to the Flash Command
Register (FCMD). Erase All erases all bits in the flash array. The User page is not erased. All
flash memory locations, the general-purpose fuse bits, and the security bit are erased (reset to
0xFF) after an Erase All.
The EA command also ensures that all volatile memories, such as register file and RAMs, are
erased before the security bit is erased.
Erase All operation is allowed only if no regions are locked, and the BOOTPROT fuses are configured
with a BOOTPROT region size of 0. Thus, if at least one region is locked, the bit LOCKE
in FSR is set and the command is cancelled. If the LOCKE bit in FCR is one, an interrupt request
is set generated.
When the command is complete, the FRDY bit in the Flash Status Register (FSR) is set. If an
interrupt has been enabled by writing FCR.FRDY to one, an interrupt request is generated. Two
errors can be detected in the FSR register after issuing the command:
143
32142D–06/2013
ATUC64/128/256L3/4U
• Programming Error: A bad keyword and/or an invalid command have been written in the
FCMD register.
• Lock Error: At least one lock region is protected, or BOOTPROT is different from 0. The erase
command has been aborted and no page has been erased. A “Unlock region containing
given page” (UP) command must be executed to unlock any locked regions.
9.5.3 Region Lock Bits
The flash memory has p pages, and these pages are grouped into 16 lock regions, each region
containing p/16 pages. Each region has a dedicated lock bit preventing writing and erasing
pages in the region. After production, the device may have some regions locked. These locked
regions are reserved for a boot or default application. Locked regions can be unlocked to be
erased and then programmed with another application or other data.
To lock or unlock a region, the commands Lock Region Containing Page (LP) and Unlock
Region Containing Page (UP) are provided. Writing one of these commands, together with the
number of the page whose region should be locked/unlocked, performs the desired operation.
One error can be detected in the FSR register after issuing the command:
• Programming Error: A bad keyword and/or an invalid command have been written in the
FCMD register.
The lock bits are implemented using the lowest 16 general-purpose fuse bits. This means that
lock bits can also be set/cleared using the commands for writing/erasing general-purpose fuse
bits, see Section 9.6. The general-purpose bit being in an erased (1) state means that the region
is unlocked.
The lowermost pages in the flash can additionally be protected by the BOOTPROT fuses, see
Section 9.6.
9.6 General-purpose Fuse Bits
The flash memory has a number of general-purpose fuse bits that the application programmer
can use freely. The fuse bits can be written and erased using dedicated commands, and read
144
32142D–06/2013
ATUC64/128/256L3/4U
through a dedicated Peripheral Bus address. Some of the general-purpose fuse bits are
reserved for special purposes, and should not be used for other functions:
The BOOTPROT fuses protects the following address space for the Boot Loader:
Table 9-2. General-purpose Fuses with Special Functions
GeneralPurpose
fuse
number Name Usage
15:0 LOCK Region lock bits.
16 EPFL
External Privileged Fetch Lock. Used to prevent the CPU from
fetching instructions from external memories when in privileged
mode. This bit can only be changed when the security bit is
cleared. The address range corresponding to external
memories is device-specific, and not known to the Flash
Controller. This fuse bit is simply routed out of the CPU or bus
system, the Flash Controller does not treat this fuse in any
special way, except that it can not be altered when the security
bit is set.
If the security bit is set, only an external JTAG or aWire Chip
Erase can clear EPFL. No internal commands can alter EPFL if
the security bit is set.
When the fuse is erased (i.e. "1"), the CPU can execute
instructions fetched from external memories. When the fuse is
programmed (i.e. "0"), instructions can not be executed from
external memories.
This fuse has no effect in devices with no External Memory
Interface (EBI).
19:17 BOOTPROT
Used to select one of eight different bootloader sizes. Pages
included in the bootloader area can not be erased or
programmed except by a JTAG or aWire chip erase.
BOOTPROT can only be changed when the security bit is
cleared.
If the security bit is set, only an external JTAG or aWire Chip
Erase can clear BOOTPROT, and thereby allow the pages
protected by BOOTPROT to be programmed. No internal
commands can alter BOOTPROT or the pages protected by
BOOTPROT if the security bit is set.
21:20 SECURE
Used to configure secure state and secure state debug
capabilities. Decoded into SSE and SSDE signals as shown in
Table 9-5. Refer to the AVR32 Architecture Manual and the
AVR32UC Technical Reference Manual for more details on
SSE and SSDE.
22 UPROT
If programmed (i.e. “0”), the JTAG USER PROTECTION
feature is enabled. If this fuse is programmed some HSB
addresses will be accessible by JTAG access even if the flash
security fuse is programmed. Refer to the JTAG documentation
for more information on this functionality. This bit can only be
changed when the security bit is cleared.
145
32142D–06/2013
ATUC64/128/256L3/4U
The SECURE fuses have the following functionality:
To erase or write a general-purpose fuse bit, the commands Write General-Purpose Fuse Bit
(WGPB) and Erase General-Purpose Fuse Bit (EGPB) are provided. Writing one of these commands,
together with the number of the fuse to write/erase, performs the desired operation.
An entire General-Purpose Fuse byte can be written at a time by using the Program GP Fuse
Byte (PGPFB) instruction. A PGPFB to GP fuse byte 2 is not allowed if the flash is locked by the
security bit. The PFB command is issued with a parameter in the PAGEN field:
• PAGEN[2:0] - byte to write
• PAGEN[10:3] - Fuse value to write
All general-purpose fuses can be erased by the Erase All General-Purpose fuses (EAGP) command.
An EAGP command is not allowed if the flash is locked by the security bit.
Two errors can be detected in the FSR register after issuing these commands:
• Programming Error: A bad keyword and/or an invalid command have been written in the
FCMD register.
• Lock Error:
– A write or erase of the BOOTPROT or EPFL or UPROT fuse bits was attempted
while the flash is locked by the security bit.
– A write or erase of the SECURE fuse bits was attempted when SECURE mode was
enabled.
The lock bits are implemented using the lowest 16 general-purpose fuse bits. This means that
the 16 lowest general-purpose fuse bits can also be written/erased using the commands for
locking/unlocking regions, see Section 9.5.3.
Table 9-3. Boot Loader Area Specified by BOOTPROT
BOOTPROT
Pages protected by
BOOTPROT
Size of protected
memory
7 None 0
6 0-1 1Kbyte
5 0-3 2Kbyte
4 0-7 4Kbyte
3 0-15 8Kbyte
2 0-31 16Kbyte
1 0-63 32Kbyte
0 0-127 64Kbyte
Table 9-5. Secure State Configuration
SECURE Functionality SSE SSDE
00 Secure state disabled 0 0
01 Secure enabled, secure state debug enabled 1 1
10 Secure enabled, secure state debug disabled 1 0
11 Secure state disabled 0 0
146
32142D–06/2013
ATUC64/128/256L3/4U
9.7 Security Bit
The security bit allows the entire device to be locked from external JTAG, aWire, or other debug
access for code security. The security bit can be written by a dedicated command, Set Security
Bit (SSB). Once set, the only way to clear the security bit is through the JTAG or aWire Chip
Erase command.
Once the security bit is set, the following Flash Controller commands will be unavailable and
return a lock error if attempted:
• Write General-Purpose Fuse Bit (WGPB) to BOOTPROT or EPFL fuses
• Erase General-Purpose Fuse Bit (EGPB) to BOOTPROT or EPFL fuses
• Program General-Purpose Fuse Byte (PGPFB) of fuse byte 2
• Erase All General-Purpose Fuses (EAGPF)
One error can be detected in the FSR register after issuing the command:
• Programming Error: A bad keyword and/or an invalid command have been written in the
FCMD register.
147
32142D–06/2013
ATUC64/128/256L3/4U
9.8 User Interface
Note: 1. The value of the Lock bits depend on their programmed state. All other bits in FSR are 0.
2. All bits in FGPRHI/LO are dependent on the programmed state of the fuses they map to. Any bits in these registers not
mapped to a fuse read as 0.
3. The reset values for these registers are device specific. Please refer to the Module Configuration section at the end of this
chapter.
Table 9-6. FLASHCDW Register Memory Map
Offset Register Register Name Access Reset
0x00 Flash Control Register FCR Read/Write 0x00000000
0x04 Flash Command Register FCMD Read/Write 0x00000000
0x08 Flash Status Register FSR Read-only -(1)
0x0C Flash Parameter Register FPR Read-only -(3)
0x10 Flash Version Register FVR Read-only -(3)
0x14 Flash General Purpose Fuse Register Hi FGPFRHI Read-only -(2)
0x18 Flash General Purpose Fuse Register Lo FGPFRLO Read-only -(2)
148
32142D–06/2013
ATUC64/128/256L3/4U
9.8.1 Flash Control Register
Name: FCR
Access Type: Read/Write
Offset: 0x00
Reset Value: 0x00000000
• BRBUF: Branch Target Instruction Buffer Enable
0: The Branch Target Instruction Buffer is disabled.
1: The Branch Target Instruction Buffer is enabled.
• SEQBUF: Sequential Instruction Fetch Buffer Enable
0: The Sequential Instruction Fetch Buffer is disabled.
1: The Sequential Instruction Fetch Buffer is enabled.
• FWS: Flash Wait State
0: The flash is read with 0 wait states.
1: The flash is read with 1 wait state.
• PROGE: Programming Error Interrupt Enable
0: Programming Error does not generate an interrupt request.
1: Programming Error generates an interrupt request.
• LOCKE: Lock Error Interrupt Enable
0: Lock Error does not generate an interrupt request.
1: Lock Error generates an interrupt request.
• FRDY: Flash Ready Interrupt Enable
0: Flash Ready does not generate an interrupt request.
1: Flash Ready generates an interrupt request.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
- - - - - BRBUF SEQBUF -
76543210
- FWS - - PROGE LOCKE - FRDY
149
32142D–06/2013
ATUC64/128/256L3/4U
9.8.2 Flash Command Register
Name: FCMD
Access Type: Read/Write
Offset: 0x04
Reset Value: 0x00000000
The FCMD can not be written if the flash is in the process of performing a flash command. Doing
so will cause the FCR write to be ignored, and the PROGE bit in FSR to be set.
• KEY: Write protection key
This field should be written with the value 0xA5 to enable the command defined by the bits of the register. If the field is written
with a different value, the write is not performed and no action is started.
This field always reads as 0.
• PAGEN: Page number
The PAGEN field is used to address a page or fuse bit for certain operations. In order to simplify programming, the PAGEN field
is automatically updated every time the page buffer is written to. For every page buffer write, the PAGEN field is updated with the
page number of the address being written to. Hardware automatically masks writes to the PAGEN field so that only bits
representing valid page numbers can be written, all other bits in PAGEN are always 0. As an example, in a flash with 1024
pages (page 0 - page 1023), bits 15:10 will always be 0.
31 30 29 28 27 26 25 24
KEY
23 22 21 20 19 18 17 16
PAGEN [15:8]
15 14 13 12 11 10 9 8
PAGEN [7:0]
76543210
- - CMD
Table 9-7. Semantic of PAGEN field in different commands
Command PAGEN description
No operation Not used
Write Page The number of the page to write
Clear Page Buffer Not used
Lock region containing given Page Page number whose region should be locked
Unlock region containing given Page Page number whose region should be unlocked
Erase All Not used
Write General-Purpose Fuse Bit GPFUSE #
Erase General-Purpose Fuse Bit GPFUSE #
Set Security Bit Not used
150
32142D–06/2013
ATUC64/128/256L3/4U
• CMD: Command
This field defines the flash command. Issuing any unused command will cause the Programming Error bit in FSR to be set, and
the corresponding interrupt to be requested if the PROGE bit in FCR is one.
Program GP Fuse Byte WriteData[7:0], ByteAddress[2:0]
Erase All GP Fuses Not used
Quick Page Read Page number
Write User Page Not used
Erase User Page Not used
Quick Page Read User Page Not used
High Speed Mode Enable Not used
High Speed Mode Disable Not used
Table 9-8. Set of commands
Command Value Mnemonic
No operation 0 NOP
Write Page 1 WP
Erase Page 2 EP
Clear Page Buffer 3 CPB
Lock region containing given Page 4 LP
Unlock region containing given Page 5 UP
Erase All 6 EA
Write General-Purpose Fuse Bit 7 WGPB
Erase General-Purpose Fuse Bit 8 EGPB
Set Security Bit 9 SSB
Program GP Fuse Byte 10 PGPFB
Erase All GPFuses 11 EAGPF
Quick Page Read 12 QPR
Write User Page 13 WUP
Erase User Page 14 EUP
Quick Page Read User Page 15 QPRUP
High Speed Mode Enable 16 HSEN
High Speed Mode Disable 17 HSDIS
RESERVED 16-31
Table 9-7. Semantic of PAGEN field in different commands
Command PAGEN description
151
32142D–06/2013
ATUC64/128/256L3/4U
9.8.3 Flash Status Register
Name: FSR
Access Type: Read-only
Offset: 0x08
Reset Value: 0x00000000
• LOCKx: Lock Region x Lock Status
0: The corresponding lock region is not locked.
1: The corresponding lock region is locked.
• HSMODE: High-Speed Mode
0: High-speed mode disabled.
1: High-speed mode enabled.
• QPRR: Quick Page Read Result
0: The result is zero, i.e. the page is not erased.
1: The result is one, i.e. the page is erased.
• SECURITY: Security Bit Status
0: The security bit is inactive.
1: The security bit is active.
• PROGE: Programming Error Status
Automatically cleared when FSR is read.
0: No invalid commands and no bad keywords were written in the Flash Command Register FCMD.
1: An invalid command and/or a bad keyword was/were written in the Flash Command Register FCMD.
• LOCKE: Lock Error Status
Automatically cleared when FSR is read.
0: No programming of at least one locked lock region has happened since the last read of FSR.
1: Programming of at least one locked lock region has happened since the last read of FSR.
• FRDY: Flash Ready Status
0: The Flash Controller is busy and the application must wait before running a new command.
1: The Flash Controller is ready to run a new command.
31 30 29 28 27 26 25 24
LOCK15 LOCK14 LOCK13 LOCK12 LOCK11 LOCK10 LOCK9 LOCK8
23 22 21 20 19 18 17 16
LOCK7 LOCK6 LOCK5 LOCK4 LOCK3 LOCK2 LOCK1 LOCK0
15 14 13 12 11 10 9 8
--------
76543210
- HSMODE QPRR SECURITY PROGE LOCKE - FRDY
152
32142D–06/2013
ATUC64/128/256L3/4U
9.8.4 Flash Parameter Register
Name: FPR
Access Type: Read-only
Offset: 0x0C
Reset Value: -
• PSZ: Page Size
The size of each flash page.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
- - - - - PSZ
76543210
- - - - FSZ
Table 9-9. Flash Page Size
PSZ Page Size
0 32 Byte
1 64 Byte
2 128 Byte
3 256 Byte
4 512 Byte
5 1024 Byte
6 2048 Byte
7 4096 Byte
153
32142D–06/2013
ATUC64/128/256L3/4U
• FSZ: Flash Size
The size of the flash. Not all device families will provide all flash sizes indicated in the table.
Table 9-10. Flash Size
FSZ Flash Size FSZ Flash Size
0 4 Kbyte 8 192 Kbyte
1 8 Kbyte 9 256 Kbyte
2 16 Kbyte 10 384 Kbyte
3 32 Kbyte 11 512 Kbyte
4 48 Kbyte 12 768 Kbyte
5 64 Kbyte 13 1024 Kbyte
6 96 Kbyte 14 2048 Kbyte
7 128 Kbyte 15 Reserved
154
32142D–06/2013
ATUC64/128/256L3/4U
9.8.5 Flash Version Register
Name: FVR
Access Type: Read-only
Offset: 0x10
Reset Value: 0x00000000
• VARIANT: Variant Number
Reserved. No functionality associated.
• VERSION: Version Number
Version number of the module. No functionality associated.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
- - - - VARIANT
15 14 13 12 11 10 9 8
- - - - VERSION[11:8]
76543210
VERSION[7:0]
155
32142D–06/2013
ATUC64/128/256L3/4U
9.8.6 Flash General Purpose Fuse Register High
Name: FGPFRHI
Access Type: Read-only
Offset: 0x14
Reset Value: -
This register is only used in systems with more than 32 GP fuses.
• GPFxx: General Purpose Fuse xx
0: The fuse has a written/programmed state.
1: The fuse has an erased state.
31 30 29 28 27 26 25 24
GPF63 GPF62 GPF61 GPF60 GPF59 GPF58 GPF57 GPF56
23 22 21 20 19 18 17 16
GPF55 GPF54 GPF53 GPF52 GPF51 GPF50 GPF49 GPF48
15 14 13 12 11 10 9 8
GPF47 GPF46 GPF45 GPF44 GPF43 GPF42 GPF41 GPF40
76543210
GPF39 GPF38 GPF37 GPF36 GPF35 GPF34 GPF33 GPF32
156
32142D–06/2013
ATUC64/128/256L3/4U
9.8.7 Flash General Purpose Fuse Register Low
Name: FGPFRLO
Access Type: Read-only
Offset: 0x18
Reset Value: -
• GPFxx: General Purpose Fuse xx
0: The fuse has a written/programmed state.
1: The fuse has an erased state.
31 30 29 28 27 26 25 24
GPF31 GPF30 GPF29 GPF28 GPF27 GPF26 GPF25 GPF24
23 22 21 20 19 18 17 16
GPF23 GPF22 GPF21 GPF20 GPF19 GPF18 GPF17 GPF16
15 14 13 12 11 10 9 8
GPF15 GPF14 GPF13 GPF12 GPF11 GPF10 GPF09 GPF08
76543210
GPF07 GPF06 GPF05 GPF04 GPF03 GPF02 GPF01 GPF00
157
32142D–06/2013
ATUC64/128/256L3/4U
9.9 Fuse Settings
The flash contains 32 general purpose fuses. These 32 fuses can be found in the Flash General
Purpose Fuse Register Low (FGPFRLO). The Flash General Purpose Fuse Register High
(FGPFRHI) is not used. In addition to the general purpose fuses, parts of the flash user page
can have a defined meaning outside of the flash controller and will also be described in this
section.
Note that when writing to the user page the values do not get loaded by the other modules on
the device until a chip reset occurs.
The general purpose fuses are erased by a JTAG or aWire chip erase.
158
32142D–06/2013
ATUC64/128/256L3/4U
9.9.1 Flash General Purpose Fuse Register Low (FGPFRLO)
• BODEN: Brown Out Detector Enable
• BODHYST: Brown Out Detector Hysteresis
0: The Brown out detector hysteresis is disabled
1: The Brown out detector hysteresis is enabled
• BODLEVEL: Brown Out Detector Trigger Level
This controls the voltage trigger level for the Brown out detector. Refer to ”Electrical Characteristics” on page 897.
• UPROT, SECURE, BOOTPROT, EPFL, LOCK
These are Flash Controller fuses and are described in the FLASHCDW section.
9.9.1.1 Default Fuse Value
The devices are shipped with the FGPFRLO register value:0xE07FFFFF:
• BODEN fuses set to 11. BOD is disabled.
• BODHYST fuse set to 1. The BOD hysteresis is enabled.
• BODLEVEL fuses set to 000000. This is the minimum voltage trigger level for BOD. This level
is lower than the POR level, so when BOD is enabled, it will never trigger with this default
value.
• UPROT fuse set to 1.
• SECURE fuse set to 11.
• BOOTPROT fuses set to 111. The bootloader protection is disabled.
• EPFL fuse set to 1. External privileged fetch is not locked.
• LOCK fuses set to 1111111111111111. No region locked.
After the JTAG or aWire chip erase command, the FGPFR register value is 0xFFFFFFFF.
31 30 29 28 27 26 25 24
BODEN BODHYST BODLEVEL[5:1]
23 22 21 20 19 18 17 16
BODLEVEL[0] UPROT SECURE BOOTPROT EPFL
15 14 13 12 11 10 9 8
LOCK[15:8]
7 6543210
LOCK[7:0]
BODEN Description
00 BOD disabled
01 BOD enabled, BOD reset enabled
10 BOD enabled, BOD reset disabled
11 BOD disabled
159
32142D–06/2013
ATUC64/128/256L3/4U
9.9.2 First Word of the User Page (Address 0x80800000)
• WDTAUTO: WatchDog Timer Auto Enable at Startup
0: The WDT is automatically enabled at startup.
1: The WDT is not automatically enabled at startup.
Please refer to the WDT chapter for detail about timeout settings when the WDT is automatically enabled.
9.9.2.1 Default user page first word value
The devices are shipped with the user page erased (all bits 1):
• WDTAUTO set to 1, WDT disabled.
31 30 29 28 27 26 25 24
- -------
23 22 21 20 19 18 17 16
- -------
15 14 13 12 11 10 9 8
- -------
7 6543210
- - - - - - - WDTAUTO
160
32142D–06/2013
ATUC64/128/256L3/4U
9.9.3 Second Word of the User Page (Address 0x80800004)
• SSADRR: Secure State End Address for the RAM
• SSADRF: Secure State End Address for the Flash
9.9.3.1 Default user page second word value
The devices are shipped with the User page erased (all bits 1).
9.10 Serial Number
Each device has a unique 120 bits serial number readable from address 0x8080020C to
0x8080021A.
9.11 Module Configuration
The specific configuration for each FLASHCDW instance is listed in the following tables.The
module bus clocks listed here are connected to the system bus clocks. Please refer to the Power
Manager chapter for details.
31 30 29 28 27 26 25 24
SSADRR[15:8]
23 22 21 20 19 18 17 16
SSADRR[7:0]
15 14 13 12 11 10 9 8
SSADRF[15:8]
7 6543210
SSADRF[7:0]
Table 9-11. Module Configuration
Feature
ATUC256L3U,
ATUC256L4U
ATUC128L3U,
ATUC128L4U
ATUC64L3U,
ATUC64L4U
Flash size 256Kbytes 128Kbytes 64Kbytes
Number of pages 512 256 128
Page size 512 bytes 512 bytes 512 bytes
Table 9-12. Module Clock Name
Module Name Clock Name Description
FLASHCDW
CLK_FLASHCDW_HSB Clock for the FLASHCDW HSB interface
CLK_FLASHCDW_PB Clock for the FLASHCDW PB interface
161
32142D–06/2013
ATUC64/128/256L3/4U
Table 9-13. Register Reset Values
Register
ATUC256L3U,
ATUC256L4U
ATUC128L3U,
ATUC128L4U
ATUC64L3U,
ATUC64L4U
FVR 0x00000120 0x00000120 0x00000120
FPR 0x00000409 0x00000407 0x00000405
162
32142D–06/2013
ATUC64/128/256L3/4U
10. Secure Access Unit (SAU)
Rev: 1.1.1.3
10.1 Features
• Remaps registers in memory regions protected by the MPU to regions not protected by the MPU
• Programmable physical address for each channel
• Two modes of operation: Locked and Open
– In Locked Mode, access to a channel must be preceded by an unlock action
• An unlocked channel remains open only for a specific amount of time, if no access is
performed during this time, the channel is relocked
• Only one channel can be open at a time, opening a channel while another one is open
locks the first one
• Access to a locked channel is denied, a bus error and optionally an interrupt is returned
• If a channel is relocked due to an unlock timeout, an interrupt can optionally be
generated
– In Open Mode, all channels are permanently unlocked
10.2 Overview
In many systems, erroneous access to peripherals can lead to catastrophic failure. An example
of such a peripheral is the Pulse Width Modulator (PWM) used to control electric motors. The
PWM outputs a pulse train that controls the motor. If the control registers of the PWM module
are inadvertently updated with wrong values, the motor can start operating out of control, possibly
causing damage to the application and the surrounding environment. However, sometimes
the PWM control registers must be updated with new values, for example when modifying the
pulse train to accelerate the motor. A mechanism must be used to protect the PWM control registers
from inadvertent access caused by for example:
• Errors in the software code
• Transient errors in the CPU caused by for example electrical noise altering the execution path
of the program
To improve the security in a computer system, the AVR32UC implements a Memory Protection
Unit (MPU). The MPU can be set up to limit the accesses that can be performed to specific
memory addresses. The MPU divides the memory space into regions, and assigns a set of
access restrictions on each region. Access restrictions can for example be read/write if the CPU
is in supervisor mode, and read-only if the CPU is in application mode. The regions can be of different
size, but each region is usually quite large, e.g. protecting 1 kilobyte of address space or
more. Furthermore, access to each region is often controlled by the execution state of the CPU,
i.e. supervisor or application mode. Such a simple control mechanism is often too inflexible (too
coarse-grained chunks) and with too much overhead (often requiring system calls to access protected
memory locations) for simple or real-time systems such as embedded microcontrollers.
Usually, the Secure Access Unit (SAU) is used together with the MPU to provide the required
security and integrity. The MPU is set up to protect regions of memory, while the SAU is set up
to provide a secure channel into specific memory locations that are protected by the MPU.
These specific locations can be thought of as fine-grained overrides of the general coarsegrained
protection provided by the MPU.
163
32142D–06/2013
ATUC64/128/256L3/4U
10.3 Block Diagram
Figure 10-1 presents the SAU integrated in an example system with a CPU, some memories,
some peripherals, and a bus system. The SAU is connected to both the Peripheral Bus (PB) and
the High Speed Bus (HSB). Configuration of the SAU is done via the PB, while memory
accesses are done via the HSB. The SAU receives an access on its HSB slave interface,
remaps it, checks that the channel is unlocked, and if so, initiates a transfer on its HSB master
interface to the remapped address.
The thin arrows in Figure 10-1 exemplifies control flow when using the SAU. The CPU wants to
read the RX Buffer in the USART. The MPU has been configured to protect all registers in the
USART from user mode access, while the SAU has been configured to remap the RX Buffer into
a memory space that is not protected by the MPU. This unprotected memory space is mapped
into the SAU HSB slave space. When the CPU reads the appropriate address in the SAU, the
SAU will perform an access to the desired RX buffer register in the USART, and thereafter return
the read results to the CPU. The return data flow will follow the opposite direction of the control
flow arrows in Figure 10-1.
Figure 10-1. SAU Block Diagram
SAU Channel
Bus master
MPU
CPU
Bus slave
USART
PWM
Bus slave Bus master
Bus slave
Flash
Bus slave
RAM
Bus bridge
SAU Configuration
Interrupt
request
High Speed Bus
SAU
Peripheral Bus
164
32142D–06/2013
ATUC64/128/256L3/4U
10.4 Product Dependencies
In order to use this module, other parts of the system must be configured correctly, as described
below.
10.4.1 Power Management
If the CPU enters a sleep mode that disables clocks used by the SAU, the SAU will stop functioning
and resume operation after the system wakes up from sleep mode.
10.4.2 Clocks
The SAU has two bus clocks connected: One High Speed Bus clock (CLK_SAU_HSB) and one
Peripheral Bus clock (CLK_SAU_PB). These clocks are generated by the Power Manager. Both
clocks are enabled at reset, and can be disabled by writing to the Power Manager. The user has
to ensure that CLK_SAU_HSB is not turned off before accessing the SAU. Likewise, the user
must ensure that no bus access is pending in the SAU before disabling CLK_SAU_HSB. Failing
to do so may deadlock the High Speed Bus.
10.4.3 Interrupt
The SAU interrupt request line is connected to the interrupt controller. Using the SAU interrupt
requires the interrupt controller to be programmed first.
10.4.4 Debug Operation
When an external debugger forces the CPU into debug mode, the SAU continues normal operation.
If the SAU is configured in a way that requires it to be periodically serviced by the CPU
through interrupts or similar, improper operation or data loss may result during debugging.
10.5 Functional Description
10.5.1 Enabling the SAU
The SAU is enabled by writing a one to the Enable (EN) bit in the Control Register (CR). This will
set the SAU Enabled (EN) bit in the Status Register (SR).
10.5.2 Configuring the SAU Channels
The SAU has a set of channels, mapped in the HSB memory space. These channels can be
configured by a Remap Target Register (RTR), located at the same memory address. When the
SAU is in normal mode, the SAU channel is addressed, and when the SAU is in setup mode, the
RTR can be addressed.
Before the SAU can be used, the channels must be configured and enabled. To configure a
channel, the corresponding RTR must be programmed with the Remap Target Address. To do
this, make sure the SAU is in setup mode by writing a one to the Setup Mode Enable (SEN) bit
in CR. This makes sure that a write to the RTR address accesses the RTR, not the SAU channel.
Thereafter, the RTR is written with the address to remap to, typically the address of a
specific PB register. When all channels have been configured, return to normal mode by writing
a one to the Setup Mode Disable (SDIS) in CR. The channels can now be enabled by writing
ones to the corresponding bits in the Channel Enable Registers (CERH/L).
The SAU is only able to remap addresses above 0xFFFC0000.
165
32142D–06/2013
ATUC64/128/256L3/4U
10.5.2.1 Protecting SAU configuration registers
In order to prevent the SAU configuration registers to be changed by malicious or runaway code,
they should be protected by the MPU as soon as they have been configured. Maximum security
is provided in the system if program memory does not contain any code to unprotect the configuration
registers in the MPU. This guarantees that runaway code can not accidentally unprotect
and thereafter change the SAU configuration registers.
10.5.3 Lock Mechanism
The SAU can be configured to use two different access mechanisms: Open and Locked. In
Open Mode, SAU channels can be accessed freely after they have been configured and
enabled. In order to prevent accidental accesses to remapped addresses, it is possible to configure
the SAU in Locked Mode. Writing a one to the Open Mode bit in the CONFIG register
(CONFIG.OPEN) will enable Open Mode. Writing a zero to CONFIG.OPEN will enable Locked
Mode.
When using Locked Mode, the lock mechanism must be configured by writing a user defined key
value to the Unlock Key (UKEY) field in the Configuration Register (CONFIG). The number of
CLK_SAU_HSB cycles the channel remains unlocked must be written to the Unlock Number of
Clock Cycles (UCYC) field in CONFIG.
Access control to the SAU channels is enabled by means of the Unlock Register (UR), which
resides in the same address space as the SAU channels. Before a channel can be accessed,
the unlock register must be written with th correct key and channel number (single write access).
Access to the channel is then permitted for the next CONFIG.UCYC clock cycles, or until a successful
access to the unlocked channel has been made.
Only one channel can be unlocked at a time. If any other channel is unlocked at the time of writing
UR, this channel will be automatically locked before the channel addressed by the UR write
is unlocked.
An attempted access to a locked channel will be aborted, and the Channel Access Unsuccessful
bit (SR.CAU) will be set.
Any pending errors bits in SR must be cleared before it is possible to access UR. The following
SR bits are defined as error bits: EXP, CAU, URREAD, URKEY, URES, MBERROR, RTRADR.
If any of these bits are set while writing to UR, the write is aborted and the Unlock Register Error
Status (URES) bit in SR is set.
10.5.4 Normal Operation
The following sequence must be used in order to access a SAU channel in normal operation
(CR.SEN=0):
1. If not in Open Mode, write the unlock key to UR.KEY and the channel number to
UR.CHANNEL.
2. Perform the read or write operation to the SAU channel. If not in Open Mode, this must
be done within CONFIG.UCYC clock cycles of unlocking the channel. The SAU will use
its HSB master interface to remap the access to the target address pointed to by the
corresponding RTR.
3. To confirm that the access was successful, wait for the IDLE transfer status bit
(SR.IDLE) to indicate the operation is completed. Then check SR for possible error conditions.
The SAU can be configured to generate interrupt requests or a Bus Error
Exception if the access failed.
166
32142D–06/2013
ATUC64/128/256L3/4U
10.5.4.1 Operation example
Figure 10-2 shows a typical memory map, consisting of some memories, some simple peripherals,
and a SAU with multiple channels and an Unlock Register (UR). Imagine that the MPU has
been set up to disallow all accesses from the CPU to the grey modules. Thus the CPU has no
way of accessing for example the Transmit Holding register in the UART, present on address X
on the bus. Note that the SAU RTRs are not protected by the MPU, thus the RTRs can be
accessed. If for example RTR0 is configured to point to address X, an access to RTR0 will be
remapped by the SAU to address X according to the algorithm presented above. By programming
the SAU RTRs, specific addresses in modules that have generally been protected by the
MPU can be performed.
Figure 10-2. Example Memory Map for a System with SAU
10.5.5 Interrupts
The SAU can generate an interrupt request to signal different events. All events that can generate
an interrupt request have dedicated bits in the Status Register (SR). An interrupt request will
be generated if the corresponding bit in the Interrupt Mask Register (IMR) is set. Bits in IMR are
set by writing a one to the corresponding bit in the Interrupt Enable Register (IER), and cleared
by writing a one to the corresponding bit in the Interrupt Disable Register (IDR). The interrupt
request remains active until the corresponding bit in SR is cleared by writing a one to the corresponding
bit in the Interrupt Clear Register (ICR).
The following SR bits are used for signalling the result of SAU accesses:
• RTR Address Error (RTRADR) is set if an illegal address is written to the RTRs. Only
addresses in the range 0xFFFC0000-0xFFFFFFFF are allowed.
• Master Interface Bus Error (MBERROR) is set if any of the conditions listed in Section 10.5.7
occurred.
Transmit Holding
Baudrate
Control
Receive Holding
Channel 1
RTR0
RTR1
Address X
Address Z
UART
SAU
CONFIG
SAU
CHANNEL
UR
RTR62 ...
167
32142D–06/2013
ATUC64/128/256L3/4U
• Unlock Register Error Status (URES) is set if an attempt was made to unlock a channel by
writing to the Unlock Register while one or more error bits in SR were set (see Section
10.5.6). The unlock operation was aborted.
• Unlock Register Key Error (URKEY) is set if the Unlock Register was attempted written with
an invalid key.
• Unlock Register Read (URREAD) is set if the Unlock Register was attempted read.
• Channel Access Unsuccessful (CAU) is set if the channel access was unsuccessful.
• Channel Access Successful (CAS) is set if the channel access was successful.
• Channel Unlock Expired (EXP) is set if the channel lock expired, with no channel being
accessed after the channel was unlocked.
10.5.6 Error bits
If error bits are set when attempting to unlock a channel, SR.URES will be set. The following SR
bits are considered error bits:
• EXP
• CAU
• URREAD
• URKEY
• URES
• MBERROR
• RTRADR
10.5.7 Bus Error Responses
By writing a one to the Bus Error Response Enable bit (CR.BERREN), serious access errors will
be configured to return a bus error to the CPU. This will cause the CPU to execute its Bus Error
Data Fetch exception routine.
The conditions that can generate a bus error response are:
• Reading the Unlock Register
• Trying to access a locked channel
• The SAU HSB master receiving a bus error response from its addressed slave
10.5.8 Disabling the SAU
To disable the SAU, the user must first ensure that no SAU bus operations are pending. This
can be done by checking that the SR.IDLE bit is set.
The SAU may then be disabled by writing a one to the Disable (DIS) bit in CR.
168
32142D–06/2013
ATUC64/128/256L3/4U
10.6 User Interface
The following addresses are used by SAU channel configuration registers. All offsets are relative to the SAU’s PB base
address.
Note: 1. The reset values are device specific. Please refer to the Module Configuration section at the end of this chapter.
The following addresses are used by SAU channel registers. All offsets are relative to the SAU’s HSB base address. The
number of channels implemented is device specific, refer to the Module Configuration section at the end of this chapter.
Table 10-1. SAU Configuration Register Memory Map
Offset Register Register Name Access Reset
0x00 Control Register CR Write-only 0x00000000
0x04 Configuration Register CONFIG Write-only 0x00000000
0x08 Channel Enable Register High CERH Read/Write 0x00000000
0x0C Channel Enable Register Low CERL Read/Write 0x00000000
0x10 Status Register SR Read-only 0x00000400
0x14 Interrupt Enable Register IER Write-only 0x00000000
0x18 Interrupt Disable Register IDR Write-only 0x00000000
0x1C Interrupt Mask Register IMR Read-only 0x00000000
0x20 Interrupt Clear Register ICR Write-only 0x00000000
0x24 Parameter Register PARAMETER Read-only -(1)
0x28 Version Register VERSION Read-only -(1)
Table 10-2. SAU Channel Register Memory Map
Offset Register Register Name Access Reset
0x00 Remap Target Register 0 RTR0 Read/Write N/A
0x04 Remap Target Register 1 RTR1 Read/Write N/A
0x08 Remap Target Register 2 RTR2 Read/Write N/A
... ... ... ... ...
0x04*n Remap Target Register n RTRn Read/Write N/A
0xFC Unlock Register UR Write-only N/A
169
32142D–06/2013
ATUC64/128/256L3/4U
10.6.1 Control Register
Name: CR
Access Type: Write-only
Offset: 0x00
Reset Value: 0x00000000
• BERRDIS: Bus Error Response Disable
Writing a zero to this bit has no effect.
Writing a one to this bit disables Bus Error Response from the SAU.
• BERREN: Bus Error Response Enable
Writing a zero to this bit has no effect.
Writing a one to this bit enables Bus Error Response from the SAU.
• SDIS: Setup Mode Disable
Writing a zero to this bit has no effect.
Writing a one to this bit exits setup mode.
• SEN: Setup Mode Enable
Writing a zero to this bit has no effect.
Writing a one to this bit enters setup mode.
• DIS: SAU Disable
Writing a zero to this bit has no effect.
Writing a one to this bit disables the SAU.
• EN: SAU Enable
Writing a zero to this bit has no effect.
Writing a one to this bit enables the SAU.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
- - BERRDIS BERREN SDIS SEN DIS EN
170
32142D–06/2013
ATUC64/128/256L3/4U
10.6.2 Configuration Register
Name: CONFIG
Access Type: Write-only
Offset: 0x04
Reset Value: 0x00000000
• OPEN: Open Mode Enable
Writing a zero to this bit disables open mode.
Writing a one to this bit enables open mode.
• UCYC: Unlock Number of Clock Cycles
Once a channel has been unlocked, it remains unlocked for this amount of CLK_SAU_HSB clock cycles or until one access to a
channel has been made.
• UKEY: Unlock Key
The value in this field must be written to UR.KEY to unlock a channel.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
- - - - - - - OPEN
15 14 13 12 11 10 9 8
UCYC
76543210
UKEY
171
32142D–06/2013
ATUC64/128/256L3/4U
10.6.3 Channel Enable Register High
Name: CERH
Access Type: Read/Write
Offset: 0x08
Reset Value: 0x00000000
• CERH[n]: Channel Enable Register High
0: Channel (n+32) is not enabled.
1: Channel (n+32) is enabled.
31 30 29 28 27 26 25 24
- CERH[30:24]
23 22 21 20 19 18 17 16
CERH[23:16]
15 14 13 12 11 10 9 8
CERH[15:8]
76543210
CERH[7:0]
172
32142D–06/2013
ATUC64/128/256L3/4U
10.6.4 Channel Enable Register Low
Name: CERL
Access Type: Read/Write
Offset: 0x0C
Reset Value: 0x00000000
• CERL[n]: Channel Enable Register Low
0: Channel n is not enabled.
1: Channel n is enabled.
31 30 29 28 27 26 25 24
CERL[31:24]
23 22 21 20 19 18 17 16
CERL[23:16]
15 14 13 12 11 10 9 8
CERL[15:8]
76543210
CERL[7:0]
173
32142D–06/2013
ATUC64/128/256L3/4U
10.6.5 Status Register
Name: SR
Access Type: Read-only
Offset: 0x10
Reset Value: 0x00000400
• IDLE
This bit is cleared when a read or write operation to the SAU channel is started.
This bit is set when the operation is completed and no SAU bus operations are pending.
• SEN: SAU Setup Mode Enable
This bit is cleared when the SAU exits setup mode.
This bit is set when the SAU enters setup mode.
• EN: SAU Enabled
This bit is cleared when the SAU is disabled.
This bit is set when the SAU is enabled.
• RTRADR: RTR Address Error
This bit is cleared when the corresponding bit in ICR is written to one.
This bit is set if, in the configuration phase, an RTR was written with an illegal address, i.e. the upper 16 bits in the address were
different from 0xFFFC, 0xFFFD, 0xFFFE or 0xFFFF.
• MBERROR: Master Interface Bus Error
This bit is cleared when the corresponding bit in ICR is written to one.
This bit is set if a channel access generated a transfer on the master interface that received a bus error response from the
addressed slave.
• URES: Unlock Register Error Status
This bit is cleared when the corresponding bit in ICR is written to one.
This bit is set if an attempt was made to unlock a channel by writing to the Unlock Register while one or more error bits were set
in SR. The unlock operation was aborted.
• URKEY: Unlock Register Key Error
This bit is cleared when the corresponding bit in ICR is written to one.
This bit is set if the Unlock Register was attempted written with an invalid key.
• URREAD: Unlock Register Read
This bit is cleared when the corresponding bit in ICR is written to one.
This bit is set if the Unlock Register was read.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
- - - - - IDLE SEN EN
76543210
RTRADR MBERROR URES URKEY URREAD CAU CAS EXP
174
32142D–06/2013
ATUC64/128/256L3/4U
• CAU: Channel Access Unsuccessful
This bit is cleared when the corresponding bit in ICR is written to one.
This bit is set if channel access was unsuccessful, i.e. an access was attempted to a locked or disabled channel.
• CAS: Channel Access Successful
This bit is cleared when the corresponding bit in ICR is written to one.
This bit is set if channel access successful, i.e. one access was made after the channel was unlocked.
• EXP: Channel Unlock Expired
This bit is cleared when the corresponding bit in ICR is written to one.
This bit is set if channel unlock has expired, i.e. no access being made after the channel was unlocked.
175
32142D–06/2013
ATUC64/128/256L3/4U
10.6.6 Interrupt Enable Register
Name: IER
Access Type: Write-only
Offset: 0x14
Reset Value: 0x00000000
Writing a zero to a bit in this register has no effect.
Writing a one to a bit in this register will set the corresponding bit in IMR.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
RTRADR MBERROR URES URKEY URREAD CAU CAS EXP
176
32142D–06/2013
ATUC64/128/256L3/4U
10.6.7 Interrupt Disable Register
Name: IDR
Access Type: Write-only
Offset: 0x18
Reset Value: 0x00000000
Writing a zero to a bit in this register has no effect.
Writing a one to a bit in this register will clear the corresponding bit in IMR.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
RTRADR MBERROR URES URKEY URREAD CAU CAS EXP
177
32142D–06/2013
ATUC64/128/256L3/4U
10.6.8 Interrupt Mask Register
Name: IMR
Access Type: Read-only
Offset: 0x1C
Reset Value: 0x00000000
0: The corresponding interrupt is disabled.
1: The corresponding interrupt is enabled.
A bit in this register is cleared when the corresponding bit in IDR is written to one.
A bit in this register is set when the corresponding bit in IER is written to one.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
RTRADR MBERROR URES URKEY URREAD CAU CAS EXP
178
32142D–06/2013
ATUC64/128/256L3/4U
10.6.9 Interrupt Clear Register
Name: ICR
Access Type: Write-only
Offset: 0x20
Reset Value: 0x00000000
Writing a zero to a bit in this register has no effect.
Writing a one to a bit in this register will clear the corresponding bit in SR and any corresponding interrupt request.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
RTRADR MBERROR URES URKEY URREAD CAU CAS EXP
179
32142D–06/2013
ATUC64/128/256L3/4U
10.6.10 Parameter Register
Name: PARAMETER
Access Type: Read-only
Offset: 0x24
Reset Value: -
• CHANNELS:
Number of channels implemented.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
- - CHANNELS
180
32142D–06/2013
ATUC64/128/256L3/4U
10.6.11 Version Register
Name: VERSION
Access Type: Write-only
Offset: 0x28
Reset Value: -
• VARIANT: Variant Number
Reserved. No functionality associated.
• VERSION: Version Number
Version number of the module. No functionality associated.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
- - - - VARIANT
15 14 13 12 11 10 9 8
- - - - VERSION[11:8]
76543210
VERSION[7:0]
181
32142D–06/2013
ATUC64/128/256L3/4U
10.6.12 Remap Target Register n
Name: RTRn
Access Type: Read/Write
Offset: n*4
Reset Value: 0x00000000
• RTR: Remap Target Address for Channel n
RTR[31:16] must have one of the following values, any other value will result in UNDEFINED behavior:
0xFFFC
0xFFFD
0xFFFE
0xFFFF
RTR[1:0] must be written to 00, any other value will result in UNDEFINED behavior.
31 30 29 28 27 26 25 24
RTR[31:24]
23 22 21 20 19 18 17 16
RTR[23:16]
15 14 13 12 11 10 9 8
RTR[15:8]
76543210
RTR[7:0]
182
32142D–06/2013
ATUC64/128/256L3/4U
10.6.13 Unlock Register
Name: UR
Access Type : Write-only
Offset: 0xFC
Reset Value: 0x00000000
• KEY: Unlock Key
The correct key must be written in order to unlock a channel. The key value written must correspond to the key value defined in
CONFIG.UKEY.
• CHANNEL: Channel Number
Number of the channel to unlock.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
KEY
76543210
- - CHANNEL
183
32142D–06/2013
ATUC64/128/256L3/4U
10.7 Module Configuration
The specific configuration for each SAU instance is listed in the following tables.The module bus
clocks listed here are connected to the system bus clocks. Please refer to the Power Manager
chapter for details.
Table 10-3. SAU configuration
Feature SAU
SAU Channels 16
Table 10-4. SAU clock name
Module name Clock name Description
SAU CLK_SAU_HSB Clock for the SAU HSB interface
SAU CLK_SAU_PB Clock for the SAU PB interface
Table 10-5. Register Reset Values
Register Reset Value
VERSION 0x00000111
PARAMETER 0x00000010
184
32142D–06/2013
ATUC64/128/256L3/4U
11. HSB Bus Matrix (HMATRIXB)
Rev: 1.3.0.3
11.1 Features
• User Interface on peripheral bus
• Configurable number of masters (up to 16)
• Configurable number of slaves (up to 16)
• One decoder for each master
• Programmable arbitration for each slave
– Round-Robin
– Fixed priority
• Programmable default master for each slave
– No default master
– Last accessed default master
– Fixed default master
• One cycle latency for the first access of a burst
• Zero cycle latency for default master
• One special function register for each slave (not dedicated)
11.2 Overview
The Bus Matrix implements a multi-layer bus structure, that enables parallel access paths
between multiple High Speed Bus (HSB) masters and slaves in a system, thus increasing the
overall bandwidth. The Bus Matrix interconnects up to 16 HSB Masters to up to 16 HSB Slaves.
The normal latency to connect a master to a slave is one cycle except for the default master of
the accessed slave which is connected directly (zero cycle latency). The Bus Matrix provides 16
Special Function Registers (SFR) that allow the Bus Matrix to support application specific
features.
11.3 Product Dependencies
In order to configure this module by accessing the user registers, other parts of the system must
be configured correctly, as described below.
11.3.1 Clocks
The clock for the HMATRIX bus interface (CLK_HMATRIX) is generated by the Power Manager.
This clock is enabled at reset, and can be disabled in the Power Manager.
11.4 Functional Description
11.4.1 Special Bus Granting Mechanism
The Bus Matrix provides some speculative bus granting techniques in order to anticipate access
requests from some masters. This mechanism reduces latency at first access of a burst or single
transfer. This bus granting mechanism sets a different default master for every slave.
At the end of the current access, if no other request is pending, the slave remains connected to
its associated default master. A slave can be associated with three kinds of default masters: no
default master, last access master, and fixed default master.
185
32142D–06/2013
ATUC64/128/256L3/4U
To change from one kind of default master to another, the Bus Matrix user interface provides the
Slave Configuration Registers, one for each slave, that set a default master for each slave. The
Slave Configuration Register contains two fields: DEFMSTR_TYPE and FIXED_DEFMSTR. The
2-bit DEFMSTR_TYPE field selects the default master type (no default, last access master, fixed
default master), whereas the 4-bit FIXED_DEFMSTR field selects a fixed default master provided
that DEFMSTR_TYPE is set to fixed default master. Please refer to the Bus Matrix user
interface description.
11.4.1.1 No Default Master
At the end of the current access, if no other request is pending, the slave is disconnected from
all masters. No Default Master suits low-power mode.
11.4.1.2 Last Access Master
At the end of the current access, if no other request is pending, the slave remains connected to
the last master that performed an access request.
11.4.1.3 Fixed Default Master
At the end of the current access, if no other request is pending, the slave connects to its fixed
default master. Unlike last access master, the fixed master does not change unless the user
modifies it by a software action (field FIXED_DEFMSTR of the related SCFG).
11.4.2 Arbitration
The Bus Matrix provides an arbitration mechanism that reduces latency when conflict cases
occur, i.e. when two or more masters try to access the same slave at the same time. One arbiter
per HSB slave is provided, thus arbitrating each slave differently.
The Bus Matrix provides the user with the possibility of choosing between 2 arbitration types for
each slave:
1. Round-Robin Arbitration (default)
2. Fixed Priority Arbitration
This is selected by the ARBT field in the Slave Configuration Registers (SCFG).
Each algorithm may be complemented by selecting a default master configuration for each
slave.
When a re-arbitration must be done, specific conditions apply. This is described in “Arbitration
Rules” .
11.4.2.1 Arbitration Rules
Each arbiter has the ability to arbitrate between two or more different master requests. In order
to avoid burst breaking and also to provide the maximum throughput for slave interfaces, arbitration
may only take place during the following cycles:
1. Idle Cycles: When a slave is not connected to any master or is connected to a master
which is not currently accessing it.
2. Single Cycles: When a slave is currently doing a single access.
3. End of Burst Cycles: When the current cycle is the last cycle of a burst transfer. For
defined length burst, predicted end of burst matches the size of the transfer but is managed
differently for undefined length burst. This is described below.
4. Slot Cycle Limit: When the slot cycle counter has reached the limit value indicating that
the current master access is too long and must be broken. This is described below.
186
32142D–06/2013
ATUC64/128/256L3/4U
• Undefined Length Burst Arbitration
In order to avoid long slave handling during undefined length bursts (INCR), the Bus Matrix provides
specific logic in order to re-arbitrate before the end of the INCR transfer. A predicted end
of burst is used as a defined length burst transfer and can be selected among the following five
possibilities:
1. Infinite: No predicted end of burst is generated and therefore INCR burst transfer will
never be broken.
2. One beat bursts: Predicted end of burst is generated at each single transfer inside the
INCP transfer.
3. Four beat bursts: Predicted end of burst is generated at the end of each four beat
boundary inside INCR transfer.
4. Eight beat bursts: Predicted end of burst is generated at the end of each eight beat
boundary inside INCR transfer.
5. Sixteen beat bursts: Predicted end of burst is generated at the end of each sixteen beat
boundary inside INCR transfer.
This selection can be done through the ULBT field in the Master Configuration Registers
(MCFG).
• Slot Cycle Limit Arbitration
The Bus Matrix contains specific logic to break long accesses, such as very long bursts on a
very slow slave (e.g., an external low speed memory). At the beginning of the burst access, a
counter is loaded with the value previously written in the SLOT_CYCLE field of the related Slave
Configuration Register (SCFG) and decreased at each clock cycle. When the counter reaches
zero, the arbiter has the ability to re-arbitrate at the end of the current byte, halfword, or word
transfer.
11.4.2.2 Round-Robin Arbitration
This algorithm allows the Bus Matrix arbiters to dispatch the requests from different masters to
the same slave in a round-robin manner. If two or more master requests arise at the same time,
the master with the lowest number is first serviced, then the others are serviced in a round-robin
manner.
There are three round-robin algorithms implemented:
1. Round-Robin arbitration without default master
2. Round-Robin arbitration with last default master
3. Round-Robin arbitration with fixed default master
• Round-Robin Arbitration without Default Master
This is the main algorithm used by Bus Matrix arbiters. It allows the Bus Matrix to dispatch
requests from different masters to the same slave in a pure round-robin manner. At the end of
the current access, if no other request is pending, the slave is disconnected from all masters.
This configuration incurs one latency cycle for the first access of a burst. Arbitration without
default master can be used for masters that perform significant bursts.
• Round-Robin Arbitration with Last Default Master
This is a biased round-robin algorithm used by Bus Matrix arbiters. It allows the Bus Matrix to
remove the one latency cycle for the last master that accessed the slave. At the end of the cur-
187
32142D–06/2013
ATUC64/128/256L3/4U
rent transfer, if no other master request is pending, the slave remains connected to the last
master that performed the access. Other non privileged masters still get one latency cycle if they
want to access the same slave. This technique can be used for masters that mainly perform single
accesses.
• Round-Robin Arbitration with Fixed Default Master
This is another biased round-robin algorithm. It allows the Bus Matrix arbiters to remove the one
latency cycle for the fixed default master per slave. At the end of the current access, the slave
remains connected to its fixed default master. Every request attempted by this fixed default master
will not cause any latency whereas other non privileged masters will still get one latency
cycle. This technique can be used for masters that mainly perform single accesses.
11.4.2.3 Fixed Priority Arbitration
This algorithm allows the Bus Matrix arbiters to dispatch the requests from different masters to
the same slave by using the fixed priority defined by the user. If two or more master requests are
active at the same time, the master with the highest priority number is serviced first. If two or
more master requests with the same priority are active at the same time, the master with the
highest number is serviced first.
For each slave, the priority of each master may be defined through the Priority Registers for
Slaves (PRAS and PRBS).
11.4.3 Slave and Master assignation
The index number assigned to Bus Matrix slaves and masters are described in the Module Configuration
section at the end of this chapter.
188
32142D–06/2013
ATUC64/128/256L3/4U
11.5 User Interface
Table 11-1. HMATRIX Register Memory Map
Offset Register Name Access Reset Value
0x0000 Master Configuration Register 0 MCFG0 Read/Write 0x00000002
0x0004 Master Configuration Register 1 MCFG1 Read/Write 0x00000002
0x0008 Master Configuration Register 2 MCFG2 Read/Write 0x00000002
0x000C Master Configuration Register 3 MCFG3 Read/Write 0x00000002
0x0010 Master Configuration Register 4 MCFG4 Read/Write 0x00000002
0x0014 Master Configuration Register 5 MCFG5 Read/Write 0x00000002
0x0018 Master Configuration Register 6 MCFG6 Read/Write 0x00000002
0x001C Master Configuration Register 7 MCFG7 Read/Write 0x00000002
0x0020 Master Configuration Register 8 MCFG8 Read/Write 0x00000002
0x0024 Master Configuration Register 9 MCFG9 Read/Write 0x00000002
0x0028 Master Configuration Register 10 MCFG10 Read/Write 0x00000002
0x002C Master Configuration Register 11 MCFG11 Read/Write 0x00000002
0x0030 Master Configuration Register 12 MCFG12 Read/Write 0x00000002
0x0034 Master Configuration Register 13 MCFG13 Read/Write 0x00000002
0x0038 Master Configuration Register 14 MCFG14 Read/Write 0x00000002
0x003C Master Configuration Register 15 MCFG15 Read/Write 0x00000002
0x0040 Slave Configuration Register 0 SCFG0 Read/Write 0x00000010
0x0044 Slave Configuration Register 1 SCFG1 Read/Write 0x00000010
0x0048 Slave Configuration Register 2 SCFG2 Read/Write 0x00000010
0x004C Slave Configuration Register 3 SCFG3 Read/Write 0x00000010
0x0050 Slave Configuration Register 4 SCFG4 Read/Write 0x00000010
0x0054 Slave Configuration Register 5 SCFG5 Read/Write 0x00000010
0x0058 Slave Configuration Register 6 SCFG6 Read/Write 0x00000010
0x005C Slave Configuration Register 7 SCFG7 Read/Write 0x00000010
0x0060 Slave Configuration Register 8 SCFG8 Read/Write 0x00000010
0x0064 Slave Configuration Register 9 SCFG9 Read/Write 0x00000010
0x0068 Slave Configuration Register 10 SCFG10 Read/Write 0x00000010
0x006C Slave Configuration Register 11 SCFG11 Read/Write 0x00000010
0x0070 Slave Configuration Register 12 SCFG12 Read/Write 0x00000010
0x0074 Slave Configuration Register 13 SCFG13 Read/Write 0x00000010
0x0078 Slave Configuration Register 14 SCFG14 Read/Write 0x00000010
0x007C Slave Configuration Register 15 SCFG15 Read/Write 0x00000010
0x0080 Priority Register A for Slave 0 PRAS0 Read/Write 0x00000000
0x0084 Priority Register B for Slave 0 PRBS0 Read/Write 0x00000000
0x0088 Priority Register A for Slave 1 PRAS1 Read/Write 0x00000000
189
32142D–06/2013
ATUC64/128/256L3/4U
0x008C Priority Register B for Slave 1 PRBS1 Read/Write 0x00000000
0x0090 Priority Register A for Slave 2 PRAS2 Read/Write 0x00000000
0x0094 Priority Register B for Slave 2 PRBS2 Read/Write 0x00000000
0x0098 Priority Register A for Slave 3 PRAS3 Read/Write 0x00000000
0x009C Priority Register B for Slave 3 PRBS3 Read/Write 0x00000000
0x00A0 Priority Register A for Slave 4 PRAS4 Read/Write 0x00000000
0x00A4 Priority Register B for Slave 4 PRBS4 Read/Write 0x00000000
0x00A8 Priority Register A for Slave 5 PRAS5 Read/Write 0x00000000
0x00AC Priority Register B for Slave 5 PRBS5 Read/Write 0x00000000
0x00B0 Priority Register A for Slave 6 PRAS6 Read/Write 0x00000000
0x00B4 Priority Register B for Slave 6 PRBS6 Read/Write 0x00000000
0x00B8 Priority Register A for Slave 7 PRAS7 Read/Write 0x00000000
0x00BC Priority Register B for Slave 7 PRBS7 Read/Write 0x00000000
0x00C0 Priority Register A for Slave 8 PRAS8 Read/Write 0x00000000
0x00C4 Priority Register B for Slave 8 PRBS8 Read/Write 0x00000000
0x00C8 Priority Register A for Slave 9 PRAS9 Read/Write 0x00000000
0x00CC Priority Register B for Slave 9 PRBS9 Read/Write 0x00000000
0x00D0 Priority Register A for Slave 10 PRAS10 Read/Write 0x00000000
0x00D4 Priority Register B for Slave 10 PRBS10 Read/Write 0x00000000
0x00D8 Priority Register A for Slave 11 PRAS11 Read/Write 0x00000000
0x00DC Priority Register B for Slave 11 PRBS11 Read/Write 0x00000000
0x00E0 Priority Register A for Slave 12 PRAS12 Read/Write 0x00000000
0x00E4 Priority Register B for Slave 12 PRBS12 Read/Write 0x00000000
0x00E8 Priority Register A for Slave 13 PRAS13 Read/Write 0x00000000
0x00EC Priority Register B for Slave 13 PRBS13 Read/Write 0x00000000
0x00F0 Priority Register A for Slave 14 PRAS14 Read/Write 0x00000000
0x00F4 Priority Register B for Slave 14 PRBS14 Read/Write 0x00000000
0x00F8 Priority Register A for Slave 15 PRAS15 Read/Write 0x00000000
0x00FC Priority Register B for Slave 15 PRBS15 Read/Write 0x00000000
0x0110 Special Function Register 0 SFR0 Read/Write –
0x0114 Special Function Register 1 SFR1 Read/Write –
0x0118 Special Function Register 2 SFR2 Read/Write –
0x011C Special Function Register 3 SFR3 Read/Write –
0x0120 Special Function Register 4 SFR4 Read/Write –
0x0124 Special Function Register 5 SFR5 Read/Write –
0x0128 Special Function Register 6 SFR6 Read/Write –
Table 11-1. HMATRIX Register Memory Map (Continued)
Offset Register Name Access Reset Value
190
32142D–06/2013
ATUC64/128/256L3/4U
0x012C Special Function Register 7 SFR7 Read/Write –
0x0130 Special Function Register 8 SFR8 Read/Write –
0x0134 Special Function Register 9 SFR9 Read/Write –
0x0138 Special Function Register 10 SFR10 Read/Write –
0x013C Special Function Register 11 SFR11 Read/Write –
0x0140 Special Function Register 12 SFR12 Read/Write –
0x0144 Special Function Register 13 SFR13 Read/Write –
0x0148 Special Function Register 14 SFR14 Read/Write –
0x014C Special Function Register 15 SFR15 Read/Write –
Table 11-1. HMATRIX Register Memory Map (Continued)
Offset Register Name Access Reset Value
191
32142D–06/2013
ATUC64/128/256L3/4U
11.5.1 Master Configuration Registers
Name: MCFG0...MCFG15
Access Type: Read/Write
Offset: 0x00 - 0x3C
Reset Value: 0x00000002
• ULBT: Undefined Length Burst Type
31 30 29 28 27 26 25 24
––––––––
23 22 21 20 19 18 17 16
––––––––
15 14 13 12 11 10 9 8
––––––––
76543210
– – – – – ULBT
Table 11-2. Undefined Length Burst Type
ULBT Undefined Length Burst Type Description
000 Inifinite Length Burst No predicted end of burst is generated and therefore INCR bursts coming from this
master cannot be broken.
001 Single-Access The undefined length burst is treated as a succession of single accesses, allowing rearbitration
at each beat of the INCR burst.
010 4 Beat Burst The undefined length burst is split into a four-beat burst, allowing re-arbitration at each
four-beat burst end.
011 8 Beat Burst The undefined length burst is split into an eight-beat burst, allowing re-arbitration at
each eight-beat burst end.
100 16 Beat Burst The undefined length burst is split into a sixteen-beat burst, allowing re-arbitration at
each sixteen-beat burst end.
192
32142D–06/2013
ATUC64/128/256L3/4U
11.5.2 Slave Configuration Registers
Name: SCFG0...SCFG15
Access Type: Read/Write
Offset: 0x40 - 0x7C
Reset Value: 0x00000010
• ARBT: Arbitration Type
0: Round-Robin Arbitration
1: Fixed Priority Arbitration
• FIXED_DEFMSTR: Fixed Default Master
This is the number of the Default Master for this slave. Only used if DEFMSTR_TYPE is 2. Specifying the number of a master
which is not connected to the selected slave is equivalent to setting DEFMSTR_TYPE to 0.
• DEFMSTR_TYPE: Default Master Type
0: No Default Master
At the end of the current slave access, if no other master request is pending, the slave is disconnected from all masters.
This results in a one cycle latency for the first access of a burst transfer or for a single access.
1: Last Default Master
At the end of the current slave access, if no other master request is pending, the slave stays connected to the last master having
accessed it.
This results in not having one cycle latency when the last master tries to access the slave again.
2: Fixed Default Master
At the end of the current slave access, if no other master request is pending, the slave connects to the fixed master the number
that has been written in the FIXED_DEFMSTR field.
This results in not having one cycle latency when the fixed master tries to access the slave again.
• SLOT_CYCLE: Maximum Number of Allowed Cycles for a Burst
When the SLOT_CYCLE limit is reached for a burst, it may be broken by another master trying to access this slave.
This limit has been placed to avoid locking a very slow slave when very long bursts are used.
This limit must not be very small. Unreasonably small values break every burst and the Bus Matrix arbitrates without performing
any data transfer. 16 cycles is a reasonable value for SLOT_CYCLE.
31 30 29 28 27 26 25 24
– – – – – – – ARBT
23 22 21 20 19 18 17 16
– – FIXED_DEFMSTR DEFMSTR_TYPE
15 14 13 12 11 10 9 8
––––––––
76543210
SLOT_CYCLE
193
32142D–06/2013
ATUC64/128/256L3/4U
11.5.3 Bus Matrix Priority Registers A For Slaves
Register Name: PRAS0...PRAS15
Access Type: Read/Write
Offset: -
Reset Value: 0x00000000
• MxPR: Master x Priority
Fixed priority of Master x for accessing the selected slave. The higher the number, the higher the priority.
31 30 29 28 27 26 25 24
- - M7PR - - M6PR
23 22 21 20 19 18 17 16
- - M5PR - - M4PR
15 14 13 12 11 10 9 8
- - M3PR - - M2PR
76543210
- - M1PR - - M0PR
194
32142D–06/2013
ATUC64/128/256L3/4U
11.5.4 Priority Registers B For Slaves
Name: PRBS0...PRBS15
Access Type: Read/Write
Offset: -
Reset Value: 0x00000000
• MxPR: Master x Priority
Fixed priority of Master x for accessing the selected slave. The higher the number, the higher the priority.
31 30 29 28 27 26 25 24
- - M15PR - - M14PR
23 22 21 20 19 18 17 16
- - M13PR - - M12PR
15 14 13 12 11 10 9 8
- - M11PR - - M10PR
76543210
- - M9PR - - M8PR
195
32142D–06/2013
ATUC64/128/256L3/4U
11.5.5 Special Function Registers
Name: SFR0...SFR15
Access Type: Read/Write
Offset: 0x110 - 0x14C
Reset Value: -
• SFR: Special Function Register Fields
Those registers are not a HMATRIX specific register. The field of those will be defined where they are used.
31 30 29 28 27 26 25 24
SFR
23 22 21 20 19 18 17 16
SFR
15 14 13 12 11 10 9 8
SFR
76543210
SFR
196
32142D–06/2013
ATUC64/128/256L3/4U
11.6 Module Configuration
The specific configuration for each HMATRIX instance is listed in the following tables.The module
bus clocks listed here are connected to the system bus clocks. Please refer to the Power
Manager chapter for details.
11.6.1 Bus Matrix Connections
The bus matrix has the several masters and slaves. Each master has its own bus and its own
decoder, thus allowing a different memory mapping per master. The master number in the table
below can be used to index the HMATRIX control registers. For example, HMATRIX MCFG0
register is associated with the CPU Data master interface.
Each slave has its own arbiter, thus allowing a different arbitration per slave. The slave number
in the table below can be used to index the HMATRIX control registers. For example, SCFG3 is
associated with the Internal SRAM Slave Interface.
Accesses to unused areas returns an error result to the master requesting such an access.
Table 11-3. HMATRIX Clocks
Clock Name Description
CLK_HMATRIX Clock for the HMATRIX bus interface
Table 11-4. High Speed Bus Masters
Master 0 CPU Data
Master 1 CPU Instruction
Master 2 CPU SAB
Master 3 SAU
Master 4 PDCA
Master 5 USBC
Table 11-5. High Speed Bus Slaves
Slave 0 Internal Flash
Slave 1 HSB-PB Bridge A
Slave 2 HSB-PB Bridge B
Slave 3 Internal SRAM
Slave 4 SAU
197
32142D–06/2013
ATUC64/128/256L3/4U
Figure 11-1. HMatrix Master / Slave Connections
CPU Data 0
CPU
Instruction 1
CPU SAB 2
SAU 3
Internal Flash
0
HSB-PB
Bridge 0
1
HSB-PB
Bridge 1
2
Internal SRAM
3
HMATRIX SLAVES
HMATRIX MASTERS
SAU
4
PDCA 4
USBC 5
198
32142D–06/2013
ATUC64/128/256L3/4U
12. Interrupt Controller (INTC)
Rev: 1.0.2.5
12.1 Features
• Autovectored low latency interrupt service with programmable priority
– 4 priority levels for regular, maskable interrupts
– One Non-Maskable Interrupt
• Up to 64 groups of interrupts with up to 32 interrupt requests in each group
12.2 Overview
The INTC collects interrupt requests from the peripherals, prioritizes them, and delivers an interrupt
request and an autovector to the CPU. The AVR32 architecture supports 4 priority levels for
regular, maskable interrupts, and a Non-Maskable Interrupt (NMI).
The INTC supports up to 64 groups of interrupts. Each group can have up to 32 interrupt request
lines, these lines are connected to the peripherals. Each group has an Interrupt Priority Register
(IPR) and an Interrupt Request Register (IRR). The IPRs are used to assign a priority level and
an autovector to each group, and the IRRs are used to identify the active interrupt request within
each group. If a group has only one interrupt request line, an active interrupt group uniquely
identifies the active interrupt request line, and the corresponding IRR is not needed. The INTC
also provides one Interrupt Cause Register (ICR) per priority level. These registers identify the
group that has a pending interrupt of the corresponding priority level. If several groups have a
pending interrupt of the same level, the group with the lowest number takes priority.
12.3 Block Diagram
Figure 12-1 gives an overview of the INTC. The grey boxes represent registers that can be
accessed via the user interface. The interrupt requests from the peripherals (IREQn) and the
NMI are input on the left side of the figure. Signals to and from the CPU are on the right side of
the figure.
199
32142D–06/2013
ATUC64/128/256L3/4U
Figure 12-1. INTC Block Diagram
12.4 Product Dependencies
In order to use this module, other parts of the system must be configured correctly, as described
below.
12.4.1 Power Management
If the CPU enters a sleep mode that disables CLK_SYNC, the INTC will stop functioning and
resume operation after the system wakes up from sleep mode.
12.4.2 Clocks
The clock for the INTC bus interface (CLK_INTC) is generated by the Power Manager. This
clock is enabled at reset, and can be disabled in the Power Manager.
The INTC sampling logic runs on a clock which is stopped in any of the sleep modes where the
system RC oscillator is not running. This clock is referred to as CLK_SYNC. This clock is
enabled at reset, and only turned off in sleep modes where the system RC oscillator is stopped.
12.4.3 Debug Operation
When an external debugger forces the CPU into debug mode, the INTC continues normal
operation.
12.5 Functional Description
All of the incoming interrupt requests (IREQs) are sampled into the corresponding Interrupt
Request Register (IRR). The IRRs must be accessed to identify which IREQ within a group that
is active. If several IREQs within the same group are active, the interrupt service routine must
prioritize between them. All of the input lines in each group are logically ORed together to form
the GrpReqN lines, indicating if there is a pending interrupt in the corresponding group.
The Request Masking hardware maps each of the GrpReq lines to a priority level from INT0 to
INT3 by associating each group with the Interrupt Level (INTLEVEL) field in the corresponding
Request
Masking
OR
IREQ0
IREQ1
IREQ2
IREQ31
GrpReq0
Masks SREG
Masks
I[3-0]M
GM
INTLEVEL
AUTOVECTOR
Prioritizer
Interrupt Controller CPU
OR GrpReqN
NMIREQ
OR
IREQ32
IREQ33
IREQ34
IREQ63
GrpReq1
IRR Registers IPR Registers ICR Registers
INT_level,
offset
INT_level,
offset
INT_level,
offset
IPR0
IPR1
IPRn
IRR0
IRR1
IRRn
ValReq0
ValReq1
ValReqN
.
.
.
.
.
.
.
.
.
200
32142D–06/2013
ATUC64/128/256L3/4U
Interrupt Priority Register (IPR). The GrpReq inputs are then masked by the mask bits from the
CPU status register. Any interrupt group that has a pending interrupt of a priority level that is not
masked by the CPU status register, gets its corresponding ValReq line asserted.
Masking of the interrupt requests is done based on five interrupt mask bits of the CPU status
register, namely Interrupt Level 3 Mask (I3M) to Interrupt Level 0 Mask (I0M), and Global Interrupt
Mask (GM). An interrupt request is masked if either the GM or the corresponding interrupt
level mask bit is set.
The Prioritizer hardware uses the ValReq lines and the INTLEVEL field in the IPRs to select the
pending interrupt of the highest priority. If an NMI interrupt request is pending, it automatically
gets the highest priority of any pending interrupt. If several interrupt groups of the highest pending
interrupt level have pending interrupts, the interrupt group with the lowest number is
selected.
The INTLEVEL and handler autovector offset (AUTOVECTOR) of the selected interrupt are
transmitted to the CPU for interrupt handling and context switching. The CPU does not need to
know which interrupt is requesting handling, but only the level and the offset of the handler
address. The IRR registers contain the interrupt request lines of the groups and can be read via
user interface registers for checking which interrupts of the group are actually active.
The delay through the INTC from the peripheral interrupt request is set until the interrupt request
to the CPU is set is three cycles of CLK_SYNC.
12.5.1 Non-Maskable Interrupts
A NMI request has priority over all other interrupt requests. NMI has a dedicated exception vector
address defined by the AVR32 architecture, so AUTOVECTOR is undefined when
INTLEVEL indicates that an NMI is pending.
12.5.2 CPU Response
When the CPU receives an interrupt request it checks if any other exceptions are pending. If no
exceptions of higher priority are pending, interrupt handling is initiated. When initiating interrupt
handling, the corresponding interrupt mask bit is set automatically for this and lower levels in status
register. E.g, if an interrupt of level 3 is approved for handling, the interrupt mask bits I3M,
I2M, I1M, and I0M are set in status register. If an interrupt of level 1 is approved, the masking
bits I1M and I0M are set in status register. The handler address is calculated by logical OR of
the AUTOVECTOR to the CPU system register Exception Vector Base Address (EVBA). The
CPU will then jump to the calculated address and start executing the interrupt handler.
Setting the interrupt mask bits prevents the interrupts from the same and lower levels to be
passed through the interrupt controller. Setting of the same level mask bit prevents also multiple
requests of the same interrupt to happen.
It is the responsibility of the handler software to clear the interrupt request that caused the interrupt
before returning from the interrupt handler. If the conditions that caused the interrupt are not
cleared, the interrupt request remains active.
12.5.3 Clearing an Interrupt Request
Clearing of the interrupt request is done by writing to registers in the corresponding peripheral
module, which then clears the corresponding NMIREQ/IREQ signal.
The recommended way of clearing an interrupt request is a store operation to the controlling
peripheral register, followed by a dummy load operation from the same register. This causes a
201
32142D–06/2013
ATUC64/128/256L3/4U
pipeline stall, which prevents the interrupt from accidentally re-triggering in case the handler is
exited and the interrupt mask is cleared before the interrupt request is cleared.
202
32142D–06/2013
ATUC64/128/256L3/4U
12.6 User Interface
Table 12-1. INTC Register Memory Map
Offset Register Register Name Access Reset
0x000 Interrupt Priority Register 0 IPR0 Read/Write 0x00000000
0x004 Interrupt Priority Register 1 IPR1 Read/Write 0x00000000
... ... ... ... ...
0x0FC Interrupt Priority Register 63 IPR63 Read/Write 0x00000000
0x100 Interrupt Request Register 0 IRR0 Read-only N/A
0x104 Interrupt Request Register 1 IRR1 Read-only N/A
... ... ... ... ...
0x1FC Interrupt Request Register 63 IRR63 Read-only N/A
0x200 Interrupt Cause Register 3 ICR3 Read-only N/A
0x204 Interrupt Cause Register 2 ICR2 Read-only N/A
0x208 Interrupt Cause Register 1 ICR1 Read-only N/A
0x20C Interrupt Cause Register 0 ICR0 Read-only N/A
203
32142D–06/2013
ATUC64/128/256L3/4U
12.6.1 Interrupt Priority Registers
Name: IPR0...IPR63
Access Type: Read/Write
Offset: 0x000 - 0x0FC
Reset Value: 0x00000000
• INTLEVEL: Interrupt Level
Indicates the EVBA-relative offset of the interrupt handler of the corresponding group:
00: INT0: Lowest priority
01: INT1
10: INT2
11: INT3: Highest priority
• AUTOVECTOR: Autovector Address
Handler offset is used to give the address of the interrupt handler. The least significant bit should be written to zero to give
halfword alignment.
31 30 29 28 27 26 25 24
INTLEVEL - - - - - -
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
- - AUTOVECTOR[13:8]
76543210
AUTOVECTOR[7:0]
204
32142D–06/2013
ATUC64/128/256L3/4U
12.6.2 Interrupt Request Registers
Name: IRR0...IRR63
Access Type: Read-only
Offset: 0x0FF - 0x1FC
Reset Value: N/A
• IRR: Interrupt Request line
This bit is cleared when no interrupt request is pending on this input request line.
This bit is set when an interrupt request is pending on this input request line.
The are 64 IRRs, one for each group. Each IRR has 32 bits, one for each possible interrupt request, for a total of 2048 possible
input lines. The IRRs are read by the software interrupt handler in order to determine which interrupt request is pending. The
IRRs are sampled continuously, and are read-only.
31 30 29 28 27 26 25 24
IRR[32*x+31] IRR[32*x+30] IRR[32*x+29] IRR[32*x+28] IRR[32*x+27] IRR[32*x+26] IRR[32*x+25] IRR[32*x+24]
23 22 21 20 19 18 17 16
IRR[32*x+23] IRR[32*x+22] IRR[32*x+21] IRR[32*x+20] IRR[32*x+19] IRR[32*x+18] IRR[32*x+17] IRR[32*x+16]
15 14 13 12 11 10 9 8
IRR[32*x+15] IRR[32*x+14] IRR[32*x+13] IRR[32*x+12] IRR[32*x+11] IRR[32*x+10] IRR[32*x+9] IRR[32*x+8]
76543210
IRR[32*x+7] IRR[32*x+6] IRR[32*x+5] IRR[32*x+4] IRR[32*x+3] IRR[32*x+2] IRR[32*x+1] IRR[32*x+0]
205
32142D–06/2013
ATUC64/128/256L3/4U
12.6.3 Interrupt Cause Registers
Name: ICR0...ICR3
Access Type: Read-only
Offset: 0x200 - 0x20C
Reset Value: N/A
• CAUSE: Interrupt Group Causing Interrupt of Priority n
ICRn identifies the group with the highest priority that has a pending interrupt of level n. This value is only defined when at least
one interrupt of level n is pending.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
- - CAUSE
206
32142D–06/2013
ATUC64/128/256L3/4U
12.7 Module Configuration
The specific configuration for each INTC instance is listed in the following tables.The module
bus clocks listed here are connected to the system bus clocks. Please refer to the Power Manager
chapter for details.
12.7.1 Interrupt Request Signal Map
12.8 Interrupt Request Signal Map
The various modules may output Interrupt request signals. These signals are routed to the Interrupt
Controller (INTC), described in a later chapter. The Interrupt Controller supports up to 64
groups of interrupt requests. Each group can have up to 32 interrupt request signals. All interrupt
signals in the same group share the same autovector address and priority level. Refer to the
documentation for the individual submodules for a description of the semantics of the different
interrupt requests.
The interrupt request signals are connected to the INTC as follows.
Table 12-2. INTC Clock Name
Module Name Clock Name Description
INTC CLK_INTC Clock for the INTC bus interface
Table 12-3. Interrupt Request Signal Map
Group Line Module Signal
0 0 AVR32UC3 CPU SYSREG COMPARE
1
0 AVR32UC3 CPU OCD DCEMU_DIRTY
1 AVR32UC3 CPU OCD DCCPU_READ
2 0 Flash Controller FLASHCDW
3 0 Secure Access Unit SAU
4
0 Peripheral DMA Controller PDCA 0
1 Peripheral DMA Controller PDCA 1
2 Peripheral DMA Controller PDCA 2
3 Peripheral DMA Controller PDCA 3
5
0 Peripheral DMA Controller PDCA 4
1 Peripheral DMA Controller PDCA 5
2 Peripheral DMA Controller PDCA 6
3 Peripheral DMA Controller PDCA 7
6
0 Peripheral DMA Controller PDCA 8
1 Peripheral DMA Controller PDCA 9
2 Peripheral DMA Controller PDCA 10
3 Peripheral DMA Controller PDCA 11
7 0 Power Manager PM
207
32142D–06/2013
ATUC64/128/256L3/4U
8 0 System Control Interface SCIF
9 0 Asynchronous Timer AST ALARM
10
0 Asynchronous Timer AST PER
1 Asynchronous Timer AST OVF
2 Asynchronous Timer AST READY
3 Asynchronous Timer AST CLKREADY
11
0 External Interrupt Controller EIC 1
1 External Interrupt Controller EIC 2
2 External Interrupt Controller EIC 3
3 External Interrupt Controller EIC 4
12 0 External Interrupt Controller EIC 5
13 0 Frequency Meter FREQM
14
0 General-Purpose Input/Output Controller GPIO 0
1 General-Purpose Input/Output Controller GPIO 1
2 General-Purpose Input/Output Controller GPIO 2
3 General-Purpose Input/Output Controller GPIO 3
4 General-Purpose Input/Output Controller GPIO 4
5 General-Purpose Input/Output Controller GPIO 5
6 General-Purpose Input/Output Controller GPIO 6
7 General-Purpose Input/Output Controller GPIO 7
15 0 Universal Synchronous Asynchronous
Receiver Transmitter USART0
16 0 Universal Synchronous Asynchronous
Receiver Transmitter USART1
17 0 Universal Synchronous Asynchronous
Receiver Transmitter USART2
18 0 Universal Synchronous Asynchronous
Receiver Transmitter USART3
19 0 Serial Peripheral Interface SPI
20 0 Two-wire Master Interface TWIM0
21 0 Two-wire Master Interface TWIM1
22 0 Two-wire Slave Interface TWIS0
23 0 Two-wire Slave Interface TWIS1
24 0 Pulse Width Modulation Controller PWMA
25
0 Timer/Counter TC00
1 Timer/Counter TC01
2 Timer/Counter TC02
Table 12-3. Interrupt Request Signal Map
208
32142D–06/2013
ATUC64/128/256L3/4U
26
0 Timer/Counter TC10
1 Timer/Counter TC11
2 Timer/Counter TC12
27 0 ADC Interface ADCIFB
28 0 Analog Comparator Interface ACIFB
29 0 Capacitive Touch Module CAT
30 0 aWire AW
31 0 Audio Bitstream DAC ABDACB
32 0 USB 2.0 Interface USBC
33 0 Inter-IC Sound (I2S) Controller IISC
Table 12-3. Interrupt Request Signal Map
209
32142D–06/2013
ATUC64/128/256L3/4U
13. Power Manager (PM)
Rev: 4.2.0.4
13.1 Features
• Generates clocks and resets for digital logic
• On-the-fly frequency change of CPU, HSB and PBx clocks
• Sleep modes allow simple disabling of logic clocks and clock sources
• Module-level clock gating through maskable peripheral clocks
• Wake-up from internal or external interrupts
• Automatic identification of reset sources
• Supports advanced Shutdown sleep mode
13.2 Overview
The Power Manager (PM) provides synchronous clocks used to clock the main digital logic in the
device, namely the CPU, and the modules and peripherals connected to the High Speed Bus
(HSB) and the Peripheral Buses (PBx).
The PM contains advanced power-saving features, allowing the user to optimize the power consumption
for an application. The synchronous clocks are divided into a number of clock
domains, one for the CPU and HSB, and one for each PBx. The clocks can run at different
speeds, allowing the user to save power by running peripherals relatively slow, whilst maintaining
high CPU performance. The clocks can be independently changed on-the-fly, without halting
any peripherals. The user may adjust CPU and memory speeds according to the dynamic application
load, without disturbing or re-configuring active peripherals.
Each module has a separate clock, enabling the user to save power by switching off clocks to
inactive modules. Clocks and oscillators can be automatically switched off during idle periods by
the CPU sleep instruction. The system will return to normal operation when interrupts occur.
To achieve minimal power usage, a special sleep mode, called Shutdown is available, where
power on all internal logic (CPU, peripherals) and most of the I/O lines is removed, reducing current
leakage. Only a small amount of logic, including the 32KHz crystal oscillator (OSC32K) and
the AST remain powered.
The Power Manager also contains a Reset Controller, which collects all possible reset sources,
generates hard and soft resets, and allows the reset source to be identified by software.
210
32142D–06/2013
ATUC64/128/256L3/4U
13.3 Block Diagram
Figure 13-1. PM Block Diagram
13.4 I/O Lines Description
13.5 Product Dependencies
13.5.1 Interrupt
The PM interrupt line is connected to one of the interrupt controllers internal sources. Using the
PM interrupt requires the interrupt controller to be configured first.
13.5.2 Clock Implementation
In ATUC64/128/256L3/4U, the HSB shares source clock with the CPU. Write attempts to the
HSB Clock Select register (HSBSEL) will be ignored, and it will always read the same as the
CPU Clock Select register (CPUSEL).
The PM bus interface clock (CLK_PM) is generated by the Power Manager. This clock is
enabled at reset, and can be disabled in the Power Manager. If disabled it can only be reenabled
by a reset.
13.5.3 Power Considerations
The Shutdown mode is only available for the “3.3V supply mode, with 1.8V regulated I/O lines“
power configuration.
Table 13-1. I/O Lines Description
Name Description Type Active Level
RESET_N Reset Input Low
Sleep Controller
Synchronous
Clock Generator
Reset Controller
Main Clock Sources
Sleep
Instruction
Power-on Reset
Detector(s)
Resets
Synchronous
clocks
CPU, HSB,
PBx
Interrupts
External Reset Pin
Reset Sources
211
32142D–06/2013
ATUC64/128/256L3/4U
13.6 Functional Description
13.6.1 Synchronous Clocks
The System RC Oscillator (RCSYS) and a selection of other clock sources can provide the
source for the main clock, which is the origin for the synchronous CPU/HSB and PBx module
clocks. For details about the other main clock sources, please refer to the Main Clock Control
(MCCTRL) register description. The synchronous clocks can run of the main clock and all the 8-
bit prescaler settings as long as fCPU fPBx,. The synchronous clock source can be changed onthe
fly, according to variations in application load. The clock domains can be shut down in sleep
mode, as described in Section 13.6.3. The module clocks in every synchronous clock domain
can be individually masked to minimize power consumption in inactive modules.
Figure 13-2. Synchronous Clock Generation
13.6.1.1 Selecting the main clock source
The common main clock can be connected to RCSYS or a selection of other clock sources. For
details about the other main clock sources, please refer to the MCCTRL register description. By
default, the main clock will be connected to RCSYS. The user can connect the main clock to
another source by writing to the Main Clock Select (MCCTRL.MCSEL) field. The user must first
assure that the source is enabled and ready in order to avoid a deadlock. Care should also be
taken so that the new synchronous clock frequencies do not exceed the maximum frequency for
each clock domain.
13.6.1.2 Selecting synchronous clock division ratio
The main clock feeds an 8-bit prescaler, which can be used to generate the synchronous clocks.
By default, the synchronous clocks run on the undivided main clock. The user can select a prescaler
division for the CPU clock by writing a one to the CPU Division bit in the CPU Clock Select
register (CPUSEL.CPUDIV), and a value to the CPU Clock Select field (CPUSEL.CPUSEL),
resulting in a CPU clock frequency:
fCPU = fmain / 2(CPUSEL+1)
Mask
Prescaler Main Clock
Sources
MCSEL
0
1
CPUSEL
CPUDIV
Main Clock
Sleep
Controller
CPUMASK
CPU Clocks
HSB Clocks
PBx Clocks
Sleep
Instruction
212
32142D–06/2013
ATUC64/128/256L3/4U
Similarly, the PBx clocks can be divided by writing their respective Clock Select (PBxSEL) registers
to get the divided PBx frequency:
fPBx = fmain / 2(PBSEL+1)
The PBx clock frequency can not exceed the CPU clock frequency. The user must select a PBxSEL.PBSEL
value greater than or equal to the CPUSEL.CPUSEL value, so that fCPU fPBx. If the
user selects division factors that will result in fCPU< fPBx, the Power Manager will automatically
change the PBxSEL.PBSEL/PBDIV values to ensure correct operation (fCPU fPBx).
The HSB clock will always be forced to the same division as the CPU clock.
To ensure correct operation, the frequencies must never exceed the specified maximum frequency
for each clock domain.
For modules connected to the HSB bus, the PB clock frequency must be the same as the CPU
clock frequency.
13.6.1.3 Clock Ready flag
There is a slight delay from CPUSEL and PBxSEL being written to the new clock setting taking
effect. During this interval, the Clock Ready bit in the Status Register (SR.CKRDY) will read as
zero. When the clock settings change is completed, the bit will read as one. The Clock Select
registers (CPUSEL, PBxSEL) must not be written to while SR.CKRDY is zero, or the system
may become unstable or hang.
The Clock Ready bit in the Interrupt Status Register (ISR.CKRDY) is set on a SR.CKRDY zeroto-one
transition. If the Clock Ready bit in the Interrupt Mask Register (IMR.CKRDY) is set, an
interrupt request is generated. IMR.CKRDY is set by writing a one to the corresponding bit in the
Interrupt Enable Register (IER.CKRDY).
13.6.2 Peripheral Clock Masking
By default, the clocks for all modules are enabled, regardless of which modules are actually
being used. It is possible to disable the clock for a module in the CPU, HSB, or PBx clock
domain by writing a zero to the corresponding bit in the corresponding Clock Mask (CPUMASK/HSBMASK/PBxMASK)
register. When a module is not clocked, it will cease operation,
and its registers cannot be read nor written. The module can be re-enabled later by writing a one
to the corresponding mask bit. A module may be connected to several clock domains, in which
case it will have several mask bits. The Maskable Module Clocks table in the Clock Mask register
description contains a list of implemented maskable clocks.
13.6.2.1 Cautionary note
Note that clocks should only be switched off if it is certain that the module will not be used.
Switching off the clock for the Flash Controller will cause a problem if the CPU needs to read
from the flash. Switching off the clock to the Power Manager, which contains the mask registers,
or the corresponding PBx bridge, will make it impossible to write to the mask registers again. In
this case, they can only be re-enabled by a system reset.
13.6.3 Sleep Modes
In normal operation, all clock domains are active, allowing software execution and peripheral
operation. When the CPU is idle, it is possible to switch it and other (optional) clock domains off
to save power. This is done by the sleep instruction, which takes the sleep mode index number
from Table 13-2 on page 213 as argument.
213
32142D–06/2013
ATUC64/128/256L3/4U
13.6.3.1 Entering and exiting sleep modes
The sleep instruction will halt the CPU and all modules belonging to the stopped clock domains.
The modules will be halted regardless of the bit settings in the mask registers.
Clock sources can also be switched off to save power. Some of these have a relatively long
start-up time, and are only switched off when very low power consumption is required.
The CPU and affected modules are restarted when the sleep mode is exited. This occurs when
an interrupt triggers. Note that even if an interrupt is enabled in sleep mode, it may not trigger if
the source module is not clocked.
13.6.3.2 Supported sleep modes
The following sleep modes are supported. These are detailed in Table 13-2 on page 213.
• Idle: The CPU is stopped, the rest of the device is operational.
• Frozen: The CPU and HSB modules are stopped, peripherals are operational.
• Standby: All synchronous clocks are stopped, and the clock sources are running, allowing for
a quick wake-up to normal mode.
• Stop: As Standby, but oscillators, and other clock sources are also stopped. 32KHz Oscillator
OSC32K(2), RCSYS, AST, and WDT will remain operational.
• DeepStop: All synchronous clocks and clock sources are stopped. Bandgap voltage
reference and BOD are turned off. OSC32K(2) and RCSYS remain operational.
• Static: All clock sources, including RCSYS are stopped. Bandgap voltage reference and BOD
are turned off. OSC32K(2) remains operational.
• Shutdown: All clock sources, including RCSYS are stopped. Bandgap voltage reference,
BOD detector, and Voltage regulator are turned off. OSC32K(2) remains operational. This
mode can only be used in the “3.3V supply mode, with 1.8V regulated I/O lines“
configuration (described in Power Considerations chapter). Refer to Section 13.6.4 for more
details.
Notes: 1. The sleep mode index is used as argument for the sleep instruction.
2. OSC32K will only remain operational if pre-enabled.
3. Clock sources other than those specifically listed in the table.
4. SYSTIMER is the clock for the CPU COUNT and COMPARE registers.
The internal voltage regulator is also adjusted according to the sleep mode in order to reduce its
power consumption.
Table 13-2. Sleep Modes
Index(1) Sleep Mode CPU HSB
PBx,
GCLK
Clock Sources(3),
SYSTIMER(4) OSC32K(2) RCSYS
BOD &
Bandgap
Voltage
Regulator
0 Idle Stop Run Run Run Run Run On Normal mode
1 Frozen Stop Stop Run Run Run Run On Normal mode
2 Standby Stop Stop Stop Run Run Run On Normal mode
3 Stop Stop Stop Stop Stop Run Run On Low power mode
4 DeepStop Stop Stop Stop Stop Run Run Off Low power mode
5 Static Stop Stop Stop Stop Run Stop Off Low power mode
6 Shutdown Stop Stop Stop Stop Run Stop Off Off
214
32142D–06/2013
ATUC64/128/256L3/4U
13.6.3.3 Waking from sleep modes
There are two types of wake-up sources from sleep mode, synchronous and asynchronous.
Synchronous wake-up sources are all non-masked interrupts. Asynchronous wake-up sources
are AST, WDT, external interrupts from EIC, external reset, external wake pin (WAKE_N), and
all asynchronous wake-ups enabled in the Asynchronous Wake Up Enable (AWEN) register. The
valid wake-up sources for each sleep mode are detailed in Table 13-3 on page 214.
In Shutdown the only wake-up sources are external reset, external wake-up pin or AST. See
Section 13.6.4.3 on page 216.
Notes: 1. The sleep mode index is used as argument for the sleep instruction.
2. Only PB modules operational, as HSB module clocks are stopped.
3. WDT only available if clocked from pre-enabled OSC32K.
13.6.3.4 SleepWalking
In all sleep modes where the PBx clocks are stopped, except for Shutdown mode, the device
can partially wake up if a PBx module asynchronously discovers that it needs its clock. Only the
requested clocks and clock sources needed will be started, all other clocks will remain masked
to zero. E.g. if the main clock source is OSC0, only OSC0 will be started even if other clock
sources were enabled in normal mode. Generic clocks can also be started in a similar way. The
state where only requested clocks are running is referred to as SleepWalking.
The time spent to start the requested clock is mostly limited by the startup time of the given clock
source. This allows PBx modules to handle incoming requests, while still keeping the power consumption
at a minimum.
When the device is SleepWalking any asynchronous wake-up can wake the device up at any
time without stopping the requested PBx clock.
All requests to start clocks can be masked by writing to the Peripheral Power Control Register
(PPCR), all requests are enabled at reset.
During SleepWalking the interrupt controller clock will be running. If an interrupt is pending when
entering SleepWalking, it will wake the whole device up.
13.6.3.5 Precautions when entering sleep mode
Modules communicating with external circuits should normally be disabled before entering a
sleep mode that will stop the module operation. This will prevent erratic behavior caused by
entering or exiting sleep modes. Please refer to the relevant module documentation for recommended
actions.
Table 13-3. Wake-up Sources
Index(1) Sleep Mode Wake-up Sources
0 Idle Synchronous, Asynchronous
1 Frozen Synchronous(2), Asynchronous
2 Standby Asynchronous
3 Stop Asynchronous
4 DeepStop Asynchronous
5 Static Asynchronous(3)
6 Shutdown External reset, External wake-up pin
215
32142D–06/2013
ATUC64/128/256L3/4U
Communication between the synchronous clock domains is disturbed when entering and exiting
sleep modes. Bus transactions over clock domains affected by the sleep mode are therefore not
recommended. The system may hang if the bus clocks are stopped during a bus transaction.
The CPU is automatically stopped in a safe state to ensure that all CPU bus operations are complete
when the sleep mode goes into effect. Thus, when entering Idle mode, no further action is
necessary.
When entering a sleep mode (except Idle mode), all HSB masters must be stopped before
entering the sleep mode. In order to let potential PBx write operations complete, the user should
let the CPU perform a PBx register read operation before issuing the sleep instruction. This will
stall the CPU until pending PBx operations have completed.
The Shutdown sleep mode requires extra care. Please refer to Section 13.6.4.
13.6.4 Shutdown Sleep Mode
13.6.4.1 Description
The Shutdown sleep mode is available only when the device is used in the “3.3V supply mode,
with 1.8V regulated I/O lines“ configuration (refer to the Power Considerations chapter). In this
configuration, the voltage regulator supplies both VDDCORE and VDDIO power supplies.
When the device enters Shutdown mode, the regulator is turned off and only the following logic
is kept powered by VDDIN:
– OSC32K using alternate pinout PA13/PA20
– AST core logic (internal counter and alarm detection logic)
– Backup Registers
– I/O lines PA11, PA13, PA20, PA21, PB04, PB05, and PB10
– RESET_N line
The table below lists I/O line functionality that remains operational during Shutdown sleep mode.
If no special function is used the I/O line will keep its setting when entering the sleep mode
13.6.4.2 Entering Shutdown sleep mode
Before entering the Shutdown sleep mode, a few actions are required:
– All modules should normally be disabled before entering Shutdown sleep mode (see
Section 13.6.3.5)
Table 13-4. I/O Lines Usage During Shutdown Mode
Pin Possible Usage During Shutdown Sleep Mode
PA11 WAKE_N signal (active low wake-up)
PA13 XIN32_2 (OSC32K using alternate pinout)
PA20 XOUT32_2 (OSC32K using alternate pinout)
PA21
PB04
PB05
PB10
RESET_N Reset pin
216
32142D–06/2013
ATUC64/128/256L3/4U
– The POR33 must be masked to avoid spurious resets when the power is back. This
must also be done when POR33 is disabled, as POR33 will be enabled
automatically when the device wakes up from Shutdown mode. Disable the POR33
by writing a one to the POR33MASK bit in the SCIF.VREGCR register. Due to
internal synchronisation, this bit must be read as a one before the sleep instruction is
executed by the CPU. Refer to the System Control Interface (SCIF) chapter for more
details.
– The 32KHz RC oscillator (RC32K) must be running and stable. This is done by
writing a one to the EN bit in the SCIF.RC32KCR register. Due to internal
synchronisation, this bit must be read as a one to ensure that the oscillator is stable
before the sleep instruction is executed by the CPU.
As soon as the Shutdown sleep mode is entered, all CPU and peripherals are reset to ensure a
consistent state. POR33 and RC32K are automatically disabled to save extra power.
13.6.4.3 Leaving Shutdown sleep mode
Exiting Shutdown sleep mode can be done by the events described in Table 13-5.
When a wake-up event occurs, the regulator is turned on and the device will wait for VDDCORE
to be valid before starting. The Sleep Reset bit in the Reset Cause register (RCAUSE.SLEEP) is
then set, allowing software running on the device to distinguish between the first power-up and a
wake-up from Shutdown mode.
13.6.4.4 Special consideration regarding waking up from Shutdown sleep mode using the WAKE_N pin
By default, the WAKE_N pin will only wake the device up if it is pulled low after entering Shutdown
mode. If the WAKE_N is pulled low before the Shutdown mode is entered, it will not wake
the device from the Shutdown sleep mode. In order to wake the device by pulling WAKE_N low
before entering Shutdown mode, the user has to write a one to the bit corresponding to the
WAKEN wake-up source in the AWEN register. In this scenario, the CPU execution will proceed
with the next instruction, and the RCAUSE register content will not be altered.
13.6.5 Divided PB Clocks
The clock generator in the Power Manager provides divided PBx clocks for use by peripherals
that require a prescaled PBx clock. This is described in the documentation for the relevant modules.
The divided clocks are directly maskable, and are stopped in sleep modes where the PBx
clocks are stopped.
Table 13-5. Events That Can Wake up the Device from Shutdown Mode
Source How
PA11 (WAKE_N) Pulling-down PA11 will wake up the device
RESET_N
Pulling-down RESET_N pin will wake up the device
The device is kept under reset until RESET_N is tied high
again
AST
OSC32K must be set-up to use alternate pinout (XIN32_2
and XOUT32_2) Refer to the SCIF Chapter
AST must be configured to use the clock from OSC32K
AST must be configured to allow alarm, periodic, or
overflow wake-up
217
32142D–06/2013
ATUC64/128/256L3/4U
13.6.6 Reset Controller
The Reset Controller collects the various reset sources in the system and generates hard and
soft resets for the digital logic.
The device contains a Power-on Reset (POR) detector, which keeps the system reset until
power is stable. This eliminates the need for external reset circuitry to guarantee stable operation
when powering up the device.
It is also possible to reset the device by pulling the RESET_N pin low. This pin has an internal
pull-up, and does not need to be driven externally during normal operation. Table 13-6 on page
217 lists these and other reset sources supported by the Reset Controller.
Figure 13-3. Reset Controller Block Diagram
In addition to the listed reset types, the JTAG & aWire can keep parts of the device statically
reset. See JTAG and aWire documentation for details.
Table 13-6. Reset Description
Reset Source Description
Power-on Reset Supply voltage below the Power-on Reset detector threshold
voltage VPOT
External Reset RESET_N pin asserted
Brown-out Reset VDDCORE supply voltage below the Brown-out detector
threshold voltage
JTAG
Reset
Controller
RESET_N
Power-on Reset
Detector(s)
OCD
Watchdog Reset
RCAUSE
CPU, HSB, PBx
OCD, AST, WDT,
Clock Generator
Brown-out
Detector
AWIRE
SM33 Detector
218
32142D–06/2013
ATUC64/128/256L3/4U
Depending on the reset source, when a reset occurs, some parts of the device are not always
reset. Only the Power-on Reset (POR) will force a whole device reset. Refer to the table in the
Module Configuration section at the end of this chapter for further details. The latest reset cause
can be read in the RCAUSE register, and can be read during the applications boot sequence in
order to determine proper action.
13.6.6.1 Power-on Reset Detector
The Power-on Reset 1.8V (POR18) detector monitors the VDDCORE supply pin and generates
a Power-on Reset (POR) when the device is powered on. The POR is active until the
VDDCORE voltage is above the power-on threshold level (VPOT). The POR will be re-generated
if the voltage drops below the power-on threshold level. See Electrical Characteristics for parametric
details.
The Power-on Reset 3.3V (POR33) detector monitors the internal regulator supply pin and generates
a Power-on Reset (POR) when the device is powered on. The POR is active until the
internal regulator supply voltage is above the regulator power-on threshold level (VPOT). The
POR will be re-generated if the voltage drops below the regulator power-on threshold level. See
Electrical Characteristics for parametric details.
13.6.6.2 External Reset
The external reset detector monitors the RESET_N pin state. By default, a low level on this pin
will generate a reset.
13.6.7 Clock Failure Detector
This mechanism automatically switches the main clock source to the safe RCSYS clock when
the main clock source fails. This may happen when an external crystal is selected as a source
for the main clock and the crystal is not mounted on the board. The main clock is compared with
RCSYS, and if no rising edge of the main clock is detected during one RCSYS period, the clock
is considered to have failed.
The detector is enabled by writing a one to the Clock Failure Detection Enable bit in the Clock
Failure Detector Control Register (CFDCTRL.CFDEN). As soon as the detector is enabled, the
clock failure detector will monitor the divided main clock. Note that the detector does not monitor
the main clock if RCSYS is the source of the main clock, or if the main clock is temporarily not
available (startup-time after a wake-up, switching timing etc.), or in sleep mode where the main
clock is driven by the RCSYS (Stop and DeepStop mode). When a clock failure is detected, the
main clock automatically switches to the RCSYS clock and the Clock Failure Detected (CFD)
interrupt is generated if enabled. The MCCTRL register is also changed by hardware to indicate
that the main clock comes from RCSYS.
13.6.8 Interrupts
The PM has a number of interrupt sources:
• AE - Access Error,
SM33 Reset Internal regulator supply voltage below the SM33 threshold
voltage. This generates a Power-on Reset.
Watchdog Timer See Watchdog Timer documentation
OCD See On-Chip Debug documentation
Reset Source Description
219
32142D–06/2013
ATUC64/128/256L3/4U
– A lock protected register is written to without first being unlocked.
• CKRDY - Clock Ready:
– New Clock Select settings in the CPUSEL/PBxSEL registers have taken effect. (A
zero-to-one transition on SR.CKRDY is detected).
• CFD - Clock Failure Detected:
– The system detects that the main clock is not running.
The Interrupt Status Register contains one bit for each interrupt source. A bit in this register is
set on a zero-to-one transition of the corresponding bit in the Status Register (SR), and cleared
by writing a one to the corresponding bit in the Interrupt Clear Register (ICR). The interrupt
sources will generate an interrupt request if the corresponding bit in the Interrupt Mask Register
is set. The interrupt sources are ORed together to form one interrupt request. The Power Manager
will generate an interrupt request if at least one of the bits in the Interrupt Mask Register
(IMR) is set. Bits in IMR are set by writing a one to the corresponding bit in the Interrupt Enable
Register (IER), and cleared by writing a one to the corresponding bit in the Interrupt Disable
Register (IDR). The interrupt request remains active until the corresponding bit in the Interrupt
Status Register (ISR) is cleared by writing a one to the corresponding bit in the Interrupt Clear
Register (ICR). Because all the interrupt sources are ORed together, the interrupt request from
the Power Manager will remain active until all the bits in ISR are cleared.
220
32142D–06/2013
ATUC64/128/256L3/4U
13.7 User Interface
Note: 1. The reset value is device specific. Please refer to the Module Configuration section at the end of this chapter.
2. Latest Reset Source.
3. Latest Wake Source.
Table 13-7. PM Register Memory Map
Offset Register Register Name Access Reset
0x000 Main Clock Control MCCTRL Read/Write 0x00000000
0x004 CPU Clock Select CPUSEL Read/Write 0x00000000
0x008 HSB Clock Select HSBSEL Read-only 0x00000000
0x00C PBA Clock Select PBASEL Read/Write 0x00000000
0x010 PBB Clock Select PBBSEL Read/Write 0x00000000
0x014 - 0x01C Reserved
0x020 CPU Mask CPUMASK Read/Write 0x00010001
0x024 HSB Mask HSBMASK Read/Write 0x0000007F
0x028 PBA Mask PBAMASK Read/Write 0x0FFFFFFF
0x02C PBB Mask PBBMASK Read/Write 0x0000000F
0x030- 0x03C Reserved
0x040 PBA Divided Mask PBADIVMASK Read/Write 0x0000007F
0x044 - 0x050 Reserved
0x054 Clock Failure Detector Control CFDCTRL Read/Write 0x00000000
0x058 Unlock Register UNLOCK Write-only 0x00000000
0x05C - 0x0BC Reserved
0x0C0 Interrupt Enable Register IER Write-only 0x00000000
0x0C4 Interrupt Disable Register IDR Write-only 0x00000000
0x0C8 Interrupt Mask Register IMR Read-only 0x00000000
0x0CC Interrupt Status Register ISR Read-only 0x00000000
0x0D0 Interrupt Clear Register ICR Write-only 0x00000000
0x0D4 Status Register SR Read-only 0x00000020
0x0D8 - 0x15C Reserved
0x160 Peripheral Power Control Register PPCR Read/Write 0x000001FA
0x164 - 0x17C Reserved
0x180 Reset Cause Register RCAUSE Read-only -(2)
0x184 Wake Cause Register WCAUSE Read-only -(3)
0x188 Asynchronous Wake Up Enable Register AWEN Read/Write 0x00000000
0x18C - 0x3F4 Reserved
0x3F8 Configuration Register CONFIG Read-only 0x00000043
0x3FC Version Register VERSION Read-only -(1)
221
32142D–06/2013
ATUC64/128/256L3/4U
13.7.1 Main Clock Control
Name: MCCTRL
Access Type: Read/Write
Offset: 0x000
Reset Value: 0x00000000
• MCSEL: Main Clock Select
Note: 1. If the 120MHz RC oscillator is selected as main clock source, it must be divided by at least 4 before being used as clock
source for the CPU. This division is selected by writing to the CPUSEL and CPUDIV bits in the CPUSEL register, before
switching to RC120M as main clock source.
Note that this register is protected by a lock. To write to this register the UNLOCK register has to be written first. Please
refer to the UNLOCK register description for details.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
- - - - - MCSEL
Table 13-8. Main clocks in ATUC64/128/256L3/4U.
MCSEL[2:0] Main clock source
0 System RC oscillator (RCSYS)
1 Oscillator0 (OSC0)
2 DFLL
3 120MHz RC oscillator
(RC120M)(1)
222
32142D–06/2013
ATUC64/128/256L3/4U
13.7.2 CPU Clock Select
Name: CPUSEL
Access Type: Read/Write
Offset: 0x004
Reset Value: 0x00000000
• CPUDIV, CPUSEL: CPU Division and Clock Select
CPUDIV = 0: CPU clock equals main clock.
CPUDIV = 1: CPU clock equals main clock divided by 2(CPUSEL+1).
Note that if CPUDIV is written to 0, CPUSEL should also be written to 0 to ensure correct operation.
Also note that writing this register clears POSCSR.CKRDY. The register must not be re-written until CKRDY goes high.
Note that this register is protected by a lock. To write to this register the UNLOCK register has to be written first. Please
refer to the UNLOCK register description for details.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
CPUDIV - - - - CPUSEL
223
32142D–06/2013
ATUC64/128/256L3/4U
13.7.3 HSB Clock Select
Name: HSBSEL
Access Type: Read
Offset: 0x008
Reset Value: 0x00000000
This register is read-only and its content is always equal to CPUSEL.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
HSBDIV - - - - HSBSEL
224
32142D–06/2013
ATUC64/128/256L3/4U
13.7.4 PBx Clock Select
Name: PBxSEL
Access Type: Read/Write
Offset: 0x00C-0x010
Reset Value: 0x00000000
• PBDIV, PBSEL: PBx Division and Clock Select
PBDIV = 0: PBx clock equals main clock.
PBDIV = 1: PBx clock equals main clock divided by 2(PBSEL+1).
Note that if PBDIV is written to 0, PBSEL should also be written to 0 to ensure correct operation.
Also note that writing this register clears SR.CKRDY. The register must not be re-written until SR.CKRDY is set.
Note that this register is protected by a lock. To write to this register the UNLOCK register has to be written first. Please
refer to the UNLOCK register description for details.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
PBDIV - - - - PBSEL
225
32142D–06/2013
ATUC64/128/256L3/4U
13.7.5 Clock Mask
Name: CPUMASK/HSBMASK/PBAMASK/PBBMASK
Access Type: Read/Write
Offset: 0x020-0x02C
Reset Value: -
• MASK: Clock Mask
If bit n is cleared, the clock for module n is stopped. If bit n is set, the clock for module n is enabled according to the current
power mode. The number of implemented bits in each mask register, as well as which module clock is controlled by each bit, is
shown in Table 13-9.
31 30 29 28 27 26 25 24
MASK[31:24]
23 22 21 20 19 18 17 16
MASK[23:16]
15 14 13 12 11 10 9 8
MASK[15:8]
76543210
MASK[7:0]
Table 13-9. Maskable Module Clocks in ATUC64/128/256L3/4U.
Bit CPUMASK HSBMASK PBAMASK PBBMASK
0 OCD PDCA PDCA FLASHCDW
1 - FLASHCDW INTC HMATRIX
2 - SAU PM SAU
3 - PBB bridge SCIF USBC
4 - PBA bridge AST -
5 - Peripheral Event System WDT -
6 - USBC EIC -
7 - - FREQM -
8 - - GPIO -
9 - - USART0 -
10 - - USART1 -
11 - - USART2 -
226
32142D–06/2013
ATUC64/128/256L3/4U
Note that this register is protected by a lock. To write to this register the UNLOCK register has to be written first. Please
refer to the UNLOCK register description for details.
12 - - USART3 -
13 - - SPI -
14 - - TWIM0 -
15 - - TWIM1 -
16 SYSTIMER - TWIS0 -
17 - - TWIS1 -
18 - - PWMA -
19 - - TC0 -
20 - - TC1 -
21 - - ADCIFB -
22 - - ACIFB -
23 - - CAT -
24 - - GLOC -
25 - - AW -
26 - - ABDACB -
27 - - IISC -
31:28 - - - -
Table 13-9. Maskable Module Clocks in ATUC64/128/256L3/4U.
Bit CPUMASK HSBMASK PBAMASK PBBMASK
227
32142D–06/2013
ATUC64/128/256L3/4U
13.7.6 PBA Divided Mask
Name: PBADIVMASK
Access Type: Read/Write
Offset: 0x040
Reset Value: 0x0000007F
• MASK: Clock Mask
If bit n is written to zero, the clock divided by 2(n+1) is stopped. If bit n is written to one, the clock divided by 2(n+1) is enabled
according to the current power mode. Table 13-10 shows what clocks are affected by the different MASK bits.
Note that this register is protected by a lock. To write to this register the UNLOCK register has to be written first. Please
refer to the UNLOCK register description for details.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
- ------
15 14 13 12 11 10 9 8
--------
76543210
- MASK[6:0]
Table 13-10. Divided Clock Mask
Bit USART0 USART1 USART2 USART3 TC0 TC1
0 - - - - TIMER_CLOCK2 TIMER_CLOCK2
1- - - - - -
2 CLK_USART/
DIV
CLK_USART/
DIV
CLK_USART/
DIV
CLK_USART/
DIV TIMER_CLOCK3 TIMER_CLOCK3
3- - - - - -
4 - - - - TIMER_CLOCK4 TIMER_CLOCK4
5- - - - - -
6 - - - - TIMER_CLOCK5 TIMER_CLOCK5
228
32142D–06/2013
ATUC64/128/256L3/4U
13.7.7 Clock Failure Detector Control Register
Name: CFDCTRL
Access Type: Read/Write
Offset: 0x054
Reset Value: 0x00000000
• SFV: Store Final Value
0: The register is read/write
1: The register is read-only, to protect against further accidental writes.
• CFDEN: Clock Failure Detection Enable
0: Clock Failure Detector is disabled
1: Clock Failure Detector is enabled
Note that this register is protected by a lock. To write to this register the UNLOCK register has to be written first. Please
refer to the UNLOCK register description for details.
31 30 29 28 27 26 25 24
SFV - - - - - - -
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
- - - - - - - CFDEN
229
32142D–06/2013
ATUC64/128/256L3/4U
13.7.8 Unlock Register
Name: UNLOCK
Access Type: Write-only
Offset: 0x058
Reset Value: 0x00000000
To unlock a write protected register, first write to the UNLOCK register with the address of the register to unlock in the
ADDR field and 0xAA in the KEY field. Then, in the next PB access write to the register specified in the ADDR field.
• KEY: Unlock Key
Write this bit field to 0xAA to enable unlock.
• ADDR: Unlock Address
Write the address of the register to unlock to this field.
31 30 29 28 27 26 25 24
KEY
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
- - - - - - ADDR[9:8]
76543210
ADDR[7:0]
230
32142D–06/2013
ATUC64/128/256L3/4U
13.7.9 Interrupt Enable Register
Name: IER
Access Type: Write-only
Offset: 0x0C0
Reset Value: 0x00000000
Writing a zero to a bit in this register has no effect.
Writing a one to a bit in this register will set the corresponding bit in IMR.
31 30 29 28 27 26 25 24
AE - - - - - - -
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
- - CKRDY - - - - CFD
231
32142D–06/2013
ATUC64/128/256L3/4U
13.7.10 Interrupt Disable Register
Name: IDR
Access Type: Write-only
Offset: 0x0C4
Reset Value: 0x00000000
Writing a zero to a bit in this register has no effect.
Writing a one to a bit in this register will clear the corresponding bit in IMR.
31 30 29 28 27 26 25 24
AE - - - - - - -
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
- - CKRDY - - - - CFD
232
32142D–06/2013
ATUC64/128/256L3/4U
13.7.11 Interrupt Mask Register
Name: IMR
Access Type: Read-only
Offset: 0x0C8
Reset Value: 0x00000000
0: The corresponding interrupt is disabled.
1: The corresponding interrupt is enabled.
This bit is cleared when the corresponding bit in IDR is written to one.
This bit is set when the corresponding bit in IER is written to one.
31 30 29 28 27 26 25 24
AE - - - - - - -
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
- - CKRDY - - - - CFD
233
32142D–06/2013
ATUC64/128/256L3/4U
13.7.12 Interrupt Status Register
Name: ISR
Access Type: Read-only
Offset: 0x0CC
Reset Value: 0x00000000
0: The corresponding interrupt is cleared.
1: The corresponding interrupt is pending.
This bit is cleared when the corresponding bit in ICR is written to one.
This bit is set on a zero-to-one transition of the corresponding bit in the Status Register (SR).
31 30 29 28 27 26 25 24
AE - - - - - - -
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
- - CKRDY - - - - CFD
234
32142D–06/2013
ATUC64/128/256L3/4U
13.7.13 Interrupt Clear Register
Name: ICR
Access Type: Write-only
Offset: 0x0D0
Reset Value: 0x00000000
Writing a zero to a bit in this register has no effect.
Writing a one to a bit in this register will clear the corresponding bit in ISR.
31 30 29 28 27 26 25 24
AE - - - - - - -
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
- - CKRDY - - - - CFD
235
32142D–06/2013
ATUC64/128/256L3/4U
13.7.14 Status Register
Name: SR
Access Type: Read-only
Offset: 0x0D4
Reset Value: 0x00000020
• AE: Access Error
0: No access error has occurred.
1: A write to lock protected register without unlocking it has occurred.
• CKRDY: Clock Ready
0: One of the CPUSEL/PBxSEL registers has been written, and the new clock setting is not yet effective.
1: The synchronous clocks have frequencies as indicated in the CPUSEL/PBxSEL registers.
• CFD: Clock Failure Detected
0: Main clock is running correctly.
1: Failure on main clock detected. Main clock is now running on RCSYS.
31 30 29 28 27 26 25 24
AE - - - - - - -
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
- - CKRDY - - - - CFD
236
32142D–06/2013
ATUC64/128/256L3/4U
13.7.15 Peripheral Power Control Register
Name: PPCR
Access Type: Read/Write
Offset: 0x004
Reset Value: 0x000001FA
• RSTTM: Reset test mode
0: External reset not in test mode
1: External reset in test mode
• FRC32: Force RC32 out
0: RC32 signal is not forced as output
1: RC32 signal is forced as output
• RSTPUN: Reset Pull-up, active low
0: Pull-up for external reset on
1: Pull-up for external reset off
31 30 29 28 27 26 25 24
PPC[31:24]
23 22 21 20 19 18 17 16
PPC[23:16]
15 14 13 12 11 10 9 8
PPC[15:8]
76543210
PPC[7:0]
Table 13-11. Peripheral Power Control
Bit Name
0 RSTPUN
1 FRC32
2 RSTTM
3 CATRCMASK
4 ACIFBCRCMASK
5 ADCIFBRCMASK
6 ASTRCMASK
7 TWIS0RCMASK
8 TWIS1RCMASK
31:9 -
237
32142D–06/2013
ATUC64/128/256L3/4U
• CATRCMASK: CAT Request Clock Mask
0: CAT Request Clock is disabled
1: CAT Request Clock is enabled
• ACIFBRCMASK: ACIFB Request Clock Mask
0: ACIFB Request Clock is disabled
1: ACIFB Request Clock is enabled
• ADCIFBRCMASK: ADCIFB Request Clock Mask
0: ADCIFB Request Clock is disabled
1: ADCIFB Request Clock is enabled
• ASTRCMASK: AST Request Clock Mask
0: AST Request Clock is disabled
1: AST Request Clock is enabled
• TWIS0RCMASK: TWIS0 Request Clock Mask
0: TWIS0 Request Clock is disabled
1: TWIS0 Request Clock is enabled
• TWIS1RCMASK: TWIS1 Request Clock Mask
0: TWIS1 Request Clock is disabled
1: TWIS1 Request Clock is enabled
Note that this register is protected by a lock. To write to this register the UNLOCK register has to be written first. Please
refer to the UNLOCK register description for details.
238
32142D–06/2013
ATUC64/128/256L3/4U
13.7.16 Reset Cause Register
Name: RCAUSE
Access Type: Read-only
Offset: 0x180
Reset Value: Latest Reset Source
• AWIRE: aWire Reset
This bit is set when the last reset was caused by the aWire.
• JTAG: JTAG Reset
This bit is set when the last reset was caused by the JTAG.
• OCDRST: OCD Reset
This bit is set when the last reset was due to the RES bit in the OCD Development Control register having been written to one.
• SLEEP: Sleep Reset
This bit is set when the last reset was due to the device waking up from the Shutdown sleep mode.
• WDT: Watchdog Reset
This bit is set when the last reset was due to a watchdog time-out.
• EXT: External Reset Pin
This bit is set when the last reset was due to the RESET_N pin being pulled low.
• BOD: Brown-out Reset
This bit is set when the last reset was due to the core supply voltage being lower than the brown-out threshold level.
• POR: Power-on Reset
This bit is set when the last reset was due to the core supply voltage VDDCORE being lower than the power-on threshold level
(the reset is generated by the POR18 detector), or the internal regulator supply voltage being lower than the regulator power-on
threshold level (generated by the POR33 detector), or the internal regulator supply voltage being lower than the minimum
required input voltage (generated by the 3.3V supply monitor SM33).
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
- - - AWIRE - JTAG OCDRST
76543210
- SLEEP - - WDT EXT BOD POR
239
32142D–06/2013
ATUC64/128/256L3/4U
13.7.17 Wake Cause Register
Name: WCAUSE
Access Type: Read-only
Offset: 0x184
Reset Value: Latest Wake Source
A bit in this register is set on wake up caused by the peripheral referred to in Table 13-12 on page 239.
31 30 29 28 27 26 25 24
WCAUSE[31:24]
23 22 21 20 19 18 17 16
WCAUSE[23:16]
15 14 13 12 11 10 9 8
WCAUSE[15:8]
76543210
WCAUSE[7:0]
Table 13-12. Wake Cause
Bit Wake Cause
0 CAT
1 ACIFB
2 ADCIFB
3 TWI Slave 0
4 TWI Slave 1
5 WAKE_N
6 ADCIFB Pen Detect
7 USBC
15:8 -
16 EIC
17 AST
31:18 -
240
32142D–06/2013
ATUC64/128/256L3/4U
13.7.18 Asynchronous Wake Up Enable Register
Name: AWEN
Access Type: Read/Write
Offset: 0x188
Reset Value: 0x00000000
Each bit in this register corresponds to an asynchronous wake-up source, according to Table 13-13 on page 240.
0: The corresponding wake up is disabled.
1: The corresponding wake up is enabled
31 30 29 28 27 26 25 24
AWEN[31:24]
23 22 21 20 19 18 17 16
AWEN[23:16]
15 14 13 12 11 10 9 8
AWEN[15:8]
76543210
AWEN[7:0]
Table 13-13. Asynchronous Wake-up Sources
Bit Asynchronous Wake-up Source
0 CAT
1 ACIFB
2 ADCIFB
3 TWIS0
4 TWIS1
5 WAKEN
6 ADCIFBPD
7 USBC
31:8 -
241
32142D–06/2013
ATUC64/128/256L3/4U
13.7.19 Configuration Register
Name: CONFIG
Access Type: Read-Only
Offset: 0x3F8
Reset Value: -
This register shows the configuration of the PM.
• HSBPEVC:HSB PEVC Clock Implemented
0: HSBPEVC not implemented.
1: HSBPEVC implemented.
• PBD: PBD Implemented
0: PBD not implemented.
1: PBD implemented.
• PBC: PBC Implemented
0: PBC not implemented.
1: PBC implemented.
• PBB: PBB Implemented
0: PBB not implemented.
1: PBB implemented.
• PBA: PBA Implemented
0: PBA not implemented.
1: PBA implemented.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
HSBPEVC - - - PBD PBC PBB PBA
242
32142D–06/2013
ATUC64/128/256L3/4U
13.7.20 Version Register
Name: VERSION
Access Type: Read-Only
Offset: 0x3FC
Reset Value: -
• VARIANT: Variant Number
Reserved. No functionality associated.
• VERSION: Version Number
Version number of the module. No functionality associated.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
- - - - VARIANT
15 14 13 12 11 10 9 8
- - - - VERSION[11:8]
76543210
VERSION[7:0]
243
32142D–06/2013
ATUC64/128/256L3/4U
13.8 Module Configuration
The specific configuration for each PM instance is listed in the following tables. The module bus
clocks listed here are connected to the system bus clocks. Please refer to the “Synchronous
Clocks”, “Peripheral Clock Masking” and “Sleep Modes” sections for details.
Table 13-14. Power Manager Clocks
Clock Name Description
CLK_PM Clock for the PM bus interface
Table 13-15. Register Reset Values
Register Reset Value
VERSION 0x00000420
Table 13-16. Effect of the Different Reset Events
Power-on
Reset
External
Reset
Watchdog
Reset
BOD
Reset
SM33
Reset
CPU Error
Reset
OCD
Reset
JTAG
Reset
CPU/HSB/PBx
(excluding Power Manager)
Y Y Y YY Y YY
32KHz oscillator Y N N N N N N N
RC Oscillator Calibration register Y N N N N N N N
Other oscillator control registers Y Y Y Y Y Y Y Y
AST registers, except interrupt
registers
Y N N NN N NN
Watchdog control register Y Y N Y Y Y Y Y
Voltage Calibration register Y N N N N N N N
SM33 control register Y Y Y Y Y Y Y Y
BOD control register Y Y Y N Y Y Y Y
Clock control registers Y Y Y Y Y Y Y Y
OCD system and OCD registers Y Y N Y Y Y N Y
244
32142D–06/2013
ATUC64/128/256L3/4U
14. System Control Interface (SCIF)
Rev: 1.1.0.0
14.1 Features
• Supports crystal oscillator 0.45-16MHz (OSC0)
• Supports Digital Frequency Locked Loop 20-150MHz (DFLL)
• Supports Phase Locked Loop 80-240MHz (PLL)
• Supports 32KHz ultra-low-power oscillator (OSC32K)
• Supports 32kHz RC oscillator (RC32K)
• Integrated low-power RC oscillator (RCSYS)
• Generic clocks (GCLK) with wide frequency range provided
• Generic Clock Prescaler
• Controls Bandgap
• Controls Brown-out detectors (BOD) and supply monitors
• Controls Voltage Regulator (VREG) behavior and calibration
• Controls Temperature Sensor
• Controls Supply Monitor 33 (SM33) operating modes and calibration
• Controls 120MHz integrated RC Oscillator (RC120M)
• Four 32-bit general-purpose backup registers
14.2 Overview
The System Control Interface (SCIF) controls the oscillators, Generic Clocks, BODs, Bandgap,
VREG, Temperature Sensor, and Backup Registers.
14.3 I/O Lines Description
14.4 Product Dependencies
In order to use this module, other parts of the system must be configured correctly, as described
below.
Table 14-1. I/O Lines Description
Pin Name Pin Description Type
RC32OUT RC32 output at startup Output
XIN0 Crystal 0 Input Analog/Digital
XIN32 Crystal 32 Input (primary location) Analog/Digital
XIN32_2 Crystal 32 Input (secondary location) Analog/Digital
XOUT0 Crystal 0 Output Analog
XOUT32 Crystal 32 Output (primary location) Analog
XOUT32_2 Crystal 32 Output (secondary location) Analog
GCLK9-GCLK0 Generic Clock Output Output
GCLK_IN2-GCLK_IN0 Generic Clock Input Input
245
32142D–06/2013
ATUC64/128/256L3/4U
14.4.1 I/O Lines
The SCIF provides a number of generic clock outputs, which can be connected to output pins,
multiplexed with GPIO lines. The programmer must first program the GPIO controller to assign
these pins to their peripheral function. If the I/O pins of the SCIF are not used by the application,
they can be used for other purposes by the GPIO controller. Oscillator pins are also multiplexed
with GPIO. When oscillators are used, the related pins are controlled directly by the SCIF, overriding
GPIO settings.
RC32OUT will be output after reset, and the GPIO controller can assign this pin to other peripheral
function after start-up.
14.4.2 Power Management
The BODs and all the oscillators, except the 32KHz oscillator (OSC32K) are turned off in some
sleep modes and turned automatically on when the device wakes up. The Voltage Regulator is
set in low power mode in some sleep modes and automatically set back in normal mode when
the device wakes up. Please refer to the Power Manager chapter for details.
The BOD control registers will not be reset by the Power Manager on a BOD reset.
14.4.3 Clocks
The SCIF controls all oscillators in the device. The oscillators can be used as source for the CPU
and peripherals. Selection of source is done in the Power Manager. The oscillators can also be
used as source for generic clocks.
14.4.4 Interrupts
The SCIF interrupt request line is connected to the interrupt controller. Using the SCIF interrupt
requires the interrupt controller to be programmed first.
14.4.5 Debug Operation
The SCIF does not interact with debug operations.
14.5 Functional Description
14.5.1 Oscillator (OSC) Operation
Rev: 1.1.1.0
The main oscillator (OSCn) is designed to be used with an external 0.450 to 16MHz crystal and
two biasing capacitors, as shown in the Electrical Characteristics chapter, or with an external
clock connected to the XIN. The oscillator can be used as source for the main clock in the
device, as described in the Power Manager chapter. The oscillator can be used as source for the
generic clocks, as described in the Generic Clocks section.
The oscillator is disabled by default after reset. When the oscillator is disabled, the XIN and
XOUT pins can be used as general purpose I/Os. When the oscillator is enabled, the XIN and
XOUT pins are controlled directly by the SCIF, overriding GPIO settings. When the oscillator is
configured to use an external clock, the clock must be applied to the XIN pin while the XOUT pin
can be used as general purpose I/O.
The oscillator is enabled by writing a one to the Oscillator Enable bit in the Oscillator Control register
(OSCCTRLn.OSCEN). Operation mode (external clock or crystal) is selected by writing to
the Oscillator Mode bit in OSCCTRLn (OSCCTRLn.MODE). The oscillator is automatically dis-
246
32142D–06/2013
ATUC64/128/256L3/4U
abled in certain sleep modes to reduce power consumption, as described in the Power Manager
chapter.
After a hard reset, or when waking up from a sleep mode where the oscillators were disabled,
the oscillator will need a certain amount of time to stabilize on the correct frequency. This startup
time can be set in the OSCCTRLn register.
The SCIF masks the oscillator outputs during the start-up time, to ensure that no unstable clocks
propagate to the digital logic.
The OSCn Ready bit in the Power and Clock Status Register (PCLKSR.OSCnRDY) is set when
the oscillator is stable and ready to be used as clock source. An interrupt can be generated on a
zero-to-one transition on OSCnRDY if the OSCnRDY bit in the Interrupt Mask Register
(IMR.OSCnRDY) is set. This bit is set by writing a one to the corresponding bit in the Interrupt
Enable Register (IER.OSCnRDY).
14.5.2 32KHz Oscillator (OSC32K) Operation
Rev: 1.1.0.1
The 32KHz oscillator operates as described for the oscillator above. The 32KHz oscillator can
be used as source clock for the Asynchronous Timer (AST) and the Watchdog Timer (WDT).
The 32KHz oscillator can also be used as source for the generic clocks.
The oscillator is disabled by default after reset. When the oscillator is disabled, the XIN32 and
XOUT32 pins can be used as general-purpose I/Os. When the oscillator is enabled, the XIN32
and XOUT32 pins are controlled directly by the SCIF, overriding GPIO settings. When the oscillator
is configured to use an external clock, the clock must be applied to the XIN32 pin while the
XOUT32 pin can be used as general-purpose I/O.
The oscillator is enabled writing a one to the OSC32 Enable bit in the 32KHz Oscillator Control
Register (OSCCTRL32OSC32EN). The oscillator is disabled by writing a zero to the OSC32EN
bit, while keeping the other bits unchanged. Writing to OSC32EN while also writing to other bits
may result in unpredictable behavior. Operation mode (external clock or crystal) is selected by
writing to the Oscillator Mode bit in OSCCTRL32 (OSCCTRL32.MODE). The oscillator is an
ultra-low-power design and remains enabled in all sleep modes.
The start-up time of the 32KHz oscillator is selected by writing to the Oscillator Start-up Time
field in the OSCCTRL32 register (OSCCTRL32.STARTUP). The SCIF masks the oscillator output
during the start-up time, to ensure that no unstable clock cycles propagate to the digital logic.
The OSC32 Ready bit in the Power and Clock Status Register (PCLKSR.OSC32RDY) is set
when the oscillator is stable and ready to be used as clock source. An interrupt can be generated
on a zero-to-one transition on PCLKSR.OSC32RDY if the OSC32RDY bit in the Interrupt
Mask Register (IMR.OSC32RDY) is set. This bit is set by writing a one to the corresponding bit
in the Interrupt Enable Register (IER.OSC32RDY).
.As a crystal oscillator usually requires a very long start-up time (up to 1 second), the 32KHz
oscillator will keep running across resets, except a Power-on Reset (POR).
The 32KHz oscillator also has a 1KHz output. This is enabled by writing a one to the Enable
1KHz output bit in OSCCTRL32 register (OSCCTRL32.EN1K). If the 32KHz output clock is not
needed when 1K is enabled, this can be disabled by writing a zero to the Enable 32KHz output
bit in the OSCCTRL32 register (OSCCTRL32.EN32K). OSCCTRL32.EN32K is set after a POR.
The 32KHz oscillator has two possible sets of pins. To select between them write to the Pin
Select bit in the OSCCTRL32 register (OSCCTRL32.PINSEL). If the 32KHz oscillator is to be
247
32142D–06/2013
ATUC64/128/256L3/4U
used in Shutdown mode, PINSEL must be written to one, and XIN32_2 and XOUT32_2 must be
used.
14.5.3 PLL Operation
Rev: 1.1.0.0
The device contains one Phase Locked Loop (PLL), which is controlled by the Phase Locked
Loop Interface (PLLIF). The PLL is disabled by default, but can be enabled to provide high frequency
source clocks for synchronous or generic clocks. The PLL can use different clock
sources as reference clock, please refer to the “PLL Clock Sources” table in the SCIF Module
Configuration section for details. The PLL output is divided by a multiplication factor, and the
PLL compares the phase of the resulting clock to the reference clock. The PLL will adjust its output
frequency until the two compared clocks phases are equal, thus locking the output frequency
to a multiple of the reference clock frequency.
When the PLL is switched on, or when changing the clock source or multiplication factor for the
PLL, the PLL is unlocked and the output frequency is undefined. The PLL clock for the digital
logic is automatically masked when the PLL is unlocked, to prevent the connected digital logic
from receiving a too high frequency and thus become unstable.
The PLL can be configured by writing the PLL Control Register (PLLn). To prevent unexpected
writes due to software bugs, write access to the PLLn register is protected by a locking mechanism,
for details please refer to the UNLOCK register description.
Figure 14-1. PLL with Control Logic and Filters
14.5.3.1 Enabling the PLL
Before the PLL is enabled it must be set up correctly. The PLL Oscillator Select field (PLLOSC)
selects a source for the reference clock. The PLL Multiply Factor (PLLMUL) and PLL Division
Phase
Detector
Output
Divider
Source
clocks
PLLOSC PLLOPT[0]
PLLMUL
Lock bit
Mask PLL clock
Input
Divider
PLLDIV
1/2
PLLOPT[1]
0
1
VCO
fvco fPLL
Lock
Counter
fREF
248
32142D–06/2013
ATUC64/128/256L3/4U
Factor (PLLDIV) fields must be written with the multiplication and division factors, respectively.
The PLLMUL must always be greater than 1, creating the PLL frequency:
fvco = (PLLMUL+1)/PLLDIV • fREF, if PLLDIV >0
fvco = 2•(PLLMUL+1) • fREF, if PLLDIV = 0
The PLL Options (PLLOPT) field should be configured to proper values according to the PLL
operating frequency. The PLLOPT field can also be configured to divide the output frequency of
the PLL by 2 and Wide-Bandwidth mode, which allows faster startup time and out-of-lock time.
It is not possible to change any of the PLL configuration bits when the PLL is enabled, Any write
to PLLn while the PLL is enabled will be discarded.
After setting up the PLL, the PLL is enabled by writing a one to the PLL Enable (PLLEN) bit in
the PLLn register.
14.5.3.2 Disabling the PLL
The PLL is disabled by writing a zero to the PLL Enable (PLLEN) bit in the PLLn register. After
disabling the PLL, the PLL configuration fields becomes writable.
14.5.3.3 PLL Lock
The lock signal for each PLL is available as a PLLLOCKn flag in the PCLKSR register. If the lock
for some reason is lost, the PLLLOCKLOSTn flag in PCLKSR register will be set. An interrupt
can be generated on a 0 to 1 transition of these bits.
14.5.4 Digital Frequency Locked Loop (DFLL) Operation
Rev: 2.1.0.1
The DFLL is controlled by the Digital Frequency Locked Loop Interface (DFLLIF). The DFLL is
disabled by default, but can be enabled to provide a high-frequency source clock for synchronous
and generic clocks.
Features:
• Internal oscillator with no external components
• 20-150MHz frequency in closed loop mode
• Can operate standalone as a high-frequency programmable oscillator in open loop mode
• Can operate as an accurate frequency multiplier against a known frequency in closed loop
mode
• Optional spread-spectrum clock generation
• Very high-frequency multiplication supported - can generate all frequencies from a 32KHz
clock
The DFLL can operate in both open loop mode and closed loop mode. In closed loop mode a
low frequency clock with high accuracy can be used as reference clock to get high accuracy on
the output clock (CLK_DFLL).
To prevent unexpected writes due to software bugs, write access to the configuration registers is
protected by a locking mechanism. For details please refer to the UNLOCK register description.
249
32142D–06/2013
ATUC64/128/256L3/4U
Figure 14-2. DFLLIF Block Diagram
14.5.4.1 Enabling the DFLL
The DFLL is enabled by writing a one to the Enable bit (EN) in the DFLLn Configuration Register
(DFLLnCONF). No other bits or fields in DFLLnCONF must be changed simultaneously, or
before the DFLL is enabled.
14.5.4.2 Internal synchronization
Due to multiple clock domains in the DFLLIF, values in the DFLLIF configuration registers need
to be synchronized to other clock domains. The status of this synchronization can be read from
the Power and Clocks Status Register (PCLKSR). Before writing to a DFLLIF configuration register,
the user must check that the DFLLn Synchronization Ready bit (DFLLnRDY) in PCLKSR is
set. When this bit is set, the DFLL can be configured, and CLK_DFLL is ready to be used. Any
write to a DFLLIF configuration register while DFLLnRDY is cleared will be ignored.
Before reading the value in any of the DFLL configuration registers a one must be written to the
Synchronization bit (SYNC) in the DFLLn Synchronization Register (DFLLnSYNC). The DFLL
configuration registers are ready to be read when PCLKSR.DFLLnRDY is set.
14.5.4.3 Disabling the DFLL
The DFLL is disabled by writing a zero to DFLLnCONF.EN. No other bits or fields in DFLLnCONF
must be changed simultaneously.
After disabling the DFLL, PCLKSR.DFLLnRDY will not be set. It is not required to wait for
PCLKSR.DFLLnRDY to be set before re-enabling the DFLL.
14.5.4.4 Open loop operation
After enabling the DFLL, open loop mode is selected by writing a zero to the Mode Selection bit
(MODE) in DFLLnCONF. When operating in open loop mode the output frequency of the DFLL
will be determined by the values written to the Coarse Calibration Value field (COARSE) and the
Fine Calibration Value field (FINE) in the DFLLnCONF register. When writing to COARSE and
DFLL
COARSE
FINE
8
9
CLK_DFLL
IMUL
FMUL 32
CLK_DFLLIF_REF
FREQUENCY
TUNER
DFLLLOCKC
DFLLLOCKLOSTC
DFLLLOCKF
DFLLLOCKLOSTF
DFLLLOCKA
DFLLLOCKLOSTA
CSTEP
FSTEP 8+9 CLK_DFLLIF_DITHER
250
32142D–06/2013
ATUC64/128/256L3/4U
FINE, be aware that the output frequency must not exceed the maximum frequency of the
device after the division in the clock generator. It is possible to change the value of COARSE
and FINE, and thereby the output frequency of the DFLL, while the DFLL is enabled and in use.
The DFLL clock is ready to be used when PCLKSR.DFLLnRDY is cleared after enabling the
DFLL.
The frequency range in open loop mode is 20-150MHz, but maximum frequency can be higher,
and the minimum frequency can be lower. The best way to start the DFLL at a specific frequency
in open loop mode is to first configure it for closed loop mode, see Section 14.5.4.5. When a lock
is achieved, read back the COARSE and FINE values and switch to open loop mode using these
values. An alternative approach is to use the Frequency Meter (FREQM) to monitor the DFLL
frequency and adjust the COARSE and FINE values based on measurement results form the
FREQM. Please refer to the FREQM chapter for more information on how to use it. Note that the
output frequency of the DFLL will drift when in open loop mode due to temperature and voltage
changes. Please refer to the Electrical Characteristics chapter for details.
14.5.4.5 Closed loop operation
The DFLL must be correctly configured before closed loop operation can be enabled. After
enabling the DFLL, enable and select a reference clock (CLK_DFLLIF_REF).
CLK_DFLLIF_REF is a generic clock, please refer to Generic Clocks section for details. Then
set the maximum step size allowed in finding the COARSE and FINE values by setting the
Coarse Maximum Step field (CSTEP) and Fine Maximum Step field (FSTEP) in the DFLLn Maximum
Step Register (DFLLnSTEP). A small step size will ensure low overshoot on the output
frequency, but can typically result in longer lock times. A high value might give a big overshoot,
but can typically give faster locking. DFLLnSTEP.CSTEP and DFLLnSTEP.FSTEP must be
lower than 50% of the maximum value of DFLLnCONF.COARSE and DFLLnCONF.FINE
respectively. Then select the multiplication factor in the Integer Multiply Factor field (IMUL) and
the Fractional Multiply field (FMUL) in the DFLLn Multiplier Register (DFLLnMUL). Care must be
taken when choosing IMUL and FMUL so the output frequency does not exceed the maximum
frequency of the device. Start the closed loop mode by writing a one to DFLLnCONF.MODE bit.
The frequency of CLK_DFLL (fDFLL) is given by:
where fREF is the frequency of CLK_DFLLIF_REF. COARSE and FINE in DFLLnCONF are readonly
in closed loop mode, and are controlled by the DFLLIF to meet user specified frequency.
The values in COARSE when the closed loop mode is enabled is used by the frequency tuner as
a starting point for COARSE. Setting COARSE to a value close to the final value will reduce the
time needed to get a lock on COARSE.
Frequency locking
The locking of the frequency in closed loop mode is divided into three stages. In the COARSE
stage the control logic quickly finds the correct value for DFLLnCONF.COARSE and thereby
sets the output frequency to a value close to the correct frequency. The DFLLn Locked on
Coarse Value bit (DFLLnLOCKC) in PCLKSR will be set when this is done. In the FINE stage the
control logic tunes the value in DFLLnCONF.FINE so the output frequency will be very close to
the desired frequency. DFLLn Locked on Fine Value bit (DFLLnLOCKF) in PCLKSR will be set
when this is done. In the ACCURATE stage the DFLL frequency tuning mechanism uses dithering
on the FINE bits to obtain an accurate average output frequency. DFLLn Locked on Accurate
Value bit (DFLLnLOCKA) in PCLKSR will be set when this is done. The ACCURATE stage will
f
DFLL IMUL FMUL
216
+ ----------------- f
REF =
251
32142D–06/2013
ATUC64/128/256L3/4U
only be executed if the Dithering Enable bit (DITHER) in DFLLnCONF has been written to a one.
If DITHER is written to a zero DFLLnLOCKA will never occur. If dithering is enabled, the frequency
of the dithering is decided by a generic clock (CLK_DFLLIF_DITHER). This clock has to
be set up correctly before enabling dithering. Please refer to the Generic Clocks section for
details.
Figure 14-3. DFLL Closed loop State Diagram
When dithering is enabled the accuracy of the average output frequency of the DFLL will be
higher. However, the actual frequency will be alternating between two frequencies. If a fixed frequency
is required, the dithering should not be enabled.
Figure 14-4. DFLL Locking in Closed loop
CLK_DFLL is ready to be used when the DFLLn Synchronization Ready bit (DFLLnRDY) in
PCLKSR is set after enabling the DFLL. However, the accuracy of the output frequency depends
on which locks are set.
For lock times, please refer to the Electrical Characteristics chapter.
Measure
fDFLLn
Calculate
new
COARSE
value
DFLLnLOCKC
0
Calculate
new FINE
value
DFLLnLOCKF
0
1 1 DFLLnLOCKA
Calculate
new
dithering
dutycycle
0
Compensate
for
drift
1 DITHER 1
Compensate
for
drift
0
Initial
frequency
Target
frequency
DFLLnLOCKC DFLLnLOCKF DFLLnLOCKA
252
32142D–06/2013
ATUC64/128/256L3/4U
Drift compensation
The frequency tuner will automatically compensate for drift in the fDFLL without losing either of the
locks. If the FINE value overflows or underflows, which should normally not happen, but could
occur due to large drift in temperature and voltage, all locks will be lost, and the COARSE and
FINE values will be recalibrated as described earlier. If any lock is lost the corresponding bit in
PCLKSR will be set, DFLLn Lock Lost on Coarse Value bit (DFLLnLOCKLOSTC) for lock lost on
COARSE value, DFLLn Lock Lost on Fine Value bit (DFLLnLOCKLOSTF) for lock lost on FINE
value and DFLLn Lock Lost on Accurate Value bit (DFLLnLOCKLOSTA) for lock lost on ACCURATE
value. The corresponding lock status bit will be cleared when the lock lost bit is set, and
vice versa.
Reference clock stop detection
If CLK_DFLLIF_REF stops or is running at a very slow frequency, the DFLLn Reference Clock
Stopped bit (DFLLnRCS) in PCLKSR will be set. Note that the detection of the clock stop will
take a long time. The DFLLIF operate as if it was in open loop mode if it detects that the reference
clock has stopped. This means that the COARSE and FINE values will be kept constant
while PCLKSR.DFLLnRCS is set. Closed loop mode operation will automatically resume if the
CLK_DFLLIF_REF is restarted, and compensate for any drift during the time CLK_DFLLIF_REF
was stopped. No locks will be lost.
Frequency error measurement
The ratio between CLK_DFLLIF_REF and CLK_DFLL is measured automatically by the DFLLIF.
The difference between this ratio and DFLLnMUL is stored in the Multiplication Ratio Difference
field (RATIODIFF) in the DFLLn Ratio Register (DFLLnRATIO). The relative error on CLK_DFLL
compared to the target frequency can be calculated as follows:
where is the number of reference clock cycles the DFLLIF is using for calculating the
ratio.
14.5.4.6 Dealing with delay in the DFLL
The time from selecting a new frequency until this frequency is output by the DFLL, can be up to
several micro seconds. If the difference between the desired output frequency (CLK_DFLL) and
the frequency of CLK_DFLLIF_REF is small this can lead to an instability in the DFLLIF locking
mechanism, which can prevent the DFLLIF from achieving locks. To avoid this, a chill cycle
where the CLK_DFLL frequency is not measured can be enabled. The chill cycle is enabled by
writing a one to the Chill Cycle Enable (CCEN) bit in the DFLLnCONF register. Enabling chill
cycles might double the lock time,
Another solution to the same problem can be to use less strict lock requirements. This is called
Quick Lock (QL), which is enabled by writing a one to the Quick Lock Enable (QLEN) bit in the
DFLLnCONF register. The QL might lead to bigger spread in the outputted frequency than chill
cycles, but the average output frequency is the same.
If the target frequency is below 40MHz, one of these methods should always be used.
14.5.4.7 Spread Spectrum Generator (SSG)
When the DFLL is used as the main clock source for the device, the EMI radiated from the
device will be synchronous to fDFLL. To provide better Electromagnetic Compatibility (EMC) the
error RATIODIFF fREF
2NUMREF f
DFLL = ------------------------------------------------
2NUMREF
253
32142D–06/2013
ATUC64/128/256L3/4U
DFLLIF can provide a clock with the energy spread in the frequency domain. This is done by
adding or subtracting values from the FINE value. SSG is enabled by writing a one to the Enable
bit (EN) in the DFLLn Spread Spectrum Generator Control Register (DFLLnSSG).
A generic clock sets the rate at which the SSG changes the frequency of the DFLL clock to generate
a spread spectrum (CLK_DFLLIF_DITHER). This is the same clock used by the dithering
mechanism. The frequency of this clock should be higher than fREF to ensure that the DFLLIF
can lock. Please refer to the Generic clocks section for details.
Optionally, the clock ticks can be qualified by a Pseudo Random Binary Sequence (PRBS) if the
PRBS bit in DFLLnSSG is one. This reduces the modulation effect of CLK_DFLLIF_DITHER frequency
onto fDFLL.
The amplitude of the frequency variation can be selected by setting the SSG Amplitude field
(AMPLITUDE) in DFLLnSSG. If AMPLITUDE is zero the SSG will toggle on the LSB of the FINE
value. If AMPLITUDE is one the SSG will add the sequence {1,-1, 0} to FINE.
The step size of the SSG is selected by writing to the SSG Step Size field (STEPSIZE) in
DFLLnSSG. STEPSIZE equal to zero or one will result in a step size equal to one. If the step
size is set to n, the output value from the SSG will be incremented/decremented by n on every
tick of the source clock.
The Spread Spectrum Generator is available in both open and closed loop mode.
When spread spectrum is enabled in closed loop mode, and the AMPLITUDE is high, an overflow/underflow
in FINE is more likely to occur.
Figure 14-5. Spread Spectrum Generator Block Diagram.
14.5.4.8 Wake from sleep modes
The DFLLIF may optionally reset its lock bits when waking from a sleep mode which disables the
DFLL. This is configured by the Lose Lock After Wake (LLAW) bit in DFLLnCONF register. If
DFLLnCONF.LLAW is written to zero the DFLL will be re-enabled and start running with the
same configuration as before going to sleep even if the reference clock is not available. The
locks will not be lost. When the reference clock has restarted, the FINE tracking will quickly compensate
for any frequency drift during sleep. If a one is written to DFLLnCONF.LLAW before
going to a sleep mode where the DFLL is turned off, the DFLLIF will lose all its locks when waking
up, and needs to regain these through the full lock sequence.
14.5.4.9 Accuracy
There are mainly three factors that decide the accuracy of the fDFLL. These can be tuned to
obtain maximum accuracy when fine lock is achieved.
Pseudorandom
Binary Sequence Spread Spectrum
Generator
FINE
9
To DFLL CLK_DFLLIF_DITHER
AMPLITUDE,
STEPSIZE PRBS
1
0
254
32142D–06/2013
ATUC64/128/256L3/4U
• FINE resolution: The frequency step between two FINE values. This is relatively smaller for
high output frequencies.
• Resolution of the measurement: If the resolution of the measured fDFLL is low, i.e. the ratio
between CLK_DFLL frequency and CLK_DFLLIF_REF is small, then the DFLLIF might lock
at a frequency that is lower than the targeted frequency. It is recommended to use a
reference clock frequency of 32 KHz or lower to avoid this issue for low target frequencies.
• The accuracy of the reference clock.
14.5.4.10 Interrupts
A interrupt can be generated on a zero-to-one transaction on DFLLnLOCKC, DFLLnLOCKF,
DFLLnLOCKA, DFLLnLOCKLOSTC, DFLLnLOCKLOSTF, DFLLnLOCKLOSTA, DFLLnRDY or
DFLLnRCS.
14.5.5 Brown-Out Detection (BOD)
Rev: 1.2.0.0
The Brown-Out Detector monitors the VDDCORE supply pin and compares the supply voltage
to the brown-out detection level.
The BOD is disabled by default, and is enabled by writing to the BOD Control field in the BOD
Control Register (BOD.CTRL). This field can also be updated by flash fuses.
The BOD is powered by VDDIO and will not be powered during Shutdown sleep mode.
To prevent unexpected writes to the BOD register due to software bugs, write access to this register
is protected by a locking mechanism. For details please refer to the UNLOCK register
description.
To prevent further modifications by software, the content of the BOD register can be set as readonly
by writing a one to the Store Final Value bit (BOD.SFV). When this bit is one, software can
not change the BOD register content. This bit is cleared after flash calibration and after a reset
except after a BOD reset.
The brown-out detection level is selected by writing to the BOD Level field in BOD
(BOD.LEVEL). Please refer to the Electrical Characteristics chapter for parametric details.
If the BOD is enabled (BOD.CTRL is one or two) and the supply voltage goes below the detection
level, the Brown-Out Detection bit in the Power and Clocks Status Register
(PCLKSR.BODDET) is set. This bit is cleared when the supply voltage goes above the detection
level. An interrupt request will be generated on a zero-to-one transition on PCLKSR.BODDET if
the Brown-Out Detection bit in the Interrupt Mask Register (IMR.BODDET) is set. This bit is set
by writing a one to the corresponding bit in the Interrupt Enable Register (IER.BODDET).
If BOD.CTRL is one, a BOD reset will be generated when the supply voltage goes below the
detection level. If BOD.CTRL is two, the device will not be reset.
Writing a one to the BOD Hysteresis bit in BOD (BOD.HYST) will add a hysteresis on the BOD
detection level.
Note that the BOD must be disabled before changing BOD.LEVEL, to avoid spurious reset or
interrupt. After enabling the BOD, the BOD output will be masked during one half of a RCSYS
clock cycle and two main clocks cycles to avoid false results.
When the JTAG or aWire is enabled, the BOD reset and interrupt are masked.
255
32142D–06/2013
ATUC64/128/256L3/4U
The CTRL, HYST, and LEVEL fields in the BOD Control Register are loaded factory defined calibration
values from flash fuses after a reset. If the Flash Calibration Done bit in the BOD Control
Register (BOD.FCD) is zero, the flash calibration will be redone after any reset, and the
BOD.FCD bit will be set before program execution starts in the CPU. If BOD.FCD is one, the
flash calibration is redone after any reset except for a BOD reset. The BOD.FCD bit is cleared
after a reset, except for a BOD reset. BOD.FCD is set when these fields have been updated after
a flash calibration. It is possible to override the values in the BOD.CTRL, BOD.HYST, and
BOD.LEVEL fields after reset by writing to the BOD Control Register. Please refer to the Fuse
Settings chapter for more details about BOD fuses and how to program the fuses.
Figure 14-6. BOD Block Diagram
14.5.6 Bandgap
Rev: 1.2.0.0
The flash memory, the BOD, and the Temperature Sensor need a stable voltage reference to
operate. This reference voltage is provided by an internal Bandgap voltage reference. This reference
is automatically turned on at start-up and turned off during some sleep modes to save
power. The Bandgap reference is powered by the internal regulator supply voltage and will not
be powered during Shutdown sleep mode. Please refer to the Power Manager chapter for
details.
VDDCORE
POR18 BOD
SCIF
POWER MANAGER(PM) INTC
Reset
Bod
Detected
Enable
BO
D Hyst
BOD
Level
Reset
In et rrupt
256
32142D–06/2013
ATUC64/128/256L3/4U
14.5.7 System RC Oscillator (RCSYS)
Rev: 1.1.1.0
The system RC oscillator has a startup time of three cycles, and is always available except in
some sleep modes. Please refer to the Power Manager chapter for details. The system RC oscillator
operates at a nominal frequency of 115kHz, and is calibrated using the Calibration Value
field (CALIB) in the RC Oscillator Calibration Register (RCCR). After a Power-on Reset (POR),
the RCCR.CALIB field is loaded with a factory defined value stored in the Flash fuses. Please
refer to the Fuse setting chapter for more details about RCCR fuses and how to program the
fuses.
If the Flash Calibration Done (FCD) bit in the RCCR is zero at any reset, the flash calibration will
be redone and the RCCR.FCD bit will be set before program execution starts in the CPU. If the
RCCR.FCD is one, the flash calibration will only be redone after a Power-on Reset.
To prevent unexpected writes to RCCR due to software bugs, write access to this register is protected
by a locking mechanism. For details please refer to the UNLOCK register description.
Although it is not recommended to override default factory settings, it is still possible to override
the default values by writing to RCCR.CALIB.
14.5.8 Voltage Regulator (VREG)
Rev: 1.1.0.0
The embedded voltage regulator can be used to provide the VDDCORE voltage from the internal
regulator supply voltage. It is controlled by the Voltage Regulator Calibration Register
(VREGCR). The voltage regulator is enabled by default at start-up but can be disabled by software
if an external voltage is provided on the VDDCORE pin. The VREGCR also contains bits to
control the POR18 detector and the POR33 detector.
14.5.8.1 Register protection
To prevent unexpected writes to VREGCR due to software bugs, write access to this register is
protected by a locking mechanism. For details please refer to the UNLOCK register description.
To prevent further modifications by software, the content of the VREGCR register can be set as
read-only by writing a one to the Store Final Value bit (VREGCR.SFV). Once this bit is set, software
can not change the VREGCR content until a Power-on Reset (POR) is applied.
14.5.8.2 Controlling voltage regulator output
The voltage regulator is always enabled at start-up, i.e. after a POR or when waking up from
Shutdown mode. It can be disabled by software by writing a zero to the Enable bit
(VREGCR.EN). This bit is set after a POR. Because of internal synchronization, the voltage regulator
is not immediately enabled or disabled. The actual state of the voltage regulator can be
read from the ON bit (VREGCR.ON).
The voltage regulator output level is controlled by the Select VDD field (SELVDD) in VREGCR.
The default value of this field corresponds to a regulator output voltage of 1.8V. Other values of
this field are not defined, and it is not recommended to change the value of this field.
The Voltage Regulator OK bit (VREGCR.VREGOK) bit indicates when the voltage regulator output
has reached the voltage threshold level.
257
32142D–06/2013
ATUC64/128/256L3/4U
14.5.8.3 Factory calibration
After a Power-on Reset (POR) the VREGCR.CALIB field is loaded with a factory defined calibration
value. This value is chosen so that the normal output voltage of the regulator after a powerup
is 1.8V.
Although it is not recommended to override default factory settings, it is still possible to override
these default values by writing to VREGCR.CALIB.
If the Flash Calibration Done bit in VREGCR (VREGCR.FCD) is zero, the flash calibration will be
redone after any reset, and the VREGCR.FCD bit will be set before program execution starts in
the CPU. If VREGCR.FCD is one, the flash calibration will only be redone after a POR.
14.5.8.4 POR33 control
VREGCR includes control bits for the Power-on Reset 3.3V (POR33) detector that monitors the
internal regulator supply voltage. The POR33 detector is enabled by default but can be disabled
by software to reduce power consumption. The 3.3V Supply Monitor (SM33) can then be used to
monitor the regulator power supply.
The POR33 detector is disabled by writing a zero to the POR33 Enable bit
(VREGCR.POR33EN). Because of internal synchronisation, the POR33 detector is not immediately
enabled or disabled. The actual state of the POR33 detector can be read from the POR33
Status bit (VREGCR.POR33STATUS).
The 32kHz RC oscillator (RC32K) must be enabled before disabling the POR33 detector. Once
the POR33 detector has been disabled, the RC32K oscillator can be disabled again.
To avoid spurious resets, it is mandatory to mask the Power-on Reset when enabling or disabling
the POR33 detector. The Power-on Reset generated by the POR33 detector can be
ignored by writing a one to the POR33 Mask bit (VREGCR.POR33MASK). Because of internal
synchronization, the masking is not immediately effective, so software should wait for the
VREGCR.POR33MASK to read as a one before assuming the masking is effective.
The output of the POR33 detector is zero if the internal regulator supply voltage is below the
POR33 power-on threshold level, and one if the internal regulator supply voltage is above the
POR33 power-on threshold level. This output (before masking) can be read from the POR33
Value bit (VREGCR.POR33VALUE).
14.5.8.5 POR18 control
VREGCR includes control bits for the Power-on Reset 1.8V (POR18) detector that monitors the
VDDCORE voltage. The POR18 detector is enabled by default but can be disabled by software
to reduce power consumption.
The POR18 detector is disabled by writing a zero to the POR18 Enable bit
(VREGCR.POR18EN). Because of internal synchronization, the POR18 detector is not immediately
enabled or disabled. The actual state of the POR18 detector can be read from the POR18
Status bit (VREGCR.POR18STATUS).
Please note that the POR18 detector cannot be disabled while the JTAG or aWire debug interface
is used. Writing a zero to VREGCR.POR18EN bit will have no effect.
To avoid spurious resets, it is mandatory to mask the Power-on Reset when enabling or disabling
the POR18 detector. The Power-on Reset generated by the POR18 detector can be
ignored by writing a one to the POR18 Mask bit (VREGCR.POR18MASK). Because of internal
258
32142D–06/2013
ATUC64/128/256L3/4U
synchronisation, the masking is not immediately effective, so software should wait for the
VREGCR.POR18MASK to read as one before assuming the masking is effective.
The output of the POR18 detector is zero if the VDDCORE voltage is below the POR18 poweron
threshold level, and one if the VDDCORE voltage is above the POR18 power-on threshold
level. The output of the POR18 detector (before masking) can be read from the POR18 Value bit
(VREGCR.POR18VALUE).
14.5.9 3.3 V Supply Monitor (SM33)
Rev: 1.1.0.0
The 3.3V supply monitor is a specific voltage detector for the internal regulator supply voltage. It
will indicate if the internal regulator supply voltage is above the minimum required input voltage
threshold. The user can choose to generate either a Power-on Reset (POR) and an interrupt
request, or only an interrupt request, when the internal regulator supply voltage drops below this
threshold.
Please refer to the Electrical Characteristics chapter for parametric details.
14.5.9.1 Register protection
To prevent unexpected writes to SM33 register due to software bugs, write access to this register
is protected by a locking mechanism. For details please refer to the UNLOCK register
description.
To prevent further modifications by software, the content of the register can be set as read-only
by writing a one to the Store Final Value bit (SM33.SFV). When this bit is one, software can not
change the SM33 register content until the device is reset.
14.5.9.2 Operating modes
The SM33 is disabled by default and is enabled by writing to the Supply Monitor Control field in
the SM33 control register (SM33.CTRL). The current state of the SM33 can be read from the
Supply Monitor On Indicator bit in SM33 (SM33.ONSM). Enabling the SM33 will disable the
POR33 detector.
The SM33 can operate in continuous mode or in sampling mode. In sampling mode, the SM33 is
periodically enabled for a short period of time, just enough to make a a measurement, and then
disabled for a longer time to reduce power consumption.
By default, the SM33 operates in sampling mode during DeepStop and Static mode and in continuous
mode for other sleep modes. Sampling mode can also be forced during sleep modes
other than DeepStop and Static, and during normal operation, by writing a one to the Force
Sampling Mode bit in the SM33 register (SM33.FS).
The user can select the sampling frequency by writing to the Sampling Frequency field in SM33
(SM33.SAMPFREQ). The sampling mode uses the 32kHz RC oscillator (RC32K) as clock
source. The 32kHz RC oscillator is automatically enabled when the SM33 operates in sampling
mode.
14.5.9.3 Interrupt and reset generation
If the SM33 is enabled (SM33.CTRL is one or two) and the regulator supply voltage drops below
the SM33 threshold, the SM33DET bit in the Power and Clocks Status Register
(PCLKSR.SM33DET) is set. This bit is cleared when the supply voltage goes above the threshold.
An interrupt request is generated on a zer-to-one transition of PCLKSR.SM33DET if the
259
32142D–06/2013
ATUC64/128/256L3/4U
Supply Monitor 3.3V Detection bit in the Interrupt Mask Register (IMR.SM33DET) is set. This bit
is set by writing a one to the corresponding bit in the Interrupt Enable Register (IER.SM33DET).
If SM33.CTRL is one, a POR will be generated when the voltage drops below the threshold. If
SM33.CTRL is two, the device will not be reset.
14.5.9.4 Factory calibration
After a reset the SM33.CALIB field is loaded with a factory defined value. This value is chosen
so that the nominal threshold value is 1.75V. The flash calibration is redone after any reset, and
the Flash Calibration Done bit in SM33 (SM33.FCD) is set before program execution starts in the
CPU.
Although it is not recommended to override default factory settings, it is still possible to override
the default value by writing to SM33.CALIB
14.5.10 Temperature Sensor
Rev: 1.0.0.0
The Temperature Sensor is connected to an ADC channel, please refer to the ADC chapter for
details. It is enabled by writing one to the Enable bit (EN) in the Temperature Sensor Configuration
Register (TSENS). The Temperature Sensor can not be calibrated.
Please refer to the Electrical Characteristics chapter for more details.
14.5.11 120MHz RC Oscillator (RC120M)
Rev: 1.1.0.0
The 120MHz RC Oscillator can be used as source for the main clock in the device, as described
in the Power Manager chapter. The oscillator can also be used as source for the generic clocks,
as described in Generic Clock section. The RC120M must be enabled before it is used as a
source clock. To enable the clock, the user must write a one to the Enable bit in the 120MHz RC
Oscillator Control Register (RC120MCR.EN), and read back the RC120MCR register until the
EN bit reads one. The clock is disabled by writing a zero to RC120MCR.EN. The EN bit must be
read back as zero before the RC120M is re-enabled. If not, undefined behavior may occur.
The oscillator is automatically disabled in certain sleep modes to reduce power consumption, as
described in the Power Manager chapter.
14.5.12 Backup Registers (BR)
Rev: 1.0.0.1
Four 32-bit backup registers are available to store values when the device is in Shutdown
mode. These registers will keep their content even when the VDDCORE supply and the internal
regulator supply voltage supplies are removed. The backup registers can be accessed by reading
from and writing to the BR0, BR1, BR2, and BR3 registers.
After writing to one of the backup registers the user must wait until the Backup Register Interface
Ready bit in tne Power and Clocks Status Register (PCLKSR.BRIFARDY) is set before writing to
another backup register. Writes to the backup register while PCLKSR.BRIFARDY is zero will be
discarded. An interrupt can be generated on a zero-to-one transition on PCLKSR.BRIFARDY if
260
32142D–06/2013
ATUC64/128/256L3/4U
the BRIFARDY bit in the Interrupt Mask Register (IMR.BRIFARDY) is set. This bit is set by writing
a one to the corresponding bit in the Interrupt Enable Register (IER.BRIFARDY).
After powering up the device the Backup Register Interface Valid bit in PCLKSR (PCLKSR.BRIFAVALID)
is cleared, indicating that the content of the backup registers has not been written and
contains the reset value. After writing to one of the backup registers the PCLKSR.BRIFAVALID
bit is set. During writes to the backup registers (when BRIFARDY is zero) BRIFAVALID will be
zero. If a reset occurs when BRIFARDY is zero, BRIFAVALID will be cleared after the reset, indicating
that the content of the backup registers is not valid. If BRIFARDY is one when a reset
occurs, BRIFAVALID will be one and the content is the same as before the reset.
The user must ensure that BRIFAVALID and BRIFARDY are both set before reading the backup
register values.
14.5.13 32kHz RC Oscillator (RC32K)
Rev: 1.1.0.0
The RC32K can be used as source for the generic clocks, as described in The Generic Clocks
section.
The 32kHz RC oscillator (RC32K) is forced on after reset, and output on PA20. The clock is
available on the pad until the PPCR.FRC32 bit in the Power Manager has been cleared or a different
peripheral function has been chosen on PA20 (PA20 will start with peripheral function F
by default). Note that the forcing will only enable the clock output. To be able to use the RC32K
normally the oscillator must be enabled as described below.
The oscillator is enabled by writing a one to the Enable bit in the 32kHz RC Oscillator Configuration
Register (RC32KCR.EN) and disabled by writing a zero to RC32KCR.EN. The oscillator is
also automatically enabled when the sampling mode is requested for the SM33. In this case,
writing a zero to RC32KCR.EN will not disable the RC32K until the sampling mode is no longer
requested.
14.5.14 Generic Clock Prescalers
Rev: 1.0.0.0
The generic clocks can be sourced by two special prescalers to increase the generic clock frequency
precision.
These prescalers are named the High Resolution Prescaler (HRP) and the Fractional Prescaler
(FP).
14.5.14.1 High resolution prescaler
The HRP is a 24-bit counter that can generate a very accurate clock waveform. The clock
obtained has 50% duty cycle.
261
32142D–06/2013
ATUC64/128/256L3/4U
Figure 14-7. High Resolution Prescaler Generation
The HRP is enabled by writing a one to the High Resolution Prescaler Enable (HRPEN) bit in the
High Resolution Prescaler Control Register (HRPCR).
The user can select a clock source for the HRP by writing to the Clock Selection (CKSEL) field of
the HRPCR register.
The user must configure the High Resolution Prescaler Clock (HRPCLK) frequency by writing to
the High Resolution Count (HRCOUNT) field of the High Resolution Counter (HRPCR) register.
This results in the output frequency:
fHRPCLK = fSRC / (2*(HRCOUNT+1))
The CKSEL field can not be changed dynamically but the HRCOUNT field can be changed onthe-fly.
14.5.14.2 Fractional prescaler
The FP generates a clock whose average frequency is more precise than the HRP. However,
this clock frequency is subject to jitter around the target clock frequency. This jitter influence can
be decreased by dividing this clock with the GCLK divider. Moreover the duty cycle of this clock
is not precisely 50%.
Figure 14-8. Fractional Prescaler Generation
The FP is enabled by writing a one to the FPEN bit in the Fractional Prescaler Control Register
(FPCR).
The user can select a clock source for the FP by writing to the CKSEL field of the FPCR register.
Divider
CKSEL
HRPCLK
HRCOUNT
Mask
HRPEN
Divider
CKSEL
FPCLK
FPDIV
Mask
FPMUL FPEN
262
32142D–06/2013
ATUC64/128/256L3/4U
The user must configure the FP frequency by writing to the FPMUL and FPDIV fields of the
FPMUL and FPDIV registers. FPMUL and FPDIV must not be equal to zero and FPDIV must be
greater or equal to FPMUL. This results in the output frequency:
fFPCLK = fSRC * FPMUL/ (2*FPDIV)
The CKSEL field can not be changed dynamically but the FPMUL and FPDIV fields can be
changed on-the-fly.
• Jitter description
As described in Figure 14-9, the CLKFP half period lengths are integer multiples of the source
clock period but are not always equals. However the difference between the low level half period
length and the high level half period length is at the most one source clock period.
This induces when FPDIV is not an integer multiple of FPMUL a jitter on the FPCLK. The more
the FPCLK frequency is low, the more the jitter incidence is reduced.
Figure 14-9. Fractional Prescaler Jitter Examples
14.5.15 Generic Clocks
Rev: 1.1.0.0
Timers, communication modules, and other modules connected to external circuitry may require
specific clock frequencies to operate correctly. The SCIF defines a number of generic clocks that
can provide a wide range of accurate clock frequencies.
Each generic clock runs from either clock source listed in the “Generic Clock Sources” table in
the SCIF Module Configuration section. The selected source can optionally be divided by any
even integer up to 512. Each clock can be independently enabled and disabled, and is also
automatically disabled along with peripheral clocks by the Sleep Controller in the Power
Manager.
SRC clock
FPCLK
FMUL= 5
FDIV=5
FMUL=3
FDIV=10
FMUL=7
FDIV=9
263
32142D–06/2013
ATUC64/128/256L3/4U
Figure 14-10. Generic Clock Generation
14.5.15.1 Enabling a generic clock
A generic clock is enabled by writing a one to the Clock Enable bit (CEN) in the Generic Clock
Control Register (GCCTRL). Each generic clock can individually select a clock source by writing
to the Oscillator Select field (OSCSEL). The source clock can optionally be divided by writing a
one to the Divide Enable bit (DIVEN) and the Division Factor field (DIV), resulting in the output
frequency:
where fSRC is the frequency of the selected source clock, and fGCLK is the output frequency of the
generic clock.
14.5.15.2 Disabling a generic clock
A generic clock is disabled by writing a zero to CEN or entering a sleep mode that disables the
PB clocks. In either case, the generic clock will be switched off on the first falling edge after the
disabling event, to ensure that no glitches occur. After CEN has been written to zero, the bit will
still read as one until the next falling edge occurs, and the clock is actually switched off. When
writing a zero to CEN the other bits in GCCTRL should not be changed until CEN reads as zero,
to avoid glitches on the generic clock. The generic clocks will be automatically re-enabled when
waking from sleep.
14.5.15.3 Changing clock frequency
When changing the generic clock frequency by changing OSCSEL or DIV, the clock should be
disabled before being re-enabled with the new clock source or division setting. This prevents
glitches during the transition.
14.5.15.4 Generic clock allocation
The generic clocks are allocated to different functions as shown in the “Generic Clock Allocation”
table in the SCIF Module Configuration section.
14.5.16 Interrupts
The SCIF has the following interrupt sources:
• AE - Access Error:
– A protected SCIF register was accessed without first being correctly unlocked.
Divider
OSCSEL
Generic Clock
DIV
0
1
DIVEN
Mask
CEN
Sleep Controller
fSRC fGCLK
Generic
Clock
Sources
f
GCLK
f
SRC
2 DIV + 1 = ----------------------------
264
32142D–06/2013
ATUC64/128/256L3/4U
• PLLLOCK - PLL Lock
– A 0 to 1 transition on the PCLKSR.PLLLOCK bit is detected.
• PLLLOCKLOST - PLL Lock Lost
– A to 1 transition on the PCLKSR.PLLLOCKLOST bit is detected.
• BRIFARDY - Backup Register Interface Ready.
– A 0 to 1 transition on the PCLKSR.BRIFARDY bit is detected.
• DFLL0RCS - DFLL Reference Clock Stopped:
– A 0 to 1 transition on the PCLKSR.DFLLRCS bit is detected.
• DFLL0RDY - DFLL Ready:
– A 0 to 1 transition on the PCLKSR.DFLLRDY bit is detected.
• DFLL0LOCKLOSTA - DFLL lock lost on Accurate value:
– A 0 to 1 transition on the PCLKSR.DFLLLOCKLOSTA bit is detected.
• DFLL0LOCKLOSTF - DFLL lock lost on Fine value:
– A 0 to 1 transition on the PCLKSR.DFLLLOCKLOSTF bit is detected.
• DFLL0LOCKLOSTC - DFLL lock lost on Coarse value:
– A 0 to 1 transition on the PCLKSR.DFLLLOCKLOSTC bit is detected.
• DFLL0LOCKA - DFLL Locked on Accurate value:
– A 0 to 1 transition on the PCLKSR.DFLLLOCKA bit is detected.
• DFLL0LOCKF - DFLL Locked on Fine value:
– A 0 to 1 transition on the PCLKSR.DFLLLOCKF bit is detected.
• DFLL0LOCKC - DFLL Locked on Coarse value:
– A 0 to 1 transition on the PCLKSR.DFLLLOCKC bit is detected.
• BODDET - Brown out detection:
– A 0 to 1 transition on the PCLKSR.BODDET bit is detected.
• SM33DET - Supply Monitor 3.3V Detector:
– A 0 to 1 transition on the PCLKSR.SM33DET bit is detected.
• VREGOK - Voltage Regulator OK:
– A 0 to 1 transition on the PCLKSR.VREGOK bit is detected.
• OSC0RDY - Oscillator Ready:
– A 0 to 1 transition on the PCLKSR.OSC0RDY bit is detected.
• OSC32RDY - 32KHz Oscillator Ready:
– A 0 to 1 transition on the PCLKSR.OSC32RDY bit is detected.
The interrupt sources will generate an interrupt request if the corresponding bit in the Interrupt
Mask Register is set. The interrupt sources are ORed together to form one interrupt request. The
SCIF will generate an interrupt request if at least one of the bits in the Interrupt Mask Register
(IMR) is set. Bits in IMR are set by writing a one to the corresponding bit in the Interrupt Enable
Register (IER), and cleared by writing a one to the corresponding bit in the Interrupt Disable
Register (IDR). The interrupt request remains active until the corresponding bit in the Interrupt
Status Register (ISR) is cleared by writing a one to the corresponding bit in the Interrupt Clear
Register (ICR). Because all the interrupt sources are ORed together, the interrupt request from
the SCIF will remain active until all the bits in ISR are cleared.
265
32142D–06/2013
ATUC64/128/256L3/4U
14.6 User Interface
Table 14-2. SCIF Register Memory Map
Offset Register Register Name Access Reset
0x0000 Interrupt Enable Register IER Write-only 0x00000000
0x0004 Interrupt Disable Register IDR Write-only 0x00000000
0x0008 Interrupt Mask Register IMR Read-only 0x00000000
0x000C Interrupt Status Register ISR Read-only 0x00000000
0x0010 Interrupt Clear Register ICR Write-only 0x00000000
0x0014 Power and Clocks Status Register PCLKSR Read-only 0x00000000
0x0018 Unlock Register UNLOCK Write-only 0x00000000
0x001C Oscillator 0 Control Register OSCCTRL0 Read/Write 0x00000000
0x0020 Oscillator 32 Control Register OSCCTRL32 Read/Write 0x00000004
0x0024 DFLL Config Register DFLL0CONF Read/Write 0x00000000
0x0028 DFLL Multiplier Register DFLL0MUL Write-only 0x00000000
0x002C DFLL Step Register DFLL0STEP Write-only 0x00000000
0x0030 DFLL Spread Spectrum Generator Control
Register DFLL0SSG Write-only 0x00000000
0x0034 DFLL Ratio Register DFLL0RATIO Read-only 0x00000000
0x0038 DFLL Synchronization Register DFLL0SYNC Write-only 0x00000000
0x003C BOD Level Register BOD Read/Write -(2)
0x0044 Voltage Regulator Calibration Register VREGCR Read/Write -(2)
0x0048 System RC Oscillator Calibration Register RCCR Read/Write -(2)
0x004C Supply Monitor 33 Calibration Register SM33 Read/Write -(2)
0x0050 Temperature Sensor Calibration Register TSENS Read/Write 0x00000000
0x0058 120MHz RC Oscillator Control Register RC120MCR Read/Write 0x00000000
0x005C-0x0068 Backup Registers BR Read/Write 0x00000000
0x006C 32kHz RC Oscillator Control Register RC32KCR Read/Write 0x00000000
0x0070 Generic Clock Control0 GCCTRL0 Read/Write 0x00000000
0x0074 Generic Clock Control1 GCCTRL1 Read/Write 0x00000000
0x0078 Generic Clock Control2 GCCTRL2 Read/Write 0x00000000
0x007C Generic Clock Control3 GCCTRL3 Read/Write 0x00000000
0x0080 Generic Clock Control4 GCCTRL4 Read/Write 0x00000000
0x0084 Generic Clock Control5 GCCTRL5 Read/Write 0x00000000
0x0088 Generic Clock Control6 GCCTRL6 Read/Write 0x00000000
0x008C Generic Clock Control7 GCCTRL7 Read/Write 0x00000000
0x0090 Generic Clock Control8 GCCTRL8 Read/Write 0x00000000
0x0094 Generic Clock Control9 GCCTRL9 Read/Write 0x00000000
266
32142D–06/2013
ATUC64/128/256L3/4U
Note: 1. The reset value is device specific. Please refer to the Module Configuration section at the end of this chapter.
2. The reset value of this register depends on factory calibration.
0x0098 PLL0 Control Register PLL0 Read/Write 0x00000000
0x009C High Resolution Prescaler Control Register HRPCR Read/Write 0x00000000
0x00A0 Fractional Prescaler Control Register FPCR Read/Write 0x00000000
0x00A4 Fractional Prescaler Multiplier Register FPMUL Read/Write 0x00000000
0x00A8 Fractional Prescaler DIVIDER Register FPDIV Read/Write 0x00000000
0x03BC Commonly used Modules Version Register CMVERSION Read-only -(1)
0x03C0 Generic Clock Prescaler Version Register GCLKPRESCVERSION Read-only -(1)
0x03C4 PLL Version Register PLLVERSION Read-only -(1)
0x03C8 Oscillator0 Version Register OSC0VERSION Read-only -(1)
0x03CC 32 KHz Oscillator Version Register OSC32VERSION Read-only -(1)
0x03D0 DFLL Version Register DFLLIFVERSION Read-only -(1)
0x03D4 BOD Version Register BODIFAVERSION Read-only -(1)
0x03D8 Voltage Regulator Version Register VREGIFBVERSION Read-only -(1)
0x03DC System RC Oscillator Version Register RCOSCIFAVERSION Read-only -(1)
0x03E0 3.3V Supply Monitor Version Register SM33IFAVERSION Read-only -(1)
0x03E4 Temperature Sensor Version Register TSENSIFAVERSION Read-only -(1)
0x03EC 120MHz RC Oscillator Version Register RC120MIFAVERSION Read-only -(1)
0x03F0 Backup Register Interface Version Register BRIFAVERSION Read-only -(1)
0x03F4 32kHz RC Oscillator Version Register RC32KIFAVERSION Read-only -(1)
0x03F8 Generic Clock Version Register GCLKVERSION Read-only -(1)
0x03FC SCIF Version Register VERSION Read-only -(1)
Table 14-2. SCIF Register Memory Map
Offset Register Register Name Access Reset
267
32142D–06/2013
ATUC64/128/256L3/4U
14.6.1 Interrupt Enable Register
Name: IER
Access Type: Write-only
Offset: 0x0000
Reset Value: 0x00000000
Writing a zero to a bit in this register has no effect.
Writing a one to a bit in this register will set the corresponding bit in IMR.
31 30 29 28 27 26 25 24
AE - - - - - - -
23 22 21 20 19 18 17 16
----- PLLLOCKLO
ST0 PLLLOCK0 BRIFARDY
15 14 13 12 11 10 9 8
DFLL0RCS DFLL0RDY DFLL0LOCK
LOSTA
DFLL0LOCK
LOSTF
DFLL0LOCK
LOSTC
DFLL0LOCK
A
DFLL0LOCK
F
DFLL0LOCK
C
76543210
BODDET SM33DET VREGOK - - - OSC0RDY OSC32RDY
268
32142D–06/2013
ATUC64/128/256L3/4U
14.6.2 Interrupt Disable Register
Name: IDR
Access Type: Write-only
Offset: 0x0004
Reset Value: 0x00000000
Writing a zero to a bit in this register has no effect.
Writing a one to a bit in this register will clear the corresponding bit in IMR.
31 30 29 28 27 26 25 24
AE - - - - - - -
23 22 21 20 19 18 17 16
----- PLLLOCKLO
ST0 PLLLOCK0 BRIFARDY
15 14 13 12 11 10 9 8
DFLL0RCS DFLL0RDY DFLL0LOCK
LOSTA
DFLL0LOCK
LOSTF
DFLL0LOCK
LOSTC
DFLL0LOCK
A
DFLL0LOCK
F
DFLL0LOCK
C
76543210
BODDET SM33DET VREGOK - - - OSC0RDY OSC32RDY
269
32142D–06/2013
ATUC64/128/256L3/4U
14.6.3 Interrupt Mask Register
Name: IMR
Access Type: Read-only
Offset: 0x0008
Reset Value: 0x00000000
0: The corresponding interrupt is disabled.
1: The corresponding interrupt is enabled.
A bit in this register is cleared when the corresponding bit in IDR is written to one.
A bit in this register is set when the corresponding bit in IER is written to one.
31 30 29 28 27 26 25 24
AE - - - - - - -
23 22 21 20 19 18 17 16
----- PLLLOCKLO
ST0 PLLLOCK0 BRIFARDY
15 14 13 12 11 10 9 8
DFLL0RCS DFLL0RDY DFLL0LOCK
LOSTA
DFLL0LOCK
LOSTF
DFLL0LOCK
LOSTC
DFLL0LOCK
A
DFLL0LOCK
F
DFLL0LOCK
C
76543210
BODDET SM33DET VREGOK - - - OSC0RDY OSC32RDY
270
32142D–06/2013
ATUC64/128/256L3/4U
14.6.4 Interrupt Status Register
Name: ISR
Access Type: Read-only
Offset: 0x000C
Reset Value: 0x00000000
0: The corresponding interrupt is cleared.
1: The corresponding interrupt is pending.
A bit in this register is cleared when the corresponding bit in ICR is written to one.
A bit in this register is set when the corresponding interrupt occurs.
31 30 29 28 27 26 25 24
AE - - - - - - -
23 22 21 20 19 18 17 16
----- PLLLOCKLO
ST0 PLLLOCK0 BRIFARDY
15 14 13 12 11 10 9 8
DFLL0RCS DFLL0RDY DFLL0LOCK
LOSTA
DFLL0LOCK
LOSTF
DFLL0LOCK
LOSTC
DFLL0LOCK
A
DFLL0LOCK
F
DFLL0LOCK
C
76543210
BODDET SM33DET VREGOK - - - OSC0RDY OSC32RDY
271
32142D–06/2013
ATUC64/128/256L3/4U
14.6.5 Interrupt Clear Register
Name: ICR
Access Type: Write-only
Offset: 0x0010
Reset Value: 0x00000000
Writing a zero to a bit in this register has no effect.
Writing a one to a bit in this register will clear the corresponding bit in ISR.
31 30 29 28 27 26 25 24
AE - - - - - - -
23 22 21 20 19 18 17 16
----- PLLLOCKLO
ST0 PLLLOCK0 BRIFARDY
15 14 13 12 11 10 9 8
DFLL0RCS DFLL0RDY DFLL0LOCK
LOSTA
DFLL0LOCK
LOSTF
DFLL0LOCK
LOSTC
DFLL0LOCK
A
DFLL0LOCK
F
DFLL0LOCK
C
76543210
BODDET SM33DET VREGOK - - - OSC0RDY OSC32RDY
272
32142D–06/2013
ATUC64/128/256L3/4U
14.6.6 Power and Clocks Status Register
Name: PCLKSR
Access Type: Read-only
Offset: 0x0014
Reset Value: 0x00000000
• BRIFAVALID: Backup Register Interface Valid
0: The values in the backup registers are not valid.
1: The values in the backup registers are valid.
• PLLL0LOCKLOST: PLL0 lock lost value
0: PLL0 has not lost it’s lock or has never been enabled.
1: PLL0 has lost it’s lock, either by disabling the PLL0 or due to faulty operation.
• PLL0LOCK: PLL0 Locked on Accurate value
0: PLL0 is unlocked on accurate value.
1: PLL0 is locked on accurate value, and is ready to be selected as clock source with an accurate output clock.
• BRIFARDY: Backup Register Interface Ready
0: The backup register interface is busy updating the backup registers. Writes to BRn will be discarded.
1: The backup register interface is ready to accept new writes to the backup registers.
• DFLL0RCS: DFLL0 Reference Clock Stopped
0: The DFLL reference clock is running, or has never been enabled.
1: The DFLL reference clock has stopped or is too slow.
• DFLL0RDY: DFLL0 Synchronization Ready
0: Read or write to DFLL registers is invalid
1: Read or write to DFLL registers is valid
• DFLL0LOCKLOSTA: DFLL0 Lock Lost on Accurate Value
0: DFLL has not lost its Accurate lock or has never been enabled.
1: DFLL has lost its Accurate lock, either by disabling the DFLL or due to faulty operation.
• DFLL0LOCKLOSTF: DFLL0 Lock Lost on Fine Value
0: DFLL has not lost its Fine lock or has never been enabled.
1: DFLL has lost its Fine lock, either by disabling the DFLL or due to faulty operation.
31 30 29 28 27 26 25 24
- BRIFAVALID - - - - - -
23 22 21 20 19 18 17 16
----- PLLLOCKLO
ST0 PLLLOCK0 BRIFARDY
15 14 13 12 11 10 9 8
DFLL0RCS DFLL0RDY DFLL0LOCK
LOSTA
DFLL0LOCK
LOSTF
DFLL0LOCK
LOSTC
DFLL0LOCK
A
DFLL0LOCK
F
DFLL0LOCK
C
76543210
BODDET SM33DET VREGOK - - - OSC0RDY OSC32RDY
273
32142D–06/2013
ATUC64/128/256L3/4U
• DFLL0LOCKLOSTC: DFLL0 Lock Lost on Coarse Value
0: DFLL has not lost its Coarse lock or has never been enabled.
1: DFLL has lost its Coarse lock, either by disabling the DFLL or due to faulty operation.
• DFLL0LOCKA: DFLL0 Locked on Accurate Value
0: DFLL is unlocked on Accurate value.
1: DFLL is locked on Accurate value, and is ready to be selected as clock source with an accurate output clock.
• DFLL0LOCKF: DFLL0 Locked on Fine Value
0: DFLL is unlocked on Fine value.
1: DFLL is locked on Fine value, and is ready to be selected as clock source with a high accuracy on the output clock.
• DFLL0LOCKC: DFLL0 Locked on Coarse Value
0: DFLL is unlocked on Coarse value.
1: DFLL is locked on Coarse value, and is ready to be selected as clock source with medium accuracy on the output clock.
• BODDET: Brown-Out Detection
0: No BOD Event.
1: BOD has detected that the supply voltage is below the BOD reference value.
• SM33DET: Supply Monitor 3.3V Detector
0: SM33 not enabled or the supply voltage is above the SM33 threshold.
1: SM33 enabled and the supply voltage is below the SM33 threshold.
• VREGOK: Voltage Regulator OK
0: Voltage regulator not enabled or not ready.
1: Voltage regulator has reached its output threshold value after being enabled.
• OSC0RDY: OSC0 Ready
0: Oscillator not enabled or not ready.
1: Oscillator is stable and ready to be used as clock source.
• OSC32RDY: 32 KHz oscillator Ready
0: OSC32K not enabled or not ready.
1: OSC32K is stable and ready to be used as clock source.
274
32142D–06/2013
ATUC64/128/256L3/4U
14.6.7 Unlock Register
Name: UNLOCK
Access Type: Write-only
Offset: 0x0018
Reset Value: 0x00000000
To unlock a write protected register, first write to the UNLOCK register with the address of the register to unlock in the ADDR
field and 0xAA in the KEY field. Then, in the next PB access write to the register specified in the ADDR field.
The LOCK is by default off. To turn on the LOCK, first write 0xAA to the KEY field and UNLOCK address offset to the ADDR field
in the UNLOCK register, followed by writing 0x5A5A5A5A to the UNLOCK register. To turn off the LOCK, first write 0xAA to the
KEY field and UNLOCK address offset to the ADDR field in the UNLOCK register, followed by writing 0xA5AA5A55 to the
UNLOCK register.
• KEY: Unlock Key
Write this bit field to 0xAA to enable unlock.
• ADDR: Unlock Address
Write the address offset of the register to unlock to this field.
31 30 29 28 27 26 25 24
KEY
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
- - - - - - ADDR[9:8]
76543210
ADDR[7:0]
275
32142D–06/2013
ATUC64/128/256L3/4U
14.6.8 Oscillator Control Register
Name: OSCCTRLn
Access Type: Read/Write
Reset Value: 0x00000000
• OSCEN: Oscillator Enable
0: The oscillator is disabled.
1: The oscillator is enabled.
• STARTUP: Oscillator Start-up Time
Select start-up time for the oscillator. Please refer to the “Oscillator Startup Time” table in the SCIF Module Configuration
section for details.
• AGC: Automatic Gain Control
For test purposes.
• GAIN: Gain
Selects the gain for the oscillator. Please refer to the “Oscillator Gain Settings” table in the SCIF Module Configuration section
for details.
• MODE: Oscillator Mode
0: External clock connected on XIN. XOUT can be used as general-purpose I/O (no crystal).
1: Crystal is connected to XIN/XOUT.
Note that this register is protected by a lock. To write to this register the UNLOCK register has to be written first. Please
refer to the UNLOCK register description for details.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
- - - - - - - OSCEN
15 14 13 12 11 10 9 8
- - - - STARTUP[3:0]
76543210
- - - - AGC GAIN[1:0] MODE
276
32142D–06/2013
ATUC64/128/256L3/4U
14.6.9 32KHz Oscillator Control Register
Name: OSCCTRL32
Access Type: Read/Write
Reset Value: 0x00000004
Note: This register is only reset by Power-On Reset
• RESERVED
This bit must always be written to zero.
• STARTUP: Oscillator Start-up Time
Select start-up time for 32 KHz oscillator
31 30 29 28 27 26 25 24
RESERVED -------
23 22 21 20 19 18 17 16
- - - - - STARTUP[2:0]
15 14 13 12 11 10 9 8
- - - - - MODE[2:0]
76543210
- - - - EN1K EN32K PINSEL OSC32EN
Table 14-3. Start-up Time for 32 KHz Oscillator
STARTUP
Number of RCSYS Clock
Cycle
Approximative Equivalent Time
(RCOSC = 115 kHz)
00 0
1 128 1.1 ms
2 8192 72.3 ms
3 16384 143 ms
4 65536 570 ms
5 131072 1.1 s
6 262144 2.3 s
7 524288 4.6 s
277
32142D–06/2013
ATUC64/128/256L3/4U
• MODE: Oscillator Mode
• EN1K: 1 KHz output Enable
0: The 1 KHz output is disabled.
1: The 1 KHz output is enabled.
• EN32K: 32 KHz output Enable
0: The 32 KHz output is disabled.
1: The 32 KHz output is enabled.
• PINSEL: Pins Select
0: Default pins used.
1: Alternate pins: XIN32_2 pin is used instead of XIN32 pin, XOUT32_2 pin is used instead of XOUT32.
• OSC32EN: 32 KHz Oscillator Enable
0: The 32 KHz Oscillator is disabled
1: The 32 KHz Oscillator is enabled
Table 14-4. Operation Mode for 32 KHz Oscillator
MODE Description
0 External clock connected to XIN32, XOUT32 can be used as general-purpose I/O (no crystal)
1 Crystal mode. Crystal is connected to XIN32/XOUT32.
2 Reserved
3 Reserved
4 Crystal and high current mode. Crystal is connected to XIN32/XOUT32.
5 Reserved
6 Reserved
7 Reserved
278
32142D–06/2013
ATUC64/128/256L3/4U
14.6.10 DFLLn Configuration Register
Name: DFLLnCONF
Access Type: Read/Write
Reset Value: 0x00000000
• COARSE: Coarse Calibration Value
Set the value of the coarse calibration register. If in closed loop mode, this field is Read-only.
• FINE: FINE Calibration Value
Set the value of the fine calibration register. If in closed loop mode, this field is Read-only.
• QLEN: Quick Lock Enable
0: Quick Lock is disabled.
1: Quick Lock is enabled.
• CCEN: Chill Cycle Enable
0: Chill Cycle is disabled.
1: Chill Cycle is enabled.
• LLAW: Lose Lock After Wake
0: Locks will not be lost after waking up from sleep modes.
1: Locks will be lost after waking up from sleep modes where the DFLL clock has been stopped.
• DITHER: Enable Dithering
0: The fine LSB input to the VCO is constant.
1: The fine LSB input to the VCO is dithered to achieve sub-LSB approximation to the correct multiplication ratio.
• MODE: Mode Selection
0: The DFLL is in open loop operation.
1: The DFLL is in closed loop operation.
• EN: Enable
0: The DFLL is disabled.
1: The DFLL is enabled.
Note that this register is protected by a lock. To write to this register the UNLOCK register has to be written first. Please
refer to the UNLOCK register description for details.
31 30 29 28 27 26 25 24
COARSE[7:0]
23 22 21 20 19 18 17 16
- - - - - - - FINE[8]
15 14 13 12 11 10 9 8
FINE[7:0]
76543210
- QLEN CCEN - LLAW DITHER MODE EN
279
32142D–06/2013
ATUC64/128/256L3/4U
14.6.11 DFLLn Multiplier Register
Name: DFLLnMUL
Access Type: Read/Write
Reset Value: 0x00000000
• IMUL: Integer Multiply Factor
This field, together with FMUL, determines the ratio between fDFLL and fREFthe DFLL. IMUL is the integer part, while the FMUL is
the fractional part.
In open loop mode, writing to this register has no effect.
• FMUL: Fractional Multiply Factor
This field, together with IMUL, determines the ratio between fDFLL and fREFthe DFLL. IMUL is the integer part, while the FMUL is
the fractional part.
In open loop mode, writing to this register has no effect.
Note that this register is protected by a lock. To write to this register the UNLOCK register has to be written first. Please
refer to the UNLOCK register description for details.
31 30 29 28 27 26 25 24
IMUL[15:8]
23 22 21 20 19 18 17 16
IMUL[7:0]
15 14 13 12 11 10 9 8
FMUL[15:8]
76543210
FMUL[7:0]
280
32142D–06/2013
ATUC64/128/256L3/4U
14.6.12 DFLLn Maximum Step Register
Name: DFLLnSTEP
Access Type: Read/Write
Reset Value: 0x00000000
• FSTEP: Fine Maximum Step
This indicates the maximum step size during fine adjustment in closed-loop mode. When adjusting to a new frequency, the
expected overshoot of that frequency depends on this step size.
• CSTEP: Coarse Maximum Step
This indicates the maximum step size during coarse adjustment in closed-loop mode. When adjusting to a new frequency, the
expected overshoot of that frequency depends on this step size.
Note that this register is protected by a lock. To write to this register the UNLOCK register has to be written first. Please
refer to the UNLOCK register description for details.
31 30 29 28 27 26 25 24
- - - - - - - FSTEP[8]
23 22 21 20 19 18 17 16
FSTEP[7:0]
15 14 13 12 11 10 9 8
--------
76543210
CSTEP[7:0]
281
32142D–06/2013
ATUC64/128/256L3/4U
14.6.13 DFLLn Spread Spectrum Generator Control Register
Name: DFLLnSSG
Access Type: Read/Write
Reset Value: 0x00000000
• STEPSIZE: SSG Step Size
Sets the step size of the spread spectrum.
• AMPLITUDE: SSG Amplitude
Sets the amplitude of the spread spectrum.
• PRBS: Pseudo Random Bit Sequence
0: Each spread spectrum frequency is applied at constant intervals
1: Each spread spectrum frequency is applied at pseudo-random intervals
• EN: Enable
0: SSG is disabled.
1: SSG is enabled.
Note that this register is protected by a lock. To write to this register the UNLOCK register has to be written first. Please
refer to the UNLOCK register description for details.
31 30 29 28 27 26 25 24
- -------
23 22 21 20 19 18 17 16
- - - STEPSIZE[4:0]
15 14 13 12 11 10 9 8
- - - AMPLITUDE[4:0]
76543210
- - - - - - PRBS EN
282
32142D–06/2013
ATUC64/128/256L3/4U
14.6.14 DFLLn Ratio Register
Name: DFLLnRATIO
Access Type: Read-only
Reset Value: 0x00000000
• RATIODIFF: Multiplication Ratio Difference
In closed-loop mode, this field indicates the error in the ratio between the VCO frequency and the target frequency.
• NUMREF: Numerical Reference
The number of reference clock cycles used to measure the VCO frequency equals 2^NUMREF.
31 30 29 28 27 26 25 24
RATIODIFF[15:8]
23 22 21 20 19 18 17 16
RATIODIFF[7:0]
15 14 13 12 11 10 9 8
- -------
76543210
- - - NUMREF[4:0]
283
32142D–06/2013
ATUC64/128/256L3/4U
14.6.15 DFLLn Synchronization Register
Name: DFLLnSYNC
Access Type: Write-only
Reset Value: 0x00000000
• SYNC: Synchronization
To be able to read the current value of DFLLnCONF or DFLLnRATIO in closed-loop mode, this bit should be written to one. The
updated value is available in DFLLnCONF and DFLLnRATIO when PCLKSR.DFLLnRDY is set.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
- - - - - - - SYNC
284
32142D–06/2013
ATUC64/128/256L3/4U
14.6.16 BOD Control Register
Name: BOD
Access Type: Read/Write
Reset Value: -
• SFV: Store Final Value
0: The register is read/write
1: The register is read-only, to protect against further accidental writes.
This bit is cleared after any reset except for a BOD reset, and during flash calibration.
• FCD: Fuse Calibration Done
0: The flash calibration will be redone after any reset.
1: The flash calibration will be redone after any reset except for a BOD reset.
This bit is cleared after any reset, except for a BOD reset.
This bit is set when the CTRL, HYST and LEVEL fields have been updated by the flash fuses after a reset.
• CTRL: BOD Control
• HYST: BOD Hysteresis
0: No hysteresis.
1: Hysteresis on.
• LEVEL: BOD Level
This field sets the triggering threshold of the BOD. See Electrical Characteristics for actual voltage levels.
Note that any change to the LEVEL field of the BOD register should be done with the BOD deactivated to avoid spurious reset
or interrupt.
31 30 29 28 27 26 25 24
SFV - - - - - - -
23 22 21 20 19 18 17 16
- - - - - - - FCD
15 14 13 12 11 10 9 8
- - - - - - CTRL
76543210
- HYST LEVEL
Table 14-5. Operation Mode for BOD
CTRL Description
0 BOD is disabled.
1 BOD is enabled and can reset the device. An interrupt request will be generated, if enabled in the IMR
register.
2 BOD is enabled but cannot reset the device. An interrupt request will be generated, if enabled in the IMR
register.
3 Reserved.
285
32142D–06/2013
ATUC64/128/256L3/4U
Note that this register is protected by a lock. To write to this register the UNLOCK register has to be written first. Please
refer to the UNLOCK register description for details.
286
32142D–06/2013
ATUC64/128/256L3/4U
14.6.17 Voltage Regulator Calibration Register
Name: VREGCR
Access Type: Read/Write
Reset Value: -
• SFV: Store Final Value
0: The register is read/write.
1: The register is read-only, to protect against further accidental writes.
This bit is cleared by a Power-on Reset.
• INTPD: Internal Pull-down
This bit is used for test purposes only.
0: The voltage regulator output is not pulled to ground.
1: The voltage regulator output has a pull-down to ground.
• POR18VALUE: Power-on Reset 1.8V Output Value
0: VDDCORE voltage is below the POR18 power-on threshold level.
1: VDDCORE voltage is above the POR18 power-on threshold level.
This bit is read-only. Writing to this bit has no effect.
• POR33VALUE: Power-on Reset 3.3V Output Value
0: Internal regulator supply voltage is below the POR33 power-on threshold level.
1: Internal regulator supply voltage is above the POR33 power-on threshold level.
This bit is read-only. Writing to this bit has no effect.
• POR18MASK: Power-on Reset 1.8V Output Mask
0: Power-on Reset is not masked.
1: Power-on Reset is masked.
• POR18STATUS: Power-on Reset 1.8V Status
0: Power-on Reset is disabled.
1: Power-on Reset is enabled.
This bit is read-only. Writing to this bit has no effect.
• POR18EN: Power-on Reset 1.8V Enable
Writing a zero to this bit disables the POR18 detector.
Writing a one to this bit enables the POR18 detector.
• POR33MASK: Power-on Reset 3.3V Output Mask
0: Power-on Reset 3.3V is not masked.
31 30 29 28 27 26 25 24
SFV INTPD - - - DBG- POR18VALUE POR33VALUE
23 22 21 20 19 18 17 16
POR18MASK POR18STAT
US POR18EN POR33MASK POR33STAT
US POR33EN DEEPDIS FCD
15 14 13 12 11 10 9 8
- - - - CALIB
76543210
ON VREGOK EN - - SELVDD
287
32142D–06/2013
ATUC64/128/256L3/4U
1: Power-on Reset 3.3V is masked.
• POR33STATUS: Power-on Reset 3.3V Status
0: Power-on Reset is disabled.
1: Power-on Reset is enabled.
This bit is read-only. Writing to this bit has no effect.
• POR33EN: Power-on Reset 3.3V Enable
0: Writing a zero to this bit disables the POR33 detector.
1: Writing a one to this bit enables the POR33 detector.
• DEEPDIS: Disable Regulator Deep Mode
0: Regulator will enter deep mode in low-power sleep modes for lower power consumption.
1: Regulator will stay in full-power mode in all sleep modes for shorter start-up time.
• FCD: Flash Calibration Done
0: The flash calibration will be redone after any reset.
1: The flash calibration will only be redone after a Power-on Reset.
This bit is cleared after a Power-on Reset.
This bit is set when the CALIB field has been updated by flash calibration after a reset.
• CALIB: Calibration Value
Calibration value for Voltage Regulator. This is calibrated during production and should not be changed.
• ON: Voltage Regulator On Status
0: The voltage regulator is currently disabled.
1: The voltage regulator is currently enabled.
This bit is read-only. Writing to this bit has no effect.
• VREGOK: Voltage Regulator OK Status
0: The voltage regulator is disabled or has not yet reached a stable output voltage.
1: The voltage regulator has reached the output voltage threshold level after being enabled.
This bit is read-only. Writing to this bit has no effect.
• EN: Enable
0: The voltage regulator is disabled.
1: The voltage regulator is enabled.
Note: This bit is set after a Power-on Reset (POR).
• SELVDD: Select VDD
Output voltage of the Voltage Regulator. The default value of this bit corresponds to an output voltage of 1.8V.
Note that this register is protected by a lock. To write to this register the UNLOCK register has to be written first. Please
refer to the UNLOCK register description for details.
288
32142D–06/2013
ATUC64/128/256L3/4U
14.6.18 System RC Oscillator Calibration Register
Name: RCCR
Access Type: Read/Write
Reset Value: -
• FCD: Flash Calibration Done
0: The flash calibration will be redone after any reset.
1: The flash calibration will only be redone after a Power-on Reset.
This bit is cleared after a POR.
This bit is set when the CALIB field has been updated by the flash fuses after a reset.
• CALIB: Calibration Value
Calibration Value for the System RC oscillator (RCSYS).
Note that this register is protected by a lock. To write to this register the UNLOCK register has to be written first. Please
refer to the UNLOCK register description for details.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
- - - - - - - FCD
15 14 13 12 11 10 9 8
- - - - - - CALIB[9:8]
76543210
CALIB[7:0]
289
32142D–06/2013
ATUC64/128/256L3/4U
14.6.19 Supply Monitor 33 Calibration Register
Name: SM33
Access Type: Read/Write
Reset Value: -
• SAMPFREQ: Sampling Frequency
Selects the sampling mode frequency of the 3.3V supply monitor. In sampling mode, the SM33 performs a measurement every
2(SAMPFREQ+5) cycles of the internal 32kHz RC oscillator.
• ONSM: Supply Monitor On Indicator
0: The supply monitor is disabled.
1: The supply monitor is enabled.
This bit is read-only. Writing to this bit has no effect.
• SFV: Store Final Value
0: The register is read/write
1: The register is read-only, to protect against further accidental writes.
This bit is cleared after a reset.
• FCD: Flash Calibration Done
This bit is cleared after a reset.
This bit is set when CALIB field has been updated after a reset.
• CALIB: Calibration Value
Calibration Value for the SM33.
• FS: Force Sampling Mode
0: Sampling mode is enabled in DeepStop and Static mode only.
1: Sampling mode is always enabled.
• CTRL: Supply Monitor Control
31 30 29 28 27 26 25 24
- - - - SAMPFREQ
23 22 21 20 19 18 17 16
- - - - - ONSM SFV FCD
15 14 13 12 11 10 9 8
- - - - CALIB
76543210
FS - - - CTRL
290
32142D–06/2013
ATUC64/128/256L3/4U
Selects the operating mode for the SM33.
Note that this register is protected by a lock. To write to this register the UNLOCK register has to be written first. Please
refer to the UNLOCK register description for details.
Table 14-6. Operation Mode for SM33
CTRL Description
0 SM33 is disabled.
1 SM33 is enabled and can reset the device. An interrupt request will be generated if the corresponding
interrupt is enabled in the IMR register.
2 SM33 is enabled and cannot reset the device. An interrupt request will be generated if the corresponding
interrupt is enabled in the IMR register.
3 SM33 is disabled
4-7 Reserved
291
32142D–06/2013
ATUC64/128/256L3/4U
14.6.20 Temperature Sensor Configuration Register
Name: TSENS
Access Type: Read/Write
Reset Value: 0x00000000
• EN: Temperature Sensor Enable
0: The Temperature Sensor is disabled.
1: The Temperature Sensor is enabled.
Note that this register is protected by a lock. To write to this register the UNLOCK register has to be written first. Please
refer to the UNLOCK register description for details.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
- - - - - EN
292
32142D–06/2013
ATUC64/128/256L3/4U
14.6.21 120MHz RC Oscillator Configuration Register
Name: RC120MCR
Access Type: Read/Write
Reset Value: 0x00000000
• EN: RC120M Enable
0: The 120 MHz RC oscillator is disabled.
1: The 120 MHz RC oscillator is enabled.
Note that this register is protected by a lock. To write to this register the UNLOCK register has to be written first. Please
refer to the UNLOCK register description for details.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
- - - - - - - EN
293
32142D–06/2013
ATUC64/128/256L3/4U
14.6.22 Backup Register n
Name: BRn
Access Type: Read/Write
Reset Value: 0x00000000
This is a set of general-purpose read/write registers. Data stored in these registers is retained when the device is in Shutdown.
Before writing to these registers the user must ensure that PCLKSR.BRIFARDY is not set.
Note that this registers are protected by a lock. To write to these registers the UNLOCK register has to be written first.
Please refer to the UNLOCK register description for details.
31 30 29 28 27 26 25 24
DATA[31:24]
23 22 21 20 19 18 17 16
DATA[23:16]
15 14 13 12 11 10 9 8
DATA[15:8]
76543210
DATA[7:0]
294
32142D–06/2013
ATUC64/128/256L3/4U
14.6.23 32kHz RC Oscillator Configuration Register
Name: RC32KCR
Access Type: Read/Write
Reset Value: 0x00000000
• EN: RC32K Enable
0: The 32 kHz RC oscillator is disabled.
1: The 32 kHz RC oscillator is enabled.
Note that this register is protected by a lock. To write to this register the UNLOCK register has to be written first. Please
refer to the UNLOCK register description for details.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
- - - - - - - EN
295
32142D–06/2013
ATUC64/128/256L3/4U
14.6.24 Generic Clock Control
Name: GCCTRL
Access Type: Read/Write
Reset Value: 0x00000000
There is one GCCTRL register per generic clock in the design.
• DIV: Division Factor
The number of DIV bits for each generic clock is as shown in the “Generic Clock number of DIV bits” table in the SCIF Module
Configuration section.
• OSCSEL: Oscillator Select
Selects the source clock for the generic clock. Please refer to the “Generic Clock Sources” table in the SCIF Module
Configuration section.
• DIVEN: Divide Enable
0: The generic clock equals the undivided source clock.
1: The generic clock equals the source clock divided by 2*(DIV+1).
• CEN: Clock Enable
0: The generic clock is disabled.
1: The generic clock is enabled.
31 30 29 28 27 26 25 24
DIV[15:8]
23 22 21 20 19 18 17 16
DIV[7:0]
15 14 13 12 11 10 9 8
- - - OSCSEL[4:0]
76543210
- - - - - - DIVEN CEN
296
32142D–06/2013
ATUC64/128/256L3/4U
14.6.25 PLL Control Register
Name: PLLn
Access Type: Read/Write
Reset Value: 0x00000000
• PLLCOUNT: PLL Count
Specifies the number of RCSYS clock cycles before ISR.PLLLOCKn will be set after PLLn has been written, or after PLLn has
been automatically re-enabled after exiting a sleep mode.
• PLLMUL: PLL Multiply Factor
• PLLDIV: PLL Division Factor
These fields determine the ratio of the PLL output frequency to the source oscillator frequency:
fvco = (PLLMUL+1)/PLLDIV • fREF if PLLDIV >0
fvco = 2•(PLLMUL+1) • fREF if PLLDIV = 0
Note that the PLLMUL field should always be greater than 1 or the behavior of the PLL will be undefined.
• PLLOPT: PLL Option
PLLOPT[0]: Selects the VCO frequency range (fvco).
0: 80MHz1
1
1
0
0
BaudRate SelectedClock
8 2 – OVER CD = -----------------------------------------------
438
32142D–06/2013
ATUC64/128/256L3/4U
The baud rate is calculated with the following formula (OVER=0):
The baud rate error is calculated with the following formula. It is not recommended to work with
an error higher than 5%.
20.6.1.3 Fractional Baud Rate in Asynchronous Mode
The baud rate generator has a limitation: the source frequency is always a multiple of the baud
rate. An approach to this problem is to integrate a high resolution fractional N clock generator,
outputting fractional multiples of the reference source clock. This fractional part is selected with
the Fractional Part field (BRGR.FP), and is activated by giving it a non-zero value. The resolution
is one eighth of CD. The resulting baud rate is calculated using the following formula:
The modified architecture is presented below:
Table 20-3. Baud Rate Example (OVER=0)
Source Clock (Hz)
Expected Baud
Rate (bit/s) Calculation Result CD Actual Baud Rate (bit/s) Error
3 686 400 38 400 6.00 6 38 400.00 0.00%
4 915 200 38 400 8.00 8 38 400.00 0.00%
5 000 000 38 400 8.14 8 39 062.50 1.70%
7 372 800 38 400 12.00 12 38 400.00 0.00%
8 000 000 38 400 13.02 13 38 461.54 0.16%
12 000 000 38 400 19.53 20 37 500.00 2.40%
12 288 000 38 400 20.00 20 38 400.00 0.00%
14 318 180 38 400 23.30 23 38 908.10 1.31%
14 745 600 38 400 24.00 24 38 400.00 0.00%
18 432 000 38 400 30.00 30 38 400.00 0.00%
24 000 000 38 400 39.06 39 38 461.54 0.16%
24 576 000 38 400 40.00 40 38 400.00 0.00%
25 000 000 38 400 40.69 40 38 109.76 0.76%
32 000 000 38 400 52.08 52 38 461.54 0.16%
32 768 000 38 400 53.33 53 38 641.51 0.63%
33 000 000 38 400 53.71 54 38 194.44 0.54%
40 000 000 38 400 65.10 65 38 461.54 0.16%
50 000 000 38 400 81.38 81 38 580.25 0.47%
60 000 000 38 400 97.66 98 38 265.31 0.35%
BaudRate CLKUSART = CD 16
Error 1 ExpectedBaudRate
ActualBaudRate
-------------------------------------------------- = –
BaudRate SelectedClock
8 2 – OVER CD FP
8
+ -------
= --------------------------------------------------------------------
439
32142D–06/2013
ATUC64/128/256L3/4U
Figure 20-3. Fractional Baud Rate Generator
20.6.1.4 Baud Rate in Synchronous and SPI Mode
If the USART is configured to operate in synchronous mode, the selected clock is divided by the
BRGR.CD field. This does not apply when CLK is selected.
When CLK is selected the external frequency must be at least 4.5 times lower than the system
clock, and when either CLK or CLK_USART/DIV are selected, CD must be even to ensure a
50/50 duty cycle. If CLK_USART is selected, the generator ensures this regardless of value.
20.6.2 Receiver and Transmitter Control
After a reset, the transceiver is disabled. The receiver/transmitter is enabled by writing a one to
either the Receiver Enable, or Transmitter Enable bit in the Control Register (CR.RXEN, or
CR.TXEN). They may be enabled together and can be configured both before and after they
have been enabled. The user can reset the USART receiver/transmitter at any time by writing a
one to either the Reset Receiver (CR.RSTRX), or Reset Transmitter (CR.RSTTX) bit. This software
reset clears status bits and resets internal state machines, immediately halting any
communication. The user interface configuration registers will retain their values.
The user can disable the receiver/transmitter by writing a one to either the Receiver Disable, or
Transmitter Disable bit (CR.RXDIS, or CR.TXDIS). If the receiver is disabled during a character
reception, the USART will wait for the current character to be received before disabling. If the
transmitter is disabled during transmission, the USART will wait until both the current character
and the character stored in the Transmitter Holding Register (THR) are transmitted before disabling.
If a timeguard has been implemented it will remain functional during the transaction.
USCLKS CD Modulus
Control
FP
FP
CD
glitch-free
logic
16-bit Counter
OVER
FIDI
SYNC
Sampling
Divider
CLK_USART
CLK_USART/DIV
Reserved CLK
CLK
BaudRate
Clock
Sampling
Clock
SYNC
USCLKS = 3
>1
1
2
3
0
0
1
0
1
1
0
0
BaudRate SelectedClock
CD = -------------------------------------
440
32142D–06/2013
ATUC64/128/256L3/4U
20.6.3 Synchronous and Asynchronous Modes
20.6.3.1 Transmitter Operations
The transmitter performs equally in both synchronous and asynchronous operating modes
(MR.SYNC). One start bit, up to 9 data bits, an optional parity bit, and up to two stop bits are
successively shifted out on the TXD pin at each falling edge of the serial clock. The number of
data bits is selected by the Character Length field (MR.CHRL) and the MR.MODE9 bit. Nine bits
are selected by writing a one to MODE9, overriding any value in CHRL. The parity bit configuration
is selected in the MR.PAR field. The Most Significant Bit First bit (MR.MSBF) selects which
data bit to send first. The number of stop bits is selected by the MR.NBSTOP field. The 1.5 stop
bit configuration is only supported in asynchronous mode.
Figure 20-4. Character Transmit
The characters are sent by writing to the Character to be Transmitted field (THR.TXCHR). The
transmitter reports status with the Transmitter Ready (TXRDY) and Transmitter Empty
(TXEMPTY) bits in the Channel Status Register (CSR). TXRDY is set when THR is empty.
TXEMPTY is set when both THR and the transmit shift register are empty (transmission complete).
Both TXRDY and TXEMPTY are cleared when the transmitter is disabled. Writing a
character to THR while TXRDY is zero has no effect and the written character will be lost.
Figure 20-5. Transmitter Status
20.6.3.2 Asynchronous Receiver
If the USART is configured in an asynchronous operating mode (MR.SYNC = 0), the receiver will
oversample the RXD input line by either 8 or 16 times the baud rate clock, as selected by the
Oversampling Mode bit (MR.OVER). If the line is zero for half a bit period (four or eight consecutive
samples, respectively), a start bit will be assumed, and the following 8th or 16th sample will
determine the logical value on the line, in effect resulting in bit values being determined at the
middle of the bit period.
D0 D1 D2 D3 D4 D5 D6 D7
TXD
Start
Bit
Parity
Bit
Stop
Bit
Example: 8-bit, Parity Enabled One Stop
Baud Rate
Clock
D0 D1 D2 D3 D4 D5 D6 D7
TXD
Start
Bit
Parity
Bit
Stop
Bit
Baud Rate
Clock
Start
Bit
Write
THR
D0 D1 D2 D3 D4 D5 D6 D7 Parity
Bit
Stop
Bit
TXRDY
TXEMPTY
441
32142D–06/2013
ATUC64/128/256L3/4U
The number of data bits, endianess, parity mode, and stop bits are selected by the same bits
and fields as for the transmitter (MR.CHRL, MODE9, MSBF, PAR, and NBSTOP). The synchronization
mechanism will only consider one stop bit, regardless of the used protocol, and when
the first stop bit has been sampled, the receiver will automatically begin looking for a new start
bit, enabling resynchronization even if there is a protocol miss-match. Figure 20-6 and Figure
20-7 illustrate start bit detection and character reception in asynchronous mode.
Figure 20-6. Asynchronous Start Bit Detection
Figure 20-7. Asynchronous Character Reception
20.6.3.3 Synchronous Receiver
In synchronous mode (SYNC=1), the receiver samples the RXD signal on each rising edge of
the Baud Rate Clock. If a low level is detected, it is considered as a start bit. Configuration bits
and fields are the same as in asynchronous mode.
Sampling
Clock (x16)
RXD
Start
Detection
Sampling
Baud Rate
Clock
RXD
Start
Rejection
Sampling
12345678
12345670 1234
12345678 9 10 11 12 13 14 15 16 D0
Sampling
D0 D1 D2 D3 D4 D5 D6 D7
RXD
Parity
Bit
Stop
Bit
Example: 8-bit, Parity Enabled
Baud Rate
Clock
Start
Detection
16
samples
16
samples
16
samples
16
samples
16
samples
16
samples
16
samples
16
samples
16
samples
16
samples
442
32142D–06/2013
ATUC64/128/256L3/4U
Figure 20-8. Synchronous Mode Character Reception
20.6.3.4 Receiver Operations
When a character reception is completed, it is transferred to the Received Character field in the
Receive Holding Register (RHR.RXCHR), and the Receiver Ready bit in the Channel Status
Register (CSR.RXRDY) is set. If RXRDY is already set, RHR will be overwritten and the Overrun
Error bit (CSR.OVRE) is set. Reading RHR will clear RXRDY, and writing a one to the Reset
Status bit in the Control Register (CR.RSTSTA) will clear OVRE.
Figure 20-9. Receiver Status
20.6.3.5 Parity
The USART supports five parity modes selected by MR.PAR. The PAR field also enables the
Multidrop mode, see ”Multidrop Mode” on page 443. If even parity is selected, the parity bit will
be a zero if there is an even number of ones in the data character, and if there is an odd number
it will be a one. For odd parity the reverse applies. If space or mark parity is chosen, the parity bit
will always be a zero or one, respectively. See Table 20-4.
D0 D1 D2 D3 D4 D5 D6 D7
RXD
Start Sampling
Parity Bit
Stop Bit
Example: 8-bit, Parity Enabled 1 Stop
Baud Rate
Clock
D0 D1 D2 D3 D4 D5 D6 D7
RXD
Start
Bit
Parity
Bit
Stop
Bit
Baud Rate
Clock
Write
CR
RXRDY
OVRE
D0 D1 D2 D3 D4 D5 D6 D7 Start
Bit
Parity
Bit
Stop
Bit
RSTSTA = 1
Read
RHR
Table 20-4. Parity Bit Examples
Alphanum
Character Hex Bin
Parity Mode
Odd Even Mark Space None
A 0x41 0100 0001 1 0 1 0 -
V 0x56 0101 0110 1 0 1 0 -
R 0x52 0101 0010 0 1 1 0 -
443
32142D–06/2013
ATUC64/128/256L3/4U
The receiver will report parity errors in CSR.PARE, unless parity is disabled. Writing a one to
CR.RSTSTA will clear PARE. See Figure 20-10
Figure 20-10. Parity Error
20.6.3.6 Multidrop Mode
If PAR is either 0x6 or 0x7, the USART runs in Multidrop mode. This mode differentiates data
and address characters. Data has the parity bit zero and addresses have a one. By writing a one
to the Send Address bit (CR.SENDA) the user will cause the next character written to THR to be
transmitted as an address. Receiving a character with a one as parity bit will set PARE.
20.6.3.7 Transmitter Timeguard
The timeguard feature enables the USART to interface slow devices by inserting an idle state on
the TXD line in between two characters. This idle state corresponds to a long stop bit, whose
duration is selected by the Timeguard Value field in the Transmitter Timeguard Register
(TTGR.TG). The transmitter will hold the TXD line high for TG bit periods, in addition to the number
of stop bits. As illustrated in Figure 20-11, the behavior of TXRDY and TXEMPTY is modified
when TG has a non-zero value. If a pending character has been written to THR, the TXRDY bit
will not be set until this characters start bit has been sent. TXEMPTY will remain low until the
timeguard transmission has completed.
Figure 20-11. Timeguard Operation
D0 D1 D2 D3 D4 D5 D6 D7
RXD
Start
Bit
Bad
Parity
Bit
Stop
Bit
Baud Rate
Clock
Write
CR
PARE
RXRDY
RSTSTA = 1
D0 D1 D2 D3 D4 D5 D6 D7
TXD
Start
Bit
Parity
Bit
Stop
Bit
Baud Rate
Clock
Start
Bit
TG = 4
Write
THR
D0 D1 D2 D3 D4 D5 D6 D7 Parity
Bit
Stop
Bit
TXRDY
TXEMPTY
TG = 4
444
32142D–06/2013
ATUC64/128/256L3/4U
Table 20-5. Maximum Baud Rate Dependent Timeguard Durations
20.6.3.8 Receiver Time-out
The Time-out Value field in the Receiver Time-out Register (RTOR.TO) enables handling of variable-length
frames by detection of selectable idle durations on the RXD line. The value written to
TO is loaded to a decremental counter, and unless it is zero, a time-out will occur when the
amount of inactive bit periods match the initial counter value. If a time-out has not occurred, the
counter will reload and restart every time a new character arrives. A time-out sets the TIMEOUT
bit in CSR. Clearing TIMEOUT can be done in two ways:
• Writing a one to the Start Time-out bit (CR.STTTO). This also aborts count down until the
next character has been received.
• Writing a one to the Reload and Start Time-out bit (CR.RETTO). This also reloads the
counter and restarts count down immediately.
Figure 20-12. Receiver Time-out Block Diagram
Table 20-6. Maximum Time-out Period
Baud Rate (bit/sec) Bit time (µs) Timeguard (ms)
1 200 833 212.50
9 600 104 26.56
14400 69.4 17.71
19200 52.1 13.28
28800 34.7 8.85
33400 29.9 7.63
56000 17.9 4.55
57600 17.4 4.43
115200 8.7 2.21
Baud Rate (bit/sec) Bit Time (µs) Time-out (ms)
600 1 667 109 225
1 200 833 54 613
2 400 417 27 306
4 800 208 13 653
16-bit Time-out
Counter
0
TO
TIMEOUT
Baud Rate
Clock
=
Character
Received
RETTO
Load
Clock
16-bit
Value
STTTO
1 D Q
Clear
445
32142D–06/2013
ATUC64/128/256L3/4U
20.6.3.9 Framing Error
The receiver is capable of detecting framing errors. A framing error has occurred if a stop bit
reads as zero. This can occur if the transmitter and receiver are not synchronized. A framing
error is reported by CSR.FRAME as soon as the error is detected, at the middle of the stop bit.
Figure 20-13. Framing Error Status
20.6.3.10 Transmit Break
When TXRDY is set, the user can request the transmitter to generate a break condition on the
TXD line by writing a one to The Start Break bit (CR.STTBRK). The break is treated as a normal
0x00 character transmission, clearing TXRDY and TXEMPTY, but with zeroes for preambles,
start, parity, stop, and time guard bits. Writing a one to the Stop Break bit (CR.STBRK) will stop
the generation of new break characters, and send ones for TG duration or at least 12 bit periods,
ensuring that the receiver detects end of break, before resuming normal operation. Figure 20-14
illustrates STTBRK and STPBRK effect on the TXD line.
Writing to STTBRK and STPBRK simultaneously can lead to unpredictable results. Writes to
THR before a pending break has started will be ignored.
9 600 104 6 827
14400 69 4 551
19200 52 3 413
28800 35 2 276
33400 30 1 962
56000 18 1 170
57600 17 1 138
200000 5 328
Baud Rate (bit/sec) Bit Time (µs) Time-out (ms)
D0 D1 D2 D3 D4 D5 D6 D7
RXD
Start
Bit
Parity
Bit
Stop
Bit
Baud Rate
Clock
Write
CR
FRAME
RXRDY
RSTSTA = 1
446
32142D–06/2013
ATUC64/128/256L3/4U
Figure 20-14. Break Transmission
20.6.3.11 Receive Break
A break condition is assumed when incoming data, parity, and stop bits are zero. This corresponds
to a framing error, but FRAME will remain zero while the Break Received/End Of Break
bit (CSR.RXBRK) is set. Writing a one to CR.RSTSTA will clear RXBRK. An end of break will
also set RXBRK, and is assumed when TX is high for at least 2/16 of a bit period in asynchronous
mode, or when a high level is sampled in synchronous mode.
20.6.3.12 Hardware Handshaking
The USART features an out-of-band hardware handshaking flow control mechanism, implementable
by connecting the RTS and CTS pins with the remote device, as shown in Figure 20-
15.
Figure 20-15. Connection with a Remote Device for Hardware Handshaking
Writing 0x2 to the MR.MODE field configures the USART to operate in this mode. The receiver
will drive its RTS pin high when disabled or when the Reception Buffer Full bit (CSR.RXBUFF) is
set by the Buffer Full signal from the Peripheral DMA controller. If the receivers RTS pin is high,
the transmitters CTS pin will also be high and only the active character transactions will be completed.
Allocating a new buffer to the DMA controller by clearing RXBUFF, will drive the RTS pin
low, allowing the transmitter to resume transmission. Detected level changes on the CTS pin
can trigger interrupts, and are reported by the CTS Input Change bit in the Channel Status Register
(CSR.CTSIC).
Figure 20-16 illustrates receiver functionality, and Figure 20-17 illustrates transmitter
functionality.
D0 D1 D2 D3 D4 D5 D6 D7
TXD
Start
Bit
Parity
Bit
Stop
Bit
Baud Rate
Clock
Write
CR
TXRDY
TXEMPTY
STTBRK = 1 STPBRK = 1
Break Transmission End of Break
USART
TXD
CTS
Remote
Device
RXD
RXD TXD
RTS
RTS
CTS
447
32142D–06/2013
ATUC64/128/256L3/4U
Figure 20-16. Receiver Behavior when Operating with Hardware Handshaking
Figure 20-17. Transmitter Behavior when Operating with Hardware Handshaking
Figure 20-18.
20.6.4 SPI Mode
The USART features a Serial Peripheral Interface (SPI) link compliant mode, supporting synchronous,
full-duplex communication, in both master and slave mode. Writing 0xE (master) or
0xF (slave) to MR.MODE will enable this mode. A SPI in master mode controls the data flow to
and from the other SPI devices, who are in slave mode. It is possible to let devices take turns
being masters (aka multi-master protocol), and one master may shift data simultaneously into
several slaves, but only one slave may respond at a time. A slave is selected when its slave
select (NSS) signal has been raised by the master. The USART can only generate one NSS signal,
and it is possible to use standard I/O lines to address more than one slave.
20.6.4.1 Modes of Operation
The SPI system consists of two data lines and two control lines:
• Master Out Slave In (MOSI): This line supplies the data shifted from master to slave. In
master mode this is connected to TXD, and in slave mode to RXD.
• Master In Slave Out (MISO): This line supplies the data shifted from slave to master. In
master mode this is connected to RXD, and in slave mode to TXD.
• Serial Clock (CLK): This is controlled by the master. One period per bit transmission. In both
modes this is connected to CLK.
• Slave Select (NSS): This control line allows the master to select or deselect a slave. In
master mode this is connected to RTS, and in slave mode to CTS.
Changing SPI mode after initial configuration has to be followed by a transceiver software reset
in order to avoid unpredictable behavior.
20.6.4.2 Baud Rate
The baud rate generator operates as described in ”Baud Rate in Synchronous and SPI Mode”
on page 439, with the following requirements:
In SPI Master Mode:
RTS
RXBUFF
Write
CR
RXEN = 1
RXD
RXDIS = 1
CTS
TXD
448
32142D–06/2013
ATUC64/128/256L3/4U
• The Clock Selection field (MR.USCLKS) must not equal 0x3 (external clock, CLK).
• The Clock Output Select bit (MR.CLKO) must be one.
• The BRGR.CD field must be at least 0x4.
• If USCLKS is one (internal divided clock, CLK_USART/DIV), the value in CD has to be even,
ensuring a 50:50 duty cycle. CD can be odd if USCLKS is zero (internal clock, CLK_USART).
In SPI Slave Mode:
• CLK frequency must be at least four times lower than the system clock.
20.6.4.3 Data Transfer
• Up to nine data bits are successively shifted out on the TXD pin at each edge. There are no
start, parity, or stop bits, and MSB is always sent first. The SPI Clock Polarity (MR.CPOL),
and SPI Clock Phase (MR.CPHA) bits configure CLK by selecting the edges upon which bits
are shifted and sampled, resulting in four non-interoperable protocol modes see Table 20-7.
A master/slave pair must use the same configuration, and the master must be reconfigured if
it is to communicate with slaves using different configurations. See Figures 20-19 and 20-20.
Figure 20-19. SPI Transfer Format (CPHA=1, 8 bits per transfer)
Table 20-7. SPI Bus Protocol Modes
SPI Bus Protocol Mode CPOL CPHA
0 01
1 00
2 11
3 10
CLK cycle (for reference)
CLK
(CPOL= 1)
MOSI
SPI Master ->TXD
SPI Slave ->RXD
MISO
SPI Master ->RXD
SPI Slave ->TXD
NSS
SPI Master ->RTS
SPI Slave ->CTS
MSB
MSB
1
CLK
(CPOL= 0)
3 5 6 7 8
4 3 2 1 LSB
6
6 5
5 4 3 2 1 LSB
2 4
449
32142D–06/2013
ATUC64/128/256L3/4U
Figure 20-20. SPI Transfer Format (CPHA=0, 8 bits per transfer)
20.6.4.4 Receiver and Transmitter Control
See ”Transmitter Operations” on page 440, and ”Receiver Operations” on page 442.
20.6.4.5 Character Transmission and Reception
In SPI master mode, the slave select line (NSS) is asserted low one bit period before the start of
transmission, and released high one bit period after every character transmission. A delay for at
least three bit periods is always inserted in between characters. In order to address slave
devices supporting the Chip Select Active After Transfer (CSAAT) mode, NSS can be forced low
by writing a one to the Force SPI Chip Select bit (CR.RTSEN/FCS). Releasing NSS when FCS
is one, is only possible by writing a one to the Release SPI Chip Select bit (CR.RTSDIS/RCS).
In SPI slave mode, a low level on NSS for at least one bit period will allow the slave to initiate a
transmission or reception. The Underrun Error bit (CSR.UNRE) is set if a character must be sent
while THR is empty, and TXD will be high during character transmission, as if 0xFF was being
sent. If a new character is written to THR it will be sent correctly during the next transmission
slot. Writing a one to CR.RSTSTA will clear UNRE. To ensure correct behavior of the receiver in
SPI slave mode, the master device sending the frame must ensure a minimum delay of one bit
period in between each character transmission.
20.6.4.6 Receiver Time-out
Receiver Time-out’s are not possible in SPI mode as the baud rate clock is only active during
data transfers.
20.6.5 LIN Mode
The USART features a LIN (Local Interconnect Network) 1.3 and 2.0 compliant mode, embedding
full error checking and reporting, automatic frame processing with up to 256 data bytes,
CLK cycle (for reference)
CLK
(CPOL= 0)
CLK
(CPOL= 1)
MOSI
SPI Master -> TXD
SPI Slave -> RXD
MISO
SPI Master -> RXD
SPI Slave -> TXD
NSS
SPI Master -> RTS
SPI Slave -> CTS
MSB 6 5
MSB 6 5
4
4 3
3 2
2 1
1 LSB
LSB
1 2 3 4 5 6 7 8
450
32142D–06/2013
ATUC64/128/256L3/4U
customizable response data lengths, and requires minimal CPU resources. Writing 0xA (master)
or 0xB (slave) to MR.MODE enables this mode.
20.6.5.1 Modes of operation
Changing LIN mode after initial configuration has to be followed by a transceiver software reset
in order to avoid unpredictable behavior.
20.6.5.2 Receiver and Transmitter Control
See Section “20.6.2” on page 439.
20.6.5.3 Baud Rate Configuration
The LIN nodes baud rate is configured in the Baud Rate Generator Register (BRGR), See Section
“20.6.1.1” on page 437.
20.6.5.4 Character Transmission and Reception
See ”Transmitter Operations” on page 440, and ”Receiver Operations” on page 442.
20.6.5.5 Header Transmission (Master Node Configuration)
All LIN frames start with a header sent by the master. As soon as the identifier has been written
to the Identifier Character field in the LIN Identifier Register (LINIR.IDCHR), TXRDY is cleared
and the header is sent. The header consists of a Break, Sync, and Identifier field. TXRDY is set
when the identifier has been transferred into the transmitters shift register.
The Break field consists of 13 dominant bits, the break, and one recessive bit, the break delimiter.
The Sync field is the character 0x55. The Identifier field contains the Identifier as written to
IDCHR. The identifier parity bits can be generated automatically (see Section 20.6.5.8).
Figure 20-21. Header Transmission
20.6.5.6 Header Reception (Slave Node Configuration)
The USART stays idle until it detects a break field, consisting of at least 11 consecutive dominant
bits (zeroes) on the bus. A received break will set the Lin Break bit (CSR.LINBK). The Sync
field is used to synchronize the baud rate (see Section 20.6.5.7). IDCHR is updated and the LIN
Identifier bit (CSR.LINID) is set when the Identifier has been received. The Identifier parity bits
can be automatically checked (see Section 20.6.5.8). Writing a one to RSTSTA will clear LINBK
and LINID.
TXD
Baud Rate
Clock
Start
Bit
Write
LINIR
10101010
TXRDY
Stop
Bit
Start
Bit Break Field ID0 ID1 ID2 ID3 ID4 ID5 ID6 ID7
13 dominant bits (at 0)
Stop
Bit
Break
Delimiter
1 recessive bit
(at 1)
Synch Byte = 0x55
LINIR ID
451
32142D–06/2013
ATUC64/128/256L3/4U
Figure 20-22. Header Reception
20.6.5.7 Slave Node Synchronization
Synchronization is only done by the slave. If the Sync field is not 0x55, an Inconsistent Sync
Field error (CSR.LINISFE) is generated. The time between falling edges is measured by a 19-bit
counter, driven by the sampling clock (see Section 20.6.1).
Figure 20-23. Sync Field
The counter starts when the Sync field start bit is detected, and continues for eight bit periods.
The 16 most significant bits (counter value divided by 8) becomes the new clock divider
(BRGR.CD), and the three least significant bits (the remainder) becomes the new fractional part
(BRGR.FP).
Figure 20-24. Slave Node Synchronization
The synchronization accuracy depends on:
• The theoretical slave node clock frequency; nominal clock frequency (FNom)
• The baud rate
Break Field
13 dominant bits (at 0)
Break
Delimiter
1 recessive bit
(at 1)
Start
Bit 10101010 Stop
Bit
Start
Bit ID0 ID1 ID2 ID4 ID3 ID6 ID5 ID7 Stop
Bit
Synch Byte = 0x55
Baud Rate
Clock
RXD
Write US_CR
With RSTSTA=1
US_LINIR
LINID
Start
bit
Stop
bit
Synch Field
8 Tbit
2 Tbit 2 Tbit 2 Tbit 2 Tbit
RXD
Baud Rate
Clock
LINIDRX
Synchro Counter 000_0011_0001_0110_1101
BRGR
Clcok Divider (CD)
0000_0110_0010_1101
BRGR
Fractional Part (FP)
101
Initial CD
Initial FP
Reset
Start
Bit 10101010 Stop
Bit
Start
Bit Break Field ID0 ID1 ID2 ID3 ID4 ID5 ID6 ID7
13 dominant bits (at 0)
Stop
Bit
Break
Delimiter
1 recessive bit
(at 1)
Synch Byte = 0x55
452
32142D–06/2013
ATUC64/128/256L3/4U
• The oversampling mode (OVER=0 => 16x, or OVER=1 => 8x)
The following formula is used to calculate synchronization deviation, where FSLAVE is the real
slave node clock frequency, and FTOL_UNSYNC is the difference between FNom and FSLAVE According
to the LIN specification, FTOL_UNSYNCH may not exceed ±15%, and the bit rates between two
nodes must be within ±2% of each other, resulting in a maximal BaudRate_deviation of ±1%.
Minimum nominal clock frequency with a fractional part:
Examples:
• Baud rate = 20 kbit/s, OVER=0 (Oversampling 16x) => FNom(min) = 2.64 MHz
• Baud rate = 20 kbit/s, OVER=1 (Oversampling 8x) => FNom(min) = 1.47 MHz
• Baud rate = 1 kbit/s, OVER=0 (Oversampling 16x) => FNom(min) = 132 kHz
• Baud rate = 1 kbit/s, OVER=1 (Oversampling 8x) => FNom(min) = 74 kHz
If the fractional part is not used, the synchronization accuracy is much lower. The 16 most significant
bits, added with the first least significant bit, becomes the new clock divider (CD). The
equation of the baud rate deviation is the same as above, but the constants are:
Minimum nominal clock frequency without a fractional part:
Examples:
• Baud rate = 20 kbit/s, OVER=0 (Oversampling 16x) => FNom(min) = 19.12 MHz
• Baud rate = 20 kbit/s, OVER=1 (Oversampling 8x) => FNom(min) = 9.71 MHz
• Baud rate = 1 kbit/s, OVER=0 (Oversampling 16x) => FNom(min) = 956 kHz
• Baud rate = 1 kbit/s, OVER=1 (Oversampling 8x) => FNom(min) = 485 kHz
20.6.5.8 Identifier Parity
An identifier field consists of two sub-fields; the identifier and its parity. Bits 0 to 5 are assigned
to the identifier, while bits 6 and 7 are assigned to parity. Automatic parity management is disabled
by writing a one to the Parity Disable bit in the LIN Mode register (LINMR.PARDIS).
BaudRate_deviation 100 8 2 OVER – + BaudRate
8 FSLAVE -------------------------------------------------------------------------------------------------- = %
BaudRate_deviation 100 8 2 OVER – + BaudRate
8
FTOL_UNSYNC
100 ----------------------------------- xFNom
--------------------------------------------------------------------------------------------------
= %
–0.5 +0.5 -1 +1
FNom min 100 0.5 8 2 OVER – + 1 BaudRate
8 –15
100
--------- + 1 1%
------------------------------------------------------------------------------------------------------
= Hz
–4 +4 -1 +1
FNom min 100 4 8 2 OVER – + 1 Baudrate
8 –15
100
--------- + 1 1%
-----------------------------------------------------------------------------------------------
= Hz
453
32142D–06/2013
ATUC64/128/256L3/4U
• PARDIS=0: During header transmission, the parity bits are computed and in the shift register
they replace bits six and seven from IDCHR. During header reception, the parity bits are
checked and can generate a LIN Identifier Parity Error (see Section 20.6.6). Bits six and
seven in IDCHR read as zero when receiving.
• PARDIS=1: During header transmission, all the bits in IDCHR are sent on the bus. During
header reception, all the bits in IDCHR are updated with the received Identifier.
20.6.5.9 Node Action
After an identifier transaction, a LIN response mode has to be selected. This is done in the Node
Action field (LINMR.NACT). Below are some response modes exemplified in a small LIN cluster:
• Response, from master to slave1:
Master: NACT=PUBLISH
Slave1: NACT=SUBSCRIBE
Slave2: NACT=IGNORE
• Response, from slave1 to master:
Master: NACT=SUBSCRIBE
Slave1: NACT=PUBLISH
Slave2: NACT=IGNORE
• Response, from slave1 to slave2:
Master: NACT=IGNORE
Slave1: NACT=PUBLISH
Slave2: NACT=SUBSCRIBE
20.6.5.10 LIN Response Data Length
The response data length is the number of data fields (bytes), excluding the checksum.
Figure 20-25. Response Data Length
The response data length can be configured, either by the user, or automatically by bits 4 and 5
in the Identifier (IDCHR), in accordance to LIN 1.1. The user selects mode by writing to the Data
Length Mode bit (LINMR.DML):
• DLM=0: the response data length is configured by the user by writing to the 8-bit Data Length
Control field (LINMR.DLC). The response data length equals DLC + 1 bytes.
User configuration: 1 - 256 data fields (DLC+1)
Identifier configuration: 2/4/8 data fields
Sync
Break
Sync
Field
Identifier
Field
Checksum
Field
Data
Field
Data
Field
Data
Field
Data
Field
454
32142D–06/2013
ATUC64/128/256L3/4U
• DLM=1: the response data length is defined by the Identifier bits according to the table below.
20.6.5.11 Checksum
The last frame field is the checksum. It is configured by the Checksum Type (LINMR.CHKTYP),
and the Checksum Disable (LINMR.CHKDIS) bits. TXRDY will not be set after the last THR data
write if enabled. Writing a one to CHKDIS will disable the automatic checksum generation/checking,
and the user may send/check this last byte manually, disguised as a normal data.
The checksum is an inverted 8-bit sum with carry, either:
• over all data bytes, called a classic checksum. This is used for LIN 1.3 compliant slaves, and
automatically managed when CHKDIS=0, and CHKTYP=1.
• over all data bytes and the protected identifier, called an enhanced checksum. This is used
for LIN 2.0 compliant slaves, and automatically managed when CHKDIS=0, and CHKTYP=0.
20.6.5.12 Frame Slot Mode
A LIN master can be configured to use frame slots with a pre-defined minimum length. Writing a
one to the Frame Slot Mode Disable bit (LINMR.FSDIS) disables this mode. This mode will not
allow TXRDY to be set after a frame transfer until the entire frame slot duration has elapsed, in
effect preventing the master from sending a new header. The LIN Transfer Complete bit
(CSR.LINTC) will still be set after the checksum has been sent. Writing a one to CR.RSTST
clears LINTC.
Figure 20-26. Frame Slot Mode with Automatic Checksum
The minimum frame slot size is determined by TFrame_Maximum, and calculated below (all values
in bit periods):
• THeader_Nominal = 34
Table 20-8. Response Data Length if DLM = 1
IDCHR[5] IDCHR[4] Response Data Length [bytes]
00 2
01 2
10 4
11 8
Break Synch Protected
Identifier
Data N Checksum
Header
Interframe
space Response
space
Frame
Frame slot = TFrame_Maximum
Response
TXRDY
Write
THR
Write
LINID
Data 1 Data 2 Data 3
Data3
Data N-1
Data N
Frame Slot Mode
Disabled
Frame Slot Mode
Enabled
LINTC
Data 1
455
32142D–06/2013
ATUC64/128/256L3/4U
• TFrame_Maximum = 1.4 x (THeader_Nominal + TResponse_Nominal + 1)(Note:)
Note: The term “+1” leads to an integer result for TFrame_Max (LIN Specification 1.3)
If the Checksum is sent (CHKDIS=0):
• TResponse_Nominal = 10 x (NData + 1)
• TFrame_Maximum = 1.4 x (34 + 10 x (DLC + 1 + 1) + 1)
• TFrame_Maximum = 77 + 14 x DLC
If the Checksum is not sent (CHKDIS=1):
• TResponse_Nominal = 10 x NData
• TFrame_Maximum = 1.4 x (34 + 10 x (DLC + 1) + 1)
• TFrame_Maximum = 63 + 14 x DLC
20.6.6 LIN Errors
These error bits are cleared by writing a one to CSR.RSTSTA.
20.6.6.1 Slave Not Responding Error (CSR.LINSNRE)
This error is generated if no valid message appears within the TFrame_Maximum time frame
slot, while the USART is expecting a response from another node (NACT=SUBSCRIBE).
20.6.6.2 Checksum Error (CSR.LINCE)
This error is generated if the received checksum is wrong. This error can only be generated if the
checksum feature is enabled (CHKDIS=0).
20.6.6.3 Identifier Parity Error (CSR.LINIPE)
This error is generated if the identifier parity is wrong. This error can only be generated if parity is
enabled (PARDIS=0).
20.6.6.4 Inconsistent Sync Field Error (CSR.LINISFE)
This error is generated in slave mode if the Sync Field character received is not 0x55. Synchronization
procedure is aborted.
20.6.6.5 Bit Error (CSR.LINBE)
This error is generated if the value transmitted by the USART on Tx differs from the value sampled
on Rx. If a bit error is detected, the transmission is aborted at the next byte border.
20.6.7 LIN Frame Handling
20.6.7.1 Master Node Configuration
• Write a one to CR.TXEN and CR.RXEN to enable both transmitter and receiver
• Select LIN mode and master node by writing to MR.MODE
• Configure the baud rate by writing to CD and FP in BRGR
• Configure the frame transfer by writing to NACT, PARDIS, CHKDIS, CHKTYPE, DLCM,
FSDIS, and DLC in LINMR
• Check that CSR.TXRDY is one
• Send the header by writing to LINIR.IDCHR
The following procedure depends on the NACT setting:
456
32142D–06/2013
ATUC64/128/256L3/4U
• Case 1: NACT=PUBLISH, the USART sends a response
– Wait until TXRDY is a one
– Send a byte by writing to THR.TXCHR
– Repeat the two previous steps until there is no more data to send
– Wait until CSR.LINTC is a one
– Check for LIN errors
• Case 2: NACT=SUBSCRIBE, the USART receives a response
– Wait until RXRDY is a one
– Read RHR.RXCHR
– Repeat the two previous steps until there is no more data to read
– Wait until LINTC is a one
– Check for LIN errors
• Case 3: NACT=IGNORE, the USART is not concerned by a response
– Wait until LINTC is a one
– Check for LIN errors
Figure 20-27. Master Node Configuration, NACT=PUBLISH
Frame
Break Synch Protected
Identifier
Data 1 Data N Checksum
TXRDY
Write
THR
Write
LINIR
Data 1 Data 2 Data 3
Data N-1
Data N
RXRDY
Header
Interframe
space Response
space
Frame slot = TFrame_Maximum
Data3 Response
LINTC
FSDIS=1 FSDIS=0
457
32142D–06/2013
ATUC64/128/256L3/4U
Figure 20-28. Master Node Configuration, NACT=SUBSCRIBE
Figure 20-29. Master Node Configuration, NACT=IGNORE
20.6.7.2 Slave Node Configuration
This is identical to the master node configuration above, except for:
• LIN mode selected in MR.MODE is slave
• When the baud rate is configured, wait until CSR.LINID is a one, then;
• Check for LINISFE and LINPE errors, clear errors and LINIDby writing a one to RSTSTA
• Read IDCHR
• Configure the frame transfer by writing to NACT, PARDIS, CHKDIS, CHKTYPE, DLCM, and
DLC in LINMR
IMPORTANT: if NACT=PUBLISH, and this field is already correct, the LINMR register must still
be written with this value in order to set TXRDY, and to request the corresponding Peripheral
DMA Controller write transfer.
The different NACT settings result in the same procedure as for the master node, see page 455.
Break Synch Protected
Identifier
Data 1 Data N Checksum
TXRDY
Read
RHR
Write
LINIR
Data 1
Data N-1
Data N-1
RXRDY
Data N-2 Data N
Header
Interframe
Response space
space
Frame
Frame slot = TFrame_Maximum
Data3 Response
LINTC
FSDIS=1 FSDIS=0
TXRDY
Write
LINIR
RXRDY
LINTC
Break Synch Protected
Identifier
Data 1 Data N-1 Data N Checksum
Header
Interframe
Response space
space
Frame
Frame slot = TFrame_Maximum
Data3 Response
FSDIS=1 FSDIS=0
458
32142D–06/2013
ATUC64/128/256L3/4U
Figure 20-30. Slave Node Configuration, NACT=PUBLISH
Figure 20-31. Slave Node Configuration, NACT=SUBSCRIBE
Figure 20-32. Slave Node Configuration, NACT=IGNORE
20.6.8 LIN Frame Handling With The Peripheral DMA Controller
The USART can be used together with the Peripheral DMA Controller in order to transfer data
without processor intervention. The DMA Controller uses the TXRDY and RXRDY bits, to trigger
one byte writes or reads. It always writes to THR, and it always reads RHR.
Break Synch Protected
Identifier
Data 1 Data N Checksum
TXRDY
Write
THR
Read
LINID
Data 1 Data 3
Data N-1
Data N
RXRDY
LINIDRX
Data 2
LINTC
TXRDY
Read
RHR
Read
LINID
RXRDY
LINIDRX
LINTC
Break Synch Protected
Identifier
Data 1 Data N Checksum
Data 1
Data N-1
Data N-2 Data N-1 Data N
TXRDY
Read
RHR
Read
LINID
RXRDY
LINIDRX
LINTC
Break Synch Protected
Identifier
Data 1 Data N Checksum Data N-1
459
32142D–06/2013
ATUC64/128/256L3/4U
20.6.8.1 Master Node Configuration
The Peripheral DMA Controller Mode bit (LINMR.PDCM) allows the user to select configuration:
• PDCM=0: LIN configuration must be written to LINMR, it is not stored in the write buffer.
• PDCM=1: LIN configuration is written by the DMA Controller to THR, and is stored in the
write buffer. Since data transfer size is a byte, the transfer is split into two accesses. The first
writes the NACT, PARDIS, CHKDIS, CHKTYP, DLM and FSDIS bits, while the second writes
the DLC field. If NACT=PUBLISH, the write buffer will also contain the Identifier.
When NACT=SUBSCRIBE, the read buffer contains the data.
Figure 20-33. Master Node with Peripheral DMA Controller (PDCM=0)
Figure 20-34. Master Node with Peripheral DMA Controller (PDCM=1)
|
|
|
|
RXRDY
TXRDY
Peripheral
bus
USART LIN
CONTROLLER
DATA 0
DATA N
|
|
|
|
READ BUFFER
NODE ACTION = PUBLISH NODE ACTION = SUBSCRIBE
Peripheral DMA
Controller
RXRDY
Peripheral
bus
DATA 0
DATA 1
DATA N
WRITE BUFFER
Peripheral DMA
Controller
USART LIN
CONTROLLER
|
|
|
|
|
|
|
|
NACT
PARDIS
CHKDIS
CHKTYP DLM
FSDIS
DLC
IDENTIFIER
DATA 0
DATA N
WRITE BUFFER
RXRDY
Peripheral
bus
DLC
IDENTIFIER
DATA 0
DATA N
WRITE BUFFER
RXRDY READ BUFFER
NODE ACTION = PUBLISH NODE ACTION = SUBSCRIBE
Peripheral DMA
Controller
Peripheral DMA
Controller
USART LIN
CONTROLLER
NACT
PARDIS
CHKDIS
CHKTYP DLM
FSDIS
USART LIN
CONTROLLER
TXRDY
Peripheral
bus
460
32142D–06/2013
ATUC64/128/256L3/4U
20.6.8.2 Slave Node Configuration
In this mode, the Peripheral DMA Controller transfers only data. The user reads the Identifier
from LINIR, and selects LIN mode by writing to LINMR. When NACT=PUBLISH the data is in the
write buffer, while the read buffer contains the data when NACT=SUBSCRIBE.
IMPORTANT: if in slave mode, NACT is already configured correctly as PUBLISH, the LINMR
register must still be written with this value in order to set TXRDY, and to request the corresponding
Peripheral DMA Controller write transfer.
Figure 20-35. Slave Node with Peripheral DMA Controller
20.6.9 Wake-up Request
Any node in a sleeping LIN cluster may request a wake-up. By writing to the Wakeup Signal
Type bit (LINMR.WKUPTYP), the user can choose to send either a LIN 1.3 (WKUPTYP=1), or a
LIN 2.0 (WKUPTYP=0) compliant wakeup request. Writing a one to the Send LIN Wakeup Signal
bit (CR.LINWKUP), transmits a wakeup, and when completed sets LINTC.
According to LIN 1.3, the wakeup request should be generated with the character 0x80 in order
to impose eight successive dominant bits.
According to LIN 2.0, the wakeup request is issued by forcing the bus into the dominant state for
250µs to 5ms. Sending the character 0xF0 does this, regardless of baud rate.
• Baud rate max = 20 kbit/s -> one bit period = 50µs -> five bit periods = 250µs
• Baud rate min = 1 kbit/s -> one bit period = 1ms -> five bit periods = 5ms
20.6.10 Bus Idle Time-out
LIN bus inactivity should eventually cause slaves to time-out and enter sleep mode. LIN 1.3
specifies this to 25000 bit periods, whilst LIN 2.0 specifies 4seconds. For the time-out counter
operation see Section 20.6.3.8 ”Receiver Time-out” on page 444.
|
|
|
|
|
|
|
|
DATA 0
DATA N
RXRDY
Peripheral
Bus
READ BUFFER
NACT = SUBSCRIBE DATA 0
DATA N
TXRDY
Peripheral
bus
WRITE BUFFER
USART LIN
CONTROLLER
USART LIN
CONTROLLER
Peripheral DMA
Controller
Peripheral DMA
Controller
Table 20-9. Receiver Time-out Values (RTOR.TO)
LIN Specification Baud Rate Time-out period TO
2.0
1 000 bit/s
4s
4 000
2 400 bit/s 9 600
9 600 bit/s 38 400
19 200 bit/s 76 800
20 000 bit/s 80 000
1.3 - 25 000 bit periods 25 000
461
32142D–06/2013
ATUC64/128/256L3/4U
20.6.11 Test Modes
The internal loopback feature enables on-board diagnostics, and allows the USART to operate
in three different test modes, with reconfigured pin functionality, as shown below.
20.6.11.1 Normal Mode
During normal operation, a receivers RXD pin is connected to a transmitters TXD pin.
Figure 20-36. Normal Mode Configuration
20.6.11.2 Automatic Echo Mode
Automatic echo mode allows bit-by-bit retransmission. When a bit is received on the RXD pin, it
is also sent to the TXD pin, as shown in Figure 20-37. Transmitter configuration has no effect.
Figure 20-37. Automatic Echo Mode Configuration
20.6.11.3 Local Loopback Mode
Local loopback mode connects the output of the transmitter directly to the input of the receiver,
as shown in Figure 20-38. The TXD and RXD pins are not used. The RXD pin has no effect on
the receiver and the TXD pin is continuously driven high, as in idle state.
Figure 20-38. Local Loopback Mode Configuration
20.6.11.4 Remote Loopback Mode
Remote loopback mode connects the RXD pin to the TXD pin, as shown in Figure 20-39. The
transmitter and the receiver are disabled and have no effect. This mode allows bit-by-bit
retransmission.
Receiver
Transmitter
RXD
TXD
Receiver
Transmitter
RXD
TXD
Receiver
Transmitter
RXD
TXD
1
462
32142D–06/2013
ATUC64/128/256L3/4U
Figure 20-39. Remote Loopback Mode Configuration
20.6.12 Write Protection Registers
To prevent single software errors from corrupting USART behavior, certain address spaces can
be write-protected by writing the correct Write Protect KEY and a one to the Write Protect
Enable bit in the Write Protect Mode Register (WPMR.WPKEY, and WPMR.WPEN). Disabling
the write protection is done by writing the correct key, and a zero to WPEN.
Write attempts to a write protected register are detected and the Write Protect Violation Status
bit in the Write Protect Status Register (WPSR.WPVS) is set, while the Write Protect Violation
Source field (WPSR.WPVSRC) indicates the targeted register. Writing the correct key to the
Write Protect KEY bit (WPMR.WPKEY) clears WPVSRC and WPVS.
The protected registers are:
• ”Mode Register” on page 466
• ”Baud Rate Generator Register” on page 476
• ”Receiver Time-out Register” on page 477
• ”Transmitter Timeguard Register” on page 478
Receiver
Transmitter
RXD
TXD
1
463
32142D–06/2013
ATUC64/128/256L3/4U
20.7 User Interface
Note: 1. Values in the Version Register vary with the version of the IP block implementation.
Table 20-10. USART Register Memory Map
Offset Register Name Access Reset
0x0000 Control Register CR Write-only 0x00000000
0x0004 Mode Register MR Read-write 0x00000000
0x0008 Interrupt Enable Register IER Write-only 0x00000000
0x000C Interrupt Disable Register IDR Write-only 0x00000000
0x0010 Interrupt Mask Register IMR Read-only 0x00000000
0x0014 Channel Status Register CSR Read-only 0x00000000
0x0018 Receiver Holding Register RHR Read-only 0x00000000
0x001C Transmitter Holding Register THR Write-only 0x00000000
0x0020 Baud Rate Generator Register BRGR Read-write 0x00000000
0x0024 Receiver Time-out Register RTOR Read-write 0x00000000
0x0028 Transmitter Timeguard Register TTGR Read-write 0x00000000
0x0054 LIN Mode Register LINMR Read-write 0x00000000
0x0058 LIN Identifier Register LINIR Read-write 0x00000000
0x00E4 Write Protect Mode Register WPMR Read-write 0x00000000
0x00E8 Write Protect Status Register WPSR Read-only 0x00000000
0x00FC Version Register VERSION Read-only 0x–(1)
464
32142D–06/2013
ATUC64/128/256L3/4U
20.7.1 Control Register
Name: CR
Access Type: Write-only
Offset: 0x0
Reset Value: 0x00000000
• LINWKUP: Send LIN Wakeup Signal
Writing a zero to this bit has no effect.
Writing a one to this bit will sends a wakeup signal on the LIN bus.
• LINABT: Abort LIN Transmission
Writing a zero to this bit has no effect.
Writing a one to this bit will abort the current LIN transmission.
• RTSDIS/RCS: Request to Send Disable/Release SPI Chip Select
Writing a zero to this bit has no effect.
Writing a one to this bit when USART is not in SPI master mode drives RTS pin high.
Writing a one to this bit when USART is in SPI master mode releases NSS (RTS pin).
• RTSEN/FCS: Request to Send Enable/Force SPI Chip Select
Writing a zero to this bit has no effect.
Writing a one to this bit when USART is not in SPI master mode drives RTS low.
Writing a one to this bit when USART is in SPI master mode when;
FCS=0: has no effect.
FCS=1: forces NSS (RTS pin) low, even if USART is not transmitting, in order to address SPI slave devices supporting the
CSAAT Mode (Chip Select Active After Transfer).
• RETTO: Rearm Time-out
Writing a zero to this bit has no effect.
Writing a one to this bit reloads the time-out counter and clears CSR.TIMEOUT.
• RSTNACK: Reset Non Acknowledge
Writing a zero to this bit has no effect.
Writing a one to this bit clears CSR.NACK.
• SENDA: Send Address
Writing a zero to this bit has no effect.
Writing a one to this bit will in multidrop mode send the next character written to THR as an address.
• STTTO: Start Time-out
Writing a zero to this bit has no effect.
Writing a one to this bit will abort any current time-out count down, and trigger a new count down when the next character has
been received. CSR.TIMEOUT is also cleared.
31 30 29 28 27 26 25 24
––––––––
23 22 21 20 19 18 17 16
– – LINWKUP LINABT RTSDIS/RCS RTSEN/FCS – –
15 14 13 12 11 10 9 8
RETTO RSTNACK – SENDA STTTO STPBRK STTBRK RSTSTA
76543210
TXDIS TXEN RXDIS RXEN RSTTX RSTRX – –
465
32142D–06/2013
ATUC64/128/256L3/4U
• STPBRK: Stop Break
Writing a zero to this bit has no effect.
Writing a one to this bit will stop the generation of break signal characters, and then send ones for TTGR.TG duration, or at least
12 bit periods. No effect if no break is being transmitted.
• STTBRK: Start Break
Writing a zero to this bit has no effect.
Writing a one to this bit will start transmission of break characters when current characters present in THR and the transmit shift
register have been sent. No effect if a break signal is already being generated.
• RSTSTA: Reset Status Bits
Writing a zero to this bit has no effect.
Writing a one to this bit will clear the following bits in CSR: PARE, FRAME, OVRE, LINBE, LINSFE, LINIPE, LINCE, LINSNRE,
and RXBRK.
• TXDIS: Transmitter Disable
Writing a zero to this bit has no effect.
Writing a one to this bit disables the transmitter.
• TXEN: Transmitter Enable
Writing a zero to this bit has no effect.
Writing a one to this bit enables the transmitter if TXDIS is zero.
• RXDIS: Receiver Disable
Writing a zero to this bit has no effect.
Writing a one to this bit disables the receiver.
• RXEN: Receiver Enable
Writing a zero to this bit has no effect.
Writing a one to this bit enables the receiver if RXDIS is zero.
• RSTTX: Reset Transmitter
Writing a zero to this bit has no effect.
Writing a one to this bit will reset the transmitter.
• RSTRX: Reset Receiver
Writing a zero to this bit has no effect.
Writing a one to this bit will reset the receiver.
466
32142D–06/2013
ATUC64/128/256L3/4U
20.7.2 Mode Register
Name: MR
Access Type: Read-write
Offset: 0x4
Reset Value: 0x00000000
This register can only be written if the WPEN bit is cleared in the Write Protect Mode Register.
• INACK: Inhibit Non Acknowledge
0: The NACK is generated.
1: The NACK is not generated.
• OVER: Oversampling Mode
0: Oversampling at 16 times the baud rate.
1: Oversampling at 8 times the baud rate.
• CLKO: Clock Output Select
0: The USART does not drive the CLK pin.
1: The USART drives the CLK pin unless USCLKS selects the external clock.
• MODE9: 9-bit Character Length
0: CHRL defines character length.
1: 9-bit character length.
• MSBF/CPOL: Bit Order or SPI Clock Polarity
If USART does not operate in SPI Mode:
MSBF=0: Least Significant Bit is sent/received first.
MSBF=1: Most Significant Bit is sent/received first.
If USART operates in SPI Mode, CPOL is used with CPHA to produce the required clock/data relationship between devices.
CPOL=0: The inactive state value of CLK is logic level zero.
CPOL=1: The inactive state value of CLK is logic level one.
31 30 29 28 27 26 25 24
––––– –
23 22 21 20 19 18 17 16
– – – INACK OVER CLKO MODE9 MSBF/CPOL
15 14 13 12 11 10 9 8
CHMODE NBSTOP PAR SYNC/CPHA
76543210
CHRL USCLKS MODE
467
32142D–06/2013
ATUC64/128/256L3/4U
• CHMODE: Channel Mode
• NBSTOP: Number of Stop Bits
• PAR: Parity Type
• SYNC/CPHA: Synchronous Mode Select or SPI Clock Phase
If USART does not operate in SPI Mode (MODE is 0xE and 0xF):
SYNC = 0: USART operates in Asynchronous Mode.
SYNC = 1: USART operates in Synchronous Mode.
If USART operates in SPI Mode, CPHA determines which edge of CLK causes data to change and which edge causes data to
be captured. CPHA is used with CPOL to produce the required clock/data relationship between master and slave devices.
CPHA = 0: Data is changed on the leading edge of CLK and captured on the following edge of CLK.
CPHA = 1: Data is captured on the leading edge of CLK and changed on the following edge of CLK.
Table 20-11.
CHMODE Mode Description
0 0 Normal Mode
0 1 Automatic Echo. Receiver input is connected to the TXD pin.
1 0 Local Loopback. Transmitter output is connected to the Receiver input.
1 1 Remote Loopback. RXD pin is internally connected to the TXD pin.
Table 20-12.
NBSTOP Asynchronous (SYNC=0) Synchronous (SYNC=1)
0 0 1 stop bit 1 stop bit
0 1 1.5 stop bits Reserved
1 0 2 stop bits 2 stop bits
1 1 Reserved Reserved
Table 20-13.
PAR Parity Type
0 0 0 Even parity
0 0 1 Odd parity
0 1 0 Parity forced to 0 (Space)
0 1 1 Parity forced to 1 (Mark)
1 0 x No parity
1 1 x Multidrop mode
468
32142D–06/2013
ATUC64/128/256L3/4U
• CHRL: Character Length.
• USCLKS: Clock Selection
Note: 1. The value of DIV is device dependent. Please refer to the Module Configuration section at the end of this chapter.
• MODE
Table 20-14.
CHRL Character Length
0 0 5 bits
0 1 6 bits
1 0 7 bits
1 1 8 bits
Table 20-15.
USCLKS Selected Clock
0 0 CLK_USART
0 1 CLK_USART/DIV(1)
1 0 Reserved
1 1 CLK
Table 20-16.
MODE Mode of the USART
0 0 0 0 Normal
0 0 1 0 Hardware Handshaking
1 0 1 0 LIN Master
1 0 1 1 LIN Slave
1 1 1 0 SPI Master
1 1 1 1 SPI Slave
Others Reserved
469
32142D–06/2013
ATUC64/128/256L3/4U
20.7.3 Interrupt Enable Register
Name: IER
Access Type: Write-only
Offset: 0x8
Reset Value: 0x00000000
Writing a zero to a bit in this register has no effect.
Writing a one to a bit in this register will set the corresponding bit in IMR.
31 30 29 28 27 26 25 24
– – LINSNRE LINCE LINIPE LINISFE LINBE –
23 22 21 20 19 18 17 16
– – – – CTSIC – – –
15 14 13 12 11 10 9 8
LINTC LINID NACK/LINBK RXBUFF – ITER/UNRE TXEMPTY TIMEOUT
76543210
PARE FRAME OVRE – – RXBRK TXRDY RXRDY
470
32142D–06/2013
ATUC64/128/256L3/4U
20.7.4 Interrupt Disable Register
Name: IDR
Access Type: Write-only
Offset: 0xC
Reset Value: 0x00000000
Writing a zero to a bit in this register has no effect.
Writing a one to a bit in this register will clear the corresponding bit in IMR.
31 30 29 28 27 26 25 24
– – LINSNRE LINCE LINIPE LINISFE LINBE –
23 22 21 20 19 18 17 16
– – – – CTSIC – – –
15 14 13 12 11 10 9 8
LINTC LINID NACK/LINBK RXBUFF – ITER/UNRE TXEMPTY TIMEOUT
76543210
PARE FRAME OVRE – – RXBRK TXRDY RXRDY
471
32142D–06/2013
ATUC64/128/256L3/4U
20.7.5 Interrupt Mask Register
Name: IMR
Access Type: Read-only
Offset: 0x10
Reset Value: 0x00000000
0: The corresponding interrupt is disabled.
1: The corresponding interrupt is enabled.
A bit in this register is cleared when the corresponding bit in IDR is written to one.
A bit in this register is set when the corresponding bit in IER is written to one.
31 30 29 28 27 26 25 24
– – LINSNRE LINCE LINIPE LINISFE LINBE –
23 22 21 20 19 18 17 16
– – – – CTSIC – – –
15 14 13 12 11 10 9 8
LINTC LINID NACK/LINBK RXBUFF – ITER/UNRE TXEMPTY TIMEOUT
76543210
PARE FRAME OVRE – – RXBRK TXRDY RXRDY
472
32142D–06/2013
ATUC64/128/256L3/4U
20.7.6 Channel Status Register
Name: CSR
Access Type: Read-only
Offset: 0x14
Reset Value: 0x00000000
• LINSNRE: LIN Slave Not Responding Error
0: No LIN Slave Not Responding Error has been detected since the last RSTSTA.
1: A LIN Slave Not Responding Error has been detected since the last RSTSTA.
• LINCE: LIN Checksum Error
0: No LIN Checksum Error has been detected since the last RSTSTA.
1: A LIN Checksum Error has been detected since the last RSTSTA.
• LINIPE: LIN Identifier Parity Error
0: No LIN Identifier Parity Error has been detected since the last RSTSTA.
1: A LIN Identifier Parity Error has been detected since the last RSTSTA.
• LINISFE: LIN Inconsistent Sync Field Error
0: No LIN Inconsistent Sync Field Error has been detected since the last RSTSTA
1: The USART is configured as a Slave node and a LIN Inconsistent Sync Field Error has been detected since the last RSTSTA.
• LINBE: LIN Bit Error
0: No Bit Error has been detected since the last RSTSTA.
1: A Bit Error has been detected since the last RSTSTA.
• CTS: Image of CTS Input
0: CTS is low.
1: CTS is high.
• CTSIC: Clear to Send Input Change Flag
0: No change has been detected on the CTS pin since the last CSR read.
1: At least one change has been detected on the CTS pin since the last CSR read.
• LINTC: LIN Transfer Completed
0: The USART is either idle or a LIN transfer is ongoing.
1: A LIN transfer has been completed since the last RSTSTA.
• LINID: LIN Identifier
0: No LIN Identifier has been sent or received.
1: A LIN Identifier has been sent (master) or received (slave), since the last RSTSTA.
• NACK: Non Acknowledge
0: No Non Acknowledge has been detected since the last RSTNACK.
1: At least one Non Acknowledge has been detected since the last RSTNACK.
• RXBUFF: Reception Buffer Full
0: The Buffer Full signal from the Peripheral DMA Controller channel is inactive.
31 30 29 28 27 26 25 24
– – LINSNRE LINCE LINIPE LINISFE LINBE –
23 22 21 20 19 18 17 16
CTS – – – CTSIC – – –
15 14 13 12 11 10 9 8
LINTC LINID NACK/LINBK RXBUFF – ITER/UNRE TXEMPTY TIMEOUT
76543210
PARE FRAME OVRE – – RXBRK TXRDY RXRDY
473
32142D–06/2013
ATUC64/128/256L3/4U
1: The Buffer Full signal from the Peripheral DMA Controller channel is active.
• ITER/UNRE: Max number of Repetitions Reached or SPI Underrun Error
If USART does not operate in SPI Slave Mode:
ITER=0: Maximum number of repetitions has not been reached since the last RSTSTA.
ITER=1: Maximum number of repetitions has been reached since the last RSTSTA.
If USART operates in SPI Slave Mode:
UNRE=0: No SPI underrun error has occurred since the last RSTSTA.
UNRE=1: At least one SPI underrun error has occurred since the last RSTSTA.
• TXEMPTY: Transmitter Empty
0: The transmitter is either disabled or there are characters in THR, or in the transmit shift register.
1: There are no characters in neither THR, nor in the transmit shift register.
• TIMEOUT: Receiver Time-out
0: There has not been a time-out since the last Start Time-out command (CR.STTTO), or RTOR.TO is zero.
1: There has been a time-out since the last Start Time-out command.
• PARE: Parity Error
0: Either no parity error has been detected, or the parity bit is a zero in multidrop mode, since the last RSTSTA.
1: Either at least one parity error has been detected, or the parity bit is a one in multidrop mode, since the last RSTSTA.
• FRAME: Framing Error
0: No stop bit has been found as low since the last RSTSTA.
1: At least one stop bit has been found as low since the last RSTSTA.
• OVRE: Overrun Error
0: No overrun error has occurred since the last RSTSTA.
1: At least one overrun error has occurred since the last RSTSTA.
• RXBRK: Break Received/End of Break
0: No Break received or End of Break detected since the last RSTSTA.
1: Break received or End of Break detected since the last RSTSTA.
• TXRDY: Transmitter Ready
0: The transmitter is either disabled, or a character in THR is waiting to be transferred to the transmit shift register, or an
STTBRK command has been requested. As soon as the transmitter is enabled, TXRDY becomes one.
1: There is no character in the THR.
• RXRDY: Receiver Ready
0: The receiver is either disabled, or no complete character has been received since the last read of RHR. If characters were
being received when the receiver was disabled, RXRDY changes to 1 when the receiver is enabled.
1: At least one complete character has been received and RHR has not yet been read.
474
32142D–06/2013
ATUC64/128/256L3/4U
20.7.7 Receiver Holding Register
Name: RHR
Access Type: Read-only
Offset: 0x18
Reset Value: 0x00000000
• RXCHR: Received Character
Last received character.
31 30 29 28 27 26 25 24
––––––––
23 22 21 20 19 18 17 16
––––––––
15 14 13 12 11 10 9 8
– – – – – – – RXCHR[8]
76543210
RXCHR[7:0]
475
32142D–06/2013
ATUC64/128/256L3/4U
20.7.8 Transmitter Holding Register
Name: THR
Access Type: Write-only
Offset: 0x1C
Reset Value: 0x00000000
• TXCHR: Character to be Transmitted
If TXRDY is zero this field contains the next character to be transmitted.
31 30 29 28 27 26 25 24
––––––––
23 22 21 20 19 18 17 16
––––––––
15 14 13 12 11 10 9 8
– – – – – – – TXCHR[8]
76543210
TXCHR[7:0]
476
32142D–06/2013
ATUC64/128/256L3/4U
20.7.9 Baud Rate Generator Register
Name: BRGR
Access Type: Read-write
Offset: 0x20
Reset Value: 0x00000000
This register can only be written to if write protection is disabled, see ”Write Protect Mode Register” on page 482.
• FP: Fractional Part
0: Fractional divider is disabled.
1 - 7: Baud rate resolution, defined by FP x 1/8.
• CD: Clock Divider
31 30 29 28 27 26 25 24
––––––––
23 22 21 20 19 18 17 16
– – – – – FP
15 14 13 12 11 10 9 8
CD[15:8]
76543210
CD[7:0]
Table 20-17.
CD
SYNC = 0
SYNC = 1
or
MODE = SPI
(Master or Slave)
OVER = 0 OVER = 1
0 Baud Rate Clock Disabled
1 to 65535
Baud Rate =
Selected Clock/16/CD
Baud Rate =
Selected Clock/8/CD
Baud Rate =
Selected Clock /CD
477
32142D–06/2013
ATUC64/128/256L3/4U
20.7.10 Receiver Time-out Register
Name: RTOR
Access Type: Read-write
Offset: 0x24
Reset Value: 0x00000000
This register can only be written to if write protection is disabled, see ”Write Protect Mode Register” on page 482.
• TO: Time-out Value
0: The receiver Time-out is disabled.
1 - 131071: The receiver Time-out is enabled and the time-out delay is TO x bit period.
Note that the size of the TO counter is device dependent, see the Module Configuration section.
31 30 29 28 27 26 25 24
––––––––
23 22 21 20 19 18 17 16
– – – – – – – TO[16]
15 14 13 12 11 10 9 8
TO[15:8]
76543210
TO[7:0]
478
32142D–06/2013
ATUC64/128/256L3/4U
20.7.11 Transmitter Timeguard Register
Name: TTGR
Access Type: Read-write
Offset: 0x28
Reset Value: 0x00000000
This register can only be written to if write protection is disabled, see ”Write Protect Mode Register” on page 482.
• TG: Timeguard Value
0: The transmitter Timeguard is disabled.
1 - 255: The transmitter timeguard is enabled and the timeguard delay is TG x bit period.
31 30 29 28 27 26 25 24
––––––––
23 22 21 20 19 18 17 16
––––––––
15 14 13 12 11 10 9 8
––––––––
76543210
TG
479
32142D–06/2013
ATUC64/128/256L3/4U
20.7.12 LIN Mode Register
Name: LINMR
Access Type: Read-write
Offset: 0x54
Reset Value: 0x00000000
• PDCM: Peripheral DMA Controller Mode
0: The LIN mode register is not written by the Peripheral DMA Controller.
1: The LIN mode register is, except for this bit, written by the Peripheral DMA Controller.
• DLC: Data Length Control
0 - 255: If DLM=0 this field defines the response data length to DLC+1 bytes.
• WKUPTYP: Wakeup Signal Type
0: Writing a one to CR.LINWKUP will send a LIN 2.0 wakeup signal.
1: Writing a one to CR.LINWKUP will send a LIN 1.3 wakeup signal.
• FSDIS: Frame Slot Mode Disable
0: The Frame Slot mode is enabled.
1: The Frame Slot mode is disabled.
• DLM: Data Length Mode
0: The response data length is defined by DLC.
1: The response data length is defined by bits 4 and 5 of the Identifier (LINIR.IDCHR).
• CHKTYP: Checksum Type
0: LIN 2.0 “Enhanced” checksum
1: LIN 1.3 “Classic” checksum
• CHKDIS: Checksum Disable
0: Checksum is automatically computed and sent when master, and checked when slave.
1: Checksum is not computed and sent, nor checked.
• PARDIS: Parity Disable
0: Identifier parity is automatically computed and sent when master, and checked when slave.
1: Identifier parity is not computed and sent, nor checked.
• NACT: LIN Node Action
31 30 29 28 27 26 25 24
––––––––
23 22 21 20 19 18 17 16
– – – – – – – PDCM
15 14 13 12 11 10 9 8
DLC
76543210
WKUPTYP FSDIS DLM CHKTYP CHKDIS PARDIS NACT
Table 20-18.
NACT Mode Description
0 0 PUBLISH: The USART transmits the response.
480
32142D–06/2013
ATUC64/128/256L3/4U
0 1 SUBSCRIBE: The USART receives the response.
1 0 IGNORE: The USART does not transmit and does not receive the response.
1 1 Reserved
Table 20-18.
481
32142D–06/2013
ATUC64/128/256L3/4U
20.7.13 LIN Identifier Register
Name: LINIR
Access Type: Read-write or Read-only
Offset: 0x58
Reset Value: 0x00000000
• IDCHR: Identifier Character
If USART is in LIN master mode, the IDCHR field is read-write, and its value is the Identifier character to be transmitted.
If USART is in LIN slave mode, the IDCHR field is read-only, and its value is the last received Identifier character.
31 30 29 28 27 26 25 24
––––––––
23 22 21 20 19 18 17 16
––––––––
15 14 13 12 11 10 9 8
––––––––
76543210
IDCHR
482
32142D–06/2013
ATUC64/128/256L3/4U
20.7.14 Write Protect Mode Register
Register Name: WPMR
Access Type: Read-write
Offset: 0xE4
Reset Value: See Table 20-10
• WPKEY: Write Protect KEY
Has to be written to 0x555341 (“USA” in ASCII) in order to successfully write WPEN. Always reads as zero.
• WPEN: Write Protect Enable
0 = Write protection disabled.
1 = Write protection enabled.
Protects the registers:
• ”Mode Register” on page 466
• ”Baud Rate Generator Register” on page 476
• ”Receiver Time-out Register” on page 477
• ”Transmitter Timeguard Register” on page 478
31 30 29 28 27 26 25 24
WPKEY[23:16]
23 22 21 20 19 18 17 16
WPKEY[15:8]
15 14 13 12 11 10 9 8
WPKEY[7:0]
76543210
— — — — — — — WPEN
483
32142D–06/2013
ATUC64/128/256L3/4U
20.7.15 Write Protect Status Register
Register Name: WPSR
Access Type: Read-only
Offset: 0xE8
Reset Value: See Table 20-10
• WPVSRC: Write Protect Violation Source
If WPVS=1 this field indicates which write-protected register was unsuccessfully written to, either by address offset or code.
• WPVS: Write Protect Violation Status
0= No write protect violation has occurred since the last WPSR read.
1= A write protect violation has occurred since the last WPSR read.
Note: Reading WPSR automatically clears all fields.
31 30 29 28 27 26 25 24
————————
23 22 21 20 19 18 17 16
WPVSRC[15:8]
15 14 13 12 11 10 9 8
WPVSRC[7:0]
76543210
— — — — — — — WPVS
484
32142D–06/2013
ATUC64/128/256L3/4U
20.7.16 Version Register
Name: VERSION
Access Type: Read-only
Offset: 0xFC
Reset Value: -
• MFN
Reserved. No functionality associated.
• VERSION
Version of the module. No functionality associated.
31 30 29 28 27 26 25 24
––––––––
23 22 21 20 19 18 17 16
– – – – MFN
15 14 13 12 11 10 9 8
– – – – VERSION[11:8]
76543210
VERSION[7:0]
485
32142D–06/2013
ATUC64/128/256L3/4U
20.8 Module Configuration
The specific configuration for each USART instance is listed in the following tables.The module
bus clocks listed here are connected to the system bus clocks. Please refer to the Power Manager
chapter for details.
Table 20-19. USART Configuration
Feature USART0 USART1 USART2 USART3
Receiver Time-out Counter Size
(Size of the RTOR.TO field) 17 bit 17 bit 17 bit 17 bit
DIV Value for divided CLK_USART 8 8 8 8
Table 20-20. USART Clocks
Module Name Clock Name Description
USART0 CLK_USART0 Clock for the USART0 bus interface
USART1 CLK_USART1 Clock for the USART1 bus interface
USART2 CLK_USART2 Clock for the USART2 bus interface
USART3 CLK_USART3 Clock for the USART3 bus interface
Table 20-21. Register Reset Values
Register Reset Value
VERSION 0x00000440
486
32142D–06/2013
ATUC64/128/256L3/4U
21. Serial Peripheral Interface (SPI)
Rev: 2.1.1.3
21.1 Features
• Compatible with an embedded 32-bit microcontroller
• Supports communication with serial external devices
– Four chip selects with external decoder support allow communication with up to 15
peripherals
– Serial memories, such as DataFlash and 3-wire EEPROMs
– Serial peripherals, such as ADCs, DACs, LCD controllers, CAN controllers and Sensors
– External co-processors
• Master or Slave Serial Peripheral Bus Interface
– 4 - to 16-bit programmable data length per chip select
– Programmable phase and polarity per chip select
– Programmable transfer delays between consecutive transfers and between clock and data
per chip select
– Programmable delay between consecutive transfers
– Selectable mode fault detection
• Connection to Peripheral DMA Controller channel capabilities optimizes data transfers
– One channel for the receiver, one channel for the transmitter
– Next buffer support
– Four character FIFO in reception
21.2 Overview
The Serial Peripheral Interface (SPI) circuit is a synchronous serial data link that provides communication
with external devices in Master or Slave mode. It also enables communication
between processors if an external processor is connected to the system.
The Serial Peripheral Interface is essentially a shift register that serially transmits data bits to
other SPIs. During a data transfer, one SPI system acts as the “master”' which controls the data
flow, while the other devices act as “slaves'' which have data shifted into and out by the master.
Different CPUs can take turn being masters (Multiple Master Protocol opposite to Single Master
Protocol where one CPU is always the master while all of the others are always slaves) and one
master may simultaneously shift data into multiple slaves. However, only one slave may drive its
output to write data back to the master at any given time.
A slave device is selected when the master asserts its NSS signal. If multiple slave devices
exist, the master generates a separate slave select signal for each slave (NPCS).
The SPI system consists of two data lines and two control lines:
• Master Out Slave In (MOSI): this data line supplies the output data from the master shifted
into the input(s) of the slave(s).
• Master In Slave Out (MISO): this data line supplies the output data from a slave to the input of
the master. There may be no more than one slave transmitting data during any particular
transfer.
• Serial Clock (SPCK): this control line is driven by the master and regulates the flow of the
data bits. The master may transmit data at a variety of baud rates; the SPCK line cycles once
for each bit that is transmitted.
• Slave Select (NSS): this control line allows slaves to be turned on and off by hardware.
487
32142D–06/2013
ATUC64/128/256L3/4U
21.3 Block Diagram
Figure 21-1. SPI Block Diagram
21.4 Application Block Diagram
Figure 21-2. Application Block Diagram: Single Master/Multiple Slave Implementation
Spi Interface
Interrupt Control
Peripheral DMA
Controller
I/O
Controller
CLK_SPI
Peripheral Bus
SPI Interrupt
SPCK
NPCS3
NPCS2
NPCS1
NPCS0/NSS
MOSI
MISO
Slave 0
Slave 2
Slave 1
SPCK
NPCS3
NPCS2
NPCS1
NPCS0
MOSI
MISO
Spi Master
SPCK
NSS
MOSI
MISO
SPCK
NSS
MOSI
MISO
SPCK
NSS
MOSI
MISO
NC
488
32142D–06/2013
ATUC64/128/256L3/4U
21.5 I/O Lines Description
21.6 Product Dependencies
In order to use this module, other parts of the system must be configured correctly, as described
below.
21.6.1 I/O Lines
The pins used for interfacing the compliant external devices may be multiplexed with I/O lines.
The user must first configure the I/O Controller to assign the SPI pins to their peripheral
functions.
21.6.2 Clocks
The clock for the SPI bus interface (CLK_SPI) is generated by the Power Manager. This clock is
enabled at reset, and can be disabled in the Power Manager. It is recommended to disable the
SPI before disabling the clock, to avoid freezing the SPI in an undefined state.
21.6.3 Interrupts
The SPI interrupt request line is connected to the interrupt controller. Using the SPI interrupt
requires the interrupt controller to be programmed first.
21.7 Functional Description
21.7.1 Modes of Operation
The SPI operates in master mode or in slave mode.
Operation in master mode is configured by writing a one to the Master/Slave Mode bit in the
Mode Register (MR.MSTR). The pins NPCS0 to NPCS3 are all configured as outputs, the SPCK
pin is driven, the MISO line is wired on the receiver input and the MOSI line driven as an output
by the transmitter.
If the MR.MSTR bit is written to zero, the SPI operates in slave mode. The MISO line is driven by
the transmitter output, the MOSI line is wired on the receiver input, the SPCK pin is driven by the
transmitter to synchronize the receiver. The NPCS0 pin becomes an input, and is used as a
Slave Select signal (NSS). The pins NPCS1 to NPCS3 are not driven and can be used for other
purposes.
The data transfers are identically programmable for both modes of operations. The baud rate
generator is activated only in master mode.
Table 21-1. I/O Lines Description
Pin Name Pin Description
Type
Master Slave
MISO Master In Slave Out Input Output
MOSI Master Out Slave In Output Input
SPCK Serial Clock Output Input
NPCS1-NPCS3 Peripheral Chip Selects Output Unused
NPCS0/NSS Peripheral Chip Select/Slave Select Output Input
489
32142D–06/2013
ATUC64/128/256L3/4U
21.7.2 Data Transfer
Four combinations of polarity and phase are available for data transfers. The clock polarity is
configured with the Clock Polarity bit in the Chip Select Registers (CSRn.CPOL). The clock
phase is configured with the Clock Phase bit in the CSRn registers (CSRn.NCPHA). These two
bits determine the edges of the clock signal on which data is driven and sampled. Each of the
two bits has two possible states, resulting in four possible combinations that are incompatible
with one another. Thus, a master/slave pair must use the same parameter pair values to communicate.
If multiple slaves are used and fixed in different configurations, the master must
reconfigure itself each time it needs to communicate with a different slave.
Table 21-2 on page 489 shows the four modes and corresponding parameter settings.
Figure 21-3 on page 489 and Figure 21-4 on page 490 show examples of data transfers.
Figure 21-3. SPI Transfer Format (NCPHA = 1, 8 bits per transfer)
Table 21-2. SPI modes
SPI Mode CPOL NCPHA
0 01
1 00
2 11
3 10
SPCK cycle (for reference) 1 4 2 3 5 8 6 7
SPCK
(CPOL = 0)
NSS
(to slave)
MISO
(from slave)
MOSI
(from master)
SPCK
(CPOL = 1)
MSB 6 4 5 LSB 3 2 1
MSB 6 5 4 3 2 1 LSB ***
*** Not Defined, but normaly MSB of previous character received
490
32142D–06/2013
ATUC64/128/256L3/4U
Figure 21-4. SPI Transfer Format (NCPHA = 0, 8 bits per transfer)
21.7.3 Master Mode Operations
When configured in master mode, the SPI uses the internal programmable baud rate generator
as clock source. It fully controls the data transfers to and from the slave(s) connected to the SPI
bus. The SPI drives the chip select line to the slave and the serial clock signal (SPCK).
The SPI features two holding registers, the Transmit Data Register (TDR) and the Receive Data
Register (RDR), and a single Shift Register. The holding registers maintain the data flow at a
constant rate.
After enabling the SPI, a data transfer begins when the processor writes to the TDR register.
The written data is immediately transferred in the Shift Register and transfer on the SPI bus
starts. While the data in the Shift Register is shifted on the MOSI line, the MISO line is sampled
and shifted in the Shift Register. Transmission cannot occur without reception.
Before writing to the TDR, the Peripheral Chip Select field in TDR (TDR.PCS) must be written in
order to select a slave.
If new data is written to TDR during the transfer, it stays in it until the current transfer is completed.
Then, the received data is transferred from the Shift Register to RDR, the data in TDR is
loaded in the Shift Register and a new transfer starts.
The transfer of a data written in TDR in the Shift Register is indicated by the Transmit Data Register
Empty bit in the Status Register (SR.TDRE). When new data is written in TDR, this bit is
cleared. The SR.TDRE bit is used to trigger the Transmit Peripheral DMA Controller channel.
The end of transfer is indicated by the Transmission Registers Empty bit in the SR register
(SR.TXEMPTY). If a transfer delay (CSRn.DLYBCT) is greater than zero for the last transfer,
SR.TXEMPTY is set after the completion of said delay. The CLK_SPI can be switched off at this
time.
During reception, received data are transferred from the Shift Register to the reception FIFO.
The FIFO can contain up to 4 characters (both Receive Data and Peripheral Chip Select fields).
While a character of the FIFO is unread, the Receive Data Register Full bit in SR remains high
(SR.RDRF). Characters are read through the RDR register. If the four characters stored in the
FIFO are not read and if a new character is stored, this sets the Overrun Error Status bit in the
SR register (SR.OVRES). The procedure to follow in such a case is described in Section
21.7.3.8.
SPCK cycle (for reference) 1 4 2 3 5 8 6 7
SPCK
(CPOL = 0)
NSS
(to slave)
MISO
(from slave)
MOSI
(from master)
SPCK
(CPOL = 1)
MSB 6 4 5 LSB 3 2 1
6 5 4 3 2 1 LSB
*** Not Defined, but normaly LSB of previous character transmitted
*** MSB
491
32142D–06/2013
ATUC64/128/256L3/4U
Figure 21-5 on page 491shows a block diagram of the SPI when operating in master mode. Figure
21-6 on page 492 shows a flow chart describing how transfers are handled.
21.7.3.1 Master mode block diagram
Figure 21-5. Master Mode Block Diagram
Baud Rate Generator
RXFIFOEN
4 – Character FIFO
Shift Register
TDRE
RXFIFOEN
4 – Character FIFO
PS
PCSDEC
Current
Peripheral
MODF
MODFDIS
MSTR
SCBR
CSR0..3
CSR0..3
CPOL
NCPHA
BITS
RDR
RD
RDRF
OVRES
TD
TDR
RDR
CSAAT
CSNAAT
CSR0..3
PCS
MR
PCS
TDR
SPCK CLK_SPI
MISO MOSI LSB MSB
NPCS1
NPCS2
NPCS3
NPCS0
SPI
Clock
0
1
0
1
0
1
NPCS0
492
32142D–06/2013
ATUC64/128/256L3/4U
21.7.3.2 Master mode flow diagram
Figure 21-6. Master Mode Flow Diagram
SPI Enable
CSAAT ?
PS ?
1
0
0
1
1
NPCS = TDR(PCS) NPCS = MR(PCS)
Delay DLYBS
Serializer = TDR(TD)
TDRE = 1
Data Transfer
RDR(RD) = Serializer
RDRF = 1
TDRE ?
NPCS = 0xF
Delay DLYBCS
Fixed
peripheral
Variable
peripheral
Delay DLYBCT
0
1 CSAAT ?
0
TDRE ?
1
0
PS ?
0
1
TDR(PCS)
= NPCS ?
no
yes MR(PCS)
= NPCS ?
no
NPCS = 0xF
Delay DLYBCS
NPCS = TDR(PCS)
NPCS = 0xF
Delay DLYBCS
NPCS = MR(PCS),
TDR(PCS)
Fixed
peripheral
Variable
peripheral
- NPCS defines the current Chip Select
- CSAAT, DLYBS, DLYBCT refer to the fields of the
Chip Select Register corresponding to the Current Chip Select
- When NPCS is 0xF, CSAAT is 0.
493
32142D–06/2013
ATUC64/128/256L3/4U
21.7.3.3 Clock generation
The SPI Baud rate clock is generated by dividing the CLK_SPI , by a value between 1 and 255.
This allows a maximum operating baud rate at up to CLK_SPI and a minimum operating baud
rate of CLK_SPI divided by 255.
Writing the Serial Clock Baud Rate field in the CSRn registers (CSRn.SCBR) to zero is forbidden.
Triggering a transfer while CSRn.SCBR is zero can lead to unpredictable results.
At reset, CSRn.SCBR is zero and the user has to configure it at a valid value before performing
the first transfer.
The divisor can be defined independently for each chip select, as it has to be configured in the
CSRn.SCBR field. This allows the SPI to automatically adapt the baud rate for each interfaced
peripheral without reprogramming.
21.7.3.4 Transfer delays
Figure 21-7 on page 493 shows a chip select transfer change and consecutive transfers on the
same chip select. Three delays can be configured to modify the transfer waveforms:
• The delay between chip selects, programmable only once for all the chip selects by writing to
the Delay Between Chip Selects field in the MR register (MR.DLYBCS). Allows insertion of a
delay between release of one chip select and before assertion of a new one.
• The delay before SPCK, independently programmable for each chip select by writing the
Delay Before SPCK field in the CSRn registers (CSRn.DLYBS). Allows the start of SPCK to
be delayed after the chip select has been asserted.
• The delay between consecutive transfers, independently programmable for each chip select
by writing the Delay Between Consecutive Transfers field in the CSRn registers
(CSRn.DLYBCT). Allows insertion of a delay between two transfers occurring on the same
chip select
These delays allow the SPI to be adapted to the interfaced peripherals and their speed and bus
release time.
Figure 21-7. Programmable Delays
DLYBCS DLYBS DLYBCT DLYBCT
Chip Select 1
Chip Select 2
SPCK
494
32142D–06/2013
ATUC64/128/256L3/4U
21.7.3.5 Peripheral selection
The serial peripherals are selected through the assertion of the NPCS0 to NPCS3 signals. By
default, all the NPCS signals are high before and after each transfer.
The peripheral selection can be performed in two different ways:
• Fixed Peripheral Select: SPI exchanges data with only one peripheral
• Variable Peripheral Select: Data can be exchanged with more than one peripheral
Fixed Peripheral Select is activated by writing a zero to the Peripheral Select bit in MR (MR.PS).
In this case, the current peripheral is defined by the MR.PCS field and the TDR.PCS field has no
effect.
Variable Peripheral Select is activated by writing a one to the MR.PS bit . The TDR.PCS field is
used to select the current peripheral. This means that the peripheral selection can be defined for
each new data.
The Fixed Peripheral Selection allows buffer transfers with a single peripheral. Using the Peripheral
DMA Controller is an optimal means, as the size of the data transfer between the memory
and the SPI is either 4 bits or 16 bits. However, changing the peripheral selection requires the
Mode Register to be reprogrammed.
The Variable Peripheral Selection allows buffer transfers with multiple peripherals without reprogramming
the MR register. Data written to TDR is 32-bits wide and defines the real data to be
transmitted and the peripheral it is destined to. Using the Peripheral DMA Controller in this mode
requires 32-bit wide buffers, with the data in the LSBs and the PCS and LASTXFER fields in the
MSBs, however the SPI still controls the number of bits (8 to16) to be transferred through MISO
and MOSI lines with the CSRn registers. This is not the optimal means in term of memory size
for the buffers, but it provides a very effective means to exchange data with several peripherals
without any intervention of the processor.
21.7.3.6 Peripheral chip select decoding
The user can configure the SPI to operate with up to 15 peripherals by decoding the four Chip
Select lines, NPCS0 to NPCS3 with an external logic. This can be enabled by writing a one to
the Chip Select Decode bit in the MR register (MR.PCSDEC).
When operating without decoding, the SPI makes sure that in any case only one chip select line
is activated, i.e. driven low at a time. If two bits are defined low in a PCS field, only the lowest
numbered chip select is driven low.
When operating with decoding, the SPI directly outputs the value defined by the PCS field of
either the MR register or the TDR register (depending on PS).
As the SPI sets a default value of 0xF on the chip select lines (i.e. all chip select lines at one)
when not processing any transfer, only 15 peripherals can be decoded.
The SPI has only four Chip Select Registers, not 15. As a result, when decoding is activated,
each chip select defines the characteristics of up to four peripherals. As an example, the CRS0
register defines the characteristics of the externally decoded peripherals 0 to 3, corresponding to
the PCS values 0x0 to 0x3. Thus, the user has to make sure to connect compatible peripherals
on the decoded chip select lines 0 to 3, 4 to 7, 8 to 11 and 12 to 14.
21.7.3.7 Peripheral deselection
When operating normally, as soon as the transfer of the last data written in TDR is completed,
the NPCS lines all rise. This might lead to runtime error if the processor is too long in responding
495
32142D–06/2013
ATUC64/128/256L3/4U
to an interrupt, and thus might lead to difficulties for interfacing with some serial peripherals
requiring the chip select line to remain active during a full set of transfers.
To facilitate interfacing with such devices, the CSRn registers can be configured with the Chip
Select Active After Transfer bit written to one (CSRn.CSAAT) . This allows the chip select lines
to remain in their current state (low = active) until transfer to another peripheral is required.
When the CSRn.CSAAT bit is written to qero, the NPCS does not rise in all cases between two
transfers on the same peripheral. During a transfer on a Chip Select, the SR.TDRE bit rises as
soon as the content of the TDR is transferred into the internal shifter. When this bit is detected
the TDR can be reloaded. If this reload occurs before the end of the current transfer and if the
next transfer is performed on the same chip select as the current transfer, the Chip Select is not
de-asserted between the two transfers. This might lead to difficulties for interfacing with some
serial peripherals requiring the chip select to be de-asserted after each transfer. To facilitate
interfacing with such devices, the CSRn registers can be configured with the Chip Select Not
Active After Transfer bit (CSRn.CSNAAT) written to one. This allows to de-assert systematically
the chip select lines during a time DLYBCS. (The value of the CSRn.CSNAAT bit is taken into
account only if the CSRn.CSAAT bit is written to zero for the same Chip Select).
Figure 21-8 on page 496 shows different peripheral deselection cases and the effect of the
CSRn.CSAAT and CSRn.CSNAAT bits.
21.7.3.8 FIFO management
A FIFO has been implemented in Reception FIFO (both in master and in slave mode), in order to
be able to store up to 4 characters without causing an overrun error. If an attempt is made to
store a fifth character, an overrun error rises. If such an event occurs, the FIFO must be flushed.
There are two ways to Flush the FIFO:
• By performing four read accesses of the RDR (the data read must be ignored)
• By writing a one to the Flush Fifo Command bit in the CR register (CR.FLUSHFIFO).
After that, the SPI is able to receive new data.
496
32142D–06/2013
ATUC64/128/256L3/4U
Figure 21-8. Peripheral Deselection
Figure 21-8 on page 496 shows different peripheral deselection cases and the effect of the
CSRn.CSAAT and CSRn.CSNAAT bits.
21.7.3.9 Mode fault detection
The SPI is capable of detecting a mode fault when it is configured in master mode and NPCS0,
MOSI, MISO, and SPCK are configured as open drain through the I/O Controller with either
internal or external pullup resistors. If the I/O Controller does not have open-drain capability,
mode fault detection must be disabled by writing a one to the Mode Fault Detection bit in the MR
A
NPCS[0..3]
Write TDR
TDRE
NPCS[0..3]
Write TDR
TDRE
NPCS[0..3]
Write TDR
TDRE
DLYBCS
PCS = A
DLYBCS
DLYBCT
A
PCS = B
B
DLYBCS
PCS = A
DLYBCS
DLYBCT
A
PCS = B
B
DLYBCS
DLYBCT
PCS=A
A
DLYBCS
DLYBCT
A
PCS = A
A A
DLYBCT
A A
CSAAT = 0 and CSNAAT = 0
DLYBCT
A A
CSAAT = 1 and CSNAAT= 0 / 1
A
DLYBCS
PCS = A
DLYBCT
A A
CSAAT = 0 and CSNAAT = 1
NPCS[0..3]
Write TDR
TDRE
PCS = A
DLYBCT
A A
CSAAT = 0 and CSNAAT = 0
497
32142D–06/2013
ATUC64/128/256L3/4U
register (MR.MODFDIS). In systems with open-drain I/O lines, a mode fault is detected when a
low level is driven by an external master on the NPCS0/NSS signal.
When a mode fault is detected, the Mode Fault Error bit in the SR (SR.MODF) is set until the SR
is read and the SPI is automatically disabled until re-enabled by writing a one to the SPI Enable
bit in the CR register (CR.SPIEN).
By default, the mode fault detection circuitry is enabled. The user can disable mode fault detection
by writing a one to the Mode Fault Detection bit in the MR register (MR.MODFDIS).
21.7.4 SPI Slave Mode
When operating in slave mode, the SPI processes data bits on the clock provided on the SPI
clock pin (SPCK).
The SPI waits for NSS to go active before receiving the serial clock from an external master.
When NSS falls, the clock is validated on the serializer, which processes the number of bits
defined by the Bits Per Transfer field of the Chip Select Register 0 (CSR0.BITS). These bits are
processed following a phase and a polarity defined respectively by the CSR0.NCPHA and
CSR0.CPOL bits. Note that the BITS, CPOL, and NCPHA bits of the other Chip Select Registers
have no effect when the SPI is configured in Slave Mode.
The bits are shifted out on the MISO line and sampled on the MOSI line.
When all the bits are processed, the received data is transferred in the Receive Data Register
and the SR.RDRF bit rises. If the RDR register has not been read before new data is received,
the SR.OVRES bit is set. Data is loaded in RDR even if this flag is set. The user has to read the
SR register to clear the SR.OVRES bit.
When a transfer starts, the data shifted out is the data present in the Shift Register. If no data
has been written in the TDR register, the last data received is transferred. If no data has been
received since the last reset, all bits are transmitted low, as the Shift Register resets to zero.
When a first data is written in TDR, it is transferred immediately in the Shift Register and the
SR.TDRE bit rises. If new data is written, it remains in TDR until a transfer occurs, i.e. NSS falls
and there is a valid clock on the SPCK pin. When the transfer occurs, the last data written in
TDR is transferred in the Shift Register and the SR.TDRE bit rises. This enables frequent
updates of critical variables with single transfers.
Then, a new data is loaded in the Shift Register from the TDR. In case no character is ready to
be transmitted, i.e. no character has been written in TDR since the last load from TDR to the
Shift Register, the Shift Register is not modified and the last received character is retransmitted.
In this case the Underrun Error Status bit is set in SR (SR.UNDES).
Figure 21-9 on page 498 shows a block diagram of the SPI when operating in slave mode.
498
32142D–06/2013
ATUC64/128/256L3/4U
Figure 21-9. Slave Mode Functional Block Diagram
Shift Register
SPCK
SPIENS
LSB MSB
NSS
MOSI
SPI
Clock
TDRE
TDR
TD
RDRF
OVRES
CSR0
CPOL
NCPHA
BITS
SPIEN
SPIDIS
MISO
UNDES
RDR
RD
4 - Character FIFO
0
1
RXFIFOEN
499
32142D–06/2013
ATUC64/128/256L3/4U
21.8 User Interface
Note: 1. The reset values are device specific. Please refer to the Module Configuration section at the end of this chapter.
Table 21-3. SPI Register Memory Map
Offset Register Register Name Access Reset
0x00 Control Register CR Write-only 0x00000000
0x04 Mode Register MR Read/Write 0x00000000
0x08 Receive Data Register RDR Read-only 0x00000000
0x0C Transmit Data Register TDR Write-only 0x00000000
0x10 Status Register SR Read-only 0x00000000
0x14 Interrupt Enable Register IER Write-only 0x00000000
0x18 Interrupt Disable Register IDR Write-only 0x00000000
0x1C Interrupt Mask Register IMR Read-only 0x00000000
0x30 Chip Select Register 0 CSR0 Read/Write 0x00000000
0x34 Chip Select Register 1 CSR1 Read/Write 0x00000000
0x38 Chip Select Register 2 CSR2 Read/Write 0x00000000
0x3C Chip Select Register 3 CSR3 Read/Write 0x00000000
0x E4 Write Protection Control Register WPCR Read/Write 0X00000000
0xE8 Write Protection Status Register WPSR Read-only 0x00000000
0xF8 Features Register FEATURES Read-only - (1)
0xFC Version Register VERSION Read-only - (1)
500
32142D–06/2013
ATUC64/128/256L3/4U
21.8.1 Control Register
Name: CR
Access Type: Write-only
Offset: 0x00
Reset Value: 0x00000000
• LASTXFER: Last Transfer
1: The current NPCS will be deasserted after the character written in TD has been transferred. When CSRn.CSAAT is one, this
allows to close the communication with the current serial peripheral by raising the corresponding NPCS line as soon as TD
transfer has completed.
0: Writing a zero to this bit has no effect.
• FLUSHFIFO: Flush Fifo Command
1: If The FIFO Mode is enabled (MR.FIFOEN written to one) and if an overrun error has been detected, this command allows to
empty the FIFO.
0: Writing a zero to this bit has no effect.
• SWRST: SPI Software Reset
1: Writing a one to this bit will reset the SPI. A software-triggered hardware reset of the SPI interface is performed. The SPI is in
slave mode after software reset. Peripheral DMA Controller channels are not affected by software reset.
0: Writing a zero to this bit has no effect.
• SPIDIS: SPI Disable
1: Writing a one to this bit will disable the SPI. As soon as SPIDIS is written to one, the SPI finishes its transfer, all pins are set
in input mode and no data is received or transmitted. If a transfer is in progress, the transfer is finished before the SPI is
disabled. If both SPIEN and SPIDIS are equal to one when the CR register is written, the SPI is disabled.
0: Writing a zero to this bit has no effect.
• SPIEN: SPI Enable
1: Writing a one to this bit will enable the SPI to transfer and receive data.
0: Writing a zero to this bit has no effect.
31 30 29 28 27 26 25 24
- - - - - - - LASTXFER
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
- - - - - - - FLUSHFIFO
76543210
SWRST - - - - - SPIDIS SPIEN
501
32142D–06/2013
ATUC64/128/256L3/4U
21.8.2 Mode Register
Name: MR
Access Type: Read/Write
Offset: 0x04
Reset Value: 0x00000000
• DLYBCS: Delay Between Chip Selects
This field defines the delay from NPCS inactive to the activation of another NPCS. The DLYBCS time guarantees nonoverlapping
chip selects and solves bus contentions in case of peripherals having long data float times.
If DLYBCS is less than or equal to six, six CLK_SPI periods will be inserted by default.
Otherwise, the following equation determines the delay:
• PCS: Peripheral Chip Select
This field is only used if Fixed Peripheral Select is active (PS = 0).
If PCSDEC = 0:
PCS = xxx0NPCS[3:0] = 1110
PCS = xx01NPCS[3:0] = 1101
PCS = x011NPCS[3:0] = 1011
PCS = 0111NPCS[3:0] = 0111
PCS = 1111forbidden (no peripheral is selected)
(x = don’t care)
If PCSDEC = 1:
NPCS[3:0] output signals = PCS.
• LLB: Local Loopback Enable
1: Local loopback path enabled. LLB controls the local loopback on the data serializer for testing in master mode only (MISO is
internally connected on MOSI).
0: Local loopback path disabled.
• RXFIFOEN: FIFO in Reception Enable
1: The FIFO is used in reception (four characters can be stored in the SPI).
31 30 29 28 27 26 25 24
DLYBCS
23 22 21 20 19 18 17 16
- - - - PCS
15 14 13 12 11 10 9 8
--------
76543210
LLB RXFIFOEN - MODFDIS - PCSDEC PS MSTR
Delay Between Chip Selects DLYBCS
CLKSPI = -----------------------
502
32142D–06/2013
ATUC64/128/256L3/4U
0: The FIFO is not used in reception (only one character can be stored in the SPI).
• MODFDIS: Mode Fault Detection
1: Mode fault detection is disabled. If the I/O controller does not have open-drain capability, mode fault detection must be
disabled for proper operation of the SPI.
0: Mode fault detection is enabled.
• PCSDEC: Chip Select Decode
0: The chip selects are directly connected to a peripheral device.
1: The four chip select lines are connected to a 4- to 16-bit decoder.
When PCSDEC equals one, up to 15 Chip Select signals can be generated with the four lines using an external 4- to 16-bit
decoder. The CSRn registers define the characteristics of the 15 chip selects according to the following rules:
CSR0 defines peripheral chip select signals 0 to 3.
CSR1 defines peripheral chip select signals 4 to 7.
CSR2 defines peripheral chip select signals 8 to 11.
CSR3 defines peripheral chip select signals 12 to 14.
• PS: Peripheral Select
1: Variable Peripheral Select.
0: Fixed Peripheral Select.
• MSTR: Master/Slave Mode
1: SPI is in master mode.
0: SPI is in slave mode.
503
32142D–06/2013
ATUC64/128/256L3/4U
21.8.3 Receive Data Register
Name: RDR
Access Type: Read-only
Offset: 0x08
Reset Value: 0x00000000
• RD: Receive Data
Data received by the SPI Interface is stored in this register right-justified. Unused bits read zero.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
RD[15:8]
76543210
RD[7:0]
504
32142D–06/2013
ATUC64/128/256L3/4U
21.8.4 Transmit Data Register
Name: TDR
Access Type: Write-only
Offset: 0x0C
Reset Value: 0x00000000
• LASTXFER: Last Transfer
1: The current NPCS will be deasserted after the character written in TD has been transferred. When CSRn.CSAAT is one, this
allows to close the communication with the current serial peripheral by raising the corresponding NPCS line as soon as TD
transfer has completed.
0: Writing a zero to this bit has no effect.
This field is only used if Variable Peripheral Select is active (MR.PS = 1).
• PCS: Peripheral Chip Select
If PCSDEC = 0:
PCS = xxx0NPCS[3:0] = 1110
PCS = xx01NPCS[3:0] = 1101
PCS = x011NPCS[3:0] = 1011
PCS = 0111NPCS[3:0] = 0111
PCS = 1111forbidden (no peripheral is selected)
(x = don’t care)
If PCSDEC = 1:
NPCS[3:0] output signals = PCS
This field is only used if Variable Peripheral Select is active (MR.PS = 1).
• TD: Transmit Data
Data to be transmitted by the SPI Interface is stored in this register. Information to be transmitted must be written to the TDR
register in a right-justified format.
31 30 29 28 27 26 25 24
- - - - - - - LASTXFER
23 22 21 20 19 18 17 16
- - - - PCS
15 14 13 12 11 10 9 8
TD[15:8]
76543210
TD[7:0]
505
32142D–06/2013
ATUC64/128/256L3/4U
21.8.5 Status Register
Name: SR
Access Type: Read-only
Offset: 0x10
Reset Value: 0x00000000
• SPIENS: SPI Enable Status
1: This bit is set when the SPI is enabled.
0: This bit is cleared when the SPI is disabled.
• UNDES: Underrun Error Status (Slave Mode Only)
1: This bit is set when a transfer begins whereas no data has been loaded in the TDR register.
0: This bit is cleared when the SR register is read.
• TXEMPTY: Transmission Registers Empty
1: This bit is set when TDR and internal shifter are empty. If a transfer delay has been defined, TXEMPTY is set after the
completion of such delay.
0: This bit is cleared as soon as data is written in TDR.
• NSSR: NSS Rising
1: A rising edge occurred on NSS pin since last read.
0: This bit is cleared when the SR register is read.
• OVRES: Overrun Error Status
1: This bit is set when an overrun has occurred. An overrun occurs when RDR is loaded at least twice from the serializer since
the last read of the RDR.
0: This bit is cleared when the SR register is read.
• MODF: Mode Fault Error
1: This bit is set when a Mode Fault occurred.
0: This bit is cleared when the SR register is read.
• TDRE: Transmit Data Register Empty
1: This bit is set when the last data written in the TDR register has been transferred to the serializer.
0: This bit is cleared when data has been written to TDR and not yet transferred to the serializer.
TDRE equals zero when the SPI is disabled or at reset. The SPI enable command sets this bit to one.
• RDRF: Receive Data Register Full
1: Data has been received and the received data has been transferred from the serializer to RDR since the last read of RDR.
0: No data has been received since the last read of RDR
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
- - - - - - - SPIENS
15 14 13 12 11 10 9 8
- - - - - UNDES TXEMPTY NSSR
76543210
- - - - OVRES MODF TDRE RDRF
506
32142D–06/2013
ATUC64/128/256L3/4U
21.8.6 Interrupt Enable Register
Name: IER
Access Type: Write-only
Offset: 0x14
Reset Value: 0x00000000
Writing a zero to a bit in this register has no effect.
Writing a one to a bit in this register will set the corresponding bit in IMR.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
- - - - - UNDES TXEMPTY NSSR
76543210
- - - - OVRES MODF TDRE RDRF
507
32142D–06/2013
ATUC64/128/256L3/4U
21.8.7 Interrupt Disable Register
Name: IDR
Access Type: Write-only
Offset: 0x18
Reset Value: 0x00000000
Writing a zero to a bit in this register has no effect.
Writing a one to a bit in this register will clear the corresponding bit in IMR.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
- - - - - UNDES TXEMPTY NSSR
76543210
- - - - OVRES MODF TDRE RDRF
508
32142D–06/2013
ATUC64/128/256L3/4U
21.8.8 Interrupt Mask Register
Name: IMR
Access Type: Read-only
Offset: 0x1C
Reset Value: 0x00000000
0: The corresponding interrupt is disabled.
1: The corresponding interrupt is enabled.
A bit in this register is cleared when the corresponding bit in IDR is written to one.
A bit in this register is set when the corresponding bit in IER is written to one.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
- - - - - UNDES TXEMPTY NSSR
76543210
- - - - OVRES MODF TDRE RDRF
509
32142D–06/2013
ATUC64/128/256L3/4U
21.8.9 Chip Select Register 0
Name: CSR0
Access Type: Read/Write
Offset: 0x30
Reset Value: 0x00000000
• DLYBCT: Delay Between Consecutive Transfers
This field defines the delay between two consecutive transfers with the same peripheral without removing the chip select. The
delay is always inserted after each transfer and before removing the chip select if needed.
When DLYBCT equals zero, no delay between consecutive transfers is inserted and the clock keeps its duty cycle over the
character transfers.
Otherwise, the following equation determines the delay:
• DLYBS: Delay Before SPCK
This field defines the delay from NPCS valid to the first valid SPCK transition.
When DLYBS equals zero, the NPCS valid to SPCK transition is 1/2 the SPCK clock period.
Otherwise, the following equations determine the delay:
• SCBR: Serial Clock Baud Rate
In Master Mode, the SPI Interface uses a modulus counter to derive the SPCK baud rate from the CLK_SPI. The Baud rate is
selected by writing a value from 1 to 255 in the SCBR field. The following equations determine the SPCK baud rate:
Writing the SCBR field to zero is forbidden. Triggering a transfer while SCBR is zero can lead to unpredictable results.
At reset, SCBR is zero and the user has to write it to a valid value before performing the first transfer.
If a clock divider (SCBRn) field is set to one and the other SCBR fields differ from one, access on CSn is correct but no correct
access will be possible on other CS.
31 30 29 28 27 26 25 24
DLYBCT
23 22 21 20 19 18 17 16
DLYBS
15 14 13 12 11 10 9 8
SCBR
76543210
BITS CSAAT CSNAAT NCPHA CPOL
Delay Between Consecutive Transfers 32 DLYBCT
CLKSPI = ------------------------------------
Delay Before SPCK DLYBS
CLKSPI = ---------------------
SPCK Baudrate CLKSPI
SCBR = ---------------------
510
32142D–06/2013
ATUC64/128/256L3/4U
• BITS: Bits Per Transfer
The BITS field determines the number of data bits transferred. Reserved values should not be used.
• CSAAT: Chip Select Active After Transfer
1: The Peripheral Chip Select does not rise after the last transfer is achieved. It remains active until a new transfer is requested
on a different chip select.
0: The Peripheral Chip Select Line rises as soon as the last transfer is achieved.
• CSNAAT: Chip Select Not Active After Transfer (Ignored if CSAAT = 1)
0: The Peripheral Chip Select does not rise between two transfers if the TDR is reloaded before the end of the first transfer and
if the two transfers occur on the same Chip Select.
1: The Peripheral Chip Select rises systematically between each transfer performed on the same slave for a minimal duration of:
(if DLYBCT field is different from 0)
(if DLYBCT field equals 0)
• NCPHA: Clock Phase
1: Data is captured after the leading (inactive-to-active) edge of SPCK and changed on the trailing (active-to-inactive) edge of
SPCK.
0: Data is changed on the leading (inactive-to-active) edge of SPCK and captured after the trailing (active-to-inactive) edge of
SPCK.
NCPHA determines which edge of SPCK causes data to change and which edge causes data to be captured. NCPHA is used
with CPOL to produce the required clock/data relationship between master and slave devices.
• CPOL: Clock Polarity
1: The inactive state value of SPCK is logic level one.
0: The inactive state value of SPCK is logic level zero.
BITS Bits Per Transfer
0000 8
0001 9
0010 10
0011 11
0100 12
0101 13
0110 14
0111 15
1000 16
1001 4
1010 5
1011 6
1100 7
1101 Reserved
1110 Reserved
1111 Reserved
DLYBCS
CLKSPI
-----------------------
DLYBCS + 1
CLKSPI
--------------------------------
511
32142D–06/2013
ATUC64/128/256L3/4U
CPOL is used to determine the inactive state value of the serial clock (SPCK). It is used with NCPHA to produce the required
clock/data relationship between master and slave devices.
512
32142D–06/2013
ATUC64/128/256L3/4U
21.8.10 Chip Select Register 1
Name: CSR1
Access Type: Read/Write
Offset: 0x34
Reset Value: 0x00000000
• DLYBCT: Delay Between Consecutive Transfers
This field defines the delay between two consecutive transfers with the same peripheral without removing the chip select. The
delay is always inserted after each transfer and before removing the chip select if needed.
When DLYBCT equals zero, no delay between consecutive transfers is inserted and the clock keeps its duty cycle over the
character transfers.
Otherwise, the following equation determines the delay:
• DLYBS: Delay Before SPCK
This field defines the delay from NPCS valid to the first valid SPCK transition.
When DLYBS equals zero, the NPCS valid to SPCK transition is 1/2 the SPCK clock period.
Otherwise, the following equations determine the delay:
• SCBR: Serial Clock Baud Rate
In Master Mode, the SPI Interface uses a modulus counter to derive the SPCK baud rate from the CLK_SPI. The Baud rate is
selected by writing a value from 1 to 255 in the SCBR field. The following equations determine the SPCK baud rate:
Writing the SCBR field to zero is forbidden. Triggering a transfer while SCBR is zero can lead to unpredictable results.
At reset, SCBR is zero and the user has to write it to a valid value before performing the first transfer.
If a clock divider (SCBRn) field is set to one and the other SCBR fields differ from one, access on CSn is correct but no correct
access will be possible on other CS.
31 30 29 28 27 26 25 24
DLYBCT
23 22 21 20 19 18 17 16
DLYBS
15 14 13 12 11 10 9 8
SCBR
76543210
BITS CSAAT CSNAAT NCPHA CPOL
Delay Between Consecutive Transfers 32 DLYBCT
CLKSPI = ------------------------------------
Delay Before SPCK DLYBS
CLKSPI = ---------------------
SPCK Baudrate CLKSPI
SCBR = ---------------------
513
32142D–06/2013
ATUC64/128/256L3/4U
• BITS: Bits Per Transfer
The BITS field determines the number of data bits transferred. Reserved values should not be used.
• CSAAT: Chip Select Active After Transfer
1: The Peripheral Chip Select does not rise after the last transfer is achieved. It remains active until a new transfer is requested
on a different chip select.
0: The Peripheral Chip Select Line rises as soon as the last transfer is achieved.
• CSNAAT: Chip Select Not Active After Transfer (Ignored if CSAAT = 1)
0: The Peripheral Chip Select does not rise between two transfers if the TDR is reloaded before the end of the first transfer and
if the two transfers occur on the same Chip Select.
1: The Peripheral Chip Select rises systematically between each transfer performed on the same slave for a minimal duration of:
(if DLYBCT field is different from 0)
(if DLYBCT field equals 0)
• NCPHA: Clock Phase
1: Data is captured after the leading (inactive-to-active) edge of SPCK and changed on the trailing (active-to-inactive) edge of
SPCK.
0: Data is changed on the leading (inactive-to-active) edge of SPCK and captured after the trailing (active-to-inactive) edge of
SPCK.
NCPHA determines which edge of SPCK causes data to change and which edge causes data to be captured. NCPHA is used
with CPOL to produce the required clock/data relationship between master and slave devices.
• CPOL: Clock Polarity
1: The inactive state value of SPCK is logic level one.
0: The inactive state value of SPCK is logic level zero.
BITS Bits Per Transfer
0000 8
0001 9
0010 10
0011 11
0100 12
0101 13
0110 14
0111 15
1000 16
1001 4
1010 5
1011 6
1100 7
1101 Reserved
1110 Reserved
1111 Reserved
DLYBCS
CLKSPI
-----------------------
DLYBCS + 1
CLKSPI
--------------------------------
514
32142D–06/2013
ATUC64/128/256L3/4U
CPOL is used to determine the inactive state value of the serial clock (SPCK). It is used with NCPHA to produce the required
clock/data relationship between master and slave devices.
515
32142D–06/2013
ATUC64/128/256L3/4U
21.8.11 Chip Select Register 2
Name: CSR2
Access Type: Read/Write
Offset: 0x38
Reset Value: 0x00000000
• DLYBCT: Delay Between Consecutive Transfers
This field defines the delay between two consecutive transfers with the same peripheral without removing the chip select. The
delay is always inserted after each transfer and before removing the chip select if needed.
When DLYBCT equals zero, no delay between consecutive transfers is inserted and the clock keeps its duty cycle over the
character transfers.
Otherwise, the following equation determines the delay:
• DLYBS: Delay Before SPCK
This field defines the delay from NPCS valid to the first valid SPCK transition.
When DLYBS equals zero, the NPCS valid to SPCK transition is 1/2 the SPCK clock period.
Otherwise, the following equations determine the delay:
• SCBR: Serial Clock Baud Rate
In Master Mode, the SPI Interface uses a modulus counter to derive the SPCK baud rate from the CLK_SPI. The Baud rate is
selected by writing a value from 1 to 255 in the SCBR field. The following equations determine the SPCK baud rate:
Writing the SCBR field to zero is forbidden. Triggering a transfer while SCBR is zero can lead to unpredictable results.
At reset, SCBR is zero and the user has to write it to a valid value before performing the first transfer.
If a clock divider (SCBRn) field is set to one and the other SCBR fields differ from one, access on CSn is correct but no correct
access will be possible on other CS.
31 30 29 28 27 26 25 24
DLYBCT
23 22 21 20 19 18 17 16
DLYBS
15 14 13 12 11 10 9 8
SCBR
76543210
BITS CSAAT CSNAAT NCPHA CPOL
Delay Between Consecutive Transfers 32 DLYBCT
CLKSPI = ------------------------------------
Delay Before SPCK DLYBS
CLKSPI = ---------------------
SPCK Baudrate CLKSPI
SCBR = ---------------------
516
32142D–06/2013
ATUC64/128/256L3/4U
• BITS: Bits Per Transfer
The BITS field determines the number of data bits transferred. Reserved values should not be used.
• CSAAT: Chip Select Active After Transfer
1: The Peripheral Chip Select does not rise after the last transfer is achieved. It remains active until a new transfer is requested
on a different chip select.
0: The Peripheral Chip Select Line rises as soon as the last transfer is achieved.
• CSNAAT: Chip Select Not Active After Transfer (Ignored if CSAAT = 1)
0: The Peripheral Chip Select does not rise between two transfers if the TDR is reloaded before the end of the first transfer and
if the two transfers occur on the same Chip Select.
1: The Peripheral Chip Select rises systematically between each transfer performed on the same slave for a minimal duration of:
(if DLYBCT field is different from 0)
(if DLYBCT field equals 0)
• NCPHA: Clock Phase
1: Data is captured after the leading (inactive-to-active) edge of SPCK and changed on the trailing (active-to-inactive) edge of
SPCK.
0: Data is changed on the leading (inactive-to-active) edge of SPCK and captured after the trailing (active-to-inactive) edge of
SPCK.
NCPHA determines which edge of SPCK causes data to change and which edge causes data to be captured. NCPHA is used
with CPOL to produce the required clock/data relationship between master and slave devices.
• CPOL: Clock Polarity
1: The inactive state value of SPCK is logic level one.
0: The inactive state value of SPCK is logic level zero.
BITS Bits Per Transfer
0000 8
0001 9
0010 10
0011 11
0100 12
0101 13
0110 14
0111 15
1000 16
1001 4
1010 5
1011 6
1100 7
1101 Reserved
1110 Reserved
1111 Reserved
DLYBCS
CLKSPI
-----------------------
DLYBCS + 1
CLKSPI
--------------------------------
517
32142D–06/2013
ATUC64/128/256L3/4U
CPOL is used to determine the inactive state value of the serial clock (SPCK). It is used with NCPHA to produce the required
clock/data relationship between master and slave devices.
518
32142D–06/2013
ATUC64/128/256L3/4U
21.8.12 Chip Select Register 3
Name: CSR3
Access Type: Read/Write
Offset: 0x3C
Reset Value: 0x00000000
• DLYBCT: Delay Between Consecutive Transfers
This field defines the delay between two consecutive transfers with the same peripheral without removing the chip select. The
delay is always inserted after each transfer and before removing the chip select if needed.
When DLYBCT equals zero, no delay between consecutive transfers is inserted and the clock keeps its duty cycle over the
character transfers.
Otherwise, the following equation determines the delay:
• DLYBS: Delay Before SPCK
This field defines the delay from NPCS valid to the first valid SPCK transition.
When DLYBS equals zero, the NPCS valid to SPCK transition is 1/2 the SPCK clock period.
Otherwise, the following equations determine the delay:
• SCBR: Serial Clock Baud Rate
In Master Mode, the SPI Interface uses a modulus counter to derive the SPCK baud rate from the CLK_SPI. The Baud rate is
selected by writing a value from 1 to 255 in the SCBR field. The following equations determine the SPCK baud rate:
Writing the SCBR field to zero is forbidden. Triggering a transfer while SCBR is zero can lead to unpredictable results.
At reset, SCBR is zero and the user has to write it to a valid value before performing the first transfer.
If a clock divider (SCBRn) field is set to one and the other SCBR fields differ from one, access on CSn is correct but no correct
access will be possible on other CS.
31 30 29 28 27 26 25 24
DLYBCT
23 22 21 20 19 18 17 16
DLYBS
15 14 13 12 11 10 9 8
SCBR
76543210
BITS CSAAT CSNAAT NCPHA CPOL
Delay Between Consecutive Transfers 32 DLYBCT
CLKSPI = ------------------------------------
Delay Before SPCK DLYBS
CLKSPI = ---------------------
SPCK Baudrate CLKSPI
SCBR = ---------------------
519
32142D–06/2013
ATUC64/128/256L3/4U
• BITS: Bits Per Transfer
The BITS field determines the number of data bits transferred. Reserved values should not be used.
• CSAAT: Chip Select Active After Transfer
1: The Peripheral Chip Select does not rise after the last transfer is achieved. It remains active until a new transfer is requested
on a different chip select.
0: The Peripheral Chip Select Line rises as soon as the last transfer is achieved.
• CSNAAT: Chip Select Not Active After Transfer (Ignored if CSAAT = 1)
0: The Peripheral Chip Select does not rise between two transfers if the TDR is reloaded before the end of the first transfer and
if the two transfers occur on the same Chip Select.
1: The Peripheral Chip Select rises systematically between each transfer performed on the same slave for a minimal duration of:
(if DLYBCT field is different from 0)
(if DLYBCT field equals 0)
• NCPHA: Clock Phase
1: Data is captured after the leading (inactive-to-active) edge of SPCK and changed on the trailing (active-to-inactive) edge of
SPCK.
0: Data is changed on the leading (inactive-to-active) edge of SPCK and captured after the trailing (active-to-inactive) edge of
SPCK.
NCPHA determines which edge of SPCK causes data to change and which edge causes data to be captured. NCPHA is used
with CPOL to produce the required clock/data relationship between master and slave devices.
• CPOL: Clock Polarity
1: The inactive state value of SPCK is logic level one.
0: The inactive state value of SPCK is logic level zero.
BITS Bits Per Transfer
0000 8
0001 9
0010 10
0011 11
0100 12
0101 13
0110 14
0111 15
1000 16
1001 4
1010 5
1011 6
1100 7
1101 Reserved
1110 Reserved
1111 Reserved
DLYBCS
CLKSPI
-----------------------
DLYBCS + 1
CLKSPI
--------------------------------
520
32142D–06/2013
ATUC64/128/256L3/4U
CPOL is used to determine the inactive state value of the serial clock (SPCK). It is used with NCPHA to produce the required
clock/data relationship between master and slave devices.
521
32142D–06/2013
ATUC64/128/256L3/4U
21.8.13 Write Protection Control Register
Register Name: WPCR
Access Type: Read-write
Offset: 0xE4
Reset Value: 0x00000000
• SPIWPKEY: SPI Write Protection Key Password
If a value is written in SPIWPEN, the value is taken into account only if SPIWPKEY is written with “SPI” (SPI written in ASCII
Code, i.e. 0x535049 in hexadecimal).
• SPIWPEN: SPI Write Protection Enable
1: The Write Protection is Enabled
0: The Write Protection is Disabled
31 30 29 28 27 26 25 24
SPIWPKEY[23:16]
23 22 21 20 19 18 17 16
SPIWPKEY[15:8]
15 14 13 12 11 10 9 8
SPIWPKEY[7:0]
76543210
- - - - - - - SPIWPEN
522
32142D–06/2013
ATUC64/128/256L3/4U
21.8.14 Write Protection Status Register
Register Name: WPSR
Access Type: Read-only
Offset: 0xE8
Reset Value: 0x00000000
• SPIWPVSRC: SPI Write Protection Violation Source
This Field indicates the Peripheral Bus Offset of the register concerned by the violation (MR or CSRx)
• SPIWPVS: SPI Write Protection Violation Status
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
SPIWPVSRC
76543210
- - - - - SPIWPVS
SPIWPVS value Violation Type
1 The Write Protection has blocked a Write access to a protected register (since the last read).
2 Software Reset has been performed while Write Protection was enabled (since the last read
or since the last write access on MR, IER, IDR or CSRx).
3 Both Write Protection violation and software reset with Write Protection enabled have
occurred since the last read.
4 Write accesses have been detected on MR (while a chip select was active) or on CSRi (while
the Chip Select “i” was active) since the last read.
5
The Write Protection has blocked a Write access to a protected register and write accesses
have been detected on MR (while a chip select was active) or on CSRi (while the Chip Select
“i” was active) since the last read.
6
Software Reset has been performed while Write Protection was enabled (since the last read
or since the last write access on MR, IER, IDR or CSRx) and some write accesses have been
detected on MR (while a chip select was active) or on CSRi (while the Chip Select “i” was
active) since the last read.
7
- The Write Protection has blocked a Write access to a protected register.
and
- Software Reset has been performed while Write Protection was enabled.
and
- Write accesses have been detected on MR (while a chip select was active) or on CSRi
(while the Chip Select “i” was active) since the last read.
523
32142D–06/2013
ATUC64/128/256L3/4U
21.8.15 Features Register
Register Name: FEATURES
Access Type: Read-only
Offset: 0xF8
Reset Value: –
• SWIMPL: Spurious Write Protection Implemented
0: Spurious write protection is not implemented.
1: Spurious write protection is implemented.
• FIFORIMPL: FIFO in Reception Implemented
0: FIFO in reception is not implemented.
1: FIFO in reception is implemented.
• BRPBHSB: Bridge Type is PB to HSB
0: Bridge type is not PB to HSB.
1: Bridge type is PB to HSB.
• CSNAATIMPL: CSNAAT Features Implemented
0: CSNAAT (Chip select not active after transfer) features are not implemented.
1: CSNAAT features are implemented.
• EXTDEC: External Decoder True
0: External decoder capability is not implemented.
1: External decoder capability is implemented.
• LENNCONF: Character Length if not Configurable
If the character length is not configurable, this field specifies the fixed character length.
• LENCONF: Character Length Configurable
0: The character length is not configurable.
1: The character length is configurable.
• PHZNCONF: Phase is Zero if Phase not Configurable
0: If phase is not configurable, phase is non-zero.
1: If phase is not configurable, phase is zero.
• PHCONF: Phase Configurable
0: Phase is not configurable.
1: Phase is configurable.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
- - - SWIMPL FIFORIMPL BRPBHSB CSNAATIMPL EXTDEC
15 14 13 12 11 10 9 8
LENNCONF LENCONF
76543210
PHZNCONF PHCONF PPNCONF PCONF NCS
524
32142D–06/2013
ATUC64/128/256L3/4U
• PPNCONF: Polarity Positive if Polarity not Configurable
0: If polarity is not configurable, polarity is negative.
1: If polarity is not configurable, polarity is positive.
• PCONF: Polarity Configurable
0: Polarity is not configurable.
1: Polarity is configurable.
• NCS: Number of Chip Selects
This field indicates the number of chip selects implemented.
525
32142D–06/2013
ATUC64/128/256L3/4U
21.8.16 Version Register
Register Name: VERSION
Access Type: Read-only
Offset: 0xFC
Reset Value: –
• MFN
Reserved. No functionality associated.
• VERSION
Version number of the module. No functionality associated.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
- - - - MFN
15 14 13 12 11 10 9 8
VERSION[11:8]
76543210
VERSION[7:0]
526
32142D–06/2013
ATUC64/128/256L3/4U
21.9 Module Configuration
The specific configuration for each SPI instance is listed in the following tables.The module bus
clocks listed here are connected to the system bus clocks. Please refer to the Power Manager
chapter for details.
Table 21-4. SPI Clock Name
Module Name Clock Name Description
SPI CLK_SPI Clock for the SPI bus interface
Table 21-5.
Register Reset Value
FEATURES 0x001F0154
VERSION 0x00000211
527
32142D–06/2013
ATUC64/128/256L3/4U
22. Two-wire Master Interface (TWIM)
Rev.: 1.1.0.1
22.1 Features
• Compatible with I²C standard
– Multi-master support
– Transfer speeds of 100 and 400 kbit/s
– 7- and 10-bit and General Call addressing
• Compatible with SMBus standard
– Hardware Packet Error Checking (CRC) generation and verification with ACK control
– SMBus ALERT interface
– 25 ms clock low timeout delay
– 10 ms master cumulative clock low extend time
– 25 ms slave cumulative clock low extend time
• Compatible with PMBus
• Compatible with Atmel Two-wire Interface Serial Memories
• DMA interface for reducing CPU load
• Arbitrary transfer lengths, including 0 data bytes
• Optional clock stretching if transmit or receive buffers not ready for data transfer
22.2 Overview
The Atmel Two-wire Master Interface (TWIM) interconnects components on a unique two-wire
bus, made up of one clock line and one data line with speeds of up to 400 kbit/s, based on a
byte-oriented transfer format. It can be used with any Atmel Two-wire Interface bus serial
EEPROM and I²C compatible device such as a real time clock (RTC), dot matrix/graphic LCD
controller, and temperature sensor, to name a few. The TWIM is always a bus master and can
transfer sequential or single bytes. Multiple master capability is supported. Arbitration of the bus
is performed internally and relinquishes the bus automatically if the bus arbitration is lost.
A configurable baud rate generator permits the output data rate to be adapted to a wide range of
core clock frequencies.Table 22-1 lists the compatibility level of the Atmel Two-wire Interface in
Master Mode and a full I²C compatible device.
Note: 1. START + b000000001 + Ack + Sr
Table 22-1. Atmel TWIM Compatibility with I²C Standard
I²C Standard Atmel TWIM
Standard-mode (100 kbit/s) Supported
Fast-mode (400 kbit/s) Supported
Fast-mode Plus (1 Mbit/s) Supported
7- or 10-bits Slave Addressing Supported
START BYTE(1) Not Supported
Repeated Start (Sr) Condition Supported
ACK and NACK Management Supported
Slope Control and Input Filtering (Fast mode) Supported
Clock Stretching Supported
528
32142D–06/2013
ATUC64/128/256L3/4U
Table 22-2 lists the compatibility level of the Atmel Two-wire Master Interface and a full SMBus
compatible master.
22.3 List of Abbreviations
22.4 Block Diagram
Figure 22-1. Block Diagram
Table 22-2. Atmel TWIM Compatibility with SMBus Standard
SMBus Standard Atmel TWIM
Bus Timeouts Supported
Address Resolution Protocol Supported
Alert Supported
Host Functionality Supported
Packet Error Checking Supported
Table 22-3. Abbreviations
Abbreviation Description
TWI Two-wire Interface
A Acknowledge
NA Non Acknowledge
P Stop
S Start
Sr Repeated Start
SADR Slave Address
ADR Any address except SADR
R Read
W Write
Peripheral
Bus Bridge
Two-wire
Interface
I/O Controller
TWCK
TWD
INTC
TWI Interrupt
Power
Manager
CLK_TWIM
TWALM
529
32142D–06/2013
ATUC64/128/256L3/4U
22.5 Application Block Diagram
Figure 22-2. Application Block Diagram
22.6 I/O Lines Description
22.7 Product Dependencies
In order to use this module, other parts of the system must be configured correctly, as described
below.
22.7.1 I/O Lines
TWD and TWCK are bidirectional lines, connected to a positive supply voltage via a current
source or pull-up resistor (see Figure 22-4 on page 531). When the bus is free, both lines are
high. The output stages of devices connected to the bus must have an open-drain or open-collector
to perform the wired-AND function.
TWALM is used to implement the optional SMBus SMBALERT signal.
The TWALM, TWD, and TWCK pins may be multiplexed with I/O Controller lines. To enable the
TWIM, the user must perform the following steps:
• Program the I/O Controller to:
– Dedicate TWD, TWCK, and optionally TWALM as peripheral lines.
– Define TWD, TWCK, and optionally TWALM as open-drain.
22.7.2 Power Management
If the CPU enters a sleep mode that disables clocks used by the TWIM, the TWIM will stop functioning
and resume operation after the system wakes up from sleep mode.
TWI
Master
TWD
TWCK
Atmel TWI
serial EEPROM I
2
C RTC I
2
C LCD
controller
I
2
C temp
sensor
Slave 2 Slave 3 Slave 4
VDD
Rp: pull-up value as given by the I2C Standard
TWALM
Slave 1
Rp Rp Rp
Table 22-4. I/O Lines Description
Pin Name Pin Description Type
TWD Two-wire Serial Data Input/Output
TWCK Two-wire Serial Clock Input/Output
TWALM SMBus SMBALERT Input/Output
530
32142D–06/2013
ATUC64/128/256L3/4U
22.7.3 Clocks
The clock for the TWIM bus interface (CLK_TWIM) is generated by the Power Manager. This
clock is enabled at reset, and can be disabled in the Power Manager. It is recommended to disable
the TWIM before disabling the clock, to avoid freezing the TWIM in an undefined state.
22.7.4 DMA
The TWIM DMA handshake interface is connected to the Peripheral DMA Controller. Using the
TWIM DMA functionality requires the Peripheral DMA Controller to be programmed after setting
up the TWIM.
22.7.5 Interrupts
The TWIM interrupt request lines are connected to the interrupt controller. Using the TWIM interrupts
requires the interrupt controller to be programmed first.
22.7.6 Debug Operation
When an external debugger forces the CPU into debug mode, the TWIM continues normal operation.
If the TWIM is configured in a way that requires it to be periodically serviced by the CPU
through interrupts or similar, improper operation or data loss may result during debugging.
531
32142D–06/2013
ATUC64/128/256L3/4U
22.8 Functional Description
22.8.1 Transfer Format
The data put on the TWD line must be 8 bits long. Data is transferred MSB first; each byte must
be followed by an acknowledgement. The number of bytes per transfer is unlimited (see Figure
22-4).
Each transfer begins with a START condition and terminates with a STOP condition (see Figure
22-4).
• A high-to-low transition on the TWD line while TWCK is high defines the START condition.
• A low-to-high transition on the TWD line while TWCK is high defines a STOP condition.
Figure 22-3. START and STOP Conditions
Figure 22-4. Transfer Format
22.8.2 Operation
The TWIM has two modes of operation:
• Master transmitter mode
• Master receiver mode
The master is the device which starts and stops a transfer and generates the TWCK clock.
These modes are described in the following chapters.
TWD
TWCK
Start Stop
TWD
TWCK
Start Address R/W Ack Data Ack Data Ack Stop
532
32142D–06/2013
ATUC64/128/256L3/4U
22.8.2.1 Clock Generation
The Clock Waveform Generator Register (CWGR) is used to control the waveform of the TWCK
clock. CWGR must be written so that the desired TWI bus timings are generated. CWGR
describes bus timings as a function of cycles of a prescaled clock. The clock prescaling can be
selected through the Clock Prescaler field in CWGR (CWGR.EXP).
CWGR has the following fields:
LOW: Prescaled clock cycles in clock low count. Used to time TLOW and TBUF.
HIGH: Prescaled clock cycles in clock high count. Used to time THIGH.
STASTO: Prescaled clock cycles in clock high count. Used to time THD_STA, TSU_STA, TSU_STO.
DATA: Prescaled clock cycles for data setup and hold count. Used to time THD_DAT, TSU_DAT.
EXP: Specifies the clock prescaler setting.
Note that the total clock low time generated is the sum of THD_DAT + TSU_DAT + TLOW.
Any slave or other bus master taking part in the transfer may extend the TWCK low period at any
time.
The TWIM hardware monitors the state of the TWCK line as required by the I²C specification.
The clock generation counters are started when a high/low level is detected on the TWCK line,
not when the TWIM hardware releases/drives the TWCK line. This means that the CWGR settings
alone do not determine the TWCK frequency. The CWGR settings determine the clock low
time and the clock high time, but the TWCK rise and fall times are determined by the external circuitry
(capacitive load, etc.).
Figure 22-5. Bus Timing Diagram
f
PRESCALER
f
CLK_TWIM
2 EXP 1 + = -------------------------
S t
HD:STA
t LOW
t
SU:DAT
t HIGH
t
HD:DAT
t LOW
P
t
SU:STO
Sr
t
SU:STA
t
SU:DAT
533
32142D–06/2013
ATUC64/128/256L3/4U
22.8.2.2 Setting up and Performing a Transfer
Operation of the TWIM is mainly controlled by the Control Register (CR) and the Command Register
(CMDR). TWIM status is provided in the Status Register (SR). The following list presents
the main steps in a typical communication:
1. Before any transfers can be performed, bus timings must be configured by writing to the
Clock Waveform Generator Register (CWGR). If operating in SMBus mode, the SMBus
Timing Register (SMBTR) register must also be configured.
2. If the Peripheral DMA Controller is to be used for the transfers, it must be set up.
3. CMDR or NCMDR must be written with a value describing the transfer to be performed.
The interrupt system can be set up to give interrupt requests on specific events or error conditions
in the SR, for example when the transfer is complete or if arbitration is lost. The Interrupt
Enable Register (IER) and Interrupt Disable Register (IDR) can be written to specify which bits in
the SR will generate interrupt requests.
The SR.BUSFREE bit is set when activity is completed on the two-wire bus. The SR.CRDY bit is
set when CMDR and/or NCMDR is ready to receive one or more commands.
The controller will refuse to start a new transfer while ANAK, DNAK, or ARBLST in the Status
Register (SR) is one. This is necessary to avoid a race when the software issues a continuation
of the current transfer at the same time as one of these errors happen. Also, if ANAK or DNAK
occurs, a STOP condition is sent automatically. The user will have to restart the transmission by
clearing the error bits in SR after resolving the cause for the NACK.
After a data or address NACK from the slave, a STOP will be transmitted automatically. Note
that the VALID bit in CMDR is NOT cleared in this case. If this transfer is to be discarded, the
VALID bit can be cleared manually allowing any command in NCMDR to be copied into CMDR.
When a data or address NACK is returned by the slave while the master is transmitting, it is possible
that new data has already been written to the THR register. This data will be transferred out
as the first data byte of the next transfer. If this behavior is to be avoided, the safest approach is
to perform a software reset of the TWIM.
22.8.3 Master Transmitter Mode
A START condition is transmitted and master transmitter mode is initiated when the bus is free
and CMDR has been written with START=1 and READ=0. START and SADR+W will then be
transmitted. During the address acknowledge clock pulse (9th pulse), the master releases the
data line (HIGH), enabling the slave to pull it down in order to acknowledge the address. The
master polls the data line during this clock pulse and sets the Address Not Acknowledged bit
(ANAK) in the Status Register if no slave acknowledges the address.
After the address phase, the following is repeated:
while (NBYTES>0)
1. Wait until THR contains a valid data byte, stretching low period of TWCK. SR.TXRDY
indicates the state of THR. Software or the Peripheral DMA Controller must write the
data byte to THR.
2. Transmit this data byte
3. Decrement NBYTES
4. If (NBYTES==0) and STOP=1, transmit STOP condition
Writing CMDR with START=STOP=1 and NBYTES=0 will generate a transmission with no data
bytes, ie START, SADR+W, STOP.
534
32142D–06/2013
ATUC64/128/256L3/4U
TWI transfers require the slave to acknowledge each received data byte. During the acknowledge
clock pulse (9th pulse), the master releases the data line (HIGH), enabling the slave to pull
it down in order to generate the acknowledge. The master polls the data line during this clock
pulse and sets the Data Acknowledge bit (DNACK) in the Status Register if the slave does not
acknowledge the data byte. As with the other status bits, an interrupt can be generated if
enabled in the Interrupt Enable Register (IER).
TXRDY is used as Transmit Ready for the Peripheral DMA Controller transmit channel.
The end of a command is marked when the TWIM sets the SR.CCOMP bit. See Figure 22-6 and
Figure 22-7.
Figure 22-6. Master Write with One Data Byte
Figure 22-7. Master Write with Multiple Data Bytes
22.8.4 Master Receiver Mode
A START condition is transmitted and master receiver mode is initiated when the bus is free and
CMDR has been written with START=1 and READ=1. START and SADR+R will then be transmitted.
During the address acknowledge clock pulse (9th pulse), the master releases the data
line (HIGH), enabling the slave to pull it down in order to acknowledge the address. The master
polls the data line during this clock pulse and sets the Address Not Acknowledged bit (ANAK) in
the Status Register if no slave acknowledges the address.
After the address phase, the following is repeated:
while (NBYTES>0)
TWD
SR.IDLE
TXRDY
Write THR (DATA)
NBYTES set to 1
STOP sent automatically
(ACK received and NBYTES=0)
S DADR W A DATA A P
TWD
SR.IDLE
TXRDY
Write THR
(DATAn)
NBYTES set to n
STOP sent automatically
(ACK received and NBYTES=0)
S DADR W A DATAn A DATAn+5 A A DATAn+m P
Write THR
(DATAn+1)
Write THR
(DATAn+m)
Last data sent
535
32142D–06/2013
ATUC64/128/256L3/4U
1. Wait until RHR is empty, stretching low period of TWCK. SR.RXRDY indicates the state
of RHR. Software or the Peripheral DMA Controller must read any data byte present in
RHR.
2. Release TWCK generating a clock that the slave uses to transmit a data byte.
3. Place the received data byte in RHR, set RXRDY.
4. If NBYTES=0, generate a NAK after the data byte, otherwise generate an ACK.
5. Decrement NBYTES
6. If (NBYTES==0) and STOP=1, transmit STOP condition.
Writing CMDR with START=STOP=1 and NBYTES=0 will generate a transmission with no data
bytes, ie START, DADR+R, STOP
The TWI transfers require the master to acknowledge each received data byte. During the
acknowledge clock pulse (9th pulse), the slave releases the data line (HIGH), enabling the master
to pull it down in order to generate the acknowledge. All data bytes except the last are
acknowledged by the master. Not acknowledging the last byte informs the slave that the transfer
is finished.
RXRDY is used as Receive Ready for the Peripheral DMA Controller receive channel.
Figure 22-8. Master Read with One Data Byte
Figure 22-9. Master Read with Multiple Data Bytes
TWD
SR.IDLE
RXRDY
Write START &
STOP bit
NBYTES set to 1
Read RHR
S DADR R A DATA N P
TWD
SR.IDLE
RXRDY
Write START +
STOP bit
NBYTES set to m
S DADR R A DATAn A DATAn+m-1 A N DATAn+m P
Read RHR
DATAn
DATAn+1
Read RHR
DATAn+m-2
Read RHR
DATAn+m-1
Read RHR
DATAn+m
Send STOP
When NBYTES=0
536
32142D–06/2013
ATUC64/128/256L3/4U
22.8.5 Using the Peripheral DMA Controller
The use of the Peripheral DMA Controller significantly reduces the CPU load. The user can set
up ring buffers for the Peripheral DMA Controller, containing data to transmit or free buffer space
to place received data.
To assure correct behavior, respect the following programming sequences:
22.8.5.1 Data Transmit with the Peripheral DMA Controller
1. Initialize the transmit Peripheral DMA Controller (memory pointers, size, etc.).
2. Configure the TWIM (ADR, NBYTES, etc.).
3. Start the transfer by enabling the Peripheral DMA Controller to transmit.
4. Wait for the Peripheral DMA Controller end-of-transmit flag.
5. Disable the Peripheral DMA Controller.
22.8.5.2 Data Receive with the Peripheral DMA Controller
1. Initialize the receive Peripheral DMA Controller (memory pointers, size, etc.).
2. Configure the TWIM (ADR, NBYTES, etc.).
3. Start the transfer by enabling the Peripheral DMA Controller to receive.
4. Wait for the Peripheral DMA Controller end-of-receive flag.
5. Disable the Peripheral DMA Controller.
22.8.6 Multi-master Mode
More than one master may access the bus at the same time without data corruption by using
arbitration.
Arbitration starts as soon as two or more masters place information on the bus at the same time,
and stops (arbitration is lost) for the master that intends to send a logical one while the other
master sends a logical zero.
As soon as arbitration is lost by a master, it stops sending data and listens to the bus in order to
detect a STOP. The SR.ARBLST flag will be set. When the STOP is detected, the master who
lost arbitration may reinitiate the data transfer.
Arbitration is illustrated in Figure 22-11.
If the user starts a transfer and if the bus is busy, the TWIM automatically waits for a STOP condition
on the bus before initiating the transfer (see Figure 22-10).
Note: The state of the bus (busy or free) is not indicated in the user interface.
537
32142D–06/2013
ATUC64/128/256L3/4U
Figure 22-10. User Sends Data While the Bus is Busy
Figure 22-11. Arbitration Cases
22.8.7 Combined Transfers
CMDR and NCMDR may be used to generate longer sequences of connected transfers, since
generation of START and/or STOP conditions is programmable on a per-command basis.
Writing NCMDR with START=1 when the previous transfer was written with STOP=0 will cause
a REPEATED START on the bus. The ability to generate such connected transfers allows arbitrary
transfer lengths, since it is legal to write CMDR with both START=0 and STOP=0. If this is
done in master receiver mode, the CMDR.ACKLAST bit must also be controlled.
TWCK
TWD DATA sent by a master
STOP sent by the master START sent by the TWI
DATA sent by the TWI
Bus is busy
Bus is free
A transfer is programmed
(DADR + W + START + Write THR) Transfer is initiated
TWI DATA transfer Transfer is kept
Bus is considered as free
TWCK
Bus is busy Bus is free
A transfer is programmed
(DADR + W + START + Write THR) Transfer is initiated
TWI DATA transfer Transfer is kept
Bus is considered as free
Data from a Master
Data from TWI S 0
S 0 0
1
1
1
ARBLST
S 0
S 0 0
1
1
1
TWD S 1 0 0
1 1
1 1
Arbitration is lost
TWI stops sending data
P
P S 1 0 0
1 1
Data from the master 1 1 Data from the TWI
Arbitration is lost
The master stops sending data
Transfer is stopped
Transfer is programmed again
(DADR + W + START + Write THR)
TWCK
TWD
538
32142D–06/2013
ATUC64/128/256L3/4U
As for single data transfers, the TXRDY and RXRDY bits in the Status Register indicates when
data to transmit can be written to THR, or when received data can be read from RHR. Transfer
of data to THR and from RHR can also be done automatically by DMA, see Section 22.8.5
22.8.7.1 Write Followed by Write
Consider the following transfer:
START, DADR+W, DATA+A, DATA+A, REPSTART, DADR+W, DATA+A, DATA+A, STOP.
To generate this transfer:
1. Write CMDR with START=1, STOP=0, DADR, NBYTES=2 and READ=0.
2. Write NCMDR with START=1, STOP=1, DADR, NBYTES=2 and READ=0.
3. Wait until SR.TXRDY==1, then write first data byte to transfer to THR.
4. Wait until SR.TXRDY==1, then write second data byte to transfer to THR.
5. Wait until SR.TXRDY==1, then write third data byte to transfer to THR.
6. Wait until SR.TXRDY==1, then write fourth data byte to transfer to THR.
22.8.7.2 Read Followed by Read
Consider the following transfer:
START, DADR+R, DATA+A, DATA+NA, REPSTART, DADR+R, DATA+A, DATA+NA, STOP.
To generate this transfer:
1. Write CMDR with START=1, STOP=0, DADR, NBYTES=2 and READ=1.
2. Write NCMDR with START=1, STOP=1, DADR, NBYTES=2 and READ=1.
3. Wait until SR.RXRDY==1, then read first data byte received from RHR.
4. Wait until SR.RXRDY==1, then read second data byte received from RHR.
5. Wait until SR.RXRDY==1, then read third data byte received from RHR.
6. Wait until SR.RXRDY==1, then read fourth data byte received from RHR.
If combining several transfers, without any STOP or REPEATED START between them, remember
to write a one to the ACKLAST bit in CMDR to keep from ending each of the partial transfers
with a NACK.
22.8.7.3 Write Followed by Read
Consider the following transfer:
START, DADR+W, DATA+A, DATA+A, REPSTART, DADR+R, DATA+A, DATA+NA, STOP.
539
32142D–06/2013
ATUC64/128/256L3/4U
Figure 22-12. Combining a Write and Read Transfer
To generate this transfer:
1. Write CMDR with START=1, STOP=0, DADR, NBYTES=2 and READ=0.
2. Write NCMDR with START=1, STOP=1, DADR, NBYTES=2 and READ=1.
3. Wait until SR.TXRDY==1, then write first data byte to transfer to THR.
4. Wait until SR.TXRDY==1, then write second data byte to transfer to THR.
5. Wait until SR.RXRDY==1, then read first data byte received from RHR.
6. Wait until SR.RXRDY==1, then read second data byte received from RHR.
22.8.7.4 Read Followed by Write
Consider the following transfer:
START, DADR+R, DATA+A, DATA+NA, REPSTART, DADR+W, DATA+A, DATA+A, STOP.
Figure 22-13. Combining a Read and Write Transfer
To generate this transfer:
1. Write CMDR with START=1, STOP=0, DADR, NBYTES=2 and READ=1.
2. Write NCMDR with START=1, STOP=1, DADR, NBYTES=2 and READ=0.
3. Wait until SR.RXRDY==1, then read first data byte received from RHR.
4. Wait until SR.RXRDY==1, then read second data byte received from RHR.
5. Wait until SR.TXRDY==1, then write first data byte to transfer to THR.
6. Wait until SR.TXRDY==1, then write second data byte to transfer to THR.
TWD
SR.IDLE
TXRDY
S DADR W A DATA0 A DATA1 NA Sr DADR R A DATA2 A DATA3 A P
THR DATA0 DATA1
RXRDY
1
RHR DATA2 DATA3
TWD
SR.IDLE
TXRDY
S SADR R A DATA0 A DATA1 Sr DADR W A DATA2 A DATA3 NA P
THR DATA2
RXRDY
RHR DATA0 DATA3
A
1
2
DATA3
Read
TWI_RHR
540
32142D–06/2013
ATUC64/128/256L3/4U
22.8.8 Ten Bit Addressing
Writing a one to CMDR.TENBIT enables 10-bit addressing in hardware. Performing transfers
with 10-bit addressing is similar to transfers with 7-bit addresses, except that bits 9:7 of
CMDR.SADR must be written appropriately.
In Figure 22-14 and Figure 22-15, the grey boxes represent signals driven by the master, the
white boxes are driven by the slave.
22.8.8.1 Master Transmitter
To perform a master transmitter transfer:
1. Write CMDR with TENBIT=1, REPSAME=0, READ=0, START=1, STOP=1 and the
desired address and NBYTES value.
Figure 22-14. A Write Transfer with 10-bit Addressing
22.8.8.2 Master Receiver
When using master receiver mode with 10-bit addressing, CMDR.REPSAME must also be controlled.
CMDR.REPSAME must be written to one when the address phase of the transfer should
consist of only 1 address byte (the 11110xx byte) and not 2 address bytes. The I²C standard
specifies that such addressing is required when addressing a slave for reads using 10-bit
addressing.
To perform a master receiver transfer:
1. Write CMDR with TENBIT=1, REPSAME=0, READ=0, START=1, STOP=0,
NBYTES=0 and the desired address.
2. Write NCMDR with TENBIT=1, REPSAME=1, READ=1, START=1, STOP=1 and the
desired address and NBYTES value.
Figure 22-15. A Read Transfer with 10-bit Addressing
22.8.9 SMBus Mode
SMBus mode is enabled and disabled by writing to the SMEN and SMDIS bits in CR. SMBus
mode operation is similar to I²C operation with the following exceptions:
• Only 7-bit addressing can be used.
• The SMBus standard describes a set of timeout values to ensure progress and throughput on
the bus. These timeout values must be written into SMBTR.
• Transmissions can optionally include a CRC byte, called Packet Error Check (PEC).
• A dedicated bus line, SMBALERT, allows a slave to get a master’s attention.
• A set of addresses have been reserved for protocol handling, such as Alert Response
Address (ARA) and Host Header (HH) Address.
S SLAVE ADDRESS
1st 7 bits RW A1 A2 DATA A P SLAVE ADDRESS
2nd byte DATA AA
11110XX0
S SLAVE ADDRESS
1st 7 bits RW A1 A2 DATA A P SLAVE ADDRESS
2nd byte DATA A
11110XX0
Sr SLAVE ADDRESS
1st 7 bits RW A3
11110XX1
541
32142D–06/2013
ATUC64/128/256L3/4U
22.8.9.1 Packet Error Checking
Each SMBus transfer can optionally end with a CRC byte, called the PEC byte. Writing a one to
CMDR.PECEN enables automatic PEC handling in the current transfer. Transfers with and without
PEC can freely be intermixed in the same system, since some slaves may not support PEC.
The PEC LFSR is always updated on every bit transmitted or received, so that PEC handling on
combined transfers will be correct.
In master transmitter mode, the master calculates a PEC value and transmits it to the slave after
all data bytes have been transmitted. Upon reception of this PEC byte, the slave will compare it
to the PEC value it has computed itself. If the values match, the data was received correctly, and
the slave will return an ACK to the master. If the PEC values differ, data was corrupted, and the
slave will return a NACK value. The DNAK bit in SR reflects the state of the last received
ACK/NACK value. Some slaves may not be able to check the received PEC in time to return a
NACK if an error occurred. In this case, the slave should always return an ACK after the PEC
byte, and some other mechanism must be implemented to verify that the transmission was
received correctly.
In master receiver mode, the slave calculates a PEC value and transmits it to the master after all
data bytes have been transmitted. Upon reception of this PEC byte, the master will compare it to
the PEC value it has computed itself. If the values match, the data was received correctly. If the
PEC values differ, data was corrupted, and SR.PECERR is set. In master receiver mode, the
PEC byte is always followed by a NACK transmitted by the master, since it is the last byte in the
transfer.
The PEC byte is automatically inserted in a master transmitter transmission if PEC is enabled
when NBYTES reaches zero. The PEC byte is identified in a master receiver transmission if
PEC is enabled when NBYTES reaches zero. NBYTES must therefore be written with the total
number of data bytes in the transmission, including the PEC byte.
In combined transfers, the PECEN bit should only be written to one in the last of the combined
transfers. Consider the following transfer:
S, ADR+W, COMMAND_BYTE, ACK, SR, ADR+R, DATA_BYTE, ACK, PEC_BYTE, NACK, P
This transfer is generated by writing two commands to the command registers. The first command
is a write with NBYTES=1 and PECEN=0, and the second is a read with NBYTES=2 and
PECEN=1.
Writing a one to the STOP bit in CR will place a STOP condition on the bus after the current
byte. No PEC byte will be sent in this case.
22.8.9.2 Timeouts
The TLOWS and TLOWM fields in SMBTR configure the SMBus timeout values. If a timeout
occurs, the master will transmit a STOP condition and leave the bus. The SR.TOUT bit is set.
22.8.9.3 SMBus ALERT Signal
A slave can get the master’s attention by pulling the TWALM line low. The TWIM will then set the
SR.SMBALERT bit. This can be set up to trigger an interrupt, and software can then take the
appropriate action, as defined in the SMBus standard.
542
32142D–06/2013
ATUC64/128/256L3/4U
22.8.10 Identifying Bus Events
This chapter lists the different bus events, and how they affect bits in the TWIM registers. This is
intended to help writing drivers for the TWIM.
Table 22-5. Bus Events
Event Effect
Master transmitter has sent
a data byte SR.THR is cleared.
Master receiver has
received a data byte SR.RHR is set.
Start+Sadr sent, no ack
received from slave
SR.ANAK is set.
SR.CCOMP not set.
CMDR.VALID remains set.
STOP automatically transmitted on bus.
Data byte sent to slave, no
ack received from slave
SR.DNAK is set.
SR.CCOMP not set.
CMDR.VALID remains set.
STOP automatically transmitted on bus.
Arbitration lost
SR.ARBLST is set.
SR.CCOMP not set.
CMDR.VALID remains set.
TWCK and TWD immediately released to a pulled-up state.
SMBus Alert received SR.SMBALERT is set.
SMBus timeout received
SR.SMBTOUT is set.
SR.CCOMP not set.
CMDR.VALID remains set.
STOP automatically transmitted on bus.
Master transmitter receives
SMBus PEC Error
SR.DNAK is set.
SR.CCOMP not set.
CMDR.VALID remains set.
STOP automatically transmitted on bus.
Master receiver discovers
SMBus PEC Error
SR.PECERR is set.
SR.CCOMP not set.
CMDR.VALID remains set.
STOP automatically transmitted on bus.
CR.STOP is written by user
SR.STOP is set.
SR.CCOMP set.
CMDR.VALID remains set.
STOP transmitted on bus after current byte transfer has finished.
543
32142D–06/2013
ATUC64/128/256L3/4U
22.9 User Interface
Note: 1. The reset values for these registers are device specific. Please refer to the Module Configuration section at the end of this
chapter.
Table 22-6. TWIM Register Memory Map
Offset Register Register Name Access Reset
0x00 Control Register CR Write-only 0x00000000
0x04 Clock Waveform Generator Register CWGR Read/Write 0x00000000
0x08 SMBus Timing Register SMBTR Read/Write 0x00000000
0x0C Command Register CMDR Read/Write 0x00000000
0x10 Next Command Register NCMDR Read/Write 0x00000000
0x14 Receive Holding Register RHR Read-only 0x00000000
0x18 Transmit Holding Register THR Write-only 0x00000000
0x1C Status Register SR Read-only 0x00000002
0x20 Interrupt Enable Register IER Write-only 0x00000000
0x24 Interrupt Disable Register IDR Write-only 0x00000000
0x28 Interrupt Mask Register IMR Read-only 0x00000000
0x2C Status Clear Register SCR Write-only 0x00000000
0x30 Parameter Register PR Read-only -(1)
0x34 Version Register VR Read-only -(1)
544
32142D–06/2013
ATUC64/128/256L3/4U
22.9.1 Control Register
Name: CR
Access Type: Write-only
Offset: 0x00
Reset Value: 0x00000000
• STOP: Stop the Current Transfer
Writing a one to this bit terminates the current transfer, sending a STOP condition after the shifter has become idle. If there are
additional pending transfers, they will have to be explicitly restarted by software after the STOP condition has been successfully
sent.
Writing a zero to this bit has no effect.
• SWRST: Software Reset
If the TWIM master interface is enabled, writing a one to this bit resets the TWIM. All transfers are halted immediately, possibly
violating the bus semantics.
If the TWIM master interface is not enabled, it must first be enabled before writing a one to this bit.
Writing a zero to this bit has no effect.
• SMDIS: SMBus Disable
Writing a one to this bit disables SMBus mode.
Writing a zero to this bit has no effect.
• SMEN: SMBus Enable
Writing a one to this bit enables SMBus mode.
Writing a zero to this bit has no effect.
• MDIS: Master Disable
Writing a one to this bit disables the master interface.
Writing a zero to this bit has no effect.
• MEN: Master Enable
Writing a one to this bit enables the master interface.
Writing a zero to this bit has no effect.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
- - - - - - - STOP
76543210
SWRST - SMDIS SMEN - - MDIS MEN
545
32142D–06/2013
ATUC64/128/256L3/4U
22.9.2 Clock Waveform Generator Register
Name: CWGR
Access Type: Read/Write
Offset: 0x04
Reset Value: 0x00000000
• EXP: Clock Prescaler
Used to specify how to prescale the TWCK clock. Counters are prescaled according to the following formula
• DATA: Data Setup and Hold Cycles
Clock cycles for data setup and hold count. Prescaled by CWGR.EXP. Used to time THD_DAT, TSU_DAT.
• STASTO: START and STOP Cycles
Clock cycles in clock high count. Prescaled by CWGR.EXP. Used to time THD_STA, TSU_STA, TSU_STO
• HIGH: Clock High Cycles
Clock cycles in clock high count. Prescaled by CWGR.EXP. Used to time THIGH.
• LOW: Clock Low Cycles
Clock cycles in clock low count. Prescaled by CWGR.EXP. Used to time TLOW, TBUF.
31 30 29 28 27 26 25 24
- EXP DATA
23 22 21 20 19 18 17 16
STASTO
15 14 13 12 11 10 9 8
HIGH
76543210
LOW
f
PRESCALER
f
CLK_TWIM
2 EXP 1 + = -------------------------
546
32142D–06/2013
ATUC64/128/256L3/4U
22.9.3 SMBus Timing Register
Name: SMBTR
Access Type: Read/Write
Offset: 0x08
Reset Value: 0x00000000
• EXP: SMBus Timeout Clock Prescaler
Used to specify how to prescale the TIM and TLOWM counters in SMBTR. Counters are prescaled according to the following
formula
• THMAX: Clock High Maximum Cycles
Clock cycles in clock high maximum count. Prescaled by SMBTR.EXP. Used for bus free detection. Used to time THIGH:MAX.
NOTE: Uses the prescaler specified by CWGR, NOT the prescaler specified by SMBTR.
• TLOWM: Master Clock Stretch Maximum Cycles
Clock cycles in master maximum clock stretch count. Prescaled by SMBTR.EXP. Used to time TLOW:MEXT
• TLOWS: Slave Clock Stretch Maximum Cycles
Clock cycles in slave maximum clock stretch count. Prescaled by SMBTR.EXP. Used to time TLOW:SEXT.
31 30 29 28 27 26 25 24
EXP - - - -
23 22 21 20 19 18 17 16
THMAX
15 14 13 12 11 10 9 8
TLOWM
76543210
TLOWS
f
prescaled SMBus
f
CLKTWIM
2 EXP + 1 = ------------------------
547
32142D–06/2013
ATUC64/128/256L3/4U
22.9.4 Command Register
Name: CMDR
Access Type: Read/Write
Offset: 0x0C
Reset Value: 0x00000000
• ACKLAST: ACK Last Master RX Byte
0: Causes the last byte in master receive mode (when NBYTES has reached 0) to be NACKed. This is the standard way of
ending a master receiver transfer.
1: Causes the last byte in master receive mode (when NBYTES has reached 0) to be ACKed. Used for performing linked
transfers in master receiver mode with no STOP or REPEATED START between the subtransfers. This is needed when more
than 255 bytes are to be received in one single transmission.
• PECEN: Packet Error Checking Enable
0: Causes the transfer not to use PEC byte verification. The PEC LFSR is still updated for every bit transmitted or received. Must
be used if SMBus mode is disabled.
1: Causes the transfer to use PEC. PEC byte generation (if master transmitter) or PEC byte verification (if master receiver) will
be performed.
• NBYTES: Number of Data Bytes in Transfer
The number of data bytes in the transfer. After the specified number of bytes have been transferred, a STOP condition is
transmitted if CMDR.STOP is one. In SMBus mode, if PEC is used, NBYTES includes the PEC byte, i.e. there are NBYTES-1
data bytes and a PEC byte.
• VALID: CMDR Valid
0: Indicates that CMDR does not contain a valid command.
1: Indicates that CMDR contains a valid command. This bit is cleared when the command is finished.
• STOP: Send STOP Condition
0: Do not transmit a STOP condition after the data bytes have been transmitted.
1: Transmit a STOP condition after the data bytes have been transmitted.
• START: Send START Condition
0: The transfer in CMDR should not commence with a START or REPEATED START condition.
1: The transfer in CMDR should commence with a START or REPEATED START condition. If the bus is free when the command
is executed, a START condition is used. If the bus is busy, a REPEATED START is used.
• REPSAME: Transfer is to Same Address as Previous Address
Only used in 10-bit addressing mode, always write to 0 in 7-bit addressing mode.
31 30 29 28 27 26 25 24
- - - - ACKLAST PECEN
23 22 21 20 19 18 17 16
NBYTES
15 14 13 12 11 10 9 8
VALID STOP START REPSAME TENBIT SADR[9:7]
76543210
SADR[6:0] READ
548
32142D–06/2013
ATUC64/128/256L3/4U
Write this bit to one if the command in CMDR performs a repeated start to the same slave address as addressed in the previous
transfer in order to enter master receiver mode.
Write this bit to zero otherwise.
• TENBIT: Ten Bit Addressing Mode
0: Use 7-bit addressing mode.
1: Use 10-bit addressing mode. Must not be used when the TWIM is in SMBus mode.
• SADR: Slave Address
Address of the slave involved in the transfer. Bits 9-7 are don’t care if 7-bit addressing is used.
• READ: Transfer Direction
0: Allow the master to transmit data.
1: Allow the master to receive data.
549
32142D–06/2013
ATUC64/128/256L3/4U
22.9.5 Next Command Register
Name: NCMDR
Access Type: Read/Write
Offset: 0x10
Reset Value: 0x00000000
This register is identical to CMDR. When the VALID bit in CMDR becomes 0, the content of NCMDR is copied into CMDR,
clearing the VALID bit in NCMDR. If the VALID bit in CMDR is cleared when NCMDR is written, the content is copied
immediately.
31 30 29 28 27 26 25 24
- - - - ACKLAST PECEN
23 22 21 20 19 18 17 16
NBYTES
15 14 13 12 11 10 9 8
VALID STOP START REPSAME TENBIT SADR[9:7]
76543210
SADR[6:0] READ
550
32142D–06/2013
ATUC64/128/256L3/4U
22.9.6 Receive Holding Register
Name: RHR
Access Type: Read-only
Offset: 0x14
Reset Value: 0x00000000
• RXDATA: Received Data
When the RXRDY bit in the Status Register (SR) is one, this field contains a byte received from the TWI bus.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
RXDATA
551
32142D–06/2013
ATUC64/128/256L3/4U
22.9.7 Transmit Holding Register
Name: THR
Access Type: Write-only
Offset: 0x18
Reset Value: 0x00000000
• TXDATA: Data to Transmit
Write data to be transferred on the TWI bus here.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
TXDATA
552
32142D–06/2013
ATUC64/128/256L3/4U
22.9.8 Status Register
Name: SR
Access Type: Read-only
Offset: 0x1C
Reset Value: 0x00000002
• MENB: Master Interface Enable
0: Master interface is disabled.
1: Master interface is enabled.
• STOP: Stop Request Accepted
This bit is one when a STOP request caused by writing a one to CR.STOP has been accepted, and transfer has stopped.
This bit is cleared by writing 1 to the corresponding bit in the Status Clear Register (SCR).
• PECERR: PEC Error
This bit is one when a SMBus PEC error occurred.
This bit is cleared by writing 1 to the corresponding bit in the Status Clear Register (SCR).
• TOUT: Timeout
This bit is one when a SMBus timeout occurred.
This bit is cleared by writing 1 to the corresponding bit in the Status Clear Register (SCR).
• SMBALERT: SMBus Alert
This bit is one when an SMBus Alert was received.
This bit is cleared by writing 1 to the corresponding bit in the Status Clear Register (SCR).
• ARBLST: Arbitration Lost
This bit is one when the actual state of the SDA line did not correspond to the data driven onto it, indicating a higher-priority
transmission in progress by a different master.
This bit is cleared by writing 1 to the corresponding bit in the Status Clear Register (SCR).
• DNAK: NAK in Data Phase Received
This bit is one when no ACK was received form slave during data transmission.
This bit is cleared by writing 1 to the corresponding bit in the Status Clear Register (SCR).
• ANAK: NAK in Address Phase Received
This bit is one when no ACK was received from slave during address phase
This bit is cleared by writing 1 to the corresponding bit in the Status Clear Register (SCR).
• BUSFREE: Two-wire Bus is Free
This bit is one when activity has completed on the two-wire bus.
Otherwise, this bit is cleared.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
- - - - - - - MENB
15 14 13 12 11 10 9 8
- STOP PECERR TOUT SMBALERT ARBLST DNAK ANAK
76543210
- - BUSFREE IDLE CCOMP CRDY TXRDY RXRDY
553
32142D–06/2013
ATUC64/128/256L3/4U
• IDLE: Master Interface is Idle
This bit is one when no command is in progress, and no command waiting to be issued.
Otherwise, this bit is cleared.
• CCOMP: Command Complete
This bit is one when the current command has completed successfully.
This bit is zero if the command failed due to conditions such as a NAK receved from slave.
This bit is cleared by writing 1 to the corresponding bit in the Status Clear Register (SCR).
• CRDY: Ready for More Commands
This bit is one when CMDR and/or NCMDR is ready to receive one or more commands.
This bit is cleared when this is no longer true.
• TXRDY: THR Data Ready
This bit is one when THR is ready for one or more data bytes.
This bit is cleared when this is no longer true (i.e. THR is full or transmission has stopped).
• RXRDY: RHR Data Ready
This bit is one when RX data are ready to be read from RHR.
This bit is cleared when this is no longer true.
554
32142D–06/2013
ATUC64/128/256L3/4U
22.9.9 Interrupt Enable Register
Name: IER
Access Type: Write-only
Offset: 0x20
Reset Value: 0x00000000
Writing a zero to a bit in this register has no effect.
Writing a one to a bit in this register will set the corresponding bit in IMR
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
- STOP PECERR TOUT SMBALERT ARBLST DNAK ANAK
76543210
- - BUSFREE IDLE CCOMP CRDY TXRDY RXRDY
555
32142D–06/2013
ATUC64/128/256L3/4U
22.9.10 Interrupt Disable Register
Name: IDR
Access Type: Write-only
Offset: 0x24
Reset Value: 0x00000000
Writing a zero to a bit in this register has no effect.
Writing a one to a bit in this register will clear the corresponding bit in IMR
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
- STOP PECERR TOUT SMBALERT ARBLST DNAK ANAK
76543210
- - BUSFREE IDLE CCOMP CRDY TXRDY RXRDY
556
32142D–06/2013
ATUC64/128/256L3/4U
22.9.11 Interrupt Mask Register
Name: IMR
Access Type: Read-only
Offset: 0x28
Reset Value: 0x00000000
0: The corresponding interrupt is disabled.
1: The corresponding interrupt is enabled.
This bit is cleared when the corresponding bit in IDR is written to one.
This bit is set when the corresponding bit in IER is written to one.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
- STOP PECERR TOUT SMBALERT ARBLST DNAK ANAK
76543210
- - BUSFREE IDLE CCOMP CRDY TXRDY RXRDY
557
32142D–06/2013
ATUC64/128/256L3/4U
22.9.12 Status Clear Register
Name: SCR
Access Type : Write-only
Offset: 0x2C
Reset Value: 0x00000000
Writing a zero to a bit in this register has no effect.
Writing a one to a bit in this register will clear the corresponding bit in SR and the corresponding interrupt request.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
- STOP PECERR TOUT SMBALERT ARBLST DNAK ANAK
76543210
- - - - CCOMP - - -
558
32142D–06/2013
ATUC64/128/256L3/4U
22.9.13 Parameter Register (PR)
Name: PR
Access Type: Read-only
Offset: 0x30
Reset Value: -
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
--------
559
32142D–06/2013
ATUC64/128/256L3/4U
22.9.14 Version Register (VR)
Name: VR
Access Type: Read-only
Offset: 0x34
Reset Value: -
• VARIANT: Variant Number
Reserved. No functionality associated.
• VERSION: Version Number
Version number of the module. No functionality associated.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
- - - - VARIANT
15 14 13 12 11 10 9 8
- - - - VERSION [11:8]
76543210
VERSION [7:0]
560
32142D–06/2013
ATUC64/128/256L3/4U
22.10 Module Configuration
The specific configuration for each TWIM instance is listed in the following tables.The module
bus clocks listed here are connected to the system bus clocks. Please refer to the Power Manager
chapter for details.
Table 22-7. Module Clock Name
Module Name Clock Name Description
TWIM0 CLK_TWIM0 Clock for the TWIM0 bus interface
TWIM1 CLK_TWIM1 Clock for the TWIM1 bus interface
Table 22-8. Register Reset Values
Register Reset Value
VERSION 0x00000110
PARAMETER 0x00000000
561
32142D–06/2013
ATUC64/128/256L3/4U
23. Two-wire Slave Interface (TWIS)
Rev.: 1.2.0.1
23.1 Features
• Compatible with I²C standard
– Transfer speeds of 100 and 400 kbit/s
– 7 and 10-bit and General Call addressing
• Compatible with SMBus standard
– Hardware Packet Error Checking (CRC) generation and verification with ACK response
– SMBALERT interface
– 25 ms clock low timeout delay
– 25 ms slave cumulative clock low extend time
• Compatible with PMBus
• DMA interface for reducing CPU load
• Arbitrary transfer lengths, including 0 data bytes
• Optional clock stretching if transmit or receive buffers not ready for data transfer
• 32-bit Peripheral Bus interface for configuration of the interface
23.2 Overview
The Atmel Two-wire Slave Interface (TWIS) interconnects components on a unique two-wire
bus, made up of one clock line and one data line with speeds of up to 400 kbit/s, based on a
byte-oriented transfer format. It can be used with any Atmel Two-wire Interface bus, I²C, or
SMBus-compatible master. The TWIS is always a bus slave and can transfer sequential or single
bytes.
Below, Table 23-1 lists the compatibility level of the Atmel Two-wire Slave Interface and a full I²C
compatible device.
Note: 1. START + b000000001 + Ack + Sr
Table 23-1. Atmel TWIS Compatibility with I²C Standard
I²C Standard Atmel TWIS
Standard-mode (100 kbit/s) Supported
Fast-mode (400 kbit/s) Supported
7 or 10 bits Slave Addressing Supported
START BYTE(1) Not Supported
Repeated Start (Sr) Condition Supported
ACK and NAK Management Supported
Slope control and input filtering (Fast mode) Supported
Clock stretching Supported
562
32142D–06/2013
ATUC64/128/256L3/4U
Below, Table 23-2 lists the compatibility level of the Atmel Two-wire Slave Interface and a full
SMBus compatible device.
23.3 List of Abbreviations
23.4 Block Diagram
Figure 23-1. Block Diagram
Table 23-2. Atmel TWIS Compatibility with SMBus Standard
SMBus Standard Atmel TWIS
Bus Timeouts Supported
Address Resolution Protocol Supported
Alert Supported
Packet Error Checking Supported
Table 23-3. Abbreviations
Abbreviation Description
TWI Two-wire Interface
A Acknowledge
NA Non Acknowledge
P Stop
S Start
Sr Repeated Start
SADR Slave Address
ADR Any address except SADR
R Read
W Write
Peripheral
Bus Bridge
Two-wire
Interface
I/O Controller
TWCK
TWD
Interrupt
Controller
TWI Interrupt
Power
Manager
CLK_TWIS
TWALM
563
32142D–06/2013
ATUC64/128/256L3/4U
23.5 Application Block Diagram
Figure 23-2. Application Block Diagram
23.6 I/O Lines Description
23.7 Product Dependencies
In order to use this module, other parts of the system must be configured correctly, as described
below.
23.7.1 I/O Lines
TWDand TWCK are bidirectional lines, connected to a positive supply voltage via a current
source or pull-up resistor (see Figure 23-5 on page 565). When the bus is free, both lines are
high. The output stages of devices connected to the bus must have an open-drain or open-collector
to perform the wired-AND function.
TWALM is used to implement the optional SMBus SMBALERT signal.
TWALM, TWD, and TWCK pins may be multiplexed with I/O Controller lines. To enable the
TWIS, the user must perform the following steps:
• Program the I/O Controller to:
– Dedicate TWD, TWCK, and optionally TWALM as peripheral lines.
– Define TWD, TWCK, and optionally TWALM as open-drain.
Host with
TWI
Interface
TWD
TWCK
Atmel TWI
serial EEPROM I²C RTC I²C LCD
controller
Slave 1 Slave 2 Slave 3
VDD
I²C temp.
sensor
Slave 4
Rp: Pull up value as given by the I²C Standard
Rp Rp
Table 23-4. I/O Lines Description
Pin Name Pin Description Type
TWD Two-wire Serial Data Input/Output
TWCK Two-wire Serial Clock Input/Output
TWALM SMBus SMBALERT Input/Output
564
32142D–06/2013
ATUC64/128/256L3/4U
23.7.2 Power Management
If the CPU enters a sleep mode that disables clocks used by the TWIS, the TWIS will stop functioning
and resume operation after the system wakes up from sleep mode. The TWIS is able to
wake the system from sleep mode upon address match, see Section 23.8.8 on page 572.
23.7.3 Clocks
The clock for the TWIS bus interface (CLK_TWIS) is generated by the Power Manager. This
clock is enabled at reset, and can be disabled in the Power Manager. It is recommended to disable
the TWIS before disabling the clock, to avoid freezing the TWIS in an undefined state.
23.7.4 DMA
The TWIS DMA handshake interface is connected to the Peripheral DMA Controller. Using the
TWIS DMA functionality requires the Peripheral DMA Controller to be programmed after setting
up the TWIS.
23.7.5 Interrupts
The TWIS interrupt request lines are connected to the interrupt controller. Using the TWIS interrupts
requires the interrupt controller to be programmed first.
23.7.6 Debug Operation
When an external debugger forces the CPU into debug mode, the TWIS continues normal operation.
If the TWIS is configured in a way that requires it to be periodically serviced by the CPU
through interrupts or similar, improper operation or data loss may result during debugging.
23.8 Functional Description
23.8.1 Transfer Format
The data put on the TWD line must be 8 bits long. Data is transferred MSB first; each byte must
be followed by an acknowledgement. The number of bytes per transfer is unlimited (see Figure
23-4 on page 565).
Each transfer begins with a START condition and terminates with a STOP condition (see Figure
23-3).
• A high-to-low transition on the TWD line while TWCK is high defines the START condition.
• A low-to-high transition on the TWD line while TWCK is high defines a STOP condition.
Figure 23-3. START and STOP Conditions
TWD
TWCK
Start Stop
565
32142D–06/2013
ATUC64/128/256L3/4U
Figure 23-4. Transfer Format
23.8.2 Operation
The TWIS has two modes of operation:
• Slave transmitter mode
• Slave receiver mode
A master is a device which starts and stops a transfer and generates the TWCK clock. A slave is
assigned an address and responds to requests from the master. These modes are described in
the following chapters.
Figure 23-5. Typical Application Block Diagram
23.8.2.1 Bus Timing
The Timing Register (TR) is used to control the timing of bus signals driven by the TWIS. TR
describes bus timings as a function of cycles of the prescaled CLK_TWIS. The clock prescaling
can be selected through TR.EXP.
TR has the following fields:
TLOWS: Prescaled clock cycles used to time SMBUS timeout TLOW:SEXT.
TWD
TWCK
Start Address R/W Ack Data Ack Data Ack Stop
Host with
TWI
Interface
TWD
TWCK
Atmel TWI
Serial EEPROM I²C RTC I²C LCD
Controller
Slave 1 Slave 2 Slave 3
VDD
I²C Temp.
Sensor
Slave 4
Rp: Pull up value as given by the I²C Standard
Rp Rp
fPRESCALED
f
CLK_TWIS
2 EXP 1 + = ------------------------
566
32142D–06/2013
ATUC64/128/256L3/4U
TTOUT: Prescaled clock cycles used to time SMBUS timeout TTIMEOUT.
SUDAT: Non-prescaled clock cycles for data setup and hold count. Used to time TSU_DAT.
EXP: Specifies the clock prescaler setting used for the SMBUS timeouts.
Figure 23-6. Bus Timing Diagram
23.8.2.2 Setting Up and Performing a Transfer
Operation of the TWIS is mainly controlled by the Control Register (CR). The following list presents
the main steps in a typical communication:
3. Before any transfers can be performed, bus timings must be configured by writing to the
Timing Register (TR).If the Peripheral DMA Controller is to be used for the transfers, it
must be set up.
4. The Control Register (CR) must be configured with information such as the slave
address, SMBus mode, Packet Error Checking (PEC), number of bytes to transfer, and
which addresses to match.
The interrupt system can be set up to generate interrupt request on specific events or error conditions,
for example when a byte has been received.
The NBYTES register is only used in SMBus mode, when PEC is enabled. In I²C mode or in
SMBus mode when PEC is disabled, the NBYTES register is not used, and should be written to
zero. NBYTES is updated by hardware, so in order to avoid hazards, software updates of
NBYTES can only be done through writes to the NBYTES register.
23.8.2.3 Address Matching
The TWIS can be set up to match several different addresses. More than one address match
may be enabled simultaneously, allowing the TWIS to be assigned to several addresses. The
address matching phase is initiated after a START or REPEATED START condition. When the
TWIS receives an address that generates an address match, an ACK is automatically returned
to the master.
S t
HD:STA
t LOW
t
SU:DAT
t HIGH
t
HD:DAT
t LOW
P
t
SU:STO
Sr
t
SU:STA
t
SU:DAT
567
32142D–06/2013
ATUC64/128/256L3/4U
In I²C mode:
• The address in CR.ADR is checked for address match if CR.SMATCH is one.
• The General Call address is checked for address match if CR.GCMATCH is one.
In SMBus mode:
• The address in CR.ADR is checked for address match if CR.SMATCH is one.
• The Alert Response Address is checked for address match if CR.SMAL is one.
• The Default Address is checked for address match if CR.SMDA is one.
• The Host Header Address is checked for address match if CR.SMHH is one.
23.8.2.4 Clock Stretching
Any slave or bus master taking part in a transfer may extend the TWCK low period at any time.
The TWIS may extend the TWCK low period after each byte transfer if CR.STREN is one and:
• Module is in slave transmitter mode, data should be transmitted, but THR is empty, or
• Module is in slave receiver mode, a byte has been received and placed into the internal
shifter, but the Receive Holding Register (RHR) is full, or
• Stretch-on-address-match bit CR.SOAM=1 and slave was addressed. Bus clock remains
stretched until all address match bits in the Status Register (SR) have been cleared.
If CR.STREN is zero and:
• Module is in slave transmitter mode, data should be transmitted but THR is empty: Transmit
the value present in THR (the last transmitted byte or reset value), and set SR.URUN.
• Module is in slave receiver mode, a byte has been received and placed into the internal
shifter, but RHR is full: Discard the received byte and set SR.ORUN.
23.8.2.5 Bus Errors
If a bus error (misplaced START or STOP) condition is detected, the SR.BUSERR bit is set and
the TWIS waits for a new START condition.
23.8.3 Slave Transmitter Mode
If the TWIS matches an address in which the R/W bit in the TWI address phase transfer is set, it
will enter slave transmitter mode and set the SR.TRA bit (note that SR.TRA is set one
CLK_TWIS cycle after the relevant address match bit in the same register is set).
After the address phase, the following actions are performed:
1. If SMBus mode and PEC is used, NBYTES must be set up with the number of bytes to
transmit. This is necessary in order to know when to transmit the PEC byte. NBYTES
can also be used to count the number of bytes received if using DMA.
2. Byte to transmit depends on I²C/SMBus mode and CR.PEC:
– If in I²C mode or CR.PEC is zero or NBYTES is non-zero: The TWIS waits until THR
contains a valid data byte, possibly stretching the low period of TWCK. After THR
contains a valid data byte, the data byte is transferred to a shifter, and then
SR.TXRDY is changed to one because the THR is empty again.
– SMBus mode and CR.PEC is one: If NBYTES is zero, the generated PEC byte is
automatically transmitted instead of a data byte from THR. TWCK will not be
stretched by the TWIS.
3. The data byte in the shifter is transmitted.
568
32142D–06/2013
ATUC64/128/256L3/4U
4. NBYTES is updated. If CR.CUP is one, NBYTES is incremented, otherwise NBYTES is
decremented.
5. After each data byte has been transmitted, the master transmits an ACK (Acknowledge)
or NAK (Not Acknowledge) bit. If a NAK bit is received by the TWIS, the SR.NAK bit is
set. Note that this is done two CLK_TWIS cycles after TWCK has been sampled by the
TWIS to be HIGH (see Figure 23-9). The NAK indicates that the transfer is finished, and
the TWIS will wait for a STOP or REPEATED START. If an ACK bit is received, the
SR.NAK bit remains LOW. The ACK indicates that more data should be transmitted,
jump to step 2. At the end of the ACK/NAK clock cycle, the Byte Transfer Finished
(SR.BTF) bit is set. Note that this is done two CLK_TWIS cycles after TWCK has been
sampled by the TWIS to be LOW (see Figure 23-9). Also note that in the event that
SR.NAK bit is set, it must not be cleared before the SR.BTF bit is set to ensure correct
TWIS behavior.
6. If STOP is received, SR.TCOMP and SR.STO will be set.
7. If REPEATED START is received, SR.REP will be set.
The TWI transfers require the receiver to acknowledge each received data byte. During the
acknowledge clock pulse (9th pulse), the slave releases the data line (HIGH), enabling the master
to pull it down in order to generate the acknowledge. The slave polls the data line during this
clock pulse and sets the NAK bit in SR if the master does not acknowledge the data byte. A NAK
means that the master does not wish to receive additional data bytes. As with the other status
bits, an interrupt can be generated if enabled in the Interrupt Enable Register (IER).
SR.TXRDY is used as Transmit Ready for the Peripheral DMA Controller transmit channel.
The end of the complete transfer is marked by the SR.TCOMP bit changing from zero to one.
See Figure 23-7 and Figure 23-8.
Figure 23-7. Slave Transmitter with One Data Byte
TCOMP
TXRDY
Write THR (DATA) STOP sent by master
TWD S DADR R P A DATA N
NBYTES set to 1
569
32142D–06/2013
ATUC64/128/256L3/4U
Figure 23-8. Slave Transmitter with Multiple Data Bytes
Figure 23-9. Timing Relationship between TWCK, SR.NAK, and SR.BTF
23.8.4 Slave Receiver Mode
If the TWIS matches an address in which the R/W bit in the TWI address phase transfer is
cleared, it will enter slave receiver mode and clear SR.TRA (note that SR.TRA is cleared one
CLK_TWIS cycle after the relevant address match bit in the same register is set).
After the address phase, the following is repeated:
1. If SMBus mode and PEC is used, NBYTES must be set up with the number of bytes to
receive. This is necessary in order to know which of the received bytes is the PEC byte.
NBYTES can also be used to count the number of bytes received if using DMA.
2. Receive a byte. Set SR.BTF when done.
3. Update NBYTES. If CR.CUP is written to one, NBYTES is incremented, otherwise
NBYTES is decremented. NBYTES is usually configured to count downwards if PEC is
used.
4. After a data byte has been received, the slave transmits an ACK or NAK bit. For ordinary
data bytes, the CR.ACK field controls if an ACK or NAK should be returned. If PEC
is enabled and the last byte received was a PEC byte (indicated by NBYTES equal to
zero), The TWIS will automatically return an ACK if the PEC value was correct, otherwise
a NAK will be returned.
5. If STOP is received, SR.TCOMP will be set.
6. If REPEATED START is received, SR.REP will be set.
The TWI transfers require the receiver to acknowledge each received data byte. During the
acknowledge clock pulse (9th pulse), the master releases the data line (HIGH), enabling the
S DADR R DATA n+5 A P A DATA n A DATA n+m N
TCOMP
TXRDY
Write THR (Data n)
NBYTES set to m
STOP sent by master
TWD
Write THR (Data n+1) Write THR (Data n+m)
Last data sent
DATA (LSB) N P
TWCK
SR.NAK
SR.BTF
t1 t1
t1: (CLK_TWIS period) x 2
TWD
570
32142D–06/2013
ATUC64/128/256L3/4U
slave to pull it down in order to generate the acknowledge. The master polls the data line during
this clock pulse.
The SR.RXRDY bit indicates that a data byte is available in the RHR. The RXRDY bit is also
used as Receive Ready for the Peripheral DMA Controller receive channel.
Figure 23-10. Slave Receiver with One Data Byte
Figure 23-11. Slave Receiver with Multiple Data Bytes
23.8.5 Interactive ACKing Received Data Bytes
When implementing a register interface over TWI, it may sometimes be necessary or just useful
to report reads and writes to invalid register addresses by sending a NAK to the host. To be able
to do this, one must first receive the register address from the TWI bus, and then tell the TWIS
whether to ACK or NAK it. In normal operation of the TWIS, this is not possible because the controller
will automatically ACK the byte at about the same time as the RXRDY bit changes from
zero to one. Writing a one to the Stretch on Data Byte Received bit (CR.SODR) will stretch the
clock allowing the user to update CR.ACK bit before returning the desired value. After the last bit
in the data byte is received, the TWI bus clock is stretched, the received data byte is transferred
to the RHR register, and SR.BTF is set. At this time, the user can examine the received byte and
write the desired ACK or NACK value to CR.ACK. When the user clears SR.BTF, the desired
ACK value is transferred on the TWI bus. This makes it possible to look at the byte received,
determine if it is valid, and then decide to ACK or NAK it.
23.8.6 Using the Peripheral DMA Controller
The use of the Peripheral DMA Controller significantly reduces the CPU load. The user can set
up ring buffers for the Peripheral DMA Controller, containing data to transmit or free buffer space
to place received data. By initializing NBYTES to zero before a transfer, and writing a one to
CR.CUP, NBYTES is incremented by one each time a data has been transmitted or received.
This allows the user to detect how much data was actually transferred by the DMA system.
S DADR W DATA A P A
TCOMP
RXRDY
Read RHR
TWD
TWD S DADR W DATA n A A A DATA (n+1) A DATA (n+m) DATA (n+m)-1 P A
TCOMP
RXRDY
Read RHR
DATA n
Read RHR
DATA (n+1)
Read RHR
DATA (n+m)-1
Read RHR
DATA (n+m)
571
32142D–06/2013
ATUC64/128/256L3/4U
To assure correct behavior, respect the following programming sequences:
23.8.6.1 Data Transmit with the Peripheral DMA Controller
1. Initialize the transmit Peripheral DMA Controller (memory pointers, size, etc.).
2. Configure the TWIS (ADR, NBYTES, etc.).
3. Start the transfer by enabling the Peripheral DMA Controller to transmit.
4. Wait for the Peripheral DMA Controller end-of-transmit flag.
5. Disable the Peripheral DMA Controller.
23.8.6.2 Data Receive with the Peripheral DMA Controller
1. Initialize the receive Peripheral DMA Controller (memory pointers, size - 1, etc.).
2. Configure the TWIS (ADR, NBYTES, etc.).
3. Start the transfer by enabling the Peripheral DMA Controller to receive.
4. Wait for the Peripheral DMA Controller end-of-receive flag.
5. Disable the Peripheral DMA Controller.
23.8.7 SMBus Mode
SMBus mode is enabled by writing a one to the SMBus Mode Enable (SMEN) bit in CR. SMBus
mode operation is similar to I²C operation with the following exceptions:
• Only 7-bit addressing can be used.
• The SMBus standard describes a set of timeout values to ensure progress and throughput on
the bus. These timeout values must be written to TR.
• Transmissions can optionally include a CRC byte, called Packet Error Check (PEC).
• A dedicated bus line, SMBALERT, allows a slave to get a master’s attention.
• A set of addresses have been reserved for protocol handling, such as Alert Response
Address (ARA) and Host Header (HH) Address. Address matching on these addresses can
be enabled by configuring CR appropriately.
23.8.7.1 Packet Error Checking (PEC)
Each SMBus transfer can optionally end with a CRC byte, called the PEC byte. Writing a one to
the Packet Error Checking Enable (PECEN) bit in CR enables automatic PEC handling in the
current transfer. The PEC generator is always updated on every bit transmitted or received, so
that PEC handling on following linked transfers will be correct.
In slave receiver mode, the master calculates a PEC value and transmits it to the slave after all
data bytes have been transmitted. Upon reception of this PEC byte, the slave will compare it to
the PEC value it has computed itself. If the values match, the data was received correctly, and
the slave will return an ACK to the master. If the PEC values differ, data was corrupted, and the
slave will return a NAK value. The SR.SMBPECERR bit is set automatically if a PEC error
occurred.
In slave transmitter mode, the slave calculates a PEC value and transmits it to the master after
all data bytes have been transmitted. Upon reception of this PEC byte, the master will compare
it to the PEC value it has computed itself. If the values match, the data was received correctly. If
the PEC values differ, data was corrupted, and the master must take appropriate action.
The PEC byte is automatically inserted in a slave transmitter transmission if PEC enabled when
NBYTES reaches zero. The PEC byte is identified in a slave receiver transmission if PEC
572
32142D–06/2013
ATUC64/128/256L3/4U
enabled when NBYTES reaches zero. NBYTES must therefore be set to the total number of
data bytes in the transmission, including the PEC byte.
23.8.7.2 Timeouts
The Timing Register (TR) configures the SMBus timeout values. If a timeout occurs, the slave
will leave the bus. The SR.SMBTOUT bit is also set.
23.8.7.3 SMBALERT
A slave can get the master’s attention by pulling the SMBALERT line low. This is done by writing
a one to the SMBus Alert (SMBALERT) bit in CR. This will also enable address match on the
Alert Response Address (ARA).
23.8.8 Wakeup from Sleep Modes by TWI Address Match
The TWIS is able to wake the device up from a sleep mode upon an address match, including
sleep modes where CLK_TWIS is stopped. After detecting the START condition on the bus, The
TWIS will stretch TWCK until CLK_TWIS has started. The time required for starting CLK_TWIS
depends on which sleep mode the device is in. After CLK_TWIS has started, the TWIS releases
its TWCK stretching and receives one byte of data on the bus. At this time, only a limited part of
the device, including the TWIS, receives a clock, thus saving power. The TWIS goes on to
receive the slave address. If the address phase causes a TWIS address match, the entire
device is wakened and normal TWIS address matching actions are performed. Normal TWI
transfer then follows. If the TWIS is not addressed, CLK_TWIS is automatically stopped and the
device returns to its original sleep mode.
23.8.9 Identifying Bus Events
This chapter lists the different bus events, and how these affects the bits in the TWIS registers.
This is intended to help writing drivers for the TWIS.
Table 23-5. Bus Events
Event Effect
Slave transmitter has sent a
data byte
SR.THR is cleared.
SR.BTF is set.
The value of the ACK bit sent immediately after the data byte is given
by CR.ACK.
Slave receiver has received
a data byte
SR.RHR is set.
SR.BTF is set.
SR.NAK updated according to value of ACK bit received from master.
Start+Sadr on bus, but
address is to another slave None.
Start+Sadr on bus, current
slave is addressed, but
address match enable bit in
CR is not set
None.
Start+Sadr on bus, current
slave is addressed,
corresponding address
match enable bit in CR set
Correct address match bit in SR is set.
SR.TRA updated according to transfer direction (updating is done one
CLK_TWIS cycle after address match bit is set)
Slave enters appropriate transfer direction mode and data transfer
can commence.
573
32142D–06/2013
ATUC64/128/256L3/4U
Start+Sadr on bus, current
slave is addressed,
corresponding address
match enable bit in CR set,
SR.STREN and SR.SOAM
are set.
Correct address match bit in SR is set.
SR.TRA updated according to transfer direction (updating is done one
CLK_TWIS cycle after address match bit is set).
Slave stretches TWCK immediately after transmitting the address
ACK bit. TWCK remains stretched until all address match bits in SR
have been cleared.
Slave enters appropriate transfer direction mode and data transfer
can commence.
Repeated Start received
after being addressed
SR.REP set.
SR.TCOMP unchanged.
Stop received after being
addressed
SR.STO set.
SR.TCOMP set.
Start, Repeated Start, or
Stop received in illegal
position on bus
SR.BUSERR set.
SR.STO and SR.TCOMP may or may not be set depending on the
exact position of an illegal stop.
Data is to be received in
slave receiver mode,
SR.STREN is set, and RHR
is full
TWCK is stretched until RHR has been read.
Data is to be transmitted in
slave receiver mode,
SR.STREN is set, and THR
is empty
TWCK is stretched until THR has been written.
Data is to be received in
slave receiver mode,
SR.STREN is cleared, and
RHR is full
TWCK is not stretched, read data is discarded.
SR.ORUN is set.
Data is to be transmitted in
slave receiver mode,
SR.STREN is cleared, and
THR is empty
TWCK is not stretched, previous contents of THR is written to bus.
SR.URUN is set.
SMBus timeout received SR.SMBTOUT is set.
TWCK and TWD are immediately released.
Slave transmitter in SMBus
PEC mode has transmitted
a PEC byte, that was not
identical to the PEC
calculated by the master
receiver.
Master receiver will transmit a NAK as usual after the last byte of a
master receiver transfer.
Master receiver will retry the transfer at a later time.
Slave receiver discovers
SMBus PEC Error
SR.SMBPECERR is set.
NAK returned after the data byte.
Table 23-5. Bus Events
Event Effect
574
32142D–06/2013
ATUC64/128/256L3/4U
23.9 User Interface
Note: 1. The reset values for these registers are device specific. Please refer to the Module Configuration section at the end of this
chapter.
Table 23-6. TWIS Register Memory Map
Offset Register Register Name Access Reset
0x00 Control Register CR Read/Write 0x00000000
0x04 NBYTES Register NBYTES Read/Write 0x00000000
0x08 Timing Register TR Read/Write 0x00000000
0x0C Receive Holding Register RHR Read-only 0x00000000
0x10 Transmit Holding Register THR Write-only 0x00000000
0x14 Packet Error Check Register PECR Read-only 0x00000000
0x18 Status Register SR Read-only 0x00000002
0x1C Interrupt Enable Register IER Write-only 0x00000000
0x20 Interrupt Disable Register IDR Write-only 0x00000000
0x24 Interrupt Mask Register IMR Read-only 0x00000000
0x28 Status Clear Register SCR Write-only 0x00000000
0x2C Parameter Register PR Read-only -(1)
0x30 Version Register VR Read-only -(1)
575
32142D–06/2013
ATUC64/128/256L3/4U
23.9.1 Control Register
Name: CR
Access Type: Read/Write
Offset: 0x00
Reset Value: 0x00000000
• TENBIT: Ten Bit Address Match
0: Disables Ten Bit Address Match.
1: Enables Ten Bit Address Match.
• ADR: Slave Address
Slave address used in slave address match. Bits 9:0 are used if in 10-bit mode, bits 6:0 otherwise.
• SODR: Stretch Clock on Data Byte Reception
0: Does not stretch bus clock immediately before ACKing a received data byte.
1: Stretches bus clock immediately before ACKing a received data byte.
• SOAM: Stretch Clock on Address Match
0: Does not stretch bus clock after address match.
1: Stretches bus clock after address match.
• CUP: NBYTES Count Up
0: Causes NBYTES to count down (decrement) per byte transferred.
1: Causes NBYTES to count up (increment) per byte transferred.
• ACK: Slave Receiver Data Phase ACK Value
0: Causes a low value to be returned in the ACK cycle of the data phase in slave receiver mode.
1: Causes a high value to be returned in the ACK cycle of the data phase in slave receiver mode.
• PECEN: Packet Error Checking Enable
0: Disables SMBus PEC (CRC) generation and check.
1: Enables SMBus PEC (CRC) generation and check.
• SMHH: SMBus Host Header
0: Causes the TWIS not to acknowledge the SMBus Host Header.
1: Causes the TWIS to acknowledge the SMBus Host Header.
• SMDA: SMBus Default Address
0: Causes the TWIS not to acknowledge the SMBus Default Address.
1: Causes the TWIS to acknowledge the SMBus Default Address.
• SMBALERT: SMBus Alert
0: Causes the TWIS to release the SMBALERT line and not to acknowledge the SMBus Alert Response Address (ARA).
1: Causes the TWIS to pull down the SMBALERT line and to acknowledge the SMBus Alert Response Address (ARA).
31 30 29 28 27 26 25 24
- - - - - TENBIT ADR[9:8]
23 22 21 20 19 18 17 16
ADR[7:0]
15 14 13 12 11 10 9 8
SODR SOAM CUP ACK PECEN SMHH SMDA SMBALERT
76543210
SWRST - - STREN GCMATCH SMATCH SMEN SEN
576
32142D–06/2013
ATUC64/128/256L3/4U
• SWRST: Software Reset
This bit will always read as 0.
Writing a zero to this bit has no effect.
Writing a one to this bit resets the TWIS.
• STREN: Clock Stretch Enable
0: Disables clock stretching if RHR/THR buffer full/empty. May cause over/underrun.
1: Enables clock stretching if RHR/THR buffer full/empty.
• GCMATCH: General Call Address Match
0: Causes the TWIS not to acknowledge the General Call Address.
1: Causes the TWIS to acknowledge the General Call Address.
• SMATCH: Slave Address Match
0: Causes the TWIS not to acknowledge the Slave Address.
1: Causes the TWIS to acknowledge the Slave Address.
• SMEN: SMBus Mode Enable
0: Disables SMBus mode.
1: Enables SMBus mode.
• SEN: Slave Enable
0: Disables the slave interface.
1: Enables the slave interface.
577
32142D–06/2013
ATUC64/128/256L3/4U
23.9.2 NBYTES Register
Name: NBYTES
Access Type: Read/Write
Offset: 0x04
Reset Value: 0x00000000
• NBYTES: Number of Bytes to Transfer
Writing to this field updates the NBYTES counter. The field can also be read to learn the progress of the transfer. NBYTES can
be incremented or decremented automatically by hardware.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
NBYTES
578
32142D–06/2013
ATUC64/128/256L3/4U
23.9.3 Timing Register
Name: TR
Access Type: Read/Write
Offset: 0x08
Reset Value: 0x00000000
• EXP: Clock Prescaler
Used to specify how to prescale the SMBus TLOWS counter. The counter is prescaled according to the following formula:
• SUDAT: Data Setup Cycles
Non-prescaled clock cycles for data setup count. Used to time TSU_DAT. Data is driven SUDAT cycles after TWCK low detected.
This timing is used for timing the ACK/NAK bits, and any data bits driven in slave transmitter mode.
• TTOUT: SMBus TTIMEOUT Cycles
Prescaled clock cycles used to time SMBus TTIMEOUT.
• TLOWS: SMBus TLOW:SEXT Cycles
Prescaled clock cycles used to time SMBus TLOW:SEXT.
31 30 29 28 27 26 25 24
EXP - - - -
23 22 21 20 19 18 17 16
SUDAT
15 14 13 12 11 10 9 8
TTOUT
76543210
TLOWS
f
PRESCALED
f
CLK_TWIS
2 EXP 1 + = ------------------------
579
32142D–06/2013
ATUC64/128/256L3/4U
23.9.4 Receive Holding Register
Name: RHR
Access Type: Read-only
Offset: 0x0C
Reset Value: 0x00000000
• RXDATA: Received Data Byte
When the RXRDY bit in the Status Register (SR) is one, this field contains a byte received from the TWI bus.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
RXDATA
580
32142D–06/2013
ATUC64/128/256L3/4U
23.9.5 Transmit Holding Register
Name: THR
Access Type: Write-only
Offset: 0x10
Reset Value: 0x00000000
• TXDATA: Data Byte to Transmit
Write data to be transferred on the TWI bus here.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
TXDATA
581
32142D–06/2013
ATUC64/128/256L3/4U
23.9.6 Packet Error Check Register
Name: PECR
Access Type: Read-only
Offset: 0x14
Reset Value: 0x00000000
• PEC: Calculated PEC Value
The calculated PEC value. Updated automatically by hardware after each byte has been transferred. Reset by hardware after a
STOP condition. Provided if the user manually wishes to control when the PEC byte is transmitted, or wishes to access the PEC
value for other reasons. In ordinary operation, the PEC handling is done automatically by hardware.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
PEC
582
32142D–06/2013
ATUC64/128/256L3/4U
23.9.7 Status Register
Name: SR
Access Type: Read-only
Offset: 0x18
Reset Value: 0x000000002
• BTF: Byte Transfer Finished
This bit is cleared when the corresponding bit in SCR is written to one.
This bit is set when byte transfer has completed.
• REP: Repeated Start Received
This bit is cleared when the corresponding bit in SCR is written to one.
This bit is set when a REPEATED START condition is received.
• STO: Stop Received
This bit is cleared when the corresponding bit in SCR is written to one.
This bit is set when the STOP condition is received.
• SMBDAM: SMBus Default Address Match
This bit is cleared when the corresponding bit in SCR is written to one.
This bit is set when the received address matched the SMBus Default Address.
• SMBHHM: SMBus Host Header Address Match
This bit is cleared when the corresponding bit in SCR is written to one.
This bit is set when the received address matched the SMBus Host Header Address.
• SMBALERTM: SMBus Alert Response Address Match
This bit is cleared when the corresponding bit in SCR is written to one.
This bit is set when the received address matched the SMBus Alert Response Address.
• GCM: General Call Match
This bit is cleared when the corresponding bit in SCR is written to one.
This bit is set when the received address matched the General Call Address.
• SAM: Slave Address Match
This bit is cleared when the corresponding bit in SCR is written to one.
This bit is set when the received address matched the Slave Address.
• BUSERR: Bus Error
This bit is cleared when the corresponding bit in SCR is written to one.
This bit is set when a misplaced START or STOP condition has occurred.
31 30 29 28 27 26 25 24
-- - -----
23 22 21 20 19 18 17 16
BTF REP STO SMBDAM SMBHHM SMBALERTM GCM SAM
15 14 13 12 11 10 9 8
- BUSERR SMBPECERR SMBTOUT - - - NAK
76 5 43210
ORUN URUN TRA - TCOMP SEN TXRDY RXRDY
583
32142D–06/2013
ATUC64/128/256L3/4U
• SMBPECERR: SMBus PEC Error
This bit is cleared when the corresponding bit in SCR is written to one.
This bit is set when a SMBus PEC error has occurred.
• SMBTOUT: SMBus Timeout
This bit is cleared when the corresponding bit in SCR is written to one.
This bit is set when a SMBus timeout has occurred.
• NAK: NAK Received
This bit is cleared when the corresponding bit in SCR is written to one.
This bit is set when a NAK was received from the master during slave transmitter operation.
• ORUN: Overrun
This bit is cleared when the corresponding bit in SCR is written to one.
This bit is set when an overrun has occurred in slave receiver mode. Can only occur if CR.STREN is zero.
• URUN: Underrun
This bit is cleared when the corresponding bit in SCR is written to one.
This bit is set when an underrun has occurred in slave transmitter mode. Can only occur if CR.STREN is zero.
• TRA: Transmitter Mode
0: The slave is in slave receiver mode.
1: The slave is in slave transmitter mode.
• TCOMP: Transmission Complete
This bit is cleared when the corresponding bit in SCR is written to one.
This bit is set when transmission is complete. Set after receiving a STOP after being addressed.
• SEN: Slave Enabled
0: The slave interface is disabled.
1: The slave interface is enabled.
• TXRDY: TX Buffer Ready
0: The TX buffer is full and should not be written to.
1: The TX buffer is empty, and can accept new data.
• RXRDY: RX Buffer Ready
0: No RX data ready in RHR.
1: RX data is ready to be read from RHR.
584
32142D–06/2013
ATUC64/128/256L3/4U
23.9.8 Interrupt Enable Register
Name: IER
Access Type: Write-only
Offset: 0x1C
Reset Value: 0x00000000
Writing a zero to a bit in this register has no effect.
Writing a one to a bit in this register will write a one to the corresponding bit in IMR.
31 30 29 28 27 26 25 24
-- - -----
23 22 21 20 19 18 17 16
BTF REP STO SMBDAM SMBHHM SMBALERTM GCM SAM
15 14 13 12 11 10 9 8
- BUSERR SMBPECERR SMBTOUT - - - NAK
76 5 43210
ORUN URUN - - TCOMP - TXRDY RXRDY
585
32142D–06/2013
ATUC64/128/256L3/4U
23.9.9 Interrupt Disable Register
Name: IDR
Access Type: Write-only
Offset: 0x20
Reset Value: 0x00000000
Writing a zero to a bit in this register has no effect.
Writing a one to a bit in this register will clear the corresponding bit in IMR.
31 30 29 28 27 26 25 24
-- - -----
23 22 21 20 19 18 17 16
BTF REP STO SMBDAM SMBHHM SMBALERTM GCM SAM
15 14 13 12 11 10 9 8
- BUSERR SMBPECERR SMBTOUT - - - NAK
76 5 43210
ORUN URUN - - TCOMP - TXRDY RXRDY
586
32142D–06/2013
ATUC64/128/256L3/4U
23.9.10 Interrupt Mask Register
Name: IMR
Access Type: Read-only
Offset: 0x24
Reset Value: 0x00000000
0: The corresponding interrupt is disabled.
1: The corresponding interrupt is enabled.
This bit is cleared when the corresponding bit in IDR is written to one.
This bit is set when the corresponding bit in IER is written to one.
31 30 29 28 27 26 25 24
-- - -----
23 22 21 20 19 18 17 16
BTF REP STO SMBDAM SMBHHM SMBALERTM GCM SAM
15 14 13 12 11 10 9 8
- BUSERR SMBPECERR SMBTOUT - - - NAK
76 5 43210
ORUN URUN - - TCOMP - TXRDY RXRDY
587
32142D–06/2013
ATUC64/128/256L3/4U
23.9.11 Status Clear Register
Name: SCR
Access Type: Write-only
Offset: 0x28
Reset Value: 0x00000000
Writing a zero to a bit in this register has no effect.
Writing a one to a bit in this register will clear the corresponding bit in SR and the corresponding interrupt request.
31 30 29 28 27 26 25 24
-- - -----
23 22 21 20 19 18 17 16
BTF REP STO SMBDAM SMBHHM SMBALERTM GCM SAM
15 14 13 12 11 10 9 8
- BUSERR SMBPECERR SMBTOUT - - - NAK
76 5 43210
ORUN URUN - - TCOMP - - -
588
32142D–06/2013
ATUC64/128/256L3/4U
23.9.12 Parameter Register
Name: PR
Access Type: Read-only
Offset: 0x2C
Reset Value: -
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
--------
589
32142D–06/2013
ATUC64/128/256L3/4U
23.9.13 Version Register (VR)
Name: VR
Access Type: Read-only
Offset: 0x30
Reset Value: -
• VARIANT: Variant Number
Reserved. No functionality associated.
• VERSION: Version Number
Version number of the module. No functionality associated.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
- - - - VARIANT
15 14 13 12 11 10 9 8
- - - - VERSION [11:8]
76543210
VERSION [7:0]
590
32142D–06/2013
ATUC64/128/256L3/4U
23.10 Module Configuration
The specific configuration for each TWIS instance is listed in the following tables.The module
bus clocks listed here are connected to the system bus clocks. Please refer to the Power Manager
chapter for details.
Table 23-7. Module Clock Name
Module Name Clock Name Description
TWIS0 CLK_TWIS0 Clock for the TWIS0 bus interface
TWIS1 CLK_TWIS1 Clock for the TWIS1 bus interface
Table 23-8. Register Reset Values
Register Reset Value
VERSION 0x00000120
PARAMETER 0x00000000
591
32142D–06/2013
ATUC64/128/256L3/4U
24. Inter-IC Sound Controller (IISC)
Rev: 1.0.0.0
24.1 Features
• Compliant with Inter-IC Sound (I2
S) bus specification
• Master, slave, and controller modes:
– Slave: data received/transmitted
– Master: data received/transmitted and clocks generated
– Controller: clocks generated
• Individual enable and disable of receiver, transmitter, and clocks
• Configurable clock generator common to receiver and transmitter:
– Suitable for a wide range of sample frequencies (fs), including 32kHz, 44.1kHz, 48kHz,
88.2kHz, 96kHz, and 192kHz
– 16fs to 1024fs Master Clock generated for external oversampling ADCs
• Several data formats supported:
– 32-, 24-, 20-, 18-, 16-, and 8-bit mono or stereo format
– 16- and 8-bit compact stereo format, with left and right samples packed in the same word to
reduce data transfers
• DMA interfaces for receiver and transmitter to reduce processor overhead:
– Either one DMA channel for both audio channels, or
– One DMA channel per audio channel
• Smart holding registers management to avoid audio channels mix after overrun or underrun
24.2 Overview
The Inter-IC Sound Controller (IISC) provides a 5-wire, bidirectional, synchronous, digital audio
link with external audio devices: ISDI, ISDO, IWS, ISCK, and IMCK pins.
This controller is compliant with the Inter-IC Sound (I2
S) bus specification.
The IISC consists of a Receiver, a Transmitter, and a common Clock Generator, that can be
enabled separately, to provide Master, Slave, or Controller modes with Receiver, Transmitter, or
both active.
Peripheral DMA channels, separate for the Receiver and for the Transmitter, allow a continuous
high bitrate data transfer without processor intervention to the following:
• Audio CODECs in Master, Slave, or Controller mode
• Stereo DAC or ADC through dedicated I2
S serial interface
The IISC can use either a single DMA channel for both audio channels or one DMA channel per
audio channel.
The 8- and 16-bit compact stereo format allows reducing the required DMA bandwidth by transferring
the left and right samples within the same data word.
In Master Mode, the IISC allows outputting a 16 fs to 1024fs Master Clock, in order to provide an
oversampling clock to an external audio codec or digital signal processor (DSP).
592
32142D–06/2013
ATUC64/128/256L3/4U
24.3 Block Diagram
Figure 24-1. IISC Block Diagram
24.4 I/O Lines Description
24.5 Product Dependencies
In order to use this module, other parts of the system must be configured correctly, as described
below.
24.5.1 I/O lines
The IISC pins may be multiplexed with I/O Controller lines. The user must first program the I/O
Controller to assign the desired IISC pins to their peripheral function. If the IISC I/O lines are not
used by the application, they can be used for other purposes by the I/O Controller. It is required
to enable only the IISC inputs and outputs actually in use.
24.5.2 Power Management
If the CPU enters a sleep mode that disables clocks used by the IISC, the IISC will stop functioning
and resume operation after the system wakes up from sleep mode.I/O Controller
ISCK
IWS
ISDI
ISDO
IMCK
Receiver
Clocks
Transmitter
Peripheral Bus interface
Generic clock
PB Peripheral
Bus Bridge
Interrupt
Controller
SCIF
Power
Manager PB clock
IRQ
Peripheral
DMA
Controller
Rx
Tx
IISC
Table 24-1. I/O Lines Description
Pin Name Pin Description Type
IMCK Master Clock Output
ISCK Serial Clock Input/Output
IWS I2
S Word Select Input/Output
ISDI Serial Data Input Input
ISDO Serial Data Output Output
593
32142D–06/2013
ATUC64/128/256L3/4U
24.5.3 Clocks
The clock for the IISC bus interface (CLK_IISC) is generated by the Power Manager. This clock
is enabled at reset, and can be disabled in the Power Manager. It is recommended to disable the
IISC before disabling the clock, to avoid freezing the IISC in an undefined state.
One of the generic clocks is connected to the IISC. The generic clock (GCLK_IISC) can be set to
a wide range of frequencies and clock sources. The GCLK_IISC must be enabled and configured
before use. Refer to the module configuration section for details on the GCLK_IISC used
for the IISC. The frequency for this clock has to be set as described in Table.
24.5.4 DMA
The IISC DMA handshake interfaces are connected to the Peripheral DMA Controller. Using the
IISC DMA functionality requires the Peripheral DMA Controller to be programmed first.
24.5.5 Interrupts
The IISC interrupt line is connected to the Interrupt Controller. Using the IISC interrupt requires
the Interrupt Controller to be programmed first.
24.5.6 Debug Operation
When an external debugger forces the CPU into debug mode, the IISC continues normal operation.
If this module is configured in a way that requires it to be periodically serviced by the CPU
through interrupt requests or similar, improper operation or data loss may result during
debugging.
24.6 Functional Description
24.6.1 Initialization
The IISC features a Receiver, a Transmitter, and, for Master and Controller modes, a Clock
Generator. Receiver and Transmitter share the same Serial Clock and Word Select.
Before enabling the IISC, the chosen configuration must be written to the Mode Register (MR).
The IMCKMODE, MODE, and DATALENGTH fields in the MR register must be written. If the
IMCKMODE field is written as one, then the IMCKFS field should be written with the chosen
ratio, as described in Section 24.6.5 ”Serial Clock and Word Select Generation” on page 595.
Once the Mode Register has been written, the IISC Clock Generator, Receiver, and Transmitter
can be enabled by writing a one to the CKEN, RXEN, and TXEN bits in the Control Register
(CR). The Clock Generator can be enabled alone, in Controller Mode, to output clocks to the
IMCK, ISCK, and IWS pins. The Clock Generator must also be enabled if the Receiver or the
Transmitter is enabled.
The Clock Generator, Receiver, and Transmitter can be disabled independently by writing a one
to CR.CXDIS, CR.RXDIS and/or CR.TXDIS respectively. Once requested to stop, they will only
stop when the transmission of the pending frame transmission will be completed.
24.6.2 Basic Operation
The Receiver can be operated by reading the Receiver Holding Register (RHR), whenever the
Receive Ready (RXRDY) bit in the Status Register (SR) is set. Successive values read from
RHR will correspond to the samples from the left and right audio channels for the successive
frames.
594
32142D–06/2013
ATUC64/128/256L3/4U
The Transmitter can be operated by writing to the Transmitter Holding Register (RHR), whenever
the Transmit Ready (TXRDY) bit in the Status Register (SR) is set. Successive values
written to THR should correspond to the samples from the left and right audio channels for the
successive frames.
The Receive Ready and Transmit Ready bits can be polled by reading the Status Register.
The IISC processor load can be reduced by enabling interrupt-driven operation. The RXRDY
and/or TXRDY interrupt requests can be enabled by writing a one to the corresponding bit in the
Interrupt Enable Register (IER). The interrupt service routine associated to the IISC interrupt
request will then be executed whenever the Receive Ready or the Transmit Ready status bit is
set.
24.6.3 Master, Controller, and Slave Modes
In Master and Controller modes, the IISC provides the Master Clock, the Serial Clock and the
Word Select. IMCK, ISCK, and IWS pins are outputs.
In Controller mode, the IISC Receiver and Transmitter are disabled. Only the clocks are enabled
and used by an external receiver and/or transmitter.
In Slave mode, the IISC receives the Serial Clock and the Word Select from an external master.
ISCK and IWS pins are inputs.
The mode is selected by writing the MODE field of the Mode Register (MR). Since the MODE
field changes the direction of the IWS and ISCK pins, the Mode Register should only be written
when the IISC is stopped, in order to avoid unwanted glitches on the IWS and ISCK pins.
24.6.4 I2
S Reception and Transmission Sequence
As specified in the I2
S protocol, data bits are left-adjusted in the Word Select time slot, with the
MSB transmitted first, starting one clock period after the transition on the Word Select line.
Figure 24-2. I
2
S Reception and Transmission Sequence
Data bits are sent on the falling edge of the Serial Clock and sampled on the rising edge of the
Serial Clock. The Word Select line indicates the channel in transmission, a low level for the left
channel and a high level for the right channel.
The length of transmitted words can be chosen among 8, 16, 18, 20, 24, and 32 bits by writing
the MR.DATALENGTH field.
If the time slot allows for more data bits than written in the MR.DATALENGTH field, zeroes are
appended to the transmitted data word or extra received bits are discarded. If the time slot
allows for less data bits than written, the extra bits to be transmitted are not sent or the missing
bits are set to zero in the received data word.
Serial Clock ISCK
Word Select IWS
Data ISDI/ISDO MSB
Left Channel
LSB MSB
Right Channel
595
32142D–06/2013
ATUC64/128/256L3/4U
24.6.5 Serial Clock and Word Select Generation
The generation of clocks in the IISC is described in Figure 24-3 on page 596.
In Slave mode, the Serial Clock and Word Select Clock are driven by an external master. ISCK
and IWS pins are inputs and no generic clock is required by the IISC.
In Master mode, the user can configure the Master Clock, Serial Clock, and Word Select Clock
through the Mode Register (MR). IMCK, ISCK, and IWS pins are outputs and a generic clock is
used to derive the IISC clocks.
Audio codecs connected to the IISC pins may require a Master Clock signal with a frequency
multiple of the audio sample frequency (fs), such as 256fs. When the IISC is in Master mode,
writing a one to MR.IMCKMODE will output GCLK_IISC as Master Clock to the IMCK pin, and
will divide GCLK_IISC to create the internal bit clock, output on the ISCK pin. The clock division
factor is defined by writing to MR.IMCKFS and MR.DATALENGTH, as described ”IMCKFS:
Master Clock to fs Ratio” on page 602.
The Master Clock (IMCK) frequency is 16*(IMCKFS+1) times the sample frequency (fs), i.e. IWS
frequency. The Serial Clock (ISCK) frequency is 2*Slot Length times the sample frequency (fs),
where Slot Length is defined in Table 24-2 on page 595.
Warning: MR.IMCKMODE should only be written as one if the Master Clock frequency is strictly
higher than the Serial Clock.
If a Master Clock output is not required, the GCLK_IISC generic clock is used as ISCK, by writing
a zero to MR.IMCKMODE. Alternatively, if the frequency of the generic clock used is a
multiple of the required ISCK frequency, the IMCK to ISCK divider can be used with the ratio
defined by writing the MR.IMCKFS field.
The IWS pin is used as Word Select as described in Section 24.6.4.
Table 24-2. Slot Length
MR.DATALENGTH Word Length Slot Length
0 32 bits 32
1 24 bits
32 if MR.IWS24 is zero
24 if MR.IWS24 is one 2 20 bits
3 18 bits
4 16 bits
16
5 16 bits compact stereo
6 8 bits
8
7 8 bits compact stereo
596
32142D–06/2013
ATUC64/128/256L3/4U
Figure 24-3. IISC Clocks Generation
24.6.6 Mono
When the Transmit Mono (TXMONO) in the Mode Register is set, data written to the left channel
is duplicated to the right output channel.
When the Receive Mono (RXMONO) in the Mode Register is set, data received from the left
channel is duplicated to the right channel.
24.6.7 Holding Registers
The IISC user interface includes a Receive Holding Register (RHR) and a Transmit Holding
Register (THR). RHR and THR are used to access audio samples for both audio channels.
When a new data word is available in the RHR register, the Receive Ready bit (RXRDY) in the
Status Register (SR) is set. Reading the RHR register will clear this bit.
A receive overrun condition occurs if a new data word becomes available before the previous
data word has been read from the RHR register. Then, the Receive Overrun bit in the Status
Register will be set and bit i of the RXORCH field in the Status Register is set, where i is the current
receive channel number.
When the THR register is empty, the Transmit Ready bit (TXRDY) in the Status Register (SR) is
set. Writing into the THR register will clear this bit.
A transmit underrun condition occurs if a new data word needs to be transmitted before it has
been written to the THR register. Then, the Transmit Underrun bit in the Status Register will be
set and bit i of the TXORCH field in the Status Register is set, where i is the current transmit
channel number. If the TXSAME bit in the Mode Register is zero, then a zero data word is transmitted
in case of underrun. If MR.TXSAME is one, then the previous data word for the current
transmit channel number is transmitted.
MR.MODE = SLAVE Clock
divider MR.DATALENGTH
GCLK_IISC Clock
enable
Clock
divider
CR.CKEN/CKDIS MR.IMCKMODE
MR.DATALENGTH
MR.IMCKFS
MR.IMCKMODE 0 1
IMCK pin output
Clock
enable
CR.CKEN/CKDIS
Internal
bit clock ISCK pin input 1
0
ISCK pin output
Internal
word clock IWS pin input 1
0
IWS pin output
597
32142D–06/2013
ATUC64/128/256L3/4U
Data words are right-justified in the RHR and THR registers. For 16-bit compact stereo, the left
sample uses bits 15 through 0 and the right sample uses bits 31 through 16 of the same data
word. For 8-bit compact stereo, the left sample uses bits 7 through 0 and the right sample uses
bits 15 through 8 of the same data word.
24.6.8 DMA Operation
The Receiver and the Transmitter can each be connected either to one single Peripheral DMA
channel or to one Peripheral DMA channel per data channel. This is selected by writing to the
MR.RXDMA and MR.TXDMA bits. If a single Peripheral DMA channel is selected, all data samples
use IISC Receiver or Transmitter DMA channel 0.
The Peripheral DMA reads from the RHR register and writes to the RHR register for both audio
channels, successively.
The Peripheral DMA transfers may use 32-bit word, 16-bit halfword, or 8-bit byte according to
the value of the MR.DATALENGTH field.
24.6.9 Loop-back Mode
For debugging purposes, the IISC can be configured to loop back the Transmitter to the
Receiver. Writing a one to the MR.LOOP bit will internally connect ISDO to ISDI, so that the
transmitted data is also received. Writing a zero to MR.LOOP will restore the normal behavior
with independent Receiver and Transmitter. As for other changes to the Receiver or Transmitter
configuration, the IISC Receiver and Transmitter must be disabled before writing to the MR register
to update MR.LOOP.
24.6.10 Interrupts
An IISC interrupt request can be triggered whenever one or several of the following bits are set
in the Status Register (SR): Receive Ready (RXRDY), Receive Overrun (RXOR), Transmit
Ready (TXRDY), or Transmit Underrun (TXOR).
The interrupt request will be generated if the corresponding bit in the Interrupt Mask Register
(IMR) is set. Bits in IMR are set by writing a one to the corresponding bit in the Interrupt Enable
Register (IER), and cleared by writing a one to the corresponding bit in the Interrupt Disable
Register (IDR). The interrupt request remains active until the corresponding bit in SR is cleared
by writing a one the corresponding bit in the Status Clear Register (SCR).
For debugging purposes, interrupt requests can be simulated by writing a one to the corresponding
bit in the Status Set Register (SSR).
598
32142D–06/2013
ATUC64/128/256L3/4U
Figure 24-4. Interrupt Block Diagram
24.7 IISC Application Examples
The IISC can support several serial communication modes used in audio or high-speed serial
links. Some standard applications are shown in the following figures. All serial link applications
supported by the IISC are not listed here.
Figure 24-5. Audio Application Block Diagram
IER IDR IMR
Set Clear
Interrupt
Control
IISC Interrupt
Request
TXRDY
TXUR
Transmitter
Receiver
RXRDY
RXOR
Serial Clock
Word Select
Serial Data Out MSB LSB MSB
Serial Data Out
Word Select
Serial Clock
IISC
ISCK
IWS
ISDO
ISDI
EXTERNAL
I
2
S
RECEIVER
599
32142D–06/2013
ATUC64/128/256L3/4U
Figure 24-6. Codec Application Block Diagram
Figure 24-7. Time Slot Application Block Diagram
IISC Word Select
Serial Data Out
Serial Data In
EXTERNAL
AUDIO
CODEC
IMCK
IWS
ISDO
ISDI
Serial Clock
Master Clock
ISCK
Right Time Slot
Serial Clock
Word Select
Serial Data Out
Serial Data In
Dstart Dend
Left Time Slot
EXTERNAL
AUDIO
CODEC
for Left
Time Slot
EXTERNAL
AUDIO
CODEC
for Right
Time Slot
Serial Data In
Serial Data Out
Word Select
Serial Clock
Serial Clock
Word Select
Serial Data Out
Serial Data In
Dstart
Left Time Slot Right Time Slot
Dend
IISC
ISCK
IWS
ISDO
ISDI
Master Clock IMCK
600
32142D–06/2013
ATUC64/128/256L3/4U
24.8 User Interface
Note: 1. The reset values for these registers are device specific. Please refer to the Module Configuration section at the end of this
chapter.
Table 24-3. IISC Register Memory Map
Offset Register Register Name Access Reset
0x00 Control Register CR Write-only 0x00000000
0x04 Mode Register MR Read/Write 0x00000000
0x08 Status Register SR Read-only 0x00000000
0x0C Status Clear Register SCR Write-only 0x00000000
0x10 Status Set Register SSR Write-only 0x00000000
0x14 Interrupt Enable Register IER Write-only 0x00000000
0x18 Interrupt Disable Register IDR Write-only 0x00000000
0x1C Interrupt Mask Register IMR Read-only 0x00000000
0x20 Receiver Holding Register RHR Read-only 0x00000000
0x24 Transmitter Holding Register THR Write-only 0x00000000
0x28 Version Register VERSION Read-only -
(1)
0x2C Parameter Register PARAMETER Read-only -
(1)
601
32142D–06/2013
ATUC64/128/256L3/4U
24.8.1 Control Register
Name: CR
Access Type: Write-only
Offset: 0x00
Reset Value: 0x00000000
The Control Register should only be written to enable the IISC after the chosen configuration has been written to the Mode
Register, in order to avoid unwanted glitches on the IWS, ISCK, and ISDO outputs. The proper sequence is to write the MR
register, then write the CR register to enable the IISC, or to disable the IISC before writing a new value into MR.
• SWRST: Software Reset
Writing a zero to this bit has no effect.
Writing a one to this bit resets all the registers in the module. The module will be disabled after the reset.
This bit always reads as zero.
• TXDIS: Transmitter Disable
Writing a zero to this bit has no effect.
Writing a one to this bit disables the IISC Transmitter. SR.TXEN will be cleared when the Transmitter is effectively stopped.
• TXEN: Transmitter Enable
Writing a zero to this bit has no effect.
Writing a one to this bit enables the IISC Transmitter, if TXDIS is not one. SR.TXEN will be set when the Transmitter is effectively
started.
• CKDIS: Clocks Disable
Writing a zero to this bit has no effect.
Writing a one to this bit disables the IISC clocks generation.
• CKEN: Clocks Enable
Writing a zero to this bit has no effect.
Writing a one to this bit enables the IISC clocks generation, if CKDIS is not one.
• RXDIS: Receiver Disable
Writing a zero to this bit has no effect.
Writing a one to this bit disables the IISC Receiver. SR.TXEN will be cleared when the Transmitter is effectively stopped.
• RXEN: Receiver Enable
Writing a zero to this bit has no effect.
Writing a one to this bit enables the IISC Receiver, if RXDIS is not one. SR.RXEN will be set when the Receiver is effectively
started.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
SWRST - TXDIS TXEN CKDIS CKEN RXDIS RXEN
602
32142D–06/2013
ATUC64/128/256L3/4U
24.8.2 Mode Register
Name: MR
Access Type: Read/Write
Offset: 0x04
Reset Value: 0x00000000
The Mode Register should only be written when the IISC is stopped, in order to avoid unwanted glitches on the IWS, ISCK,
and ISDO outputs. The proper sequence is to write the MR register, then write the CR register to enable the IISC, or to disable
the IISC before writing a new value into MR.
• IWS24: IWS TDM Slot Width
0: IWS slot is 32-bit wide for DATALENGTH=18/20/24-bit
1: IWS slot is 24-bit wide for DATALENGTH=18/20/24-bit
Refer to Table 24-2, “Slot Length,” on page 595.
• IMCKMODE: Master Clock Mode
0: No Master Clock generated (generic clock is used as ISCK output)
1: Master Clock generated (generic clock is used as IMCK output)
Warning: if IMCK frequency is the same as ISCK, IMCKMODE should not be written as one. Refer to Section 24.6.5 ”Serial
Clock and Word Select Generation” on page 595 and Table 24-2, “Slot Length,” on page 595.
• IMCKFS: Master Clock to fs Ratio
Master Clock frequency is 16*(IMCKFS+1) times the sample rate, i.e. IWS frequency:
31 30 29 28 27 26 25 24
IWS24 IMCKMODE IMCKFS
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
- TXSAME TXDMA TXMONO RXLOOP RXDMA RXMONO
76543210
- - - DATALENGTH - MODE
Table 24-4. Master Clock to Sample Frequency (fs) Ratio
fs Ratio IMCKFS
16 fs 0
32 fs 1
48fs 2
64 fs 3
96fs 5
128 fs 7
192fs 11
256 fs 15
603
32142D–06/2013
ATUC64/128/256L3/4U
• TXSAME: Transmit Data when Underrun
0: Zero sample transmitted when underrun
1: Previous sample transmitted when underrun
• TXDMA: Single or multiple DMA Channels for Transmitter
0: Transmitter uses a single DMA channel for both audio channels
1: Transmitter uses one DMA channel per audio channel
• TXMONO: Transmit Mono
0: Stereo
1: Mono, with left audio samples duplicated to right audio channel by the IISC
• RXLOOP: Loop-back Test Mode
0: Normal mode
1: ISDO output of IISC is internally connected to ISDI input
• RXMONO: Receive Mono
0: Stereo
1: Mono, with left audio samples duplicated to right audio channel by the IISC
• RXDMA: Single or multiple DMA Channels for Receiver
0: Receiver uses a single DMA channel for both audio channels
1: Receiver uses one DMA channel per audio channel-
• DATALENGTH: Data Word Length
• MODE: Mode
384 fs 23
512 fs 31
768 fs 47
1024 fs 63
Table 24-5. Data Word Length
DATALENGTH Word Length Comments
0 32 bits
1 24 bits
2 20 bits
3 18 bits
4 16 bits
5 16 bits compact stereo Left sample in bits 15 through 0 and right sample in bits 31 through 16 of the same word
6 8 bits
7 8 bits compact stereo Left sample in bits 7 through 0 and right sample in bits 15 through 8 of the same word
Table 24-6. Mode
MODE Comments
0 SLAVE ISCK and IWS pin inputs used as Bit Clock and Word Select/Frame Sync.
1 MASTER Bit Clock and Word Select/Frame Sync generated by IISC from GCLK_IISC and output to ISCK and IWS pins.
GCLK_IISC is output as Master Clock on IMCK if MR.IMCKMODE is one.
Table 24-4. Master Clock to Sample Frequency (fs) Ratio
fs Ratio IMCKFS
604
32142D–06/2013
ATUC64/128/256L3/4U
24.8.3 Status Register
Name: SR
Access Type: Read-only
Offset: 0x08
Reset Value: 0x00000000
• TXURCH: Transmit Underrun Channel
This field is cleared when SCR.TXUR is written to one
Bit i of this field is set when a transmit underrun error occurred in channel i (i=0 for first channel of the frame)
• RXORCH: Receive Overrun Channel
This field is cleared when SCR.RXOR is written to one
Bit i of this field is set when a receive overrun error occurred in channel i (i=0 for first channel of the frame)
• TXUR: Transmit Underrun
This bit is cleared when the corresponding bit in SCR is written to one
This bit is set when an underrun error occurs on the THR register or when the corresponding bit in SSR is written to one
• TXRDY: Transmit Ready
This bit is cleared when data is written to THR
This bit is set when the THR register is empty and can be written with new data to be transmitted
• TXEN: Transmitter Enabled
This bit is cleared when the Transmitter is effectively disabled, following a CR.TXDIS or CR.SWRST request
This bit is set when the Transmitter is effectively enabled, following a CR.TXEN request
• RXOR: Receive Overrun
This bit is cleared when the corresponding bit in SCR is written to one
This bit is set when an overrun error occurs on the RHR register or when the corresponding bit in SSR is written to one
• RXRDY: Receive Ready
This bit is cleared when the RHR register is read
This bit is set when received data is present in the RHR register
• RXEN: Receiver Enabled
This bit is cleared when the Receiver is effectively disabled, following a CR.RXDIS or CR.SWRST request
This bit is set when the Receiver is effectively enabled, following a CR.RXEN request
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
- - TXURCH - - - -
15 14 13 12 11 10 9 8
- - - - - - RXORCH
76543210
- TXUR TXRDY TXEN - RXOR RXRDY RXEN
605
32142D–06/2013
ATUC64/128/256L3/4U
24.8.4 Status Clear Register
Name: SCR
Access Type: Write-only
Offset: 0x0C
Reset Value: 0x00000000
Writing a zero to a bit in this register has no effect.
Writing a one to a bit in this register will clear the corresponding bit in SR and the corresponding interrupt request.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
- - TXURCH - - - -
15 14 13 12 11 10 9 8
- - - - - - RXORCH
76543210
- TXUR - - - RXOR - -
606
32142D–06/2013
ATUC64/128/256L3/4U
24.8.5 Status Set Register
Name: SSR
Access Type: Write-only
Offset: 0x10
Reset Value: 0x00000000
Writing a zero to a bit in this register has no effect.
Writing a one to a bit in this register will set the corresponding bit in SR.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
- - TXURCH - - - -
15 14 13 12 11 10 9 8
- - - - - - RXORCH
76543210
- TXUR - - - RXOR - -
607
32142D–06/2013
ATUC64/128/256L3/4U
24.8.6 Interrupt Enable Register
Name: IER
Access Type: Write-only
Offset: 0x14
Reset Value: 0x00000000
Writing a zero to a bit in this register has no effect.
Writing a one to a bit in this register will set the corresponding bit in IMR.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
- TXUR TXRDY - - RXOR RXRDY -
608
32142D–06/2013
ATUC64/128/256L3/4U
24.8.7 Interrupt Disable Register
Name: IDR
Access Type: Write-only
Offset: 0x18
Reset Value: 0x00000000
Writing a zero to a bit in this register has no effect.
Writing a one to a bit in this register will clear the corresponding bit in IMR.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
- TXUR TXRDY - - RXOR RXRDY -
609
32142D–06/2013
ATUC64/128/256L3/4U
24.8.8 Interrupt Mask Register
Name: IMR
Access Type: Read-only
Offset: 0x1C
Reset Value: 0x00000000
0: The corresponding interrupt is disabled.
1: The corresponding interrupt is enabled.
A bit in this register is cleared when the corresponding bit in IDR is written to one.
A bit in this register is set when the corresponding bit in IER is written to one.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
- TXUR TXRDY - - RXOR RXRDY -
610
32142D–06/2013
ATUC64/128/256L3/4U
24.8.9 Receive Holding Register
Name: RHR
Access Type: Read-only
Offset: 0x20
Reset Value: 0x00000000
• RHR: Received Word
This field is set by hardware to the last received data word. If MR.DATALENGTH specifies less than 32 bits, data shall be rightjustified
into the RHR field.
31 30 29 28 27 26 25 24
RHR[31:24]
23 22 21 20 19 18 17 16
RHR[23:16]
15 14 13 12 11 10 9 8
RHR[15:8]
76543210
RHR[7:0]
611
32142D–06/2013
ATUC64/128/256L3/4U
24.8.10 Transmit Holding Register
Name: THR
Access Type: Write-only
Offset: 0x24
Reset Value: 0x00000000
• THR: Data Word to Be Transmitted
Next data word to be transmitted after the current word if TXRDY is not set. If MR.DATALENGTH specifies less than 32 bits, data
shall be right-justified into the THR field.
31 30 29 28 27 26 25 24
THR[31:24]
23 22 21 20 19 18 17 16
THR[23:16]
15 14 13 12 11 10 9 8
THR[15:8]
76543210
THR[7:0]
612
32142D–06/2013
ATUC64/128/256L3/4U
24.8.11 Module Version
Name: VERSION
Access Type: Read-only
Offset: 0x28
Reset Value: -
• VARIANT: Variant Number
Reserved. No functionality associated.
• VERSION: Version Number
Version number of the module. No functionality associated.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
- - - - VARIANT
15 14 13 12 11 10 9 8
- - - - VERSION[11:8]
76543210
VERSION[7:0]
613
32142D–06/2013
ATUC64/128/256L3/4U
24.8.12 Module Parameters
Name: PARAMETER
Access Type: Read-only
Offset: 0x2C
Reset Value: -
Reserved. No functionality associated.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
--------
614
32142D–06/2013
ATUC64/128/256L3/4U
24.9 Module configuration
The specific configuration for each IISC instance is listed in the following tables. The module bus
clocks listed here are connected to the system bus clocks. Please refer to the Power Manager
chapter for details.
Table 24-7. IISC Clocks
Clock Name Description
CLK_IISC Clock for the IISC bus interface
GCLK The generic clock used for the IISC is GCLK6
Table 24-8. Register Reset Values
Register Reset Value
VERSION 0x00000100
615
32142D–06/2013
ATUC64/128/256L3/4U
25. Pulse Width Modulation Controller (PWMA)
Rev: 2.0.1.0
25.1 Features
• Left-aligned non-inverted 12-bit PWM
• Common 12-bit timebase counter
– Asynchronous clock source supported
– Spread-spectrum counter to allow a constantly varying duty cycle
• Separate 12-bit duty cycle register per channel
• Synchronized channel updates
– No glitches when changing the duty cycles
• Interlinked operation supported
– Up to 32 channels can be updated with the same duty cycle value at a time
– Up to 4 channels can be updated with different duty cycle values at a time
• Interrupt on PWM timebase overflow
• Incoming peripheral events supported
– Pre-defined channels support incoming (increase/decrease) peripheral events from the
Peripheral Event System
– Incoming increase/decrease event can either increase or decrease the duty cycle by one
• One output peripheral event supported
– Connected to channel 0 and asserted when the common timebase counter is equal to the
programmed duty cycle for channel 0
• Output PWM waveforms
– Support normal waveform output for each channel
– Support composite waveform generation (XOR’ed) for each pair channels
• Open drain driving on selected pins for 5V PWM operation
25.2 Overview
The Pulse Width Modulation Controller (PWMA) controls several pulse width modulation (PWM)
channels. The number of channels is specific to the device. Each channel controls one square
output PWM waveform. Characteristics of the output PWM waveforms such as period and duty
cycle are configured through the user interface. All user interface registers are mapped on the
peripheral bus.
The duty cycle value for each channel can be set independently, while the period is determined
by a common timebase counter (TC). The timebase for the counter is selected by using the allocated
asynchronous Generic Clock (GCLK). The user interface for the PWMA contains
handshake and synchronizing logic to ensure that no glitches occur on the output PWM waveforms
while changing the duty cycle values.
PWMA duty cycle values can be changed using two approaches, either an interlinked singlevalue
mode or an interlinked multi-value mode. In the interlinked single-value mode, any set of
channels, up to 32 channels, can be updated simultaneously with the same value while the other
channels remain unchanged. There is also an interlinked multi-value mode, where the 8 least
significant bits of up to 4 channels can be updated with 4 different values while the other channels
remain unchanged.
Some pins can be driven in open drain mode, allowing the PWMA to generate a 5V waveform
using an external pullup resistor.
616
32142D–06/2013
ATUC64/128/256L3/4U
25.3 Block Diagram
Figure 25-1. PWMA Block Diagram
25.4 I/O Lines Description
Each channel outputs one PWM waveform on one external I/O line.
25.5 Product Dependencies
In order to use this module, other parts of the system must be configured correctly, as described
below.
PWM Blocks
Channel m
Channel 1
Channel 0
Duty Cycle
Register
COMP
PWMA[m:0]
Interrupt
Handling
IRQ
PB
TOP
Timebase
Counter
SPREAD
Adjust
TOFL
READY
Channel_0
CLK_PWMA
GCLK Domain
PB Clock Domain
Spread
Spectrum
Counter
Sync
GCLK ETV
Control
Duty Cycle Channel
Select WAVEXOR
CWG
TCLR CHERR
Table 25-1. I/O Line Description
Pin Name Pin Description Type
PWMA[n] Output PWM waveform for one channel n Output
PWMMOD[n] Output PWM waveform for one channel n, open drain mode Output
617
32142D–06/2013
ATUC64/128/256L3/4U
25.5.1 I/O Lines
The pins used for interfacing the PWMA may be multiplexed with I/O Controller lines. The programmer
must first program the I/O Controller to assign the desired PWMA pins to their
peripheral function.
It is only required to enable the PWMA outputs actually in use.
25.5.2 Power Management
If the CPU enters a sleep mode that disables clocks used by the PWMA, the PWMA will stop
functioning and resume operation after the system wakes up from sleep mode.
25.5.3 Clocks
The clock for the PWMA bus interface (CLK_PWMA) is controlled by the Power Manager. This
clock is enabled at reset, and can be disabled in the Power Manager. It is recommended to disable
the PWMA before disabling the clock, to avoid freezing the PWMA in an undefined state.
Additionally, the PWMA depends on a dedicated Generic Clock (GCLK). The GCLK can be set
to a wide range of frequencies and clock sources and must be enabled in the System Control
Interface (SCIF) before the PWMA can be used.
25.5.4 Interrupts
The PWMA interrupt request lines are connected to the interrupt controller. Using the PWMA
interrupts requires the interrupt controller to be programmed first.
25.5.5 Peripheral Events
The PWMA peripheral events are connected via the Peripheral Event System. Refer to the
Peripheral Event System chapter for details.
25.5.6 Debug Operation
When an external debugger forces the CPU into debug mode, the PWMA continues normal
operation. If the PWMA is configured in a way that requires it to be periodically serviced by the
CPU through interrupts, improper operation or data loss may result during debugging.
25.6 Functional Description
The PWMA embeds a number of PWM channel submodules, each providing an output PWM
waveform. Each PWM channel contains a duty cycle register and a comparator. A common
timebase counter for all channels determines the frequency and the period for all the PWM
waveforms.
25.6.1 Enabling the PWMA
Once the GCLK has been enabled, the PWMA is enabled by writing a one to the EN bit in the
Control Register (CR).
25.6.2 Timebase Counter
The top value of the timebase counter defines the period of the PWMA output waveform. The
timebase counter starts at zero when the PWMA is enabled and counts upwards until it reaches
its effective top value (ETV). The effective top value is defined by specifying the desired number
of GCLK clock cycles in the TOP field of Top Value Register (TVR.TOP) in normal operation (the
618
32142D–06/2013
ATUC64/128/256L3/4U
SPREAD field of CR (CR.SPREAD) is zero). When the timebase counter reaches its effective
top value, it restarts counting from zero. The period of the PWMA output waveform is then:
The timebase counter can be reset by writing a one to the Timebase Clear bit in CR (CR.TCLR).
Note that this can cause a glitch to the output PWM waveforms in use.
25.6.3 Spread Spectrum Counter
The spread spectrum counter allows the generation of constantly varying duty cycles on the output
PWM waveforms. This is achieved by varying the effective top value of the timebase counter
in a range defined by the spread spectrum counter value.
When CR.SPREAD is not zero, the spread spectrum counter is enabled. Its range is defined by
CR.SPREAD. It starts to count from -CR.SPREAD when the PWMA is enabled or after reset
and counts upwards. When it reaches CR.SPREAD, it restarts to count from -CR.SPREAD
again. The spread spectrum counter will cause the effective top value to vary from TOPSPREAD
to TOP+SPREAD. Figure 25-2 on page 618 illustrates this. This leads to a constantly
varying duty cycle on the PWM output waveforms though the duty cycle values stored are
unchanged.
Figure 25-2. PWMA Adjusting Top Value for Timebase Counter
25.6.3.1 Special considerations
The maximum value of the timebase counter is 0x0FFF. If SPREAD is written to a value that will
cause the ETV to exceed this value, the spread spectrum counter’s range will be limited to prevent
the timebase counter to exceed its maximum value.
If SPREAD is written to a value causing (TOP-SPREAD) to be below zero, the spread spectrum
counter’s range will be limited to prevent the timebase counter to count below zero.
In both cases, the SPREAD value read from the Control Register will be the same value as written
to the SPREAD field.
TPWMA ETV + 1 TGCLK =
0x0
0x0FFF
Duty Cycle
-SPREAD
SPREAD
TOP Adjusting top value range
for the timerbase counter
619
32142D–06/2013
ATUC64/128/256L3/4U
When writing a one to CR.TCLR, the timebase counter and the spread spectrum counter are
reset at their lower limit values and the effective top value of the timebase counter will also be
reset.
25.6.4 Duty Cycle and Waveform Properties
Each PWM channel has its own duty cycle value (DCV) which is write-only and cannot be read
out. The duty cycle value can be changed in two approaches as described in Section25.6.6.
When the duty cycle value is zero, the PWM output is zero. Otherwise, the PWM output is set
when the timebase counter is zero, and cleared when the timebase counter reaches the duty
cycle value. This is summarized as:
Note that when increasing the duty cycle value for one channel from 0 to 1, the number of GCLK
cycles when the PWM waveform is high will jump from 0 to 2. When incrementing the duty cycle
value by one for any other values, the number of GCLK cycle when the waveform is high will
increase by one. This is summarized in Table 25-2.
25.6.5 Waveform Output
PWMA waveforms are output to I/O lines. The output waveform properties are controlled by
Composite Waveform Generation (CWG) register(s). If this register is cleared (by default), the
channel waveforms are out directly to the I/O lines. To avoid too many I/O toggling simultaneously
on the output I/O lines, every other output PWM waveform toggles on the negative edge of
the GCLK instead of the positive edge.
In CWG mode, all channels are paired and their outputs are XOR’ed together if the corresponding
bit of CWG register is set. The even number of output is the XOR’ed output and the odd
number of output is the inverse of its. Each bit of CWG register controls one pair channels and
the least significant bit refers to the lowest number of pair channels.
25.6.6 Updating Duty Cycle Values
25.6.6.1 Interlinked Single Value PWM Operation
The PWM channels can be interlinked to allow multiple channels to be updated simultaneously
with the same duty cycle value. This value must be written to the Interlinked Single Value Duty
Table 25-2. PMW Waveform Duty Cycles
Duty Cycle Value
#Clock Cycles
When Waveform is High
#Clock Cycles
When Waveform is Low
0 0 ETV+1
1 2 ETV-1
2 3 ETV-2
... ... ...
ETV-1 ETV 1
ETV ETV+1 0
PWM Waveform = low when DCV = 0 or TC DCV
high when TC DCV and DCV 0
620
32142D–06/2013
ATUC64/128/256L3/4U
(ISDUTY) register. Each channel has a corresponding enabling bit in the Interlinked Single
Value Channel Set (ISCHSET) register(s). When a bit is written to one in the ISCHSET register,
the duty cycle register for the corresponding channel will be updated with the value stored in the
ISDUTY register. It can only be updated when the READY bit in the Status Register
(SR.READY) is one, indicating that the PWMA is ready for writing. Figure 25-3 on page 620
shows the writing procedure. It is thus possible to update the duty cycle values for up to 32 PWM
channels within one ISCHSET register at a time.
Figure 25-3. Interlinked Single Value PWM Operation Flow
25.6.6.2 Interlinked Multiple Value PWM Operation
The interlinked multiple value PWM operation allows up to four channels to be updated simultaneously
with different duty cycle values. The four duty cycle values are required to be written to
the four registers, DUTY3, DUTY2, DUTY1 and DUTY0 , respectively. The index number of the
four channels to be updated is written to the four SEL fields in the Interlinked Multiple Value
Channel Select (IMCHSEL) register (IMCHSEL.SEL). When the IMCHSEL register is written,
the values stored in the DUTY0/1/2/3 registers are synchronized to the duty cycle registers for
the channels selected by the SEL fields. Figure 25-4 on page 620 shows the writing procedure.
Note that only writes to the implemented channels will be effective. If one of the IMCHSEL.SEL
fields points to a non-existing channel, the corresponding value in the DUTYx register will not be
written. If the same channel is specified multiple times in the IMCHSEL.SEL fields, the channel
will be updated with the value referred by the upper IMCHSEL.SEL field.
When only the least significant 8-bits duty cycle value are considered for updating, the four duty
cycle values can be written to the IMDUTY register once. This is equivalent to writing the four
duty cycle values to the four DUTY registers one by one.
Figure 25-4. Interlinked Multiple Value PWM Operation Flow
ISCHSETm
...
Write
Enable
Channeln
DUTY
Channel1
DUTY
Channel0
DUTY
ISDUTY
Channel2
DUTY
DUTY3/2/1/0
IMDUTY IMCHSEL
Channeln
DUTY
...
MUX
Channel1
DUTY
Channel0
DUTY
621
32142D–06/2013
ATUC64/128/256L3/4U
25.6.7 Open Drain Mode
Some pins can be used in open drain mode, allowing the PWMA waveform to toggle between
0V and up to 5V on these pins. In this mode the PWMA will drive the pin to zero or leave the output
open. An external pullup can be used to pull the pin up to the desired voltage.
To enable open drain mode on a pin the PWMAOD function must be selected instead of the
PWMA function in the I/O Controller. Please refer to the Module Configuration chapter for information
about which pins are available in open drain mode.
25.6.8 Synchronization
Both the timebase counter and the spread spectrum counter can be reset and the duty cycle
registers can be written through the user interface of the module. This requires a synchronization
between the PB and GCLK clock domains, which takes a few clock cycles of each clock
domain. The BUSY bit in SR indicates when the synchronization is ongoing. Writing to the module
while the BUSY bit is set will result in discarding the new value.
Note that the duty cycle registers will not be updated with the new values until the timebase
counter reaches its top value, in order to avoid glitches. The BUSY bit in SR will always be set
during this updating and synchronization period.
25.6.9 Interrupts
When the timebase counter overflows, the Timebase Overflow bit in the Status Register
(SR.TOFL) is set. If the corresponding bit in the Interrupt Mask Register (IMR) is set, an interrupt
request will be generated.
Since the user needs to wait until the user interface is available between each write due to synchronization,
a READY bit is provided in SR, which can be used to generate an interrupt
request.
The interrupt request will be generated if the corresponding bit in IMR is set. Bits in IMR are set
by writing a one to the corresponding bit in the Interrupt Enable Register (IER), and cleared by
writing a one to the corresponding bit in the Interrupt Disable Register (IDR). The interrupt
request remains active until the corresponding bit in SR is cleared by writing a one to the corresponding
bit in the Status Clear Register (SCR).
25.6.10 Peripheral Events
25.6.10.1 Input Peripheral Events
The pre-defined channels support input peripheral events from the Peripheral Event System.
Input peripheral events must be enabled by writing a one to the corresponding bit in the Channel
Event Enable Registers (CHEERs) before peripheral events can be used to control the duty
cycle value. Each bit in the register corresponds to one channel, where bit 0 corresponds to
channel 0 and so on. Both the increase and decrease events are enabled for the corresponding
channel when a bit in the CHEER register is set.
An increase or decrease event (event_incr/event_decr) can either increase or decrease the duty
cycle value by one in a PWM period. The events are taken into account when the common timebase
counter reaches its top. The behavior is defined by the Channel Event Response Register
(CHERR). Each bit in the register corresponds to one channel, where bit 0 corresponds to channel
0 and so on. If the bit in CHERR is set to 0 (default) for a channel, the increase event will
increase the duty cycle value and the decrease event will decrease the duty cycle value for that
channel. If the bit is set to 1, the increase and decrease event will have reverse function so that
622
32142D–06/2013
ATUC64/128/256L3/4U
the increase event will decrease the duty cycle value and decrease event will increase the duty
cycle value. If both the increase event and the decrease event occur at the same time for a
channel, the duty cycle value will not be changed.
The number of channels supporting input peripheral events is device specific. Please refer to the
Module Configuration section at the end of this chapter for details.
25.6.10.2 Output Peripheral Event
The PWMA also supports one output peripheral event (event_ch0) to the Peripheral Event System.
This output peripheral event is connected to channel 0 and will be asserted when the
timebase counter reaches the duty cycle value for channel 0. This output event is always
enabled.
623
32142D–06/2013
ATUC64/128/256L3/4U
25.7 User Interface
Note: 1. The reset values are device specific. Please refer to the Module Configuration section at the end of this chapter.
Table 25-3. PWMA Register Memory Map
Offset Register Register Name Access Reset
0x00 Control Register CR Read/Write 0x00000000
0x04 Interlinked Single Value Duty Register ISDUTY Write-only 0x00000000
0x08 Interlinked Multiple Value Duty Register IMDUTY Write-only 0x00000000
0x0C Interlinked Multiple Value Channel Select IMCHSEL Write-only 0x00000000
0x10 Interrupt Enable Register IER Write-only 0x00000000
0x14 Interrupt Disable Register IDR Write-only 0x00000000
0x18 Interrupt Mask Register IMR Read-only 0x00000000
0x1C Status Register SR Read-only 0x00000000
0x20 Status Clear Register SCR Write-only 0x00000000
0x24 Parameter Register PARAMETER Read-only - (1)
0x28 Version Register VERSION Read-only - (1)
0x2C Top Value Register TVR Read/Write 0x00000000
0x30+m*0x10 Interlinked Single Value Channel Set m ISCHSETm Write-only 0x00000000
0x34+m*0x10 Channel Event Response Register m CHERRm Read/Write 0x00000000
0x38+m*0x10 Channel Event Enable Register m CHEERm Read/Write 0x00000000
0x3C+k*0x10 CWG Register CWGk Read/Write 0x00000000
0x80 Interlinked Multiple Value Duty0 Register DUTY0 Write-only 0x00000000
0x84 Interlinked Multiple Value Duty1 Register DUTY1 Write-only 0x00000000
0x88 Interlinked Multiple Value Duty2 Register DUTY2 Write-only 0x00000000
0x8C Interlinked Multiple Value Duty3 Register DUTY3 Write-only 0x00000000
624
32142D–06/2013
ATUC64/128/256L3/4U
25.7.1 Control Register
Name: CR
Access Type: Read/Write
Offset: 0x00
Reset Value: 0x00000000
• SPREAD: Spread Spectrum Limit Value
The spread spectrum limit value, together with the TOP field, defines the range for the spread spectrum counter. It is introduced
in order to achieve constant varying duty cycles on the output PWM waveforms. Refer to Section25.6.3 for more information.
• TOP: Timebase Counter Top Value
The top value for the timebase counter. The value written to this field will update the least significant 8 bits of the TVR.TOP field
in case only 8-bits resolution is required. The 4 most significant bits of TVR.TOP will be written to 0. When the TVR.TOP field is
written, this CR.TOP field will also be updated with only the least significant 8 bits of TVR.TOP field.
• TCLR: Timebase Clear
Writing a zero to this bit has no effect.
Writing a one to this bit will clear the timebase counter.
This bit is always read as zero.
• EN: Module Enable
0: The PWMA is disabled
1: The PWMA is enabled
31 30 29 28 27 26 25 24
- - - - - - - SPREAD[8]
23 22 21 20 19 18 17 16
SPREAD[7:0]
15 14 13 12 11 10 9 8
TOP
76543210
- - - - - - TCLR EN
625
32142D–06/2013
ATUC64/128/256L3/4U
25.7.2 Interlinked Single Value Duty Register
Name: ISDUTY
Access Type: Write-only
Offset: 0x04
Reset Value: 0x00000000
• DUTY: Duty Cycle Value
The duty cycle value written to this field is written simultaneously to all channels selected in the ISCHSETm register.
If the value zero is written to DUTY all affected channels will be disabled. In this state the output waveform will be zero all the
time.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
- - - - DUTY[11:8]
76543210
DUTY[7:0]
626
32142D–06/2013
ATUC64/128/256L3/4U
25.7.3 Interlinked Multiple Value Duty Register
Name: IMDUTY
Access Type: Write-only
Offset: 0x08
Reset Value: 0x00000000
• DUTYn: Duty Cycle
The value written to DUTY field n will be automatically written to the least significant 8 bits of the DUTYn register for a PWMA
channel while the most significant 4bits of the DUTYn register are unchanged. Which channel is selected for updating is defined
by the corresponding SEL field in the IMCHSEL register.
To write mulitple channels at a time with more than 8 bits of the duty cycle value, refer to DUTY3/2/1/0 registers.
If the value zero is written to DUTY all affected channels will be disabled. In this state the output waveform will be zero all the
time.
31 30 29 28 27 26 25 24
DUTY3
23 22 21 20 19 18 17 16
DUTY2
15 14 13 12 11 10 9 8
DUTY1
76543210
DUTY0
627
32142D–06/2013
ATUC64/128/256L3/4U
25.7.4 Interlinked Multiple Value Channel Select
Name: IMCHSEL
Access Type: Write-only
Offset: 0x0C
Reset Value: 0x00000000
• SELn: Channel Select
The duty cycle of the PWMA channel SELn will be updated with the value stored in the DUTYn register when IMCHSEL is
written. If SELn points to a non-implemented channel, the write will be discarded.
Note: The duty registers will be updated with the value stored in the DUTY3, DUTY2, DUTY1 and DUTY0 registers when the IMCHSEL
register is written. Synchronization takes place immediately when an IMCHSEL register is written. The duty cycle registers
will, however, not be updated until the synchronization is completed and the timebase counter reaches its top value in order to
avoid glitches. When only 8 bits duty cycle value are considered for updating, the four duty cycle values can be written to the
IMDUTY register once. This is equivalent to writing the 8 bits four duty cycle values to the four DUTY registers one by one while
the upper 4 bits remain unchanged.
31 30 29 28 27 26 25 24
SEL3
23 22 21 20 19 18 17 16
SEL2
15 14 13 12 11 10 9 8
SEL1
76543210
SEL0
628
32142D–06/2013
ATUC64/128/256L3/4U
25.7.5 Interrupt Enable Register
Name: IER
Access Type: Write-only
Offset: 0x10
Reset Value: 0x00000000
Writing a zero to a bit in this register has no effect
Writing a one to a bit in this register will set the corresponding bit in IMR.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
- - - - - READY - TOFL
629
32142D–06/2013
ATUC64/128/256L3/4U
25.7.6 Interrupt Disable Register
Name: IDR
Access Type: Write-only
Offset: 0x14
Reset Value: 0x00000000
Writing a zero to a bit in this register has no effect
Writing a one to a bit in this register will clear the corresponding bit in IMR.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
- - - - - READY - TOFL
630
32142D–06/2013
ATUC64/128/256L3/4U
25.7.7 Interrupt Mask Register
Name: IMR
Access Type: Read-only
Offset: 0x18
Reset Value: 0x00000000
0: The corresponding interrupt is disabled.
1: The corresponding interrupt is enabled.
A bit in this register is cleared when the corresponding bit in IDR is written to one.
A bit in this register is set when the corresponding bit in IER is written to one.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
- - - - - READY - TOFL
631
32142D–06/2013
ATUC64/128/256L3/4U
25.7.8 Status Register
Name: SR
Access Type: Read-only
Offset: 0x1C
Reset Value: 0x00000000
• BUSY: Interface Busy
This bit is automatically cleared when the interface is no longer busy.
This bit is set when the user interface is busy and will not respond to new write operations.
• READY: Interface Ready
This bit is cleared by writing a one to the corresponding bit in the SCR register.
This bit is set when the BUSY bit has a 1-to-0 transition.
• TOFL: Timebase Overflow
This bit is cleared by writing a one to corresponding bit in the SCR register.
This bit is set when the timebase counter has wrapped at its top value.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
- - - - BUSY READY - TOFL
632
32142D–06/2013
ATUC64/128/256L3/4U
25.7.9 Status Clear Register
Name: SCR
Access Type: Write-only
Offset: 0x20
Reset Value: 0x00000000
Writing a zero to a bit in this register has no effect.
Writing a one to a bit in this register will clear the corresponding bit in SR and the corresponding interrupt request.
This register always reads as zero.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 1 10 9 8
--------
76543210
- - - - - READY - TOFL
633
32142D–06/2013
ATUC64/128/256L3/4U
25.7.10 Parameter Register
Name: PARAMETER
Access Type: Read-only
Offset: 0x24
Reset Value: -
• CHANNELS: Channels Implemented
This field contains the number of channels implemented on the device.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
CHANNELS
634
32142D–06/2013
ATUC64/128/256L3/4U
25.7.11 Version Register
Name: VERSION
Access Type: Read-only
Offset: 0x28
Reset Value: -
• VARIANT: Variant Number
Reserved. No functionality associated.
• VERSION: Version Number
Version number of the module. No functionality associated.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
- - - - VARIANT
15 14 13 12 11 10 9 8
- - - - VERSION[11:8]
76543210
VERSION[7:0]
635
32142D–06/2013
ATUC64/128/256L3/4U
25.7.12 Top Value Register
Name: TVR
Access Type: Read/Write
Offset: 0x2C
Reset Value: 0x00000000
• TOP: Timebase Counter Top Value
The top value for the timebase counter. The value written to the CR.TOP field will automatically be written to the 8 least
significant bits of this field while the 4 most significant bits will be 0. When this register is written, it will also automatically update
the CR.TOP field with the 8 least significant bits.
The effective top value of the timebase counter is defined by both TVR.TOP and the CR.SPREAD. Refer to Section25.6.2 for
more information.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
- - - - TOP[11:8]
76543210
TOP[7:0]
636
32142D–06/2013
ATUC64/128/256L3/4U
25.7.13 Interlinked Single Value Channel Set
Name: ISCHSETm
Access Type: Write-only
Offset: 0x30+m*0x10
Reset Value: 0x00000000
• SET: Single Value Channel Set
If the bit n in SET is one, the duty cycle of PWMA channel n will be updated with the value written to ISDUTY.
If more than one ISCHSET register is present, ISCHSET0 controls channels 31 to 0 and ISCHSET1 controls channels 63 to 32.
Note: The duty registers will be updated with the value stored in the ISDUTY register when any ISCHSETm register is written. Synchronization
takes place immediately when an ISCHSET register is written. The duty cycle registers will, however, not be
updated until the synchronization is completed and the timebase counter reaches its top value in order to avoid glitches.
31 30 29 28 27 26 25 24
SET
23 22 21 20 19 18 17 16
SET
15 14 13 12 11 10 9 8
SET
76543210
SET
637
32142D–06/2013
ATUC64/128/256L3/4U
25.7.14 Channel Event Response Register
Name: CHERRm
Access Type: Read/Write
Offset: 0x34+m*0x10
Reset Value: 0x00000000
• CHER: Channel Event Response
0: The increase event will increase the duty cycle value by one in a PWM period for the corresponding channel and the
decrease event will decrease the duty cycle value by one.
1: The increase event will decrease the duty cycle value by one in a PWM period for the corresponding channel and the
decrease event will increase the duty cycle value by one.
The events are taken into account when the common timebase counter reaches its top.
If more than one CHERR register is present, CHERR0 controls channels 31-0 and CHERR1 controls channels 64-32 and so on.
31 30 29 28 27 26 25 24
CHER
23 22 21 20 19 18 17 16
CHER
15 14 13 12 11 10 9 8
CHER
76543210
CHER
638
32142D–06/2013
ATUC64/128/256L3/4U
25.7.15 Channel Event Enable Register
Name: CHEERm
Access Type: Read/Write
Offset: 0x38+m*0x10
Reset Value: 0x00000000
• CHEE: Channel Event Enable
0: The input peripheral event for the corresponding channel is disabled.
1: The input peripheral event for the corresponding channel is enabled.
Both increase and decrease events for channel n are enabled if bit n is one.
If more than one CHEER register is present, CHEER0 controls channels 31-0 and CHEER1 controls channels 64-32 and so on.
31 30 29 28 27 26 25 24
CHEE
23 22 21 20 19 18 17 16
CHEE
15 14 13 12 11 10 9 8
CHEE
76543210
CHEE
639
32142D–06/2013
ATUC64/128/256L3/4U
25.7.16 Composite Waveform Generation
Name: CWG
Access Type: Read/Write
Offset: 0x3C+k*0x10
Reset Value: 0x00000000
• XOR: Pair Waveform XOR’ed
If the bit n in XOR field is one, the pair of PWMA output waveforms will be XORed before output. The even number output will be
the XOR’ed output and the odd number output will be reverse of it. For example, if bit 0 in XOR is one, the pair of PWMA output
waveforms for channel 0 and 1 will be XORed together.
If bit n in XOR is zero, normal waveforms are output for that pair. Note that
If more than one CWG register is present, CWG0 controls the first 32 pairs, corresponding to channels 63 downto 0, and CWG1
controls the second 32 pairs, corresponding to channels 127 downto 64.
31 30 29 28 27 26 25 24
XOR
23 22 21 20 19 18 17 16
XOR
15 14 13 12 11 10 9 8
XOR
76543210
XOR
640
32142D–06/2013
ATUC64/128/256L3/4U
25.7.17 Interlinked Multiple Value Duty0/1/2/3 Register
Name: DUTY0/1/2/3
Access Type: Write-only
Offset: 0x80-0x8C
Reset Value: 0x00000000
These registers allows up to 4 channels to be updated with a common 12-bits duty cycle value at a time. They are the
extension of the IMDUTY register which only supports updating the least significant 8 bits of the duty registers for up to 4
channels.
• DUTY: Duty Cycle Value
The duty cycle value written to this field will be updated to the channel specified by IMCHSEL.
DUTY0 is specified by IMCHSEL.SEL0, DUTY1 is specified by IMCHSEL.SEL1, and so on.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
- - - - DUTY[11:8]
76543210
DUTY[7:0]
641
32142D–06/2013
ATUC64/128/256L3/4U
25.8 Module Configuration
The specific configuration for each PWMA instance is listed in the following tables. The module
bus clocks listed here are connected to the system bus clocks. Please refer to the Power Manager
chapter for details.
Table 25-4. PWMA Configuration
Feature PWMA
Number of PWM channels 36
Channels supporting incoming peripheral events 0, 6, 8, 9, 11, 14, 19, and 20
PWMA channels with Open Drain mode 21, 27, and 28
Table 25-5. PWMA Clocks
Clock Name Descripton
CLK_PWMA Clock for the PWMA bus interface
GCLK The generic clock used for the PWMA is GCLK3
Table 25-6. Register Reset Values
Register Reset Value
VERSION 0x00000201
PARAMETER 0x00000024
642
32142D–06/2013
ATUC64/128/256L3/4U
26. Timer/Counter (TC)
Rev: 2.2.3.1.3
26.1 Features
• Three 16-bit Timer Counter channels
• A wide range of functions including:
– Frequency measurement
– Event counting
– Interval measurement
– Pulse generation
– Delay timing
– Pulse width modulation
– Up/down capabilities
• Each channel is user-configurable and contains:
– Three external clock inputs
– Five internal clock inputs
– Two multi-purpose input/output signals
• Internal interrupt signal
• Two global registers that act on all three TC channels
• Peripheral event input on all A lines in capture mode
26.2 Overview
The Timer Counter (TC) includes three identical 16-bit Timer Counter channels.
Each channel can be independently programmed to perform a wide range of functions including
frequency measurement, event counting, interval measurement, pulse generation, delay timing,
and pulse width modulation.
Each channel has three external clock inputs, five internal clock inputs, and two multi-purpose
input/output signals which can be configured by the user. Each channel drives an internal interrupt
signal which can be programmed to generate processor interrupts.
The TC block has two global registers which act upon all three TC channels.
The Block Control Register (BCR) allows the three channels to be started simultaneously with
the same instruction.
The Block Mode Register (BMR) defines the external clock inputs for each channel, allowing
them to be chained.
643
32142D–06/2013
ATUC64/128/256L3/4U
26.3 Block Diagram
Figure 26-1. TC Block Diagram
26.4 I/O Lines Description
26.5 Product Dependencies
In order to use this module, other parts of the system must be configured correctly, as described
below.
26.5.1 I/O Lines
The pins used for interfacing the compliant external devices may be multiplexed with I/O lines.
The user must first program the I/O Controller to assign the TC pins to their peripheral functions.
I/O
Controller
TC2XC2S
INT0
INT1
INT2
TIOA0
TIOA1
TIOA2
TIOB0
TIOB1
TIOB2
XC2
TCLK0
TCLK1
TCLK2
TCLK0
TCLK1
TCLK2
TCLK0
TCLK1
TCLK2
TIOA1
TIOA2
TIOA0
TIOA2
TIOA1
Interrupt
Controller
CLK0
CLK1
CLK2
A0
B0
A1
B1
A2
B2
Timer Count er
TIOB
TIOA
TIOB
SYNC
TIMER_CLOCK1
TIOA
SYNC
SYNC
TIOA
TIOB
TIMER_CLOCK2
TIMER_CLOCK3
TIMER_CLOCK4
TIMER_CLOCK5
XC1
XC0
XC0
XC2
XC1
XC0
XC1
XC2
Timer/Counter
Channel 2
Timer/Counter
Channel 1
Timer/Counter
Channel 0
TC1XC1S
TC0XC0S
TIOA0
Table 26-1. I/O Lines Description
Pin Name Description Type
CLK0-CLK2 External Clock Input Input
A0-A2 I/O Line A Input/Output
B0-B2 I/O Line B Input/Output
644
32142D–06/2013
ATUC64/128/256L3/4U
When using the TIOA lines as inputs the user must make sure that no peripheral events are generated
on the line. Refer to the Peripheral Event System chapter for details.
26.5.2 Power Management
If the CPU enters a sleep mode that disables clocks used by the TC, the TC will stop functioning
and resume operation after the system wakes up from sleep mode.
26.5.3 Clocks
The clock for the TC bus interface (CLK_TC) is generated by the Power Manager. This clock is
enabled at reset, and can be disabled in the Power Manager. It is recommended to disable the
TC before disabling the clock, to avoid freezing the TC in an undefined state.
26.5.4 Interrupts
The TC interrupt request line is connected to the interrupt controller. Using the TC interrupt
requires the interrupt controller to be programmed first.
26.5.5 Peripheral Events
The TC peripheral events are connected via the Peripheral Event System. Refer to the Peripheral
Event System chapter for details.
26.5.6 Debug Operation
The Timer Counter clocks are frozen during debug operation, unless the OCD system keeps
peripherals running in debug operation.
26.6 Functional Description
26.6.1 TC Description
The three channels of the Timer Counter are independent and identical in operation. The registers
for channel programming are listed in Figure 26-3 on page 659.
26.6.1.1 Channel I/O Signals
As described in Figure 26-1 on page 643, each Channel has the following I/O signals.
26.6.1.2 16-bit counter
Each channel is organized around a 16-bit counter. The value of the counter is incremented at
each positive edge of the selected clock. When the counter has reached the value 0xFFFF and
passes to 0x0000, an overflow occurs and the Counter Overflow Status bit in the Channel n Status
Register (SRn.COVFS) is set.
Table 26-2. Channel I/O Signals Description
Block/Channel Signal Name Description
Channel Signal
XC0, XC1, XC2 External Clock Inputs
TIOA Capture mode: Timer Counter Input
Waveform mode: Timer Counter Output
TIOB Capture mode: Timer Counter Input
Waveform mode: Timer Counter Input/Output
INT Interrupt Signal Output
SYNC Synchronization Input Signal
645
32142D–06/2013
ATUC64/128/256L3/4U
The current value of the counter is accessible in real time by reading the Channel n Counter
Value Register (CVn). The counter can be reset by a trigger. In this case, the counter value
passes to 0x0000 on the next valid edge of the selected clock.
26.6.1.3 Clock selection
At block level, input clock signals of each channel can either be connected to the external inputs
TCLK0, TCLK1 or TCLK2, or be connected to the configurable I/O signals A0, A1 or A2 for
chaining by writing to the BMR register. See Figure 26-2 on page 645.
Each channel can independently select an internal or external clock source for its counter:
• Internal clock signals: TIMER_CLOCK1, TIMER_CLOCK2, TIMER_CLOCK3,
TIMER_CLOCK4, TIMER_CLOCK5. See the Module Configuration Chapter for details about
the connection of these clock sources.
• External clock signals: XC0, XC1 or XC2. See the Module Configuration Chapter for details
about the connection of these clock sources.
This selection is made by the Clock Selection field in the Channel n Mode Register
(CMRn.TCCLKS).
The selected clock can be inverted with the Clock Invert bit in CMRn (CMRn.CLKI). This allows
counting on the opposite edges of the clock.
The burst function allows the clock to be validated when an external signal is high. The Burst
Signal Selection field in the CMRn register (CMRn.BURST) defines this signal.
Note: In all cases, if an external clock is used, the duration of each of its levels must be longer than the
CLK_TC period. The external clock frequency must be at least 2.5 times lower than the CLK_TC.
Figure 26-2. Clock Selection
TIMER_CLOCK5
XC2
TCCLKS
CLKI
BURST
1
Selected
Clock
XC1
XC0
TIMER_CLOCK4
TIMER_CLOCK3
TIMER_CLOCK2
TIMER_CLOCK1
646
32142D–06/2013
ATUC64/128/256L3/4U
26.6.1.4 Clock control
The clock of each counter can be controlled in two different ways: it can be enabled/disabled
and started/stopped. See Figure 26-3 on page 646.
• The clock can be enabled or disabled by the user by writing to the Counter Clock
Enable/Disable Command bits in the Channel n Clock Control Register (CCRn.CLKEN and
CCRn.CLKDIS). In Capture mode it can be disabled by an RB load event if the Counter Clock
Disable with RB Loading bit in CMRn is written to one (CMRn.LDBDIS). In Waveform mode,
it can be disabled by an RC Compare event if the Counter Clock Disable with RC Compare
bit in CMRn is written to one (CMRn.CPCDIS). When disabled, the start or the stop actions
have no effect: only a CLKEN command in CCRn can re-enable the clock. When the clock is
enabled, the Clock Enabling Status bit is set in SRn (SRn.CLKSTA).
• The clock can also be started or stopped: a trigger (software, synchro, external or compare)
always starts the clock. In Capture mode the clock can be stopped by an RB load event if the
Counter Clock Stopped with RB Loading bit in CMRn is written to one (CMRn.LDBSTOP). In
Waveform mode it can be stopped by an RC compare event if the Counter Clock Stopped
with RC Compare bit in CMRn is written to one (CMRn.CPCSTOP). The start and the stop
commands have effect only if the clock is enabled.
Figure 26-3. Clock Control
26.6.1.5 TC operating modes
Each channel can independently operate in two different modes:
• Capture mode provides measurement on signals.
• Waveform mode provides wave generation.
The TC operating mode selection is done by writing to the Wave bit in the CCRn register
(CCRn.WAVE).
In Capture mode, TIOA and TIOB are configured as inputs.
Q S
R
S
R
Q
CLKSTA CLKEN CLKDIS
Stop
Event
Disable
Counter
Clock
Selected
Clock Trigger
Event
647
32142D–06/2013
ATUC64/128/256L3/4U
In Waveform mode, TIOA is always configured to be an output and TIOB is an output if it is not
selected to be the external trigger.
26.6.1.6 Trigger
A trigger resets the counter and starts the counter clock. Three types of triggers are common to
both modes, and a fourth external trigger is available to each mode.
The following triggers are common to both modes:
• Software Trigger: each channel has a software trigger, available by writing a one to the
Software Trigger Command bit in CCRn (CCRn.SWTRG).
• SYNC: each channel has a synchronization signal SYNC. When asserted, this signal has the
same effect as a software trigger. The SYNC signals of all channels are asserted
simultaneously by writing a one to the Synchro Command bit in the BCR register
(BCR.SYNC).
• Compare RC Trigger: RC is implemented in each channel and can provide a trigger when the
counter value matches the RC value if the RC Compare Trigger Enable bit in CMRn
(CMRn.CPCTRG) is written to one.
The channel can also be configured to have an external trigger. In Capture mode, the external
trigger signal can be selected between TIOA and TIOB. In Waveform mode, an external event
can be programmed to be one of the following signals: TIOB, XC0, XC1, or XC2. This external
event can then be programmed to perform a trigger by writing a one to the External Event Trigger
Enable bit in CMRn (CMRn.ENETRG).
If an external trigger is used, the duration of the pulses must be longer than the CLK_TC period
in order to be detected.
Regardless of the trigger used, it will be taken into account at the following active edge of the
selected clock. This means that the counter value can be read differently from zero just after a
trigger, especially when a low frequency signal is selected as the clock.
26.6.1.7 Peripheral events on TIOA inputs
The TIOA input lines are ored internally with peripheral events from the Peripheral Event System.
To capture using events the user must ensure that the corresponding pin functions for the
TIOA line are disabled. When capturing on the external TIOA pin the user must ensure that no
peripheral events are generated on this pin.
26.6.2 Capture Operating Mode
This mode is entered by writing a zero to the CMRn.WAVE bit.
Capture mode allows the TC channel to perform measurements such as pulse timing, frequency,
period, duty cycle and phase on TIOA and TIOB signals which are considered as
inputs.
Figure 26-4 on page 649 shows the configuration of the TC channel when programmed in Capture
mode.
26.6.2.1 Capture registers A and B
Registers A and B (RA and RB) are used as capture registers. This means that they can be
loaded with the counter value when a programmable event occurs on the signal TIOA.
648
32142D–06/2013
ATUC64/128/256L3/4U
The RA Loading Selection field in CMRn (CMRn.LDRA) defines the TIOA edge for the loading of
the RA register, and the RB Loading Selection field in CMRn (CMRn.LDRB) defines the TIOA
edge for the loading of the RB register.
RA is loaded only if it has not been loaded since the last trigger or if RB has been loaded since
the last loading of RA.
RB is loaded only if RA has been loaded since the last trigger or the last loading of RB.
Loading RA or RB before the read of the last value loaded sets the Load Overrun Status bit in
SRn (SRn.LOVRS). In this case, the old value is overwritten.
26.6.2.2 Trigger conditions
In addition to the SYNC signal, the software trigger and the RC compare trigger, an external trigger
can be defined.
The TIOA or TIOB External Trigger Selection bit in CMRn (CMRn.ABETRG) selects TIOA or
TIOB input signal as an external trigger. The External Trigger Edge Selection bit in CMRn
(CMRn.ETREDG) defines the edge (rising, falling or both) detected to generate an external trigger.
If CMRn.ETRGEDG is zero (none), the external trigger is disabled.
649
32142D–06/2013
ATUC64/128/256L3/4U
Figure 26-4. Capture Mode TIMER_CLOCK1 XC0
XC1
XC2
TCCLKS
CLKI
Q S
R
S
R
Q
CLKSTA CLKEN CLKDIS
BURST
TIOB
Capture
Register A Compare RC =
16-bit
Counter
ABETRG
SWTRG
ETRGEDG CPCTRG
IMR
Trig
LDRBS
LDRAS
ETRGS
SR
LOVRS
COVFS
SYNC
1
MTIOB
TIOA
MTIOA
LDRA
LDBSTOP
If RA is not Loaded
or RB is Loaded If RA is Loaded
LDBDIS
CPCS
INT
Edge
Detector
LDRB
CLK OVF
RESET
Timer/Counter Channel
Edge
Detector
Edge
Detector
Capture
Register B
Register C
TIMER_CLOCK2
TIMER_CLOCK3
TIMER_CLOCK4
TIMER_CLOCK5
650
32142D–06/2013
ATUC64/128/256L3/4U
26.6.3 Waveform Operating Mode
Waveform operating mode is entered by writing a one to the CMRn.WAVE bit.
In Waveform operating mode the TC channel generates one or two PWM signals with the same
frequency and independently programmable duty cycles, or generates different types of oneshot
or repetitive pulses.
In this mode, TIOA is configured as an output and TIOB is defined as an output if it is not used
as an external event.
Figure 26-5 on page 651 shows the configuration of the TC channel when programmed in
Waveform operating mode.
26.6.3.1 Waveform selection
Depending on the Waveform Selection field in CMRn (CMRn.WAVSEL), the behavior of CVn
varies.
With any selection, RA, RB and RC can all be used as compare registers.
RA Compare is used to control the TIOA output, RB Compare is used to control the TIOB output
(if correctly configured) and RC Compare is used to control TIOA and/or TIOB outputs.
651
32142D–06/2013
ATUC64/128/256L3/4U
Figure 26-5. Waveform Mode TCCLKS CLKI Q S
R
S
R
Q
CLKSTA CLKEN CLKDIS
CPCDIS
BURST
TIOB
Register A
Compare RC =
CPCSTOP
16-bit
Counter
EEVT
EEVTEDG
SYNC
SWTRG
ENETRG
WAVSEL
IMR
Trig
ACPC
ACPA
AEEVT
ASWTRG
BCPC
BCPB
BEEVT
BSWTRG
TIOA
MTIOA
TIOB
MTIOB
CPAS
COVFS
ETRGS
SR
CPCS
CPBS
CLK
OVF
RESET
Output Contr oller O utput Cont r oller
INT
1
Edge
Detector
Timer/Counter Channel
TIMER_CLOCK1
XC0
XC1
XC2
WAVSEL
Register B Register C
Compare RB = Compare RA =
TIMER_CLOCK2
TIMER_CLOCK3
TIMER_CLOCK4
TIMER_CLOCK5
652
32142D–06/2013
ATUC64/128/256L3/4U
26.6.3.2 WAVSEL = 0
When CMRn.WAVSEL is zero, the value of CVn is incremented from 0 to 0xFFFF. Once
0xFFFF has been reached, the value of CVn is reset. Incrementation of CVn starts again and
the cycle continues. See Figure 26-6 on page 652.
An external event trigger or a software trigger can reset the value of CVn. It is important to note
that the trigger may occur at any time. See Figure 26-7 on page 653.
RC Compare cannot be programmed to generate a trigger in this configuration. At the same
time, RC Compare can stop the counter clock (CMRn.CPCSTOP = 1) and/or disable the counter
clock (CMRn.CPCDIS = 1).
Figure 26-6. WAVSEL= 0 Without Trigger
Time
Counter Value
RC
RB
RA
TIOB
TIOA
Counter cleared by compare match with
0xFFFF
0xFFFF
Waveform Examples
653
32142D–06/2013
ATUC64/128/256L3/4U
Figure 26-7. WAVSEL= 0 With Trigger
26.6.3.3 WAVSEL = 2
When CMRn.WAVSEL is two, the value of CVn is incremented from zero to the value of RC,
then automatically reset on a RC Compare. Once the value of CVn has been reset, it is then
incremented and so on. See Figure 26-8 on page 654.
It is important to note that CVn can be reset at any time by an external event or a software trigger
if both are programmed correctly. See Figure 26-9 on page 654.
In addition, RC Compare can stop the counter clock (CMRn.CPCSTOP) and/or disable the
counter clock (CMRn.CPCDIS = 1).
Time
Counter Value
RC
RB
RA
TIOB
TIOA
Counter cleared by compare match with 0xFFFF
0xFFFF
Waveform Examples
Counter cleared by trigger
654
32142D–06/2013
ATUC64/128/256L3/4U
Figure 26-8. WAVSEL = 2 Without Trigger
Figure 26-9. WAVSEL = 2 With Trigger
26.6.3.4 WAVSEL = 1
When CMRn.WAVSEL is one, the value of CVn is incremented from 0 to 0xFFFF. Once 0xFFFF
is reached, the value of CVn is decremented to 0, then re-incremented to 0xFFFF and so on.
See Figure 26-10 on page 655.
Time
Counter Value
RC
RB
RA
TIOB
TIOA
Counter cleared by compare match
with RC
0xFFFF
Waveform Examples
Time
Counter Value
RC
RB
RA
TIOB
TIOA
Counter cleared by compare match with RC
0xFFFF
Waveform Examples
Counter cleared by trigger
655
32142D–06/2013
ATUC64/128/256L3/4U
A trigger such as an external event or a software trigger can modify CVn at any time. If a trigger
occurs while CVn is incrementing, CVn then decrements. If a trigger is received while CVn is
decrementing, CVn then increments. See Figure 26-11 on page 655.
RC Compare cannot be programmed to generate a trigger in this configuration.
At the same time, RC Compare can stop the counter clock (CMRn.CPCSTOP = 1) and/or disable
the counter clock (CMRn.CPCDIS = 1).
Figure 26-10. WAVSEL = 1 Without Trigger
Figure 26-11. WAVSEL = 1 With Trigger
Time
Counter Value
RC
RB
RA
TIOB
TIOA
Counter decremented by compare match
with 0xFFFF
0xFFFF
Waveform Examples
Time
Counter Value
TIOB
TIOA
Counter decremented by compare match with 0xFFFF
0xFFFF
Waveform Examples
Counter decremented by trigger
RC
RB
RA
Counter incremented by trigger
656
32142D–06/2013
ATUC64/128/256L3/4U
26.6.3.5 WAVSEL = 3
When CMRn.WAVSEL is three, the value of CVn is incremented from zero to RC. Once RC is
reached, the value of CVn is decremented to zero, then re-incremented to RC and so on. See
Figure 26-12 on page 656.
A trigger such as an external event or a software trigger can modify CVn at any time. If a trigger
occurs while CVn is incrementing, CVn then decrements. If a trigger is received while CVn is
decrementing, CVn then increments. See Figure 26-13 on page 657.
RC Compare can stop the counter clock (CMRn.CPCSTOP = 1) and/or disable the counter clock
(CMRn.CPCDIS = 1).
Figure 26-12. WAVSEL = 3 Without Trigger
Time
Counter Value
RC
RB
RA
TIOB
TIOA
Counter cleared by compare match with RC
0xFFFF
Waveform Examples
657
32142D–06/2013
ATUC64/128/256L3/4U
Figure 26-13. WAVSEL = 3 With Trigger
26.6.3.6 External event/trigger conditions
An external event can be programmed to be detected on one of the clock sources (XC0, XC1,
XC2) or TIOB. The external event selected can then be used as a trigger.
The External Event Selection field in CMRn (CMRn.EEVT) selects the external trigger. The
External Event Edge Selection field in CMRn (CMRn.EEVTEDG) defines the trigger edge for
each of the possible external triggers (rising, falling or both). If CMRn.EEVTEDG is written to
zero, no external event is defined.
If TIOB is defined as an external event signal (CMRn.EEVT = 0), TIOB is no longer used as an
output and the compare register B is not used to generate waveforms and subsequently no
IRQs. In this case the TC channel can only generate a waveform on TIOA.
When an external event is defined, it can be used as a trigger by writing a one to the
CMRn.ENETRG bit.
As in Capture mode, the SYNC signal and the software trigger are also available as triggers. RC
Compare can also be used as a trigger depending on the CMRn.WAVSEL field.
26.6.3.7 Output controller
The output controller defines the output level changes on TIOA and TIOB following an event.
TIOB control is used only if TIOB is defined as output (not as an external event).
The following events control TIOA and TIOB:
• software trigger
• external event
• RC compare
RA compare controls TIOA and RB compare controls TIOB. Each of these events can be programmed
to set, clear or toggle the output as defined in the following fields in CMRn:
• RC Compare Effect on TIOB (CMRn.BCPC)
Time
Counter Value
TIOB
TIOA
Counter decremented by compare match
with RC
0xFFFF
Waveform Examples
RC
RB
RA
Counter decremented by trigger
Counter incremented by trigger
658
32142D–06/2013
ATUC64/128/256L3/4U
• RB Compare Effect on TIOB (CMRn.BCPB)
• RC Compare Effect on TIOA (CMRn.ACPC)
• RA Compare Effect on TIOA (CMRn.ACPA)
659
32142D–06/2013
ATUC64/128/256L3/4U
26.7 User Interface
Table 26-3. TC Register Memory Map
Offset Register Register Name Access Reset
0x00 Channel 0 Control Register CCR0 Write-only 0x00000000
0x04 Channel 0 Mode Register CMR0 Read/Write 0x00000000
0x10 Channel 0 Counter Value CV0 Read-only 0x00000000
0x14 Channel 0 Register A RA0 Read/Write(1) 0x00000000
0x18 Channel 0 Register B RB0 Read/Write(1) 0x00000000
0x1C Channel 0 Register C RC0 Read/Write 0x00000000
0x20 Channel 0 Status Register SR0 Read-only 0x00000000
0x24 Interrupt Enable Register IER0 Write-only 0x00000000
0x28 Channel 0 Interrupt Disable Register IDR0 Write-only 0x00000000
0x2C Channel 0 Interrupt Mask Register IMR0 Read-only 0x00000000
0x40 Channel 1 Control Register CCR1 Write-only 0x00000000
0x44 Channel 1 Mode Register CMR1 Read/Write 0x00000000
0x50 Channel 1 Counter Value CV1 Read-only 0x00000000
0x54 Channel 1 Register A RA1 Read/Write(1) 0x00000000
0x58 Channel 1 Register B RB1 Read/Write(1) 0x00000000
0x5C Channel 1 Register C RC1 Read/Write 0x00000000
0x60 Channel 1 Status Register SR1 Read-only 0x00000000
0x64 Channel 1 Interrupt Enable Register IER1 Write-only 0x00000000
0x68 Channel 1 Interrupt Disable Register IDR1 Write-only 0x00000000
0x6C Channel 1 Interrupt Mask Register IMR1 Read-only 0x00000000
0x80 Channel 2 Control Register CCR2 Write-only 0x00000000
0x84 Channel 2 Mode Register CMR2 Read/Write 0x00000000
0x90 Channel 2 Counter Value CV2 Read-only 0x00000000
0x94 Channel 2 Register A RA2 Read/Write(1) 0x00000000
0x98 Channel 2 Register B RB2 Read/Write(1) 0x00000000
0x9C Channel 2 Register C RC2 Read/Write 0x00000000
0xA0 Channel 2 Status Register SR2 Read-only 0x00000000
0xA4 Channel 2 Interrupt Enable Register IER2 Write-only 0x00000000
0xA8 Channel 2 Interrupt Disable Register IDR2 Write-only 0x00000000
0xAC Channel 2 Interrupt Mask Register IMR2 Read-only 0x00000000
0xC0 Block Control Register BCR Write-only 0x00000000
0xC4 Block Mode Register BMR Read/Write 0x00000000
0xF8 Features Register FEATURES Read-only -(2)
0xFC Version Register VERSION Read-only -(2)
660
32142D–06/2013
ATUC64/128/256L3/4U
Notes: 1. Read-only if CMRn.WAVE is zero.
2. The reset values are device specific. Please refer to the Module Configuration section at the
end of this chapter.
661
32142D–06/2013
ATUC64/128/256L3/4U
26.7.1 Channel Control Register
Name: CCR
Access Type: Write-only
Offset: 0x00 + n * 0x40
Reset Value: 0x00000000
• SWTRG: Software Trigger Command
1: Writing a one to this bit will perform a software trigger: the counter is reset and the clock is started.
0: Writing a zero to this bit has no effect.
• CLKDIS: Counter Clock Disable Command
1: Writing a one to this bit will disable the clock.
0: Writing a zero to this bit has no effect.
• CLKEN: Counter Clock Enable Command
1: Writing a one to this bit will enable the clock if CLKDIS is not one.
0: Writing a zero to this bit has no effect.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
- - - - - SWTRG CLKDIS CLKEN
662
32142D–06/2013
ATUC64/128/256L3/4U
26.7.2 Channel Mode Register: Capture Mode
Name: CMR
Access Type: Read/Write
Offset: 0x04 + n * 0x40
Reset Value: 0x00000000
• LDRB: RB Loading Selection
• LDRA: RA Loading Selection
• WAVE
1: Capture mode is disabled (Waveform mode is enabled).
0: Capture mode is enabled.
• CPCTRG: RC Compare Trigger Enable
1: RC Compare resets the counter and starts the counter clock.
0: RC Compare has no effect on the counter and its clock.
• ABETRG: TIOA or TIOB External Trigger Selection
1: TIOA is used as an external trigger.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
- - - - LDRB LDRA
15 14 13 12 11 10 9 8
WAVE CPCTRG - - - ABETRG ETRGEDG
76543210
LDBDIS LDBSTOP BURST CLKI TCCLKS
LDRB Edge
0 none
1 rising edge of TIOA
2 falling edge of TIOA
3 each edge of TIOA
LDRA Edge
0 none
1 rising edge of TIOA
2 falling edge of TIOA
3 each edge of TIOA
663
32142D–06/2013
ATUC64/128/256L3/4U
0: TIOB is used as an external trigger.
• ETRGEDG: External Trigger Edge Selection
• LDBDIS: Counter Clock Disable with RB Loading
1: Counter clock is disabled when RB loading occurs.
0: Counter clock is not disabled when RB loading occurs.
• LDBSTOP: Counter Clock Stopped with RB Loading
1: Counter clock is stopped when RB loading occurs.
0: Counter clock is not stopped when RB loading occurs.
• BURST: Burst Signal Selection
• CLKI: Clock Invert
1: The counter is incremented on falling edge of the clock.
0: The counter is incremented on rising edge of the clock.
• TCCLKS: Clock Selection
ETRGEDG Edge
0 none
1 rising edge
2 falling edge
3 each edge
BURST Burst Signal Selection
0 The clock is not gated by an external signal
1 XC0 is ANDed with the selected clock
2 XC1 is ANDed with the selected clock
3 XC2 is ANDed with the selected clock
TCCLKS Clock Selected
0 TIMER_CLOCK1
1 TIMER_CLOCK2
2 TIMER_CLOCK3
3 TIMER_CLOCK4
4 TIMER_CLOCK5
5 XC0
6 XC1
7 XC2
664
32142D–06/2013
ATUC64/128/256L3/4U
26.7.3 Channel Mode Register: Waveform Mode
Name: CMR
Access Type: Read/Write
Offset: 0x04 + n * 0x40
Reset Value: 0x00000000
• BSWTRG: Software Trigger Effect on TIOB
• BEEVT: External Event Effect on TIOB
31 30 29 28 27 26 25 24
BSWTRG BEEVT BCPC BCPB
23 22 21 20 19 18 17 16
ASWTRG AEEVT ACPC ACPA
15 14 13 12 11 10 9 8
WAVE WAVSEL ENETRG EEVT EEVTEDG
76543210
CPCDIS CPCSTOP BURST CLKI TCCLKS
BSWTRG Effect
0 none
1 set
2 clear
3 toggle
BEEVT Effect
0 none
1 set
2 clear
3 toggle
665
32142D–06/2013
ATUC64/128/256L3/4U
• BCPC: RC Compare Effect on TIOB
• BCPB: RB Compare Effect on TIOB
• ASWTRG: Software Trigger Effect on TIOA
• AEEVT: External Event Effect on TIOA
• ACPC: RC Compare Effect on TIOA
BCPC Effect
0 none
1 set
2 clear
3 toggle
BCPB Effect
0 none
1 set
2 clear
3 toggle
ASWTRG Effect
0 none
1 set
2 clear
3 toggle
AEEVT Effect
0 none
1 set
2 clear
3 toggle
ACPC Effect
0 none
1 set
2 clear
3 toggle
666
32142D–06/2013
ATUC64/128/256L3/4U
• ACPA: RA Compare Effect on TIOA
• WAVE
1: Waveform mode is enabled.
0: Waveform mode is disabled (Capture mode is enabled).
• WAVSEL: Waveform Selection
• ENETRG: External Event Trigger Enable
1: The external event resets the counter and starts the counter clock.
0: The external event has no effect on the counter and its clock. In this case, the selected external event only controls the TIOA
output.
• EEVT: External Event Selection
Note: 1. If TIOB is chosen as the external event signal, it is configured as an input and no longer generates waveforms and subsequently
no IRQs.
• EEVTEDG: External Event Edge Selection
• CPCDIS: Counter Clock Disable with RC Compare
1: Counter clock is disabled when counter reaches RC.
0: Counter clock is not disabled when counter reaches RC.
ACPA Effect
0 none
1 set
2 clear
3 toggle
WAVSEL Effect
0 UP mode without automatic trigger on RC Compare
1 UPDOWN mode without automatic trigger on RC Compare
2 UP mode with automatic trigger on RC Compare
3 UPDOWN mode with automatic trigger on RC Compare
EEVT Signal selected as external event TIOB Direction
0 TIOB input(1)
1 XC0 output
2 XC1 output
3 XC2 output
EEVTEDG Edge
0 none
1 rising edge
2 falling edge
3 each edge
667
32142D–06/2013
ATUC64/128/256L3/4U
• CPCSTOP: Counter Clock Stopped with RC Compare
1: Counter clock is stopped when counter reaches RC.
0: Counter clock is not stopped when counter reaches RC.
• BURST: Burst Signal Selection
• CLKI: Clock Invert
1: Counter is incremented on falling edge of the clock.
0: Counter is incremented on rising edge of the clock.
• TCCLKS: Clock Selection
BURST Burst Signal Selection
0 The clock is not gated by an external signal.
1 XC0 is ANDed with the selected clock.
2 XC1 is ANDed with the selected clock.
3 XC2 is ANDed with the selected clock.
TCCLKS Clock Selected
0 TIMER_CLOCK1
1 TIMER_CLOCK2
2 TIMER_CLOCK3
3 TIMER_CLOCK4
4 TIMER_CLOCK5
5 XC0
6 XC1
7 XC2
668
32142D–06/2013
ATUC64/128/256L3/4U
26.7.4 Channel Counter Value Register
Name: CV
Access Type: Read-only
Offset: 0x10 + n * 0x40
Reset Value: 0x00000000
• CV: Counter Value
CV contains the counter value in real time.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
CV[15:8]
76543210
CV[7:0]
669
32142D–06/2013
ATUC64/128/256L3/4U
26.7.5 Channel Register A
Name: RA
Access Type: Read-only if CMRn.WAVE = 0, Read/Write if CMRn.WAVE = 1
Offset: 0x14 + n * 0X40
Reset Value: 0x00000000
• RA: Register A
RA contains the Register A value in real time.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
RA[15:8]
76543210
RA[7:0]
670
32142D–06/2013
ATUC64/128/256L3/4U
26.7.6 Channel Register B
Name: RB
Access Type: Read-only if CMRn.WAVE = 0, Read/Write if CMRn.WAVE = 1
Offset: 0x18 + n * 0x40
Reset Value: 0x00000000
• RB: Register B
RB contains the Register B value in real time.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
RB[15:8]
76543210
RB[7:0]
671
32142D–06/2013
ATUC64/128/256L3/4U
26.7.7 Channel Register C
Name: RC
Access Type: Read/Write
Offset: 0x1C + n * 0x40
Reset Value: 0x00000000
• RC: Register C
RC contains the Register C value in real time.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
RC[15:8]
76543210
RC[7:0]
672
32142D–06/2013
ATUC64/128/256L3/4U
26.7.8 Channel Status Register
Name: SR
Access Type: Read-only
Offset: 0x20 + n * 0x40
Reset Value: 0x00000000
Note: Reading the Status Register will also clear the interrupt bit for the corresponding interrupts.
• MTIOB: TIOB Mirror
1: TIOB is high. If CMRn.WAVE is zero, this means that TIOB pin is high. If CMRn.WAVE is one, this means that TIOB is driven
high.
0: TIOB is low. If CMRn.WAVE is zero, this means that TIOB pin is low. If CMRn.WAVE is one, this means that TIOB is driven
low.
• MTIOA: TIOA Mirror
1: TIOA is high. If CMRn.WAVE is zero, this means that TIOA pin is high. If CMRn.WAVE is one, this means that TIOA is driven
high.
0: TIOA is low. If CMRn.WAVE is zero, this means that TIOA pin is low. If CMRn.WAVE is one, this means that TIOA is driven
low.
• CLKSTA: Clock Enabling Status
1: This bit is set when the clock is enabled.
0: This bit is cleared when the clock is disabled.
• ETRGS: External Trigger Status
1: This bit is set when an external trigger has occurred.
0: This bit is cleared when the SR register is read.
• LDRBS: RB Loading Status
1: This bit is set when an RB Load has occurred and CMRn.WAVE is zero.
0: This bit is cleared when the SR register is read.
• LDRAS: RA Loading Status
1: This bit is set when an RA Load has occurred and CMRn.WAVE is zero.
0: This bit is cleared when the SR register is read.
• CPCS: RC Compare Status
1: This bit is set when an RC Compare has occurred.
0: This bit is cleared when the SR register is read.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
- - - - - MTIOB MTIOA CLKSTA
15 14 13 12 11 10 9 8
--------
76543210
ETRGS LDRBS LDRAS CPCS CPBS CPAS LOVRS COVFS
673
32142D–06/2013
ATUC64/128/256L3/4U
• CPBS: RB Compare Status
1: This bit is set when an RB Compare has occurred and CMRn.WAVE is one.
0: This bit is cleared when the SR register is read.
• CPAS: RA Compare Status
1: This bit is set when an RA Compare has occurred and CMRn.WAVE is one.
0: This bit is cleared when the SR register is read.
• LOVRS: Load Overrun Status
1: This bit is set when RA or RB have been loaded at least twice without any read of the corresponding register and
CMRn.WAVE is zero.
0: This bit is cleared when the SR register is read.
• COVFS: Counter Overflow Status
1: This bit is set when a counter overflow has occurred.
0: This bit is cleared when the SR register is read.
674
32142D–06/2013
ATUC64/128/256L3/4U
26.7.9 Channel Interrupt Enable Register
Name: IER
Access Type: Write-only
Offset: 0x24 + n * 0x40
Reset Value: 0x00000000
Writing a zero to a bit in this register has no effect.
Writing a one to a bit in this register will set the corresponding bit in IMR.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
ETRGS LDRBS LDRAS CPCS CPBS CPAS LOVRS COVFS
675
32142D–06/2013
ATUC64/128/256L3/4U
26.7.10 Channel Interrupt Disable Register
Name: IDR
Access Type: Write-only
Offset: 0x28 + n * 0x40
Reset Value: 0x00000000
Writing a zero to a bit in this register has no effect.
Writing a one to a bit in this register will clear the corresponding bit in IMR.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
ETRGS LDRBS LDRAS CPCS CPBS CPAS LOVRS COVFS
676
32142D–06/2013
ATUC64/128/256L3/4U
26.7.11 Channel Interrupt Mask Register
Name: IMR
Access Type: Read-only
Offset: 0x2C + n * 0x40
Reset Value: 0x00000000
0: The corresponding interrupt is disabled.
1: The corresponding interrupt is enabled.
A bit in this register is cleared when the corresponding bit in IDR is written to one.
A bit in this register is set when the corresponding bit in IER is written to one.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
ETRGS LDRBS LDRAS CPCS CPBS CPAS LOVRS COVFS
677
32142D–06/2013
ATUC64/128/256L3/4U
26.7.12 Block Control Register
Name: BCR
Access Type: Write-only
Offset: 0xC0
Reset Value: 0x00000000
• SYNC: Synchro Command
1: Writing a one to this bit asserts the SYNC signal which generates a software trigger simultaneously for each of the channels.
0: Writing a zero to this bit has no effect.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
- - - - - - - SYNC
678
32142D–06/2013
ATUC64/128/256L3/4U
26.7.13 Block Mode Register
Name: BMR
Access Type: Read/Write
Offset: 0xC4
Reset Value: 0x00000000
• TC2XC2S: External Clock Signal 2 Selection
• TC1XC1S: External Clock Signal 1 Selection
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
- - TC2XC2S TC1XC1S TC0XC0S
TC2XC2S Signal Connected to XC2
0 TCLK2
1 none
2 TIOA0
3 TIOA1
TC1XC1S Signal Connected to XC1
0 TCLK1
1 none
2 TIOA0
3 TIOA2
679
32142D–06/2013
ATUC64/128/256L3/4U
• TC0XC0S: External Clock Signal 0 Selection
TC0XC0S Signal Connected to XC0
0 TCLK0
1 none
2 TIOA1
3 TIOA2
680
32142D–06/2013
ATUC64/128/256L3/4U
26.7.14 Features Register
Name: FEATURES
Access Type: Read-only
Offset: 0xF8
Reset Value: -
• BRPBHSB: Bridge type is PB to HSB
1: Bridge type is PB to HSB.
0: Bridge type is not PB to HSB.
• UPDNIMPL: Up/down is implemented
1: Up/down counter capability is implemented.
0: Up/down counter capability is not implemented.
• CTRSIZE: Counter size
This field indicates the size of the counter in bits.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
-------
15 14 13 12 11 10 9 8
- - - - - - BRPBHSB UPDNIMPL
76543210
CTRSIZE
681
32142D–06/2013
ATUC64/128/256L3/4U
26.7.15 Version Register
Name: VERSION
Access Type: Read-only
Offset: 0xFC
Reset Value: -
• VARIANT: Variant number
Reserved. No functionality associated.
• VERSION: Version number
Version number of the module. No functionality associated.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
- - - - VARIANT
15 14 13 12 11 10 9 8
- - - - VERSION[11:8]
76543210
VERSION[7:0]
682
32142D–06/2013
ATUC64/128/256L3/4U
26.8 Module Configuration
The specific configuration for each Timer/Counter instance is listed in the following tables.The
module bus clocks listed here are connected to the system bus clocks. Please refer to the Power
Manager chapter for details.
26.8.1 Clock Connections
There are two Timer/Counter modules, TC0 and TC1, with three channels each, giving a total of
six Timer/Counter channels. Each Timer/Counter channel can independently select an internal
or external clock source for its counter:
Table 26-4. TC Bus Interface Clocks
Module name Clock Name Description
TC0 CLK_TC0 Clock for the TC0 bus interface
TC1 CLK_TC1 Clock for the TC1 bus interface
Table 26-5. Timer/Counter Clock Connections
Module Source Name Connection
TC0 Internal TIMER_CLOCK1 32 KHz oscillator clock (CLK_32K)
TIMER_CLOCK2 PBA Clock / 2
TIMER_CLOCK3 PBA Clock / 8
TIMER_CLOCK4 PBA Clock / 32
TIMER_CLOCK5 PBA Clock / 128
External XC0 See Section on page 10
XC1
XC2
TC1 Internal TIMER_CLOCK1 32 KHz oscillator clock (CLK_32K)
TIMER_CLOCK2 PBA Clock / 2
TIMER_CLOCK3 PBA Clock / 8
TIMER_CLOCK4 PBA Clock / 32
TIMER_CLOCK5 PBA Clock / 128
External XC0 See Section on page 10
XC1
XC2
683
32142D–06/2013
ATUC64/128/256L3/4U
27. Peripheral Event System
Rev: 1.0.0.1
27.1 Features
• Direct peripheral to peripheral communication system
• Allows peripherals to receive, react to, and send peripheral events without CPU intervention
• Cycle deterministic event communication
• Asynchronous interrupts allow advanced peripheral operation in low power sleep modes
27.2 Overview
Several peripheral modules can be configured to emit or respond to signals known as peripheral
events. The exact condition to trigger a peripheral event, or the action taken upon receiving a
peripheral event, is specific to each module. Peripherals that respond to peripheral events are
called peripheral event users and peripherals that emit peripheral events are called peripheral
event generators. A single module can be both a peripheral event generator and user.
The peripheral event generators and users are interconnected by a network known as the
Peripheral Event System. This allows low latency peripheral-to-peripheral signaling without CPU
intervention, and without consuming system resources such as bus or RAM bandwidth. This
offloads the CPU and system resources compared to a traditional interrupt-based software
driven system.
27.3 Peripheral Event System Block Diagram
Figure 27-1. Peripheral Event System Block Diagram
27.4 Functional Description
27.4.1 Configuration
The Peripheral Event System in the ATUC64/128/256L3/4U has a fixed mapping of peripheral
events between generators and users, as described in Table 27-1 to Table 27-4. Thus, the user
does not need to configure the interconnection between the modules, although each peripheral
event can be enabled or disabled at the generator or user side as described in the peripheral
chapter for each module.
Peripheral
Event
System
Generator
Generator
User
Generator/
User
684
32142D–06/2013
ATUC64/128/256L3/4U
Table 27-1. Peripheral Event Mapping from ACIFB to PWMA
Generator Generated Event User Effect Asynchronous
ACIFB channel 0
AC0 VINP > AC0 VINN PWMA channel 0
PWMA duty cycle value increased by one
No
AC0 VINN > AC0 VINP PWMA duty cycle value decreased by one
ACIFB channel 1
AC1 VINP > AC1 VINN PWMA channel 6
PWMA duty cycle value increased by one
AC1 VINN > AC1 VINP PWMA duty cycle value decreased by one
ACIFB channel 2
AC2 VINP > AC2 VINN PWMA channel 8
PWMA duty cycle value increased by one
AC2 VINN > AC2 VINP PWMA duty cycle value decreased by one
ACIFB channel 3
AC3 VINP > AC3 VINN PWMA channel 9
PWMA duty cycle value increased by one
AC3 VINN > AC3 VINP PWMA duty cycle value decreased by one
ACIFB channel 4
AC4 VINP > AC4 VINN PWMA channel 11
PWMA duty cycle value increased by one
AC4 VINN > AC4 VINP PWMA duty cycle value decreased by one
ACIFB channel 5
AC5 VINP > AC5 VINN PWMA channel 14
PWMA duty cycle value increased by one
AC5 VINN > AC5 VINP PWMA duty cycle value decreased by one
ACIFB channel 6
AC6 VINP > AC6 VINN PWMA channel 19
PWMA duty cycle value increased by one
AC6 VINN > AC6 VINP PWMA duty cycle value decreased by one
ACIFB channel 7
AC7 VINP > AC7 VINN PWMA channel 20
PWMA duty cycle value increased by one
AC7 VINN > AC7 VINP PWMA duty cycle value decreased by one
ACIFB channel n ACn VINN > ACn VINP CAT Automatically used by the CAT when
performing QMatrix acquisition. No
Table 27-2. Peripheral Event Mapping from GPIO to TC
Generator Generated Event User Effect Asynchronous
GPIO
Pin change on PA00-PA07
TC0
A0 capture
No
Pin change on PA08-PA15 A1 capture
Pin change on PA16-PA23 A2 capture
Pin change on PB00-PB07 TC1
A1 capture
Pin change on PB08-PB15 A2 capture
685
32142D–06/2013
ATUC64/128/256L3/4U
27.4.2 Peripheral Event Connections
Each generated peripheral event is connected to one or more users. If a peripheral event is connected
to multiple users, the peripheral event can trigger actions in multiple modules.
A peripheral event user can likewise be connected to one or more peripheral event generators. If
a peripheral event user is connected to multiple generators, the peripheral events are OR’ed
together to a single peripheral event. This means that peripheral events from either one of the
generators will result in a peripheral event to the user.
To configure a peripheral event, the peripheral event must be enabled at both the generator and
user side. Even if a generator is connected to multiple users, only the users with the peripheral
event enabled will trigger on the peripheral event.
27.4.3 Low Power Operation
As the peripheral events do not require CPU intervention, they are available in Idle mode. They
are also available in deeper sleep modes if both the generator and user remain clocked in that
mode.
Certain events are known as asynchronous peripheral events, as identified in Table 27-1 to
Table 27-4. These can be issued even when the system clock is stopped, and revive unclocked
user peripherals. The clock will be restarted for this module only, without waking the system from
sleep mode. The clock remains active only as long as required by the triggered function, before
being switched off again, and the system remains in the original sleep mode. The CPU and sysTable
27-3. Peripheral Event Mapping from AST
Generator Generated Event User Effect Asynchronous
AST
Overflow event
ACIFB
Comparison is triggered if the ACIFB.CONFn
register is written to 11 (Event Triggered Single
Measurement Mode) and the EVENTEN bit in
the ACIFB.CTRL register is written to 1.
Yes
Periodic event
Alarm event
Overflow event
ADCIFB
Conversion is triggered if the TRGMOD bit in
the ADCIFB.TRGR register is written to 111
(Peripheral Event Trigger).
Periodic event
Alarm event
Overflow event
CAT Trigger one iteration of autonomous touch
detection. Periodic event
Alarm event
Table 27-4. Peripheral Event Mapping from PWMA
Generator Generated Event User Effect Asynchronous
PWMA channel 0
Timebase counter
reaches the duty cycle
value.
ACIFB
Comparison is triggered if the ACIFB.CONFn
register is written to 11 (Event Triggered Single
Measurement Mode) and the EVENTEN bit in
the ACIFB.CTRL register is written to 1. No
ADCIFB
Conversion is triggered if the TRGMOD bit in
the ADCIFB.TRGR register is written to 111
(Peripheral Event Trigger).
686
32142D–06/2013
ATUC64/128/256L3/4U
tem will only be woken up if the user peripheral generates an interrupt as a result of the
operation. This concept is known as SleepWalking and is described in further detail in the Power
Manager chapter. Note that asynchronous peripheral events may be associated with a delay
due to the need to restart the system clock source if this has been stopped in the sleep mode.
27.5 Application Example
This application example shows how the Peripheral Event System can be used to program the
ADC Interface to perform ADC conversions at selected intervals.
Conversions of the active analog channels are started with a software or a hardware trigger.
One of the possible hardware triggers is a peripheral event trigger, allowing the Peripheral Event
System to synchronize conversion with some configured peripheral event source. From Table
27-3 and Table 27-4, it can be read that this peripheral event source can be either an AST
peripheral event, or an event from the PWM Controller. The AST can generate periodic peripheral
events at selected intervals, among other types of peripheral events. The Peripheral Event
System can then be used to set up the ADC Interface to sample an analog signal at regular
intervals.
The user must enable peripheral events in the AST and in the ADC Interface to accomplish this.
The periodic peripheral event in the AST is enabled by writing a one to the corresponding bit in
the AST Event Enable Register (EVE). To select the peripheral event trigger for the ADC Interface,
the user must write the value 0x7 to the Trigger Mode (TRGMOD) field in the ADC
Interface Trigger Register (TRGR). When the peripheral events are enabled, the AST will generate
peripheral events at the selected intervals, and the Peripheral Event System will route the
peripheral events to the ADC Interface, which will perform ADC conversions at the selected
intervals.
Figure 27-2. Application Example
Since the AST peripheral event is asynchronous, the description above will also work in sleep
modes where the ADC clock is stopped. In this case, the ADC clock (and clock source, if
needed) will be restarted during the ADC conversion. After the conversion, the ADC clock and
clock source will return to the sleep state, unless the ADC generates an interrupt, which in turn
will wake up the system. Using asynchronous interrupts thus allows ADC operation in much
lower power states than would otherwise be possible.
Peripheral
Event
System
AST ADC
Interface
Trigger
conversion
Periodic peripheral
event
687
32142D–06/2013
ATUC64/128/256L3/4U
28. Audio Bit Stream DAC (ABDACB)
Rev.: 1.0.0.0
28.1 Features
• 16 bit digital stereo DAC
• Oversampling D/A conversion architecture
– Adjustable oversampling ratio
– 3rd order Sigma-Delta D/A converters
• Digital bitstream output
• Parallel interface
• Connects to DMA for background transfer without CPU intervention
• Supported sampling frequencies
– 8000Hz, 11025Hz, 12000Hz, 16000Hz, 22050Hz, 24000Hz, 32000Hz, 44100Hz, and 48000Hz
• Supported data formats
– 32-, 24-, 20-, 18-, 16-, and 8-bit stereo format
– 16- and 8-bit compact stereo format, with left and right sample packed in the same word to
reduce data transfers
• Common mode offset control
• Volume control
28.2 Overview
The Audio Bitstream DAC (ABDACB) converts a 16-bit sample value to a digital bitstream with
an average value proportional to the sample value. Two channels are supported making the
Audio Bitstream DAC particularly suitable for stereo audio. Each channel has a pair of complementary
digital outputs, DAC and DACN, which can be connected to an external high input
impedance amplifier.
The Audio Bitstream DAC is made up of several signal processing blocks and a 3rd order Sigma
Delta D/A converter for each channel. The Sigma Delta modulator converts the parallel data to a
bitstream, while the signal processing blocks perform volume control, offset control, upsampling,
and filtering to compensate for the upsampling process. The upsampling is performed by a Cascaded
Integrator-Comb (CIC) filter, and the compensation filter is a Finite Impulse Response
(FIR) CIC compensation filter.
28.3 Block Diagram
Figure 28-1. ABDACB Block Diagram
User Inter af ce
Synchronizer
Volume control
Offset control
CIC Compensation
filter (FIR)
CIC
Comb
Section
CIC Integrator
section
Clock
divider
Sigma Delta
Modulator
Sigma Delta
Modulator
clk_abdacb gclk
Signal processing
(before up-sampling)
CLK
DAC[0]
DACN[0]
DAC[1]
DACN[1]
PB
688
32142D–06/2013
ATUC64/128/256L3/4U
28.4 I/O Lines Description
28.5 Product Dependencies
In order to use this module, other parts of the system must be configured correctly, as described
below.
28.5.1 I/O lines
The output pins used for the output bitstream from the Audio Bitstream DAC may be multiplexed
with I/O Controller lines.
Before using the Audio Bitstream DAC, the I/O Controller must be configured in order for the
Audio Bitstream DAC I/O lines to be in Audio Bitstream DAC peripheral mode.
28.5.2 Clocks
The clock for the ABDACB bus interface (CLK_ABDACB) is generated by the Power Manager.
This clock is turned on by default, and can be enabled and disabled in the Power Manager. It is
recommended to disable the ABDACB before disabling the clock, to avoid freezing the ABDACB
in an undefined state. Before using the Audio Bitstream DAC, the user must ensure that the
Audio Bitstream DAC clock is enabled in the Power Manager.
The Audio Bitstream DAC requires a separate clock for the D/A conversion. This clock is provided
by a generic clock which has to be set up in the System Control Interface (SCIF). The
frequency for this clock has to be set as described in Table 28-3 on page 697. It is important that
this clock is accurate and has low jitter. Incorrect frequency will result in too fast or too slow playback
(frequency shift), and too high jitter will add noise to the D/A conversion. For best
performance one should trade frequency accuracy (within some limits) for low jitter to obtain the
best performance as jitter will have large impact on the quality of the converted signal.
28.5.3 DMA
The ABDACB is connected to the Peripheral DMA controller. Using DMA to transfer data samples
requires the Peripheral DMA controller to be programmed before enabling the ABDACB.
28.5.4 Interrupts
The ABDACB interrupt request line is connected to the interrupt controller. Using the ABDACB
interrupt requires the interrupt controller to be programmed first.
Table 28-1. I/O Lines Description
Pin Name Pin Description Type
DAC[0] Output for channel 0 Output
DACN[0] Inverted output for channel 0 Output
DAC[1] Output for channel 1 Output
DACN[1] Inverted output for channel 1 Output
CLK Clock output for DAC Output
689
32142D–06/2013
ATUC64/128/256L3/4U
28.6 Functional Description
28.6.1 Construction
The Audio Bitstream DAC is divided into several parts, the user interface, the signal processing
blocks, and the Sigma Delta modulator blocks. See Figure 28-1 on page 687. The user interface
is used to configure the signal processing blocks and to input new data samples to the converter.The
signal processing blocks manages volume control, offset control, and upsampling.
The Sigma Delta blocks converts the parallel data to1-bit bitstreams.
28.6.1.1 CIC Interpolation Filter
The interpolation filter in the system is a Cascaded Integrator-Comb (CIC) interpolation filter
which interpolates from Fs to {125, 128, 136}xFs depending on the control settings. This filter is a
4th order CIC filter, and the basic building blocks of the filter is a comb part and an integrator
part. Since the CIC interpolator has a sinc-function frequency response it is compensated by a
linear phase CIC compensation filter to make the passband response more flat in the range 0-
20kHz, see figure Figure 28-4 on page 693. The frequency response of this type of interpolator
has the first zero at the input sampling frequency. This means that the first repeated specters
created by the upsampling process will not be fully rejected and the output signal will contain signals
from these repeated specters. See Figure 28-6 on page 694.
Since the human ear can not hear frequencies above 20kHz, we should not be affected by this
when the sample rate is above 40kHz, but digital measurement equipment will be affected. This
need to be accounted for when doing measurements on the system to prevent aliasing and
incorrect measurement results.
28.6.1.2 Sigma Delta Modulator
The Sigma Delta modulator is a 3rd order modulator consisting of three differentiators (delta
blocks), three integrators (sigma blocks), and a one bit quantizer. The purpose of the integrators
is to shape the noise, so that the noise is reduced in the audio passband and increased at the
higher frequencies, where it can be filtered out by an analog low-pass filter. To be able to filter
out all the noise at high frequencies the analog low-pass filter must be one order larger than the
Sigma Delta modulator.
28.6.1.3 Recreating the Analog Signal
Since the DAC and DACN outputs from the ABDAC are digital square wave signals, they have
to be passed through a low pass filter to recreate the analog signal. This also means that noise
on the IO voltage will couple through to the analog signal. To remove some of the IO noise the
ABDAC can output a clock signal, CLK, which can be used to resample the DAC and DACN signals
on external Flip-Flops powered by a clean supply.
28.6.2 Initialization
Before enabling the ABDACB the correct configuration must be applied to the Control Register
(CR). Configuring the Alternative Upsampling Ratio bit (CR.ALTUPR), Common Mode Offset
Control bit (CR.CMOC), and the Sampling Frequency field (CR.FS) according to the sampling
rate of the data that is converted and the type of amplifier the outputs are connected to is
required to get the correct behavior of the system. When the correct configuration is applied the
ABDACB can be enabled by writing a one to the Enable bit in the Control Register (CR.EN). The
module is disabled by writing a zero to the Enable bit. The module should be disabled before
entering sleep modes to ensure that the outputs are not left in an undesired state.
690
32142D–06/2013
ATUC64/128/256L3/4U
28.6.3 Basic operation
To convert audio data to a digital bitstream the user must first initialize the ABDACB as
described in Section 28.6.2. When the ABDACB is initialized and enabled it will indicate that it is
ready to receive new data by setting the Transmit Ready bit in the Status Register (SR.TXRDY).
When the TXRDY bit is set in the Status Register the user has to write new samples to Sample
Data Register 0 (SDR0) and Sample Data Register 1 (SDR1). If the Mono Mode (MONO) bit in
the Control Register (CR) is set, or one of the compact stereo formats are used by configuring
the Data Word Format (DATAFORMAT) in the Control Register, only SDR0 has to be written.
Failing to write to the sample data registers will result in an underrun indicated by the Transmit
Underrun (TXUR) bit in the Status Register (SR.TXUR). When new samples are written to the
sample data registers the TXRDY bit will be cleared.
To increase performance of the system an interrupt handler or DMA transfer can be used to
write new samples to the sample data registers. See Section 28.6.10 for details on DMA, and
Section 28.6.11 for details on interrupt.
28.6.4 Data Format
The input data type is two’s complement. The Audio Bitstream DAC can be configured to accept
different audio formats. The format must be configured in the Data Word Format field in the Control
Register. In regular operation data for the two channels are written to the sample data
registers SDR0 and SDR1. If the data format field specifies a format using less than 32 bits, data
must be written right-justified in SDR0 and SDR1. Sign extension into the unused bits is not necessary.
Only the 16 most significant bits in the data will be used by the ABDACB. For data
formats larger than 16 bits the least significant bits are ignored. For 8-bit data formats the 8 bits
will be used as the most significant bits in the 16-bit samples, the additional bits will be zeros.
The ABDACB also supports compact data formats for 16- and 8-bit samples. For 16-bit samples
the sample for channel 0 must be written to bits 15 through 0 and the sample for channel 1 must
be written to bits 31 through 16 in SDR0. For 8-bit samples the sample for channel 0 must be
written to bits 7 through 0 and the sample for channel 1 must be written to bits 15 through 8 in
SDR0. SDR1 is not used in this mode. See Table 28-5 on page 699.
28.6.5 Data Swapping
When the Swap Channels (SWAP) bit in the Control Register (CR.SWAP) is one, writing to the
Sample Data Register 0 (SDR0) will put the data in Sample Data Register 1 (SDR1). Writing
SDR1 will put the data in SDR0. If one of the two compact stereo formats is used the lower and
upper halfword of SDR0 will be swapped when writing to SDR0.
28.6.6 Common Mode Offset Control
When the Common Mode Offset Control (CMOC) bit in the Control Register is one the input data
will get a DC value applied to it and the amplitude will be scaled. This will make the common
mode offset of the two corresponding outputs, DAC and DACN, to move away from each other
so that the output signals are not overlapping. The result is that the two signals can be applied to
a differential analog filter, and the difference will always be a positive value, removing the need
for a negative voltage supply for the filter. The cost of doing this a 3dB loss in dynamic range. On
the left side of Figure 28-2 one can see the filtered output from the DAC and DACN pins when a
sine wave is played when CR.CMOC is zero. The waveform on the right side shows the output
of the differential filter when the two outputs on the left side are used as inputs to the differential
filter. Figure 28-3 show the corresponding outputs when CR.CMOC is one.
691
32142D–06/2013
ATUC64/128/256L3/4U
Figure 28-2. Output signals with CMOC=0
Figure 28-3. Output signals with CMOC=1
28.6.7 Volume Control
The Audio Bitstream DAC have two volume control registers, Volume Control Register 0 (VCR0)
and Volume Control Register 1 (VCR1), that can be used to adjust the volume for the corresponding
channel. The volume control is linear and will only scale each sample according to the
value in the Volume Control (VOLUME) field in the volume control registers. The register also
has a Mute bit (MUTE) which can be used to mute the corresponding channel. The filtered out-
692
32142D–06/2013
ATUC64/128/256L3/4U
put of the DAC pins will have a voltage given by the following equation, given that it is configured
to run at the default upsampling ratio of 128:
If one want to get coherence between the sign of the input data and the output voltage one can
use the DATAN outputs or invert the sign of the input data by software.
28.6.8 Mono
When the Mono bit (MONO) in the Control Register is set, data written to SDR0 will be used for
both output channels. If one of the compact stereo formats are used only the data written to the
part of SDR0 that corresponds with channel 0 is used.
28.6.9 Alternative Upsampling Ratio
The digital filters and Sigma Delta modulators requires its own clock to perform the conversion at
the correct speed, and this clock is provided by a generic clock in the SCIF. The frequency of
this clock depends on the input sample rate and the upsampling ratio which is controlled by the
Alternative Upsampling Ratio bit (ALTUPR) in the Control Register.
The ABDACB supports three upsampling ratios, 125, 128, and 136. The default setting is a ratio
of 128, and is used when CR.ALTUPR is zero. Using this ratio gives a clock frequency requirement
that is common for audio products. In some cases one may want to use other clock
frequencies that already are available in the system. By writing a one to CR.ALTUPR a upsampling
ratio of 125 or 136 is used depending on the configuration of the Sampling Frequency field
in the Control Register. Refer to Table 28-3 for required clock frequency and settings.
The required clock frequency of the generic clock can be calculated from the following equation:
R is the upsampling ratio of the converter. If CR.ALTUPR is zero the upsampling ratio is 128. If
CR.ALTUPR is one, R will change to 125 when CR.FS is configured for 8kHz, 12kHz, 16kHz,
24kHz, 32kHz, and 48kHz. For the other configurations of CR.FS, 11.025kHz, 22.050kHz, and
44.100kHz, it will change to 136.
28.6.10 DMA operation
The Audio Bitstream DAC is connected to the Peripheral DMA Controller. The Peripheral DMA
Controller can be programmed to automatically transfer samples to the Sample Data Registers
(SDR0 and SDR1) when the Audio Bitstream DAC is ready for new samples. Two DMA channels
are used, one for each sample data register. If the Mono Mode bit in the Control Register
(CR.MONO) is one, or one of the compact stereo formats is used, only the DMA channel connected
to SDR0 will be used. When using DMA only the Control Register needs to be written in
the Audio Bitstream DAC. This enables the Audio Bitstream DAC to operate without any CPU
intervention such as polling the Status Register (SR) or using interrupts. See the Peripheral
DMA Controller documentation for details on how to setup Peripheral DMA transfers.
28.6.11 Interrupts
The ABDACB requires new data samples at a rate of FS. The interrupt status bits are used to
indicate when the system is ready to receive new samples. The Transmit Ready Interrupt Status
bit in the Status Register (SR.TXRDY) will be set whenever the ABDACB is ready to receive a
new sample. A new sample value must be written to the sample data registers (SDR0 and
VOUT
1
2
-- 33
128 – --------- SDR
215 ------------ VOLUME
215 – 1
------------------------ VVDDIO =
GCLK[Hz] F = S R 8
693
32142D–06/2013
ATUC64/128/256L3/4U
SDR1) before 1/FS second, or an underrun will occur, as indicated by the Underrun Interrupt bit
in SR (SR.TXUR). The interrupt bits in SR are cleared by writing a one to the corresponding bit
in the Status Clear Register (SCR).
28.6.12 Frequency Response
Figure Figure 28-4 to Figure 28-7 show the frequency response for the system. The sampling
frequency used is 48kHz, but the response will be the same for other sampling frequencies,
always having the first zero at FS.
Figure 28-4. Passband Frequency Response
694
32142D–06/2013
ATUC64/128/256L3/4U
Figure 28-5. Frequency Response up to Sampling Frequency
Figure 28-6. Frequency Response up to 3x Sampling Frequency
695
32142D–06/2013
ATUC64/128/256L3/4U
Figure 28-7. Frequency Response up to 128x Sampling Frequency
696
32142D–06/2013
ATUC64/128/256L3/4U
28.7 User Interface
Note: 1. The reset values are device specific. Please refer to the Module Configuration section at the end of this chapter.
Table 28-2. ABDACB Register Memory Map
Offset Register Register Name Access Reset
0x00 Control Register CR Read/Write 0x00000000
0x04 Sample Data Register 0 SDR0 Read/Write 0x00000000
0x08 Sample Data Register 1 SDR1 Read/Write 0x00000000
0x0C Volume Control Register 0 VCR0 Read/Write 0x00000000
0x10 Volume Control Register 1 VCR1 Read/Write 0x00000000
0x14 Interrupt Enable Register IER Write-only 0x00000000
0x18 Interrupt Disable Register IDR Write-only 0x00000000
0x1C Interrupt Mask Register IMR Read-only 0x00000000
0x20 Status Register SR Read-only 0x00000000
0x24 Status Clear Register SCR Write-only 0x00000000
0x28 Parameter Register PARAMETER Read-only -
(1)
0x2C Version Register VERSION Read-only -
(1)
697
32142D–06/2013
ATUC64/128/256L3/4U
28.7.1 Control Register
Name: CR
Access Type: Read/Write
Offset: 0x00
Reset Value: 0x00000000
• FS: Sampling Frequency
Must be set to the matching data sampling frequency, see Table 28-3.
Note: 1. The actual clock requirement are 11.9952MHz, 23.9904MHz, and 47.9808MHz, but this is
very close to the suggested clock frequencies, and will only result in a very small frequency
shift. This need to be accounted for during testing if comparing to a reference signal.
Notes: 1.
31 30 29 28 27 26 25 24
- - - - FS
23 22 21 20 19 18 17 16
- - - - - DATAFORMAT
15 14 13 12 11 10 9 8
--------
76543210
SWRST - MONO CMOC ALTUPR - SWAP EN
Table 28-3. Generic Clock Requirements
CR.FS Description GCLK (CR.ALTUPR=1) GCLK (CR.ALTUPR=0)
0 8000Hz sampling frequency 8.0MHz 8.1920MHz
1 11025Hz sampling frequency 12.0MHz(1) 11.2896MHz
2 12000Hz sampling frequency 12.0MHz 12.2880MHz
3 16000Hz sampling frequency 16.0MHz 16.3840MHz
4 22050Hz sampling frequency 24.0MHz(1) 22.5792MHz
5 24000Hz sampling frequency 24.0MHz 24.5760MHz
6 32000Hz sampling frequency 32.0MHz 32.7680MHz
7 44100Hz sampling frequency 48.0MHz(1) 45.1584MHz
8 48000Hz sampling frequency 48.0MHz 49.1520MHz
Other Reserved - -
698
32142D–06/2013
ATUC64/128/256L3/4U
• DATAFORMAT: Data Word Format
• SWRST: Software Reset
Writing a zero to this bit does not have any effect.
Writing a one to this bit will reset the ABDACB as if a hardware reset was done.
• MONO: Mono Mode
0: Mono mode is disabled.
1: Mono mode is enabled.
• CMOC: Common Mode Offset Control
0: Common mode adjustment is disabled.
1: Common mode adjustment is enabled.
• ALTUPR: Alternative Upsampling Ratio
0: Alternative upsampling is disabled.
1: Alternative upsampling is enabled.
• SWAP: Swap Channels
0: Channel swap is disabled.
1: Channel swap is enabled.
• EN: Enable
0: The ABDACB is disabled.
1: The ABDACB is enabled.
Table 28-4. Data Word Format
DATAFORMAT Word length Comment
0 32 bits
1 24 bits
2 20 bits
3 18 bits
4 16 bits
5 16 bits compact stereo Channel 1 sample in bits 31 through 16, channel 0 sample in bits 15 through 0 in SDR0
6 8 bits
7 8 bits compact stereo Channel 1 sample in bits 15 through 8, channel 0 sample in bits 7through 0 in SDR0
699
32142D–06/2013
ATUC64/128/256L3/4U
28.7.2 Sample Data Register 0
Name: SDR0
Access Type: Read/Write
Offset: 0x04
Reset Value: 0x00000000
• DATA: Sample Data
Sample Data for channel 0 in two’s complement format. Data must be right-justified, see Table 28-5.
31 30 29 28 27 26 25 24
DATA[31:24]
23 22 21 20 19 18 17 16
DATA[23:16]
15 14 13 12 11 10 9 8
DATA[15:8]
76543210
DATA[7:0]
Table 28-5. Sample Data Register Formats
Data Format SDR0 SDR1 Comment
32 bits CH0 sample in DATA[31:0] CH1 sample in DATA[31:0]
24 bits CH0 sample in DATA[23:0] CH1 sample in DATA[23:0] Remaining bits are ignored.
20 bits CH0 sample in DATA[19:0] CH1 sample in DATA[19:0] Remaining bits are ignored.
18 bits CH0 sample in DATA[17:0] CH1 sample in DATA[17:0] Remaining bits are ignored.
16 bits CH0 sample in DATA[15:0] CH1 sample in DATA[15:0] Remaining bits are ignored.
16 bits compact stereo CH0 sample in DATA[15:0]
CH1 sample in DATA[31:16] Not used
8 bits CH0 sample in DATA[7:0] CH1 sample in DATA[7:0] Remaining bits are ignored.
8 bits compact stereo CH0 sample in DATA[7:0]
CH1 sample in DATA[15:8] Not used Remaining bits are ignored.
700
32142D–06/2013
ATUC64/128/256L3/4U
28.7.3 Sample Data Register 1
Name: SDR1
Access Type: Read/Write
Offset: 0x08
Reset Value: 0x00000000
• DATA: Sample Data
Sample Data for channel 1 in two’s complement format. Data must be right-justified, see Table 28-5 on page 699.
31 30 29 28 27 26 25 24
DATA[31:24]
23 22 21 20 19 18 17 16
DATA[23:16]
15 14 13 12 11 10 9 8
DATA[15:8]
76543210
DATA[7:0]
701
32142D–06/2013
ATUC64/128/256L3/4U
28.7.4 Volume Control Register 0
Name: VCR0
Access Type: Read/Write
Offset: 0x0C
Reset Value: 0x00000000
• MUTE: Mute
0: Channel 0 is not muted.
1: Channel 0 is muted.
• VOLUME: Volume Control
15-bit value adjusting the volume for channel 0.
31 30 29 28 27 26 25 24
MUTE - - - - - - -
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
- VOLUME[14:8]
76543210
VOLUME[7:0]
702
32142D–06/2013
ATUC64/128/256L3/4U
28.7.5 Volume Control Register 1
Name: VCR1
Access Type: Read/Write
Offset: 0x10
Reset Value: 0x00000000
• MUTE: Mute
0: Channel 1 is not muted.
1: Channel 1 is muted.
• VOLUME: Volume Control
15-bit value adjusting the volume for channel 1.
31 30 29 28 27 26 25 24
MUTE - - - - - - -
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
- VOLUME[14:8]
76543210
VOLUME[7:0]
703
32142D–06/2013
ATUC64/128/256L3/4U
28.7.6 Interrupt Enable Register
Name: IER
Access Type: Write-only
Offset: 0x14
Reset Value: 0x00000000
Writing a zero to a bit in this register has no effect.
Writing a one to a bit in this register will set the corresponding bit in IMR.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
- - - - - TXUR TXRDY -
704
32142D–06/2013
ATUC64/128/256L3/4U
28.7.7 Interrupt Disable Register
Name: IDR
Access Type: Write-only
Offset: 0x18
Reset Value: 0x00000000
Writing a zero to a bit in this register has no effect.
Writing a one to a bit in this register will clear the corresponding bit in IMR.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
- - - - - TXUR TXRDY -
705
32142D–06/2013
ATUC64/128/256L3/4U
28.7.8 Interrupt Mask Register
Name: IMR
Access Type: Read-only
Offset: 0x1C
Reset Value: 0x00000000
0: The corresponding interrupt is disabled.
1: The corresponding interrupt is enabled.
A bit in this register is cleared when the corresponding bit in IDR is written to one.
A bit in this register is set when the corresponding bit in IER is written to one.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
- - - - - TXUR TXRDY -
706
32142D–06/2013
ATUC64/128/256L3/4U
28.7.9 Status Register
Name: SR
Access Type: Read-only
Offset: 0x20
Reset Value: 0x00000000
• TXUR: Transmit Underrun
This bit is cleared when no underrun has occurred since the last time this bit was cleared (by reset or by writing to SCR).
This bit is set when at least one underrun has occurred since the last time this bit was cleared (by reset or by writing to SCR).
• TXRDY: Transmit Ready
This bit is cleared when the ABDACB is not ready to receive a new data in SDR.
This bit is set when the ABDACB is ready to receive a new data in SDR.
• BUSY: ABDACB Busy
This bit is set when the ABDACB is busy doing a data transfer between clock domains. CR, SDR0, and SDR1 can not be written
during this time.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
- - - - - TXUR TXRDY BUSY
707
32142D–06/2013
ATUC64/128/256L3/4U
28.7.10 Status Clear Register
Name: SCR
Access Type: Write-only
Offset: 0x24
Reset Value: 0x00000000
Writing a zero to a bit in this register has no effect.
Writing a one to a bit in this register will clear the corresponding bit in SR and the corresponding interrupt request.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
- - - - - TXUR TXRDY -
708
32142D–06/2013
ATUC64/128/256L3/4U
28.7.11 Parameter Register
Name: PARAMETER
Access Type: Read-only
Offset: 0x28
Reset Value: 0x00000000
Reserved. No functionality associated.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
--------
709
32142D–06/2013
ATUC64/128/256L3/4U
28.7.12 Version Register
Name: VERSION
Access Type: Read-only
Offset: 0x2C
Reset Value: 0x00000000
• VARIANT: Variant Number
Reserved. No functionality associated.
• VERSION: Version Number
Version number of the module. No functionality associated.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
- - - - VARIANT
15 14 13 12 11 10 9 8
- - - - VERSION[11:8]
76543210
VERSION[7:0]
710
32142D–06/2013
ATUC64/128/256L3/4U
28.8 Module Configuration
The specific configuration for each ABDACB instance is listed in the following tables.The module
bus clocks listed here are connected to the system bus clocks. Please refer to the Power Manager
chapter for details.
Table 28-6. ABDACB Clocks
Clock Name Description
CLK_ABDACB Clock for the ABDACB bus interface
GCLK The generic clock used for the ABDACB is GCLK6
Table 28-7. Register Reset Values
Register Reset Value
VERSION 0x00000100
PARAMETER 0x00000000
711
32142D–06/2013
ATUC64/128/256L3/4U
29. ADC Interface (ADCIFB)
Rev:1.0.1.1
29.1 Features
• Multi-channel Analog-to-Digital Converter with up to 12-bit resolution
• Enhanced Resolution Mode
– 11-bit resolution obtained by interpolating 4 samples
– 12-bit resolution obtained by interpolating 16 samples
• Glueless interface with resistive touch screen panel, allowing
– Resistive Touch Screen position measurement
– Pen detection and pen loss detection
• Integrated enhanced sequencer
– ADC Mode
– Resistive Touch Screen Mode
• Numerous trigger sources
– Software
– Embedded 16-bit timer for periodic trigger
– Pen detect trigger
– Continuous trigger
– External trigger, rising, falling, or any-edge trigger
– Peripheral event trigger
• ADC Sleep Mode for low power ADC applications
• Programmable ADC timings
– Programmable ADC clock
– Programmable startup time
29.2 Overview
The ADC Interface (ADCIFB) converts analog input voltages to digital values. The ADCIFB is
based on a Successive Approximation Register (SAR) 10-bit Analog-to-Digital Converter (ADC).
The conversions extend from 0V to ADVREFP.
The ADCIFB supports 8-bit and 10-bit resolution mode, in addition to enhanced resolution mode
with 11-bit and 12-bit resolution. Conversion results are reported in a common register for all
channels.
The 11-bit and 12-bit resolution modes are obtained by interpolating multiple samples to acquire
better accuracy. For 11-bit mode 4 samples are used, which gives an effective sample rate of
1/4 of the actual sample frequency. For 12-bit mode 16 samples are used, giving a effective
sample rate of 1/16 of actual. This arrangement allows conversion speed to be traded for better
accuracy.
Conversions can be started for all enabled channels, either by a software trigger, by detection of
a level change on the external trigger pin (TRIGGER), or by an integrated programmable timer.
When the Resistive Touch Screen Mode is enabled, an integrated sequencer automatically configures
the pad control signals and performs resistive touch screen conversions.
The ADCIFB also integrates an ADC Sleep Mode, a Pen-Detect Mode, and an Analog Compare
Mode, and connects with one Peripheral DMA Controller channel. These features reduce both
power consumption and processor intervention.
712
32142D–06/2013
ATUC64/128/256L3/4U
29.3 Block Diagram
Figure 29-1. ADCIFB Block Diagram
ADVREFP
Analog Multiplexer
Successive
Approximation
Register
Analog-to-Digital
Converter
Trigger
ADC Control
Logic
Timer
User
Interface
AD0
AD1
AD3
ADn
AD2
Resisitve Touch
Screen
Sequencer
CLK_ADCIFB
....
ADCIFB
ADP0
ADP1
I/O Controller
TRIGGER
Peripheral
Bus
DMA
Request
Interrupt
Request
CLK_ADC
713
32142D–06/2013
ATUC64/128/256L3/4U
29.4 I/O Lines Description
29.5 Product Dependencies
In order to use this module, other parts of the system must be configured correctly, as described
below.
29.5.1 I/O Lines
The analog input pins can be multiplexed with I/O Controller lines. The user must make sure the
I/O Controller is configured correctly to allow the ADCIFB access to the AD pins before the
ADCIFB is instructed to start converting data. If the user fails to do this the converted data may
be wrong.
The number of analog inputs is device dependent, please refer to the ADCIFB Module Configuration
chapter for the number of available AD inputs on the current device.
The ADVREFP pin must be connected correctly prior to using the ADCIFB. Failing to do so will
result in invalid ADC operation. See the Electrical Characteristics chapter for details.
If the TRIGGER, ADP0, and ADP1 pins are to be used in the application, the user must configure
the I/O Controller to assign the needed pins to the ADCIFB function.
29.5.2 Power Management
If the CPU enters a sleep mode that disables clocks used by the ADCIFB, the ADCIFB will stop
functioning and resume operation after the system wakes up from sleep mode.
If the Peripheral Event System is configured to send asynchronous peripheral events to the
ADCIFB and the clock used by the ADCIFB is stopped, a local and temporary clock will automatically
be requested so the event can be processed. Refer to Section 29.6.13, Section 29.6.12,
and the Peripheral Event System chapter for details.
Before entering a sleep mode where the clock to the ADCIFB is stopped, make sure the Analogto-Digital
Converter cell is put in an inactive state. Refer to Section 29.6.13 for more information.
29.5.3 Clocks
The clock for the ADCIFB bus interface (CLK_ADCIFB) is generated by the Power Manager.
This clock is enabled at reset, and can be disabled in the Power Manager. It is recommended to
disable the ADCIFB before disabling the clock, to avoid freezing the ADCIFB in an undefined
state.
Table 29-1. I/O Lines Description
Pin Name Description Type
ADVREFP Reference voltage Analog
TRIGGER External trigger Digital
ADP0 Drive Pin 0 for Resistive Touch Screen top channel (Xp) Digital
ADP1 Drive Pin 1 for Resistive Touch Screen right channel (Yp) Digital
AD0-ADn Analog input channels 0 to n Analog
714
32142D–06/2013
ATUC64/128/256L3/4U
29.5.4 DMA
The ADCIFB DMA handshake interface is connected to the Peripheral DMA Controller. Using
the ADCIFB DMA functionality requires the Peripheral DMA Controller to be programmed first.
29.5.5 Interrupts
The ADCIFB interrupt request line is connected to the interrupt controller. Using the ADCIFB
interrupt request functionality requires the interrupt controller to be programmed first.
29.5.6 Peripheral Events
The ADCIFB peripheral events are connected via the Peripheral Event System. Refer to the
Peripheral Event System chapter for details
29.5.7 Debug Operation
When an external debugger forces the CPU into debug mode, this module continues normal
operation. If this module is configured in a way that requires it to be periodically serviced by the
CPU through interrupt requests or similar, improper operation or data loss may result during
debugging.
29.6 Functional Description
The ADCIFB embeds a Successive Approximation Register (SAR) Analog-to-Digital Converter
(ADC). The ADC supports 8-bit or 10-bit resolution, which can be extended to 11 or 12 bits by
the Enhanced Resolution Mode.
The conversion is performed on a full range between 0V and the reference voltage pin
ADVREFP. Analog inputs between these voltages converts to digital values (codes) based on a
linear conversion. This linear conversion is described in the expression below where M is the
number of bits used to represent the analog value, Vin is the voltage of the analog value to convert,
Vref is the maximum voltage, and Code is the converted digital value.
29.6.1 Initializing the ADCIFB
The ADC Interface is enabled by writing a one to the Enable bit in the Control Register (CR.EN).
After the ADC Interface is enabled, the ADC timings needs to be configured by writing the correct
values to the RES, PRESCAL, and STARTUP fields in the ADC Configuration Register
(ACR). See Section 29.6.5, and Section 29.6.7 for details. Before the ADCIFB can be used, the
I/O Controller must be configured correctly and the Reference Voltage (ADVREFP) signal must
be connected. Refer to Section 29.5.1 for details.
29.6.2 Basic Operation
To convert analog values to digital values the user must first initialize the ADCIFB as described
in Section 29.6.1. When the ADCIFB is initialized the channels to convert must be enabled by
writing a one the corresponding bits in the Channel Enable Register (CHER). Enabling channel
N instructs the ADCIFB to convert the analog voltage applied to AD pin N at each conversion
sequence. Multiple channels can be enabled resulting in multiple AD pins being converted at
each conversion sequence.
Code
2M Vin
Vref
= -------------------
715
32142D–06/2013
ATUC64/128/256L3/4U
To start converting data the user can either manually start a conversion sequence by writing a
one to the START bit in the Control Register (CR.START) or configure an automatic trigger to
initiate the conversions. The automatic trigger can be configured to trig on many different conditions.
Refer to Section 29.8.1 for details.
The result of the conversion is stored in the Last Converted Data Register (LCDR) as they
become available, overwriting the result from the previous conversion. To avoid data loss if more
than one channel is enabled, the user must read the conversion results as they become available
either by using an interrupt handler or by using a Peripheral DMA channel to copy the
results to memory. Failing to do so will result in an Overrun Error condition, indicated by the
OVRE bit in the Status Register (SR).
To use an interrupt handler the user must enable the Data Ready (DRDY) interrupt request by
writing a one to the corresponding bit in the Interrupt Enable Register (IER). To clear the interrupt
after the conversion result is read, the user must write a one to the corresponding bit in the
Interrupt Clear Register (ICR). See Section 29.6.11 for details.
To use a Peripheral DMA Controller channel the user must configure the Peripheral DMA Controller
appropriately. The Peripheral DMA Controller will, when configured, automatically read
converted data as they become available. There is no need to manually clear any bits in the
Interrupt Status Register as this is performed by the hardware. If an Overrun Error condition happens
during DMA operation, the OVRE bit in the SR will be set.
29.6.3 ADC Resolution
The Analog-to-Digital Converter cell supports 8-bit or 10-bit resolution, which can be extended to
11-bit and 12-bit with the Enhanced Resolution Mode. The resolution is selected by writing the
selected resolution value to the RES field in the ADC Configuration Register (ACR). See Section
29.9.3.
By writing a zero to the RES field, the ADC switches to the lowest resolution and the conversion
results can be read in the eight lowest significant bits of the Last Converted Data Register
(LCDR). The four highest bits of the Last Converted Data (LDATA) field in the LCDR register
reads as zero. Writing a one to the RES field enables 10-bit resolution, the optimal resolution for
both sampling speed and accuracy. Writing two or three automatically enables Enhanced Resolution
Mode with 11-bit or 12-bit resolution, see Section 29.6.4 for details.
When a Peripheral DMA Controller channel is connected to the ADCIFB in 10-bit, 11-bit, or 12-
bit resolution mode, a transfer size of 16 bits must be used. By writing a zero to the RES field,
the destination buffers can be optimized for 8-bit transfers.
29.6.4 Enhanced Resolution Mode
The Enhanced Resolution Mode is automatically enabled when 11-bit or 12-bit mode is selected
in the ADC Configuration Register (ACR). In this mode the ADCIFB will trade conversion performance
for accuracy by averaging multiple samples.
To be able to increase the accuracy by averaging multiple samples it is important that some
noise is present in the input signal. The noise level should be between one and two LSB peakto-peak
to get good averaging performance.
The performance cost of enabling 11-bit mode is 4 ADC samples, which reduces the effective
ADC performance by a factor 4. For 12-bit mode this factor is 16. For 12-bit mode the effective
sample rate is maximum ADC sample rate divided by 16.
716
32142D–06/2013
ATUC64/128/256L3/4U
29.6.5 ADC Clock
The ADCIFB generates an internal clock named CLK_ADC that is used by the Analog-to-Digital
Converter cell to perform conversions. The CLK_ADC frequency is selected by writing to the
PRESCAL field in the ADC Configuration Register (ACR). The CLK_ADC range is between
CLK_ADCIFB/2, if PRESCAL is 0, and CLK_ADCIFB/128, if PRESCAL is 63 (0x3F).
A sensible PRESCAL value must be used in order to provide an ADC clock frequency according
to the maximum sampling rate parameter given in the Electrical Characteristics section. Failing
to do so may result in incorrect Analog-to-Digital Converter operation.
29.6.6 ADC Sleep Mode
The ADC Sleep Mode maximizes power saving by automatically deactivating the Analog-to-Digital
Converter cell when it is not being used for conversions. The ADC Sleep Mode is enabled by
writing a one to the SLEEP bit in the ADC Configuration Register (ACR).
When a trigger occurs while the ADC Sleep Mode is enabled, the Analog-to-Digital Converter
cell is automatically activated. As the analog cell requires a startup time, the logic waits during
this time and then starts the conversion of the enabled channels. When conversions of all
enabled channels are complete, the ADC is deactivated until the next trigger.
29.6.7 Startup Time
The Analog-to-Digital Converter cell has a minimal startup time when the cell is activated. This
startup time is given in the Electrical Characteristics chapter and must be written to the
STARTUP field in the ADC Configuration Register (ACR) to get correct conversion results.
The STARTUP field expects the startup time to be represented as the number of CLK_ADC
cycles between 8 and 1024 and in steps of 8 that is needed to cover the ADC startup time as
specified in the Electrical Characteristics chapter.
The Analog-to-Digital Converter cell is activated at the first conversion after reset and remains
active if ACR.SLEEP is zero. If ACR.SLEEP is one, the Analog-to-Digital Converter cell is automatically
deactivated when idle and thus each conversion sequence will have a initial startup
time delay.
29.6.8 Sample and Hold Time
A minimal Sample and Hold Time is necessary for the ADCIFB to guarantee the best converted
final value when switching between ADC channels. This time depends on the input impedance
of the analog input, but also on the output impedance of the driver providing the signal to the
analog input, as there is no input buffer amplifier.
The Sample and Hold time has to be programmed through the SHTIM field in the ADC Configuration
Register (ACR). This field can define a Sample and Hold time between 1 and 16
CLK_ADC cycles.
29.6.9 ADC Conversion
ADC conversions are performed on all enabled channels when a trigger condition is detected.
For details regarding trigger conditions see Section 29.8.1. The term channel is used to identify
a specific analog input pin so it can be included or excluded in an Analog-to-Digital conversion
sequence and to identify which AD pin was used to convert the current value in the Last Converted
Data Register (LCDR). Channel number N corresponding to AD pin number N.
717
32142D–06/2013
ATUC64/128/256L3/4U
Channels are enabled by writing a one to the corresponding bit in the Channel Enable Register
(CHER), and disabled by writing a one to the corresponding bit in the Channel Disable Register
(CHDR). Active channels are listed in the Channel Status Register (CHSR).
When a conversion sequence is started, all enabled channels will be converted in one sequence
and the result will be placed in the Last Converted Data Register (LCDR) with the channel number
used to produce the result. It is important to read out the results while the conversion
sequence is ongoing, as new values will automatically overwrite any old value and the old value
will be lost if not previously read by the user.
If the Analog-to-Digital Converter cell is inactive when starting a conversion sequence, the conversion
logic will wait a configurable number of CLK_ADC cycles as defined in the startup time
field in the ADC Configuration Register (ACR). After the cell is activated all enabled channels is
converted one by one until no more enabled channels exist. The conversion sequence converts
each enabled channel in order starting with the channel with the lowest channel number. If the
ACR.SLEEP bit is one, the Analog-to-Digital Converter cell is deactivated after the conversion
sequence has finished.
For each channel converted, the ADCIFB waits a Sample and Hold number of CLK_ADC cycles
as defined in the SHTIM field in ACR, and then instructs the Analog-to-Digital Converter cell to
start converting the analog voltage. The ADC cell requires 10 CLK_ADC cycles to actually convert
the value, so the total time to convert a channel is Sample and Hold + 10 CLK_ADC cycles.
29.6.10 Analog Compare Mode
The ADCIFB can test if the converted values, as they become available, are below, above, or
inside a specified range and generate interrupt requests based on this information. This is useful
for applications where the user wants to monitor some external analog signal and only initiate
actions if the value is above, below, or inside some specified range.
The Analog Compare mode is enabled by writing a one to the Analog Compare Enable (ACE) bit
in the Mode Register (MR). The values to compare must be written to the Low Value (LV) field
and the High Value (HV) field in the Compare Value Register (CVR). The Analog Compare
mode will, when enabled, check all enabled channels against the pre-programmed high and low
values and set status bits.
To generate an interrupt request if a converted value is below a limit, write the limit to the
CVR.LV field and enable interrupt request on the Compare Lesser Than (CLT) bit by writing a
one to the corresponding bit in the Interrupt Enable Register (IER). To generate an interrupt
request if a converted value is above a limit, write the limit to the CVR.HV field and enable interrupt
for Compare Greater Than (CGT) bit. To generate an interrupt request if a converted value
is inside a range, write the low and high limit to the LV and HV fields and enable the Compare
Else (CELSE) interrupt. To generate an interrupt request if a value is outside a range, write the
LV and HV fields to the low and high limits of the range and enable CGT and CLT interrupts.
Note that the values written to LV and HV must match the resolution selected in the ADC Configuration
Register (ACR).
29.6.11 Interrupt Operation
Interrupt requests are enabled by writing a one to the corresponding bit in the Interrupt Enable
Register (IER) and disabled by writing a one to the corresponding bit in the Interrupt Disable
Register (IDR). Enabled interrupts can be read from the Interrupt Mask Register (IMR). Active
interrupt requests, but potentially masked, are visible in the Interrupt Status Register (ISR). To
718
32142D–06/2013
ATUC64/128/256L3/4U
clear an active interrupt request, write a one to the corresponding bit in the Interrupt Clear Register
(ICR).
The source for the interrupt requests are the status bits in the Status Register (SR). The SR
shows the ADCIFB status at the time the register is read. The Interrupt Status Register (ISR)
shows the status since the last write to the Interrupt Clear Register. The combination of ISR and
SR allows the user to react to status change conditions but also allows the user to read the current
status at any time.
29.6.12 Peripheral Events
The Peripheral Event System can be used together with the ADCIFB to allow any peripheral
event generator to be used as a trigger source. To enable peripheral events to trigger a conversion
sequence the user must write the Peripheral Event Trigger value (0x7) to the Trigger Mode
(TRGMOD) field in the Trigger Register (TRGR). Refer to Table 29-4 on page 730. The user
must also configure a peripheral event generator to emit peripheral events for the ADCIFB to
trigger on. Refer to the Peripheral Event System chapter for details.
29.6.13 Sleep Mode
Before entering sleep modes the user must make sure the ADCIFB is idle and that the Analogto-Digital
Converter cell is inactive. To deactivate the Analog-to-Digital Converter cell the SLEEP
bit in the ADC Configuration Register (ACR) must be written to one and the ADCIFB must be
idle. To make sure the ADCIFB is idle, write a zero the Trigger Mode (TRGMOD) field in the
Trigger Register (TRGR) and wait for the READY bit in the Status Register (SR) to be set.
Note that by deactivating the Analog-to-Digital Converter cell, a startup time penalty as defined
in the STARTUP field in the ADC Configuration Register (ACR) will apply on the next
conversion.
29.6.14 Conversion Performances
For performance and electrical characteristics of the ADCIFB, refer to the Electrical Characteristics
chapter.
29.7 Resistive Touch Screen
The ADCIFB embeds an integrated Resistive Touch Screen Sequencer that can be used to calculate
contact coordinates on a resistive touch screen film. When instructed to start, the
integrated Resistive Touch Screen Sequencer automatically applies a sequence of voltage patterns
to the resistive touch screen films and the Analog-to-Digital Conversion cell is used to
measure the effects. The resulting measurements can be used to calculate the horizontal and
vertical contact coordinates. It is recommended to use a high resistance touch screen for optimal
resolution.
The resistive touch screen film is connected to the ADCIFB using the AD and ADP pins. See
Section 29.7.3 for details.
Resistive Touch Screen Mode is enabled by writing a one to the Touch Screen ADC Mode field
in the Mode Register (MR.TSAMOD). In this mode, channels TSPO+0 though TSPO+3 are
automatically enabled where TSPO refers to the Touch Screen Pin Offset field in the Mode Register
(MR.TSPO). For each conversion sequence, all enabled channels before TSPO+0 and
after TSPO+3 are converted as ordinary ADC channels, producing 1 conversion result each.
When the sequencer enters the TSPO+0 channel the Resistive Touch Screen Sequencer will
take over control and convert the next 4 channels as described in Section 29.7.4.
719
32142D–06/2013
ATUC64/128/256L3/4U
29.7.1 Resistive Touch Screen Principles
A resistive touch screen is based on two resistive films, each one fitted with a pair of electrodes,
placed at the top and bottom on one film, and on the right and left on the other. Between the two,
there is a layer that acts as an insulator, but makes a connection when pressure is applied to the
screen. This is illustrated in Figure 29-2 on page 719.
Figure 29-2. Resistive Touch Screen Position Measurement
29.7.2 Position Measurement Method
As shown in Figure 29-2 on page 719, to detect the position of a contact, voltage is first applied
to XP (top) and Xm (bottom) leaving Yp and Ym tristated. Due to the linear resistance of the film,
there is a voltage gradient from top to bottom on the first film. When a contact is performed on
the screen, the voltage at the contact point propagates to the second film. If the input impedance
on the YP (right) and Ym (left) electrodes are high enough, no current will flow, allowing the voltage
at the contact point to be measured at Yp. The value measured represents the vertical
position component of the contact point.
For the horizontal direction, the same method is used, but by applying voltage from YP (right) to
Ym (left) and measuring at XP.
In an ideal world (linear, with no loss), the vertical position is equal to:
VYP / VDD
To compensate for some of the real world imperfections, VXP and VXm can be measured and
used to improve accuracy at the cost of two more conversions per axes. The new expression for
the vertical position then becomes:
(VYP - VXM) / (VXP - VXM)
XM
XP
YM YP
XP
XM
YP
VDD
GND
Volt
Horizontal Position Detection
YP
YM
XP
VDD
GND
Volt
Vertical Position Detection
Pen
Contact
720
32142D–06/2013
ATUC64/128/256L3/4U
29.7.3 Resistive Touch Screen Pin Connections
The resistive touch screen film signals connects to the ADCIFB using the AD and ADP pins. The
XP (top) and XM (bottom) film signals are connected to ADtspo+0 and ADtspo+1 pins, and the YP
(right) and YM (left) signals are connected to ADtspo+2 and ADtspo+3 pins. The tspo index is
configurable through the Touch Screen Pin Offset (TSPO) field in the Mode Register (MR) and
allows the user to configure which AD pins to use for resistive touch screen applications. Writing
a zero to the TSPO field instructs the ADCIFB to use AD0 through AD3, where AD0 is connected
to XP, AD1 is connected to XM and so on. Writing a one to the TSPO field instructs the
ADCIFB to use AD1 through AD4 for resistive touch screen sequencing, where AD1 is connected
to XP and AD0 is free to be used as an ordinary ADC channel.
When the Analog Pin Output Enable (APOE) bit in the Mode Register (MR) is zero, the AD pins
are used to measure input voltage and drive the GND sequences, while the ADP pins are used
to drive the VDD sequences. This arrangement allows the user to reduce the voltage seen at the
AD input pins by inserting external resistors between ADP0 and XP and ADP1 and YP signals
which are again directly connected to the AD pins. It is important that the voltages observed at
the AD pins are not higher than the maximum allowed ADC input voltage. See Figure 29-3 on
page 721 for details regarding how to connect the resistive touch screen films to the AD and
ADP pins.
By adding a resistor between ADP0 and XP, and ADP1 and YP, the maximum voltage observed
at the AD pins can be controlled by the following voltage divider expressions:
The Rfilmx parameter is the film resistance observed when measuring between XP and XM. The
Rresistorx parameter is the resistor size inserted between ADP0 and XP. The definition of Rfilmy
and Rresistory is the same but for ADP1, YP, and YM instead.
Table 29-2. Resistive Touch Screen Pin Connections
ADCIFB Pin TS Signal, APOE == 0 TS Signal, APOE == 1
ADP0 Xp through a resistor No Connect
ADP1 Yp through a resistor No Connect
ADtspo+0 Xp Xp
ADtspo+1 Xm Xm
ADtspo+2 Yp Yp
ADtspo+3 Ym Ym
V ADtspo + 0
Rfilmx
Rfilmx Rresistorx + -------------------------------------------- V DP0 =
721
32142D–06/2013
ATUC64/128/256L3/4U
The ADP pins are used by default, as the APOE bit is zero after reset. Writing a one to the
APOE bit instructs the ADCIFB Resistive Touch Screen Sequencer to use the already connected
ADtspo+0 and ADtspo+2 pins to drive VDD to XP and YP signals directly. In this mode the
ADP pins can be used as general purpose I/O pins.
Before writing a one to the APOE bit the user must make sure that the I/O voltage is compatible
with the ADC input voltage. If the I/O voltage is higher than the maximum input voltage of the
ADC, permanent damage may occur. Refer to the Electrical Characteristics chapter for details.
Figure 29-3. Resistive Touch Screen Pin Connections
V ADtspo + 2
Rfilmy
Rfilmy Rresistory + -------------------------------------------- V DP1 =
ADtspo+1
XM
XP
YM YP
ADtspo+0
DP1
DP0
ADtspo+3
ADtspo+2
Analog Pin Output Enable (MR.APOE) == 0
ADtspo+1
XM
XP
YM YP
ADtspo+0
DP1
DP0
ADtspo+3
ADtspo+2
Analog Pin Output Enable (MR.APOE) == 1
NC
NC
722
32142D–06/2013
ATUC64/128/256L3/4U
29.7.4 Resistive Touch Screen Sequencer
The Resistive Touch Screen Sequencer is responsible for applying voltage to the resistive touch
screen films as described in Section 29.7.2. This is done by controlling the output enable and the
output value of the ADP and AD pins. This allows the Resistive Touch Screen Sequencer to add
a voltage gradient on one film while keeping the other film floating so a touch can be measured.
The Resistive Touch Screen Sequencer will when measuring the vertical position, apply VDD
and GND to the pins connected to XP and XM. The YP and YM pins are put in tristate mode so the
measurement of YP can proceed without interference. To compensate for ADC offset errors and
non ideal pad drivers, the actual voltage of XP and XM is measured as well, so the real values for
VDD and GND can be used in the contact point calculation to increase accuracy. See second
formula in Section 29.7.2.
When the vertical values are converted the same setup is applies for the second axes, by setting
XP and XM in tristate mode and applying VDD and GND to YP and YM. Refer to Section 29.8.3 for
details.
29.7.5 Pen Detect
If no contact is applied to the resistive touch screen films, any resistive touch screen conversion
result will be undefined as the film being measured is floating. This can be avoided by enabling
Pen Detect and only trigger resistive touch screen conversions when the Pen Contact
(PENCNT) status bit in the Status Register (SR) is one. Pen Detect is enabled by writing a one
to the Pen Detect (PENDET) bit in the Mode Register (MR).
When Pen Detect is enabled, the ADCIFB grounds the vertical panel by applying GND to XP and
XM and polarizes the horizontal panel by enabling pull-up on the pin connected to YP. The YM pin
will in this mode be tristated. Since there is no contact, no current is flowing and there is no
related power consumption. As soon as a contact occurs, GND will propagate to YM by pulling
down YP, allowing the contact to be registered by the ADCIFB.
A programmable debouncing filter can be used to filter out false pen detects because of noise.
The debouncing filter is programmable from one CLK_ADC period and up to 215 CLK_ADC periods.
The debouncer length is set by writing to the PENDBC field in MR.
723
32142D–06/2013
ATUC64/128/256L3/4U
Figure 29-4. Resistive Touch Screen Pen Detect
The Resistive Touch Screen Pen Detect can be used to generate an ADCIFB interrupt request
or it can be used to trig a conversion, so that a position can be measured as soon as a contact is
detected.
The Pen Detect Mode generates two types of status signals, reported in the Status Register
(SR):
• The bit PENCNT is set when current flows and remains set until current stops.
• The bit NOCNT is set when no current flows and remains set until current flows.
Before a current change is reflected in the SR, the new status must be stable for the duration of
the debouncing time.
Both status conditions can generate an interrupt request if the corresponding bit in the Interrupt
Mask Register (IMR) is one. Refer to Section 29.6.11 on page 717.
XP
XM
YM
YP
Tristate
GND
Pullup T o the ADC
Debouncer Pen Interrupt
PENDBC
GND
Resistive
Touch Screen
Sequencer
724
32142D–06/2013
ATUC64/128/256L3/4U
29.8 Operating Modes
The ADCIFB features two operating modes, each defining a separate conversion sequence:
• ADC Mode: At each trigger, all the enabled channels are converted.
• Resistive Touch Screen Mode: At each trigger, all enabled channels plus the resistive touch
screen channels are converted as described in Section 29.8.3. If channels except the
dedicated resistive touch screen channels are enabled, they are converted normally before
and after the resistive touch screen channels are converted.
The operating mode is selected by the TSAMOD field in the Mode Register (MR).
29.8.1 Conversion Triggers
A conversion sequence is started either by a software or by a hardware trigger. When a conversion
sequence is started, all enabled channels will be converted and made available in the
shared Last Converted Register (LCDR).
The software trigger is asserted by writing a one to the START field in the Control Register (CR).
The hardware trigger can be selected by the TRGMOD field in the Trigger Register (TRGR). Different
hardware triggers exist:
• External trigger, either rising or falling or any, detected on the external trigger pin TRIGGER
• Pen detect trigger, depending the PENDET bit in the Mode Register (MR)
• Continuous trigger, meaning the ADCIFB restarts the next sequence as soon as it finishes
the current one
• Periodic trigger, which is defined by the TRGR.TRGPER field
• Peripheral event trigger, allowing the Peripheral Event System to synchronize conversion with
some configured peripheral event source.
Enabling a hardware trigger does not disable the software trigger functionality. Thus, if a hardware
trigger is selected, the start of a conversion can still be initiated by the software trigger.
29.8.2 ADC Mode
In the ADC Mode, the active channels are defined by the Channel Status Register (CHSR). A
channel is enabled by writing a one to the corresponding bit in the Channel Enable Register
(CHER), and disabled by writing a one to the corresponding bit in the Channel Disable Register
(CHDR). The conversion results are stored in the Last Converted Data Register (LCDR) as they
become available, overwriting old conversions.
At each trigger, the following sequence is performed:
1. If ACR.SLEEP is one, wake up the ADC and wait for the startup time.
2. If Channel 0 is enabled, convert Channel 0 and store result in LCDR.
3. If Channel 1 is enabled, convert Channel 1 and store result in LCDR.
4. If Channel N is enabled, convert Channel N and store result in LCDR.
5. If ACR.SLEEP is one, place the ADC cell in a low-power state.
If the Peripheral DMA Controller is enabled, all converted values are transferred continuously
into the memory buffer.
29.8.3 Resistive Touch Screen Mode
Writing a one to the TSAMOD field in the Mode Register (MR) enables Resistive Touch Screen
Mode. In this mode the channels TSPO+0 to TSPO+3, corresponding to the resistive touch
725
32142D–06/2013
ATUC64/128/256L3/4U
screen inputs, are automatically activated. In addition, if any other channels are enabled, they
will be converted before and after the resistive touch screen conversion.
At each trigger, the following sequence is performed:
1. If ACR.SLEEP is one, wake up the ADC cell and wait for the startup time.
2. Convert all enabled channels before TSPO and store the results in the LCDR.
3. Apply supply on the inputs XP and XM during the Sample and Hold Time.
4. Convert Channel XM and store the result in TMP.
5. Apply supply on the inputs XP and XM during the Sample and Hold Time.
6. Convert Channel XP, subtract TMP from the result and store the subtracted result in
LCDR.
7. Apply supply on the inputs XP and XM during the Sample and Hold Time.
8. Convert Channel YP, subtract TMP from the result and store the subtracted result in
LCDR.
9. Apply supply on the inputs YP and YM during the Sample and Hold Time.
10. Convert Channel YM and store the result in TMP.
11. Apply supply on the inputs YP and YM during the Sample and Hold Time.
12. Convert Channel YP, subtract TMP from the result and store the subtracted result in
LCDR.
13. Apply supply on the inputs YP and YM during the Sample and Hold Time.
14. Convert Channel XP, subtract TMP from the result and store the subtracted result in
LCDR.
15. Convert all enabled channels after TSPO + 3 and store results in the LCDR.
16. If ACR.SLEEP is one, place the ADC cell in a low-power state.
The resulting buffer structure stored in memory is:
1. XP - XM
2. YP - XM
3. YP - YM
4. XP - YM.
The vertical position can be easily calculated by dividing the data at offset 1(XP - XM) by the data
at offset 2(YP - XM).
The horizontal position can be easily calculated by dividing the data at offset 3(YP - YM) by the
data at offset 4(XP - YM).
726
32142D–06/2013
ATUC64/128/256L3/4U
29.9 User Interface
Note: 1. The reset values for these registers are device specific. Please refer to the Module Configuration section at the end of this
chapter.
Table 29-3. ADCIFB Register Memory Map
Offset Register Name Access Reset
0x00 Control Register CR Write-only -
0x04 Mode Register MR Read/Write 0x00000000
0x08 ADC Configuration Register ACR Read/Write 0x00000000
0x0C Trigger Register TRGR Read/Write 0x00000000
0x10 Compare Value Register CVR Read/Write 0x00000000
0x14 Status Register SR Read-only 0x00000000
0x18 Interrupt Status Register ISR Read-only 0x00000000
0x1C Interrupt Clear Register ICR Write-only -
0x20 Interrupt Enable Register IER Write-only -
0x24 Interrupt Disable Register IDR Write-only -
0x28 Interrupt Mask Register IMR Read-only 0x00000000
0x2C Last Converted Data Register LCDR Read-only 0x00000000
0x30 Parameter Register PARAMETER Read-only -(1)
0x34 Version Register VERSION Read-only -(1)
0x40 Channel Enable Register CHER Write-only -
0x44 Channel Disable Register CHDR Write-only -
0x48 Channel Status Register CHSR Read-only 0x00000000
727
32142D–06/2013
ATUC64/128/256L3/4U
29.9.1 Control Register
Register Name: CR
Access Type: Write-only
Offset: 0x00
Reset Value: 0x00000000
• DIS: ADCDIFB Disable
Writing a zero to this bit has no effect.
Writing a one to this bit disables the ADCIFB.
Note: Disabling the ADCIFB effectively stops all clocks in the module so the user must make sure the ADCIFB is idle before
disabling the ADCIFB.
• EN: ADCIFB Enable
Writing a zero to this bit has no effect.
Writing a one to this bit enables the ADCIFB.
Note: The ADCIFB must be enabled before use.
• START: Start Conversion
Writing a zero to this bit has no effect.
Writing a one to this bit starts an Analog-to-Digital conversion.
• SWRST: Software Reset
Writing a zero to this bit has no effect.
Writing a one to this bit resets the ADCIFB, simulating a hardware reset.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
- - - - - - DIS EN
76543210
- - - - - - START SWRST
728
32142D–06/2013
ATUC64/128/256L3/4U
29.9.2 Mode Register
Name: MR
Access Type: Read/Write
Offset: 0x04
Reset Value: 0x00000000
• PENDBC: Pen Detect Debouncing Period
Period = 2PENDBC*TCLK_ADC
• TSPO: Touch Screen Pin Offset
The Touch Screen Pin Offset field is used to indicate which AD pins are connected to the resistive touch screen film edges. Only
an offset is specified and it is assumed that the resistive touch screen films are connected sequentially from the specified offset
pin and up to and including offset + 3 (4 pins).
• APOE: Analog Pin Output Enable
0: AD pins are not used to drive VDD in resistive touch screen sequence.
1: AD pins are used to drive VDD in resistive touch screen sequence.
Note: If the selected I/O voltage configuration is incompatible with the Analog-to-Digital converter cell voltage specification, this
bit must stay cleared to avoid damaging the ADC. In this case the ADP pins must be used to drive VDD instead, as described in
Section 29.7.3. If the I/O and ADC voltages are compatible, the AD pins can be used directly by writing a one to this bit. In this
case the ADP pins can be ignored.
• ACE: Analog Compare Enable
0: The analog compare functionality is disabled.
1: The analog compare functionality is enabled.
• PENDET: Pen Detect
0: The pen detect functionality is disabled.
1: The pen detect functionality is enabled.
Note: Touch detection logic can only be enabled when the ADC sequencer is idle. For successful pen detection the user must
make sure there is enough idle time between consecutive scans for the touch detection logic to settle.
• TSAMOD: Touch Screen ADC Mode
0: Touch Screen Mode is disabled.
1: Touch Screen Mode is enabled.
31 30 29 28 27 26 25 24
PENDBC - - - -
23 22 21 20 19 18 17 16
TSPO
15 14 13 12 11 10 9 8
--------
76543210
- APOE ACE PENDET - - - TSAMOD
729
32142D–06/2013
ATUC64/128/256L3/4U
29.9.3 ADC Configuration Register
Name: ACR
Access Type: Read/Write
Offset: 0x08
Reset Value: 0x00000000
• SHTIM: Sample & Hold Time for ADC Channels
• STARTUP: Startup Time
• PRESCAL: Prescaler Rate Selection
• RES: Resolution Selection
0: 8-bit resolution.
1: 10-bit resolution.
2: 11-bit resolution, interpolated.
3: 12-bit resolution, interpolated.
• SLEEP: ADC Sleep Mode
0: ADC Sleep Mode is disabled.
1: ADC Sleep Mode is enabled.
31 30 29 28 27 26 25 24
- - - - SHTIM
23 22 21 20 19 18 17 16
- STARTUP
15 14 13 12 11 10 9 8
- - PRESCAL
76543210
- - RES - - - SLEEP
TSAMPLE&HOLD SHTIM + 2 TCLK_ADC =
TARTUP STARTUP + 1 8 TCLK_AD =
TCLK_ADC = PRESCAL + 1 2 TCLK_ADCIFB
730
32142D–06/2013
ATUC64/128/256L3/4U
29.9.4 Trigger Register
Name: TRGR
Access Type: Read/Write
Offset: 0x0C
Reset Value: 0x00000000
• TRGPER: Trigger Period
Effective only if TRGMOD defines a Periodic Trigger.
Defines the periodic trigger period, with the following equations:
Trigger Period = TRGPER *TCLK_ADC
• TRGMOD: Trigger Mode
31 30 29 28 27 26 25 24
TRGPER[15:8]
23 22 21 20 19 18 17 16
TRGPER[7:0]
15 14 13 12 11 10 9 8
--------
76543210
- - - - - TRGMOD
Table 29-4. Trigger Modes
TRGMOD Selected Trigger Mode
0 0 0 No trigger, only software trigger can start conversions
0 0 1 External Trigger Rising Edge
0 1 0 External Trigger Falling Edge
0 1 1 External Trigger Any Edge
100 Pen Detect Trigger (shall be selected only if PENDET is set and TSAMOD = Touch
Screen mode)
1 0 1 Periodic Trigger (TRGPER shall be initiated appropriately)
1 1 0 Continuous Mode
1 1 1 Peripheral Event Trigger
731
32142D–06/2013
ATUC64/128/256L3/4U
29.9.5 Compare Value Register
Name: CVR
Access Type: Read/Write
Offset: 0x10
Reset Value: 0x00000000
• HV: High Value
Defines the high value used when comparing analog input.
• LV: Low Value
Defines the low value used when comparing analog input.
31 30 29 28 27 26 25 24
- - - - HV[11:8]
23 22 21 20 19 18 17 16
HV[7:0]
15 14 13 12 11 10 9 8
- - - - LV[11:8]
76543210
LV[7:0]
732
32142D–06/2013
ATUC64/128/256L3/4U
29.9.6 Status Register
Name: SR
Access Type: Read-only
Offset: 0x14
Reset Value: 0x00000000
• EN: Enable Status
0: The ADCIFB is disabled.
1: The ADCIFB is enabled.
This bit is cleared when CR.DIS is written to one.
This bit is set when CR.EN is written to one.
• CELSE: Compare Else Status
This bit is cleared when either CLT or CGT are detected or when analog compare is disabled.
This bit is set when no CLT or CGT are detected on the last converted data and analog compare is enabled.
• CGT: Compare Greater Than Status
This bit is cleared when no compare greater than CVR.HV is detected on the last converted data or when analog compare is
disabled.
This bit is set when compare greater than CVR.HV is detected on the last converted data and analog compare is enabled.
• CLT: Compare Lesser Than Status
This bit is cleared when no compare lesser than CVR.LV is detected on the last converted data or when analog compare is
disabled.
This bit is set when compare lesser than CVR.LV is detected on the last converted data and analog compare is enabled.
• BUSY: Busy Status
This bit is cleared when the ADCIFB is ready to perform a conversion sequence.
This bit is set when the ADCIFB is busy performing a convention sequence.
• READY: Ready Status
This bit is cleared when the ADCIFB is busy performing a conversion sequence
This bit is set when the ADCIFB is ready to perform a conversion sequence.
• NOCNT: No Contact Status
This bit is cleared when no contact loss is detected or pen detect is disabled
This bit is set when contact loss is detected and pen detect is enabled.
• PENCNT: Pen Contact Status
This bit is cleared when no contact is detected or pen detect is disabled.
31 30 29 28 27 26 25 24
- - - - - - - EN
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
- CELSE CGT CLT - - BUSY READY
76543210
- - NOCNT PENCNT - - OVRE DRDY
733
32142D–06/2013
ATUC64/128/256L3/4U
This bit is set when pen contact is detected and pen detect is enabled.
• OVRE: Overrun Error Status
This bit is cleared when no Overrun Error has occurred since the start of a conversion sequence.
This bit is set when one or more Overrun Error has occurred since the start of a conversion sequence.
• DRDY: Data Ready Status
0: No data has been converted since the last reset.
1: One or more conversions have completed since the last reset and data is available in LCDR.
This bit is cleared when CR.SWRST is written to one.
This bit is set when one or more conversions have completed and data is available in LCDR.
734
32142D–06/2013
ATUC64/128/256L3/4U
29.9.7 Interrupt Status Register
Name: ISR
Access Type: Read-only
Offset: 0x18
Reset Value: 0x00000000
• CELSE: Compare Else Status
This bit is cleared when the corresponding bit in ICR is written to one.
This bit is set when the corresponding bit in SR has a zero-to-one transition.
• CGT: Compare Greater Than Status
This bit is cleared when the corresponding bit in ICR is written to one.
This bit is set when the corresponding bit in SR has a zero-to-one transition.
• CLT: Compare Lesser Than Status
This bit is cleared when the corresponding bit in ICR is written to one.
This bit is set when the corresponding bit in SR has a zero-to-one transition.
• BUSY: Busy Status
This bit is cleared when the corresponding bit in ICR is written to one.
This bit is set when the corresponding bit in SR has a zero-to-one transition.
• READY: Ready Status
This bit is cleared when the corresponding bit in ICR is written to one.
This bit is set when the corresponding bit in SR has a zero-to-one transition.
• NOCNT: No Contact Status
This bit is cleared when the corresponding bit in ICR is written to one.
This bit is set when the corresponding bit in SR has a zero-to-one transition.
• PENCNT: Pen Contact Status
This bit is cleared when the corresponding bit in ICR is written to one.
This bit is set when the corresponding bit in SR has a zero-to-one transition.
• OVRE: Overrun Error Status
This bit is cleared when the corresponding bit in ICR is written to one.
This bit is set when the corresponding bit in SR has a zero-to-one transition.
• DRDY: Data Ready Status
This bit is cleared when the corresponding bit in ICR is written to one.
This bit is set when a conversion has completed and new data is available in LCDR.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
- CELSE CGT CLT - - BUSY READY
76543210
- - NOCNT PENCNT - - OVRE DRDY
735
32142D–06/2013
ATUC64/128/256L3/4U
29.9.8 Interrupt Clear Register
Name: ICR
Access Type: Write-only
Offset: 0x1C
Reset Value: 0x00000000
Writing a zero to a bit in this register has no effect.
Writing a one to a bit in this register will clear the corresponding bit in ISR and the corresponding interrupt request.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
- CELSE CGT CLT - - BUSY READY
76543210
- - NOCNT PENCNT - - OVRE DRDY
736
32142D–06/2013
ATUC64/128/256L3/4U
29.9.9 Interrupt Enable Register
Name: IER
Access Type: Write-only
Offset: 0x20
Reset Value: 0x00000000
Writing a zero to a bit in this register has no effect.
Writing a one to a bit in this register will set the corresponding bit in IMR.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
- CELSE CGT CLT - - BUSY READY
76543210
- - NOCNT PENCNT - - OVRE DRDY
737
32142D–06/2013
ATUC64/128/256L3/4U
29.9.10 Interrupt Disable Register
Name: IDR
Access Type: Write-only
Offset: 0x24
Reset Value: 0x00000000
Writing a zero to a bit in this register has no effect.
Writing a one to a bit in this register will clear the corresponding bit in IMR.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
- CELSE CGT CLT - - BUSY READY
76543210
- - NOCNT PENCNT - - OVRE DRDY
738
32142D–06/2013
ATUC64/128/256L3/4U
29.9.11 Interrupt Mask Register
Name: IMR
Access Type: Read-only
Offset: 0x28
Reset Value: 0x00000000
0: The corresponding interrupt is disabled.
1: The corresponding interrupt is enabled.
A bit in this register is cleared by writing a one to the corresponding bit in Interrupt Disable Register (IDR).
A bit in this register is set by writing a one to the corresponding bit in Interrupt Enable Register (IER).
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
- CELSE CGT CLT - - BUSY READY
76543210
- - NOCNT PENCNT - - OVRE DRDY
739
32142D–06/2013
ATUC64/128/256L3/4U
29.9.12 Last Converted Data Register
Name: LCDR
Access Type: Read-only
Offset: 0x2C
Reset Value: 0x00000000
• LCCH: Last Converted Channel
This field indicates what channel was last converted, i.e. what channel the LDATA represents.
• LDATA: Last Data Converted
The analog-to-digital conversion data is placed in this register at the end of a conversion on any analog channel and remains
until a new conversion on any analog channel is completed.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
LCCH
15 14 13 12 11 10 9 8
- - - - LDATA[11:8]
76543210
LDATA[7:0]
740
32142D–06/2013
ATUC64/128/256L3/4U
29.9.13 Parameter Register
Name: PARAMETER
Access Type: Read-only
Offset: 0x30
Reset Value: 0x00000000
• CHn: Channel n Implemented
0: The corresponding channel is not implemented.
1: The corresponding channel is implemented.
31 30 29 28 27 26 25 24
CH31 CH30 CH29 CH28 CH27 CH26 CH25 CH24
23 22 21 20 19 18 17 16
CH23 CH22 CH21 CH20 CH19 CH18 CH17 CH16
15 14 13 12 11 10 9 8
CH15 CH14 CH13 CH12 CH11 CH10 CH9 CH8
76543210
CH7 CH6 CH5 CH4 CH3 CH2 CH1 CH0
741
32142D–06/2013
ATUC64/128/256L3/4U
29.9.14 Version Register
Name: VERSION
Access Type: Read-only
Offset: 0x34
Reset Value: 0x00000000
• VARIANT: Variant Number
Reserved. No functionality associated.
• VERSION: Version Number
Version number of the Module. No functionality associated.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
- - - - VARIANT
15 14 13 12 11 10 9 8
- - - - VERSION[11:8]
76543210
VERSION[7:0]
742
32142D–06/2013
ATUC64/128/256L3/4U
29.9.15 Channel Enable Register
Name: CHER
Access Type: Write-only
Offset: 0x40
Reset Value: 0x00000000
• CHn: Channel n Enable
Writing a zero to a bit in this register has no effect
Writing a one to a bit in this register enables the corresponding channel
The number of available channels is device dependent. Please refer to the Module Configuration section at the end of this
chapter for information regarding which channels are implemented.
31 30 29 28 27 26 25 24
CH31 CH30 CH29 CH28 CH27 CH26 CH25 CH24
23 22 21 20 19 18 17 16
CH23 CH22 CH21 CH20 CH19 CH18 CH17 CH16
15 14 13 12 11 10 9 8
CH15 CH14 CH13 CH12 CH11 CH10 CH9 CH8
76543210
CH7 CH6 CH5 CH4 CH3 CH2 CH1 CH0
743
32142D–06/2013
ATUC64/128/256L3/4U
29.9.16 Channel Disable Register
Name: CHDR
Access Type: Write-only
Offset: 0x44
Reset Value: 0x00000000
• CHn: Channel N Disable
Writing a zero to a bit in this register has no effect.
Writing a one to a bit in this register disables the corresponding channel.
Warning: If the corresponding channel is disabled during a conversion, or if it is disabled and then re-enabled during a
conversion, its associated data and its corresponding DRDY and OVRE bits in SR are unpredictable.
The number of available channels is device dependent. Please refer to the Module Configuration section at the end of this
chapter for information regarding how many channels are implemented.
31 30 29 28 27 26 25 24
CH31 CH30 CH29 CH28 CH27 CH26 CH25 CH24
23 22 21 20 19 18 17 16
CH23 CH22 CH21 CH20 CH19 CH18 CH17 CH16
15 14 13 12 11 10 9 8
CH15 CH14 CH13 CH12 CH11 CH10 CH9 CH8
76543210
CH7 CH6 CH5 CH4 CH3 CH2 CH1 CH0
744
32142D–06/2013
ATUC64/128/256L3/4U
29.9.17 Channel Status Register
Name: CHSR
Access Type: Read-only
Offset: 0x48
Reset Value: 0x00000000
• CHn: Channel N Status
0: The corresponding channel is disabled.
1: The corresponding channel is enabled.
A bit in this register is cleared by writing a one to the corresponding bit in Channel Disable Register (CHDR).
A bit in this register is set by writing a one to the corresponding bit in Channel Enable Register (CHER).
The number of available channels is device dependent. Please refer to the Module Configuration section at the end of this
chapter for information regarding how many channels are implemented.
31 30 29 28 27 26 25 24
CH31 CH30 CH29 CH28 CH27 CH26 CH25 CH24
23 22 21 20 19 18 17 16
CH23 CH22 CH21 CH20 CH19 CH18 CH17 CH16
15 14 13 12 11 10 9 8
CH15 CH14 CH13 CH12 CH11 CH10 CH9 CH8
76543210
CH7 CH6 CH5 CH4 CH3 CH2 CH1 CH0
745
32142D–06/2013
ATUC64/128/256L3/4U
29.10 Module Configuration
The specific configuration for each ADCIFB instance is listed in the following tables.The module
bus clocks listed here are connected to the system bus clocks. Please refer to the Power Manager
chapter for details.
Note: 1. AD3 does not exist
Table 29-5. Module Configuration
Feature ADCIFB
Number of ADC channels 9 (8 + 1 internal temperature sensor channel)
Table 29-6. ADCIFB Clocks
Clock Name Description
CLK_ADCIFB Clock for the ADCIFB bus interface
Table 29-7. Register Reset Values
Register Reset Value
VERSION 0x00000110
PARAMETER 0x000003FF
Table 29-8. ADC Input Channels(1)
Channel Input
CH0 AD0
CH1 AD1
CH2 AD2
CH4 AD4
CH5 AD5
CH6 AD6
CH7 AD7
CH8 AD8
CH9 Temperature sensor
746
32142D–06/2013
ATUC64/128/256L3/4U
30. Analog Comparator Interface (ACIFB)
Rev: 2.0.2.2
30.1 Features
• Controls an array of Analog Comparators
• Low power option
– Single shot mode support
• Selectable settings for filter option
– Filter length and hysteresis
• Window Mode
– Detect inside/outside window
– Detect above/below window
• Interrupt
– On comparator result rising edge, falling edge, toggle
– Inside window, outside window, toggle
– When startup time has passed
• Can generate events to the peripheral event system
30.2 Overview
The Analog Comparator Interface (ACIFB) is able to control a number of Analog Comparators
(AC) with identical behavior. An Analog Comparator compares two voltages and gives a compare
output depending on this comparison.
The ACIFB can be configured in normal mode using each comparator independently or in window
mode using defined comparator pairs to observe a window.
The number of channels implemented is device specific. Refer to the Module Configuration section
at the end of this chapter for details.
747
32142D–06/2013
ATUC64/128/256L3/4U
30.3 Block Diagram
Figure 30-1. ACIFB Block Diagram
30.4 I/O Lines Description
There are two groups of analog comparators, A and B, as shown in Table 30-1. In normal mode,
this grouping does not have any meaning. In window mode, two analog comparators, one from
group A and the corresponding comparator from group B, are paired.
……………...
TRIGGER
EVENTS
IRQ
GCLK
Peripheral Bus ACIFB
Analog
Comparators
PERIPHERAL
EVENT
GENERATION
-
+
AC
INN
INP
CONF0.INSELN
-
+
AC
INN
INP
CONFn.INSELN
FILTER
FILTER
INTERRUPT
GENERATION
CLK_ACIFB
CTRL.ACTEST
TR.ACTESTn
TR.ACTEST0
ACOUT0
ACOUTn
ACP0
ACN0
ACREFN
ACPn
ACNn
Table 30-1. Analog Comparator Groups for Window Mode
Group A Group B Pair Number
AC0 AC1 0
AC2 AC3 1
AC4 AC5 2
AC6 AC7 3
Table 30-2. I/O Line Description
Pin Name Pin Description Type
ACAPn Positive reference pin for Analog Comparator A n Analog
ACANn Negative reference pin for Analog Comparator A n Analog
748
32142D–06/2013
ATUC64/128/256L3/4U
The signal names corresponds to the groups A and B of analog comparators. For normal mode,
the mapping from input signal names in the block diagram to the signal names is given in Table
30-3.
30.5 Product Dependencies
In order to use this module, other parts of the system must be configured correctly, as described
below.
30.5.1 I/O Lines
The ACIFB pins are multiplexed with other peripherals. The user must first program the I/O Controller
to give control of the pins to the ACIFB.
30.5.2 Power Management
If the CPU enters a sleep mode that disables clocks used by the ACIFB, the ACIFB will stop
functioning and resume operation after the system wakes up from sleep mode.
30.5.3 Clocks
The clock for the ACIFB bus interface (CLK_ACIFB) is generated by the Power Manager. This
clock is enabled at reset, and can be disabled in the Power Manager. It is recommended to disable
the ACIFB before disabling the clock, to avoid freezing the ACIFB in an undefined state.
The ACIFB uses a GCLK as clock source for the Analog Comparators. The user must set up this
GCLK at the right frequency. The CLK_ACIFB clock of the interface must be at least 4x the
GCLK frequency used in the comparators. The GCLK is used both for measuring the startup
time of a comparator, and to give a frequency for the comparisons done in Continuous Measurement
Mode, see Section 30.6.
Refer to the Electrical Characteristics chapter for GCLK frequency limitations.
ACBPn Positive reference pin for Analog Comparator B n Analog
ACBNn Negative reference pin for Analog Comparator B n Analog
ACREFN Reference Voltage for all comparators selectable for INN Analog
Table 30-3. Signal Name Mapping
Pin Name Channel Number Normal Mode
ACAP0/ACAN0 0 ACP0/ACN0
ACBP0/ACBN0 1 ACP1/ACN1
ACAP1/ACAN1 2 ACP2/ACN2
ACBP1/ACBN1 3 ACP3/ACN3
ACAP2/ACAN2 4 ACP4/ACN4
ACBP2/ACBN2 5 ACP5/ACN5
ACAP3/ACAN3 6 ACP6/ACN6
ACBP3/ACBN3 7 ACP7/ACN7
Table 30-2. I/O Line Description
Pin Name Pin Description Type
749
32142D–06/2013
ATUC64/128/256L3/4U
30.5.4 Interrupts
The ACIFB interrupt request line is connected to the interrupt controller. Using the ACIFB interrupt
requires the interrupt controller to be programmed first.
30.5.5 Peripheral Events
The ACIFB peripheral events are connected via the Peripheral Event System. Refer to the
Peripheral Event System chapter for details.
30.5.6 Debug Operation
When an external debugger forces the CPU into debug mode, the ACIFB continues normal
operation. If the ACIFB is configured in a way that requires it to be periodically serviced by the
CPU through interrupts or similar, improper operation or data loss may result during debugging.
30.6 Functional Description
The ACIFB is enabled by writing a one to the Control Register Enable bit (CTRL.EN). Additionally,
the comparators must be individually enabled by programming the MODE field in the AC
Configuration Register (CONFn.MODE).
The results from the individual comparators can either be used directly (normal mode), or the
results from two comparators can be grouped to generate a comparison window (window mode).
All comparators need not be in the same mode, some comparators may be in normal mode,
while others are in window mode. There are restrictions on which AC channels that can be
grouped together in a window pair, see Section 30.6.5.
30.6.1 Analog Comparator Operation
Each AC channel can be in one of four different modes, determined by CONFn.MODE:
• Off
• Continuous Measurement Mode (CM)
• User Triggered Single Measurement Mode (UT)
• Event Triggered Single Measurement Mode (ET)
After being enabled, a startup time defined in CTRL.SUT is required before the result of the
comparison is ready. The GCLK is used for measuring the startup time of a comparator,
During the startup time the AC output is not available. When the ACn Ready bit in the Status
Register (SR.ACRDYn) is one, the output of ACn is ready. In window mode the result is available
when both the comparator outputs are ready (SR.ACRDYn=1 and SR.ACRDYn+1=1).
30.6.1.1 Continuous Measurement Mode
In CM, the Analog Comparator is continuously enabled and performing comparisons. This
ensures that the result of the latest comparison is always available in the ACn Current Comparison
Status bit in the Status Register (SR.ACCSn). Comparisons are done on every positive
edge of GCLK.
CM is enabled by writing CONFn.MODE to 1. After the startup time has passed, a comparison is
done and SR is updated. Appropriate peripheral events and interrupts are also generated. New
comparisons are performed continuously until the CONFn.MODE field is written to 0.
750
32142D–06/2013
ATUC64/128/256L3/4U
30.6.1.2 User Triggered Single Measurement Mode
In the UT mode, the user starts a single comparison by writing a one to the User Start Single
Comparison bit (CTRL.USTART). This mode is enabled by writing CONFn.MODE to 2. After the
startup time has passed, a single comparison is done and SR is updated. Appropriate peripheral
events and interrupts are also generated. No new comparisons will be performed.
CTRL.USTART is cleared automatically by hardware when the single comparison has been
done.
30.6.1.3 Event Triggered Single Measurement Mode
This mode is enabled by writing CONFn.MODE to 3 and Peripheral Event Trigger Enable
(CTRL.EVENTEN) to one. The ET mode is similar to the UT mode, the difference is that a
peripheral event from another hardware module causes the hardware to automatically set the
Peripheral Event Start Single Comparison bit (CTRL.ESTART). After the startup time has
passed, a single comparison is done and SR is updated. Appropriate peripheral events and
interrupts are also generated. No new comparisons will be performed. CTRL.ESTART is cleared
automatically by hardware when the single comparison has been done.
30.6.1.4 Selecting Comparator Inputs
Each Analog Comparator has one positive (INP) and one negative (INN) input. The positive
input is fed from an external input pin (ACPn). The negative input can either be fed from an
external input pin (ACNn) or from a reference voltage common to all ACs (ACREFN).
The user selects the input source as follows:
• In normal mode with the Negative Input Select and Positive Input Select fields
(CONFn.INSELN and CONFn.INSELP).
• In window mode with CONFn.INSELN, CONFn.INSELP and CONFn+1.INSELN,
CONFn+1,INSELP. The user must configure CONFn.INSELN and CONFn+1.INSELP to the
same source.
30.6.2 Interrupt Generation
The interrupt request will be generated if the corresponding bit in the Interrupt Mask Register
(IMR) is set. Bits in IMR are set by writing a one to the corresponding bit in the Interrupt Enable
Register (IER), and cleared by writing a one to the corresponding bit in the Interrupt Disable
Register (IDR). The interrupt request remains active until the corresponding bit in ISR is cleared
by writing a one to the corresponding bit in the Interrupt Status Clear Register (ICR).
30.6.3 Peripheral Event Generation
The ACIFB can be set up so that certain comparison results notify other parts of the device via
the Peripheral Event system. Refer to Section 30.6.4.3 and Section 30.6.5.3 for information on
which comparison results can generate events, and how to configure the ACIFB to achieve this.
Zero or one event will be generated per comparison.
30.6.4 Normal Mode
In normal mode all Analog Comparators are operating independently.
30.6.4.1 Normal Mode Output
Each Analog Comparator generates one output ACOUT according to the input voltages on INP
(AC positive input) and INN (AC negative input):
751
32142D–06/2013
ATUC64/128/256L3/4U
• ACOUT = 1 if VINP > VINN
• ACOUT = 0 if VINP < VINN
• ACOUT = 0 if the AC output is not available (SR.ACRDY = 0)
The output can optionally be filtered, as described in Section 30.6.6.
30.6.4.2 Normal Mode Interrupt
The AC channels can generate interrupts. The Interrupt Settings field in the Configuration Register
(CONFn.IS) can be configured to select when the AC will generate an interrupt:
• When VINP > VINN
• When VINP < VINN
• On toggle of the AC output (ACOUT)
• When comparison has been done
30.6.4.3 Normal Mode Peripheral Events
The ACIFB can generate peripheral events according to the configuration of CONFn.EVENN
and CONFn.EVENP.
• When VINP > VINN or
• When VINP < VINN or
• On toggle of the AC output (ACOUT)
30.6.5 Window Mode
In window mode, two ACs (an even and the following odd build up a pair) are grouped.
The negative input of ACn (even) and the positive input of ACn+1 (odd) has to be connected
together externally to the device and are controlled by the Input Select fields in the AC Configuration
Registers (CONFn.INSELN and CONFn+1.INSELP). The positive input of ACn (even) and
the negative input of ACn+1 (odd) can still be configured independently by CONFn.INSELP and
CONFn+1.INSELN, respectively.
752
32142D–06/2013
ATUC64/128/256L3/4U
Figure 30-2. Analog Comparator Interface in Window Mode
30.6.5.1 Window Mode Output
When operating in window mode, each channel generates the same ACOUT outputs as in normal
mode, see Section 30.6.4.1.
Additionally, the ACIFB generates a window mode signal (acwout) according to the common
input voltage to be compared:
• ACWOUT = 1 if the common input voltage is inside the window, VACN(N+1) < Vcommon < VACP(N)
• ACWOUT = 0 if the common input voltage is outside the window, Vcommon < VACN(N+1) or
Vcommon > VACP(N)
• ACWOUT = 0 if the window mode output is not available (SR.ACRDYn=0 or
SR.ACRDYn+1=0)
30.6.5.2 Window Mode Interrupts
When operating in window mode, each channel can generate the same interrupts as in normal
mode, see Section 30.6.4.2.
Additionally, when channels operate in window mode, programming Window Mode Interrupt Settings
in the Window Mode Configuration Register (CONFWn.WIS) can cause interrupts to be
generated when:
• As soon as the common input voltage is inside the window.
• As soon as the common input voltage is outside the window.
• On toggle of the window compare output (ACWOUT).
• When the comparison in both channels in the window pair is ready.
Comparator pair 0
-
+
AC0
Interrupt
Generator
Window
Module
ACOUT0
Peripheral Event
Generator
Window
window event
-
+
AC1
Filter
Filter
SR.ACCS0
SR.WFCS0
ACAP0
ACAN0
ACBP0
COMMON ACWOUT
ACBN0
IRQ
ACOUT1
753
32142D–06/2013
ATUC64/128/256L3/4U
30.6.5.3 Window Mode Peripheral Events
When operating in window mode, each channel can generate the same peripheral events as in
normal mode, see Section 30.6.4.3.
Additionally, when channels operate in window mode, programming Window Mode Event Selection
Source (CONFWn.WEVSRC) can cause peripheral events to be generated when:
• As soon as the common input voltage is inside the window.
• As soon as the common input voltage is outside the window.
• On toggle of the window compare output (ACWOUT)
• Whenever a comparison is ready and the common input voltage is inside the window.
• Whenever a comparison is ready and the common input voltage is outside the window.
• When the comparison in both channels in the window pair is ready.
30.6.6 Filtering
The output of the comparator can be filtered to reduce noise. The filter length is determined by
the Filter Length field in the CONFn register (CONFn.FLEN). The filter samples the Analog
Comparator output at the GCLK frequency for 2CONFn.FLEN samples. A separate counter (CNT)
counts the number of cycles the AC output was one. This filter is deactivated if CONFn.FLEN
equals 0.
If the filter is enabled, the Hysteresis Value field HYS in the CONFn register (CONFn.HYS) can
be used to define a hysteresis value. The hysteresis value should be chosen so that:
The filter function is defined by:
The filtering algorithm is explained in Figure 30-3. 2FLEN measurements are sampled. If the number
of measurements that are zero is less than (2FLEN/2 - HYS), the filtered result is zero. If the
number of measurements that are one is more than (2FLEN/2 + HYS), the filtered result is one.
Otherwise, the result is unchanged.
2FLEN
2 ---------------- HYS
CNT 2FLEN
2 ---------------- + HYS comp = 1
2FLEN
2 ---------------- + HYS CNT 2FLEN
2 ----------------–HYS comp unchanged
CNT 2FLEN
2 ----------------–HYS comp = 0
754
32142D–06/2013
ATUC64/128/256L3/4U
Figure 30-3. The Filtering Algorithm
30.7 Peripheral Event Triggers
Peripheral events from other modules can trigger comparisons in the ACIFB. All channels that
are set up in Event Triggered Single Measurement Mode will be started simultaneously when a
peripheral event is received. Channels that are operating in Continuous Measurement Mode or
User Triggered Single Measurement Mode will be unaffected by the received event. The software
can still operate these channels independently of channels in Event Triggered Single
Measurement Mode.
A peripheral event will trigger one or more comparisons, in normal or window mode.
30.8 AC Test mode
By writing the Analog Comparator Test Mode (CR.ACTEST) bit to one, the outputs from the ACs
are overridden by the value in the Test Register (TR), see Figure 30-1. This is useful for software
development.
2
FLEN
2
FLEN
2
HYS HYS
”Result=0" ”Result=1"
Result =
UNCHANGED
0
755
32142D–06/2013
ATUC64/128/256L3/4U
30.9 User Interface
Note: 1. The reset values for these registers are device specific. Please refer to the Module Configuration section at the end of this
chapter.
Table 30-4. ACIFB Register Memory Map
Offset Register Register Name Access Reset
0x00 Control Register CTRL Read/Write 0x00000000
0x04 Status Register SR Read-only 0x00000000
0x10 Interrupt Enable Register IER Write-only 0x00000000
0x14 Interrupt Disable Register IDR Write-only 0x00000000
0x18 Interrupt Mask Register IMR Read-only 0x00000000
0x1C Interrupt Status Register ISR Read-only 0x00000000
0x20 Interrupt Status Clear Register ICR Write-only 0x00000000
0x24 Test Register TR Read/Write 0x00000000
0x30 Parameter Register PARAMETER Read-only -(1)
0x34 Version Register VERSION Read-only -(1)
0x80 Window0 Configuration Register CONFW0 Read/Write 0x00000000
0x84 Window1 Configuration Register CONFW1 Read/Write 0x00000000
0x88 Window2 Configuration Register CONFW2 Read/Write 0x00000000
0x8C Window3 Configuration Register CONFW3 Read/Write 0x00000000
0xD0 AC0 Configuration Register CONF0 Read/Write 0x00000000
0xD4 AC1 Configuration Register CONF1 Read/Write 0x00000000
0xD8 AC2 Configuration Register CONF2 Read/Write 0x00000000
0xDC AC3 Configuration Register CONF3 Read/Write 0x00000000
0xE0 AC4 Configuration Register CONF4 Read/Write 0x00000000
0xE4 AC5 Configuration Register CONF5 Read/Write 0x00000000
0xE8 AC6 Configuration Register CONF6 Read/Write 0x00000000
0xEC AC7 Configuration Register CONF7 Read/Write 0x00000000
756
32142D–06/2013
ATUC64/128/256L3/4U
30.9.1 Control Register
Name: CTRL
Access Type: Read/Write
Offset: 0x00
Reset Value: 0x00000000
• SUT: Startup Time
Analog Comparator startup time = .
Each time an AC is enabled, the AC comparison will be enabled after the startup time of the AC.
• ACTEST: Analog Comparator Test Mode
0: The Analog Comparator outputs feeds the channel logic in ACIFB.
1: The Analog Comparator outputs are bypassed with the AC Test Register.
• ESTART: Peripheral Event Start Single Comparison
Writing a zero to this bit has no effect.
Writing a one to this bit starts a comparison and can be used for test purposes.
This bit is cleared when comparison is done.
This bit is set when an enabled peripheral event is received.
• USTART: User Start Single Comparison
Writing a zero to this bit has no effect.
Writing a one to this bit starts a Single Measurement Mode comparison.
This bit is cleared when comparison is done.
• EVENTEN: Peripheral Event Trigger Enable
0: A peripheral event will not trigger a comparison.
1: Enable comparison triggered by a peripheral event.
• EN: ACIFB Enable
0: The ACIFB is disabled.
1: The ACIFB is enabled.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
- - - - - - SUT[9:8]
15 14 13 12 11 10 9 8
SUT[7:0]
76543210
ACTEST - ESTART USTART - - -EVENTEN EN
SUT
FGCLK
----------------
757
32142D–06/2013
ATUC64/128/256L3/4U
30.9.2 Status Register
Name: SR
Access Type: Read-only
Offset: 0x04
Reset Value: 0x00000000
• WFCSn: Window Mode Current Status
This bit is cleared when the common input voltage is outside the window.
This bit is set when the common input voltage is inside the window.
• ACRDYn: ACn Ready
This bit is cleared when the AC output (ACOUT) is not ready.
This bit is set when the AC output (ACOUT) is ready, AC is enabled and its startup time is over.
• ACCSn: ACn Current Comparison Status
This bit is cleared when VINP is currently lower than VINN
This bit is set when VINP is currently greater than VINN.
31 30 29 28 27 26 25 24
- - - - WFCS3 WFCS2 WFCS1 WFCS0
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
ACRDY7 ACCS7 ACRDY6 ACCS6 ACRDY5 ACCS5 ACRDY4 ACCS4
76543210
ACRDY3 ACCS3 ACRDY2 ACCS2 ACRDY1 ACCS1 ACRDY0 ACCS0
758
32142D–06/2013
ATUC64/128/256L3/4U
30.9.3 Interrupt Enable Register
Name: IER
Access Type: Write-only
Offset: 0x10
Reset Value: 0x00000000
Writing a zero to a bit in this register has no effect.
Writing a one to a bit in this register will set the corresponding bit in IMR.
31 30 29 28 27 26 25 24
- - - - WFINT3 WFINT2 WFINT1 WFINT0
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
SUTINT7 ACINT7 SUTINT6 ACINT6 SUTINT5 ACINT5 SUTINT4 ACINT4
76543210
SUTINT3 ACINT3 SUTINT2 ACINT2 SUTINT1 ACINT1 SUTINT0 ACINT0
759
32142D–06/2013
ATUC64/128/256L3/4U
30.9.4 Interrupt Disable Register
Name: IDR
Access Type: Write-only
Offset: 0x14
Reset Value: 0x00000000
Writing a zero to a bit in this register has no effect.
Writing a one to a bit in this register will clear the corresponding bit in IMR.
31 30 29 28 27 26 25 24
- - - - WFINT3 WFINT2 WFINT1 WFINT0
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
SUTINT7 ACINT7 SUTINT6 ACINT6 SUTINT5 ACINT5 SUTINT4 ACINT4
76543210
SUTINT3 ACINT3 SUTINT2 ACINT2 SUTINT1 ACINT1 SUTINT0 ACINT0
760
32142D–06/2013
ATUC64/128/256L3/4U
30.9.5 Interrupt Mask Register
Name: IMR
Access Type: Read-only
Offset: 0x18
Reset Value: 0x00000000
• WFINTn: Window Mode Interrupt Mask
0: The corresponding interrupt is disabled.
1: The corresponding interrupt is enabled.
This bit is cleared when the corresponding bit in IDR is written to one.
This bit is set when the corresponding bit in IER is written to one.
• SUTINTn: ACn Startup Time Interrupt Mask
0: The corresponding interrupt is disabled.
1: The corresponding interrupt is enabled.
This bit is cleared when the corresponding bit in IDR is written to one.
This bit is set when the corresponding bit in IER is written to one.
• ACINTn: ACn Interrupt Mask
0: The corresponding interrupt is disabled.
1: The corresponding interrupt is enabled.
This bit is cleared when the corresponding bit in IDR is written to one.
This bit is set when the corresponding bit in IER is written to one.
31 30 29 28 27 26 25 24
- - - - WFINT3 WFINT2 WFINT1 WFINT0
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
SUTINT7 ACINT7 SUTINT6 ACINT6 SUTINT5 ACINT5 SUTINT4 ACINT4
76543210
SUTINT3 ACINT3 SUTINT2 ACINT2 SUTINT1 ACINT1 SUTINT0 ACINT0
761
32142D–06/2013
ATUC64/128/256L3/4U
30.9.6 Interrupt Status Register
Name: ISR
Access Type: Read-only
Offset: 0x1C
Reset Value: 0x00000000
• WFINTn: Window Mode Interrupt Status
0: No Window Mode Interrupt is pending.
1: Window Mode Interrupt is pending.
This bit is cleared when the corresponding bit in ICR is written to one.
This bit is set when the corresponding channel pair operating in window mode generated an interrupt.
• SUTINTn: ACn Startup Time Interrupt Status
0: No Startup Time Interrupt is pending.
1: Startup Time Interrupt is pending.
This bit is cleared when the corresponding bit in ICR is written to one.
This bit is set when the startup time of the corresponding AC has passed.
• ACINTn: ACn Interrupt Status
0: No Normal Mode Interrupt is pending.
1: Normal Mode Interrupt is pending.
This bit is cleared when the corresponding bit in ICR is written to one.
This bit is set when the corresponding channel generated an interrupt.
31 30 29 28 27 26 25 24
- - - - WFINT3 WFINT2 WFINT1 WFINT0
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
SUTINT7 ACINT7 SUTINT6 ACINT6 SUTINT5 ACINT5 SUTINT4 ACINT4
76543210
SUTINT3 ACINT3 SUTINT2 ACINT2 SUTINT1 ACINT1 SUTINT0 ACINT0
762
32142D–06/2013
ATUC64/128/256L3/4U
30.9.7 Interrupt Status Clear Register
Name: ICR
Access Type: Write-only
Offset: 0x20
Reset Value: 0x00000000
Writing a zero to a bit in this register has no effect.
Writing a one to a bit in this register will clear the corresponding bit in ISR and the corresponding interrupt request.
31 30 29 28 27 26 25 24
- - - - WFINT3 WFINT2 WFINT1 WFINT0
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
SUTINT7 ACINT7 SUTINT6 ACINT6 SUTINT5 ACINT5 SUTINT4 ACINT4
76543210
SUTINT3 ACINT3 SUTINT2 ACINT2 SUTINT1 ACINT1 SUTINT0 ACINT0
763
32142D–06/2013
ATUC64/128/256L3/4U
30.9.8 Test Register
Name: TR
Access Type: Read/Write
Offset: 0x24
Reset Value: 0x00000000
• ACTESTn: AC Output Override Value
If CTRL.ACTEST is set, the ACn output is overridden with the value of ACTESTn.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
ACTEST7 ACTEST6 ACTEST5 ACTEST4 ACTEST3 ACTEST2 ACTEST1 ACTEST0
764
32142D–06/2013
ATUC64/128/256L3/4U
30.9.9 Parameter Register
Name: PARAMETER
Access Type: Read-only
Offset: 0x30
Reset Value: -
• WIMPLn: Window Pair n Implemented
0: Window Pair not implemented.
1: Window Pair implemented.
• ACIMPLn: Analog Comparator n Implemented
0: Analog Comparator not implemented.
1: Analog Comparator implemented.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
- - - - WIMPL3 WIMPL2 WIMPL1 WIMPL0
15 14 13 12 11 10 9 8
--------
76543210
ACIMPL7 ACIMPL6 ACIMPL5 ACIMPL4 ACIMPL3 ACIMPL2 ACIMPL1 ACIMPL0
765
32142D–06/2013
ATUC64/128/256L3/4U
30.9.10 Version Register
Name: VERSION
Access Type: Read-only
Offset: 0x34
Reset Value: -
• VARIANT: Variant Number
Reserved. No functionality associated.
• VERSION: Version Number
Version number of the module. No functionality associated.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
- - - - VARIANT
15 14 13 12 11 10 9 8
- - - - VERSION[11:8]
76543210
VERSION[7:0]
766
32142D–06/2013
ATUC64/128/256L3/4U
30.9.11 Window Configuration Register
Name: CONFWn
Access Type: Read/Write
Offset: 0x80,0x84,0x88,0x8C
Reset Value: 0x00000000
• WFEN: Window Mode Enable
0: The window mode is disabled.
1: The window mode is enabled.
• WEVEN: Window Event Enable
0: Event from awout is disabled.
1: Event from awout is enabled.
• WEVSRC: Event Source Selection for Window Mode
000: Event on acwout rising edge.
001: Event on acwout falling edge.
010: Event on awout rising or falling edge.
011: Inside window.
100: Outside window.
101: Measure done.
110-111: Reserved.
• WIS: Window Mode Interrupt Settings
00: Window interrupt as soon as the input voltage is inside the window.
01: Window interrupt as soon as the input voltage is outside the window.
10: Window interrupt on toggle of window compare output.
11: Window interrupt when evaluation of input voltage is done.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
- - - - - - - WFEN
15 14 13 12 11 10 9 8
- - - - WEVEN WEVSRC
7654321 0
- - - - - - WIS
767
32142D–06/2013
ATUC64/128/256L3/4U
30.9.12 AC Configuration Register
Name: CONFn
Access Type: Read/Write
Offset: 0xD0,0xD4,0xD8,0xDC,0xE0,0xE4,0xE8,0xEC
Reset Value: 0x00000000
• FLEN: Filter Length
000: Filter off.
n: Number of samples to be averaged =2n
.
• HYS: Hysteresis Value
0000: No hysteresis.
1111: Max hysteresis.
• EVENN: Event Enable Negative
0: Do not output event when ACOUT is zero.
1: Output event when ACOUT is zero.
• EVENP: Event Enable Positive
0: Do not output event when ACOUT is one.
1: Output event when ACOUT is one.
• INSELP: Positive Input Select
00: ACPn pin selected.
01: Reserved.
10: Reserved.
11: Reserved.
• INSELN: Negative Input Select
00: ACNn pin selected.
01: ACREFN pin selected.
10: Reserved.
11: Reserved.
• MODE: Mode
00: Off.
01: Continuous Measurement Mode.
10: User Triggered Single Measurement Mode.
11: Event Triggered Single Measurement Mode.
31 30 29 28 27 26 25 24
- FLEN HYS
23 22 21 20 19 18 17 16
- - - - - - EVENP EVENN
15 14 13 12 11 10 9 8
- - - - INSELP INSELN
7654321 0
- - MODE - - IS
768
32142D–06/2013
ATUC64/128/256L3/4U
• IS: Interrupt Settings
00: Comparator interrupt when as VINP > VINN.
01: Comparator interrupt when as VINP < VINN.
10: Comparator interrupt on toggle of Analog Comparator output.
11: Comparator interrupt when comparison of VINP and VINN is done.
769
32142D–06/2013
ATUC64/128/256L3/4U
30.10 Module Configuration
The specific configuration for each ACIFB instance is listed in the following tables.The module
bus clocks listed here are connected to the system bus clocks. Refer to the Power Manager
chapter for details.
Table 30-5. ACIFB Configuration
Feature ACIFB
Number of channels 8
Table 30-6. ACIFB Clocks
Clock Name Description
CLK_ACIFB Clock for the ACIFB bus interface
GCLK The generic clock used for the ACIFB is GCLK4
Table 30-7. Register Reset Values
Register Reset Value
VERSION 0x00000202
PARAMETER 0x000F00FF
770
32142D–06/2013
ATUC64/128/256L3/4U
31. Capacitive Touch Module (CAT)
Rev: 4.0.0.0
31.1 Features
• QTouch® method allows N touch sensors to be implemented using 2N physical pins
• QMatrix method allows X by Y matrix of sensors to be implemented using (X+2Y) physical pins
• One autonomous QTouch sensor operates without DMA or CPU intervention
• All QTouch sensors can operate in DMA-driven mode without CPU intervention
• External synchronization to reduce 50 or 60 Hz mains interference
• Spread spectrum sensor drive capability
31.2 Overview
The Capacitive Touch Module (CAT) senses touch on external capacitive touch sensors. Capacitive
touch sensors use no external mechanical components, and therefore demand less
maintenance in the user application.
The module implements the QTouch method of capturing signals from capacitive touch sensors.
The QTouch method is generally suitable for small numbers of sensors since it requires 2 physical
pins per sensor. The module also implements the QMatrix method, which is more
appropriate for large numbers of sensors since it allows an X by Y matrix of sensors to be implemented
using only (X+2Y) physical pins. The module allows methods to function together, so N
touch sensors and an X by Y matrix of sensors can be implemented using (2N+X+2Y) physical
pins.
In addition, the module allows sensors using the QTouch method to be divided into two groups.
Each QTouch group can be configured with different properties. This eases the implementation
of multiple kinds of controls such as push buttons, wheels, and sliders.
All of the QTouch sensors can operate in a DMA-driven mode, known as DMATouch, that allows
detection of touch without CPU intervention. The module also implements one autonomous
QTouch sensor that is capable of detecting touch without DMA or CPU intervention. This allows
proximity or activation detection in low-power sleep modes.
771
32142D–06/2013
ATUC64/128/256L3/4U
31.3 Block Diagram
Figure 31-1. CAT Block Diagram
31.4 I/O Lines Description
Interface
Registers Peripheral Bus
Finite State
Machine Capacitor
Charge and
Discharge
Sequence
Generator
Counters
CSAn
SMP
I/O
Controller Pins
Discharge
Current
Sources
DIS
Yn
Analog
Comparators
Peripheral
Event System
CLK_CAT
Analog
Comparator
Interface
SYNC
Capacitive Touch Module (CAT)
CSBn
GCLK_CAT VDIVEN
NOTE:
Italicized
signals and
blocks are
used only for
QMatrix
operation
Table 31-1. I/O Lines Description
Name Description Type
CSAn Capacitive sense A line n I/O
CSBn Capacitive sense B line n I/O
DIS Discharge current control (only used for QMatrix) Analog
772
32142D–06/2013
ATUC64/128/256L3/4U
31.5 Product Dependencies
In order to use the CAT module, other parts of the system must be configured correctly, as
described below.
31.5.1 I/O Lines
The CAT pins may be multiplexed with other peripherals. The user must first program the I/O
Controller to give control of the pins to the CAT module. In QMatrix mode, the Y lines must be
driven by the CAT and analog comparators sense the voltage on the Y lines. Thus, the CAT (not
the Analog Comparator Interface) must be the selected function for the Y lines in the I/O
Controller.
By writing ones and zeros to bits in the Pin Mode Registers (PINMODEx), most of the CAT pins
can be individually selected to implement the QTouch method or the QMatrix method. Each pin
has a different name and function depending on whether it is implementing the QTouch method
or the QMatrix method. The following table shows the pin names for each method and the bits in
the PINMODEx registers which control the selection of the QTouch or QMatrix method.
SMP SMP line (only used for QMatrix) Output
SYNC Synchronize signal Input
VDIVEN Voltage divider enable (only used for QMatrix) Output
Table 31-1. I/O Lines Description
Name Description Type
Table 31-2. Pin Selection Guide
CAT Module Pin
Name
QTouch Method
Pin Name
QMatrix Method Pin
Name
Selection Bit in
PINMODEx Register
CSA0 SNS0 X0 SP0
CSB0 SNSK0 X1 SP0
CSA1 SNS1 Y0 SP1
CSB1 SNSK1 YK0 SP1
CSA2 SNS2 X2 SP2
CSB2 SNSK2 X3 SP2
CSA3 SNS3 Y1 SP3
CSB3 SNSK3 YK1 SP3
CSA4 SNS4 X4 SP4
CSB4 SNSK4 X5 SP4
CSA5 SNS5 Y2 SP5
CSB5 SNSK5 YK2 SP5
CSA6 SNS6 X6 SP6
CSB6 SNSK6 X7 SP6
CSA7 SNS7 Y3 SP7
CSB7 SNSK7 YK3 SP7
CSA8 SNS8 X8 SP8
773
32142D–06/2013
ATUC64/128/256L3/4U
31.5.2 Clocks
The clock for the CAT module, CLK_CAT, is generated by the Power Manager (PM). This clock
is turned on by default, and can be enabled and disabled in the PM. The user must ensure that
CLK_CAT is enabled before using the CAT module.
QMatrix operations also require the CAT generic clock, GCLK_CAT. This generic clock is generated
by the System Control Interface (SCIF), and is shared between the CAT and the Analog
Comparator Interface. The user must ensure that the GCLK_CAT is enabled in the SCIF before
using QMatrix functionality in the CAT module. For proper QMatrix operation, the frequency of
GCLK_CAT must be less than half the frequency of CLK_CAT. If only QTouch functionality is
used, then GCLK_CAT is unnecessary.
31.5.3 Interrupts
The CAT interrupt request line is connected to the interrupt controller. Using CAT interrupts
requires the interrupt controller to be programmed first.
31.5.4 Peripheral Events
The CAT peripheral events are connected via the Peripheral Event System. Refer to the Peripheral
Event System chapter for details.
31.5.5 Peripheral Direct Memory Access
The CAT module provides handshake capability for a Peripheral DMA Controller. One handshake
controls transfers from the Acquired Count Register (ACOUNT) to memory. A second
handshake requests burst lengths for each (X,Y) pair to the Matrix Burst Length Register
CSB8 SNSK8 X9 SP8
CSA9 SNS9 Y4 SP9
CSB9 SNSK9 YK4 SP9
CSA10 SNS10 X10 SP10
CSB10 SNSK10 X11 SP10
CSA11 SNS11 Y5 SP11
CSB11 SNSK11 YK5 SP11
CSA12 SNS12 X12 SP12
CSB12 SNSK12 X13 SP12
CSA13 SNS13 Y6 SP13
CSB13 SNSK13 YK6 SP13
CSA14 SNS14 X14 SP14
CSB14 SNSK14 X15 SP14
CSA15 SNS15 Y7 SP15
CSB15 SNSK15 YK7 SP15
CSA16 SNS16 X16 SP16
CSB16 SNSK16 X17 SP16
Table 31-2. Pin Selection Guide
CAT Module Pin
Name
QTouch Method
Pin Name
QMatrix Method Pin
Name
Selection Bit in
PINMODEx Register
774
32142D–06/2013
ATUC64/128/256L3/4U
(MBLEN) when using the QMatrix acquisition method. Two additional handshakes support DMATouch
by regulating transfers from memory to the DMATouch State Write Register (DMATSW)
and from the DMATouch State Read Register (DMATSR) to memory. The Peripheral DMA Controller
must be configured properly and enabled in order to perform direct memory access
transfers to/from the CAT module.
31.5.6 Analog Comparators
When the CAT module is performing QMatrix acquisition, it requires that on-chip analog comparators
be used as part of the process. These analog comparators are not controlled directly by
the CAT module, but by a separate Analog Comparator (AC) Interface. This interface must be
configured properly and enabled before the CAT module is used. This includes configuring the
generic clock input for the analog comparators to the proper sampling frequency.
The CAT will automatically use the negative peripheral events from the AC Interface on every Y
pin in QMatrix mode. When QMatrix acquisition is used the analog comparator corresponding to
the selected Y pins must be enabled and converting continuously, using the Y pin as the positive
reference and the ACREFN as negative reference.
31.5.7 Debug Operation
When an external debugger forces the CPU into debug mode, the CAT continues normal operation.
If the CAT is configured in a way that requires it to be periodically serviced by the CPU
through interrupts or similar, improper operation or data loss may result during debugging.
31.6 Functional Description
31.6.1 Acquisition Types
The CAT module can perform several types of QTouch acquisition from capacitive touch sensors:
autonomous QTouch (one sensor only), DMATouch, QTouch group A, and QTouch group
B. The CAT module can also perform QMatrix acquisition. Each type of acquisition has an associated
set of pin selection and configuration registers that allow a large degree of flexibility.
The following schematic diagrams show typical hardware connections for QTouch and QMatrix
sensors, respectively:
Figure 31-2. CAT Touch Connections
AVR32 Chip
QTouch
Sensor
Cs (Sense Capacitor)
SNSKn
SNSn
775
32142D–06/2013
ATUC64/128/256L3/4U
Figure 31-3. CAT Matrix Connections
In order to use the autonomous QTouch detection capability, the user must first set up the
Autonomous Touch Pin Select Register (ATPINS) and Autonomous/DMA Touch Configuration
Registers (ATCFG0 through 3) with appropriate values. The module can then be enabled using
the Control Register (CTRL). After the module is enabled, the module will acquire data from the
autonomous QTouch sensor and use it to determine whether the sensor is activated. The
active/inactive status of the autonomous QTouch sensor is reported in the Status Register (SR),
and it is also possible to configure the CAT to generate an interrupt whenever the status
changes. The module will continue acquiring autonomous QTouch sensor data and updating
autonomous QTouch status until the module is disabled or reset.
In order to use the DMATouch capability, it is first necessary to set up the pin mode registers
(PINMODE0, PINMODE1, and PINMODE2) so that the desired pins are specified as DMATouch.
The Autonomous/DMA Touch Configuration Registers (ATCFG0 through 3) must also be
configured with appropriate values. One channel of the Peripheral DMA Controller must be set
up to transfer state words from a block of memory to the DMATSW register, and another channel
must be set up to transfer state words from the DMATSR register back to the same block of
memory. The module can then be enabled using the CTRL register. After the module is enabled,
the module will acquire count values from each DMATouch sensor. Once the module has
acquired a count value for a sensor, it will use a handshake interface to signal the Peripheral
DMA controller to transfer a state word to the DMATSW register. The module will use the count
value to update the state word, and then the updated state word will be transferred to the
DMATSR register. Another handshake interface will signal the Peripheral DMA controller to
transfer the contents of the DMATSR register back to memory. The status of the DMATouch
sensors can be determined at any time by reading the DMATouch Sensor Status Register
(DMATSS).
AVR32 Chip
Cs0 (Sense Capacitor)
X3
YK0
X6 QMatrix Sensor Array
X7
X2
Y0
YK1
Y1 Cs1 (Sense Capacitor)
SMP
Rsmp1 Rsmp0
VDIVEN
DIS
Rdis
ACREFN
Ra
Rb
NOTE: If the CAT internal
current sources will be enabled,
the SMP signal and Rsmp
resistors should NOT be included
in the design. If the CAT internal
current sources will NOT be
enabled, the DIS signal and Rdis
resistor should NOT be included
in the design.
776
32142D–06/2013
ATUC64/128/256L3/4U
In order to use the QMatrix, QTouch group A, or QTouch group B acquisition capabilities, it is
first necessary to set up the pin mode registers (PINMODE0, PINMODE1, and PINMODE2) and
configuration registers (MGCFG0, MGCFG1, TGACFG0, TGACFG1, TGBCFG0, and
TGBCFG1). The module must then be enabled using the CTRL register. In order to initiate
acquisition, it is necessary to perform a write to the Acquisition Initiation and Selection Register
(AISR). The specific value written to AISR determines which type of acquisition will be performed:
QMatrix, QTouch group A, or QTouch group B. The CPU can initiate acquisition by
writing to the AISR.
While QMatrix, QTouch group A, or QTouch group B acquisition is in progress, the module collects
count values from the sensors and buffers them. Availability of acquired count data is
indicated by the Acquisition Ready (ACREADY) bit in the Status Register (SR). The CPU or the
Peripheral DMA Controller can then read the acquired counts from the ACOUNT register.
Because the CAT module is configured with Peripheral DMA Controller capability that can transfer
data from memory to MBLEN and from ACOUNT to memory, the Peripheral DMA Controller
can perform long acquisition sequences and store results in memory without CPU intervention.
31.6.2 Prescaler and Charge Length
Each QTouch acquisition type (autonomous QTouch, QTouch group A, and QTouch group B)
has its own prescaler. Each QTouch prescaler divides down the CLK_CAT clock to an appropriate
sampling frequency for its particular acquisition type. Typical frequencies are 1MHz for
QTouch acquisition and 4MHz for QMatrix burst timing control.
Each QTouch prescaler is controlled by the DIV field in the appropriate Configuration Register 0
(ATCFG0, TGACFG0, or TGBCFG0). The QMatrix burst timing prescaler is controlled by the
DIV field in MGCFG0. Each prescaler uses the following formula to generate the sampling clock:
Sampling clock = CLK_CAT / (2(DIV+1))
The capacitive sensor charge length, discharge length, and settle length can be determined for
each acquisition type using the CHLEN, DILEN, and SELEN fields in Configuration Registers 0
and 1. The lengths are specified in terms of prescaler clocks. In addition, the QMatrix Cx discharge
length can be determined using the CXDILEN field in MGCFG2.
For QMatrix acquisition, the duration of CHLEN should not be set to the same value as the
period of any periodic signal on any other pin. If the duration of CHLEN is the same as the
period of a signal on another pin, it is likely that the other signal will significantly affect measurements
due to stray capacitive coupling. For example, if a 1 MHz signal is generated on another
pin of the chip, then CHLEN should not be 1 microsecond.
For the QMatrix method, burst and capture lengths are set for each (X,Y) pair by writing the
desired length values to the MBLEN register. The write must be done before each X line can
start its acquisition and is indicated by the status bit MBLREQ in the Status Register (SR). A
DMA handshake interface is also connected to this status bit to reduce CPU overhead during
QMatrix acquisitions.
Four burst lengths (BURST0..3) can be written at one time into the MBLEN register. If the current
configuration uses Y lines larger than Y3 the register has to be written a second time. The
first write to MBLEN specifies the burst length for Y lines 0 to 3 in the BURST0 to BURST3 fields,
respectively. The second write specifies the burst length for Y lines 4 to 7 in fields BURST0 to
BURST3, respectively, and so on.
777
32142D–06/2013
ATUC64/128/256L3/4U
The Y and YK pins remain clamped to ground apart from the specified number of burst pulses,
when charge is transferred and captured into the sampling capacitor.
31.6.3 Capacitive Count Acquisition
For the QMatrix, QTouch group A, and QTouch group B types of acquisition, the module
acquires count values from the sensors, buffers them, and makes them available for reading in
the ACOUNT register. Further processing of the count values must be performed by the CPU.
When the module performs QMatrix acquisition using multiple Y lines, it starts the capture for
each Y line at the appropriate time in the burst sequence so that all captures finish simultaneously.
For example, suppose that an acquisition is performed on Y0 and Y1 with BURST0=53
and BURST1=60. The module will first toggle the X line 7 times while capturing on Y1 while Y0
and YK0 are clamped to ground. The module will then toggle the X line 53 times while capturing
on both Y1 and Y0.
31.6.4 Autonomous QTouch and DMATouch
For autonomous QTouch and DMATouch, a complete detection algorithm is implemented within
the CAT module. The additional parameters needed to control the detection algorithm must be
specified by the user in the ATCFG2 and ATCFG3 registers.
Autonomous QTouch and DMATouch sensitivity and out-of-touch sensitivity can be adjusted
with the SENSE and OUTSENS fields, respectively, in ATCFG2. Each field accepts values from
one to 255 where 255 is the least sensitive setting. The value in the OUTSENS field should be
smaller than the value in the SENSE field.
To avoid false positives a detect integration filtering technique can be used. The number of successive
detects required is specified in the FILTER field of the ATCFG2 register.
To compensate for changes in capacitance the CAT can recalibrate the autonomous QTouch
sensor periodically. The timing of this calibration is done with the NDRIFT and PDRIFT fields in
the Configuration register, ATCFG3. It is recommended that the PDRIFT value is smaller than
the NDRIFT value.
The autonomous QTouch sensor and DMATouch sensors will also recalibrate if the count value
goes too far positive beyond a threshold. This positive recalibration threshold is specified by the
PTHR field in the ATCFG3 register.
The following block diagram shows the sequence of acquisition and processing operations used
by the CAT module. The AISR written bit is internal and not visible in the user interface.
778
32142D–06/2013
ATUC64/128/256L3/4U
Figure 31-4. CAT Acquisition and Processing Sequence
31.6.5 Spread Spectrum Sensor Drive
To reduce electromagnetic compatibility issues, the capacitive sensors can be driven with a
spread spectrum signal. To enable spread spectrum drive for a specific acquisition type, the
user must write a one to the SPREAD bit in the appropriate Configuration Register 1 (MGCFG1,
ATCFG1, TGACFG1, or TGBCFG1).
During spread spectrum operation, the length of each pulse within a burst is varied in a deterministic
pattern, so that the exact same burst pattern is used for a specific burst length. The
maximum spread is determined by the MAXDEV field in the Spread Spectrum Configuration
Register (SSCFG) register. The prescaler divisor is varied in a sawtooth pattern from
(2(DIV+1))-MAXDEV to (2(DIV+1))+MAXDEV and then back to (2(DIV+1))-MAXDEV. For example,
if DIV is 2 and MAXDEV is 3, the prescaler divisor will have the following sequence: 6, 7, 8,
Idle
Acquire
autonomous
touch count
Acquire counts
Update
autonomous
touch detection
algorithm
Wait for all
acquired counts
to be transferred
AISR written flag set?
No Yes
Clear AISR
written flag
No Yes
Autonomous touch
enabled (ATEN)?
779
32142D–06/2013
ATUC64/128/256L3/4U
9, 3, 4, 5, 6, 7, 8, 9, 3, 4, etc. MAXDEV must not exceed the value of (2(DIV+1)), or undefined
behavior will occur.
31.6.6 Synchronization
To prevent interference from the 50 or 60 Hz mains line the CAT can trigger acquisition on the
SYNC signal. The SYNC signal should be derived from the mains line. The acquisition will trigger
on a falling edge of this signal. To enable synchronization for a specific acquisition type, the
user must write a one to the SYNC bit in the appropriate Configuration Register 1 (MGCFG1,
ATCFG1, TGACFG1, or TGBCFG1).
For QMatrix acquisition, all X lines must be sampled at a specific phase of the noise signal for
the synchronization to be effective. This can be accomplished by the synchronization timer,
which is enabled by writing a non-zero value to the SYNCTIM field in the MGCFG2 register. This
ensures that the start of the acquisition of each X line is spaced at regular intervals, defined by
the SYNCTIM field.
31.6.7 Resistive Drive
By default, the CAT pins are driven with normal I/O drive properties. Some of the CSA and CSB
pins can optionally drive with a 1k output resistance for improved EMC. The pins that have this
capability are listed in the Module Configuration section.
31.6.8 Discharge Current Sources
The device integrates discharge current sources, which can be used to discharge the sampling
capacitors during the QMatrix measurement phase. The discharge current sources are enabled
by writing the GLEN bit in the Discharge Current Source (DICS) register to one. This enables an
internal reference voltage, which can be either the internal 1.1V band gap voltage or VDDIO/3,
as selected by the INTVREFSEL bit in the DICS register. If the DICS.INTREFSEL bit is one, the
reference voltage is applied across an internal resistor, Rint. Otherwise, the voltage is applied to
the DIS pin, and an external reference resistor must be connected between DIS and ground.
The nominal discharge current is given by the following formula, where Vref is the reference voltage,
Rref is the value of the reference resistor, trim is the value written to the DICS.TRIM field,
and k is a constant of proportionality:
I = (Vref/Rref)*(1+(k*trim))
The values for the internal reference resistor, Rint, and the constant, k, may be found in the Electrical
Characteristics section. The nominal discharge current may be programmed between 2
and 20 µA. The reference current can be fine-tuned by adjusting the trim value in the DICS.TRIM
field.
The reference current is mirrored to each Y-pin if the corresponding bit is written to one in the
DICS.SOURCES field.
31.6.9 Voltage Divider Enable (VDIVEN) Capability
In many QMatrix applications, the sense capacitors will be charged to 50 mV or more and the
negative reference pin (ACREFN) of the analog comparators can be tied directly to ground. In
that case, the relatively small input offset voltage of the comparators will not cause acquisition
problems. However, in certain specialized QMatrix applications such as interpolated touch
screens, it may be desirable for the sense capacitors to be charged to less than 25 mV. When
such small voltages are used on the sense capacitors, the input offset voltage of the comparators
becomes an issue and can cause QMatrix acquisition problems.
780
32142D–06/2013
ATUC64/128/256L3/4U
Problems with QMatrix acquisition of small sense capacitor voltages can be solved by connecting
the negative reference pin (ACREFN) to a voltage divider that produces a small positive
voltage (20 mV, typically) to cancel any negative input offset voltage. With a 3.3V supply, recommended
values for the voltage divider are Ra (resistor from positive supply to ACREFN) of 8200
ohm and Rb (resistor from ACREFN to ground) of 50 ohm. These recommended values will produce
20 mV on the ACREFN pin, which should generally be enough to compensate for the
worst-case negative input offset of the analog comparators.
Unfortunately, such a voltage divider constantly draws a small current from the power supply,
reducing battery life in portable applications. In order to prevent this constant power drain, the
CAT module provides a voltage divider enable pin (VDIVEN) that can be used for driving the
voltage divider. The VDIVEN pin provides power to the voltage divider only when the comparators
are actually performing QMatrix comparisons. When the comparators are inactive, the
VDIVEN output is zero. This minimizes the power consumed by the voltage divider.
781
32142D–06/2013
ATUC64/128/256L3/4U
31.7 User Interface
Table 31-3. CAT Register Memory Map
Offset Register Register Name Access Reset
0x00 Control Register CTRL Read/Write 0x00000000
0x04 Autonomous Touch Pin Selection Register ATPINS Read/Write 0x00000000
0x08 Pin Mode Register 0 PINMODE0 Read/Write 0x00000000
0x0C Pin Mode Register 1 PINMODE1 Read/Write 0x00000000
0x10 Autonomous/DMA Touch Configuration Register 0 ATCFG0 Read/Write 0x00000000
0x14 Autonomous/DMA Touch Configuration Register 1 ATCFG1 Read/Write 0x00000000
0x18 Autonomous/DMA Touch Configuration Register 2 ATCFG2 Read/Write 0x00000000
0x1C Autonomous/DMA Touch Configuration Register 3 ATCFG3 Read/Write 0x00000000
0x20 Touch Group A Configuration Register 0 TGACFG0 Read/Write 0x00000000
0x24 Touch Group A Configuration Register 1 TGACFG1 Read/Write 0x00000000
0x28 Touch Group B Configuration Register 0 TGBCFG0 Read/Write 0x00000000
0x2C Touch Group B Configuration Register 1 TGBCFG1 Read/Write 0x00000000
0x30 Matrix Group Configuration Register 0 MGCFG0 Read/Write 0x00000000
0x34 Matrix Group Configuration Register 1 MGCFG1 Read/Write 0x00000000
0x38 Matrix Group Configuration Register 2 MGCFG2 Read/Write 0x00000000
0x3C Status Register SR Read-only 0x00000000
0x40 Status Clear Register SCR Write-only -
0x44 Interrupt Enable Register IER Write-only -
0x48 Interrupt Disable Register IDR Write-only -
0x4C Interrupt Mask Register IMR Read-only 0x00000000
0x50 Acquisition Initiation and Selection Register AISR Read/Write 0x00000000
0x54 Acquired Count Register ACOUNT Read-only 0x00000000
0x58 Matrix Burst Length Register MBLEN Write-only -
0x5C Discharge Current Source Register DICS Read/Write 0x00000000
0x60 Spread Spectrum Configuration Register SSCFG Read/Write 0x00000000
0x64 CSA Resistor Control Register CSARES Read/Write 0x00000000
0x68 CSB Resistor Control Register CSBRES Read/Write 0x00000000
0x6C Autonomous Touch Base Count Register ATBASE Read-only 0x00000000
0x70 Autonomous Touch Current Count Register ATCURR Read-only 0x00000000
0x74 Pin Mode Register 2 PINMODE2 Read/Write 0x00000000
0x78 DMATouch State Write Register DMATSW Write-only 0x00000000
0x7C DMATouch State Read Register DMATSR Read-only 0x00000000
0x80 Analog Comparator Shift Offset Register 0 ACSHI0 Read/Write 0x00000000
0x84 Analog Comparator Shift Offset Register 1 ACSHI1 Read/Write 0x00000000
0x88 Analog Comparator Shift Offset Register 2 ACSHI2 Read/Write 0x00000000
782
32142D–06/2013
ATUC64/128/256L3/4U
Note: 1. The reset value for this register is device specific. Please refer to the Module Configuration section at the end of this chapter.
0x8C Analog Comparator Shift Offset Register 3 ACSHI3 Read/Write 0x00000000
0x90 Analog Comparator Shift Offset Register 4 ACSHI4 Read/Write 0x00000000
0x94 Analog Comparator Shift Offset Register 5 ACSHI5 Read/Write 0x00000000
0x98 Analog Comparator Shift Offset Register 6 ACSHI6 Read/Write 0x00000000
0x9C Analog Comparator Shift Offset Register 7 ACSHI7 Read/Write 0x00000000
0xA0 DMATouch Sensor Status Register DMATSS Read-only 0x00000000
0xF8 Parameter Register PARAMETER Read-only -(1)
0xFC Version Register VERSION Read-only -(1)
Table 31-3. CAT Register Memory Map
Offset Register Register Name Access Reset
783
32142D–06/2013
ATUC64/128/256L3/4U
31.7.1 Control Register
Name: CTRL
Access Type: Read/Write
Offset: 0x00
Reset Value: 0x00000000
• SWRST: Software reset
Writing a zero to this bit has no effect.
Writing a one to this bit resets the module. The module will be disabled after the reset.
This bit always reads as zero.
• EN: Module enable
0: Module is disabled.
1: Module is enabled.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
SWRST - - - - - - EN
784
32142D–06/2013
ATUC64/128/256L3/4U
31.7.2 Autonomous Touch Pin Selection Register
Name: ATPINS
Access Type: Read/Write
Offset: 0x04
Reset Value: 0x00000000
• ATEN: Autonomous Touch Enable
0: Autonomous QTouch acquisition and detection is disabled.
1: Autonomous QTouch acquisition and detection is enabled using the sense pair specified in ATSP.
• ATSP: Autonomous Touch Sense Pair
Selects the sense pair that will be used by the autonomous QTouch sensor. A value of n will select sense pair n (CSAn and
CSBn pins).
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
- - - - - - - ATEN
76543210
- - - ATSP
785
32142D–06/2013
ATUC64/128/256L3/4U
31.7.3 Pin Mode Registers 0, 1, and 2
Name: PINMODE0, PINMODE1, and PINMODE2
Access Type: Read/Write
Offset: 0x08, 0x0C, 0x74
Reset Value: 0x00000000
• SP: Sense Pair Mode Selection
Each SP[n] bit determines the operation mode of sense pair n (CSAn and CSBn pins). The (PINMODE2.SP[n]
PINMODE1.SP[n] PINMODE0.SP[n]) bits have the following definitions:
000: Sense pair n disabled.
001: Sense pair n is assigned to QTouch Group A.
010: Sense pair n is assigned to QTouch Group B.
011: Sense pair n is assigned to the QMatrix Group.
100: Sense pair n is assigned to the DMATouch Group.
101: Reserved.
110: Reserved.
111: Reserved.
31 30 29 28 27 26 25 24
-
23 22 21 20 19 18 17 16
- SP[16]
15 14 13 12 11 10 9 8
SP[15:8]
76543210
SP[7:0]
786
32142D–06/2013
ATUC64/128/256L3/4U
31.7.4 Autonomous/DMA Touch Configuration Register 0
Name: ATCFG0
Access Type: Read/Write
Offset: 0x10
Reset Value: 0x00000000
• DIV: Clock Divider
The prescaler is used to ensure that the CLK_CAT clock is divided to around 1 MHz to produce the sampling clock.The
prescaler uses the following formula to generate the sampling clock:
Sampling clock = CLK_CAT / (2(DIV+1))
• CHLEN: Charge Length
For the autonomous QTouch sensor and DMATouch sensors, specifies how many sample clock cycles should be used for
transferring charge to the sense capacitor.
• SELEN: Settle Length
For the autonomous QTouch sensor and DMATouch sensors, specifies how many sample clock cycles should be used for
settling after charge transfer.
31 30 29 28 27 26 25 24
DIV[15:8]
23 22 21 20 19 18 17 16
DIV[7:0]
15 14 13 12 11 10 9 8
CHLEN
76543210
SELEN
787
32142D–06/2013
ATUC64/128/256L3/4U
31.7.5 Autonomous/DMA Touch Configuration Register 1
Name: ATCFG1
Access Type: Read/Write
Offset: 0x14
Reset Value: 0x00000000
• DISHIFT: Discharge Shift
For the autonomous QTouch sensor and DMATouch sensors, specifies how many bits the DILEN field should be shifted before
using it to determine the discharge time.
• SYNC: Sync Pin
For the autonomous QTouch sensor and DMATouch sensors, specifies that acquisition shall begin when a falling edge is
received on the SYNC line.
• SPREAD: Spread Spectrum Sensor Drive
For the autonomous QTouch sensor and DMATouch sensors, specifies that spread spectrum sensor drive shall be used.
• DILEN: Discharge Length
For the autonomous QTouch sensor and DMATouch sensors, specifies how many sample clock cycles the CAT should use to
discharge the capacitors before charging them.
• MAX: Maximum Count
For the autonomous QTouch sensor and DMATouch sensors, specifies how many counts the maximum acquisition should be.
31 30 29 28 27 26 25 24
- DISHIFT - SYNC SPREAD
23 22 21 20 19 18 17 16
DILEN
15 14 13 12 11 10 9 8
MAX[15:8]
76543210
MAX[7:0]
788
32142D–06/2013
ATUC64/128/256L3/4U
31.7.6 Autonomous/DMA Touch Configuration Register 2
Name: ATCFG2
Access Type: Read/Write
Offset: 0x18
Reset Value: 0x00000000
• FILTER: Autonomous Touch Filter Setting
For the autonomous QTouch sensor and DMATouch sensors, specifies how many positive detects in a row the CAT needs to
have on the sensor before reporting it as a touch. A FILTER value of 0 is not allowed and will result in undefined behavior.
• OUTSENS: Out-of-Touch Sensitivity
For the autonomous QTouch sensor and DMATouch sensors, specifies how sensitive the out-of-touch detector should be.
• SENSE: Sensitivity
For the autonomous QTouch sensor and DMATouch sensors, specifies how sensitive the touch detector should be.
31 30 29 28 27 26 25 24
-
23 22 21 20 19 18 17 16
- FILTER
15 14 13 12 11 10 9 8
OUTSENS
76543210
SENSE
789
32142D–06/2013
ATUC64/128/256L3/4U
31.7.7 Autonomous/DMA Touch Configuration Register 3
Name: ATCFG3
Access Type: Read/Write
Offset: 0x1C
Reset Value: 0x00000000
• PTHR: Positive Recalibration Threshold
For the autonomous QTouch sensor and DMATouch sensors, specifies how far a sensor’s signal must move in a positive
direction from the reference in order to cause a recalibration.
• PDRIFT: Positive Drift Compensation
For the autonomous QTouch sensor and DMATouch sensors, specifies how often a positive drift compensation should be
performed. When this field is zero, positive drift compensation will never be performed. When this field is non-zero, the positive
drift compensation time interval is given by the following formula:
Tpdrift = PDRIFT * 65536 * (sample clock period)
• NDRIFT: Negative Drift Compensation
For the autonomous QTouch sensor and DMATouch sensors, specifies how often a negative drift compensation should be
performed. When this field is zero, negative drift compensation will never be performed. When this field is non-zero, the negative
drift compensation time interval is given by the following formula:
Tndrift = NDRIFT * 65536 * (sample clock period)
With the typical sample clock frequency of 1 MHz, PDRIFT and NDRIFT can be set from 0.066 seconds to 16.7 seconds
with 0.066 second resolution.
31 30 29 28 27 26 25 24
-
23 22 21 20 19 18 17 16
PTHR
15 14 13 12 11 10 9 8
PDRIFT
76543210
NDRIFT
790
32142D–06/2013
ATUC64/128/256L3/4U
31.7.8 Touch Group x Configuration Register 0
Name: TGxCFG0
Access Type: Read/Write
Offset: 0x20, 0x28
Reset Value: 0x00000000
• DIV: Clock Divider
The prescaler is used to ensure that the CLK_CAT clock is divided to around 1 MHz to produce the sampling clock.The
prescaler uses the following formula to generate the sampling clock:
Sampling clock = CLK_CAT / (2(DIV+1))
• CHLEN: Charge Length
For the QTouch method, specifies how many sample clock cycles should be used for transferring charge to the sense capacitor.
• SELEN: Settle Length
For the QTouch method, specifies how many sample clock cycles should be used for settling after charge transfer.
31 30 29 28 27 26 25 24
DIV[15:8]
23 22 21 20 19 18 17 16
DIV[7:0]
15 14 13 12 11 10 9 8
CHLEN
76543210
SELEN
791
32142D–06/2013
ATUC64/128/256L3/4U
31.7.9 Touch Group x Configuration Register 1
Name: TGxCFG1
Access Type: Read/Write
Offset: 0x24, 0x2C
Reset Value: 0x00000000
• DISHIFT: Discharge Shift
For the sensors in QTouch group x, specifies how many bits the DILEN field should be shifted before using it to determine the
discharge time.
• SYNC: Sync Pin
For sensors in QTouch group x, specifies that acquisition shall begin when a falling edge is received on the SYNC line.
• SPREAD: Spread Spectrum Sensor Drive
For sensors in QTouch group x, specifies that spread spectrum sensor drive shall be used.
• DILEN: Discharge Length
For sensors in QTouch group x, specifies how many clock cycles the CAT should use to discharge the capacitors before
charging them.
• MAX: Touch Maximum Count
For sensors in QTouch group x, specifies how many counts the maximum acquisition should be.
31 30 29 28 27 26 25 24
- - DISHIFT - - SYNC SPREAD
23 22 21 20 19 18 17 16
DILEN
15 14 13 12 11 10 9 8
MAX[15:8]
76543210
MAX[7:0]
792
32142D–06/2013
ATUC64/128/256L3/4U
31.7.10 Matrix Group Configuration Register 0
Name: MGCFG0
Access Type: Read/Write
Offset: 0x30
Reset Value: 0x00000000
• DIV: Clock Divider
The prescaler is used to ensure that the CLK_CAT clock is divided to around 4 MHz to produce the burst timing clock.The
prescaler uses the following formula to generate the burst timing clock:
Burst timing clock = CLK_CAT / (2(DIV+1))
• CHLEN: Charge Length
For QMatrix sensors, specifies how many burst prescaler clock cycles should be used for transferring charge to the sense
capacitor.
• SELEN: Settle Length
For QMatrix sensors, specifies how many burst prescaler clock cycles should be used for settling after charge transfer.
31 30 29 28 27 26 25 24
DIV[15:8]
23 22 21 20 19 18 17 16
DIV[7:0]
15 14 13 12 11 10 9 8
CHLEN
76543210
SELEN
793
32142D–06/2013
ATUC64/128/256L3/4U
31.7.11 Matrix Group Configuration Register 1
Name: MGCFG1
Access Type: Read/Write
Offset: 0x34
Reset Value: 0x00000000
• DISHIFT: Discharge Shift
For QMatrix sensors, specifies how many bits the DILEN field should be shifted before using it to determine the discharge time.
• SYNC: Sync Pin
For QMatrix sensors, specifies that acquisition shall begin when a falling edge is received on the SYNC line.
• SPREAD: Spread Spectrum Sensor Drive
For QMatrix sensors, specifies that spread spectrum sensor drive shall be used.
• DILEN: Discharge Length
For QMatrix sensors, specifies how many burst prescaler clock cycles the CAT should use to discharge the capacitors at the
beginning of a burst sequence.
• MAX: Maximum Count
For QMatrix sensors, specifies how many counts the maximum acquisition should be.
31 30 29 28 27 26 25 24
- DISHIFT - SYNC SPREAD
23 22 21 20 19 18 17 16
DILEN
15 14 13 12 11 10 9 8
MAX[15:8]
76543210
MAX[7:0]
794
32142D–06/2013
ATUC64/128/256L3/4U
31.7.12 Matrix Group Configuration Register 2
Name: MGCFG2
Access Type: Read/Write
Offset: 0x38
Reset Value: 0x00000000
• ACCTRL: Analog Comparator Control
When written to one, allows the CAT to disable the analog comparators when they are not needed. When written to zero, the
analog comparators are always enabled.
• CONSEN: Consensus Filter Length
For QMatrix sensors, specifies that discharge will be terminated when CONSEN out of the most recent 5 comparator samples
are positive. For example, a value of 3 in the CONSEN field will terminate discharge when 3 out of the most recent 5 comparator
samples are positive. When CONSEN has the default value of 0, discharge will be terminated immediately when the comparator
output goes positive.
• CXDILEN: Cx Capacitor Discharge Length
For QMatrix sensors, specifies how many burst prescaler clock cycles the CAT should use to discharge the Cx capacitor at the
end of each burst cycle.
• SYNCTIM: Sync Time Interval
When non-zero, determines the number of prescaled clock cycles between the start of the acquisition on each X line for QMatrix
acquisition.
31 30 29 28 27 26 25 24
ACCTRL CONSEN -
23 22 21 20 19 18 17 16
CXDILEN
15 14 13 12 11 10 9 8
- SYNCTIM[11:8]
76543210
SYNCTIM[7:0]
795
32142D–06/2013
ATUC64/128/256L3/4U
31.7.13 Status Register
Name: SR
Access Type: Read-only
Offset: 0x3C
Reset Value: 0x00000000
• DMATSC: DMATouch Sensor State Change
0: No change in the DMATSS register.
1: One or more bits have changed in the DMATSS register.
• DMATSR: DMATouch State Read Register Ready
0: A new state word is not available in the DMATSR register.
1: A new state word is available in the DMATSR register.
• DMATSW: DMATouch State Write Register Request
0: The DMATouch algorithm is not requesting that a state word be written to the DMATSW register.
1: The DMATouch algorithm is requesting that a state word be written to the DMATSW register.
• ACQDONE: Acquisition Done
0: Acquisition is not done (still in progress).
1: Acquisition is complete.
• ACREADY: Acquired Count Data is Ready
0: Acquired count data is not available in the ACOUNT register.
1: Acquired count data is available in the ACOUNT register.
• MBLREQ: Matrix Burst Length Required
0: The QMatrix acquisition does not require any burst lengths.
1: The QMatrix acquisition requires burst lengths for the current X line.
• ATSTATE: Autonomous Touch Sensor State
0: The autonomous QTouch sensor is not active.
1: The autonomous QTouch sensor is active.
• ATSC: Autonomous Touch Sensor Status Interrupt
0: No status change in the autonomous QTouch sensor.
1: Status change in the autonomous QTouch sensor.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
DMATSC - - - - - DMATSR DMATSW
15 14 13 12 11 10 9 8
- - - - - - ACQDONE ACREADY
76543210
- - - MBLREQ ATSTATE ATSC ATCAL ENABLED
796
32142D–06/2013
ATUC64/128/256L3/4U
• ATCAL: Autonomous Touch Calibration Ongoing
0: The autonomous QTouch sensor is not calibrating.
1: The autonomous QTouch sensor is calibrating.
• ENABLED: Module Enabled
0: The module is disabled.
1: The module is enabled.
797
32142D–06/2013
ATUC64/128/256L3/4U
31.7.14 Status Clear Register
Name: SCR
Access Type: Write-only
Offset: 0x40
Reset Value: -
Writing a zero to a bit in this register has no effect.
Writing a one to a bit in this register will clear the corresponding bit in SR and the corresponding interrupt request.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
DMATSC - - - - - - -
15 14 13 12 11 10 9 8
- - - - - - ACQDONE ACREADY
76543210
- - - - - ATSC ATCAL -
798
32142D–06/2013
ATUC64/128/256L3/4U
31.7.15 Interrupt Enable Register
Name: IER
Access Type: Write-only
Offset: 0x44
Reset Value: -
Writing a zero to a bit in this register has no effect.
Writing a one to a bit in this register will set the corresponding bit in IMR.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
DMATSC - - - - - - -
15 14 13 12 11 10 9 8
- - - - - - ACQDONE ACREADY
76543210
- - - - - ATSC ATCAL -
799
32142D–06/2013
ATUC64/128/256L3/4U
31.7.16 Interrupt Disable Register
Name: IDR
Access Type: Write-only
Offset: 0x48
Reset Value: -
Writing a zero to a bit in this register has no effect.
Writing a one to a bit in this register will clear the corresponding bit in IMR.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
DMATSC - - - - - - -
15 14 13 12 11 10 9 8
- - - - - - ACQDONE ACREADY
76543210
- - - - - ATSC ATCAL -
800
32142D–06/2013
ATUC64/128/256L3/4U
31.7.17 Interrupt Mask Register
Name: IMR
Access Type: Read-only
Offset: 0x4C
Reset Value: 0x00000000
0: The corresponding interrupt is disabled.
1: The corresponding interrupt is enabled.
A bit in this register is cleared when the corresponding bit in IDR is written to one.
A bit in this register is set when the corresponding bit in IER is written to one.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
DMATSC - - - - - - -
15 14 13 12 11 10 9 8
- - - - - - ACQDONE ACREADY
76543210
- - - - - ATSC ATCAL -
801
32142D–06/2013
ATUC64/128/256L3/4U
31.7.18 Acquisition Initiation and Selection Register
Name: AISR
Access Type: Read/Write
Offset: 0x50
Reset Value: 0x00000000
• ACQSEL: Acquisition Type Selection
A write to this register initiates an acquisition of the following type:
00: QTouch Group A.
01: QTouch Group B.
10: QMatrix Group.
11: Undefined behavior.
A read of this register will return the value that was previously written.
31 30 29 28 27 26 25 24
-
23 22 21 20 19 18 17 16
-
15 14 13 12 11 10 9 8
-
76543210
- ACQSEL
802
32142D–06/2013
ATUC64/128/256L3/4U
31.7.19 Acquired Count Register
Name: ACOUNT
Access Type: Read-only
Offset: 0x54
Reset Value: 0x00000000
• Y: Y index
The Y index (for QMatrix method) associated with this count value.
• SPORX: Sensor pair or X index
The sensor pair index (for QTouch method) or X index (for QMatrix method) associated with this count value.
• COUNT: Count value
The signal (number of counts) acquired on the channel specified in the SPORX and Y fields.
When multiple acquired count values are read from a QTouch acquisition, the Y field will always be 0 and the SPORX value will
increase monotonically. For example, suppose a QTouch acquisition is performed using sensor pairs SP1, SP4, and SP9. The
first count read will have SPORX=1, the second read will have SPORX=4, and the third read will have SPORX=9.
When multiple acquired count values are read from a QMatrix acquisition, the SPORX value will stay the same while Y
increases monotonically through all Y values in the group. Then SPORX will increase to the next X value in the group. For
example, a QMatrix acquisition with X=2,3 and Y=4,7 would provide count values in the following order: X=2 and Y=4, then X=2
and Y=7, then X=3 and Y=4, and finally X=3 and Y=7.
31 30 29 28 27 26 25 24
Y
23 22 21 20 19 18 17 16
SPORX
15 14 13 12 11 10 9 8
COUNT[15:8]
76543210
COUNT[7:0]
803
32142D–06/2013
ATUC64/128/256L3/4U
31.7.20 Matrix Burst Length Register
Name: MBLEN
Access Type: Write-only
Offset: 0x58
Reset Value: -
• BURSTx: Burst Length x
For QMatrix sensors, specifies how many times the switching sequence should be repeated before acquisition begins for each
channel. Each count in the BURSTx field specifies 1 repeat of the switching sequence, so the actual burst length will be BURST.
Before doing a QMatrix acquisition on one X line this register has to be written with the burst values for the current XY pairs. For
each X line this register needs to be programmed with all the Y values. If Y values larger than 3 are used the register has to be
written several times in order to specify all burst lengths.
The Status Register bit MBLREQ is set to 1 when the CAT is waiting for values to be written into this register.
31 30 29 28 27 26 25 24
BURST0
23 22 21 20 19 18 17 16
BURST1
15 14 13 12 11 10 9 8
BURST2
76543210
BURST3
804
32142D–06/2013
ATUC64/128/256L3/4U
31.7.21 Discharge Current Source Register
Name: DICS
Access Type: Read/Write
Offset: 0x5C
Reset Value: 0x00000000
• FSOURCES: Force Discharge Current Sources
When FSOURCES[n] is 0, the corresponding discharge current source behavior depends on SOURCES[n].
When FSOURCES[n] is 1, the corresponding discharge current source is forced to be enabled continuously. This is useful for
testing or debugging but should not be done during normal acquisition.
• GLEN: Global Enable
0: The current source module is globally disabled.
1: The current source module is globally enabled.
• INTVREFSEL: Internal Voltage Reference Select
0: The voltage for the reference resistor is generated from the internal band gap circuit.
1: The voltage for the reference resistor is VDDIO/3.
• INTREFSEL: Internal Reference Select
0: The reference current flows through an external resistor on the DIS pin.
1: The reference current flows through the internal reference resistor.
• TRIM: Reference Current Trimming
This field is used to trim the discharge current. 0x00 corresponds to the minimum current value, and 0x1F corresponds to the
maximum current value.
• SOURCES: Enable Discharge Current Sources
When SOURCES[n] is 0, the corresponding discharge current source is disabled.
When SOURCES[n] is 1, the corresponding discharge current source is enabled at appropriate times during acquisition.
31 30 29 28 27 26 25 24
FSOURCES[7:0]
23 22 21 20 19 18 17 16
GLEN - - - - - INTVREFSEL INTREFSEL
15 14 13 12 11 10 9 8
- - - TRIM
76543210
SOURCES[7:0]
805
32142D–06/2013
ATUC64/128/256L3/4U
31.7.22 Spread Spectrum Configuration Register
Name: SSCFG
Access Type: Read/Write
Offset: 0x60
Reset Value: 0x00000000
• MAXDEV: Maximum Deviation
When spread spectrum burst is enabled, MAXDEV indicates the maximum number of prescaled clock cycles the burst pulse will
be extended or shortened.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
MAXDEV
806
32142D–06/2013
ATUC64/128/256L3/4U
31.7.23 CSA Resistor Control Register
Name: CSARES
Access Type: Read/Write
Offset: 0x64
Reset Value: 0x00000000
• RES: Resistive Drive Enable
When RES[n] is 0, CSA[n] has the same drive properties as normal I/O pads.
When RES[n] is 1, CSA[n] has a nominal output resistance of 1kOhm during the burst phase.
31 30 29 28 27 26 25 24
-
23 22 21 20 19 18 17 16
- RES[16]
15 14 13 12 11 10 9 8
RES[15:8]
76543210
RES[7:0]
807
32142D–06/2013
ATUC64/128/256L3/4U
31.7.24 CSB Resistor Control Register
Name: CSBRES
Access Type: Read/Write
Offset: 0x68
Reset Value: 0x00000000
• RES: Resistive Drive Enable
When RES[n] is 0, CSB[n] has the same drive properties as normal I/O pads.
When RES[n] is 1, CSB[n] has a nominal output resistance of 1kOhm during the burst phase.
31 30 29 28 27 26 25 24
-
23 22 21 20 19 18 17 16
- RES[16]
15 14 13 12 11 10 9 8
RES[15:8]
76543210
RES[7:0]
808
32142D–06/2013
ATUC64/128/256L3/4U
31.7.25 Autonomous Touch Base Count Register
Name: ATBASE
Access Type: Read-only
Offset: 0x6C
Reset Value: 0x00000000
• COUNT: Count value
The base count currently stored by the autonomous touch sensor. This is useful for autonomous touch debugging purposes.
31 30 29 28 27 26 25 24
-
23 22 21 20 19 18 17 16
-
15 14 13 12 11 10 9 8
COUNT[15:8]
76543210
COUNT[7:0]
809
32142D–06/2013
ATUC64/128/256L3/4U
31.7.26 Autonomous Touch Current Count Register
Name: ATCURR
Access Type: Read-only
Offset: 0x70
Reset Value: 0x00000000
• COUNT: Count value
The current count acquired by the autonomous touch sensor. This is useful for autonomous touch debugging purposes.
31 30 29 28 27 26 25 24
-
23 22 21 20 19 18 17 16
-
15 14 13 12 11 10 9 8
COUNT[15:8]
76543210
COUNT[7:0]
810
32142D–06/2013
ATUC64/128/256L3/4U
31.7.27 DMATouch State Write Register
Name: DMATSW
Access Type: Write-only
Offset: 0x78
Reset Value: 0x00000000
• NOTINCAL: Not in Calibration Mode
0: Calibration should be performed on the next iteration of the DMATouch algorithm.
1: Calibration should not be performed on the next iteration of the DMATouch algorithm.
• DETCNT: Detection Count
This count value is updated and used by the DMATouch algorithm in order to detect when a button has been pushed.
• BASECNT: Base Count
This count value represents the average expected acquired count when the sensor/button is not pushed.
31 30 29 28 27 26 25 24
- - - - - - - NOTINCAL
23 22 21 20 19 18 17 16
DETCNT[23:16]
15 14 13 12 11 10 9 8
BASECNT[15:8]
76543210
BASECNT[7:0]
811
32142D–06/2013
ATUC64/128/256L3/4U
31.7.28 DMA Touch State Read Register
Name: DMATSR
Access Type: Read/Write
Offset: 0x7C
Reset Value: 0x00000000
• NOTINCAL: Not in Calibration Mode
0: Calibration should be performed on the next iteration of the DMATouch algorithm.
1: Calibration should not be performed on the next iteration of the DMATouch algorithm.
• DETCNT: Detection Count
This count value is updated and used by the DMATouch algorithm in order to detect when a button has been pushed.
• BASECNT: Base Count
This count value represents the average expected acquired count when the sensor/button is not pushed.
31 30 29 28 27 26 25 24
- - - - - - - NOTINCAL
23 22 21 20 19 18 17 16
DETCNT[23:16]
15 14 13 12 11 10 9 8
BASECNT[15:8]
76543210
BASECNT[7:0]
812
32142D–06/2013
ATUC64/128/256L3/4U
31.7.29 Analog Comparator Shift Offset Register x
Name: ACSHIx
Access Type: Read/Write
Offset: 0x80, 0x84, 0x88, 0x8C, 0x90, 0x94, 0x98, and 0x9C
Reset Value: 0x00000000
• SHIVAL: Shift Offset Value
Specifies the amount to shift the count value from each comparator. This allows the offset of each comparator to be
compensated.
31 30 29 28 27 26 25 24
-
23 22 21 20 19 18 17 16
-
15 14 13 12 11 10 9 8
- SHIVAL[11:8]
76543210
SHIVAL[7:0]
813
32142D–06/2013
ATUC64/128/256L3/4U
31.7.30 DMATouch Sensor Status Register
Name: DMATSS
Access Type: Read-only
Offset: 0xA0
Reset Value: 0x00000000
• SS: Sensor Status
0: The DMATouch sensor is not active, i.e. the button is currently not pushed.
1: The DMATouch sensor is active, i.e. the button is currently pushed.
31 30 29 28 27 26 25 24
SS[31:24]
23 22 21 20 19 18 17 16
SS[23:16]
15 14 13 12 11 10 9 8
SS[15:8]
76543210
SS[7:0]
814
32142D–06/2013
ATUC64/128/256L3/4U
31.7.31 Parameter Register
Name: PARAMETER
Access Type: Read-only
Offset: 0xF8
Reset Value: -
• SP[n]: Sensor pair implemented
0: The corresponding sensor pair is not implemented
1: The corresponding sensor pair is implemented.
31 30 29 28 27 26 25 24
SP[31:24]
23 22 21 20 19 18 17 16
SP[23:16]
15 14 13 12 11 10 9 8
SP[15:8]
76543210
SP[7:0]
815
32142D–06/2013
ATUC64/128/256L3/4U
31.7.32 Version Register
Name: VERSION
Access Type: Read-only
Offset: 0xFC
Reset Value: -
• VARIANT: Variant number
Reserved. No functionality associated.
• VERSION: Version number
Version number of the module. No functionality associated.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
- - - - VARIANT
15 14 13 12 11 10 9 8
- - - - VERSION[11:8]
76543210
VERSION[7:0]
816
32142D–06/2013
ATUC64/128/256L3/4U
31.8 Module Configuration
The specific configuration the CAT module is listed in the following tables.The module bus
clocks listed here are connected to the system bus clocks. Please refer to the Power Manager
chapter for details.
31.8.1 Resistive Drive
By default, the CAT pins are driven with normal I/O drive properties. Some of the CSA and CSB
pins can optionally drive with a 1k output resistance for improved EMC.
To enable resistive drive on a pin, the user must write a one to the corresponding bit in the CSA
Resistor Control Register (CSARES) or CSB Resistor Control Register (CSBRES) register.
Table 31-4. CAT Configuration
Feature CAT
Number of touch sensors/Size of matrix Allows up to 17 touch sensors, or up to 16 by 8
matrix sensors to be interfaced.
Table 31-5. CAT Clocks
Clock Name Description
CLK_CAT Clock for the CAT bus interface
GCLK The generic clock used for the CAT is GCLK4
Table 31-6. Register Reset Values
Register Reset Value
VERSION 0x00000400
PARAMETER 0x0001FFFF
817
32142D–06/2013
ATUC64/128/256L3/4U
32. Glue Logic Controller (GLOC)
Rev: 1.0.0.0
32.1 Features
• Glue logic for general purpose PCB design
• Programmable lookup table
• Up to four inputs supported per lookup table
• Optional filtering of output
32.2 Overview
The Glue Logic Controller (GLOC) contains programmable logic which can be connected to the
device pins. This allows the user to eliminate logic gates for simple glue logic functions on the
PCB.
The GLOC consists of a number of lookup table (LUT) units. Each LUT can generate an output
as a user programmable logic expression with four inputs. Inputs can be individually masked.
The output can be combinatorially generated from the inputs, or filtered to remove spikes.
32.3 Block Diagram
Figure 32-1. GLOC Block Diagram PERIPHERAL BUS TRUTH
FILTER
OUT[0]
...
OUT[n]
FILTEN
IN[3:0]
…
IN[(4n+3):4n]
AEN
CLK_GLOC
GCLK
818
32142D–06/2013
ATUC64/128/256L3/4U
32.4 I/O Lines Description
Each LUT have 4 inputs and one output. The inputs and outputs for the LUTs are mapped
sequentially to the inputs and outputs. This means that LUT0 is connected to IN0 to IN3 and
OUT0. LUT1 is connected to IN4 to IN7 and OUT1. In general, LUTn is connected to IN[4n] to
IN[4n+3] and OUTn.
32.5 Product Dependencies
In order to use this module, other parts of the system must be configured correctly, as described
below.
32.5.1 I/O Lines
The pins used for interfacing the GLOC may be multiplexed with I/O Controller lines. The programmer
must first program the I/O Controller to assign the desired GLOC pins to their
peripheral function. If I/O lines of the GLOC are not used by the application, they can be used for
other purposes by the I/O Controller.
It is only required to enable the GLOC inputs and outputs actually in use. Pullups for pins configured
to be used by the GLOC will be disabled.
32.5.2 Clocks
The clock for the GLOC bus interface (CLK_GLOC) is generated by the Power Manager. This
clock is enabled at reset, and can be disabled in the Power Manager. It is recommended to disable
the GLOC before disabling the clock, to avoid freezing the module in an undefined state.
Additionally, the GLOC depends on a dedicated Generic Clock (GCLK). The GCLK can be set to
a wide range of frequencies and clock sources, and must be enabled by the System Control
Interface (SCIF) before the GLOC filter can be used.
32.5.3 Debug Operation
When an external debugger forces the CPU into debug mode, the GLOC continues normal
operation.
32.6 Functional Description
32.6.1 Enabling the Lookup Table Inputs
Since the inputs to each lookup table (LUT) unit can be multiplexed with other peripherals, each
input must be explicitly enabled by writing a one to the corresponding enable bit (AEN) in the
corresponding Control Register (CR).
If no inputs are enabled, the output OUTn will be the least significant bit in the TRUTHn register.
Table 32-1. I/O Lines Description
Pin Name Pin Description Type
IN0-INm Inputs to lookup tables Input
OUT0-OUTn Output from lookup tables Output
819
32142D–06/2013
ATUC64/128/256L3/4U
32.6.2 Configuring the Lookup Table
The lookup table in each LUT unit can generate any logic expression OUT as a function of up to
four inputs, IN[3:0]. The truth table for the expression is written to the TRUTH register for the
LUT. Table 32-2 shows the truth table for LUT0. The truth table for LUTn is written to TRUTHn,
and the corresponding input and outputs will be IN[4n] to IN[4n+3] and OUTn.
32.6.3 Output Filter
By default, the output OUTn is a combinatorial function of the inputs IN[4n] to IN[4n+3]. This may
cause some short glitches to occur when the inputs change value.
It is also possible to clock the output through a filter to remove glitches. This requires that the
corresponding generic clock (GCLK) has been enabled before use. The filter can then be
enabled by writing a one to the Filter Enable (FILTEN) bit in CRn. The OUTn output will be
delayed by three to four GCLK cycles when the filter is enabled.
Table 32-2. Truth Table for the Lookup Table in LUT0
IN[3] IN[2] IN[1] IN[0] OUT[0]
0 0 0 0 TRUTH0[0]
0 0 0 1 TRUTH0[1]
0 0 1 0 TRUTH0[2]
0 0 1 1 TRUTH0[3]
0 1 0 0 TRUTH0[4]
0 1 0 1 TRUTH0[5]
0 1 1 0 TRUTH0[6]
0 1 1 1 TRUTH0[7]
1 0 0 0 TRUTH0[8]
1 0 0 1 TRUTH0[9]
1 0 1 0 TRUTH0[10]
1 0 1 1 TRUTH0[11]
1 1 0 0 TRUTH0[12]
1 1 0 1 TRUTH0[13]
1 1 1 0 TRUTH0[14]
1 1 1 1 TRUTH0[15]
820
32142D–06/2013
ATUC64/128/256L3/4U
32.7 User Interface
Note: 1. The reset values are device specific. Please refer to the Module Configuration section at the end of this chapter.
Table 32-3. GLOC Register Memory Map
Offset Register Register Name Access Reset
0x00+n*0x08 Control Register n CRn Read/Write 0x00000000
0x04+n*0x08 Truth Table Register n TRUTHn Read/Write 0x00000000
0x38 Parameter Register PARAMETER Read-only - (1)
0x3C Version Register VERSION Read-only - (1)
821
32142D–06/2013
ATUC64/128/256L3/4U
32.7.1 Control Register n
Name: CRn
Access Type: Read/Write
Offset: 0x00+n*0x08
Reset Value: 0x00000000
• FILTEN: Filter Enable
1: The output is glitch filtered
0: The output is not glitch filtered
• AEN: Enable IN Inputs
Input IN[n] is enabled when AEN[n] is one.
Input IN[n] is disabled when AEN[n] is zero, and will not affect the OUT value.
31 30 29 28 27 26 25 24
FILTEN - - - - - - -
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
- - - - AEN
822
32142D–06/2013
ATUC64/128/256L3/4U
32.7.2 Truth Table Register n
Name: TRUTHn
Access Type: Read/Write
Offset: 0x04+n*0x08
Reset Value: 0x00000000
• TRUTH: Truth Table Value
This value defines the output OUT as a function of inputs IN:
OUT = TRUTH[IN]
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
TRUTH[15:8]
76543210
TRUTH[7:0]
823
32142D–06/2013
ATUC64/128/256L3/4U
32.7.3 Parameter Register
Name: PARAMETER
Access Type: Read-only
Offset: 0x38
Reset Value: -
• LUTS: Lookup Table Units Implemented
This field contains the number of lookup table units implemented in this device.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
LUTS
824
32142D–06/2013
ATUC64/128/256L3/4U
32.7.4 VERSION Register
Name: VERSION
Access Type: Read-only
Offset: 0x3C
Reset Value: -
• VARIANT: Variant Number
Reserved. No functionality associated.
• VERSION: Version Number
Version number of the module. No functionality associated.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
- - - - VARIANT
15 14 13 12 11 10 9 8
- - - - VERSION[11:8]
76543210
VERSION[7:0]
825
32142D–06/2013
ATUC64/128/256L3/4U
32.8 Module Configuration
The specific configuration for each GLOC instance is listed in the following tables.The GLOC
bus clocks listed here are connected to the system bus clocks. Please refer to the Power Manager
chapter for details.
Table 32-4. GLOC Configuration
Feature GLOC
Number of LUT units 2
Table 32-5. GLOC Clocks
Clock Name Description
CLK_GLOC Clock for the GLOC bus interface
GCLK The generic clock used for the GLOC is GCLK5
Table 32-6. Register Reset Values
Register Reset Value
VERSION 0x00000100
PARAMETER 0x00000002
826
32142D–06/2013
ATUC64/128/256L3/4U
33. aWire UART (AW)
Rev: 2.3.0.0
33.1 Features
• Asynchronous receiver or transmitter when the aWire system is not used for debugging.
• One- or two-pin operation supported.
33.2 Overview
If the AW is not used for debugging, the aWire UART can be used by the user to send or receive
data with one start bit, eight data bits, no parity bits, and one stop bit. This can be controlled
through the aWire UART user interface.
This chapter only describes the aWire UART user interface. For a description of the aWire
Debug Interface, please see the Programming and Debugging chapter.
33.3 Block Diagram
Figure 33-1. aWire Debug Interface Block Diagram
UART
Reset
filter
External reset
AW_ENABLE
RESET_N
Baudrate Detector
RW SZ ADDR DATA
CRC
AW CONTROL
AW User Interface
SAB interface
RESET command
Power
Manager
HALT command CPU
Flash
Controller CHIP_ERASE command
aWire Debug Interface
PB
SAB
827
32142D–06/2013
ATUC64/128/256L3/4U
33.4 I/O Lines Description
33.5 Product Dependencies
In order to use this module, other parts of the system must be configured correctly, as described
below.
33.5.1 I/O Lines
The pin used by AW is multiplexed with the RESET_N pin. The reset functionality is the default
function of this pin. To enable the aWire functionality on the RESET_N pin the user must enable
the aWire UART user interface.
33.5.2 Power Management
If the CPU enters a sleep mode that disables clocks used by the aWire UART user interface, the
aWire UART user interface will stop functioning and resume operation after the system wakes
up from sleep mode.
33.5.3 Clocks
The aWire UART uses the internal 120 MHz RC oscillator (RC120M) as clock source for its
operation. When using the aWire UART user interface RC120M must enabled using the Clock
Request Register (see Section 33.6.1).
The clock for the aWire UART user interface (CLK_AW) is generated by the Power Manager.
This clock is enabled at reset, and can be disabled in the Power Manager. It is recommended to
disable the aWire UART user interface before disabling the clock, to avoid freezing the aWire
UART user interface in an undefined state.
33.5.4 Interrupts
The aWire UART user interface interrupt request line is connected to the interrupt controller.
Using the aWire UART user interface interrupt requires the interrupt controller to be programmed
first.
33.5.5 Debug Operation
If the AW is used for debugging the aWire UART user interface will not be usable.
When an external debugger forces the CPU into debug mode, the aWire UART user interface
continues normal operation. If the aWire UART user interface is configured in a way that
requires it to be periodically serviced by the CPU through interrupts or similar, improper operation
or data loss may result during debugging.
33.5.6 External Components
The AW needs an external pullup on the RESET_N pin to ensure that the pin is pulled up when
the bus is not driven.
33.6 Functional Description
The aWire UART user interface can be used as a spare Asynchronous Receiver or Transmitter
when AW is not used for debugging.
Table 33-1. I/O Lines Description
Name Description Type
DATA aWire data multiplexed with the RESET_N pin. Input/Output
828
32142D–06/2013
ATUC64/128/256L3/4U
33.6.1 How to Initialize The Module
To initialize the aWire UART user interface the user must first enable the clock by writing a one
to the Clock Enable bit in the Clock Request Register (CLKR.CLKEN) and wait for the Clock
Enable bit in the Status Register (SR.CENABLED) to be set. After doing this either receive,
transmit or receive with resync must be selected by writing the corresponding value into the
Mode field of the Control (CTRL.MODE) Register. Due to the RC120M being asynchronous with
the system clock values must be allowed to propagate in the system. During this time the aWire
master will set the Busy bit in the Status Register (SR.BUSY).
After the SR.BUSY bit is cleared the Baud Rate field in the Baud Rate Register (BRR.BR) can
be written with the wanted baudrate ( ) according to the following formula ( is the RC120M
clock frequency):
After this operation the user must wait until the SR.BUSY is cleared. The interface is now ready
to be used.
33.6.2 Basic Asynchronous Receiver Operation
The aWire UART user interface must be initialized according to the sequence above, but the
CTRL.MODE field must be written to one (Receive mode).
When a data byte arrives the aWire UART user interface will indicate this by setting the Data
Ready Interrupt bit in the Status Register (SR.DREADYINT). The user must read the Data in the
Receive Holding Register (RHR.RXDATA) and clear the Interrupt bit by writing a one to the Data
Ready Interrupt Clear bit in the Status Clear Register (SCR.DREADYINT). The interface is now
ready to receive another byte.
33.6.3 Basic Asynchronous Transmitter Operation
The aWire UART user interface must be initialized according to the sequence above, but the
CTRL.MODE field must be written to two (Transmit mode).
To transmit a data byte the user must write the data to the Transmit Holding Register
(THE.TXDATA). Before the next byte can be written the SR.BUSY must be cleared.
33.6.4 Basic Asynchronous Receiver with Resynchronization
By writing three into CTRL.MODE the aWire UART user interface will assume that the first byte
it receives is a sync byte (0x55) and set BRR.BR according to this. All subsequent transfers will
assume this baudrate, unless BRR.BR is rewritten by the user.
To make the aWire UART user interface accept a new sync resynchronization the aWire UART
user interface must be disabled by writing zero to CTRL.MODE and then reenable the interface.
33.6.5 Overrun
In Receive mode an overrun can occur if the user has not read the previous received data from
the RHR.RXDATA when the newest data should be placed there. Such a condition is flagged by
setting the Overrun bit in the Status Register (SR.OVERRUN). If SR.OVERRUN is set the newest
data received is placed in RHR.RXDATA and the data that was there before is overwritten.
f
br f
aw
f
br
8f
aw
BR = -----------
829
32142D–06/2013
ATUC64/128/256L3/4U
33.6.6 Interrupts
To make the CPU able to do other things while waiting for the aWire UART user interface to finish
its operations the aWire UART user interface supports generating interrupts. All status bits in
the Status Register can be used as interrupt sources, except the SR.BUSY and SR.CENABLED
bits.
To enable an interrupt the user must write a one to the corresponding bit in the Interrupt Enable
Register (IER). Upon the next zero to one transition of this SR bit the aWire UART user interface
will flag this interrupt to the CPU. To clear the interrupt the user must write a one to the corresponding
bit in the Status Clear Register (SCR).
Interrupts can be disabled by writing a one to the corresponding bit in the Interrupt Disable Register
(IDR). The interrupt Mask Register (IMR) can be read to check if an interrupt is enabled or
disabled.
33.6.7 Using the Peripheral DMA Controller
To relieve the CPU of data transfers the aWire UART user interface support using the Peripheral
DMA controller.
To transmit using the Peripheral DMA Controller do the following:
1. Setup the aWire UART user interface in transmit mode.
2. Setup the Peripheral DMA Controller with buffer address and length, use byte as transfer
size.
3. Enable the Peripheral DMA Controller.
4. Wait until the Peripheral DMA Controller is done.
To receive using the Peripheral DMA Controller do the following:
1. Setup the aWire UART user interface in receive mode
2. Setup the Peripheral DMA Controller with buffer address and length, use byte as transfer
size.
3. Enable the Peripheral DMA Controller.
4. Wait until the Peripheral DMA Controller is ready.
830
32142D–06/2013
ATUC64/128/256L3/4U
33.7 User Interface
Note: 1. The reset values are device specific. Please refer to the Module Configuration section at the end of this chapter.
Table 33-2. aWire UART user interface Register Memory Map
Offset Register Register Name Access Reset
0x00 Control Register CTRL Read/Write 0x00000000
0x04 Status Register SR Read-only 0x00000000
0x08 Status Clear Register SCR Write-only -
0x0C Interrupt Enable Register IER Write-only -
0x10 Interrupt Disable Register IDR Write-only -
0x14 Interrupt Mask Register IMR Read-only 0x00000000
0x18 Receive Holding Register RHR Read-only 0x00000000
0x1C Transmit Holding Register THR Read/Write 0x00000000
0x20 Baud Rate Register BRR Read/Write 0x00000000
0x24 Version Register VERSION Read-only -(1)
0x28 Clock Request Register CLKR Read/Write 0x00000000
831
32142D–06/2013
ATUC64/128/256L3/4U
33.7.1 Control Register
Name: CTRL
Access Type: Read/Write
Offset: 0x00
Reset Value: 0x00000000
• MODE: aWire UART user interface mode
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
- - - - - - MODE
Table 33-3. aWire UART user interface Modes
MODE Mode Description
0 Disabled
1 Receive
2 Transmit
3 Receive with resync.
832
32142D–06/2013
ATUC64/128/256L3/4U
33.7.2 Status Register
Name: SR
Access Type: Read-only
Offset: 0x04
Reset Value: 0x00000000
• TRMIS: Transmit Mismatch
0: No transfers mismatches.
1: The transceiver was active when receiving.
This bit is set when the transceiver is active when receiving.
This bit is cleared when corresponding bit in SCR is written to one.
• OVERRUN: Data Overrun
0: No data overwritten in RHR.
1: Data in RHR has been overwritten before it has been read.
This bit is set when data in RHR is overwritten before it has been read.
This bit is cleared when corresponding bit in SCR is written to one.
• DREADYINT: Data Ready Interrupt
0: No new data in the RHR.
1: New data received and placed in the RHR.
This bit is set when new data is received and placed in the RHR.
This bit is cleared when corresponding bit in SCR is written to one.
• READYINT: Ready Interrupt
0: The interface has not generated an ready interrupt.
1: The interface has had a transition from busy to not busy.
This bit is set when the interface has transition from busy to not busy.
This bit is cleared when corresponding bit in SCR is written to one.
• CENABLED: Clock Enabled
0: The aWire clock is not enabled.
1: The aWire clock is enabled.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
- - TRMIS - - OVERRUN DREADYINT READYINT
76543210
- - - - - CENABLED - BUSY
833
32142D–06/2013
ATUC64/128/256L3/4U
This bit is set when the clock is disabled.
This bit is cleared when the clock is enabled.
• BUSY: Synchronizer Busy
0: The asynchronous interface is ready to accept more data.
1: The asynchronous interface is busy and will block writes to CTRL, BRR, and THR.
This bit is set when the asynchronous interface becomes busy.
This bit is cleared when the asynchronous interface becomes ready.
834
32142D–06/2013
ATUC64/128/256L3/4U
33.7.3 Status Clear Register
Name: SCR
Access Type: Write-only
Offset: 0x08
Reset Value: 0x00000000
Writing a zero to a bit in this register has no effect.
Writing a one to a bit in this register will clear the corresponding bit in SR and the corresponding interrupt request.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
- - TRMIS - - OVERRUN DREADYINT READYINT
76543210
--------
835
32142D–06/2013
ATUC64/128/256L3/4U
33.7.4 Interrupt Enable Register
Name: IER
Access Type: Write-only
Offset: 0x0C
Reset Value: 0x00000000
Writing a zero to a bit in this register has no effect.
Writing a one to a bit in this register will set the corresponding bit in IMR.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
- - TRMIS - - OVERRUN DREADYINT READYINT
76543210
--------
836
32142D–06/2013
ATUC64/128/256L3/4U
33.7.5 Interrupt Disable Register
Name: IDR
Access Type: Write-only
Offset: 0x10
Reset Value: 0x00000000
Writing a zero to a bit in this register has no effect.
Writing a one to a bit in this register will clear the corresponding bit in IMR.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
- - TRMIS - - OVERRUN DREADYINT READYINT
76543210
--------
837
32142D–06/2013
ATUC64/128/256L3/4U
33.7.6 Interrupt Mask Register
Name: IMR
Access Type: Read-only
Offset: 0x14
Reset Value: 0x00000000
0: The corresponding interrupt is disabled.
1: The corresponding interrupt is enabled.
A bit in this register is cleared when the corresponding bit in IDR is written to one.
A bit in this register is set when the corresponding bit in IER is written to one.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
- - TRMIS - - OVERRUN DREADYINT READYINT
76543210
--------
838
32142D–06/2013
ATUC64/128/256L3/4U
33.7.7 Receive Holding Register
Name: RHR
Access Type: Read-only
Offset: 0x18
Reset Value: 0x00000000
• RXDATA: Received Data
The last byte received.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
RXDATA
839
32142D–06/2013
ATUC64/128/256L3/4U
33.7.8 Transmit Holding Register
Name: THR
Access Type: Read/Write
Offset: 0x1C
Reset Value: 0x00000000
• TXDATA: Transmit Data
The data to send.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
TXDATA
840
32142D–06/2013
ATUC64/128/256L3/4U
33.7.9 Baud Rate Register
Name: BRR
Access Type: Read/Write
Offset: 0x20
Reset Value: 0x00000000
• BR: Baud Rate
The baud rate ( ) of the transmission, calculated using the following formula ( is the RC120M frequency):
BR should not be set to a value smaller than 32.
Writing a value to this field will update the baud rate of the transmission.
Reading this field will give the current baud rate of the transmission.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
BR[15:8]
76543210
BR[7:0]
f
br f
aw
f
br
8f
aw
BR = -----------
841
32142D–06/2013
ATUC64/128/256L3/4U
33.7.10 Version Register
Name: VERSION
Access Type: Read-only
Offset: 0x24
Reset Value: 0x00000200
• VERSION: Version Number
Version number of the module. No functionality associated.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
- - - - VERSION[11:8]
76543210
VERSION[7:0]
842
32142D–06/2013
ATUC64/128/256L3/4U
33.7.11 Clock Request Register
Name: CLKR
Access Type: Read/Write
Offset: 0x28
Reset Value: 0x00000000
• CLKEN: Clock Enable
0: The aWire clock is disabled.
1: The aWire clock is enabled.
Writing a zero to this bit will disable the aWire clock.
Writing a one to this bit will enable the aWire clock.
31 30 29 28 27 26 25 24
--------
23 22 21 20 19 18 17 16
--------
15 14 13 12 11 10 9 8
--------
76543210
- - - - - - - CLKEN
843
32142D–06/2013
ATUC64/128/256L3/4U
33.8 Module Configuration
The specific configuration for each aWire instance is listed in the following tables.The module
bus clocks listed here are connected to the system bus clocks. Please refer to the Power Manager
chapter for details.
Table 33-4. AW Clocks
Clock Name Description
CLK_AW Clock for the AW bus interface
Table 33-5. Register Reset Values
Register Reset Value
VERSION 0x00000230
844
32142D–06/2013
ATUC64/128/256L3/4U
34. Programming and Debugging
34.1 Overview
The ATUC64/128/256L3/4U supports programming and debugging through two interfaces,
JTAG or aWire. JTAG is an industry standard interface and allows boundary scan for PCB testing,
as well as daisy-chaining of multiple devices on the PCB. aWire is an Atmel proprietary
protocol which offers higher throughput and robust communication, and does not require application
pins to be reserved. Either interface provides access to the internal Service Access Bus
(SAB), which offers a bridge to the High Speed Bus, giving access to memories and peripherals
in the device. By using this bridge to the bus system, the flash and fuses can thus be programmed
by accessing the Flash Controller in the same manner as the CPU.
The SAB also provides access to the Nexus-compliant On-chip Debug (OCD) system in the
device, which gives the user non-intrusive run-time control of the program execution. Additionally,
trace information can be output on the Auxiliary (AUX) debug port or buffered in internal
RAM for later retrieval by JTAG or aWire.
34.2 Service Access Bus
The AVR32 architecture offers a common interface for access to On-chip Debug, programming,
and test functions. These are mapped on a common bus called the Service Access Bus (SAB),
which is linked to the JTAG and aWire port through a bus master module, which also handles
synchronization between the debugger and SAB clocks.
When accessing the SAB through the debugger there are no limitations on debugger frequency
compared to chip frequency, although there must be an active system clock in order for the SAB
accesses to complete. If the system clock is switched off in sleep mode, activity on the debugger
will restart the system clock automatically, without waking the device from sleep. Debuggers
may optimize the transfer rate by adjusting the frequency in relation to the system clock. This
ratio can be measured with debug protocol specific instructions.
The Service Access Bus uses 36 address bits to address memory or registers in any of the
slaves on the bus. The bus supports sized accesses of bytes (8 bits), halfwords (16 bits), or
words (32 bits). All accesses must be aligned to the size of the access, i.e. halfword accesses
must have the lowest address bit cleared, and word accesses must have the two lowest address
bits cleared.
34.2.1 SAB Address Map
The SAB gives the user access to the internal address space and other features through a 36
bits address space. The 4 MSBs identify the slave number, while the 32 LSBs are decoded
within the slave’s address space. The SAB slaves are shown in Table 34-1.
Table 34-1. SAB Slaves, Addresses and Descriptions
Slave Address [35:32] Description
Unallocated 0x0 Intentionally unallocated
OCD 0x1 OCD registers
HSB 0x4 HSB memory space, as seen by the CPU
845
32142D–06/2013
ATUC64/128/256L3/4U
34.2.2 SAB Security Restrictions
The Service Access bus can be restricted by internal security measures. A short description of
the security measures are found in the table below.
34.2.2.1 Security measure and control location
A security measure is a mechanism to either block or allow SAB access to a certain address or
address range. A security measure is enabled or disabled by one or several control signals. This
is called the control location for the security measure.
These security measures can be used to prevent an end user from reading out the code programmed
in the flash, for instance.
Below follows a more in depth description of what locations are accessible when the security
measures are active.
Note: 1. Second Word of the User Page, refer to the Fuses Settings section for details.
HSB 0x5 Alternative mapping for HSB space, for compatibility with
other 32-bit AVR devices.
Memory Service
Unit 0x6 Memory Service Unit registers
Reserved Other Unused
Table 34-1. SAB Slaves, Addresses and Descriptions
Slave Address [35:32] Description
Table 34-2. SAB Security Measures
Security Measure Control Location Description
Secure mode FLASHCDW
SECURE bits set
Allocates a portion of the flash for secure code. This code
cannot be read or debugged. The User page is also locked.
Security bit FLASHCDW
security bit set
Programming and debugging not possible, very restricted
access.
User code
programming
FLASHCDW
UPROT + security
bit set
Restricts all access except parts of the flash and the flash
controller for programming user code. Debugging is not
possible unless an OS running from the secure part of the
flash supports it.
Table 34-3. Secure Mode SAB Restrictions
Name Address Start Address End Access
Secure flash area 0x580000000 0x580000000 +
(USERPAGE[15:0] << 10) Blocked
Secure RAM area 0x500000000 0x500000000 +
(USERPAGE[31:16] << 10) Blocked
User page 0x580800000 0x581000000 Read
Other accesses - - As normal
846
32142D–06/2013
ATUC64/128/256L3/4U
Table 34-4. Security Bit SAB Restrictions
Name Address start Address end Access
OCD DCCPU,
OCD DCEMU,
OCD DCSR
0x100000110 0x100000118 Read/Write
User page 0x580800000 0x581000000 Read
Other accesses - - Blocked
Table 34-5. User Code Programming SAB Restrictions
Name Address start Address end Access
OCD DCCPU,
OCD DCEMU,
OCD DCSR
0x100000110 0x100000118 Read/Write
User page 0x580800000 0x581000000 Read
FLASHCDW PB
interface 0x5FFFE0000 0x5FFFE0400 Read/Write
FLASH pages
outside
BOOTPROT
0x580000000 +
BOOTPROT size 0x580000000 + Flash size Read/Write
Other accesses - - Blocked
847
32142D–06/2013
ATUC64/128/256L3/4U
34.3 On-Chip Debug
Rev: 2.1.2.0
34.3.1 Features
• Debug interface in compliance with IEEE-ISTO 5001-2003 (Nexus 2.0) Class 2+
• JTAG or aWire access to all on-chip debug functions
• Advanced Program, Data, Ownership, and Watchpoint trace supported
• NanoTrace aWire- or JTAG-based trace access
• Auxiliary port for high-speed trace information
• Hardware support for 6 Program and 2 Data breakpoints
• Unlimited number of software breakpoints supported
• Automatic CRC check of memory regions
34.3.2 Overview
Debugging on the ATUC64/128/256L3/4U is facilitated by a powerful On-Chip Debug (OCD)
system. The user accesses this through an external debug tool which connects to the JTAG or
aWire port and the Auxiliary (AUX) port if implemented. The AUX port is primarily used for trace
functions, and an aWire- or JTAG-based debugger is sufficient for basic debugging.
The debug system is based on the Nexus 2.0 standard, class 2+, which includes:
• Basic run-time control
• Program breakpoints
• Data breakpoints
• Program trace
• Ownership trace
• Data trace
In addition to the mandatory Nexus debug features, the ATUC64/128/256L3/4U implements
several useful OCD features, such as:
• Debug Communication Channel between CPU and debugger
• Run-time PC monitoring
• CRC checking
• NanoTrace
• Software Quality Assurance (SQA) support
The OCD features are controlled by OCD registers, which can be accessed by the debugger, for
instance when the NEXUS_ACCESS JTAG instruction is loaded. The CPU can also access
OCD registers directly using mtdr/mfdr instructions in any privileged mode. The OCD registers
are implemented based on the recommendations in the Nexus 2.0 standard, and are detailed in
the AVR32UC Technical Reference Manual.
34.3.3 I/O Lines Description
The OCD AUX trace port contains a number of pins, as shown in Table 34-6 on page 848.
These are multiplexed with I/O Controller lines, and must explicitly be enabled by writing OCD
registers before the debug session starts. The AUX port is mapped to two different locations,
848
32142D–06/2013
ATUC64/128/256L3/4U
selectable by OCD Registers, minimizing the chance that the AUX port will need to be shared
with an application.
34.3.4 Product Dependencies
In order to use this module, other parts of the system must be configured correctly, as described
below.
34.3.4.1 Power Management
The OCD clock operates independently of the CPU clock. If enabled in the Power Manager, the
OCD clock (CLK_OCD) will continue running even if the CPU enters a sleep mode that disables
the CPU clock.
34.3.4.2 Clocks
The OCD has a clock (CLK_OCD) running synchronously with the CPU clock. This clock is generated
by the Power Manager. The clock is enabled at reset, and can be disabled by writing to
the Power Manager.
34.3.4.3 Interrupt
The OCD system interrupt request lines are connected to the interrupt controller. Using the OCD
interrupts requires the interrupt controller to be programmed first.
Table 34-6. Auxiliary Port Signals
Pin Name Pin Description Direction Active Level Type
MCKO Trace data output clock Output Digital
MDO[5:0] Trace data output Output Digital
MSEO[1:0] Trace frame control Output Digital
EVTI_N Event In Input Low Digital
EVTO_N Event Out Output Low Digital
849
32142D–06/2013
ATUC64/128/256L3/4U
34.3.5 Block Diagram
Figure 34-1. On-Chip Debug Block Diagram
34.3.6 SAB-based Debug Features
A debugger can control all OCD features by writing OCD registers over the SAB interface. Many
of these do not depend on output on the AUX port, allowing an aWire- or JTAG-based debugger
to be used.
A JTAG-based debugger should connect to the device through a standard 10-pin IDC connector
as described in the AVR32UC Technical Reference Manual.
An aWire-based debugger should connect to the device through the RESET_N pin.
On-Chip Debug
JTAG
Debug PC
Debug
Instruction
CPU
Breakpoints
Program
Trace Data Trace Ownership
Trace
Transmit Queue Watchpoints
AUX
JTAG
Internal
SRAM
Service Access Bus
Memory
Service
Unit
HSB Bus Matrix Memories and
peripherals
aWire
aWire
850
32142D–06/2013
ATUC64/128/256L3/4U
Figure 34-2. JTAG-based Debugger
Figure 34-3. aWire-based Debugger
34.3.6.1 Debug Communication Channel
The Debug Communication Channel (DCC) consists of a pair OCD registers with associated
handshake logic, accessible to both CPU and debugger. The registers can be used to exchange
data between the CPU and the debugmaster, both runtime as well as in debug mode.
32-bit AVR
JTAG-based
debug tool
PC
JTAG
10-pin IDC
32-bit AVR
aWire-based
debug tool
PC
aWire
851
32142D–06/2013
ATUC64/128/256L3/4U
The OCD system can generate an interrupt to the CPU when DCCPU is read and when DCEMU
is written. This enables the user to build a custum debug protocol using only these registers. The
DCCPU and DCEMU registers are available even when the security bit in the flash is active.
For more information refer to the AVR32UC Technical Reference Manual.
34.3.6.2 Breakpoints
One of the most fundamental debug features is the ability to halt the CPU, to examine registers
and the state of the system. This is accomplished by breakpoints, of which many types are
available:
• Unconditional breakpoints are set by writing OCD registers by the debugger, halting the CPU
immediately.
• Program breakpoints halt the CPU when a specific address in the program is executed.
• Data breakpoints halt the CPU when a specific memory address is read or written, allowing
variables to be watched.
• Software breakpoints halt the CPU when the breakpoint instruction is executed.
When a breakpoint triggers, the CPU enters debug mode, and the D bit in the status register is
set. This is a privileged mode with dedicated return address and return status registers. All privileged
instructions are permitted. Debug mode can be entered as either OCD Mode, running
instructions from the debugger, or Monitor Mode, running instructions from program memory.
34.3.6.3 OCD Mode
When a breakpoint triggers, the CPU enters OCD mode, and instructions are fetched from the
Debug Instruction OCD register. Each time this register is written by the debugger, the instruction
is executed, allowing the debugger to execute CPU instructions directly. The debug master
can e.g. read out the register file by issuing mtdr instructions to the CPU, writing each register to
the Debug Communication Channel OCD registers.
34.3.6.4 Monitor Mode
Since the OCD registers are directly accessible by the CPU, it is possible to build a softwarebased
debugger that runs on the CPU itself. Setting the Monitor Mode bit in the Development
Control register causes the CPU to enter Monitor Mode instead of OCD mode when a breakpoint
triggers. Monitor Mode is similar to OCD mode, except that instructions are fetched from the
debug exception vector in regular program memory, instead of issued by the debug master.
34.3.6.5 Program Counter Monitoring
Normally, the CPU would need to be halted for a debugger to examine the current PC value.
However, the ATUC64/128/256L3/4U also proves a Debug Program Counter OCD register,
where the debugger can continuously read the current PC without affecting the CPU. This allows
the debugger to generate a simple statistic of the time spent in various areas of the code, easing
code optimization.
34.3.7 Memory Service Unit
The Memory Service Unit (MSU) is a block dedicated to test and debug functionality. It is controlled
through a dedicated set of registers addressed through the Service Access Bus.
852
32142D–06/2013
ATUC64/128/256L3/4U
34.3.7.1 Cyclic Redundancy Check (CRC)
The MSU can be used to automatically calculate the CRC of a block of data in memory. The
MSU will then read out each word in the specified memory block and report the CRC32-value in
an MSU register.
34.3.7.2 NanoTrace
The MSU additionally supports NanoTrace. This is a 32-bit AVR-specific feature, in which trace
data is output to memory instead of the AUX port. This allows the trace data to be extracted by
the debugger through the SAB, enabling trace features for aWire- or JTAG-based debuggers.
The user must write MSU registers to configure the address and size of the memory block to be
used for NanoTrace. The NanoTrace buffer can be anywhere in the physical address range,
including internal and external RAM, through an EBI, if present. This area may not be used by
the application running on the CPU.
34.3.8 AUX-based Debug Features
Utilizing the Auxiliary (AUX) port gives access to a wide range of advanced debug features. Of
prime importance are the trace features, which allow an external debugger to receive continuous
information on the program execution in the CPU. Additionally, Event In and Event Out pins
allow external events to be correlated with the program flow.
Debug tools utilizing the AUX port should connect to the device through a Nexus-compliant Mictor-38
connector, as described in the AVR32UC Technical Reference manual. This connector
includes the JTAG signals and the RESET_N pin, giving full access to the programming and
debug features in the device.
853
32142D–06/2013
ATUC64/128/256L3/4U
Figure 34-4. AUX+JTAG Based Debugger
34.3.8.1 Trace Operation
Trace features are enabled by writing OCD registers by the debugger. The OCD extracts the
trace information from the CPU, compresses this information and formats it into variable-length
messages according to the Nexus standard. The messages are buffered in a 16-frame transmit
queue, and are output on the AUX port one frame at a time.
The trace features can be configured to be very selective, to reduce the bandwidth on the AUX
port. In case the transmit queue overflows, error messages are produced to indicate loss of
data. The transmit queue module can optionally be configured to halt the CPU when an overflow
occurs, to prevent the loss of messages, at the expense of longer run-time for the program.
34.3.8.2 Program Trace
Program trace allows the debugger to continuously monitor the program execution in the CPU.
Program trace messages are generated for every branch in the program, and contains compressed
information, which allows the debugger to correlate the message with the source code
to identify the branch instruction and target address.
34.3.8.3 Data Trace
Data trace outputs a message every time a specific location is read or written. The message
contains information about the type (read/write) and size of the access, as well as the address
and data of the accessed location. The ATUC64/128/256L3/4U contains two data trace chanAVR32
AUX+JTAG
debu g tool
JTAG AUX
h ig h s p e e d
M ic to r3 8
T ra ce b u ffe r
P C
854
32142D–06/2013
ATUC64/128/256L3/4U
nels, each of which are controlled by a pair of OCD registers which determine the range of
addresses (or single address) which should produce data trace messages.
34.3.8.4 Ownership Trace
Program and data trace operate on virtual addresses. In cases where an operating system runs
several processes in overlapping virtual memory segments, the Ownership Trace feature can be
used to identify the process switch. When the O/S activates a process, it will write the process ID
number to an OCD register, which produces an Ownership Trace Message, allowing the debugger
to switch context for the subsequent program and data trace messages. As the use of this
feature depends on the software running on the CPU, it can also be used to extract other types
of information from the system.
34.3.8.5 Watchpoint Messages
The breakpoint modules normally used to generate program and data breakpoints can also be
used to generate Watchpoint messages, allowing a debugger to monitor program and data
events without halting the CPU. Watchpoints can be enabled independently of breakpoints, so a
breakpoint module can optionally halt the CPU when the trigger condition occurs. Data trace
modules can also be configured to produce watchpoint messages instead of regular data trace
messages.
34.3.8.6 Event In and Event Out Pins
The AUX port also contains an Event In pin (EVTI_N) and an Event Out pin (EVTO_N). EVTI_N
can be used to trigger a breakpoint when an external event occurs. It can also be used to trigger
specific program and data trace synchronization messages, allowing an external event to be
correlated to the program flow.
When the CPU enters debug mode, a Debug Status message is transmitted on the trace port.
All trace messages can be timestamped when they are received by the debug tool. However,
due to the latency of the transmit queue buffering, the timestamp will not be 100% accurate. To
improve this, EVTO_N can toggle every time a message is inserted into the transmit queue,
allowing trace messages to be timestamped precisely. EVTO_N can also toggle when a breakpoint
module triggers, or when the CPU enters debug mode, for any reason. This can be used to
measure precisely when the respective internal event occurs.
34.3.8.7 Software Quality Analysis (SQA)
Software Quality Analysis (SQA) deals with two important issues regarding embedded software
development. Code coverage involves identifying untested parts of the embedded code, to
improve test procedures and thus the quality of the released software. Performance analysis
allows the developer to precisely quantify the time spent in various parts of the code, allowing
bottlenecks to be identified and optimized.
Program trace must be used to accomplish these tasks without instrumenting (altering) the code
to be examined. However, traditional program trace cannot reconstruct the current PC value
without correlating the trace information with the source code, which cannot be done on-the-fly.
This limits program trace to a relatively short time segment, determined by the size of the trace
buffer in the debug tool.
The OCD system in ATUC64/128/256L3/4U extends program trace with SQA capabilities, allowing
the debug tool to reconstruct the PC value on-the-fly. Code coverage and performance
analysis can thus be reported for an unlimited execution sequence.
855
32142D–06/2013
ATUC64/128/256L3/4U
34.4 JTAG and Boundary-scan (JTAG)
Rev: 2.2.2.4
34.4.1 Features
• IEEE1149.1 compliant JTAG Interface
• Boundary-scan Chain for board-level testing
• Direct memory access and programming capabilities through JTAG Interface
34.4.2 Overview
The JTAG Interface offers a four pin programming and debug solution, including boundary-scan
support for board-level testing.
Figure 34-5 on page 856 shows how the JTAG is connected in an 32-bit AVR device. The TAP
Controller is a state machine controlled by the TCK and TMS signals. The TAP Controller
selects either the JTAG Instruction Register or one of several Data Registers as the scan chain
(shift register) between the TDI-input and TDO-output.
The Instruction Register holds JTAG instructions controlling the behavior of a Data Register. The
Device Identification Register, Bypass Register, and the boundary-scan chain are the Data Registers
used for board-level testing. The Reset Register can be used to keep the device reset
during test or programming.
The Service Access Bus (SAB) interface contains address and data registers for the Service
Access Bus, which gives access to On-Chip Debug, programming, and other functions in the
device. The SAB offers several modes of access to the address and data registers, as described
in Section 34.4.11.
Section 34.5 lists the supported JTAG instructions, with references to the description in this
document.
856
32142D–06/2013
ATUC64/128/256L3/4U
34.4.3 Block Diagram
Figure 34-5. JTAG and Boundary-scan Access
34.4.4 I/O Lines Description
34.4.5 Product Dependencies
In order to use this module, other parts of the system must be configured correctly, as described
below.
Table 34-7. I/O Line Description
Pin Name Pin Description Type Active Level
RESET_N External reset pin. Used when enabling and disabling the JTAG. Input Low
TCK Test Clock Input. Fully asynchronous to system clock frequency. Input
TMS Test Mode Select, sampled on rising TCK. Input
TDI Test Data In, sampled on rising TCK. Input
TDO Test Data Out, driven on falling TCK. Output
32-bit AVR device
JTAG data registers
TAP
Controller
Instruction Register
Device Identification
Register
By-pass Register
Reset Register
Service Access Bus
interface
Boundary Scan Chain
Pins and analog blocks
Data register
scan enable
JTAG Pins
Boundary scan enable
2nd JTAG
device
JTAG master
TDO TDI
Part specific registers
...
TMS TDO TDI
TMS
TCK
TCK
Instruction register
scan enable
SAB Internal I/O
lines
JTAG
TMS
TDI
TDO
TCK
857
32142D–06/2013
ATUC64/128/256L3/4U
34.4.5.1 I/O Lines
The TMS, TDI, TDO, and TCK pins are multiplexed with I/O lines. When the JTAG is used the
associated pins must be enabled. To enable the JTAG pins, refer to Section 34.4.7.
While using the multiplexed JTAG lines all normal peripheral activity on these lines is disabled.
The user must make sure that no external peripheral is blocking the JTAG lines while
debugging.
34.4.5.2 Power Management
When an instruction that accesses the SAB is loaded in the instruction register, before entering
a sleep mode, the system clocks are not switched off to allow debugging in sleep modes. This
can lead to a program behaving differently when debugging.
34.4.5.3 Clocks
The JTAG Interface uses the external TCK pin as clock source. This clock must be provided by
the JTAG master.
Instructions that use the SAB bus requires the internal main clock to be running.
34.4.6 JTAG Interface
The JTAG Interface is accessed through the dedicated JTAG pins shown in Table 34-7 on page
856. The TMS control line navigates the TAP controller, as shown in Figure 34-6 on page 858.
The TAP controller manages the serial access to the JTAG Instruction and Data registers. Data
is scanned into the selected instruction or data register on TDI, and out of the register on TDO,
in the Shift-IR and Shift-DR states, respectively. The LSB is shifted in and out first. TDO is highZ
in other states than Shift-IR and Shift-DR.
The device implements a 5-bit Instruction Register (IR). A number of public JTAG instructions
defined by the JTAG standard are supported, as described in Section 34.5.2, as well as a number
of 32-bit AVR-specific private JTAG instructions described in Section 34.5.3. Each
instruction selects a specific data register for the Shift-DR path, as described for each
instruction.
858
32142D–06/2013
ATUC64/128/256L3/4U
Figure 34-6. TAP Controller State Diagram
Test-LogicReset
Run-Test/
Idle
Select-DR
Scan
Select-IR
Scan
Capture-DR Capture-IR
Shift-DR Shift-IR
Exit1-DR Exit1-IR
Pause-DR Pause-IR
Exit2-DR Exit2-IR
Update-DR Update-IR
0
1 1
1
0
0
1
0
1
1
0
0
1
0
1
1
1
0
1 1
0 0
1 1
0
1
0
0 0
0
0
1
859
32142D–06/2013
ATUC64/128/256L3/4U
34.4.7 How to Initialize the Module
To enable the JTAG pins the TCK pin must be held low while the RESET_N pin is released.
After enabling the JTAG interface the halt bit is set automatically to prevent the system from running
code after the interface is enabled. To make the CPU run again set halt to zero using the
HALT command..
JTAG operation when RESET_N is pulled low is not possible.
Independent of the initial state of the TAP Controller, the Test-Logic-Reset state can always be
entered by holding TMS high for 5 TCK clock periods. This sequence should always be applied
at the start of a JTAG session and after enabling the JTAG pins to bring the TAP Controller into
a defined state before applying JTAG commands. Applying a 0 on TMS for 1 TCK period brings
the TAP Controller to the Run-Test/Idle state, which is the starting point for JTAG operations.
34.4.8 How to disable the module
To disable the JTAG pins the TCK pin must be held high while RESET_N pin is released.
34.4.9 Typical Sequence
Assuming Run-Test/Idle is the present state, a typical scenario for using the JTAG Interface
follows.
34.4.9.1 Scanning in JTAG Instruction
At the TMS input, apply the sequence 1, 1, 0, 0 at the rising edges of TCK to enter the Shift
Instruction Register (Shift-IR) state. While in this state, shift the 5 bits of the JTAG instructions
into the JTAG instruction register from the TDI input at the rising edge of TCK. During shifting,
the JTAG outputs status bits on TDO, refer to Section 34.5 for a description of these. The TMS
input must be held low during input of the 4 LSBs in order to remain in the Shift-IR state. The
JTAG Instruction selects a particular Data Register as path between TDI and TDO and controls
the circuitry surrounding the selected Data Register.
Apply the TMS sequence 1, 1, 0 to re-enter the Run-Test/Idle state. The instruction is latched
onto the parallel output from the shift register path in the Update-IR state. The Exit-IR, Pause-IR,
and Exit2-IR states are only used for navigating the state machine.
Figure 34-7. Scanning in JTAG Instruction
34.4.9.2 Scanning in/out Data
At the TMS input, apply the sequence 1, 0, 0 at the rising edges of TCK to enter the Shift Data
Register (Shift-DR) state. While in this state, upload the selected Data Register (selected by the
present JTAG instruction in the JTAG Instruction Register) from the TDI input at the rising edge
TCK
TAP State TLR RTI SelDR SelIR CapIR ShIR Ex1IR UpdIR RTI
TMS
TDI Instruction
TDO ImplDefined
860
32142D–06/2013
ATUC64/128/256L3/4U
of TCK. In order to remain in the Shift-DR state, the TMS input must be held low. While the Data
Register is shifted in from the TDI pin, the parallel inputs to the Data Register captured in the
Capture-DR state is shifted out on the TDO pin.
Apply the TMS sequence 1, 1, 0 to re-enter the Run-Test/Idle state. If the selected Data Register
has a latched parallel-output, the latching takes place in the Update-DR state. The Exit-DR,
Pause-DR, and Exit2-DR states are only used for navigating the state machine.
As shown in the state diagram, the Run-Test/Idle state need not be entered between selecting
JTAG instruction and using Data Registers.
34.4.10 Boundary-scan
The boundary-scan chain has the capability of driving and observing the logic levels on the digital
I/O pins, as well as the boundary between digital and analog logic for analog circuitry having
off-chip connections. At system level, all ICs having JTAG capabilities are connected serially by
the TDI/TDO signals to form a long shift register. An external controller sets up the devices to
drive values at their output pins, and observe the input values received from other devices. The
controller compares the received data with the expected result. In this way, boundary-scan provides
a mechanism for testing interconnections and integrity of components on Printed Circuits
Boards by using the 4 TAP signals only.
The four IEEE 1149.1 defined mandatory JTAG instructions IDCODE, BYPASS, SAMPLE/PRELOAD,
and EXTEST can be used for testing the Printed Circuit Board. Initial scanning of the
data register path will show the ID-code of the device, since IDCODE is the default JTAG
instruction. It may be desirable to have the 32-bit AVR device in reset during test mode. If not
reset, inputs to the device may be determined by the scan operations, and the internal software
may be in an undetermined state when exiting the test mode. If needed, the BYPASS instruction
can be issued to make the shortest possible scan chain through the device. The device can be
set in the reset state either by pulling the external RESETn pin low, or issuing the AVR_RESET
instruction with appropriate setting of the Reset Data Register.
The EXTEST instruction is used for sampling external pins and loading output pins with data.
The data from the output latch will be driven out on the pins as soon as the EXTEST instruction
is loaded into the JTAG IR-register. Therefore, the SAMPLE/PRELOAD should also be used for
setting initial values to the scan ring, to avoid damaging the board when issuing the EXTEST
instruction for the first time. SAMPLE/PRELOAD can also be used for taking a snapshot of the
external pins during normal operation of the part.
When using the JTAG Interface for boundary-scan, the JTAG TCK clock is independent of the
internal chip clock. The internal chip clock is not required to run during boundary-scan
operations.
NOTE: For pins connected to 5V lines care should be taken to not drive the pins to a logic one
using boundary-scan, as this will create a current flowing from the 3,3V driver to the 5V pull-up
on the line. Optionally a series resistor can be added between the line and the pin to reduce the
current.
Details about the boundary-scan chain can be found in the BSDL file for the device. This can be
found on the Atmel website.
34.4.11 Service Access Bus
The AVR32 architecture offers a common interface for access to On-Chip Debug, programming,
and test functions. These are mapped on a common bus called the Service Access Bus (SAB),
861
32142D–06/2013
ATUC64/128/256L3/4U
which is linked to the JTAG through a bus master module, which also handles synchronization
between the TCK and SAB clocks.
For more information about the SAB and a list of SAB slaves see the Service Access Bus
chapter.
34.4.11.1 SAB Address Mode
The MEMORY_SIZED_ACCESS instruction allows a sized read or write to any 36-bit address
on the bus. MEMORY_WORD_ACCESS is a shorthand instruction for 32-bit accesses to any
36-bit address, while the NEXUS_ACCESS instruction is a Nexus-compliant shorthand instruction
for accessing the 32-bit OCD registers in the 7-bit address space reserved for these. These
instructions require two passes through the Shift-DR TAP state: one for the address and control
information, and one for data.
34.4.11.2 Block Transfer
To increase the transfer rate, consecutive memory accesses can be accomplished by the
MEMORY_BLOCK_ACCESS instruction, which only requires a single pass through Shift-DR for
data transfer only. The address is automatically incremented according to the size of the last
SAB transfer.
34.4.11.3 Canceling a SAB Access
It is possible to abort an ongoing SAB access by the CANCEL_ACCESS instruction, to avoid
hanging the bus due to an extremely slow slave.
34.4.11.4 Busy Reporting
As the time taken to perform an access may vary depending on system activity and current chip
frequency, all the SAB access JTAG instructions can return a busy indicator. This indicates
whether a delay needs to be inserted, or an operation needs to be repeated in order to be successful.
If a new access is requested while the SAB is busy, the request is ignored.
The SAB becomes busy when:
• Entering Update-DR in the address phase of any read operation, e.g., after scanning in a
NEXUS_ACCESS address with the read bit set.
• Entering Update-DR in the data phase of any write operation, e.g., after scanning in data for
a NEXUS_ACCESS write.
• Entering Update-DR during a MEMORY_BLOCK_ACCESS.
• Entering Update-DR after scanning in a counter value for SYNC.
• Entering Update-IR after scanning in a MEMORY_BLOCK_ACCESS if the previous access
was a read and data was scanned after scanning the address.
The SAB becomes ready again when:
• A read or write operation completes.
• A SYNC countdown completed.
• A operation is cancelled by the CANCEL_ACCESS instruction.
What to do if the busy bit is set:
• During Shift-IR: The new instruction is selected, but the previous operation has not yet
completed and will continue (unless the new instruction is CANCEL_ACCESS). You may
862
32142D–06/2013
ATUC64/128/256L3/4U
continue shifting the same instruction until the busy bit clears, or start shifting data. If shifting
data, you must be prepared that the data shift may also report busy.
• During Shift-DR of an address: The new address is ignored. The SAB stays in address mode,
so no data must be shifted. Repeat the address until the busy bit clears.
• During Shift-DR of read data: The read data is invalid. The SAB stays in data mode. Repeat
scanning until the busy bit clears.
• During Shift-DR of write data: The write data is ignored. The SAB stays in data mode. Repeat
scanning until the busy bit clears.
34.4.11.5 Error Reporting
The Service Access Bus may not be able to complete all accesses as requested. This may be
because the address is invalid, the addressed area is read-only or cannot handle byte/halfword
accesses, or because the chip is set in a protected mode where only limited accesses are
allowed.
The error bit is updated when an access completes, and is cleared when a new access starts.
What to do if the error bit is set:
• During Shift-IR: The new instruction is selected. The last operation performed using the old
instruction did not complete successfully.
• During Shift-DR of an address: The previous operation failed. The new address is accepted.
If the read bit is set, a read operation is started.
• During Shift-DR of read data: The read operation failed, and the read data is invalid.
• During Shift-DR of write data: The previous write operation failed. The new data is accepted
and a write operation started. This should only occur during block writes or stream writes. No
error can occur between scanning a write address and the following write data.
• While polling with CANCEL_ACCESS: The previous access was cancelled. It may or may not
have actually completed.
• After power-up: The error bit is set after power up, but there has been no previous SAB
instruction so this error can be discarded.
34.4.11.6 Protected Reporting
A protected status may be reported during Shift-IR or Shift-DR. This indicates that the security
bit in the Flash Controller is set and that the chip is locked for access, according to Section
34.5.1.
The protected state is reported when:
• The Flash Controller is under reset. This can be due to the AVR_RESET command or the
RESET_N line.
• The Flash Controller has not read the security bit from the flash yet (This will take a a few
ms). Happens after the Flash Controller reset has been released.
• The security bit in the Flash Controller is set.
What to do if the protected bit is set:
• Release all active AVR_RESET domains, if any.
• Release the RESET_N line.
• Wait a few ms for the security bit to clear. It can be set temporarily due to a reset.
863
32142D–06/2013
ATUC64/128/256L3/4U
• Perform a CHIP_ERASE to clear the security bit. NOTE: This will erase all the contents of the
non-volatile memory.
34.5 JTAG Instruction Summary
The implemented JTAG instructions in the 32-bit AVR are shown in the table below.
34.5.1 Security Restrictions
When the security fuse in the Flash is programmed, the following JTAG instructions are
restricted:
• NEXUS_ACCESS
• MEMORY_WORD_ACCESS
• MEMORY_BLOCK_ACCESS
• MEMORY_SIZED_ACCESS
For description of what memory locations remain accessible, please refer to the SAB address
map.
Full access to these instructions is re-enabled when the security fuse is erased by the
CHIP_ERASE JTAG instruction.
Table 34-8. JTAG Instruction Summary
Instruction
OPCODE Instruction Description
0x01 IDCODE Select the 32-bit Device Identification register as data register.
0x02 SAMPLE_PRELOAD Take a snapshot of external pin values without affecting system operation.
0x03 EXTEST Select boundary-scan chain as data register for testing circuitry external to
the device.
0x04 INTEST Select boundary-scan chain for internal testing of the device.
0x06 CLAMP Bypass device through Bypass register, while driving outputs from boundaryscan
register.
0x0C AVR_RESET Apply or remove a static reset to the device
0x0F CHIP_ERASE Erase the device
0x10 NEXUS_ACCESS Select the SAB Address and Data registers as data register for the TAP. The
registers are accessed in Nexus mode.
0x11 MEMORY_WORD_ACCESS Select the SAB Address and Data registers as data register for the TAP.
0x12 MEMORY_BLOCK_ACCESS Select the SAB Data register as data register for the TAP. The address is
auto-incremented.
0x13 CANCEL_ACCESS Cancel an ongoing Nexus or Memory access.
0x14 MEMORY_SERVICE Select the SAB Address and Data registers as data register for the TAP. The
registers are accessed in Memory Service mode.
0x15 MEMORY_SIZED_ACCESS Select the SAB Address and Data registers as data register for the TAP.
0x17 SYNC Synchronization counter
0x1C HALT Halt the CPU for safe programming.
0x1F BYPASS Bypass this device through the bypass register.
Others N/A Acts as BYPASS
864
32142D–06/2013
ATUC64/128/256L3/4U
Note that the security bit will read as programmed and block these instructions also if the Flash
Controller is statically reset.
Other security mechanisms can also restrict these functions. If such mechanisms are present
they are listed in the SAB address map section.
34.5.1.1 Notation
Table 34-10 on page 864 shows bit patterns to be shifted in a format like "peb01". Each character
corresponds to one bit, and eight bits are grouped together for readability. The least
significantbit is always shifted first, and the most significant bit shifted last. The symbols used
are shown in Table 34-9.
In many cases, it is not required to shift all bits through the data register. Bit patterns are shown
using the full width of the shift register, but the suggested or required bits are emphasized using
bold text. I.e. given the pattern "aaaaaaar xxxxxxxx xxxxxxxx xxxxxxxx xx", the shift register is
34 bits, but the test or debug unit may choose to shift only 8 bits "aaaaaaar".
The following describes how to interpret the fields in the instruction description tables:
Table 34-9. Symbol Description
Symbol Description
0 Constant low value - always reads as zero.
1 Constant high value - always reads as one.
a An address bit - always scanned with the least significant bit first
b A busy bit. Reads as one if the SAB was busy, or zero if it was not. See Section 34.4.11.4 for
details on how the busy reporting works.
d A data bit - always scanned with the least significant bit first.
e An error bit. Reads as one if an error occurred, or zero if not. See Section 34.4.11.5 for
details on how the error reporting works.
p
The chip protected bit. Some devices may be set in a protected state where access to chip
internals are severely restricted. See the documentation for the specific device for details.
On devices without this possibility, this bit always reads as zero.
r A direction bit. Set to one to request a read, set to zero to request a write.
s A size bit. The size encoding is described where used.
x A don’t care bit. Any value can be shifted in, and output data should be ignored.
Table 34-10. Instruction Description
Instruction Description
IR input value
Shows the bit pattern to shift into IR in the Shift-IR state in order to select this
instruction. The pattern is show both in binary and in hexadecimal form for
convenience.
Example: 10000 (0x10)
IR output value
Shows the bit pattern shifted out of IR in the Shift-IR state when this instruction is
active.
Example: peb01
865
32142D–06/2013
ATUC64/128/256L3/4U
34.5.2 Public JTAG Instructions
The JTAG standard defines a number of public JTAG instructions. These instructions are
described in the sections below.
34.5.2.1 IDCODE
This instruction selects the 32 bit Device Identification register (DID) as Data Register. The DID
register consists of a version number, a device number, and the manufacturer code chosen by
JEDEC. This is the default instruction after a JTAG reset. Details about the DID register can be
found in the module configuration section at the end of this chapter.
Starting in Run-Test/Idle, the Device Identification register is accessed in the following way:
1. Select the IR Scan path.
2. In Capture-IR: The IR output value is latched into the shift register.
3. In Shift-IR: The instruction register is shifted by the TCK input.
4. Return to Run-Test/Idle.
5. Select the DR Scan path.
6. In Capture-DR: The IDCODE value is latched into the shift register.
7. In Shift-DR: The IDCODE scan chain is shifted by the TCK input.
8. Return to Run-Test/Idle.
34.5.2.2 SAMPLE_PRELOAD
This instruction takes a snap-shot of the input/output pins without affecting the system operation,
and pre-loading the scan chain without updating the DR-latch. The boundary-scan chain is
selected as Data Register.
Starting in Run-Test/Idle, the Device Identification register is accessed in the following way:
DR Size Shows the number of bits in the data register chain when this instruction is active.
Example: 34 bits
DR input value
Shows which bit pattern to shift into the data register in the Shift-DR state when this
instruction is active. Multiple such lines may exist, e.g., to distinguish between
reads and writes.
Example: aaaaaaar xxxxxxxx xxxxxxxx xxxxxxxx xx
DR output value
Shows the bit pattern shifted out of the data register in the Shift-DR state when this
instruction is active. Multiple such lines may exist, e.g., to distinguish between
reads and writes.
Example: xx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxeb
Table 34-10. Instruction Description (Continued)
Instruction Description
Table 34-11. IDCODE Details
Instructions Details
IR input value 00001 (0x01)
IR output value p0001
DR Size 32
DR input value xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
DR output value Device Identification Register
866
32142D–06/2013
ATUC64/128/256L3/4U
1. Select the IR Scan path.
2. In Capture-IR: The IR output value is latched into the shift register.
3. In Shift-IR: The instruction register is shifted by the TCK input.
4. Return to Run-Test/Idle.
5. Select the DR Scan path.
6. In Capture-DR: The Data on the external pins are sampled into the boundary-scan
chain.
7. In Shift-DR: The boundary-scan chain is shifted by the TCK input.
8. Return to Run-Test/Idle.
34.5.2.3 EXTEST
This instruction selects the boundary-scan chain as Data Register for testing circuitry external to
the 32-bit AVR package. The contents of the latched outputs of the boundary-scan chain is
driven out as soon as the JTAG IR-register is loaded with the EXTEST instruction.
Starting in Run-Test/Idle, the EXTEST instruction is accessed the following way:
1. Select the IR Scan path.
2. In Capture-IR: The IR output value is latched into the shift register.
3. In Shift-IR: The instruction register is shifted by the TCK input.
4. In Update-IR: The data from the boundary-scan chain is applied to the output pins.
5. Return to Run-Test/Idle.
6. Select the DR Scan path.
7. In Capture-DR: The data on the external pins is sampled into the boundary-scan chain.
8. In Shift-DR: The boundary-scan chain is shifted by the TCK input.
9. In Update-DR: The data from the scan chain is applied to the output pins.
10. Return to Run-Test/Idle.
Table 34-12. SAMPLE_PRELOAD Details
Instructions Details
IR input value 00010 (0x02)
IR output value p0001
DR Size Depending on boundary-scan chain, see BSDL-file.
DR input value Depending on boundary-scan chain, see BSDL-file.
DR output value Depending on boundary-scan chain, see BSDL-file.
Table 34-13. EXTEST Details
Instructions Details
IR input value 00011 (0x03)
IR output value p0001
DR Size Depending on boundary-scan chain, see BSDL-file.
DR input value Depending on boundary-scan chain, see BSDL-file.
DR output value Depending on boundary-scan chain, see BSDL-file.
867
32142D–06/2013
ATUC64/128/256L3/4U
34.5.2.4 INTEST
This instruction selects the boundary-scan chain as Data Register for testing internal logic in the
device. The logic inputs are determined by the boundary-scan chain, and the logic outputs are
captured by the boundary-scan chain. The device output pins are driven from the boundary-scan
chain.
Starting in Run-Test/Idle, the INTEST instruction is accessed the following way:
1. Select the IR Scan path.
2. In Capture-IR: The IR output value is latched into the shift register.
3. In Shift-IR: The instruction register is shifted by the TCK input.
4. In Update-IR: The data from the boundary-scan chain is applied to the internal logic
inputs.
5. Return to Run-Test/Idle.
6. Select the DR Scan path.
7. In Capture-DR: The data on the internal logic is sampled into the boundary-scan chain.
8. In Shift-DR: The boundary-scan chain is shifted by the TCK input.
9. In Update-DR: The data from the boundary-scan chain is applied to internal logic
inputs.
10. Return to Run-Test/Idle.
34.5.2.5 CLAMP
This instruction selects the Bypass register as Data Register. The device output pins are driven
from the boundary-scan chain.
Starting in Run-Test/Idle, the CLAMP instruction is accessed the following way:
1. Select the IR Scan path.
2. In Capture-IR: The IR output value is latched into the shift register.
3. In Shift-IR: The instruction register is shifted by the TCK input.
4. In Update-IR: The data from the boundary-scan chain is applied to the output pins.
5. Return to Run-Test/Idle.
6. Select the DR Scan path.
7. In Capture-DR: A logic ‘0’ is loaded into the Bypass Register.
8. In Shift-DR: Data is scanned from TDI to TDO through the Bypass register.
Table 34-14. INTEST Details
Instructions Details
IR input value 00100 (0x04)
IR output value p0001
DR Size Depending on boundary-scan chain, see BSDL-file.
DR input value Depending on boundary-scan chain, see BSDL-file.
DR output value Depending on boundary-scan chain, see BSDL-file.
868
32142D–06/2013
ATUC64/128/256L3/4U
9. Return to Run-Test/Idle.
34.5.2.6 BYPASS
This instruction selects the 1-bit Bypass Register as Data Register.
Starting in Run-Test/Idle, the CLAMP instruction is accessed the following way:
1. Select the IR Scan path.
2. In Capture-IR: The IR output value is latched into the shift register.
3. In Shift-IR: The instruction register is shifted by the TCK input.
4. Return to Run-Test/Idle.
5. Select the DR Scan path.
6. In Capture-DR: A logic ‘0’ is loaded into the Bypass Register.
7. In Shift-DR: Data is scanned from TDI to TDO through the Bypass register.
8. Return to Run-Test/Idle.
34.5.3 Private JTAG Instructions
The 32-bit AVR defines a number of private JTAG instructions, not defined by the JTAG standard.
Each instruction is briefly described in text, with details following in table form.
34.5.3.1 NEXUS_ACCESS
This instruction allows Nexus-compliant access to the On-Chip Debug registers through the
SAB. The 7-bit register index, a read/write control bit, and the 32-bit data is accessed through
the JTAG port.
The data register is alternately interpreted by the SAB as an address register and a data register.
The SAB starts in address mode after the NEXUS_ACCESS instruction is selected, and
toggles between address and data mode each time a data scan completes with the busy bit
cleared.
NOTE: The polarity of the direction bit is inverse of the Nexus standard.
Table 34-15. CLAMP Details
Instructions Details
IR input value 00110 (0x06)
IR output value p0001
DR Size 1
DR input value x
DR output value x
Table 34-16. BYPASS Details
Instructions Details
IR input value 11111 (0x1F)
IR output value p0001
DR Size 1
DR input value x
DR output value x
869
32142D–06/2013
ATUC64/128/256L3/4U
Starting in Run-Test/Idle, OCD registers are accessed in the following way:
1. Select the IR Scan path.
2. In Capture-IR: The IR output value is latched into the shift register.
3. In Shift-IR: The instruction register is shifted by the TCK input.
4. Return to Run-Test/Idle.
5. Select the DR Scan path.
6. In Shift-DR: Scan in the direction bit (1=read, 0=write) and the 7-bit address for the
OCD register.
7. Go to Update-DR and re-enter Select-DR Scan.
8. In Shift-DR: For a read operation, scan out the contents of the addressed register. For a
write operation, scan in the new contents of the register.
9. Return to Run-Test/Idle.
For any operation, the full 7 bits of the address must be provided. For write operations, 32 data
bits must be provided, or the result will be undefined. For read operations, shifting may be terminated
once the required number of bits have been acquired.
34.5.3.2 MEMORY_SERVICE
This instruction allows access to registers in an optional Memory Service Unit. The 7-bit register
index, a read/write control bit, and the 32-bit data is accessed through the JTAG port.
The data register is alternately interpreted by the SAB as an address register and a data register.
The SAB starts in address mode after the MEMORY_SERVICE instruction is selected, and
toggles between address and data mode each time a data scan completes with the busy bit
cleared.
Starting in Run-Test/Idle, Memory Service registers are accessed in the following way:
1. Select the IR Scan path.
2. In Capture-IR: The IR output value is latched into the shift register.
3. In Shift-IR: The instruction register is shifted by the TCK input.
4. Return to Run-Test/Idle.
5. Select the DR Scan path.
6. In Shift-DR: Scan in the direction bit (1=read, 0=write) and the 7-bit address for the
Memory Service register.
Table 34-17. NEXUS_ACCESS Details
Instructions Details
IR input value 10000 (0x10)
IR output value peb01
DR Size 34 bits
DR input value (Address phase) aaaaaaar xxxxxxxx xxxxxxxx xxxxxxxx xx
DR input value (Data read phase) xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xx
DR input value (Data write phase) dddddddd dddddddd dddddddd dddddddd xx
DR output value (Address phase) xx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxeb
DR output value (Data read phase) eb dddddddd dddddddd dddddddd dddddddd
DR output value (Data write phase) xx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxeb
870
32142D–06/2013
ATUC64/128/256L3/4U
7. Go to Update-DR and re-enter Select-DR Scan.
8. In Shift-DR: For a read operation, scan out the contents of the addressed register. For a
write operation, scan in the new contents of the register.
9. Return to Run-Test/Idle.
For any operation, the full 7 bits of the address must be provided. For write operations, 32 data
bits must be provided, or the result will be undefined. For read operations, shifting may be terminated
once the required number of bits have been acquired.
34.5.3.3 MEMORY_SIZED_ACCESS
This instruction allows access to the entire Service Access Bus data area. Data is accessed
through a 36-bit byte index, a 2-bit size, a direction bit, and 8, 16, or 32 bits of data. Not all units
mapped on the SAB bus may support all sizes of accesses, e.g., some may only support word
accesses.
The data register is alternately interpreted by the SAB as an address register and a data register.
The SAB starts in address mode after the MEMORY_SIZED_ACCESS instruction is
selected, and toggles between address and data mode each time a data scan completes with
the busy bit cleared.
Table 34-18. MEMORY_SERVICE Details
Instructions Details
IR input value 10100 (0x14)
IR output value peb01
DR Size 34 bits
DR input value (Address phase) aaaaaaar xxxxxxxx xxxxxxxx xxxxxxxx xx
DR input value (Data read phase) xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xx
DR input value (Data write phase) dddddddd dddddddd dddddddd dddddddd xx
DR output value (Address phase) xx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxeb
DR output value (Data read phase) eb dddddddd dddddddd dddddddd dddddddd
DR output value (Data write phase) xx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxeb
871
32142D–06/2013
ATUC64/128/256L3/4U
The size field is encoded as i Table 34-19.
Starting in Run-Test/Idle, SAB data is accessed in the following way:
1. Select the IR Scan path.
2. In Capture-IR: The IR output value is latched into the shift register.
3. In Shift-IR: The instruction register is shifted by the TCK input.
4. Return to Run-Test/Idle.
5. Select the DR Scan path.
6. In Shift-DR: Scan in the direction bit (1=read, 0=write), 2-bit access size, and the 36-bit
address of the data to access.
7. Go to Update-DR and re-enter Select-DR Scan.
8. In Shift-DR: For a read operation, scan out the contents of the addressed area. For a
write operation, scan in the new contents of the area.
9. Return to Run-Test/Idle.
For any operation, the full 36 bits of the address must be provided. For write operations, 32 data
bits must be provided, or the result will be undefined. For read operations, shifting may be terminated
once the required number of bits have been acquired.
Table 34-19. Size Field Semantics
Size field value Access size Data alignment
00 Byte (8 bits)
Address modulo 4 : data alignment
0: dddddddd xxxxxxxx xxxxxxxx xxxxxxxx
1: xxxxxxxx dddddddd xxxxxxxx xxxxxxxx
2: xxxxxxxx xxxxxxxx dddddddd xxxxxxxx
3: xxxxxxxx xxxxxxxx xxxxxxxx dddddddd
01 Halfword (16 bits)
Address modulo 4 : data alignment
0: dddddddd dddddddd xxxxxxxx xxxxxxxx
1: Not allowed
2: xxxxxxxx xxxxxxxx dddddddd dddddddd
3: Not allowed
10 Word (32 bits)
Address modulo 4 : data alignment
0: dddddddd dddddddd dddddddd dddddddd
1: Not allowed
2: Not allowed
3: Not allowed
11 Reserved N/A
Table 34-20. MEMORY_SIZED_ACCESS Details
Instructions Details
IR input value 10101 (0x15)
IR output value peb01
DR Size 39 bits
DR input value (Address phase) aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaassr
DR input value (Data read phase) xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxx
DR input value (Data write phase) dddddddd dddddddd dddddddd dddddddd xxxxxxx
872
32142D–06/2013
ATUC64/128/256L3/4U
34.5.3.4 MEMORY_WORD_ACCESS
This instruction allows access to the entire Service Access Bus data area. Data is accessed
through the 34 MSB of the SAB address, a direction bit, and 32 bits of data. This instruction is
identical to MEMORY_SIZED_ACCESS except that it always does word sized accesses. The
size field is implied, and the two lowest address bits are removed and not scanned in.
Note: This instruction was previously known as MEMORY_ACCESS, and is provided for backwards
compatibility.
The data register is alternately interpreted by the SAB as an address register and a data register.
The SAB starts in address mode after the MEMORY_WORD_ACCESS instruction is
selected, and toggles between address and data mode each time a data scan completes with
the busy bit cleared.
Starting in Run-Test/Idle, SAB data is accessed in the following way:
1. Select the IR Scan path.
2. In Capture-IR: The IR output value is latched into the shift register.
3. In Shift-IR: The instruction register is shifted by the TCK input.
4. Return to Run-Test/Idle.
5. Select the DR Scan path.
6. In Shift-DR: Scan in the direction bit (1=read, 0=write) and the 34-bit address of the
data to access.
7. Go to Update-DR and re-enter Select-DR Scan.
8. In Shift-DR: For a read operation, scan out the contents of the addressed area. For a
write operation, scan in the new contents of the area.
9. Return to Run-Test/Idle.
For any operation, the full 34 bits of the address must be provided. For write operations, 32 data
bits must be provided, or the result will be undefined. For read operations, shifting may be terminated
once the required number of bits have been acquired.
DR output value (Address phase) xxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxeb
DR output value (Data read phase) xxxxxeb dddddddd dddddddd dddddddd dddddddd
DR output value (Data write phase) xxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxeb
Table 34-20. MEMORY_SIZED_ACCESS Details (Continued)
Instructions Details
Table 34-21. MEMORY_WORD_ACCESS Details
Instructions Details
IR input value 10001 (0x11)
IR output value peb01
DR Size 35 bits
DR input value (Address phase) aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aar
DR input value (Data read phase) xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxx
DR input value (Data write phase) dddddddd dddddddd dddddddd dddddddd xxx
873
32142D–06/2013
ATUC64/128/256L3/4U
34.5.3.5 MEMORY_BLOCK_ACCESS
This instruction allows access to the entire SAB data area. Up to 32 bits of data is accessed at a
time, while the address is sequentially incremented from the previously used address.
In this mode, the SAB address, size, and access direction is not provided with each access.
Instead, the previous address is auto-incremented depending on the specified size and the previous
operation repeated. The address must be set up in advance with
MEMORY_SIZE_ACCESS or MEMORY_WORD_ACCESS. It is allowed, but not required, to
shift data after shifting the address.
This instruction is primarily intended to speed up large quantities of sequential word accesses. It
is possible to use it also for byte and halfword accesses, but the overhead in this is case much
larger as 32 bits must still be shifted for each access.
The following sequence should be used:
1. Use the MEMORY_SIZE_ACCESS or MEMORY_WORD_ACCESS to read or write the
first location.
2. Return to Run-Test/Idle.
3. Select the IR Scan path.
4. In Capture-IR: The IR output value is latched into the shift register.
5. In Shift-IR: The instruction register is shifted by the TCK input.
6. Return to Run-Test/Idle.
7. Select the DR Scan path. The address will now have incremented by 1, 2, or 4 (corresponding
to the next byte, halfword, or word location).
8. In Shift-DR: For a read operation, scan out the contents of the next addressed location.
For a write operation, scan in the new contents of the next addressed location.
9. Go to Update-DR.
10. If the block access is not complete, return to Select-DR Scan and repeat the access.
11. If the block access is complete, return to Run-Test/Idle.
For write operations, 32 data bits must be provided, or the result will be undefined. For read
operations, shifting may be terminated once the required number of bits have been acquired.
DR output value (Address phase) xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xeb
DR output value (Data read phase) xeb dddddddd dddddddd dddddddd dddddddd
DR output value (Data write phase) xxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxeb
Table 34-21. MEMORY_WORD_ACCESS Details (Continued)
Instructions Details
Table 34-22. MEMORY_BLOCK_ACCESS Details
Instructions Details
IR input value 10010 (0x12)
IR output value peb01
DR Size 34 bits
DR input value (Data read phase) xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xx
874
32142D–06/2013
ATUC64/128/256L3/4U
The overhead using block word access is 4 cycles per 32 bits of data, resulting in an 88% transfer
efficiency, or 2.1 MBytes per second with a 20 MHz TCK frequency.
34.5.3.6 CANCEL_ACCESS
If a very slow memory location is accessed during a SAB memory access, it could take a very
long time until the busy bit is cleared, and the SAB becomes ready for the next operation. The
CANCEL_ACCESS instruction provides a possibility to abort an ongoing transfer and report a
timeout to the JTAG master.
When the CANCEL_ACCESS instruction is selected, the current access will be terminated as
soon as possible. There are no guarantees about how long this will take, as the hardware may
not always be able to cancel the access immediately. The SAB is ready to respond to a new
command when the busy bit clears.
Starting in Run-Test/Idle, CANCEL_ACCESS is accessed in the following way:
1. Select the IR Scan path.
2. In Capture-IR: The IR output value is latched into the shift register.
3. In Shift-IR: The instruction register is shifted by the TCK input.
4. Return to Run-Test/Idle.
34.5.3.7 SYNC
This instruction allows external debuggers and testers to measure the ratio between the external
JTAG clock and the internal system clock. The SYNC data register is a 16-bit counter that
counts down to zero using the internal system clock. The busy bit stays high until the counter
reaches zero.
Starting in Run-Test/Idle, SYNC instruction is used in the following way:
1. Select the IR Scan path.
2. In Capture-IR: The IR output value is latched into the shift register.
3. In Shift-IR: The instruction register is shifted by the TCK input.
4. Return to Run-Test/Idle.
5. Select the DR Scan path.
DR input value (Data write phase) dddddddd dddddddd dddddddd dddddddd xx
DR output value (Data read phase) eb dddddddd dddddddd dddddddd dddddddd
DR output value (Data write phase) xx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxeb
Table 34-22. MEMORY_BLOCK_ACCESS Details (Continued)
Instructions Details
Table 34-23. CANCEL_ACCESS Details
Instructions Details
IR input value 10011 (0x13)
IR output value peb01
DR Size 1
DR input value x
DR output value 0
875
32142D–06/2013
ATUC64/128/256L3/4U
6. Scan in an 16-bit counter value.
7. Go to Update-DR and re-enter Select-DR Scan.
8. In Shift-DR: Scan out the busy bit, and until the busy bit clears goto 7.
9. Calculate an approximation to the internal clock speed using the elapsed time and the
counter value.
10. Return to Run-Test/Idle.
The full 16-bit counter value must be provided when starting the synch operation, or the result
will be undefined. When reading status, shifting may be terminated once the required number of
bits have been acquired.
34.5.3.8 AVR_RESET
This instruction allows a debugger or tester to directly control separate reset domains inside the
chip. The shift register contains one bit for each controllable reset domain. Setting a bit to one
resets that domain and holds it in reset. Setting a bit to zero releases the reset for that domain.
The AVR_RESET instruction can be used in the following way:
1. Select the IR Scan path.
2. In Capture-IR: The IR output value is latched into the shift register.
3. In Shift-IR: The instruction register is shifted by the TCK input.
4. Return to Run-Test/Idle.
5. Select the DR Scan path.
6. In Shift-DR: Scan in the value corresponding to the reset domains the JTAG master
wants to reset into the data register.
7. Return to Run-Test/Idle.
8. Stay in run test idle for at least 10 TCK clock cycles to let the reset propagate to the
system.
See the device specific documentation for the number of reset domains, and what these
domains are.
For any operation, all bits must be provided or the result will be undefined.
Table 34-24. SYNC_ACCESS Details
Instructions Details
IR input value 10111 (0x17)
IR output value peb01
DR Size 16 bits
DR input value dddddddd dddddddd
DR output value xxxxxxxx xxxxxxeb
Table 34-25. AVR_RESET Details
Instructions Details
IR input value 01100 (0x0C)
IR output value p0001
876
32142D–06/2013
ATUC64/128/256L3/4U
34.5.3.9 CHIP_ERASE
This instruction allows a programmer to completely erase all nonvolatile memories in a chip.
This will also clear any security bits that are set, so the device can be accessed normally. In
devices without non-volatile memories this instruction does nothing, and appears to complete
immediately.
The erasing of non-volatile memories starts as soon as the CHIP_ERASE instruction is selected.
The CHIP_ERASE instruction selects a 1 bit bypass data register.
A chip erase operation should be performed as:
1. Reset the system and stop the CPU from executing.
2. Select the IR Scan path.
3. In Capture-IR: The IR output value is latched into the shift register.
4. In Shift-IR: The instruction register is shifted by the TCK input.
5. Check the busy bit that was scanned out during Shift-IR. If the busy bit was set goto 2.
6. Return to Run-Test/Idle.
34.5.3.10 HALT
This instruction allows a programmer to easily stop the CPU to ensure that it does not execute
invalid code during programming.
This instruction selects a 1-bit halt register. Setting this bit to one halts the CPU. Setting this bit
to zero releases the CPU to run normally. The value shifted out from the data register is one if
the CPU is halted. Before releasing the halt command the CPU needs to be reset to ensure that
it will start at the reset startup address.
The HALT instruction can be used in the following way:
1. Select the IR Scan path.
2. In Capture-IR: The IR output value is latched into the shift register.
3. In Shift-IR: The instruction register is shifted by the TCK input.
4. Return to Run-Test/Idle.
5. Select the DR Scan path.
DR Size Device specific.
DR input value Device specific.
DR output value Device specific.
Table 34-25. AVR_RESET Details (Continued)
Instructions Details
Table 34-26. CHIP_ERASE Details
Instructions Details
IR input value 01111 (0x0F)
IR output value p0b01
Where b is the busy bit.
DR Size 1 bit
DR input value x
DR output value 0
877
32142D–06/2013
ATUC64/128/256L3/4U
6. In Shift-DR: Scan in the value 1 to halt the CPU, 0 to start CPU execution.
7. Return to Run-Test/Idle.
Table 34-27. HALT Details
Instructions Details
IR input value 11100 (0x1C)
IR output value p0001
DR Size 1 bit
DR input value d
DR output value d
878
32142D–06/2013
ATUC64/128/256L3/4U
34.5.4 JTAG Data Registers
The following device specific registers can be selected as JTAG scan chain depending on the
instruction loaded in the JTAG Instruction Register. Additional registers exist, but are implicitly
described in the functional description of the relevant instructions.
34.5.4.1 Device Identification Register
The Device Identification Register contains a unique identifier for each product. The register is
selected by the IDCODE instruction, which is the default instruction after a JTAG reset.
Device specific ID codes
The different device configurations have different JTAG ID codes, as shown in Table 34-28.
Note that if the flash controller is statically reset, the ID code will be undefined.
34.5.4.2 Reset Register
The reset register is selected by the AVR_RESET instruction and contains one bit for each reset
domain in the device. Setting each bit to one will keep that domain reset until the bit is cleared.
MSB LSB
Bit 31 28 27 12 11 1 0
Device ID Revision Part Number Manufacturer ID 1
4 bits 16 bits 11 bits 1 bit
Revision This is a 4 bit number identifying the revision of the component.
Rev A = 0x0, B = 0x1, etc.
Part Number The part number is a 16 bit code identifying the component.
Manufacturer ID The Manufacturer ID is a 11 bit code identifying the manufacturer.
The JTAG manufacturer ID for ATMEL is 0x01F.
Table 34-28. Device and JTAG ID
Device Name JTAG ID Code (R is the revision number)
ATUC256L3U 0xr21C303F
ATUC128L3U 0xr21C403F
ATUC64L3U 0xr21C503F
ATUC256L4U 0xr21C603F
ATUC128L4U 0xr21C703F
ATUC64L4U 0xr21C803F
Bit 0
Reset
domain System
879
32142D–06/2013
ATUC64/128/256L3/4U
34.5.4.3 Boundary--scan Chain
The boundary-scan chain has the capability of driving and observing the logic levels on the digital
I/O pins, as well as driving and observing the logic levels between the digital I/O pins and the
internal logic. Typically, output value, output enable, and input data are all available in the
boundary-scan chain.
The boundary-scan chain is described in the BSDL (Boundary Scan Description Language) file
available at the Atmel web site.
System Resets the whole chip, except the JTAG itself.
880
32142D–06/2013
ATUC64/128/256L3/4U
34.6 aWire Debug Interface (AW)
Rev.: 2.3.0.1
34.6.1 Features
• Single pin debug system.
• Half Duplex asynchronous communication (UART compatible).
• Full duplex mode for direct UART connection.
• Compatible with JTAG functionality, except boundary scan.
• Failsafe packet-oriented protocol.
• Read and write on-chip memory and program on-chip flash and fuses through SAB interface.
• On-Chip Debug access through SAB interface.
• Asynchronous receiver or transmitter when the aWire system is not used for debugging.
34.6.2 Overview
The aWire Debug Interface (AW) offers a single pin debug solution that is fully compatible with
the functionality offered by the JTAG interface, except boundary scan. This functionality includes
memory access, programming capabilities, and On-Chip Debug access.
Figure 34-8 on page 881 shows how the AW is connected in a 32-bit AVR device. The
RESET_N pin is used both as reset and debug pin. A special sequence on RESET_N is needed
to block the normal reset functionality and enable the AW.
The Service Access Bus (SAB) interface contains address and data registers for the Service
Access Bus, which gives access to On-Chip Debug, programming, and other functions in the
device. The SAB offers several modes of access to the address and data registers, as discussed
in Section 34.6.6.8.
Section 34.6.7 lists the supported aWire commands and responses, with references to the
description in this document.
If the AW is not used for debugging, the aWire UART can be used by the user to send or receive
data with one stop bit, eight data bits, no parity bits, and one stop bit. This can be controlled
through the aWire user interface.
881
32142D–06/2013
ATUC64/128/256L3/4U
34.6.3 Block Diagram
Figure 34-8. aWire Debug Interface Block Diagram
34.6.4 I/O Lines Description
34.6.5 Product Dependencies
In order to use this module, other parts of the system must be configured correctly, as described
below.
Table 34-29. I/O Lines Description
Name Description Type
DATA aWire data multiplexed with the RESET_N pin. Input/Output
DATAOUT aWire data output in 2-pin mode. Output
UART
Reset
filter
External reset
AW_ENABLE
RESET_N
Baudrate Detector
RW SZ ADDR DATA
CRC
AW CONTROL
AW User Interface
SAB interface
RESET command
Power
Manager
HALT command CPU
Flash
Controller CHIP_ERASE command
aWire Debug Interface
PB
SAB
882
32142D–06/2013
ATUC64/128/256L3/4U
34.6.5.1 I/O Lines
The pin used by AW is multiplexed with the RESET_N pin. The reset functionality is the default
function of this pin. To enable the aWire functionality on the RESET_N pin the user must enable
the AW either by sending the enable sequence over the RESET_N pin from an external aWire
master or by enabling the aWire user interface.
In 2-pin mode data is received on the RESET_N line, but transmitted on the DATAOUT line.
After sending the 2_PIN_MODE command the DATAOUT line is automatically enabled. All other
peripheral functions on this pin is disabled.
34.6.5.2 Power Management
When debugging through AW the system clocks are automatically turned on to allow debugging
in sleep modes.
34.6.5.3 Clocks
The aWire UART uses the internal 120 MHz RC oscillator (RC120M) as clock source for its
operation. When enabling the AW the RC120M is automatically started.
34.6.5.4 External Components
The AW needs an external pullup on the RESET_N pin to ensure that the pin is pulled up when
the bus is not driven.
34.6.6 Functional Description
34.6.6.1 aWire Communication Protocol
The AW is accessed through the RESET_N pin shown in Table 34-29 on page 881. The AW
communicates through a UART operating at variable baud rate (depending on a sync pattern)
with one start bit, 8 data bits (LSB first), one stop bit, and no parity bits. The aWire protocol is
based upon command packets from an externalmaster and response packets from the slave
(AW). The master always initiates communication and decides the baud rate.
The packet contains a sync byte (0x55), a command/response byte, two length bytes (optional),
a number of data bytes as defined in the length field (optional), and two CRC bytes. If the command/response
has the most significant bit set, the command/response also carries the optional
length and data fields. The CRC field is not checked if the CRC value transmitted is 0x0000.
Table 34-30. aWire Packet Format
Field Number of bytes Description Comment Optional
SYNC 1 Sync pattern (0x55). Used by the receiver to set the baud rate
clock. No
COMMAND/
RESPONSE 1 Command from the master or
response from the slave.
When the most significant bit is set the
command/response has a length field. A
response has the next most significant bit
set. A command does not have this bit set.
No
883
32142D–06/2013
ATUC64/128/256L3/4U
CRC calculation
The CRC is calculated from the command/response, length, and data fields. The polynomial
used is the FCS16 (or CRC-16-CCIT) in reverse mode (0x8408) and the starting value is
0x0000.
Example command
Below is an example command from the master with additional data.
Figure 34-9. Example Command
Example response
Below is an example response from the slave with additional data.
Figure 34-10. Example Response
LENGTH 2 The number of bytes in the DATA
field. Yes
DATA LENGTH Data according to command/
response.
Yes
CRC 2 CRC calculated with the FCS16
polynomial.
CRC value of 0x0000 makes the aWire
disregard the CRC if the master does not
support it.
No
Table 34-30. aWire Packet Format
Field Number of bytes Description Comment Optional
baud_rate_clk
data_pin ...
field sync(0x55) command(0x81) length(MSB) length(lsb)
...
data(MSB) data(LSB) CRC(MSB) CRC(lsb)
baud_rate_clk
data_pin ...
field sync(0x55) response(0xC1) length(MSB) length(lsb)
...
data(MSB) data(LSB) CRC(MSB) CRC(lsb)
884
32142D–06/2013
ATUC64/128/256L3/4U
Avoiding drive contention when changing direction
The aWire debug protocol uses one dataline in both directions. To avoid both the master and the
slave to drive this line when changing direction the AW has a built in guard time before it starts to
drive the line. At reset this guard time is set to maximum (128 bit cycles), but can be lowered by
the master upon command.
The AW will release the line immediately after the stop character has been transmitted.
During the direction change there can be a period when the line is not driven. An external pullup
has to be added to RESET_N to keep the signal stable when neither master or slave is actively
driving the line.
34.6.6.2 The RESET_N pin
Normal reset functionality on the RESET_N pin is disabled when using aWire. However, the
user can reset the system through the RESET aWire command. During aWire operation the
RESET_N pin should not be connected to an external reset circuitry, but disconnected via a
switch or a jumper to avoid drive contention and speed problems.
Figure 34-11. Reset Circuitry and aWire.
34.6.6.3 Initializing the AW
To enable AW, the user has to send a 0x55 pattern with a baudrate of 1 kHz on the RESET_N
pin. The AW is enabled after transmitting this pattern and the user can start transmitting commands.
This pattern is not the sync pattern for the first command.
After enabling the aWire debug interface the halt bit is set automatically to prevent the system
from running code after the interface is enabled. To make the CPU run again set halt to zero
using the HALT command.
34.6.6.4 Disabling the AW
To disable AW, the user can keep the RESET_N pin low for 100 ms. This will disable the AW,
return RESET_N to its normal function, and reset the device.
An aWire master can also disable aWire by sending the DISABLE command. After acking the
command the AW will be disabled and RESET_N returns to its normal function.
RESET_N
AW Debug
Interface
Jumper
MCU
Power Manager
aWire master connector
Board Reset
Circuitry
885
32142D–06/2013
ATUC64/128/256L3/4U
34.6.6.5 Resetting the AW
The aWire master can reset the AW slave by pulling the RESET_N pin low for 20 ms. This is
equivalent to disabling and then enabling AW.
34.6.6.6 2-pin Mode
To avoid using special hardware when using a normal UART device as aWire master, the aWire
slave has a 2-pin mode where one pin is used as input and on pin is used as output. To enable
this mode the 2_PIN_MODE command must be sent. After sending the command, all responses
will be sent on the DATAOUT pin instead of the RESET_N pin. Commands are still received on
the RESET_N pin.
34.6.6.7 Baud Rate Clock
The communication speed is set by the master in the sync field of the command. The AW will
use this to resynchronize its baud rate clock and reply on this frequency. The minimum frequency
of the communication is 1 kHz. The maximum frequency depends on the internal clock
source for the AW (RC120M). The baud rate clock is generated by AW with the following
formula:
Where is the baud rate frequency and is the frequency of the internal RC120M. TUNE is
the value returned by the BAUD_RATE response.
To find the max frequency the user can issue the TUNE command to the AW to make it return
the TUNE value. This value can be used to compute the . The maximum operational frequency
( ) is then:
34.6.6.8 Service Access Bus
The AVR32 architecture offers a common interface for access to On-Chip Debug, programming,
and test functions. These are mapped on a common bus called the Service Access Bus (SAB),
which is linked to the aWire through a bus master module, which also handles synchronization
between the aWire and SAB clocks.
For more information about the SAB and a list of SAB slaves see the Service Access Bus
chapter.
SAB Clock
When accessing the SAB through the aWire there are no limitations on baud rate frequency
compared to chip frequency, although there must be an active system clock in order for the SAB
accesses to complete. If the system clock (CLK_SYS) is switched off in sleep mode, activity on
the aWire pin will restart the CLK_SYS automatically, without waking the device from sleep.
aWire masters may optimize the transfer rate by adjusting the baud rate frequency in relation to
the CLK_SYS. This ratio can be measured with the MEMORY_SPEED_REQUEST command.
When issuing the MEMORY_SPEED_REQUEST command a counter value CV is returned. CV
can be used to calculate the SAB speed ( ) using this formula:
f
aw
TUNE f br
8 = ----------------------------
f
br f
aw
f
aw
f
brmax
f
brmax
f
aw
4 = -------
f
sab
886
32142D–06/2013
ATUC64/128/256L3/4U
SAB Address Mode
The Service Access Bus uses 36 address bits to address memory or registers in any of the
slaves on the bus. The bus supports sized accesses of bytes (8 bits), halfwords (16 bits), or
words (32 bits). All accesses must be aligned to the size of the access, i.e. halfword accesses
must have the lowest address bit cleared, and word accesses must have the two lowest address
bits cleared.
Two instructions exist to access the SAB: MEMORY_WRITE and MEMORY_READ. These two
instructions write and read words, halfwords, and bytes from the SAB.
Busy Reporting
If the aWire master, during a MEMORY_WRITE or a MEMORY_READ command, transmit
another byte when the aWire is still busy sending the previous byte to the SAB, the AW will
respond with a MEMORY_READ_WRITE_STATUS error. See chapter Section 34.6.8.5 for
more details.
The aWire master should adjust its baudrate or delay between bytes when doing SAB accesses
to ensure that the SAB is not overwhelmed with data.
Error Reporting
If a write is performed on a non-existing memory location the SAB interface will respond with an
error. If this happens, all further writes in this command will not be performed and the error and
number of bytes written is reported in the MEMORY_READWRITE_STATUS message from the
AW after the write.
If a read is performed on a non-existing memory location, the SAB interface will respond with an
error. If this happens, the data bytes read after this event are not valid. The AW will include three
extra bytes at the end of the transfer to indicate if the transfer was successful, or in the case of
an error, how many valid bytes were received.
34.6.6.9 CRC Errors/NACK Response
The AW will calculate a CRC value when receiving the command, length, and data fields of the
command packets. If this value differs from the value from the CRC field of the packet, the AW
will reply with a NACK response. Otherwise the command is carried out normally.
An unknown command will be replied with a NACK response.
In worst case a transmission error can happen in the length or command field of the packet. This
can lead to the aWire slave trying to receive a command with or without length (opposite of what
the master intended) or receive an incorrect number of bytes. The aWire slave will then either
wait for more data when the master has finished or already have transmitted the NACK
response in congestion with the master. The master can implement a timeout on every command
and reset the slave if no response is returned after the timeout period has ended.
f
sab
3f
aw
CV – 3 = ----------------
887
32142D–06/2013
ATUC64/128/256L3/4U
34.6.7 aWire Command Summary
The implemented aWire commands are shown in the table below. The responses from the AW
are listed in Section 34.6.8.
All aWire commands are described below, with a summary in table form.
34.6.7.1 AYA
This command asks the AW: “Are you alive”, where the AW should respond with an
acknowledge.
Table 34-31. aWire Command Summary
COMMAND Instruction Description
0x01 AYA “Are you alive”.
0x02 JTAG_ID Asks AW to return the JTAG IDCODE.
0x03 STATUS_REQUEST Request a status message from the AW.
0x04 TUNE Tell the AW to report the current baud rate.
0x05 MEMORY_SPEED_REQUEST Reports the speed difference between the aWire control and the SAB clock
domains.
0x06 CHIP_ERASE Erases the flash and all volatile memories.
0x07 DISABLE Disables the AW.
0x08 2_PIN_MODE Enables the DATAOUT pin and puts the aWire in 2-pin mode, where all
responses are sent on the DATAOUT pin.
0x80 MEMORY_WRITE Writes words, halfwords, or bytes to the SAB.
0x81 MEMORY_READ Reads words, halfwords, or bytes from the SAB.
0x82 HALT Issues a halt command to the device.
0x83 RESET Issues a reset to the Reset Controller.
0x84 SET_GUARD_TIME Sets the guard time for the AW.
Table 34-32. Command/Response Description Notation
Command/Response Description
Command/Response value Shows the command/response value to put into the command/response field of the packet.
Additional data Shows the format of the optional data field if applicable.
Possible responses Shows the possible responses for this command.
Table 34-33. AYA Details
Command Details
Command value 0x01
Additional data N/A
Possible responses 0x40: ACK (Section 34.6.8.1)
0x41: NACK (Section 34.6.8.2)
888
32142D–06/2013
ATUC64/128/256L3/4U
34.6.7.2 JTAG_ID
This command instructs the AW to output the JTAG idcode in the following response.
34.6.7.3 STATUS_REQUEST
Asks the AW for a status message.
34.6.7.4 TUNE
Asks the AW for the current baud rate counter value.
34.6.7.5 MEMORY_SPEED_REQUEST
Asks the AW for the relative speed between the aWire clock (RC120M) and the SAB interface.
34.6.7.6 CHIP_ERASE
This instruction allows a programmer to completely erase all nonvolatile memories in the chip.
This will also clear any security bits that are set, so the device can be accessed normally. The
command is acked immediately, but the status of the command can be monitored by checking
Table 34-34. JTAG_ID Details
Command Details
Command value 0x02
Additional data N/A
Possible responses 0xC0: IDCODE (Section 34.6.8.3)
0x41: NACK (Section 34.6.8.2)
Table 34-35. STATUS_REQUEST Details
Command Details
Command value 0x03
Additional data N/A
Possible responses 0xC4: STATUS_INFO (Section 34.6.8.7)
0x41: NACK (Section 34.6.8.2)
Table 34-36. TUNE Details
Command Details
Command value 0x04
Additional data N/A
Possible responses 0xC3: BAUD_RATE (Section 34.6.8.6)
0x41: NACK (Section 34.6.8.2)
Table 34-37. MEMORY_SPEED_REQUEST Details
Command Details
Command value 0x05
Additional data N/A
Possible responses 0xC5: MEMORY_SPEED (Section 34.6.8.8)
0x41: NACK (Section 34.6.8.2)
889
32142D–06/2013
ATUC64/128/256L3/4U
the Chip Erase ongoing bit in the status bytes received after the STATUS_REQUEST
command.
34.6.7.7 DISABLE
Disables the AW. The AW will respond with an ACK response and then disable itself.
34.6.7.8 2_PIN_MODE
Enables the DATAOUT pin as an output pin. All responses sent from the aWire slave will be sent
on this pin, instead of the RESET_N pin, starting with the ACK for the 2_PIN_MODE command.
34.6.7.9 MEMORY_WRITE
This command enables programming of memory/writing to registers on the SAB. The
MEMORY_WRITE command allows words, halfwords, and bytes to be programmed to a continuous
sequence of addresses in one operation. Before transferring the data, the user must
supply:
1. The number of data bytes to write + 5 (size and starting address) in the length field.
2. The size of the transfer: words, halfwords, or bytes.
3. The starting address of the transfer.
Table 34-38. CHIP_ERASE Details
Command Details
Command value 0x06
Additional data N/A
Possible responses 0x40: ACK (Section 34.6.8.1)
0x41: NACK (Section 34.6.8.2)
Table 34-39. DISABLE Details
Command Details
Command value 0x07
Additional data N/A
Possible responses 0x40: ACK (Section 34.6.8.1)
0x41: NACK (Section 34.6.8.2)
Table 34-40. DISABLE Details
Command Details
Command value 0x07
Additional data N/A
Possible responses 0x40: ACK (Section 34.6.8.1)
0x41: NACK (Section 34.6.8.2)
890
32142D–06/2013
ATUC64/128/256L3/4U
The 4 MSB of the 36 bit SAB address are submitted together with the size field (2 bits). Then follows
the 4 remaining address bytes and finally the data bytes. The size of the transfer is
specified using the values from the following table:
Below is an example write command:
1. 0x55 (sync)
2. 0x80 (command)
3. 0x00 (length MSB)
4. 0x09 (length LSB)
5. 0x25 (size and address MSB, the two MSB of this byte are unused and set to zero)
6. 0x00
7. 0x00
8. 0x00
9. 0x04 (address LSB)
10. 0xCA
11. 0xFE
12. 0xBA
13. 0xBE
14. 0xXX (CRC MSB)
15. 0xXX (CRC LSB)
The length field is set to 0x0009 because there are 9 bytes of additional data: 5 address and size
bytes and 4 bytes of data. The address and size field indicates that words should be written to
address 0x500000004. The data written to 0x500000004 is 0xCAFEBABE.
34.6.7.10 MEMORY_READ
This command enables reading of memory/registers on the Service Access Bus (SAB). The
MEMORY_READ command allows words, halfwords, and bytes to be read from a continuous
sequence of addresses in one operation. The user must supply:
Table 34-41. Size Field Decoding
Size field Description
00 Byte transfer
01 Halfword transfer
10 Word transfer
11 Reserved
Table 34-42. MEMORY_WRITE Details
Command Details
Command value 0x80
Additional data Size, Address and Data
Possible responses 0xC2: MEMORY_READWRITE_STATUS (Section 34.6.8.5)
0x41: NACK (Section 34.6.8.2)
891
32142D–06/2013
ATUC64/128/256L3/4U
1. The size of the data field: 7 (size and starting address + read length indicator) in the
length field.
2. The size of the transfer: Words, halfwords, or bytes.
3. The starting address of the transfer.
4. The number of bytes to read (max 65532).
The 4 MSB of the 36 bit SAB address are submitted together with the size field (2 bits). The 4
remaining address bytes are submitted before the number of bytes to read. The size of the
transfer is specified using the values from the following table:
Below is an example read command:
1. 0x55 (sync)
2. 0x81 (command)
3. 0x00 (length MSB)
4. 0x07 (length LSB)
5. 0x25 (size and address MSB, the two MSB of this byte are unused and set to zero)
6. 0x00
7. 0x00
8. 0x00
9. 0x04 (address LSB)
10. 0x00
11. 0x04
12. 0xXX (CRC MSB)
13. 0xXX (CRC LSB)
The length field is set to 0x0007 because there are 7 bytes of additional data: 5 bytes of address
and size and 2 bytes with the number of bytes to read. The address and size field indicates one
word (four bytes) should be read from address 0x500000004.
Table 34-43. Size Field Decoding
Size field Description
00 Byte transfer
01 Halfword transfer
10 Word transfer
11 Reserved
Table 34-44. MEMORY_READ Details
Command Details
Command value 0x81
Additional data Size, Address and Length
Possible responses
0xC1: MEMDATA (Section 34.6.8.4)
0xC2: MEMORY_READWRITE_STATUS (Section 34.6.8.5)
0x41: NACK (Section 34.6.8.2)
892
32142D–06/2013
ATUC64/128/256L3/4U
34.6.7.11 HALT
This command tells the CPU to halt code execution for safe programming. If the CPU is not
halted during programming it can start executing partially loaded programs. To halt the processor,
the aWire master should send 0x01 in the data field of the command. After programming the
halting can be released by sending 0x00 in the data field of the command.
34.6.7.12 RESET
This command resets different domains in the part. The aWire master sends a byte with the
reset value. Each bit in the reset value byte corresponds to a reset domain in the chip. If a bit is
set the reset is activated and if a bit is not set the reset is released. The number of reset domains
and their destinations are identical to the resets described in the JTAG data registers chapter
under reset register.
34.6.7.13 SET_GUARD_TIME
Sets the guard time value in the AW, i.e. how long the AW will wait before starting its transfer
after the master has finished.
The guard time can be either 0x00 (128 bit lengths), 0x01 (16 bit lengths), 0x2 (4 bit lengths) or
0x3 (1 bit length).
Table 34-45. HALT Details
Command Details
Command value 0x82
Additional data 0x01 to halt the CPU 0x00 to release the halt and reset the
device.
Possible responses 0x40: ACK (Section 34.6.8.1)
0x41: NACK (Section 34.6.8.2)
Table 34-46. RESET Details
Command Details
Command value 0x83
Additional data Reset value for each reset domain. The number of reset
domains is part specific.
Possible responses 0x40: ACK (Section 34.6.8.1)
0x41: NACK (Section 34.6.8.2)
Table 34-47. SET_GUARD_TIME Details
Command Details
Command value 0x84
Additional data Guard time
Possible responses 0x40: ACK (Section 34.6.8.1)
0x41: NACK (Section 34.6.8.2)
893
32142D–06/2013
ATUC64/128/256L3/4U
34.6.8 aWire Response Summary
The implemented aWire responses are shown in the table below.
34.6.8.1 ACK
The AW has received the command successfully and performed the operation.
34.6.8.2 NACK
The AW has received the command, but got a CRC mismatch.
34.6.8.3 IDCODE
The JTAG idcode for this device.
34.6.8.4 MEMDATA
The data read from the address specified by the MEMORY_READ command. The last 3 bytes
are status bytes from the read. The first status byte is the status of the command described in
the table below. The last 2 bytes are the number of remaining data bytes to be sent in the data
field of the packet when the error occurred. If the read was not successful all data bytes after the
failure are undefined. A successful word read (4 bytes) will look like this:
Table 34-48. aWire Response Summary
RESPONSE Instruction Description
0x40 ACK Acknowledge.
0x41 NACK Not acknowledge. Sent after CRC errors and after unknown commands.
0xC0 IDCODE The JTAG idcode.
0xC1 MEMDATA Values read from memory.
0xC2 MEMORY_READWRITE_STATUS Status after a MEMORY_WRITE or a MEMORY_READ command. OK, busy,
error.
0xC3 BAUD_RATE The current baudrate.
0xC4 STATUS_INFO Status information.
0xC5 MEMORY_SPEED SAB to aWire speed information.
Table 34-49. ACK Details
Response Details
Response value 0x40
Additional data N/A
Table 34-50. NACK Details
Response Details
Response value 0x41
Additional data N/A
Table 34-51. IDCODE Details
Response Details
Response value 0xC0
Additional data JTAG idcode
894
32142D–06/2013
ATUC64/128/256L3/4U
1. 0x55 (sync)
2. 0xC1 (command)
3. 0x00 (length MSB)
4. 0x07 (length LSB)
5. 0xCA (Data MSB)
6. 0xFE
7. 0xBA
8. 0xBE (Data LSB)
9. 0x00 (Status byte)
10. 0x00 (Bytes remaining MSB)
11. 0x00 (Bytes remaining LSB)
12. 0xXX (CRC MSB)
13. 0xXX (CRC LSB)
The status is 0x00 and all data read are valid. An unsuccessful four byte read can look like this:
1. 0x55 (sync)
2. 0xC1 (command)
3. 0x00 (length MSB)
4. 0x07 (length LSB)
5. 0xCA (Data MSB)
6. 0xFE
7. 0xXX (An error has occurred. Data read is undefined. 5 bytes remaining of the Data
field)
8. 0xXX (More undefined data)
9. 0x02 (Status byte)
10. 0x00 (Bytes remaining MSB)
11. 0x05 (Bytes remaining LSB)
12. 0xXX (CRC MSB)
13. 0xXX (CRC LSB)
The error occurred after reading 2 bytes on the SAB. The rest of the bytes read are undefined.
The status byte indicates the error and the bytes remaining indicates how many bytes were
remaining to be sent of the data field of the packet when the error occurred.
Table 34-52. MEMDATA Status Byte
status byte Description
0x00 Read successful
0x01 SAB busy
0x02 Bus error (wrong address)
Other Reserved
Table 34-53. MEMDATA Details
Response Details
Response value 0xC1
Additional data Data read, status byte, and byte count (2 bytes)
895
32142D–06/2013
ATUC64/128/256L3/4U
34.6.8.5 MEMORY_READWRITE_STATUS
After a MEMORY_WRITE command this response is sent by AW. The response can also be
sent after a MEMORY_READ command if AW encountered an error when receiving the
address. The response contains 3 bytes, where the first is the status of the command and the 2
next contains the byte count when the first error occurred. The first byte is encoded this way:
34.6.8.6 BAUD_RATE
The current baud rate in the AW. See Section 34.6.6.7 for more details.
34.6.8.7 STATUS_INFO
A status message from AW.
Table 34-54. MEMORY_READWRITE_STATUS Status Byte
status byte Description
0x00 Write successful
0x01 SAB busy
0x02 Bus error (wrong address)
Other Reserved
Table 34-55. MEMORY_READWRITE_STATUS Details
Response Details
Response value 0xC2
Additional data Status byte and byte count (2 bytes)
Table 34-56. BAUD_RATE Details
Response Details
Response value 0xC3
Additional data Baud rate
Table 34-57. STATUS_INFO Contents
Bit number Name Description
15-9 Reserved
8 Protected The protection bit in the internal flash is set. SAB access is restricted. This bit
will read as one during reset.
7 SAB busy
The SAB bus is busy with a previous transfer. This could indicate that the CPU
is running on a very slow clock, the CPU clock has stopped for some reason
or that the part is in constant reset.
6 Chip erase ongoing The Chip erase operation has not finished.
5 CPU halted This bit will be set if the CPU is halted. This bit will read as zero during reset.
4-1 Reserved
0 Reset status This bit will be set if AW has reset the CPU using the RESET command.
896
32142D–06/2013
ATUC64/128/256L3/4U
34.6.8.8 MEMORY_SPEED
Counts the number of RC120M clock cycles it takes to sync one message to the SAB interface
and back again. The SAB clock speed ( ) can be calculated using the following formula:
34.6.9 Security Restrictions
When the security fuse in the Flash is programmed, the following aWire commands are limited:
• MEMORY_WRITE
• MEMORY_READ
Unlimited access to these instructions is restored when the security fuse is erased by the
CHIP_ERASE aWire command.
Note that the security bit will read as programmed and block these instructions also if the Flash
Controller is statically reset.
Table 34-58. STATUS_INFO Details
Response Details
Response value 0xC4
Additional data 2 status bytes
Table 34-59. MEMORY_SPEED Details
Response Details
Response value 0xC5
Additional data Clock cycle count (MS)
f
sab
f
sab
3f
aw
CV – 3 = ----------------
897
32142D–06/2013
ATUC64/128/256L3/4U
35. Electrical Characteristics
35.1 Absolute Maximum Ratings*
Notes: 1. 5V tolerant pins, see Section ”Peripheral Multiplexing on I/O lines” on page 10
2. VVDD corresponds to either VVDDIN or VVDDIO, depending on the supply for the pin. Refer to Section on page 10 for details.
35.2 Supply Characteristics
The following characteristics are applicable to the operating temperature range: TA = -40°C to
85°C, unless otherwise specified and are valid for a junction temperature up to TJ = 100°C.
Please refer to Section 6. ”Supply and Startup Considerations” on page 39.
Table 35-1. Absolute Maximum Ratings
Operating temperature..................................... -40C to +85C *NOTICE: Stresses beyond those listed under
“Absolute Maximum Ratings” may cause
permanent damage to the device. This is
a stress rating only and functional operation
of the device at these or other conditions
beyond those indicated in the
operational sections of this specification is
not implied. Exposure to absolute maximum
rating conditions for extended periods
may affect device reliability.
Storage temperature...................................... -60°C to +150°C
Voltage on input pins (except for 5V pins) with respect to ground
.................................................................-0.3V to VVDD(2)+0.3V
Voltage on 5V tolerant(1) pins with respect to ground ...............
.............................................................................-0.3V to 5.5V
Total DC output current on all I/O pins - VDDIO, 64-pin package
............... ......................................................................141 mA
Total DC output current on all I/O pins - VDDIN, 64-pin package
....................................................................................... 42 mA
Total DC output current on all I/O pins - VDDIO, 48-pin package
........... ...........................................................................120mA
Total DC output current on all I/O pins - VDDIN, 48-pin package
....................................................................................... 39 mA
Maximum operating voltage VDDCORE......................... 1.98V
Maximum operating voltage VDDIO, VDDIN .................... 3.6V
Table 35-2. Supply Characteristics
Symbol Parameter
Voltage
Min Max Unit
VVDDIO DC supply peripheral I/Os 1.62 3.6 V
VVDDIN
DC supply peripheral I/Os, 1.8V
single supply mode 1.62 1.98 V
DC supply peripheral I/Os and
internal regulator, 3.3V supply
mode
1.98 3.6 V
VVDDCORE DC supply core 1.62 1.98 V
VVDDANA Analog supply voltage 1.62 1.98 V
898
32142D–06/2013
ATUC64/128/256L3/4U
Note: 1. These values are based on simulation and characterization of other AVR microcontrollers
manufactured in the same process technology. These values are not covered by test limits in
production.
35.3 Maximum Clock Frequencies
These parameters are given in the following conditions:
• VVDDCORE = 1.62V to 1.98V
• Temperature = -40°C to 85°C
35.4 Power Consumption
The values in Table 35-5 are measured values of power consumption under the following conditions,
except where noted:
• Operating conditions, internal core supply (Figure 35-1) - this is the default configuration
– VVDDIN = 3.0V
Table 35-3. Supply Rise Rates and Order(1)
Symbol Parameter
Rise Rate
Min Max Unit Comment
VVDDIO DC supply peripheral I/Os 0 2.5 V/µs
VVDDIN
DC supply peripheral I/Os
and internal regulator 0.002 2.5 V/µs
Slower rise time requires
external power-on reset
circuit.
VVDDCORE DC supply core 0 2.5 V/µs Rise before or at the same
time as VDDIO
VVDDANA Analog supply voltage 0 2.5 V/µs Rise together with
VDDCORE
Table 35-4. Clock Frequencies
Symbol Parameter Description Min Max Units
fCPU CPU clock frequency 50
MHz
fPBA PBA clock frequency 50
fPBB PBB clock frequency 50
fGCLK0 GCLK0 clock frequency DFLLIF main reference, GCLK0 pin 50
fGCLK1 GCLK1 clock frequency DFLLIF dithering and SSG reference, GCLK1 pin 50
fGCLK2 GCLK2 clock frequency AST, GCLK2 pin 20
fGCLK3 GCLK3 clock frequency PWMA, GCLK3 pin 140
fGCLK4 GCLK4 clock frequency CAT, ACIFB, GCLK4 pin 50
fGCLK5 GCLK5 clock frequency GLOC and GCLK5 pin 80
fGCLK6 GCLK6 clock frequency ABDACB, IISC, and GCLK6 pin 50
fGCLK7 GCLK7 clock frequency USBC and GCLK7 pin 50
fGCLK8 GCLK8 clock frequency PLL0 source clock and GCLK8 pin 50
fGCLK9 GCLK9 clock frequency FREQM, GCLK0-8, GCLK9 pin 150
899
32142D–06/2013
ATUC64/128/256L3/4U
– VVDDCORE = 1.62V, supplied by the internal regulator
– Corresponds to the 3.3V supply mode with 1.8V regulated I/O lines, please refer to
the Supply and Startup Considerations section for more details
• Equivalent to the 3.3V single supply mode
• Consumption in 1.8V single supply mode can be estimated by subtracting the regulator
static current
• Operating conditions, external core supply (Figure 35-2) - used only when noted
– VVDDIN = VVDDCORE = 1.8V
– Corresponds to the 1.8V single supply mode, please refer to the Supply and Startup
Considerations section for more details
• TA = 25C
• Oscillators
– OSC0 (crystal oscillator) stopped
– OSC32K (32KHz crystal oscillator) running with external 32KHz crystal
– DFLL running at 50MHz with OSC32K as reference
• Clocks
– DFLL used as main clock source
– CPU, HSB, and PBB clocks undivided
– PBA clock divided by 4
– The following peripheral clocks running
• PM, SCIF, AST, FLASHCDW, PBA bridge
– All other peripheral clocks stopped
• I/Os are inactive with internal pull-up
• Flash enabled in high speed mode
• POR18 enabled
• POR33 disabled
900
32142D–06/2013
ATUC64/128/256L3/4U
Note: 1. These numbers are valid for the measured condition only and must not be extrapolated to other frequencies.
Figure 35-1. Measurement Schematic, Internal Core Supply
Table 35-5. Power Consumption for Different Operating Modes
Mode Conditions Measured on Consumption Typ Unit
Active(1) CPU running a recursive Fibonacci algorithm
Amp0
300
µA/MHz
CPU running a division algorithm 174
Idle(1) 96
Frozen(1) 57
Standby(1) 46
Stop 38
µA
DeepStop 25
Static
-OSC32K and AST stopped
-Internal core supply
14
-OSC32K running
-AST running at 1KHz
-External core supply (Figure 35-2)
7.3
-OSC32K and AST stopped
-External core supply (Figure 35-2) 6.7
Shutdown
-OSC32K running
-AST running at 1KHz 800
nA
AST and OSC32K stopped 220
Amp0 VDDIN
VDDCORE
VDDANA
VDDIO
901
32142D–06/2013
ATUC64/128/256L3/4U
Figure 35-2. Measurement Schematic, External Core Supply
Amp0 VDDIN
VDDCORE
VDDANA
VDDIO
902
32142D–06/2013
ATUC64/128/256L3/4U
35.5 I/O Pin Characteristics
Notes: 1. VVDD corresponds to either VVDDIN or VVDDIO, depending on the supply for the pin. Refer to Section on page 10 for details.
2. These values are based on simulation and characterization of other AVR microcontrollers manufactured in the same process
technology. These values are not covered by test limits in production.
Table 35-6. Normal I/O Pin Characteristics(1)
Symbol Parameter Condition Min Typ Max Units
RPULLUP Pull-up resistance 75 100 145 kOhm
VIL Input low-level voltage
VVDD = 3.0V -0.3 0.3 * VVDD V
VVDD = 1.62V -0.3 0.3 * VVDD
VIH Input high-level voltage
VVDD = 3.6V 0.7 * VVDD VVDD + 0.3
V
VVDD = 1.98V 0.7 * VVDD VVDD + 0.3
VOL Output low-level voltage
VVDD = 3.0V, IOL = 3mA 0.4
V
VVDD = 1.62V, IOL = 2mA 0.4
VOH Output high-level voltage
VVDD = 3.0V, IOH = 3mA VVDD - 0.4
V
VVDD = 1.62V, IOH = 2mA VVDD - 0.4
fMAX Output frequency(2)
VVDD = 3.0V, load = 10pF 45
MHz
VVDD = 3.0V, load = 30pF 23
tRISE Rise time(2)
VVDD = 3.0V, load = 10pF 4.7
ns
VVDD = 3.0V, load = 30pF 11.5
tFALL Fall time(2)
VVDD = 3.0V, load = 10pF 4.8
VVDD = 3.0V, load = 30pF 12
ILEAK Input leakage current Pull-up resistors disabled 1 µA
CIN
Input capacitance, all
normal I/O pins except
PA05, PA07, PA17, PA20,
PA21, PB04, PB05
TQFP48 package 1.4
pF
QFN48 package 1.1
TLLGA48 package 1.1
TQFP64 package 1.5
QFN64 package 1.1
CIN Input capacitance, PA20
TQFP48 package 2.7
QFN48 package 2.4
TLLGA48 package 2.4
TQFP64 package 2.8
QFN64 package 2.4
CIN
Input capacitance, PA05,
PA07, PA17, PA21, PB04,
PB05
TQFP48 package 3.8
QFN48 package 3.5
TLLGA48 package 3.5
TQFP64 package 3.9
QFN64 package 3.5
903
32142D–06/2013
ATUC64/128/256L3/4U
Notes: 1. VVDD corresponds to either VVDDIN or VVDDIO, depending on the supply for the pin. Refer to Section on page 10 for details.
Table 35-7. High-drive I/O Pin Characteristics(1)
Symbol Parameter Condition Min Typ Max Units
RPULLUP Pull-up resistance
PA06 30 50 110
PA02, PB01, RESET 75 100 145 kOhm
PA08, PA09 10 20 45
VIL Input low-level voltage
VVDD = 3.0V -0.3 0.3 * VVDD V
VVDD = 1.62V -0.3 0.3 * VVDD
VIH Input high-level voltage
VVDD = 3.6V 0.7 * VVDD VVDD + 0.3
V
VVDD = 1.98V 0.7 * VVDD VVDD + 0.3
VOL Output low-level voltage
VVDD = 3.0V, IOL = 6mA 0.4
V
VVDD = 1.62V, IOL = 4mA 0.4
VOH Output high-level voltage
VVDD = 3.0V, IOH = 6mA VVDD - 0.4
V
VVDD = 1.62V, IOH = 4mA VVDD - 0.4
fMAX
Output frequency, all High-drive I/O
pins, except PA08 and PA09(2)
VVDD = 3.0V, load = 10pF 45
MHz
VVDD = 3.0V, load = 30pF 23
tRISE
Rise time, all High-drive I/O pins, except
PA08 and PA09(2)
VVDD = 3.0V, load = 10pF 4.7
ns
VVDD = 3.0V, load = 30pF 11.5
tFALL
Fall time, all High-drive I/O pins, except
PA08 and PA09(2)
VVDD = 3.0V, load = 10pF 4.8
VVDD = 3.0V, load = 30pF 12
fMAX Output frequency, PA08 and PA09(2)
VVDD = 3.0V, load = 10pF 54
MHz
VVDD = 3.0V, load = 30pF 40
tRISE Rise time, PA08 and PA09(2)
VVDD = 3.0V, load = 10pF 2.8
ns
VVDD = 3.0V, load = 30pF 4.9
tFALL Fall time, PA08 and PA09(2)
VVDD = 3.0V, load = 10pF 2.4
VVDD = 3.0V, load = 30pF 4.6
ILEAK Input leakage current Pull-up resistors disabled 1 µA
CIN
Input capacitance, all High-drive I/O
pins, except PA08 and PA09
TQFP48 package 2.2
pF
QFN48 package 2.0
TLLGA48 package 2.0
TQFP64 package 2.3
QFN64 package 2.0
CIN Input capacitance, PA08 and PA09
TQFP48 package 7.0
QFN48 package 6.7
TLLGA48 package 6.7
TQFP64 package 7.1
QFN64 package 6.7
904
32142D–06/2013
ATUC64/128/256L3/4U
2. These values are based on simulation and characterization of other AVR microcontrollers manufactured in the same process
technology. These values are not covered by test limits in production.
Notes: 1. VVDD corresponds to either VVDDIN or VVDDIO, depending on the supply for the pin. Refer to Section on page 10 for details.
2. These values are based on simulation and characterization of other AVR microcontrollers manufactured in the same process
technology. These values are not covered by test limits in production.
Table 35-8. High-drive I/O, 5V Tolerant, Pin Characteristics(1)
Symbol Parameter Condition Min Typ Max Units
RPULLUP Pull-up resistance 30 50 110 kOhm
VIL Input low-level voltage
VVDD = 3.0V -0.3 0.3 * VVDD V
VVDD = 1.62V -0.3 0.3 * VVDD
VIH Input high-level voltage
VVDD = 3.6V 0.7 * VVDD 5.5
V
VVDD = 1.98V 0.7 * VVDD 5.5
VOL Output low-level voltage
VVDD = 3.0V, IOL = 6mA 0.4
V
VVDD = 1.62V, IOL = 4mA 0.4
VOH Output high-level voltage
VVDD = 3.0V, IOH = 6mA VVDD - 0.4
V
VVDD = 1.62V, IOH = 4mA VVDD - 0.4
fMAX Output frequency(2)
VVDD = 3.0V, load = 10pF 87
MHz
VVDD = 3.0V, load = 30pF 58
tRISE Rise time(2)
VVDD = 3.0V, load = 10pF 2.3
ns
VVDD = 3.0V, load = 30pF 4.3
tFALL Fall time(2)
VVDD = 3.0V, load = 10pF 1.9
VVDD = 3.0V, load = 30pF 3.7
ILEAK Input leakage current 5.5V, pull-up resistors disabled 10 µA
CIN Input capacitance
TQFP48 package 4.5
pF
QFN48 package 4.2
TLLGA48 package 4.2
TQFP64 package 4.6
QFN64 package 4.2
Table 35-9. TWI Pin Characteristics(1)
Symbol Parameter Condition Min Typ Max Units
RPULLUP Pull-up resistance 25 35 60 kOhm
VIL Input low-level voltage
VVDD = 3.0V -0.3 0.3 * VVDD V
VVDD = 1.62V -0.3 0.3 * VVDD
VIH
Input high-level voltage
VVDD = 3.6V 0.7 * VVDD VVDD + 0.3
V
VVDD = 1.98V 0.7 * VVDD VVDD + 0.3
Input high-level voltage, 5V tolerant
SMBUS compliant pins
VVDD = 3.6V 0.7 * VVDD 5.5
V
VVDD = 1.98V 0.7 * VVDD 5.5
905
32142D–06/2013
ATUC64/128/256L3/4U
Note: 1. VVDD corresponds to either VVDDIN or VVDDIO, depending on the supply for the pin. Refer to Section on page 10 for details.
35.6 Oscillator Characteristics
35.6.1 Oscillator 0 (OSC0) Characteristics
35.6.1.1 Digital Clock Characteristics
The following table describes the characteristics for the oscillator when a digital clock is applied
on XIN.
Note: 1. These values are based on simulation and characterization of other AVR microcontrollers manufactured in the same process
technology. These values are not covered by test limits in production.
35.6.1.2 Crystal Oscillator Characteristics
The following table describes the characteristics for the oscillator when a crystal is connected
between XIN and XOUT as shown in Figure 35-3. The user must choose a crystal oscillator
where the crystal load capacitance CL is within the range given in the table. The exact value of CL
VOL Output low-level voltage IOL = 3mA 0.4 V
ILEAK Input leakage current Pull-up resistors disabled 1
IIL Input low leakage 1 µA
IIH Input high leakage 1
CIN Input capacitance
TQFP48 package 3.8
pF
QFN48 package 3.5
TLLGA48 package 3.5
TQFP64 package 3.9
QFN64 package 3.5
tFALL Fall time
Cbus = 400pF, VVDD > 2.0V 250
ns
Cbus = 400pF, VVDD > 1.62V 470
fMAX Max frequency Cbus = 400pF, VVDD > 2.0V 400 kHz
Table 35-9. TWI Pin Characteristics(1)
Symbol Parameter Condition Min Typ Max Units
Table 35-10. Digital Clock Characteristics
Symbol Parameter Conditions Min Typ Max Units
fCPXIN XIN clock frequency 50 MHz
tCPXIN XIN clock duty cycle(1) 40 60 %
tSTARTUP Startup time 0 cycles
CIN XIN input capacitance
TQFP48 package 7.0
pF
QFN48 package 6.7
TLLGA48 package 6.7
TQFP64 package 7.1
QFN64 package 6.7
906
32142D–06/2013
ATUC64/128/256L3/4U
can be found in the crystal datasheet. The capacitance of the external capacitors (CLEXT) can
then be computed as follows:
where CPCB is the capacitance of the PCB and Ci
is the internal equivalent load capacitance.
Notes: 1. Please refer to the SCIF chapter for details.
2. Nominal crystal cycles.
3. These values are based on simulation and characterization of other AVR microcontrollers manufactured in the same process
technology. These values are not covered by test limits in production.
Figure 35-3. Oscillator Connection
CLEXT 2 CL Ci – CPCB = –
Table 35-11. Crystal Oscillator Characteristics
Symbol Parameter Conditions Min Typ Max Unit
fOUT Crystal oscillator frequency(3) 0.45 10 16 MHz
CL Crystal load capacitance(3) 6 18
pF
Ci Internal equivalent load capacitance 2
tSTARTUP Startup time SCIF.OSCCTRL.GAIN = 2(1) 30 000(2) cycles
IOSC Current consumption
Active mode, f = 0.45MHz,
SCIF.OSCCTRL.GAIN = 0 30
µA Active mode, f = 10MHz,
SCIF.OSCCTRL.GAIN = 2 220
XIN
XOUT
CLEXT
CLEXT
CL
Ci
UC3L
907
32142D–06/2013
ATUC64/128/256L3/4U
35.6.2 32KHz Crystal Oscillator (OSC32K) Characteristics
Figure 35-3 and the equation above also applies to the 32KHz oscillator connection. The user
must choose a crystal oscillator where the crystal load capacitance CL is within the range given
in the table. The exact value of CL can then be found in the crystal datasheet.
Notes: 1. Nominal crystal cycles.
2. These values are based on simulation and characterization of other AVR microcontrollers manufactured in the same process
technology. These values are not covered by test limits in production.
35.6.3 Phase Locked Loop (PLL) Characteristics
Note: 1. These values are based on simulation and characterization of other AVR microcontrollers manufactured in the same process
technology. These values are not covered by test limits in production.
Table 35-12. 32 KHz Crystal Oscillator Characteristics
Symbol Parameter Conditions Min Typ Max Unit
fOUT Crystal oscillator frequency 32 768 Hz
tSTARTUP Startup time RS = 60kOhm, CL = 9pF 30 000(1) cycles
CL Crystal load capacitance(2) 6 12.5
pF Ci
Internal equivalent load
capacitance 2
IOSC32 Current consumption 0.6 µA
RS Equivalent series resistance(2) 32 768Hz 35 85 kOhm
Table 35-13. Phase Locked Loop Characteristics
Symbol Parameter Conditions Min Typ Max Unit
fOUT Output frequency(1) 40 240
MHz
fIN Input frequency(1) 4 16
IPLL Current consumption 8 µA/MHz
tSTARTUP
Startup time, from enabling
the PLL until the PLL is
locked
fIN= 4MHz 200
µs
fIN= 16MHz 155
908
32142D–06/2013
ATUC64/128/256L3/4U
35.6.4 Digital Frequency Locked Loop (DFLL) Characteristics
Notes: 1. Spread Spectrum Generator (SSG) is disabled by writing a zero to the EN bit in the DFLL0SSG register.
2. These values are based on simulation and characterization of other AVR microcontrollers manufactured in the same process
technology. These values are not covered by test limits in production.
3. The FINE and COARSE values are selected by wrirting to the DFLL0VAL.FINE and DFLL0VAL.COARSE field respectively.
Table 35-14. Digital Frequency Locked Loop Characteristics
Symbol Parameter Conditions Min Typ Max Unit
fOUT Output frequency(2) 20 150 MHz
fREF Reference frequency(2) 8 150 kHz
FINE resolution step FINE > 100, all COARSE values (3) 0.38 %
Frequency drift over voltage
and temperature Open loop mode See Figure
35-4
Accuracy(2)
FINE lock, fREF = 32kHz, SSG disabled 0.1 0.5
%
ACCURATE lock, fREF = 32kHz, dither clk
RCSYS/2, SSG disabled 0.06 0.5
FINE lock, fREF = 8-150kHz, SSG
disabled 0.2 1
ACCURATE lock, fREF = 8-150kHz,
dither clk RCSYS/2, SSG disabled 0.1 1
IDFLL Power consumption 25 µA/MHz
tSTARTUP Startup time(2) Within 90% of final values 100 µs
tLOCK Lock time
fREF = 32kHz, FINE lock, SSG disabled 8
ms fREF = 32kHz, ACCURATE lock, dithering
clock = RCSYS/2, SSG disabled 28
909
32142D–06/2013
ATUC64/128/256L3/4U
Figure 35-4. DFLL Open Loop Frequency Variation(1)(2)
Notes: 1. The plot shows a typical open loop mode behavior with COARSE= 99 and FINE= 255.
2. These values are based on simulation and characterization of other AVR microcontrollers manufactured in the same process
technology. These values are not covered by test limits in production.
35.6.5 120MHz RC Oscillator (RC120M) Characteristics
Note: 1. These values are based on simulation and characterization of other AVR microcontrollers manufactured in the same process
technology. These values are not covered by test limits in production.
DFLL Open Loop Frequency variation
80
90
100
110
120
130
140
150
160
-40 -20 0 20 40 60 80
Temperature
Frequencies (MHz)
1,98V
1,8V
1.62V
Table 35-15. Internal 120MHz RC Oscillator Characteristics
Symbol Parameter Conditions Min Typ Max Unit
fOUT Output frequency(1) 88 120 152 MHz
IRC120M Current consumption 1.2 mA
tSTARTUP Startup time(1) VVDDCORE = 1.8V 3 µs
910
32142D–06/2013
ATUC64/128/256L3/4U
35.6.6 32kHz RC Oscillator (RC32K) Characteristics
Note: 1. These values are based on simulation and characterization of other AVR microcontrollers manufactured in the same process
technology. These values are not covered by test limits in production.
35.6.7 System RC Oscillator (RCSYS) Characteristics
35.7 Flash Characteristics
Table 35-18 gives the device maximum operating frequency depending on the number of flash
wait states and the flash read mode. The FSW bit in the FLASHCDW FSR register controls the
number of wait states used when accessing the flash memory.
Table 35-16. 32kHz RC Oscillator Characteristics
Symbol Parameter Conditions Min Typ Max Unit
fOUT Output frequency(1) 20 32 44 kHz
IRC32K Current consumption 0.7 µA
tSTARTUP Startup time(1) 100 µs
Table 35-17. System RC Oscillator Characteristics
Symbol Parameter Conditions Min Typ Max Unit
fOUT Output frequency Calibrated at 85C 111.6 115 118.4 kHz
Table 35-18. Maximum Operating Frequency
Flash Wait States Read Mode Maximum Operating Frequency
1
High speed read mode
50MHz
0 25MHz
1
Normal read mode
30MHz
0 15MHz
Table 35-19. Flash Characteristics
Symbol Parameter Conditions Min Typ Max Unit
tFPP Page programming time
fCLK_HSB = 50MHz
5
ms
tFPE Page erase time 5
tFFP Fuse programming time 1
tFEA Full chip erase time (EA) 6
tFCE JTAG chip erase time (CHIP_ERASE) fCLK_HSB = 115kHz 310
911
32142D–06/2013
ATUC64/128/256L3/4U
35.8 ABDACB Electrical Characteristics.
Notes: 1. Test Condition: Common Mode Offset Control disabled (CR.CMOC = 0). Alternative Upsampling Ratio disabled
(CR.ALTUPR = 0). Volume at maximum level (VCR0.VOLUME = 0x7FFF and VCR1.VOLUME = 0x7FFF). Device is battery
powered (9V) through an LDO, VDDIO at 3.3V. Analog low pass filter as shown in Figure 35-5(1. order differential low pass
filter followed by a 4. order low-pass), +VCC at +9V and -VCC at -9V. Test signal stored on a SD card and read by the SPI
Interface.
2. Performance numbers for dynamic range, SNR, and THD performance are very dependent on the application and circuit
board design. Since the design has 0dB Power Supply Rejection Ratio (PSRR), noise on the IO power supply will couple
directly through to the output and be present in the audio signal. To get the best performance one should reduce toggling of
other IO pins as much as possible and make sure the device has sufficient decoupling on the IO supply pins.
3. These values are based on simulation and characterization of other AVR microcontrollers manufactured in the same process
technology. These values are not covered by test limits in production.
Figure 35-5. Differential Analog Low-pass Filter
Table 35-20. Flash Endurance and Data Retention
Symbol Parameter Conditions Min Typ Max Unit
NFARRAY Array endurance (write/page) 100k
cycles
NFFUSE General Purpose fuses endurance (write/bit) 10k
tRET Data retention 15 years
Table 35-21. ABDACB Electrical Characteristics
Symbol Parameter Conditions MIN TYP MAX Unit
Resolution 16 Bits
Dynamic range(1)(2)(3) FS = 48.000kHz > 76 dB
SNR(1)(2)(3) FS = 48.000kHz > 46 dB
THD(1)(2)(3) FS = 48.000kHz < 0.02 %
PSRR 0 dB
VOut maximum CR.CMOC = 0 97/128 * VDDIO V
VOut minimum CR.CMOC = 0 31/128 * VDDIO V
Common mode
CR.CMOC = 0
CR.CMOC = 1, DAC_0 and DAC_1 pins
CR.CMOC = 1, DACN_0 and DACN_1 pins
64/128 * VDDIO
80/128 * VDDIO
48/128 * VDDIO
V
R1, 22K
C2
140p
R2, 22K
R4, 22K
C1, 140p
R3, 22K
R6, 22K
R5, 22K
R7, 22K
C4
270p
C3
310p
-Vcc
+Vcc
-Vcc
+Vcc
DAC
DACN
R8, 22K R9, 22K
C6
110p
C5
750p
-Vcc
+Vcc
GND GND GND GND GND
Out
912
32142D–06/2013
ATUC64/128/256L3/4U
35.9 Analog Characteristics
35.9.1 Voltage Regulator Characteristics
Note: 1. These values are based on simulation and characterization of other AVR microcontrollers manufactured in the same process
technology. These values are not covered by test limits in production.
Note: 1. Refer to Section 6.1.2 on page 39.
Table 35-22. VREG Electrical Characteristics
Symbol Parameter Condition Min Typ Max Units
VVDDIN Input voltage range 1.98 3.3 3.6
V
VVDDCORE Output voltage, calibrated value VVDDIN >= 1.98V 1.8
Output voltage accuracy(1)
IOUT = 0.1mA to 60mA,
VVDDIN > 1.98V
2
%
IOUT = 0.1mA to 60mA,
VVDDIN <1.98V
4
IOUT DC output current(1)
Normal mode 60
mA
Low power mode 1
IVREG Static current of internal regulator
Normal mode 13
µA
Low power mode 4
Table 35-23. Decoupling Requirements
Symbol Parameter Condition Typ Techno. Units
CIN1 Input regulator capacitor 1 33
nF
CIN2 Input regulator capacitor 2 100
CIN3 Input regulator capacitor 3 10 µF
COUT1 Output regulator capacitor 1 100 nF
COUT2 Output regulator capacitor 2 2.2 Tantalum
0.5 3.0V, fADC = 6MHz,
12-bit resolution mode,
low impedance source
28
kSPS
VVDD > 3.0V, fADC = 6MHz,
10-bit resolution mode,
low impedance source
460
VVDD > 3.0V, fADC = 6MHz,
8-bit resolution mode,
low impedance source
460
VADVREFP Reference voltage range VADVREFP = VVDDANA 1.62 1.98 V
IADC Current consumption on VVDDANA ADC Clock = 6MHz 350
µA
IADVREFP
Current consumption on ADVREFP
pin fADC = 6MHz 150
Table 35-30. Analog Inputs
Symbol Parameter Conditions Min Typ Max Units
VADn Input Voltage Range
12-bit mode
10-bit mode 0 VADVREFP V
8-bit mode
CONCHIP Internal Capacitance(1) 22.5 pF
RONCHIP Internal Resistance(1)
VVDDIO = 3.0V to 3.6V,
VVDDCORE = 1.8V 3.15
kOhm
VVDDIO = VVDDCORE = 1.62V to 1.98V 55.9
RONCHIP CONCHIP RSOURCE
917
32142D–06/2013
ATUC64/128/256L3/4U
( ) of the PCB and source must be taken into account when calculating the required
sample and hold time. Figure 35-8 shows the ADC input channel equivalent circuit.
Figure 35-8. ADC Input
The minimum sample and hold time (in ns) can be found using this formula:
Where n is the number of bits in the conversion. is defined by the SHTIM field in the
ADCIFB ACR register. Please refer to the ADCIFB chapter for more information.
35.9.6.2 Applicable Conditions and Derating Data
Note: 1. These values are based on simulation and characterization of other AVR microcontrollers manufactured in the same process
technology. These values are not covered by test limits in production.
CSOURCE
ADCVREFP/2
CONCHIP
RONCHIP R Positive Input SOURCE
CSOURCE VIN
t
SAMPLEHOLD RONCHIP + RSOURCE CONCHIP CSOURCE + 2n + 1 ln
t
SAMPLEHOLD
Table 35-31. Transfer Characteristics 12-bit Resolution Mode(1)
Parameter Conditions Min Typ Max Units
Resolution 12 Bit
Integral non-linearity
ADC clock frequency = 6MHz,
Input Voltage Range = 0 - VADVREFP
+/-4
LSB
ADC clock frequency = 6MHz,
Input Voltage Range = (10% VADVREFP) -
(90% VADVREFP)
+/-2
Differential non-linearity
ADC clock frequency = 6MHz
-1.5 1.5
Offset error +/-3
Gain error +/-5
Table 35-32. Transfer Characteristics, 10-bit Resolution Mode(1)
Parameter Conditions Min Typ Max Units
Resolution 10 Bit
Integral non-linearity
ADC clock frequency = 6MHz
+/-1
LSB Differential non-linearity -1.0 1.0
Offset error +/-1
Gain error +/-2
918
32142D–06/2013
ATUC64/128/256L3/4U
Note: 1. These values are based on simulation and characterization of other AVR microcontrollers manufactured in the same process
technology. These values are not covered by test limits in production.
Note: 1. These values are based on simulation and characterization of other AVR microcontrollers manufactured in the same process
technology. These values are not covered by test limits in production.
35.9.7 Temperature Sensor Characteristics
Note: 1. The Temperature Sensor is not calibrated. The accuracy of the Temperature Sensor is governed by the ADC accuracy.
Table 35-33. Transfer Characteristics, 8-bit Resolution Mode(1)
Parameter Conditions Min Typ Max Units
Resolution 8 Bit
Integral non-linearity
ADC clock frequency = 6MHz
+/-0.5
LSB Differential non-linearity -0.3 0.3
Offset error +/-1
Gain error +/-1
Table 35-34. Temperature Sensor Characteristics(1)
Symbol Parameter Condition Min Typ Max Units
Gradient 1 mV/°C
ITS Current consumption 1 µA
tSTARTUP Startup time 0 µs
919
32142D–06/2013
ATUC64/128/256L3/4U
35.9.8 Analog Comparator Characteristics
Notes: 1. AC.CONFn.FLEN and AC.CONFn.HYS fields, refer to the Analog Comparator Interface chapter.
2. Referring to fAC.
3. These values are based on simulation and characterization of other AVR microcontrollers manufactured in the same process
technology. These values are not covered by test limits in production.
35.9.9 Capacitive Touch Characteristics
35.9.9.1 Discharge Current Source
Note: 1. These values are based on simulation and characterization of other AVR microcontrollers manufactured in the same process
technology. These values are not covered by test limits in production.
Table 35-35. Analog Comparator Characteristics
Symbol Parameter Condition Min Typ Max Units
Positive input
voltage range(3) -0.2 VVDDIO + 0.3
V
Negative input
voltage range(3) -0.2 VVDDIO - 0.6
Statistical offset(3)
VACREFN = 1.0V,
fAC = 12MHz,
filter length = 2,
hysteresis = 0(1)
20 mV
fAC
Clock frequency for
GCLK4(3) 12 MHz
Throughput rate(3) fAC = 12MHz 12 000 000 Comparisons
per second
Propagation delay
Delay from input
change to
Interrupt Status
Register Changes
ns
IAC
Current
consumption(3)
All channels,
VDDIO = 3.3V,
fA = 3MHz
420 µA
tSTARTUP Startup time 3 cycles
Input current per
pin(3) 0.2 µA/MHz(2)
Table 35-36. DICS Characteristics
Symbol Parameter Min Typ Max Unit
RREF Internal resistor 170 kOhm
k Trim step size(1) 0.7 %
1
t
CLKACIFB f
AC ---------------------------------------- + 3 t
CLKACIFB
920
32142D–06/2013
ATUC64/128/256L3/4U
35.9.9.2 Strong Pull-up Pull-down
35.9.10 USB Transceiver Characteristics
The USB on-chip buffers comply with the Universal Serial Bus (USB) v2.0 standard. All AC
parameters related to these buffers can be found within the USB 2.0 electrical specifications.
35.9.10.1 Electrical Characteristics
Table 35-37. Strong Pull-up Pull-down
Parameter Min Typ Max Unit
Pull-down resistor 1
kOhm
Pull-up resistor 1
Table 35-38. Electrical Parameters
Symbol Parameter Conditions Min Typ Max Unit
REXT
Recommended external USB
series resistor
In series with each USB pin with
±5% 39 Ohm
921
32142D–06/2013
ATUC64/128/256L3/4U
35.10 Timing Characteristics
35.10.1 Startup, Reset, and Wake-up Timing
The startup, reset, and wake-up timings are calculated using the following formula:
Where and are found in Table 35-39. is the period of the CPU clock. If a
clock source other than RCSYS is selected as the CPU clock, the oscillator startup time,
, must be added to the wake-up time from the stop, deepstop, and static sleep
modes. Please refer to the source for the CPU clock in the ”Oscillator Characteristics” on page
905 for more details about oscillator startup times.
Note: 1. These values are based on simulation and characterization of other AVR microcontrollers manufactured in the same process
technology. These values are not covered by test limits in production.
35.10.2 RESET_N Timing
Note: 1. These values are based on simulation and characterization of other AVR microcontrollers manufactured in the same process
technology. These values are not covered by test limits in production.
t tCONST NCPU t
CPU = +
t
CONST NCPU t
CPU
t
OSCSTART
Table 35-39. Maximum Reset and Wake-up Timing(1)
Parameter Measuring Max (in µs) Max
Startup time from power-up, using
regulator
Time from VDDIN crossing the VPOT+ threshold of
POR33 to the first instruction entering the decode
stage of CPU. VDDCORE is supplied by the internal
regulator.
2210 0
Startup time from power-up, no
regulator
Time from VDDIN crossing the VPOT+ threshold of
POR33 to the first instruction entering the decode
stage of CPU. VDDCORE is connected to VDDIN.
1810 0
Startup time from reset release
Time from releasing a reset source (except POR18,
POR33, and SM33) to the first instruction entering
the decode stage of CPU.
170 0
Wake-up
Idle
From wake-up event to the first instruction of an
interrupt routine entering the decode stage of the
CPU.
0 19
Frozen 0 110
Standby 0 110
Stop 27 + 116
Deepstop 27 + 116
Static 97 + 116
Wake-up from shutdown From wake-up event to the first instruction entering
the decode stage of the CPU. 1180 0
t
CONST NCPU
t
OSCSTART
t
OSCSTART
t
OSCSTART
Table 35-40. RESET_N Waveform Parameters(1)
Symbol Parameter Conditions Min Max Units
tRESET RESET_N minimum pulse length 10 ns
922
32142D–06/2013
ATUC64/128/256L3/4U
35.10.3 USART in SPI Mode Timing
35.10.3.1 Master mode
Figure 35-9. USART in SPI Master Mode with (CPOL= CPHA= 0) or (CPOL= CPHA= 1)
Figure 35-10. USART in SPI Master Mode with (CPOL= 0 and CPHA= 1) or (CPOL= 1 and
CPHA= 0)
Notes: 1. These values are based on simulation and characterization of other AVR microcontrollers manufactured in the same process
technology. These values are not covered by test limits in production.
2. Where:
USPI0 USPI1
MISO
SPCK
MOSI
USPI2
USPI3 USPI4
MISO
SPCK
MOSI
USPI5
Table 35-41. USART in SPI Mode Timing, Master Mode(1)
Symbol Parameter Conditions Min Max Units
USPI0 MISO setup time before SPCK rises
VVDDIO from
3.0V to 3.6V,
maximum
external
capacitor =
40pF
28.7 + tSAMPLE(2)
ns
USPI1 MISO hold time after SPCK rises 0
USPI2 SPCK rising to MOSI delay 16.5
USPI3 MISO setup time before SPCK falls 25.8 + tSAMPLE(2)
USPI4 MISO hold time after SPCK falls 0
USPI5 SPCK falling to MOSI delay 21.19
t
SAMPLE t
SPCK
t
SPCK
2 t
CLKUSART ------------------------------------ 1
2
-- t
CLKUSART = –
923
32142D–06/2013
ATUC64/128/256L3/4U
Maximum SPI Frequency, Master Output
The maximum SPI master output frequency is given by the following formula:
Where is the MOSI delay, USPI2 or USPI5 depending on CPOL and NCPHA. is
the maximum frequency of the SPI pins. Please refer to the I/O Pin Characteristics section for
the maximum frequency of the pins. is the maximum frequency of the CLK_SPI. Refer
to the SPI chapter for a description of this clock.
Maximum SPI Frequency, Master Input
The maximum SPI master input frequency is given by the following formula:
Where is the MISO setup and hold time, USPI0 + USPI1 or USPI3 + USPI4 depending on
CPOL and NCPHA. is the SPI slave response time. Please refer to the SPI slave
datasheet for . is the maximum frequency of the CLK_SPI. Refer to the SPI chapter
for a description of this clock.
35.10.3.2 Slave mode
Figure 35-11. USART in SPI Slave Mode with (CPOL= 0 and CPHA= 1) or (CPOL= 1 and
CPHA= 0)
f
SPCKMAX MIN fPINMAX
1
SPIn
------------ f
CLKSPI 2
9 = (, ) ----------------------------
SPIn fPINMAX
f
CLKSPI
f
SPCKMAX MIN 1
SPIn tVALID + ----------------------------------- f
CLKSPI 2
9 = ( ,) -----------------------------
SPIn
TVALID
TVALID f
CLKSPI
USPI7 USPI8
MISO
SPCK
MOSI
USPI6
924
32142D–06/2013
ATUC64/128/256L3/4U
Figure 35-12. USART in SPI Slave Mode with (CPOL= CPHA= 0) or (CPOL= CPHA= 1)
Figure 35-13. USART in SPI Slave Mode, NPCS Timing
Notes: 1. These values are based on simulation and characterization of other AVR microcontrollers manufactured in the same process
technology. These values are not covered by test limits in production.
2. Where:
USPI10 USPI11
MISO
SPCK
MOSI
USPI9
USPI14
USPI12
USPI15
USPI13
NSS
SPCK, CPOL=0
SPCK, CPOL=1
Table 35-42. USART in SPI mode Timing, Slave Mode(1)
Symbol Parameter Conditions Min Max Units
USPI6 SPCK falling to MISO delay
VVDDIO from
3.0V to 3.6V,
maximum
external
capacitor =
40pF
37.3
ns
USPI7 MOSI setup time before SPCK rises 2.6 + tSAMPLE(2) +
tCLK_USART
USPI8 MOSI hold time after SPCK rises 0
USPI9 SPCK rising to MISO delay 37.0
USPI10 MOSI setup time before SPCK falls 2.6 + tSAMPLE(2) +
tCLK_USART
USPI11 MOSI hold time after SPCK falls 0
USPI12 NSS setup time before SPCK rises 27.2
USPI13 NSS hold time after SPCK falls 0
USPI14 NSS setup time before SPCK falls 27.2
USPI15 NSS hold time after SPCK rises 0
t
SAMPLE t
SPCK
t
SPCK
2 tCLKUSART ------------------------------------ 1
2
+ -- t
CLKUSART = –
925
32142D–06/2013
ATUC64/128/256L3/4U
Maximum SPI Frequency, Slave Input Mode
The maximum SPI slave input frequency is given by the following formula:
Where is the MOSI setup and hold time, USPI7 + USPI8 or USPI10 + USPI11 depending
on CPOL and NCPHA. is the maximum frequency of the CLK_SPI. Refer to the SPI
chapter for a description of this clock.
Maximum SPI Frequency, Slave Output Mode
The maximum SPI slave output frequency is given by the following formula:
Where is the MISO delay, USPI6 or USPI9 depending on CPOL and NCPHA. is
the SPI master setup time. Please refer to the SPI master datasheet for . is the
maximum frequency of the CLK_SPI. Refer to the SPI chapter for a description of this
clock. is the maximum frequency of the SPI pins. Please refer to the I/O Pin Characteristics
section for the maximum frequency of the pins.
35.10.4 SPI Timing
35.10.4.1 Master mode
Figure 35-14. SPI Master Mode with (CPOL= NCPHA= 0) or (CPOL= NCPHA= 1)
f
SPCKMAX MIN f
CLKSPI 2
9 ----------------------------- 1
SPIn = ( ,) ------------
SPIn
f
CLKSPI
f
SPCKMAX MIN f
CLKSPI 2
9 ---------------------------- f
PINMAX 1
SPIn tSETUP + = ( ,) ------------------------------------
SPIn TSETUP
TSETUP f
CLKSPI
f
PINMAX
SPI0 SPI1
MISO
SPCK
MOSI
SPI2
926
32142D–06/2013
ATUC64/128/256L3/4U
Figure 35-15. SPI Master Mode with (CPOL= 0 and NCPHA= 1) or (CPOL= 1 and NCPHA= 0)
Note: 1. These values are based on simulation and characterization of other AVR microcontrollers manufactured in the same process
technology. These values are not covered by test limits in production.
Maximum SPI Frequency, Master Output
The maximum SPI master output frequency is given by the following formula:
Where is the MOSI delay, SPI2 or SPI5 depending on CPOL and NCPHA. is the
maximum frequency of the SPI pins. Please refer to the I/O Pin Characteristics section for the
maximum frequency of the pins.
Maximum SPI Frequency, Master Input
The maximum SPI master input frequency is given by the following formula:
Where is the MISO setup and hold time, SPI0 + SPI1 or SPI3 + SPI4 depending on
CPOL and NCPHA. is the SPI slave response time. Please refer to the SPI slave
datasheet for .
SPI3 SPI4
MISO
SPCK
MOSI
SPI5
Table 35-43. SPI Timing, Master Mode(1)
Symbol Parameter Conditions Min Max Units
SPI0 MISO setup time before SPCK rises
VVDDIO from
3.0V to 3.6V,
maximum
external
capacitor =
40pF
33.4 + (tCLK_SPI)/2
ns
SPI1 MISO hold time after SPCK rises 0
SPI2 SPCK rising to MOSI delay 7.1
SPI3 MISO setup time before SPCK falls 29.2 + (tCLK_SPI)/2
SPI4 MISO hold time after SPCK falls 0
SPI5 SPCK falling to MOSI delay 8.63
f
SPCKMAX MIN fPINMAX
1
SPIn = ( ,) ------------
SPIn f
PINMAX
f
SPCKMAX
1
SPIn tVALID + = -----------------------------------
SPIn
t
VALID
tVALID
927
32142D–06/2013
ATUC64/128/256L3/4U
35.10.4.2 Slave mode
Figure 35-16. SPI Slave Mode with (CPOL= 0 and NCPHA= 1) or (CPOL= 1 and NCPHA= 0)
Figure 35-17. SPI Slave Mode with (CPOL= NCPHA= 0) or (CPOL= NCPHA= 1)
Figure 35-18. SPI Slave Mode, NPCS Timing
SPI7 SPI8
MISO
SPCK
MOSI
SPI6
SPI10 SPI11
MISO
SPCK
MOSI
SPI9
SPI14
SPI12
SPI15
SPI13
NPCS
SPCK, CPOL=0
SPCK, CPOL=1
928
32142D–06/2013
ATUC64/128/256L3/4U
Note: 1. These values are based on simulation and characterization of other AVR microcontrollers manufactured in the same process
technology. These values are not covered by test limits in production.
Maximum SPI Frequency, Slave Input Mode
The maximum SPI slave input frequency is given by the following formula:
Where is the MOSI setup and hold time, SPI7 + SPI8 or SPI10 + SPI11 depending on
CPOL and NCPHA. is the maximum frequency of the CLK_SPI. Refer to the SPI chapter
for a description of this clock.
Maximum SPI Frequency, Slave Output Mode
The maximum SPI slave output frequency is given by the following formula:
Where is the MISO delay, SPI6 or SPI9 depending on CPOL and NCPHA. is the
SPI master setup time. Please refer to the SPI master datasheet for . is the maximum
frequency of the SPI pins. Please refer to the I/O Pin Characteristics section for the
maximum frequency of the pins.
35.10.5 TWIM/TWIS Timing
Figure 35-45 shows the TWI-bus timing requirements and the compliance of the device with
them. Some of these requirements (tr
and tf
) are met by the device without requiring user intervention.
Compliance with the other requirements (tHD-STA, tSU-STA, tSU-STO, tHD-DAT, tSU-DAT-TWI, tLOWTWI,
tHIGH, and fTWCK) requires user intervention through appropriate programming of the relevant
Table 35-44. SPI Timing, Slave Mode(1)
Symbol Parameter Conditions Min Max Units
SPI6 SPCK falling to MISO delay
VVDDIO from
3.0V to 3.6V,
maximum
external
capacitor =
40pF
29.4
ns
SPI7 MOSI setup time before SPCK rises 0
SPI8 MOSI hold time after SPCK rises 6.0
SPI9 SPCK rising to MISO delay 29.0
SPI10 MOSI setup time before SPCK falls 0
SPI11 MOSI hold time after SPCK falls 5.5
SPI12 NPCS setup time before SPCK rises 3.4
SPI13 NPCS hold time after SPCK falls 1.1
SPI14 NPCS setup time before SPCK falls 3.3
SPI15 NPCS hold time after SPCK rises 0.7
f
SPCKMAX MIN fCLKSPI
1
SPIn = ( ,) ------------
SPIn
f
CLKSPI
f
SPCKMAX MIN fPINMAX
1
SPIn tSETUP + = (, ) ------------------------------------
SPIn t
SETUP
t
SETUP fPINMAX
929
32142D–06/2013
ATUC64/128/256L3/4U
TWIM and TWIS user interface registers. Please refer to the TWIM and TWIS sections for more
information.
Notes: 1. Standard mode: ; fast mode: .
2. A device must internally provide a hold time of at least 300 ns for TWD with reference to the falling edge of TWCK.
Notations:
Cb = total capacitance of one bus line in pF
tclkpb = period of TWI peripheral bus clock
tprescaled = period of TWI internal prescaled clock (see chapters on TWIM and TWIS)
The maximum tHD;DAT has only to be met if the device does not stretch the LOW period (tLOW-TWI)
of TWCK.
Table 35-45. TWI-Bus Timing Requirements
Symbol Parameter Mode
Minimum Maximum Uni
Requirement Device Requirement Device t
tr TWCK and TWD rise time
Standard(
1) - 1000
ns
Fast(1) 20 + 0.1Cb 300
tf TWCK and TWD fall time
Standard - 300
ns
Fast 20 + 0.1Cb 300
tHD-STA (Repeated) START hold time
Standard 4
tclkpb - s
Fast 0.6
tSU-STA
(Repeated) START set-up
time
Standard 4.7
tclkpb - s
Fast 0.6
tSU-STO STOP set-up time
Standard 4.0
4tclkpb - s
Fast 0.6
tHD-DAT Data hold time
Standard
0.3(2) 2tclkpb
3.45()
15tprescaled +
tclkpb
s
Fast 0.9()
tSU-DATTWI
Data set-up time
Standard 250
2tclkpb - ns
Fast 100
tSU-DAT - -tclkpb - -
tLOW-TWI TWCK LOW period
Standard 4.7
4tclkpb - s
Fast 1.3
tLOW - -tclkpb - -
tHIGH TWCK HIGH period
Standard 4.0
8tclkpb - s
Fast 0.6
fTWCK TWCK frequency
Standard - 100
kHz
Fast 400
1
12tclkpb
-----------------------
fTWCK 100 kHz f
TWCK 100 kHz
930
32142D–06/2013
ATUC64/128/256L3/4U
35.10.6 JTAG Timing
Figure 35-19. JTAG Interface Signals
Note: 1. These values are based on simulation and characterization of other AVR microcontrollers manufactured in the same process
technology. These values are not covered by test limits in production.
JTAG2
JTAG3
JTAG1
JTAG4
JTAG0
TMS/TDI
TCK
TDO
JTAG5
JTAG6
JTAG7 JTAG8
JTAG9
JTAG10
Boundary
Scan Inputs
Boundary
Scan Outputs
Table 35-46. JTAG Timings(1)
Symbol Parameter Conditions Min Max Units
JTAG0 TCK Low Half-period
VVDDIO from
3.0V to 3.6V,
maximum
external
capacitor =
40pF
21.8
ns
JTAG1 TCK High Half-period 8.6
JTAG2 TCK Period 30.3
JTAG3 TDI, TMS Setup before TCK High 2.0
JTAG4 TDI, TMS Hold after TCK High 2.3
JTAG5 TDO Hold Time 9.5
JTAG6 TCK Low to TDO Valid 21.8
JTAG7 Boundary Scan Inputs Setup Time 0.6
JTAG8 Boundary Scan Inputs Hold Time 6.9
JTAG9 Boundary Scan Outputs Hold Time 9.3
JTAG10 TCK to Boundary Scan Outputs Valid 32.2
931
32142D–06/2013
ATUC64/128/256L3/4U
36. Mechanical Characteristics
36.1 Thermal Considerations
36.1.1 Thermal Data
Table 36-1 summarizes the thermal resistance data depending on the package.
36.1.2 Junction Temperature
The average chip-junction temperature, TJ, in °C can be obtained from the following:
1.
2.
where:
• JA = package thermal resistance, Junction-to-ambient (°C/W), provided in Table 36-1.
• JC = package thermal resistance, Junction-to-case thermal resistance (°C/W), provided in
Table 36-1.
• HEAT SINK = cooling device thermal resistance (°C/W), provided in the device datasheet.
• PD = device power consumption (W) estimated from data provided in Section 35.4 on page
898.
• TA = ambient temperature (°C).
From the first equation, the user can derive the estimated lifetime of the chip and decide if a
cooling device is necessary or not. If a cooling device is to be fitted on the chip, the second
equation should be used to compute the resulting average chip-junction temperature TJ in °C.
Table 36-1. Thermal Resistance Data
Symbol Parameter Condition Package Typ Unit
JA Junction-to-ambient thermal resistance Still Air TQFP48 54.4 C/W
JC Junction-to-case thermal resistance TQFP48 15.7
JA Junction-to-ambient thermal resistance Still Air QFN48 26.0 C/W
JC Junction-to-case thermal resistance QFN48 1.6
JA Junction-to-ambient thermal resistance Still Air TLLGA48 25.4 C/W
JC Junction-to-case thermal resistance TLLGA48 12.7
JA Junction-to-ambient thermal resistance Still Air TQFP64 52.9 C/W
JC Junction-to-case thermal resistance TQFP64 15.5
JA Junction-to-ambient thermal resistance Still Air QFN64 22.9 C/W
JC Junction-to-case thermal resistance QFN64 1.6
TJ TA PD JA = +
TJ TA PD HEATSINK JC = + +
932
32142D–06/2013
ATUC64/128/256L3/4U
36.2 Package Drawings
Figure 36-1. TQFP-48 Package Drawing
Table 36-2. Device and Package Maximum Weight
140 mg
Table 36-3. Package Characteristics
Moisture Sensitivity Level MSL3
Table 36-4. Package Reference
JEDEC Drawing Reference MS-026
JESD97 Classification E3
933
32142D–06/2013
ATUC64/128/256L3/4U
Figure 36-2. QFN-48 Package Drawing
Note: The exposed pad is not connected to anything internally, but should be soldered to ground to increase board level reliability.
Table 36-5. Device and Package Maximum Weight
140 mg
Table 36-6. Package Characteristics
Moisture Sensitivity Level MSL3
Table 36-7. Package Reference
JEDEC Drawing Reference M0-220
JESD97 Classification E3
934
32142D–06/2013
ATUC64/128/256L3/4U
Figure 36-3. TLLGA-48 Package Drawing
Table 36-8. Device and Package Maximum Weight
39.3 mg
Table 36-9. Package Characteristics
Moisture Sensitivity Level MSL3
Table 36-10. Package Reference
JEDEC Drawing Reference N/A
JESD97 Classification E4
935
32142D–06/2013
ATUC64/128/256L3/4U
Figure 36-4. TQFP-64 Package Drawing
Table 36-11. Device and Package Maximum Weight
300 mg
Table 36-12. Package Characteristics
Moisture Sensitivity Level MSL3
Table 36-13. Package Reference
JEDEC Drawing Reference MS-026
JESD97 Classification E3
936
32142D–06/2013
ATUC64/128/256L3/4U
Figure 36-5. QFN-64 Package Drawing
Note: The exposed pad is not connected to anything internally, but should be soldered to ground to increase board level reliability.
Table 36-14. Device and Package Maximum Weight
200 mg
Table 36-15. Package Characteristics
Moisture Sensitivity Level MSL3
Table 36-16. Package Reference
JEDEC Drawing Reference M0-220
JESD97 Classification E3
937
32142D–06/2013
ATUC64/128/256L3/4U
36.3 Soldering Profile
Table 36-17 gives the recommended soldering profile from J-STD-20.
A maximum of three reflow passes is allowed per component.
Table 36-17. Soldering Profile
Profile Feature Green Package
Average Ramp-up Rate (217°C to Peak) 3°C/s max
Preheat Temperature 175°C ±25°C 150-200°C
Time Maintained Above 217°C 60-150 s
Time within 5C of Actual Peak Temperature 30 s
Peak Temperature Range 260°C
Ramp-down Rate 6°C/s max
Time 25C to Peak Temperature 8 minutes max
938
32142D–06/2013
ATUC64/128/256L3/4U
37. Ordering Information
Table 37-1. Ordering Information
Device Ordering Code Carrier Type Package Package Type
Temperature Operating
Range
ATUC256L3U
ATUC256L3U-AUTES ES
TQFP 64
JESD97 Classification E3
N/A
ATUC256L3U-AUT Tray
Industrial (-40C to 85C)
ATUC256L3U-AUR Tape & Reel
ATUC256L3U-Z3UTES ES
QFN 64
N/A
ATUC256L3U-Z3UT Tray
Industrial (-40C to 85C)
ATUC256L3U-Z3UR Tape & Reel
ATUC128L3U
ATUC128L3U-AUT Tray TQFP 64
JESD97 Classification E3 Industrial (-40C to 85C)
ATUC128L3U-AUR Tape & Reel
ATUC128L3U-Z3UT Tray QFN 64
ATUC128L3U-Z3UR Tape & Reel
ATUC64L3U
ATUC64L3U-AUT Tray TQFP 64
JESD97 Classification E3 Industrial (-40C to 85C) ATUC64L3U-AUR Tape & Reel
ATUC64L3U-Z3UT Tray QFN 64
ATUC64L3U-Z3UR Tape & Reel
939
32142D–06/2013
ATUC64/128/256L3/4U
ATUC256L4U
ATUC256L4U-AUTES ES
TQFP 48
JESD97 Classification E3
N/A
ATUC256L4U-AUT Tray Industrial (-40C to 85C)
ATUC256L4U-AUR Tape & Reel
ATUC256L4U-ZAUTES ES
QFN 48
N/A
ATUC256L4U-ZAUT Tray
Industrial (-40C to 85C) ATUC256L4U-ZAUR Tape & Reel
ATUC256L4U-D3HES ES
TLLGA 48 JESD97 Classification E4
N/A
ATUC256L4U-D3HT Tray
Industrial (-40C to 85C)
ATUC256L4U-D3HR Tape & Reel
ATUC128L4U
ATUC128L4U-AUT Tray TQFP 48
JESD97 Classification E3
ATUC128L4U-AUR Tape & Reel
ATUC128L4U-ZAUT Tray QFN 48
ATUC128L4U-ZAUR Tape & Reel
ATUC128L4U-D3HT Tray TLLGA 48 JESD97 Classification E4
ATUC128L4U-D3HR Tape & Reel
ATUC64L4U
ATUC64L4U-AUT Tray TQFP 48
JESD97 Classification E3
ATUC64L4U-AUR Tape & Reel
ATUC64L4U-ZAUT Tray QFN 48
ATUC64L4U-ZAUR Tape & Reel
ATUC64L4U-D3HT Tray TLLGA 48 JESD97 Classification E4
ATUC64L4U-D3HR Tape & Reel
Table 37-1. Ordering Information
Device Ordering Code Carrier Type Package Package Type
Temperature Operating
Range
940
32142D–06/2013
ATUC64/128/256L3/4U
38. Errata
38.1 Rev. C
38.1.1 SCIF
1. The RC32K output on PA20 is not always permanently disabled
The RC32K output on PA20 may sometimes re-appear.
Fix/Workaround
Before using RC32K for other purposes, the following procedure has to be followed in order
to properly disable it:
- Run the CPU on RCSYS
- Disable the output to PA20 by writing a zero to PM.PPCR.RC32OUT
- Enable RC32K by writing a one to SCIF.RC32KCR.EN, and wait for this bit to be read as
one
- Disable RC32K by writing a zero to SCIF.RC32KCR.EN, and wait for this bit to be read as
zero.
2. PLLCOUNT value larger than zero can cause PLLEN glitch
Initializing the PLLCOUNT with a value greater than zero creates a glitch on the PLLEN signal
during asynchronous wake up.
Fix/Workaround
The lock-masking mechanism for the PLL should not be used.
The PLLCOUNT field of the PLL Control Register should always be written to zero.
3. Writing 0x5A5A5A5A to the SCIF memory range will enable the SCIF UNLOCK feature
The SCIF UNLOCK feature will be enabled if the value 0x5A5A5A5A is written to any location
in the SCIF memory range.
Fix/Workaround
None.
38.1.2 SPI
1. SPI data transfer hangs with CSR0.CSAAT==1 and MR.MODFDIS==0
When CSR0.CSAAT==1 and mode fault detection is enabled (MR.MODFDIS==0), the SPI
module will not start a data transfer.
Fix/Workaround
Disable mode fault detection by writing a one to MR.MODFDIS.
2. Disabling SPI has no effect on the SR.TDRE bit
Disabling SPI has no effect on the SR.TDRE bit whereas the write data command is filtered
when SPI is disabled. Writing to TDR when SPI is disabled will not clear SR.TDRE. If SPI is
disabled during a PDCA transfer, the PDCA will continue to write data to TDR until its buffer
is empty, and this data will be lost.
Fix/Workaround
Disable the PDCA, add two NOPs, and disable the SPI. To continue the transfer, enable the
SPI and PDCA.
3. SPI disable does not work in SLAVE mode
SPI disable does not work in SLAVE mode.
Fix/Workaround
Read the last received data, then perform a software reset by writing a one to the Software
Reset bit in the Control Register (CR.SWRST).
941
32142D–06/2013
ATUC64/128/256L3/4U
4. SPI bad serial clock generation on 2nd chip_select when SCBR=1, CPOL=1, and
NCPHA=0
When multiple chip selects (CS) are in use, if one of the baudrates equal 1 while one
(CSRn.SCBR=1) of the others do not equal 1, and CSRn.CPOL=1 and CSRn.NCPHA=0,
then an additional pulse will be generated on SCK.
Fix/Workaround
When multiple CS are in use, if one of the baudrates equals 1, the others must also equal 1
if CSRn.CPOL=1 and CSRn.NCPHA=0.
5. SPI mode fault detection enable causes incorrect behavior
When mode fault detection is enabled (MR.MODFDIS==0), the SPI module may not operate
properly.
Fix/Workaround
Always disable mode fault detection before using the SPI by writing a one to MR.MODFDIS.
6. SPI RDR.PCS is not correct
The PCS (Peripheral Chip Select) field in the SPI RDR (Receive Data Register) does not
correctly indicate the value on the NPCS pins at the end of a transfer.
Fix/Workaround
Do not use the PCS field of the SPI RDR.
38.1.3 TWI
1. SMBALERT bit may be set after reset
The SMBus Alert (SMBALERT) bit in the Status Register (SR) might be erroneously set after
system reset.
Fix/Workaround
After system reset, clear the SR.SMBALERT bit before commencing any TWI transfer.
2. Clearing the NAK bit before the BTF bit is set locks up the TWI bus
When the TWIS is in transmit mode, clearing the NAK Received (NAK) bit of the Status Register
(SR) before the end of the Acknowledge/Not Acknowledge cycle will cause the TWIS to
attempt to continue transmitting data, thus locking up the bus.
Fix/Workaround
Clear SR.NAK only after the Byte Transfer Finished (BTF) bit of the same register has been
set.
38.1.4 TC
1. Channel chaining skips first pulse for upper channel
When chaining two channels using the Block Mode Register, the first pulse of the clock
between the channels is skipped.
Fix/Workaround
Configure the lower channel with RA = 0x1 and RC = 0x2 to produce a dummy clock cycle
for the upper channel. After the dummy cycle has been generated, indicated by the
SR.CPCS bit, reconfigure the RA and RC registers for the lower channel with the real
values.
38.1.5 CAT
1. CAT QMatrix sense capacitors discharged prematurely
At the end of a QMatrix burst charging sequence that uses different burst count values for
different Y lines, the Y lines may be incorrectly grounded for up to n-1 periods of the periph-
942
32142D–06/2013
ATUC64/128/256L3/4U
eral bus clock, where n is the ratio of the PB clock frequency to the GCLK_CAT frequency.
This results in premature loss of charge from the sense capacitors and thus increased variability
of the acquired count values.
Fix/Workaround
Enable the 1kOhm drive resistors on all implemented QMatrix Y lines (CSA 1, 3, 5, 7, 9, 11,
13, and/or 15) by writing ones to the corresponding odd bits of the CSARES register.
2. Autonomous CAT acquisition must be longer than AST source clock period
When using the AST to trigger CAT autonomous touch acquisition in sleep modes where the
CAT bus clock is turned off, the CAT will start several acquisitions if the period of the AST
source clock is larger than one CAT acquisition. One AST clock period after the AST trigger,
the CAT clock will automatically stop and the CAT acquisition can be stopped prematurely,
ruining the result.
Fix/Workaround
Always ensure that the ATCFG1.max field is set so that the duration of the autonomous
touch acquisition is greater than one clock period of the AST source clock.
38.1.6 aWire
1. aWire MEMORY_SPEED_REQUEST command does not return correct CV
The aWire MEMORY_SPEED_REQUEST command does not return a CV corresponding to
the formula in the aWire Debug Interface chapter.
Fix/Workaround
Issue a dummy read to address 0x100000000 before issuing the
MEMORY_SPEED_REQUEST command and use this formula instead:
38.2 Flash
1. Corrupted data in flash may happen after flash page write operations
After a flash page write operation from an external programmer, reading (data read or code
fetch) in flash may fail. This may lead to an exception or to others errors derived from this
corrupted read access.
Fix/Workaround
Before any flash page write operation, each write in the page buffer must preceded by a
write in the page buffer with 0xFFFF_FFFF content at any address in the page.
38.3 Rev. B
38.3.1 SCIF
1. The RC32K output on PA20 is not always permanently disabled
The RC32K output on PA20 may sometimes re-appear.
Fix/Workaround
Before using RC32K for other purposes, the following procedure has to be followed in order
to properly disable it:
- Run the CPU on RCSYS
- Disable the output to PA20 by writing a zero to PM.PPCR.RC32OUT
- Enable RC32K by writing a one to SCIF.RC32KCR.EN, and wait for this bit to be read as
one
f
sab
7f
aw
CV – 3 = ----------------
943
32142D–06/2013
ATUC64/128/256L3/4U
- Disable RC32K by writing a zero to SCIF.RC32KCR.EN, and wait for this bit to be read as
zero.
2. PLLCOUNT value larger than zero can cause PLLEN glitch
Initializing the PLLCOUNT with a value greater than zero creates a glitch on the PLLEN signal
during asynchronous wake up.
Fix/Workaround
The lock-masking mechanism for the PLL should not be used.
The PLLCOUNT field of the PLL Control Register should always be written to zero.
3. Writing 0x5A5A5A5A to the SCIF memory range will enable the SCIF UNLOCK feature
The SCIF UNLOCK feature will be enabled if the value 0x5A5A5A5A is written to any location
in the SCIF memory range.
Fix/Workaround
None.
38.3.2 WDT
1. WDT Control Register does not have synchronization feedback
When writing to the Timeout Prescale Select (PSEL), Time Ban Prescale Select (TBAN),
Enable (EN), or WDT Mode (MODE) fieldss of the WDT Control Register (CTRL), a synchronizer
is started to propagate the values to the WDT clcok domain. This synchronization
takes a finite amount of time, but only the status of the synchronization of the EN bit is
reflected back to the user. Writing to the synchronized fields during synchronization can lead
to undefined behavior.
Fix/Workaround
-When writing to the affected fields, the user must ensure a wait corresponding to 2 clock
cycles of both the WDT peripheral bus clock and the selected WDT clock source.
-When doing writes that changes the EN bit, the EN bit can be read back until it reflects the
written value.
38.3.3 SPI
1. SPI data transfer hangs with CSR0.CSAAT==1 and MR.MODFDIS==0
When CSR0.CSAAT==1 and mode fault detection is enabled (MR.MODFDIS==0), the SPI
module will not start a data transfer.
Fix/Workaround
Disable mode fault detection by writing a one to MR.MODFDIS.
2. Disabling SPI has no effect on the SR.TDRE bit
Disabling SPI has no effect on the SR.TDRE bit whereas the write data command is filtered
when SPI is disabled. Writing to TDR when SPI is disabled will not clear SR.TDRE. If SPI is
disabled during a PDCA transfer, the PDCA will continue to write data to TDR until its buffer
is empty, and this data will be lost.
Fix/Workaround
Disable the PDCA, add two NOPs, and disable the SPI. To continue the transfer, enable the
SPI and PDCA.
3. SPI disable does not work in SLAVE mode
SPI disable does not work in SLAVE mode.
Fix/Workaround
Read the last received data, then perform a software reset by writing a one to the Software
Reset bit in the Control Register (CR.SWRST).
944
32142D–06/2013
ATUC64/128/256L3/4U
4. SPI bad serial clock generation on 2nd chip_select when SCBR=1, CPOL=1, and
NCPHA=0
When multiple chip selects (CS) are in use, if one of the baudrates equal 1 while one
(CSRn.SCBR=1) of the others do not equal 1, and CSRn.CPOL=1 and CSRn.NCPHA=0,
then an additional pulse will be generated on SCK.
Fix/Workaround
When multiple CS are in use, if one of the baudrates equals 1, the others must also equal 1
if CSRn.CPOL=1 and CSRn.NCPHA=0.
5. SPI mode fault detection enable causes incorrect behavior
When mode fault detection is enabled (MR.MODFDIS==0), the SPI module may not operate
properly.
Fix/Workaround
Always disable mode fault detection before using the SPI by writing a one to MR.MODFDIS.
6. SPI RDR.PCS is not correct
The PCS (Peripheral Chip Select) field in the SPI RDR (Receive Data Register) does not
correctly indicate the value on the NPCS pins at the end of a transfer.
Fix/Workaround
Do not use the PCS field of the SPI RDR.
38.3.4 TWI
1. TWIS may not wake the device from sleep mode
If the CPU is put to a sleep mode (except Idle and Frozen) directly after a TWI Start condition,
the CPU may not wake upon a TWIS address match. The request is NACKed.
Fix/Workaround
When using the TWI address match to wake the device from sleep, do not switch to sleep
modes deeper than Frozen. Another solution is to enable asynchronous EIC wake on the
TWIS clock (TWCK) or TWIS data (TWD) pins, in order to wake the system up on bus
events.
2. SMBALERT bit may be set after reset
The SMBus Alert (SMBALERT) bit in the Status Register (SR) might be erroneously set after
system reset.
Fix/Workaround
After system reset, clear the SR.SMBALERT bit before commencing any TWI transfer.
3. Clearing the NAK bit before the BTF bit is set locks up the TWI bus
When the TWIS is in transmit mode, clearing the NAK Received (NAK) bit of the Status Register
(SR) before the end of the Acknowledge/Not Acknowledge cycle will cause the TWIS to
attempt to continue transmitting data, thus locking up the bus.
Fix/Workaround
Clear SR.NAK only after the Byte Transfer Finished (BTF) bit of the same register has been
set.
38.3.5 PWMA
1. The SR.READY bit cannot be cleared by writing to SCR.READY
The Ready bit in the Status Register will not be cleared when writing a one to the corresponding
bit in the Status Clear register. The Ready bit will be cleared when the Busy bit is
set.
Fix/Workaround
945
32142D–06/2013
ATUC64/128/256L3/4U
Disable the Ready interrupt in the interrupt handler when receiving the interrupt. When an
operation that triggers the Busy/Ready bit is started, wait until the ready bit is low in the Status
Register before enabling the interrupt.
38.3.6 TC
1. Channel chaining skips first pulse for upper channel
When chaining two channels using the Block Mode Register, the first pulse of the clock
between the channels is skipped.
Fix/Workaround
Configure the lower channel with RA = 0x1 and RC = 0x2 to produce a dummy clock cycle
for the upper channel. After the dummy cycle has been generated, indicated by the
SR.CPCS bit, reconfigure the RA and RC registers for the lower channel with the real
values.
38.3.7 CAT
1. CAT QMatrix sense capacitors discharged prematurely
At the end of a QMatrix burst charging sequence that uses different burst count values for
different Y lines, the Y lines may be incorrectly grounded for up to n-1 periods of the peripheral
bus clock, where n is the ratio of the PB clock frequency to the GCLK_CAT frequency.
This results in premature loss of charge from the sense capacitors and thus increased variability
of the acquired count values.
Fix/Workaround
Enable the 1kOhm drive resistors on all implemented QMatrix Y lines (CSA 1, 3, 5, 7, 9, 11,
13, and/or 15) by writing ones to the corresponding odd bits of the CSARES register.
2. Autonomous CAT acquisition must be longer than AST source clock period
When using the AST to trigger CAT autonomous touch acquisition in sleep modes where the
CAT bus clock is turned off, the CAT will start several acquisitions if the period of the AST
source clock is larger than one CAT acquisition. One AST clock period after the AST trigger,
the CAT clock will automatically stop and the CAT acquisition can be stopped prematurely,
ruining the result.
Fix/Workaround
Always ensure that the ATCFG1.max field is set so that the duration of the autonomous
touch acquisition is greater than one clock period of the AST source clock.
3. CAT consumes unnecessary power when disabled or when autonomous touch not
used
A CAT prescaler controlled by the ATCFG0.DIV field will be active even when the CAT module
is disabled or when the autonomous touch feature is not used, thereby causing
unnecessary power consumption.
Fix/Workaround
If the CAT module is not used, disable the CLK_CAT clock in the PM module. If the CAT
module is used but the autonomous touch feature is not used, the power consumption of the
CAT module may be reduced by writing 0xFFFF to the ATCFG0.DIV field.
38.3.8 aWire
1. aWire MEMORY_SPEED_REQUEST command does not return correct CV
The aWire MEMORY_SPEED_REQUEST command does not return a CV corresponding to
the formula in the aWire Debug Interface chapter.
Fix/Workaround
946
32142D–06/2013
ATUC64/128/256L3/4U
Issue a dummy read to address 0x100000000 before issuing the
MEMORY_SPEED_REQUEST command and use this formula instead:
38.4 Flash
2. Corrupted data in flash may happen after flash page write operations
After a flash page write operation from an external programmer, reading (data read or code
fetch) in flash may fail. This may lead to an exception or to others errors derived from this
corrupted read access.
Fix/Workaround
Before any flash page write operation, each write in the page buffer must preceded by a
write in the page buffer with 0xFFFF_FFFF content at any address in the page.
38.5 Rev. A
38.5.1 Device
3. JTAGID is wrong
The JTAGID reads 0x021DF03F for all devices.
Fix/Workaround
None.
38.5.2 FLASHCDW
1. General-purpose fuse programming does not work
The general-purpose fuses cannot be programmed and are stuck at 1. Please refer to the
Fuse Settings chapter in the FLASHCDW for more information about what functions are
affected.
Fix/Workaround
None.
2. Set Security Bit command does not work
The Set Security Bit (SSB) command of the FLASHCDW does not work. The device cannot
be locked from external JTAG, aWire, or other debug accesses.
Fix/Workaround
None.
3. Flash programming time is longer than specified
f
sab
7f
aw
CV – 3 = ----------------
947
32142D–06/2013
ATUC64/128/256L3/4U
The flash programming time is now:
Fix/Workaround
None.
4. Power Manager
5. Clock Failure Detector (CFD) can be issued while turning off the CFD
While turning off the CFD, the CFD bit in the Status Register (SR) can be set. This will
change the main clock source to RCSYS.
Fix/Workaround
Solution 1: Enable CFD interrupt. If CFD interrupt is issues after turning off the CFD, switch
back to original main clock source.
Solution 2: Only turn off the CFD while running the main clock on RCSYS.
6. Sleepwalking in idle and frozen sleep mode will mask all other PB clocks
If the CPU is in idle or frozen sleep mode and a module is in a state that triggers sleep walking,
all PB clocks will be masked except the PB clock to the sleepwalking module.
Fix/Workaround
Mask all clock requests in the PM.PPCR register before going into idle or frozen mode.
4. Unused PB clocks are running
Three unused PBA clocks are enabled by default and will cause increased active power
consumption.
Fix/Workaround
Disable the clocks by writing zeroes to bits [27:25] in the PBA clock mask register.
38.5.3 SCIF
1. The RC32K output on PA20 is not always permanently disabled
The RC32K output on PA20 may sometimes re-appear.
Fix/Workaround
Before using RC32K for other purposes, the following procedure has to be followed in order
to properly disable it:
- Run the CPU on RCSYS
- Disable the output to PA20 by writing a zero to PM.PPCR.RC32OUT
- Enable RC32K by writing a one to SCIF.RC32KCR.EN, and wait for this bit to be read as
one
- Disable RC32K by writing a zero to SCIF.RC32KCR.EN, and wait for this bit to be read as
zero.
2. PLL lock might not clear after disable
Table 38-1. Flash Characteristics
Symbol Parameter Conditions Min Typ Max Unit
TFPP Page programming time
fCLK_HSB= 50MHz
7.5
ms
TFPE Page erase time 7.5
TFFP Fuse programming time 1
TFEA Full chip erase time (EA) 9
TFCE
JTAG chip erase time
(CHIP_ERASE) fCLK_HSB= 115kHz 250
948
32142D–06/2013
ATUC64/128/256L3/4U
Under certain circumstances, the lock signal from the Phase Locked Loop (PLL) oscillator
may not go back to zero after the PLL oscillator has been disabled. This can cause the propagation
of clock signals with the wrong frequency to parts of the system that use the PLL
clock.
Fix/Workaround
PLL must be turned off before entering STOP, DEEPSTOP or STATIC sleep modes. If PLL
has been turned off, a delay of 30us must be observed after the PLL has been enabled
again before the SCIF.PLL0LOCK bit can be used as a valid indication that the PLL is
locked.
3. PLLCOUNT value larger than zero can cause PLLEN glitch
Initializing the PLLCOUNT with a value greater than zero creates a glitch on the PLLEN signal
during asynchronous wake up.
Fix/Workaround
The lock-masking mechanism for the PLL should not be used.
The PLLCOUNT field of the PLL Control Register should always be written to zero.
4. RCSYS is not calibrated
The RCSYS is not calibrated and will run faster than 115.2kHz. Frequencies around 150kHz
can be expected.
Fix/Workaround
If a known clock source is available the RCSYS can be runtime calibrated by using the frequency
meter (FREQM) and tuning the RCSYS by writing to the RCCR register in SCIF.
5. Writing 0x5A5A5A5A to the SCIF memory range will enable the SCIF UNLOCK feature
The SCIF UNLOCK feature will be enabled if the value 0x5A5A5A5A is written to any location
in the SCIF memory range.
Fix/Workaround
None.
38.5.4 WDT
1. Clearing the Watchdog Timer (WDT) counter in second half of timeout period will
issue a Watchdog reset
If the WDT counter is cleared in the second half of the timeout period, the WDT will immediately
issue a Watchdog reset.
Fix/Workaround
Use twice as long timeout period as needed and clear the WDT counter within the first half
of the timeout period. If the WDT counter is cleared after the first half of the timeout period,
you will get a Watchdog reset immediately. If the WDT counter is not cleared at all, the time
before the reset will be twice as long as needed.
2. WDT Control Register does not have synchronization feedback
When writing to the Timeout Prescale Select (PSEL), Time Ban Prescale Select (TBAN),
Enable (EN), or WDT Mode (MODE) fieldss of the WDT Control Register (CTRL), a synchronizer
is started to propagate the values to the WDT clcok domain. This synchronization
takes a finite amount of time, but only the status of the synchronization of the EN bit is
reflected back to the user. Writing to the synchronized fields during synchronization can lead
to undefined behavior.
Fix/Workaround
-When writing to the affected fields, the user must ensure a wait corresponding to 2 clock
cycles of both the WDT peripheral bus clock and the selected WDT clock source.
-When doing writes that changes the EN bit, the EN bit can be read back until it reflects the
written value.
949
32142D–06/2013
ATUC64/128/256L3/4U
38.5.5 GPIO
1. Clearing Interrupt flags can mask other interrupts
When clearing interrupt flags in a GPIO port, interrupts on other pins of that port, happening
in the same clock cycle will not be registered.
Fix/Workaround
Read the PVR register of the port before and after clearing the interrupt to see if any pin
change has happened while clearing the interrupt. If any change occurred in the PVR
between the reads, they must be treated as an interrupt.
38.5.6 SPI
1. SPI data transfer hangs with CSR0.CSAAT==1 and MR.MODFDIS==0
When CSR0.CSAAT==1 and mode fault detection is enabled (MR.MODFDIS==0), the SPI
module will not start a data transfer.
Fix/Workaround
Disable mode fault detection by writing a one to MR.MODFDIS.
2. Disabling SPI has no effect on the SR.TDRE bit
Disabling SPI has no effect on the SR.TDRE bit whereas the write data command is filtered
when SPI is disabled. Writing to TDR when SPI is disabled will not clear SR.TDRE. If SPI is
disabled during a PDCA transfer, the PDCA will continue to write data to TDR until its buffer
is empty, and this data will be lost.
Fix/Workaround
Disable the PDCA, add two NOPs, and disable the SPI. To continue the transfer, enable the
SPI and PDCA.
3. SPI disable does not work in SLAVE mode
SPI disable does not work in SLAVE mode.
Fix/Workaround
Read the last received data, then perform a software reset by writing a one to the Software
Reset bit in the Control Register (CR.SWRST).
4. SPI bad serial clock generation on 2nd chip_select when SCBR=1, CPOL=1, and
NCPHA=0
When multiple chip selects (CS) are in use, if one of the baudrates equal 1 while one
(CSRn.SCBR=1) of the others do not equal 1, and CSRn.CPOL=1 and CSRn.NCPHA=0,
then an additional pulse will be generated on SCK.
Fix/Workaround
When multiple CS are in use, if one of the baudrates equals 1, the others must also equal 1
if CSRn.CPOL=1 and CSRn.NCPHA=0.
5. SPI mode fault detection enable causes incorrect behavior
When mode fault detection is enabled (MR.MODFDIS==0), the SPI module may not operate
properly.
Fix/Workaround
Always disable mode fault detection before using the SPI by writing a one to MR.MODFDIS.
6. SPI RDR.PCS is not correct
The PCS (Peripheral Chip Select) field in the SPI RDR (Receive Data Register) does not
correctly indicate the value on the NPCS pins at the end of a transfer.
Fix/Workaround
Do not use the PCS field of the SPI RDR.
950
32142D–06/2013
ATUC64/128/256L3/4U
38.5.7 TWI
1. TWIS may not wake the device from sleep mode
If the CPU is put to a sleep mode (except Idle and Frozen) directly after a TWI Start condition,
the CPU may not wake upon a TWIS address match. The request is NACKed.
Fix/Workaround
When using the TWI address match to wake the device from sleep, do not switch to sleep
modes deeper than Frozen. Another solution is to enable asynchronous EIC wake on the
TWIS clock (TWCK) or TWIS data (TWD) pins, in order to wake the system up on bus
events.
2. SMBALERT bit may be set after reset
The SMBus Alert (SMBALERT) bit in the Status Register (SR) might be erroneously set after
system reset.
Fix/Workaround
After system reset, clear the SR.SMBALERT bit before commencing any TWI transfer.
3. Clearing the NAK bit before the BTF bit is set locks up the TWI bus
When the TWIS is in transmit mode, clearing the NAK Received (NAK) bit of the Status Register
(SR) before the end of the Acknowledge/Not Acknowledge cycle will cause the TWIS to
attempt to continue transmitting data, thus locking up the bus.
Fix/Workaround
Clear SR.NAK only after the Byte Transfer Finished (BTF) bit of the same register has been
set.
4. TWIS stretch on Address match error
When the TWIS stretches TWCK due to a slave address match, it also holds TWD low for
the same duration if it is to be receiving data. When TWIS releases TWCK, it releases TWD
at the same time. This can cause a TWI timing violation.
Fix/Workaround
None.
5. TWIM TWALM polarity is wrong
The TWALM signal in the TWIM is active high instead of active low.
Fix/Workaround
Use an external inverter to invert the signal going into the TWIM. When using both TWIM
and TWIS on the same pins, the TWALM cannot be used.
38.5.8 PWMA
1. The SR.READY bit cannot be cleared by writing to SCR.READY
The Ready bit in the Status Register will not be cleared when writing a one to the corresponding
bit in the Status Clear register. The Ready bit will be cleared when the Busy bit is
set.
Fix/Workaround
Disable the Ready interrupt in the interrupt handler when receiving the interrupt. When an
operation that triggers the Busy/Ready bit is started, wait until the ready bit is low in the Status
Register before enabling the interrupt.
38.5.9 TC
1. Channel chaining skips first pulse for upper channel
When chaining two channels using the Block Mode Register, the first pulse of the clock
between the channels is skipped.
951
32142D–06/2013
ATUC64/128/256L3/4U
Fix/Workaround
Configure the lower channel with RA = 0x1 and RC = 0x2 to produce a dummy clock cycle
for the upper channel. After the dummy cycle has been generated, indicated by the
SR.CPCS bit, reconfigure the RA and RC registers for the lower channel with the real
values.
38.5.10 ADCIFB
1. ADCIFB DMA transfer does not work with divided PBA clock
DMA requests from the ADCIFB will not be performed when the PBA clock is slower than
the HSB clock.
Fix/Workaround
Do not use divided PBA clock when the PDCA transfers from the ADCIFB.
38.5.11 CAT
1. CAT QMatrix sense capacitors discharged prematurely
At the end of a QMatrix burst charging sequence that uses different burst count values for
different Y lines, the Y lines may be incorrectly grounded for up to n-1 periods of the peripheral
bus clock, where n is the ratio of the PB clock frequency to the GCLK_CAT frequency.
This results in premature loss of charge from the sense capacitors and thus increased variability
of the acquired count values.
Fix/Workaround
Enable the 1kOhm drive resistors on all implemented QMatrix Y lines (CSA 1, 3, 5, 7, 9, 11,
13, and/or 15) by writing ones to the corresponding odd bits of the CSARES register.
2. Autonomous CAT acquisition must be longer than AST source clock period
When using the AST to trigger CAT autonomous touch acquisition in sleep modes where the
CAT bus clock is turned off, the CAT will start several acquisitions if the period of the AST
source clock is larger than one CAT acquisition. One AST clock period after the AST trigger,
the CAT clock will automatically stop and the CAT acquisition can be stopped prematurely,
ruining the result.
Fix/Workaround
Always ensure that the ATCFG1.max field is set so that the duration of the autonomous
touch acquisition is greater than one clock period of the AST source clock.
3. CAT consumes unnecessary power when disabled or when autonomous touch not
used
A CAT prescaler controlled by the ATCFG0.DIV field will be active even when the CAT module
is disabled or when the autonomous touch feature is not used, thereby causing
unnecessary power consumption.
Fix/Workaround
If the CAT module is not used, disable the CLK_CAT clock in the PM module. If the CAT
module is used but the autonomous touch feature is not used, the power consumption of the
CAT module may be reduced by writing 0xFFFF to the ATCFG0.DIV field.
4. CAT module does not terminate QTouch burst on detect
The CAT module does not terminate a QTouch burst when the detection voltage is
reached on the sense capacitor. This can cause the sense capacitor to be charged more
than necessary. Depending on the dielectric absorption characteristics of the capacitor, this
can lead to unstable measurements.
Fix/Workaround
Use the minimum possible value for the MAX field in the ATCFG1, TG0CFG1, and
TG1CFG1 registers.
952
32142D–06/2013
ATUC64/128/256L3/4U
38.5.12 aWire
1. aWire MEMORY_SPEED_REQUEST command does not return correct CV
The aWire MEMORY_SPEED_REQUEST command does not return a CV corresponding to
the formula in the aWire Debug Interface chapter.
Fix/Workaround
Issue a dummy read to address 0x100000000 before issuing the
MEMORY_SPEED_REQUEST command and use this formula instead:
38.5.13 Flash
5. Corrupted data in flash may happen after flash page write operations
After a flash page write operation from an external programmer, reading (data read or code
fetch) in flash may fail. This may lead to an exception or to others errors derived from this
corrupted read access.
Fix/Workaround
Before any flash page write operation, each write in the page buffer must preceded by a
write in the page buffer with 0xFFFF_FFFF content at any address in the page.
38.5.14 I/O Pins
1. PA05 is not 3.3V tolerant.
PA05 should be grounded on the PCB and left unused if VDDIO is above 1.8V.
Fix/Workaround
None.
2. No pull-up on pins that are not bonded
PB13 to PB27 are not bonded on UC3L0256/128, but has no pull-up and can cause current
consumption on VDDIO/VDDIN if left undriven.
Fix/Workaround
Enable pull-ups on PB13 to PB27 by writing 0x0FFFE000 to the PUERS1 register in the
GPIO.
3. PA17 has low ESD tolerance
PA17 only tolerates 500V ESD pulses (Human Body Model).
Fix/Workaround
Care must be taken during manufacturing and PCB design.
f
sab
7f
aw
CV – 3 = ----------------
953
32142D–06/2013
ATUC64/128/256L3/4U
39. Datasheet Revision History
Please note that the referring page numbers in this section are referred to this document. The
referring revision in this section are referring to the document revision.
39.1 Rev. D – 06/2013
39.2 Rev. C – 01/2012
39.3 Rev. B – 12/2011
39.4 Rev. A – 12/2011
1. Updated the datasheet with a new ATmel blue logo and the last page.
2. Added Flash errata.
1. Description: DFLL frequency is 20 to 150MHz, not 40 to 150MHz.
2. Block Diagram: GCLK_IN is input, not output. CAT SMP corrected from I/O to output. SPI
NPCS corrected from output to I/O.
3, Package and Pinout: EXTINT0 in Signal Descriptions table is NMI.
4, Supply and Startup Considerations: In 1.8V single supply mode figure, the input voltage is
1.62-1.98V, not 1.98-3.6V. “On system start-up, the DFLL is disabled” is replaced by “On
system start-up, all high-speed clocks are disabled”.
5, ADCIFB: PRND signal removed from block diagram.
6, Electrical Charateristics: Added 64-pin package information to I/O Pin Characteristics tables
and Digital Clock Characteristics table.
7, Mechanical Characteristics: QFN48 Package Drawing updated. Note that the package drawing
for QFN48 is correct in datasheet rev A, but wrong in rev B. Added notes to package drawings.
8. Summary: Removed Programming and Debugging chapter, added Processor and Architecture
chapter.
1. JTAG Data Registers subchapter added in the Programming and Debugging chapter,
containing JTAG IDs.
1. Initial revision.
i
32142D–06/2013
ATUC64/128/256L3/4U
Table of Contents
Features ..................................................................................................... 1
1 Description ............................................................................................... 3
2 Overview ................................................................................................... 5
2.1 Block Diagram ...................................................................................................5
2.2 Configuration Summary .....................................................................................6
3 Package and Pinout ................................................................................. 7
3.1 Package .............................................................................................................7
3.2 See Section 3.3 for a description of the various peripheral signals. ................12
3.3 Signal Descriptions ..........................................................................................15
3.4 I/O Line Considerations ...................................................................................18
4 Processor and Architecture .................................................................. 21
4.1 Features ..........................................................................................................21
4.2 AVR32 Architecture .........................................................................................21
4.3 The AVR32UC CPU ........................................................................................22
4.4 Programming Model ........................................................................................26
4.5 Exceptions and Interrupts ................................................................................30
5 Memories ................................................................................................ 35
5.1 Embedded Memories ......................................................................................35
5.2 Physical Memory Map .....................................................................................35
5.3 Peripheral Address Map ..................................................................................36
5.4 CPU Local Bus Mapping .................................................................................37
6 Supply and Startup Considerations ..................................................... 39
6.1 Supply Considerations .....................................................................................39
6.2 Startup Considerations ....................................................................................44
7 Peripheral DMA Controller (PDCA) ...................................................... 45
7.1 Features ..........................................................................................................45
7.2 Overview ..........................................................................................................45
7.3 Block Diagram .................................................................................................46
7.4 Product Dependencies ....................................................................................46
7.5 Functional Description .....................................................................................47
7.6 Performance Monitors .....................................................................................49
7.7 User Interface ..................................................................................................51
ii
32142D–06/2013
ATUC64/128/256L3/4U
7.8 Module Configuration ......................................................................................79
8 USB Interface (USBC) ............................................................................ 81
8.1 Features ..........................................................................................................81
8.2 Overview ..........................................................................................................81
8.3 Block Diagram .................................................................................................81
8.4 I/O Lines Description .......................................................................................83
8.5 Product Dependencies ....................................................................................84
8.6 Functional Description .....................................................................................85
8.7 User Interface ...............................................................................................101
8.8 Module Configuration ....................................................................................134
9 Flash Controller (FLASHCDW) ........................................................... 135
9.1 Features ........................................................................................................135
9.2 Overview ........................................................................................................135
9.3 Product Dependencies ..................................................................................135
9.4 Functional Description ...................................................................................136
9.5 Flash Commands ..........................................................................................141
9.6 General-purpose Fuse Bits ............................................................................143
9.7 Security Bit ....................................................................................................146
9.8 User Interface ................................................................................................147
9.9 Fuse Settings .................................................................................................157
9.10 Serial Number ................................................................................................160
9.11 Module Configuration ....................................................................................160
10 Secure Access Unit (SAU) .................................................................. 162
10.1 Features ........................................................................................................162
10.2 Overview ........................................................................................................162
10.3 Block Diagram ...............................................................................................163
10.4 Product Dependencies ..................................................................................164
10.5 Functional Description ...................................................................................164
10.6 User Interface ................................................................................................168
10.7 Module Configuration ....................................................................................183
11 HSB Bus Matrix (HMATRIXB) .............................................................. 184
11.1 Features ........................................................................................................184
11.2 Overview ........................................................................................................184
11.3 Product Dependencies ..................................................................................184
11.4 Functional Description ...................................................................................184
iii
32142D–06/2013
ATUC64/128/256L3/4U
11.5 User Interface ................................................................................................188
11.6 Module Configuration ....................................................................................196
12 Interrupt Controller (INTC) .................................................................. 198
12.1 Features ........................................................................................................198
12.2 Overview ........................................................................................................198
12.3 Block Diagram ...............................................................................................198
12.4 Product Dependencies ..................................................................................199
12.5 Functional Description ...................................................................................199
12.6 User Interface ................................................................................................202
12.7 Module Configuration ....................................................................................206
12.8 Interrupt Request Signal Map ........................................................................206
13 Power Manager (PM) ............................................................................ 209
13.1 Features ........................................................................................................209
13.2 Overview ........................................................................................................209
13.3 Block Diagram ...............................................................................................210
13.4 I/O Lines Description .....................................................................................210
13.5 Product Dependencies ..................................................................................210
13.6 Functional Description ...................................................................................211
13.7 User Interface ................................................................................................220
13.8 Module Configuration ....................................................................................243
14 System Control Interface (SCIF) ......................................................... 244
14.1 Features ........................................................................................................244
14.2 Overview ........................................................................................................244
14.3 I/O Lines Description .....................................................................................244
14.4 Product Dependencies ..................................................................................244
14.5 Functional Description ...................................................................................245
14.6 User Interface ................................................................................................265
14.7 Module Configuration ....................................................................................318
15 Asynchronous Timer (AST) ................................................................ 322
15.1 Features ........................................................................................................322
15.2 Overview ........................................................................................................322
15.3 Block Diagram ...............................................................................................323
15.4 Product Dependencies ..................................................................................323
15.5 Functional Description ...................................................................................324
15.6 User Interface ................................................................................................330
iv
32142D–06/2013
ATUC64/128/256L3/4U
15.7 Module Configuration ....................................................................................351
16 Watchdog Timer (WDT) ....................................................................... 352
16.1 Features ........................................................................................................352
16.2 Overview ........................................................................................................352
16.3 Block Diagram ...............................................................................................352
16.4 Product Dependencies ..................................................................................352
16.5 Functional Description ...................................................................................353
16.6 User Interface ................................................................................................358
16.7 Module Configuration ....................................................................................364
17 External Interrupt Controller (EIC) ..................................................... 365
17.1 Features ........................................................................................................365
17.2 Overview ........................................................................................................365
17.3 Block Diagram ...............................................................................................365
17.4 I/O Lines Description .....................................................................................366
17.5 Product Dependencies ..................................................................................366
17.6 Functional Description ...................................................................................366
17.7 User Interface ................................................................................................370
17.8 Module Configuration ....................................................................................386
18 Frequency Meter (FREQM) .................................................................. 387
18.1 Features ........................................................................................................387
18.2 Overview ........................................................................................................387
18.3 Block Diagram ...............................................................................................387
18.4 Product Dependencies ..................................................................................387
18.5 Functional Description ...................................................................................388
18.6 User Interface ................................................................................................390
18.7 Module Configuration ....................................................................................401
19 General-Purpose Input/Output Controller (GPIO) ............................. 403
19.1 Features ........................................................................................................403
19.2 Overview ........................................................................................................403
19.3 Block Diagram ...............................................................................................403
19.4 I/O Lines Description .....................................................................................404
19.5 Product Dependencies ..................................................................................404
19.6 Functional Description ...................................................................................405
19.7 User Interface ................................................................................................410
19.8 Module Configuration ....................................................................................433
v
32142D–06/2013
ATUC64/128/256L3/4U
20 Universal Synchronous Asynchronous Receiver Transmitter (USART)
434
20.1 Features ........................................................................................................434
20.2 Overview ........................................................................................................434
20.3 Block Diagram ...............................................................................................435
20.4 I/O Lines Description ....................................................................................436
20.5 Product Dependencies ..................................................................................436
20.6 Functional Description ...................................................................................437
20.7 User Interface ................................................................................................463
20.8 Module Configuration ....................................................................................485
21 Serial Peripheral Interface (SPI) ......................................................... 486
21.1 Features ........................................................................................................486
21.2 Overview ........................................................................................................486
21.3 Block Diagram ...............................................................................................487
21.4 Application Block Diagram .............................................................................487
21.5 I/O Lines Description .....................................................................................488
21.6 Product Dependencies ..................................................................................488
21.7 Functional Description ...................................................................................488
21.8 User Interface ................................................................................................499
21.9 Module Configuration ....................................................................................526
22 Two-wire Master Interface (TWIM) ...................................................... 527
22.1 Features ........................................................................................................527
22.2 Overview ........................................................................................................527
22.3 List of Abbreviations ......................................................................................528
22.4 Block Diagram ...............................................................................................528
22.5 Application Block Diagram .............................................................................529
22.6 I/O Lines Description .....................................................................................529
22.7 Product Dependencies ..................................................................................529
22.8 Functional Description ...................................................................................531
22.9 User Interface ................................................................................................543
22.10 Module Configuration ....................................................................................560
23 Two-wire Slave Interface (TWIS) ......................................................... 561
23.1 Features ........................................................................................................561
23.2 Overview ........................................................................................................561
23.3 List of Abbreviations ......................................................................................562
vi
32142D–06/2013
ATUC64/128/256L3/4U
23.4 Block Diagram ...............................................................................................562
23.5 Application Block Diagram .............................................................................563
23.6 I/O Lines Description .....................................................................................563
23.7 Product Dependencies ..................................................................................563
23.8 Functional Description ...................................................................................564
23.9 User Interface ................................................................................................574
23.10 Module Configuration ....................................................................................590
24 Inter-IC Sound Controller (IISC) .......................................................... 591
24.1 Features ........................................................................................................591
24.2 Overview ........................................................................................................591
24.3 Block Diagram ...............................................................................................592
24.4 I/O Lines Description .....................................................................................592
24.5 Product Dependencies ..................................................................................592
24.6 Functional Description ...................................................................................593
24.7 IISC Application Examples ............................................................................598
24.8 User Interface ................................................................................................600
24.9 Module configuration .....................................................................................614
25 Pulse Width Modulation Controller (PWMA) ..................................... 615
25.1 Features ........................................................................................................615
25.2 Overview ........................................................................................................615
25.3 Block Diagram ...............................................................................................616
25.4 I/O Lines Description .....................................................................................616
25.5 Product Dependencies ..................................................................................616
25.6 Functional Description ...................................................................................617
25.7 User Interface ................................................................................................623
25.8 Module Configuration ....................................................................................641
26 Timer/Counter (TC) .............................................................................. 642
26.1 Features ........................................................................................................642
26.2 Overview ........................................................................................................642
26.3 Block Diagram ...............................................................................................643
26.4 I/O Lines Description .....................................................................................643
26.5 Product Dependencies ..................................................................................643
26.6 Functional Description ...................................................................................644
26.7 User Interface ................................................................................................659
26.8 Module Configuration ....................................................................................682
vii
32142D–06/2013
ATUC64/128/256L3/4U
27 Peripheral Event System ..................................................................... 683
27.1 Features ........................................................................................................683
27.2 Overview ........................................................................................................683
27.3 Peripheral Event System Block Diagram .......................................................683
27.4 Functional Description ...................................................................................683
27.5 Application Example ......................................................................................686
28 Audio Bit Stream DAC (ABDACB) ...................................................... 687
28.1 Features ........................................................................................................687
28.2 Overview ........................................................................................................687
28.3 Block Diagram ...............................................................................................687
28.4 I/O Lines Description .....................................................................................688
28.5 Product Dependencies ..................................................................................688
28.6 Functional Description ...................................................................................689
28.7 User Interface ................................................................................................696
28.8 Module Configuration ....................................................................................710
29 ADC Interface (ADCIFB) ...................................................................... 711
29.1 Features ........................................................................................................711
29.2 Overview ........................................................................................................711
29.3 Block Diagram ...............................................................................................712
29.4 I/O Lines Description .....................................................................................713
29.5 Product Dependencies ..................................................................................713
29.6 Functional Description ...................................................................................714
29.7 Resistive Touch Screen .................................................................................718
29.8 Operating Modes ...........................................................................................724
29.9 User Interface ................................................................................................726
29.10 Module Configuration ....................................................................................745
30 Analog Comparator Interface (ACIFB) ............................................... 746
30.1 Features ........................................................................................................746
30.2 Overview ........................................................................................................746
30.3 Block Diagram ...............................................................................................747
30.4 I/O Lines Description .....................................................................................747
30.5 Product Dependencies ..................................................................................748
30.6 Functional Description ...................................................................................749
30.7 Peripheral Event Triggers ..............................................................................754
30.8 AC Test mode ................................................................................................754
viii
32142D–06/2013
ATUC64/128/256L3/4U
30.9 User Interface ................................................................................................755
30.10 Module Configuration ....................................................................................769
31 Capacitive Touch Module (CAT) ......................................................... 770
31.1 Features ........................................................................................................770
31.2 Overview ........................................................................................................770
31.3 Block Diagram ...............................................................................................771
31.4 I/O Lines Description .....................................................................................771
31.5 Product Dependencies ..................................................................................772
31.6 Functional Description ...................................................................................774
31.7 User Interface ................................................................................................781
31.8 Module Configuration ....................................................................................816
32 Glue Logic Controller (GLOC) ............................................................ 817
32.1 Features ........................................................................................................817
32.2 Overview ........................................................................................................817
32.3 Block Diagram ...............................................................................................817
32.4 I/O Lines Description .....................................................................................818
32.5 Product Dependencies ..................................................................................818
32.6 Functional Description ...................................................................................818
32.7 User Interface ................................................................................................820
32.8 Module Configuration ....................................................................................825
33 aWire UART (AW) ................................................................................. 826
33.1 Features ........................................................................................................826
33.2 Overview ........................................................................................................826
33.3 Block Diagram ...............................................................................................826
33.4 I/O Lines Description .....................................................................................827
33.5 Product Dependencies ..................................................................................827
33.6 Functional Description ...................................................................................827
33.7 User Interface ................................................................................................830
33.8 Module Configuration ....................................................................................843
34 Programming and Debugging ............................................................ 844
34.1 Overview ........................................................................................................844
34.2 Service Access Bus .......................................................................................844
34.3 On-Chip Debug ..............................................................................................847
34.4 JTAG and Boundary-scan (JTAG) .................................................................855
34.5 JTAG Instruction Summary ...........................................................................863
ix
32142D–06/2013
ATUC64/128/256L3/4U
34.6 aWire Debug Interface (AW) .........................................................................880
35 Electrical Characteristics .................................................................... 897
35.1 Absolute Maximum Ratings* .........................................................................897
35.2 Supply Characteristics ...................................................................................897
35.3 Maximum Clock Frequencies ........................................................................898
35.4 Power Consumption ......................................................................................898
35.5 I/O Pin Characteristics ...................................................................................902
35.6 Oscillator Characteristics ...............................................................................905
35.7 Flash Characteristics .....................................................................................910
35.8 ABDACB Electrical Characteristics. .............................................................911
35.9 Analog Characteristics ...................................................................................912
35.10 Timing Characteristics ...................................................................................921
36 Mechanical Characteristics ................................................................. 931
36.1 Thermal Considerations ................................................................................931
36.2 Package Drawings .........................................................................................932
36.3 Soldering Profile ............................................................................................937
37 Ordering Information ........................................................................... 938
38 Errata ..................................................................................................... 940
38.1 Rev. C ............................................................................................................940
38.2 Flash ..............................................................................................................942
38.3 Rev. B ............................................................................................................942
38.4 Flash .............................................................................................................946
38.5 Rev. A ............................................................................................................946
39 Datasheet Revision History ................................................................ 953
39.1 Rev. D – 06/2013 ...........................................................................................953
39.2 Rev. C – 01/2012 ...........................................................................................953
39.3 Rev. B – 12/2011 ...........................................................................................953
39.4 Rev. A – 12/2011 ...........................................................................................953
Table of Contents....................................................................................... i
Atmel Corporation
1600 Technology Drive
San Jose, CA 95110
USA
Tel: (+1) (408) 441-0311
Fax: (+1) (408) 487-2600
www.atmel.com
Atmel Asia Limited
Unit 01-5 & 16, 19F
BEA Tower, Millennium City 5
418 Kwun Tong Roa
Kwun Tong, Kowloon
HONG KONG
Tel: (+852) 2245-6100
Fax: (+852) 2722-1369
Atmel Munich GmbH
Business Campus
Parkring 4
D-85748 Garching b. Munich
GERMANY
Tel: (+49) 89-31970-0
Fax: (+49) 89-3194621
Atmel Japan G.K.
16F Shin-Osaki Kangyo Bldg
1-6-4 Osaki, Shinagawa-ku
Tokyo 141-0032
JAPAN
Tel: (+81) (3) 6417-0300
Fax: (+81) (3) 6417-0370
© 2013 Atmel Corporation. All rights reserved. / Rev.: 32142D–AVR32–06/2013
Atmel®, logo and combinations thereof, AVR®, picoPower®, QTouch®, AKS® and others are registered trademarks or trademarks of Atmel Corporation
or its subsidiaries. Other terms and product names may be trademarks of others.
Disclaimer: The information in this document is provided in connection with Atmel products. No license, express or implied, by estoppel or otherwise, to any intellectual property right is granted by this
document or in connection with the sale of Atmel products. EXCEPT AS SET FORTH IN THE ATMEL TERMS AND CONDITIONS OF SALES LOCATED ON THE ATMEL WEBSITE, ATMEL ASSUMES
NO LIABILITY WHATSOEVER AND DISCLAIMS ANY EXPRESS, IMPLIED OR STATUTORY WARRANTY RELATING TO ITS PRODUCTS INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. IN NO EVENT SHALL ATMEL BE LIABLE FOR ANY DIRECT, INDIRECT,
CONSEQUENTIAL, PUNITIVE, SPECIAL OR INCIDENTAL DAMAGES (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS AND PROFITS, BUSINESS INTERRUPTION, OR LOSS OF
INFORMATION) ARISING OUT OF THE USE OR INABILITY TO USE THIS DOCUMENT, EVEN IF ATMEL HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Atmel makes no
representations or warranties with respect to the accuracy or completeness of the contents of this document and reserves the right to make changes to specifications and products descriptions at any time
without notice. Atmel does not make any commitment to update the information contained herein. Unless specifically provided otherwise, Atmel products are not suitable for, and shall not be used in,
automotive applications. Atmel products are not intended, authorized, or warranted for use as components in applications intended to support or sustain life.
USB Demonstrations Help
MPLAB Harmony Integrated Software Framework
© 2013-2018 Microchip Technology Inc. All rights reserved.
Volume I: Getting Started With MPLAB Harmony Libraries and Applications
This volume introduces the MPLAB® Harmony Integrated Software Framework.
Description
MPLAB Harmony is a layered framework of modular libraries that provide flexible and interoperable software "building
blocks" for developing embedded PIC32 applications. MPLAB Harmony is also part of a broad and expandable
ecosystem, providing demonstration applications, third-party offerings, and convenient development tools, such as the
MPLAB Harmony Configurator (MHC), which integrate with the MPLAB X IDE and MPLAB XC32 language tools.
Legal Notices
Please review the Software License Agreement prior to using MPLAB Harmony. It is the responsibility of the end-user to know and understand the
software license agreement terms regarding the Microchip and third-party software that is provided in this installation. A copy of the agreement is
available in the /doc folder of your MPLAB Harmony installation.
The OPENRTOS® demonstrations provided in MPLAB Harmony use the OPENRTOS evaluation license, which is meant for demonstration
purposes only. Customers desiring development and production on OPENRTOS must procure a suitable license. Please refer to one of the
following documents, which are located in the /third_party/rtos/OPENRTOS/Documents folder of your MPLAB Harmony
installation, for information on obtaining an evaluation license for your device:
• OpenRTOS Click Thru Eval License PIC32MXxx.pdf
• OpenRTOS Click Thru Eval License PIC32MZxx.pdf
TIP!
Throughout this documentation, occurrences of refer to the default MPLAB Harmony installation path:
• Windows: C:/microchip/harmony/
• Mac OS/Linux: ~/microchip/harmony/
Volume I: Getting Started With MPLAB Harmony
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 2
Applications Help
This section provides information on the various application demonstrations that are included in MPLAB Harmony.
Description
Applications determine how MPLAB Harmony libraries (device drivers, middleware, and system services) are used to do something useful. In a
MPLAB Harmony system, there may be one main application, there may be multiple independent applications or there may be one or more
Operating System (OS) specific applications. Applications interact with MPLAB Harmony libraries through well defined interfaces. Applications may
operate in a strictly polling environment, they may be interrupt driven, they may be executed in OS-specific threads, or they may be written so as to
be flexible and easily configured for any of these environments. Applications generally fit into one of the following categories.
Demonstration Applications
Demonstration applications are provided (with MPLAB Harmony or in separate installations) to demonstrate typical or interesting usage models of
one or more MPLAB Harmony libraries. Demonstration applications can demonstrate realistic solutions to real-life problems.
Sample Applications
Sample applications are extremely simple applications provided with MPLAB Harmony as examples of how to use individual features of a library.
They will not normally accomplish anything useful on their own. They are provided primarily as documentation to show how to use a library.
USB Demonstrations
This section provides descriptions of the USB demonstrations.
MPLAB Harmony is available for download from the Microchip website by visiting: http://www.microchip.com/mplabharmony. Once you are on the
site, click the Downloads tab to access the appropriate download for your operating system. For additional information on this demonstration, refer
to the “Applications Help” section in the MPLAB Harmony Help.
Introduction
USB Library Demonstration Applications Help
Description
This distribution package contains a variety of USB-related firmware projects that demonstrate the capabilities of the MPLAB Harmony USB stack.
This section describes the hardware requirement and procedures to run these firmware projects on Microchip demonstration and development
boards.
To know more about the MPLAB Harmony USB stack and configuring the USB stack and the APIs provided by the USB stack, refer to the USB
Library documentation.
Program, Data Memory, and Stack Component Memory
Refer to USB Device Stack Demonstration Application Program and Data Memory Requirements and USB Device Stack Component Memory
Requirements for important memory information.
Pen Drive Tests
Refer to USB MSD Host USB Pen Drive Tests for information on the tests conducted on USB Flash devices.
USB Device Stack Demonstration Application Program and Data Memory Requirements
Provides information on program and data memory requirements, as well as pen drive test specifications.
Description
Program Memory and Data Memory Requirements with -O1 Optimization
The following table shows the program memory and data memory requirements of the USB Device Stack demonstration applications. All size
figures are in bytes. Demonstration applications were compiled with the MPLAB XC32 C/C++ Compiler, v1.40, with –O1 optimization.
Volume I: Getting Started With MPLAB Harmony Applications Help USB Demonstrations
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 3
Note:
The msd_basic, cdc_msd_basic, and the hid_msd_basic demonstrations use the PIC32 program Flash memory as the MSD
storage media. The difference in Data Memory requirements between the PIC32MX and PIC32MZ microcontrollers for these
demonstration examples, is due to an application demonstration buffer whose size is equal to the erase page size of the PIC32
microcontroller. On the PIC32MX795F512L, this size is 4096 bytes. On the PIC32MZ2048ECH144, the erase page size is 16 KB.
Program Memory and Data Memory Requirements with -Os Optimization
The following table shows the program memory and data memory requirements of the USB Device Stack demonstration applications. All size
figures are in bytes. Demonstration applications were compiled with the MPLAB XC32 C/C++ Compiler, v1.40, with –Os optimization.
Volume I: Getting Started With MPLAB Harmony Applications Help USB Demonstrations
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 4
USB Device Stack Component Memory Requirements
Provides memory requirements.
Description
The following table shows the Program and Data Memory requirements for individual components in the MPLAB Harmony USB Device Stack.
Device Stack Component Program
Memory
Data Memory
Device Layer 5688 184
CDC Function Driver 2420 64 + (36 * Queue Size)
MSD Function Driver 5352 217
HID Function Driver 2376 40 + (36 * Queue Size)
Vendor 912 8 + (36 * Queue Size)
PIC32MX USB Driver 5636 144 + (32 * Number of Endpoints)
PIC32MZ USB Driver 10244 192 + (32 * Number of Endpoints)
Notes:
1. Memory requirements (in bytes) for a single instance.
2. Size measured for USB Device Stack Components in MPLAB Harmony.
3. Data Memory does not include function call stack memory size.
USB MSD Host USB Pen Drive Tests
Provides pen drive test specifications.
Description
USB MSD Host USB Pen Drive Tests
The following table lists the commercially available USB pen drives, which have been tested to successfully enumerate with the MSD Host Driver
Volume I: Getting Started With MPLAB Harmony Applications Help USB Demonstrations
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 5
in the MPLAB Harmony USB Host. Note that if the USB pen drive you are using in not included in the table, this indicates that this USB pen drive
has not been tested with the MSD Host Driver. However, the USB pen drive could still potentially work with MSD Host Driver. Some USB pen
drives in this table did not have their manufacturer or model data available. The USB Pen drives were tested with the msd_basic USB Host
demonstration in the latest version of the MPLAB Harmony USB Host Stack.
VID PID Manufacturer Model/Drive Capacity
0x1B1C 0x1A0F Corsair Components Flash Voyager Go 8 GB
0x03F0 0x0AB7 Hewlett-Packard 64 GB
0xABCD 0x1234 Microchip Technology Inc. 4 GB
0x125F 0xCB10 Adata Dashdrive UV100 8 GB
0x8644 0x8003 Verico T Series 16 GB
0x8564 0x1000 Transcend USB 3.0 32 GB
0x0951 0x16A7 Dell Kingston Technology 16 GB
0x0718 0x0704 Imation 16 GB Pen Drive
0x048D 0x1168 iBall Jaldi 16 GB Pen Drive
0x058F 0x6366 Alcor Micro AXL 32 GB
0x154B 0x005B PNY Cube 16 GB
0x0930 0x6544 Toshiba Hatabusa Pen Drive 8 GB
0x058F 0x6387 Alcor ZipMem 16 GB
0x090C 0x1000 Silicon Motion Inc. Axl 8GB
0x18A5 0x0245 Verbatim Store N Go Audio USB 8 GB
0x05DC 0xC75C Lexar USB Pen Drive 8 GB
0x1005 0xb113 Apacer 8 GB (AH233)
0x054C 0x06B0 Sony 8 GB
0x054C 0x0862 Sony Micro Vault USM-V 8 GB
0x0781 0x557c SanDisk 8 GB
0x1E4E 0x3257 Etron iBall 16 GB
0x1EC9 0x0101 Moserbaer Swivel 16 GB Pen Drive
0x0BDA 0x0109 SanDisk Standard A and Mini-B connector 16 GB
0x1908 0x1320 ZBEL Wrist Band Flash Drive 4 GB
0x0951 0x1665 Kingston Data Traveler SE9 16 GB
USB HID Host Keyboard and Mouse Tests
Provides information on tested USB keyboard and mouse devices.
Description
The following table lists the commercially available USB keyboard and mouse devices, which have been tested to successfully enumerate with the
HID Host Driver in the MPLAB Harmony USB Host. Note that if the USB HID device you are using in not included in the table, this indicates that
this USB HID device has not been tested, but could still potentially work with the HID Host Driver.
Volume I: Getting Started With MPLAB Harmony Applications Help USB Demonstrations
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 6
Note:
The above tests have been performed only on the PIC32M family of devices.
Demonstration Application Configurations
This topic provides information on the available USB demonstration project configurations.
Description
The available USB Demonstration application MPLAB X IDE projects feature support for multiple configurations. Selecting these configurations
allow for the demonstration projects to run across different PIC32 microcontrollers and development boards. The following project configurations
are available:
Configuration name Description
pic32mx_usb_sk2_int_dyn Selecting this configuration will set up the demonstration application to run on the PIC32 USB Starter Kit II
development board, with the PIC32MX795F512L microcontroller. The USB Stack will be configured for Interrupt
mode operation and the USB Driver will be configured for Dynamic operation mode.
pic32mx_usb_sk2_poll_dyn Selecting this configuration will set up the demonstration application to run on the PIC32 USB Starter Kit II
development board, with the PIC32MX795F512L microcontroller. The USB Stack will be configured for Polled
mode operation and the USB driver will be configured for Dynamic operation mode.
pic32mx_usb_sk3_int_dyn Selecting this configuration will set up the demonstration application to run on the PIC32 USB Starter Kit III
development board, with the PIC32MX470F512L microcontroller. The USB Stack will be configured for Interrupt
mode operation and the USB Driver will be configured for Dynamic operation mode.
pic32mx_bt_sk_int_dyn Selecting this configuration will set up the demonstration application to run on the PIC32 Bluetooth Starter Kit
development board, with the PIC32MX270F256D microcontroller. The USB Stack will be configured for Interrupt
mode operation and the USB Driver will be configured for dynamic operation mode.
pic32mz_da_sk_intddr_int_dyn Selecting this configuration will set up the demonstration application to run on the PIC32MZ Embedded
Graphics with Internal DRAM (DA) Starter Kit development board, with the PIC32MZ2064DAH169
microcontroller. The USB Stack will be configured for Interrupt mode operation and the USB Driver will be
configured for Dynamic operation mode.
pic32mz_ec_sk_int_dyn Selecting this configuration will set up the demonstration application to run on the PIC32MZ EC Starter Kit
development board, with the PIC32MZ2048ECH144 microcontroller. The USB Stack will be configured for
Interrupt mode operation and the USB Driver will be configured for Dynamic operation mode.
pic32mz_ec_sk_poll_dyn Selecting this configuration will set up the demonstration application to run on the PIC32MZ EC Starter Kit
development board, with the PIC32MC2048ECH144 microcontroller. The USB Stack will be configured for
Polled mode operation and the USB Driver will be configured for Dynamic operation mode.
pic32mz_ec_sk_meb2_int_dyn Selecting this configuration will set up the demonstration application to run on the PIC32MZ EC Starter Kit, with
the PIC32MZ2048ECH144 microcontroller board attached to the MEB II. The USB Stack will be configured for
Interrupt mode operation and the USB Driver will be configured for Dynamic operation mode.
pic32mz_ef_sk_int_dyn Selecting this configuration will set up the demonstration application to run on the PIC32MZ EF Starter Kit, with
the PIC32MZ2048EFM144 microcontroller. The USB Stack will be configured for Interrupt mode operation and
the USB Driver will be configured for Dynamic operation mode.
Volume I: Getting Started With MPLAB Harmony Applications Help USB Demonstrations
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 7
pic32mz_ef_sk_poll_dyn Selecting this configuration will set up the demonstration application to run on the PIC32MZ EF Starter Kit
development board, with the PIC32MZ2048EFM144 microcontroller. The USB Stack will be configured for
Polled mode operation and the USB Driver will be configured for Dynamic operation mode.
pic32mx795_pim_e16_int_dyn Selecting this configuration will set up the demonstration application to run on the Explorer 16 Development
Board along with the PIC32MX795F512L microcontroller Plug In Module and USB PICtail Plus Daughter Board.
The USB Stack will be configured for Interrupt mode operation and the USB Driver will be configured for
Dynamic operation mode.
pic32mx460_pim_e16_int_dyn Selecting this configuration will set up the demonstration application to run on the Explorer 16 Development
Board along with the PIC32MX460F512L microcontroller Plug In Module and USB PICtail Plus Daughter Board.
The USB Stack will be configured for Interrupt mode operation and the USB Driver will be configured for
Dynamic operation mode.
pic32mx470_curiosity Selecting this configuration will set up the demonstration application to run on the PIC32MX470 Curiosity
Development Board, with the PIC32MX470F512H microcontroller. The USB Stack will be configured for
Interrupt mode operation and the USB Driver will be configured for Dynamic operation mode.
pic32mz_ef_curiosity Selecting this configuration will set up the demonstration application to run on the PIC32MZ EF Curiosity
Development Board, with the PIC32MZ2048EFM100 microcontroller. The USB Stack will be configured for
Interrupt mode operation and the USB Driver will be configured for Dynamic operation mode.
pic32mk_evk_int_dyn Selecting this configuration will set up the demonstration application to run on the PIC32MK GP Development
Board, with the PIC32MK1024GPE100 microcontroller. The USB Stack will be configured for Interrupt mode
operation and the USB Driver will be configured for Dynamic operation mode.
pic32mx_xlp_sk_int_dyn Selecting this configuration will set up the demonstration application to run on the PIC32MX XLP Starter Kit, with
the PIC32MX274F256D microcontroller. The USB Stack will be configured for Interrupt mode operation and the
USB Driver will be configured for Dynamic operation mode.
chipkit_wf32 Selecting this configuration will set up the demonstration application to run on the chipKIT WF32 Wi-Fi
Development Board, with the PIC32MZ2048EFG100 microcontroller. The USB Stack will be configured for
Interrupt mode operation and the USB Driver will be configured for Dynamic operation mode.
chipkit_wifire Selecting this configuration will set up the demonstration application to run on the chipKIT Wi-FIRE
Development Board, with the PIC32MX275F256D microcontroller. The USB Stack will be configured for
Interrupt mode operation and the USB Driver will be configured for Dynamic operation mode.
The following figure shows how a configuration can be selected in MPLAB X IDE.
Alternatively, the active configuration can be selected in the Project Properties.
USB Device Demonstrations Matrix
The following table shows the availability of a configuration across available USB Device demonstration applications. Green indicates support.
Red indicates no support.
Volume I: Getting Started With MPLAB Harmony Applications Help USB Demonstrations
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 8
USB Host Demonstration Matrix
The following table shows the availability of a configuration across available USB Host demonstration applications. Green indicates support. Red
indicates no support.
USB Multiple Controller Demonstration Matrix
The following table shows the availability of a configuration across available USB Multiple Controller Demonstration applications. Green indicates
support. Red indicates no support.
Volume I: Getting Started With MPLAB Harmony Applications Help USB Demonstrations
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 9
Demonstrations
The USB Demonstrations are grouped into USB Device Stack, USB Host Stack, USB Dual Role, and USB demonstrations that make use of
multiple USB controllers on certain PIC32 family devices.
Device
This section describes the USB Device demonstrations.
Description
The MPLAB Harmony USB Device Stack demonstration applications uses LEDs on the development board to indicate the USB state of the device.
The following table provides details on the development board specific LEDs and the USB Device State these indicate when active. This indication
scheme is implemented by all USB Device Stack Demonstration applications.
USB Device State and LED Indication
Demonstration Board Reset State Configured
State
Suspended
State
Explorer 16 Development Board and PIM D3, D4 D5 D4, D5
PIC32 USB Starter Kit II LED1, LED2 LED3 LED2, LED3
PIC32MZ Embedded Connectivity (EC) Starter Kit LED1, LED2 LED3 LED2, LED3
PIC32MZ Embedded Connectivity with Floating Point Unit (EF) Starter Kit LED1, LED2 LED3 LED2, LED3
PIC32 USB Starter Kit III LED1, LED2 LED3 LED2, LED3
PIC32 Bluetooth Starter Kit Red LED,
Green LED
Blue LED Green LED,
Blue LED
PIC32MX470 Curiosity Development Board LED1, LED2 LED3 LED2, LED3
PIC32MZ EF Curiosity Development Board LED1, LED2 LED3 LED2, LED3
cdc_com_port_dual
Demonstrates a USB CDC device, emulating dual serial COM ports - one looping back into the other.
Description
This demonstration application creates a USB CDC Device that enumerates as two serial ports on the USB Host personal computer. This
application demonstrates the ability of the MPLAB Harmony USB Device Stack to support multiple instances of the same Device class.
Building the Application
This section identifies the MPLAB X IDE project name and location and lists and describes the available configurations for the USB CDC Device
Dual COM Port Demonstration.
Description
To build this project, you must open the cdc_com_port_dual.X project in MPLAB X IDE, and then select the desired configuration.
Volume I: Getting Started With MPLAB Harmony Applications Help USB Demonstrations
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 10
The following tables list and describe the project and supported configurations. The parent folder for these files is
/apps/usb/device/cdc_com_port_dual.
MPLAB X IDE Project
This table lists the name and location of the MPLAB X IDE project folder for the demonstration.
Project Name Location
cdc_com_port_dual.X /apps/usb/device/cdc_com_port_dual/firmware
MPLAB X IDE Project Configurations
This table lists and describes the supported configurations of the demonstration, which are located within ./firmware/src/system_config.
Project Configuration Name BSP Used Description
pic32mx460_pim_e16_int_dyn pic32mx460_pim+e16 Select this MPLAB X IDE project configuration to run the demonstration on the Explorer
16 Development Board configured for Interrupt mode and dynamic operation. This
configuration also requires PIC32MX460F512L Plug-In Module (PIM) and the USB
PICtail Plus Daughter Board.
pic32mx_bt_sk_int_dyn pic32mx_bt_sk Select this MPLAB X IDE project configuration to run the demonstration on the PIC32
Bluetooth Starter Kit configured for Interrupt mode and dynamic operation.
pic32mx_usb_sk3_int_dyn pic32mx_usb_sk3 Select this MPLAB X IDE project configuration to run the demonstration on the PIC32
USB Starter Kit III configured for Interrupt mode and dynamic operation.
pic32mx_usb_sk2_int_dyn pic32mx_usb_sk2 Select this MPLAB X IDE project configuration to run the demonstration on the PIC32
USB Starter Kit II configured for Interrupt mode and dynamic operation.
pic32mx_xlp_sk_int_dyn pic32mx_xlp_sk Select this MPLAB X IDE project configuration to run the demonstration on the PIC32MX
XLP Starter Kit configured for Interrupt mode and dynamic operation.
pic32mz_ef_sk_int_dyn pic32mz_ef_sk Select this MPLAB X IDE project configuration to run the demonstration on the PIC32MZ
Embedded Connectivity with Floating Point Unit (EF) Starter Kit configured for Interrupt
mode and dynamic operation.
pic32mx470_curiosity pic32mx470_curiosity Select this MPLAB X IDE project configuration to run the demonstration application to
run on the PIC32MX470 Curiosity Development Board, with the PIC32MX470F512H
microcontroller. The USB Stack will be configured for Interrupt mode operation and the
USB Driver will be configured for Dynamic operation mode.
pic32mz_ef_curiosity pic32mz_ef_curiosity Select this MPLAB X IDE project configuration to run the demonstration application to
run on the PIC32MZ EF Curiosity Development Board, with the PIC32MZ2048EFM100
microcontroller. The USB Stack will be configured for Interrupt mode operation and the
USB Driver will be configured for Dynamic operation mode.
Configuring the Hardware
Describes how to configure the supported hardware.
Description
PIC32 USB Starter Kit II
Remove jumper JP2.
PIC32MZ EC Starter Kit
Remove jumper JP1.
PIC32MZ EF Starter Kit
No hardware related configuration or jumper setting changes are necessary.
PIC32MX XLP Starter Kit
No hardware related configuration or jumper setting changes are necessary.
PIC32 USB Starter Kit III
Remove jumper JP1.
Volume I: Getting Started With MPLAB Harmony Applications Help USB Demonstrations
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 11
PIC32 Bluetooth Starter Kit
Jumper J8 should either be shorted between pins 2 and 3 or should be completely open.
PIC32MX460F512L PIM
Jumper J10 should be removed. This plug-in module should be used along with the Explorer 16 Development Board and the USB PICtail Plus
daughter board. The microcontroller PIM should be plugged into the PIM_socket_on the board. The USB PICtail Plus daughter board should be
connected to the edge connector J9.
On the Explorer 16 Development Board:
• Switch S2 should be set to PIM
• Jumper JP2 should be in place
On the USB PICtail Plus Daughter Board:
• Jumper JP1 should be in place
• Jumper JP2 and JP4 should be removed
On the PIC32MX460F512L PIM:
• Keep jumper J10 open
• Keep all jumpers in J9 open
PIC32MX470 Curiosity Development Board
• Ensure that a jumper is placed at 4-3 on J8, to select supply from debug USB connector.
• Power the PIC32MX470 Curiosity Development Board from a Host PC through a Type-A male to mini-B USB cable connected to Mini-B port
(J3).
• Ensure that jumper is not present in the J13 header to use the Curiosity board in device mode.
• Plug in a USB cable with a micro-B type connector to Micro-B port (J12), and plug the other end into your computer.
PIC32MZ EF Curiosity Development Board
• Ensure that a jumper is placed at 4-3 on J8, to select supply from debug USB connector.
• Power the PIC32MZ EF Curiosity Development Board from a Host PC through a Type-A male to micro-B USB cable connected to Micro-B port
(J3).
Volume I: Getting Started With MPLAB Harmony Applications Help USB Demonstrations
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 12
• Ensure that jumper is not present in the J13 header to use the Curiosity board in device mode.
• Plug in a USB cable with a micro-B type connector to Micro-B port (J12), and plug the other end into your computer.
Running the Demonstration
Provides instructions on how to build and run the CDC Dual COM Port demonstration.
Description
This demonstration allows the device to appear like dual serial (COM) ports to the host. Do the following to run this demonstration:
1. First compile and program the target device. While compiling, select the appropriate MPLAB X IDE project configuration based on the
demonstration board. Refer to Building the Application for details.
2. Attach the device to the host. If the host is a personal computer and this is the first time you have plugged this device into the computer you
may be prompted for a .inf file.
Volume I: Getting Started With MPLAB Harmony Applications Help USB Demonstrations
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 13
3. Select the "Install from a list or specific location (Advanced)" option. Specify the
/apps/usb/device/cdc_com_port_dual/inf directory.
Volume I: Getting Started With MPLAB Harmony Applications Help USB Demonstrations
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 14
Note:
As an option, to specify the driver, you may open the device manager and expand the Ports (COM & LPT) tab, and right click on
“Update Driver Software…”
Verify that the enumerated USB device is seen as a virtual USB serial comport in Device Manager.
4. Once the device is successfully installed, open up two instances of a terminal program, such as HyperTerminal. Select the appropriate COM
port for each of these terminal instances. The following screen shot shows the COM port selection for the Tera Term terminal program.
Volume I: Getting Started With MPLAB Harmony Applications Help USB Demonstrations
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 15
5. The LEDs on the demonstration board will indicate the USB state of the device, as described in the USB Device State and LED Indication
Table in the Device section.
6. To run the demonstration, turn on local echo on both the terminals. For Tera Term terminal application, navigate to Setup->Terminal to turn on
local echo. Type a character or string in one terminal window. The same character or string appears on the second terminal window. Similarly,
any character typed in the second window appears in the first window. The following screen shot shows two instances of Tera Term.
Note:
Some terminal programs, like HyperTerminal, require users to click the disconnect button before removing the device from the
computer. Failing to do so may result in having to close and open the program again to reconnect to the device.
cdc_com_port_single
Demonstrates a USB CDC device, emulating a serial COM port.
Volume I: Getting Started With MPLAB Harmony Applications Help USB Demonstrations
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 16
Description
This demonstration application creates a USB CDC Device that enumerates as a single COM port on the host personal computer. The application
demonstrates two-way communication between the USB device and the personal computer host.
Building the Application
This section identifies the MPLAB X IDE project name and location and lists and describes the available configurations for the USB CDC Device
Single COM Port Demonstration.
Description
To build this project, you must open the cdc_com_port_single.X project in MPLAB X IDE, and then select the desired configuration.
The following tables list and describe the project and supported configurations. The parent folder for these files is
/apps/usb/device/cdc_com_port_single.
MPLAB X IDE Project
This table lists the name and location of the MPLAB X IDE project folder for the demonstration.
Project Name Location
cdc_com_port_single.X /apps/usb/device/cdc_com_port_single/firmware
MPLAB X IDE Project Configurations
This table lists and describes the supported configurations of the demonstration, which are located within ./firmware/src/system_config.
Project Configuration Name BSP Used Description
pic32mx460_pim_e16_int_dyn pic32mx460_pim+e16 Select this MPLAB X IDE project configuration to run the demonstration on the
Explorer 16 Development Board configured for Interrupt mode and dynamic
operation. This configuration also requires PIC32MX460F512L Plug-In Module
(PIM) and the USB PICtail Plus Daughter Board.
pic32mx_usb_sk2_poll_dyn pic32mx_bt_sk Select this MPLAB X IDE project configuration to run the demonstration on the
PIC32 USB Starter Kit II with the USB Device Stack configured for Polled mode and
dynamic operation.
pic32mx_usb_sk3_int_dyn pic32mx_usb_sk3 Select this MPLAB X IDE project configuration to run the demonstration on the
PIC32 USB Starter Kit III configured for Interrupt mode and dynamic operation.
pic32mx_usb_sk2_int_dyn pic32mx_usb_sk2 Select this MPLAB X IDE project configuration to run the demonstration on the
PIC32 USB Starter Kit II configured for Interrupt mode and dynamic operation.
pic32mz_da_sk_intddr_int_dyn pic32mz_da_sk_intddr Select this MPLAB X IDE project configuration to run the demonstration on the
PIC32MZ Embedded Graphics with Internal DRAM (DA) Starter Kit configured for
Interrupt mode and dynamic operation.
pic32mz_ef_sk_int_dyn_micromips pic32mz_ef_sk Select this MPLAB X IDE project configuration to run the demonstration on the
PIC32MZ Embedded Connectivity with Floating Point Unit (EF) Starter Kit
configured in microMIPS mode for Interrupt mode and dynamic operation.
pic32mz_ef_sk_int_dyn pic32mz_ef_sk Select this MPLAB X IDE project configuration to run the demonstration on the
PIC32MZ Embedded Connectivity with Floating Point Unit (EF) Starter Kit
configured for Interrupt mode and dynamic operation.
pic32mz_ef_sk_poll_dyn pic32mz_ef_sk Select this MPLAB X IDE project configuration to run the demonstration on the
PIC32MZ Embedded Connectivity with Floating Point Unit (EF) Starter Kit with the
USB Device Stack configured for Polled mode and dynamic operation.
pic32mx_125_sk_int_dyn pic32mx_125_sk Select this MPLAB X IDE project configuration to run the demonstration on the
PIC32MX1/2/5 Starter Kit with the USB Device Stack configured for Interrupt mode
and dynamic operation.
Configuring the Hardware
Describes how to configure the supported hardware.
Description
PIC32 USB Starter Kit II
Remove jumper JP2.
Volume I: Getting Started With MPLAB Harmony Applications Help USB Demonstrations
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 17
PIC32MZ Embedded Graphics with Internal DRAM (DA) Starter Kit
No hardware related configuration or jumper setting changes are necessary.
PIC32MZ EF Starter Kit
No hardware related configuration or jumper setting changes are necessary.
PIC32 USB Starter Kit III
Remove jumper JP1.
PIC32MX460F512L PIM
Jumper J10 should be removed. This plug-in module should be used along with the Explorer 16 Development Board and the USB PICtail Plus
daughter board. The microcontroller PIM should be plugged into the PIM_socket_on the board. The USB PICtail Plus daughter board should be
connected to the edge connector J9.
On the Explorer 16 Development Board:
• Switch S2 should be set to PIM
• Jumper JP2 should be in place
On the USB PICtail Plus Daughter Board:
• Jumper JP1 should be in place
• Jumper JP2 and JP4 should be removed
On the PIC32MX460F512L PIM:
• Keep jumper J10 open
• Keep all jumpers in J9 open
PIC32WK Wi-Fi Starter Kit
No hardware related configuration or jumper setting changes are necessary.
Running the Demonstration
Provides instructions on how to build and run the CDC Single COM Port demonstration.
Description
This demonstration allows the device to appear like a serial (COM) port to the host. Do the following to run this demonstration:
1. First compile and program the target device. While compiling, select the appropriate MPLAB X IDE project configuration based on the
demonstration board. Refer to Building the Application for details.
2. Attach the device to the host. If the host is a personal computer and this is the first time you have plugged this device into the computer, you
may be prompted for a .inf file.
3. Select the "Install from a list or specific location (Advanced)" option. Specify the
/apps/usb/device/cdc_com_port_single/inf directory.
Volume I: Getting Started With MPLAB Harmony Applications Help USB Demonstrations
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 18
4. Once the device is successfully installed, open up a terminal program, such as HyperTerminal and select the appropriate COM port. On most
machines this will be COM5 or higher. Set the communication properties to 9600 baud, 1 Stop bit and No parity, with Flow Control set to None.
5. The LEDs on the demonstration board will indicate the USB state of the device, as described in the USB Device State and LED Indication
Table in the Device section.
6. Once connected to the device, there are two ways to run this example project:
• a) Typing a key in the terminal window will result in the attached device echoing the next letter. Therefore, if the letter 'b' is pressed, the
device will echo 'c'.
• b) If the push button is pressed, the device will echo "PUSH BUTTON PRESSED" to the terminal window.
The following table shows the switch buttons to be pressed for different demonstration boards.
Demonstration Board Button
PIC32 USB Starter Kit II
PIC32 USB Starter Kit III
PIC32MZ Embedded Graphics with Internal DRAM (DA) Starter Kit
PIC32MZ Embedded Connectivity (EC) Starter Kit
PIC32MZ Embedded Connectivity with Floating Point Unit (EF) Starter Kit
PIC32WK Wi-Fi Starter Kit
SW1
Explorer 16 Development Board S3
Note:
Some terminal programs, like HyperTerminal, require users to click the disconnect button before removing the device from the
computer. Failing to do so may result in having to close and open the program again to reconnect to the device.
cdc_msd_basic
Demonstrates a composite USB device emulating a COM port and Flash drive.
Description
This demonstration application creates a composite USB Device that enumerates as a COM port and as Flash drive simultaneously.
Building the Application
This section identifies the MPLAB X IDE project name and location and lists and describes the available configurations for the USB CDC MSD
Composite Device Demonstration.
Description
To build this project, you must open the cdc_msd_basic.X project in MPLAB X IDE, and then select the desired configuration.
The following tables list and describe the project and supported configurations. The parent folder for these files is
/apps/usb/device/cdc_msd_basic.
MPLAB X IDE Project
This table lists the name and location of the MPLAB X IDE project folder for the demonstration.
Volume I: Getting Started With MPLAB Harmony Applications Help USB Demonstrations
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 19
Project Name Location
cdc_msd_basic.X /apps/usb/device/cdc_msd_basic/firmware
MPLAB X IDE Project Configurations
This table lists and describes the supported configurations of the demonstration, which are located within ./firmware/src/system_config.
Project Configuration
Name
BSP Used Description
pic32mx_usb_sk2_int_dyn pic32mx_usb_sk2 Select this MPLAB X IDE project configuration to run the demonstration on the PIC32 USB
Starter Kit II configured for Interrupt mode and dynamic operation.
pic32mz_ef_sk_int_dyn pic32mz_ef_sk Select this MPLAB X IDE project configuration to run the demonstration on the PIC32MZ
Embedded Connectivity with Floating Point Unit (EF) Starter Kit configured for Interrupt mode
and dynamic operation.
Configuring the Hardware
Description
PIC32 USB Starter Kit II
Remove jumper JP2.
PIC32MZ EF Starter Kit
No hardware related configuration or jumper setting changes are necessary.
Running the Demonstration
Provides instructions on how to build and run the USB CDC MSD Composite Device demonstration.
Description
This demonstration application creates a composite USB Device that works simultaneously as a CDC and as a MSD device. This application
combines the functionality of the cdc_com_port_single and msd_basic demonstration applications into one device.
Refer to Running the Demonstration section of the cdc_com_port_single demonstration and the Running the Demonstration section of the
msd_basic demonstration for details on exercising the CDC and MSD device features, respectively.
The LEDs on the demonstration board will indicate the USB state of the device, as described in the USB Device State and LED Indication Table in
the Device section.
cdc_serial_emulator
This application demonstrates the use of the CDC device class in implementing a USB-to-Serial Dongle.
Description
This application demonstrates the use of the CDC device class in implementing a USB-to-Serial Dongle. The application enumerates a COM port
on the personal computer. Data received through the CDC USB interface is forwarded to a UART. Data received on the UART is forwarded to the
CDC USB interface. This emulates a USB-to-Serial Dongle.
Building the Application
This section identifies the MPLAB X IDE project name and location and lists and describes the available configurations for the USB CDC Device
USB-to-Serial Demonstration.
Description
To build this project, you must open the cdc_serial_emulator.X project in MPLAB X IDE, and then select the desired configuration.
The following tables list and describe the project and supported configurations. The parent folder for these files is
/apps/usb/device/cdc_serial_emulator.
MPLAB X IDE Project
This table lists the name and location of the MPLAB X IDE project folder for the demonstration.
Volume I: Getting Started With MPLAB Harmony Applications Help USB Demonstrations
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 20
Project Name Location
cdc_serial_emulator.X /apps/usb/device/cdc_serial_emulator/firmware
MPLAB X IDE Project Configurations
This table lists and describes the supported configurations of the demonstration, which are located within ./firmware/src/system_config.
Project Configuration Name BSP Used Description
pic32mx795_pim_e16_int_dyn pic32mx795_pim+e16 Select this MPLAB X IDE project configuration to run the demonstration on the Explorer
16 Development Board configured for Interrupt mode and dynamic operation. This
configuration also requires the PIC32MX795F512L Plug-In Module (PIM) and the USB
PICtail Plus Daughter Board.
pic32mz_ef_sk_int_dyn pic32mz_ef_sk Select this MPLAB X IDE project configuration to run the demonstration on the PIC32MZ
EF Starter Kit configured for Interrupt mode and dynamic operation.
Configuring the Hardware
Describes how to configure the supported hardware.
Description
PIC32MZ EF Starter Kit
No hardware related configuration or jumper setting changes are necessary.
PIC32MX795F512L CAN-USB PIM
Jumper J10 should be removed. Jumper J1 and J2 should_connect_to positions 1 and 2. This PIM should be used along with the Explorer 16
Development Board and the USB PICtail Plus daughter board. The microcontroller PIM should be plugged into the PIM_socket_on the board. The
USB PICtail Plus daughter board should be connected to the edge connector J9.
On the Explorer 16 Development Board:
• Switch S2 should be set to PIM
• Jumper JP2 should be in place
On the USB PICtail Plus Daughter Board:
• Jumper JP1 should be in place
• Jumper JP2 and JP4 should be removed
On the PIC32MX795F512L PIM:
• Keep jumper J10 open
• Keep all jumpers in J9 open
• Jumper J1 should be shorted between positions 1 and 2. This configuration is only applicable for the PIC32MX795F512L USB CAN PIM
(MA320003), and not the PIC32MX795F512L USB PIM (MA320002).
• Jumper J2 should be shorted between positions 1 and 2. This configuration is only applicable for the PIC32MX795F512L USB CAN PIM
(MA320003) and not the PIC32MX795F512L USB PIM (MA320002).
Running the Demonstration
Provides instructions on how to build and run the CDC Serial Emulator Demonstration.
Prior to using this demonstration, it is recommended to review the MPLAB Harmony Release Notes for any known issues. A PDF copy of the
release notes is provided in the /doc folder of your installation.
Description
This application demonstrates the use of the CDC Device class in implementing a USB-to-Serial Dongle. The application enumerates a COM port
on the personal computer. Data received through the CDC USB interface is forwarded to a UART. Data received on the UART is forwarded to the
CDC USB interface. This emulates a USB-to-Serial Dongle.
1. Open_the project in MPLAB X IDE and select the desired configuration.
2. Build the code and program the device.
3. Depending on the hardware in use, do one of the following:
• If you are using the Explorer 16 board, connect the mini-B device connector on the USB PICtail Plus Daughter Board to the personal computer
• If you a are using the PIC32MZ EF starter kit, connect the micro-USB device connector to the personal computer
Volume I: Getting Started With MPLAB Harmony Applications Help USB Demonstrations
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 21
7. Select the "Install from a list or specific location (Advanced)" option. Specify the
/apps/usb/device/cdc_serial_emulator/inf directory.
The LEDs on the demonstration board will indicate the USB state of the device, as described in the USB Device State and LED Indication Table in
the Device section.
8. Open_a terminal emulation program of your choice and select the enumerated USB COM port.
9. Connect the USB-to-Serial Dongle to the same personal computer.
10. Open_another instance of the terminal emulation program and select the USB-to-Serial Dongle.
11. Connect the serial connector of the USB-to-Serial Dongle to the UART connector (P1) on the Explorer 16 Development Board.
12. Choose a baud rate of 9600, 1 Stop bit and no parity while opening both of the terminal emulation programs.
The setup should be similar to the following diagram.
Volume I: Getting Started With MPLAB Harmony Applications Help USB Demonstrations
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 22
Any text entered into the terminal 1 program will be echoed on terminal 2 and vice versa.
cdc_serial_emulator_msd
Demonstrates a USB to Serial Dongle combined with a MSD class.
Description
This demonstration application creates a USB Device that combines the functionality of the cdc_serial_emulator and msd_basic demonstration
applications.
Building the Application
This section identifies the MPLAB X IDE project name and location and lists and describes the available configurations for the this demonstration
application.
Description
To build this project, you must open the cdc_serial_emulator_msd.X project in MPLAB X IDE, and then select the desired configuration.
The following tables list and describe the project and supported configurations. The parent folder for these files is
/apps/usb/cdc_serial_emulator_msd.
MPLAB X IDE Project
This table lists the name and location of the MPLAB X IDE project folder for the demonstration.
Project Name Location
cdc_serial_emulator_msd.X /apps/usb/device/cdc_serial_emulator_msd/firmware
MPLAB X IDE Project Configurations
This table lists and describes the supported configurations of the demonstration, which are located within ./firmware/src/system_config.
Project Configuration Name BSP Used Description
pic32mx795_pim_e16_int_dyn pic32mx795_pim+e16 Select this MPLAB X IDE project configuration to run the demonstration on the Explorer
16 Development Board configured for Interrupt mode and dynamic operation. This
configuration also requires the PIC32MX795F512L Plug-In Module (PIM) and the USB
PICtail Plus Daughter Board.
Configuring the Hardware
Describes how to configure the supported hardware.
Description
PIC32MX795F512L CAN-USB PIM
Jumper J10 should be removed. Jumper J1 and J2 should_connect_to positions 1 and 2. This PIM should be used along with the Explorer 16
Development Board and the USB PICtail Plus daughter board. The microcontroller PIM should be plugged into the PIM_socket_on the board. The
USB PICtail Plus daughter board should be connected to the edge connector J9.
On the Explorer 16 Development Board:
Volume I: Getting Started With MPLAB Harmony Applications Help USB Demonstrations
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 23
• Switch S2 should be set to PIM
• Jumper JP2 should be in place
On the USB PICtail Plus Daughter Board:
• Jumper JP1 should be in place
• Jumper JP2 and JP4 should be removed
On the PIC32MX795F512L PIM:
• Keep jumper J10 open.
• Keep all jumpers in J9 open
• Jumper J1 should be shorted between positions 1 and 2
• Jumper J2 should be shorted between positions 1 and 2
Running the Demonstration
Provides instructions on how to build and run the demonstration.
Description
This demonstration functions as a composite USB Device that combines the features of the devices created by the cdc_serial_emulator and the
msd_basic demonstration applications. Refer to Running the Demonstration section of the cdc_serial_emulator demonstration and Running the
Demonstration section of the msd_basic demonstration for details on exercising the CDC and MSD functions, respectively.
The LEDs on the demonstration board will indicate the USB state of the device, as described in the USB Device State and LED Indication Table in
the Device section.
hid_basic
This demonstration application creates a custom HID device that can be controlled by a personal computer-based utility.
Description
This application creates a custom HID device that can be controlled by a personal computer-based utility. The device allows the USB Host utility to
control the LEDs on the board and query the status of a switch.
Building the Application
This section identifies the MPLAB X IDE project name and location and lists and describes the available configurations for the USB HID Basic
Demonstration.
Description
To build this project, you must open the hid_basic.X project in MPLAB X IDE, and then select the desired configuration.
The following tables list and describe the project and supported configurations. The parent folder for these files is
/apps/usb/device/hid_basic.
MPLAB X IDE Project
This table lists the name and location of the MPLAB X IDE project folder for the demonstration.
Project Name Location
hid_basic.X /apps/usb/device/hid_basic/firmware
MPLAB X IDE Project Configurations
This table lists and describes the supported configurations of the demonstration, which are located within ./firmware/src/system_config.
Project Configuration Name BSP Used Description
pic32mx460_pim_e16_int_dyn pic32mx460_pim+e16 Select this MPLAB X IDE project configuration to run the demonstration on the Explorer
16 Development Board configured for Interrupt mode and dynamic operation. This
configuration also requires the PIC32MX460F512L Plug-In Module (PIM) and the USB
PICtail Plus Daughter Board.
pic32mx_usb_sk3_int_dyn pic32mx_usb_sk3 Select this MPLAB X IDE project configuration to run the demonstration on the PIC32
USB Starter Kit III configured for Interrupt mode and dynamic operation.
pic32mx_usb_sk2_int_dyn pic32mx_usb_sk2 Select this MPLAB X IDE project configuration to run the demonstration on the PIC32
USB Starter Kit II configured for Interrupt mode and dynamic operation.
Volume I: Getting Started With MPLAB Harmony Applications Help USB Demonstrations
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 24
pic32mz_ef_sk_int_dyn pic32mz_ef_sk Select this MPLAB X IDE project configuration to run the demonstration on the PIC32MZ
Embedded Connectivity with Floating Point Unit (EF) Starter Kit configured for Interrupt
mode and dynamic operation.
Configuring the Hardware
Describes how to configure the supported hardware.
Description
PIC32 USB Starter Kit II
Remove jumper JP2.
PIC32MZ EF Starter Kit
No hardware related configuration or jumper setting changes are necessary.
PIC32 USB Starter Kit III
Remove jumper JP1.
PIC32MX460F512L PIM
Jumper J10 should be removed. This plug-in module should be used along with the Explorer 16 Development Board and the USB PICtail Plus
daughter board. The microcontroller PIM should be plugged into the PIM_socket_on the board. The USB PICtail Plus daughter board should be
connected to the edge connector J9.
On the Explorer 16 Development Board:
• Switch S2 should be set to PIM
• Jumper JP2 should be in place
On the USB PICtail Plus Daughter Board:
• Jumper JP1 should be in place
• Jumper JP2 and JP4 should be removed
On the PIC32MX460F512L PIM:
• Keep jumper J10 open
• Keep all jumpers in J9 open
Running the Demonstration
Provides instructions on how to build and run the HID Basic demonstration.
Description
This demonstration uses the selected hardware platform as a HID class USB device, but uses the HID class for general purpose I/O operations.
While compiling, select the appropriate MPLAB X IDE project configuration based on the demonstration board. Refer to Building the Application for
details.
Typically, the HID class is used to implement human interface products, such as mice and keyboards. The HID protocol, is however, quite flexible,
and can be adapted and used to send/receive general purpose data to/from a USB device. Using the HID class for general purpose I/O operations
is quite advantageous, in that it does not require any kind of custom driver installation process. HID class drivers are already provided by and are
distributed with common operating systems. Therefore, upon plugging in a HID class device into a typical computer system, no user installation of
drivers is required, the installation is fully automatic.
The LEDs on the demonstration board will indicate the USB state of the device, as described in the USB Device State and LED Indication Table in
the Device section.
HID devices primarily communicate through one interrupt IN endpoint and one interrupt OUT endpoint. In most applications, this effectively limits
the maximum achievable bandwidth for full speed HID devices to 64 kBytes/s of IN traffic, and 64 kBytes/s of OUT traffic (64 kB/s, but effectively
"full duplex").
The GenericHIDSimpleDemo.exe program, and the associated firmware demonstrate how to use the HID protocol for basic general purpose
USB data transfer.
Before you can run the GenericHIDSimpleDemo.exe executable, you will need to have the Microsoft® .NET Framework Version 2.0
Redistributable Package (later versions are probably acceptable, but have not been tested) installed on your computer. Programs that were built in
the Visual Studio® .NET languages require the .NET redistributable package. The redistributable package can be freely downloaded from
Microsoft’s website. Users of Windows Vista® operating systems will not need to install the .NET framework, as it comes preinstalled as part of the
operating system.
Volume I: Getting Started With MPLAB Harmony Applications Help USB Demonstrations
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 25
Launching the Application
To launch the application, simply double click the executable GenericHIDSimpleDemo.exe in the
\apps\usb\device\hid_basic\bin directory. A property sheet similar to the following should appear:
Note:
If instead of this window, an error message appears while trying to launch the application, it is likely the Microsoft .NET Framework
Version 2.0 Redistributable Package has not yet been installed. Please install it and try again.
Send/Receive Packets
To begin sending/receiving packets to the device, you must first find and_connect_ to the device. As configured by default, the application is
looking for HID class USB devices with VID = 0x04D8 and PID = 0x003F. The device descriptor in the firmware project meant to be used with this
demonstration uses the same VID/PID. If you plug in a USB device programmed with the correct precompiled .hex file, and click Connect, the
other push buttons should become enabled. If clicking Connect has no effect, it is likely the USB device is either not connected, or has not been
programmed with the correct firmware.
Clicking Toggle LED(s) should send a single packet of general purpose generic data to the HID class USB peripheral device. The data will arrive
on the interrupt OUT endpoint. The firmware has been configured to receive this generic data packet, parse the packet looking for the Toggle
LED(s) command, and should respond appropriately by controlling the LED(s) on the demonstration board.
The Get Pushbutton State option will send one packet of data over the USB to the peripheral device (to the interrupt OUT endpoint) requesting the
current push button state. The firmware will process the received Get Pushbutton State command, and will prepare an appropriate response
packet depending upon the pushbutton state.
The following table shows the button that has to be pressed on the demonstration board to see the change in the push button state.
Demonstration Board Button
PIC32 USB Starter Kit II
PIC32 USB Starter Kit III
PIC32MZ Embedded Connectivity (EC) Starter Kit
PIC32MZ Embedded Connectivity with Floating Point Unit (EF) Starter Kit
SW1
Explorer 16 Development Board S3
hid_joystick
Demonstrates a USB HID device emulating a joystick.
Description
This demonstration application creates a custom HID joystick. This application is only intended to demonstrate creation of Joystick HID Report
descriptors and may not be a definite end solution. The end application requirements may need the report descriptor to be modified.
Building the Application
This section identifies the MPLAB X IDE project name and location and lists and describes the available configurations for the USB HID Joystick
Demonstration.
Description
To build this project, you must open the hid_joystick.X project in MPLAB X IDE, and then select the desired configuration.
The following tables list and describe the project and supported configurations. The parent folder for these files is
/apps/usb/device/hid_joystick.
MPLAB X IDE Project
This table lists the name and location of the MPLAB X IDE project folder for the demonstration.
Project Name Location
hid_joystick.X /apps/usb/device/hid_joystick/firmware
Volume I: Getting Started With MPLAB Harmony Applications Help USB Demonstrations
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 26
MPLAB X IDE Project Configurations
This table lists and describes the supported configurations of the demonstration, which are located within ./firmware/src/system_config.
Project Configuration Name BSP Used Description
pic32mx460_pim_e16_int_dyn pic32mx460_pim+e16 Select this MPLAB X IDE project configuration to run the demonstration on the Explorer
16 Development Board configured for Interrupt mode and dynamic operation. This
configuration also requires the PIC32MX460F512L Plug-In Module (PIM) and the USB
PICtail Plus Daughter Board.
pic32mx_usb_sk3_int_dyn pic32mx_usb_sk3 Select this MPLAB X IDE project configuration to run the demonstration on the PIC32
USB Starter Kit III configured for Interrupt mode and dynamic operation.
pic32mx_usb_sk2_int_dyn pic32mx_usb_sk2 Select this MPLAB X IDE project configuration to run the demonstration on the PIC32
USB Starter Kit II configured for Interrupt mode and dynamic operation.
pic32mz_ef_sk_int_dyn pic32mz_ef_sk Select this MPLAB X IDE project configuration to run the demonstration on the PIC32MZ
Embedded Connectivity with Floating Point Unit (EF) Starter Kit configured for Interrupt
mode and dynamic operation.
Configuring the Hardware
Describes how to configure the supported hardware.
Description
PIC32 USB Starter Kit II
Remove jumper JP2.
PIC32MZ EF Starter Kit
No hardware related configuration or jumper setting changes are necessary.
PIC32 USB Starter Kit III
Remove jumper JP1.
PIC32MX460F512L PIM
Jumper J10 should be removed. This plug-in module should be used along with the Explorer 16 Development Board and the USB PICtail Plus
daughter board. The microcontroller PIM should be plugged into the PIM_socket_on the board. The USB PICtail Plus daughter board should be
connected to the edge connector J9.
On the Explorer 16 Development Board:
• Switch S2 should be set to PIM
• Jumper JP2 should be in place
On the USB PICtail Plus Daughter Board:
• Jumper JP1 should be in place
• Jumper JP2 and JP4 should be removed
On the PIC32MX460F512L PIM:
• Keep jumper J10 open
• Keep all jumpers in J9 open
Running the Demonstration
Provides instructions on how to build and run the USB HID Joystick demonstration.
Description
This demonstration uses the selected hardware platform as a USB Joystick. Select the appropriate MPLAB X IDE project configuration based on
the demonstration board. Refer to Building the Application for details.
The LEDs on the demonstration board will indicate the USB state of the device, as described in the USB Device State and LED Indication Table in
the Device section.
To test the joystick feature, navigate to the /apps/usb/device/hid_joystick/bin directory and open
JoystickTester.exe:
Volume I: Getting Started With MPLAB Harmony Applications Help USB Demonstrations
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 27
Pressing the button will cause the device to:
• Indicate that the "x" button is pressed, but no others
• Move the hat switch to the "east" position
• Move the X and Y coordinates to their extreme values
The Following table shows the button that has to be pressed on the demonstration board to emulate the joystick.
Demonstration Board Button
PIC32 USB Starter Kit II
PIC32 USB Starter Kit III
PIC32MZ Embedded Connectivity (EC) Starter Kit
PIC32MZ Embedded Connectivity with Floating Point Unit (EF) Starter Kit
SW1
Explorer 16 Development Board S3
Volume I: Getting Started With MPLAB Harmony Applications Help USB Demonstrations
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 28
hid_keyboard
Demonstrates a USB HID device, emulating a keyboard.
Description
This demonstration application creates a Generic HID keyboard. Pressing a key on the board emulates a keyboard key press.
Building the Application
This section identifies the MPLAB X IDE project name and location and lists and describes the available configurations for the USB HID Keyboard
Demonstration.
Description
To build this project, you must open the hid_keyboard.X project in MPLAB X IDE, and then select the desired configuration.
The following tables list and describe the project and supported configurations. The parent folder for these files is
/apps/usb/device/hid_keyboard.
MPLAB X IDE Project
This table lists the name and location of the MPLAB X IDE project folder for the demonstration.
Project Name Location
hid_keyboard.X /apps/usb/device/hid_keyboard/firmware
MPLAB X IDE Project Configurations
This table lists and describes the supported configurations of the demonstration, which are located within ./firmware/src/system_config.
Project Configuration Name BSP Used Description
pic32mx460_pim_e16_int_dyn pic32mx460_pim+e16 Select this MPLAB X IDE project configuration to run the demonstration on the Explorer
16 Development Board configured for Interrupt mode and dynamic operation. This
configuration also requires the PIC32MX460F512L Plug-In Module (PIM) and the USB
PICtail Plus Daughter Board.
pic32mx_usb_sk3_int_dyn pic32mx_usb_sk3 Select this MPLAB X IDE project configuration to run the demonstration on the PIC32
USB Starter Kit III configured for Interrupt mode and dynamic operation.
pic32mx_usb_sk2_int_dyn pic32mx_usb_sk2 Select this MPLAB X IDE project configuration to run the demonstration on the PIC32
USB Starter Kit II configured for Interrupt mode and dynamic operation.
pic32mz_ef_sk_int_dyn pic32mz_ef_sk Select this MPLAB X IDE project configuration to run the demonstration on the PIC32MZ
Embedded Connectivity with Floating Point Unit (EF) Starter Kit configured for Interrupt
mode and dynamic operation.
Configuring the Hardware
Describes how to configure the supported hardware.
Description
PIC32 USB Starter Kit II
Remove jumper JP2.
PIC32MZ EF Starter Kit
No hardware related configuration or jumper setting changes are necessary.
PIC32 USB Starter Kit III
Remove jumper JP1.
PIC32MX460F512L PIM
Jumper J10 should be removed. This plug-in module should be used along with the Explorer 16 Development Board and the USB PICtail Plus
daughter board. The microcontroller PIM should be plugged into the PIM_socket_on the board. The USB PICtail Plus daughter board should be
Volume I: Getting Started With MPLAB Harmony Applications Help USB Demonstrations
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 29
connected to the edge connector J9.
On the Explorer 16 Development Board:
• Switch S2 should be set to PIM
• Jumper JP2 should be in place
On the USB PICtail Plus Daughter Board:
• Jumper JP1 should be in place
• Jumper JP2 and JP4 should be removed
On the PIC32MX460F512L PIM:
• Keep jumper J10 open
• Keep all jumpers in J9 open
Running the Demonstration
Provides instructions on how to build and run the USB HID Keyboard demonstration.
Description
This demonstration uses the selected hardware platform as a USB keyboard. While compiling, select the appropriate MPLAB X IDE project
configuration based on the demonstration board. Refer to Building the Application for details.
The LEDs on the demonstration board will indicate the USB state of the device, as described in the USB Device State and LED Indication Table in
the Device section.
Before pressing the button, select a window in which it is safe to type text freely. Pressing the button on the demonstration board will cause the
device to print a character on the screen.
The following table shows the button that has to be pressed on the demonstration board to print a character.
Demonstration Board Button
PIC32 USB Starter Kit II
PIC32 USB Starter Kit III
PIC32MZ Embedded Connectivity (EC) Starter Kit
PIC32MZ Embedded Connectivity with Floating Point Unit (EF) Starter Kit
SW1
Explorer 16 Development Board S3
hid_mouse
Demonstrates a USB HID device, emulating a mouse pointing device.
Description
This demonstration application creates a USB HID based two-button mouse device. When connected, the device emulates mouse operation by
moving the cursor in a circular pattern.
Building the Application
This section identifies the MPLAB X IDE project name and location and lists and describes the available configurations for the USB HID Mouse
Demonstration.
Description
To build this project, you must open the hid_mouse.X project in MPLAB X IDE, and then select the desired configuration.
The following tables list and describe the project and supported configurations. The parent folder for these files is
/apps/usb/device/hid_mouse.
MPLAB X IDE Project
This table lists the name and location of the MPLAB X IDE project folder for the demonstration.
Project Name Location
hid_mouse.X /apps/usb/device/hid_mouse/firmware
MPLAB X IDE Project Configurations
This table lists and describes the supported configurations of the demonstration, which are located within ./firmware/src/system_config.
Volume I: Getting Started With MPLAB Harmony Applications Help USB Demonstrations
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 30
Project Configuration Name BSP Used Description
pic32mx460_pim_e16_int_dyn pic32mx460_pim+e16 Select this MPLAB X IDE project configuration to run the demonstration on the Explorer
16 Development Board configured for Interrupt mode and dynamic operation. This
configuration also requires the PIC32MX460F512L Plug-In Module (PIM) and the USB
PICtail Plus Daughter Board.
pic32mx_usb_sk3_int_dyn pic32mx_usb_sk3 Select this MPLAB X IDE project configuration to run the demonstration on the PIC32
USB Starter Kit III configured for Interrupt mode and dynamic operation.
pic32mx_usb_sk2_int_dyn pic32mx_usb_sk2 Select this MPLAB X IDE project configuration to run the demonstration on the PIC32
USB Starter Kit II configured for Interrupt mode and dynamic operation.
pic32mz_ef_sk_int_dyn pic32mz_ef_sk Select this MPLAB X IDE project configuration to run the demonstration on the PIC32MZ
Embedded Connectivity with Floating Point Unit (EF) Starter Kit configured for Interrupt
mode and dynamic operation.
Configuring the Hardware
Describes how to configure the supported hardware.
Description
PIC32 USB Starter Kit II
Remove jumper JP2.
PIC32MZ EF Starter Kit
No hardware related configuration or jumper setting changes are necessary.
PIC32 USB Starter Kit III
Remove jumper JP1.
PIC32MX460F512L PIM
Jumper J10 should be removed. This plug-in module should be used along with the Explorer 16 Development Board and the USB PICtail Plus
daughter board. The microcontroller PIM should be plugged into the PIM_socket_on the board. The USB PICtail Plus daughter board should be
connected to the edge connector J9.
On the Explorer 16 Development Board:
• Switch S2 should be set to PIM
• Jumper JP2 should be in place
On the USB PICtail Plus Daughter Board:
• Jumper JP1 should be in place
• Jumper JP2 and JP4 should be removed
On the PIC32MX460F512L PIM:
• Keep jumper J10 open
• Keep all jumpers in J9 open
Running the Demonstration
Provides instructions on how to build and run the HID Mouse Demonstration.
Description
This demonstration uses the selected hardware platform as a USB mouse. While compiling, select the appropriate MPLAB X IDE project
configuration based on the demonstration board. Refer to Building the Application for details.
The LEDs on the demonstration board will indicate the USB state of the device, as described in the USB Device State and LED Indication Table in
the Device section.
Before connecting the board to the computer through the USB cable please be aware that the device will begin moving the mouse cursor on the
computer. There are two ways to stop the device from allowing the cursor to continue to move. The first way is to disconnect the device from the
computer. The second is to press the correct button on the hardware platform. Pressing the button again will cause the mouse cursor to start
moving in a circle again.
The following table shows the button that has to be pressed on the demonstration board to stop the circular motion:
Volume I: Getting Started With MPLAB Harmony Applications Help USB Demonstrations
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 31
Demonstration Board Button
PIC32 USB Starter Kit II
PIC32 USB Starter Kit III
PIC32MZ Embedded Connectivity (EC) Starter Kit
PIC32MZ Embedded Connectivity with Floating Point Unit (EF) Starter Kit
SW1
Explorer 16 Development Board S3
hid_msd_basic
Demonstrates a HID Device Class and MSD class composite USB Device.
Description
This demonstration application creates a USB Device that combines the functionality of the hid_basic and msd_basic demonstration applications.
Building the Application
This section identifies the MPLAB X IDE project name and location and lists and describes the available configurations for the this demonstration
application.
Description
To build this project, you must open the hid_msd_basic.X project in MPLAB X IDE, and then select the desired configuration.
The following tables list and describe the project and supported configurations. The parent folder for these files is
/apps/usb/device/hid_msd_basic.
MPLAB X IDE Project
This table lists the name and location of the MPLAB X IDE project folder for the demonstration.
Project Name Location
hid_msd_basic.X /apps/usb/device/hid_msd_basic/firmware
MPLAB X IDE Project Configurations
This table lists and describes the supported configurations of the demonstration, which are located within ./firmware/src/system_config.
Project Configuration
Name
BSP Used Description
pic32mx_usb_sk2_int_dyn pic32mx_usb_sk2 Select this configuration to run the demonstration application on the PIC32 USB Starter Kit II
configured for Interrupt mode and dynamic operation.
pic32mz_ef_sk_int_dyn pic32mz_ef_sk Select this configuration to run the demonstration application on the PIC32MZ Embedded
Connectivity with Floating Point Unit (EF) Starter Kit configured for Interrupt mode and
dynamic operation.
Configuring the Hardware
Describes how to configure the supported hardware.
Description
PIC32 USB Starter Kit II
Remove jumper JP2.
PIC32MZ EF Starter Kit
No hardware related configuration or jumper setting changes are necessary.
Running the Demonstration
Provides instructions on how to build and run the demonstration.
Volume I: Getting Started With MPLAB Harmony Applications Help USB Demonstrations
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 32
Description
This demonstration functions as composite USB Device that combines the features of the devices created by the hid_basic and the msd_basic
demonstration applications. Refer to Running the Demonstration section of the hid_basic demonstration and Running the Demonstration section of
the msd_basic demonstration for details on exercising the HID and MSD functions, respectively.
The LEDs on the demonstration board will indicate the USB state of the device, as described in the USB Device State and LED Indication Table in
the Device section.
msd_basic
Demonstrates a USB MSD Device emulating a Flash Drive.
Description
This demonstration application creates a Flash drive using the Mass Storage Device Class.
Building the Application
This section identifies the MPLAB X IDE project name and location and lists and describes the available configurations for the USB MSD Basic
Demonstration.
Description
To build this project, you must open the msd_basic.X project in MPLAB X IDE, and then select the desired configuration.
The following tables list and describe the project and supported configurations. The parent folder for these files is
/apps/usb/device/msd_basic.
MPLAB X IDE Project
This table lists the name and location of the MPLAB X IDE project folder for the demonstration.
Project Name Location
msd_basic.X /apps/usb/device/msd_basic/firmware
MPLAB X IDE Project Configurations
This table lists and describes the supported configurations of the demonstration, which are located within ./firmware/src/system_config.
Project Configuration
Name
BSP Used Description
pic32mx_bt_sk_int_dyn pic32mx_bt_sk Select this MPLAB X IDE project configuration to run the demonstration on the PIC32
Bluetooth Starter Kit configured for Interrupt mode and dynamic operation.
pic32mx_usb_sk2_poll_dyn pic32mx_usb_sk2 Select this MPLAB X IDE project configuration to run the demonstration on the PIC32 USB
Starter Kit II with the USB Device Stack configured for Polled mode and dynamic operation..
pic32mx_usb_sk2_int_dyn pic32mx_usb_sk2 Select this MPLAB X IDE project configuration to run the demonstration on the PIC32 USB
Starter Kit II configured for Interrupt mode and dynamic operation.
pic32mx_usb_sk3_int_dyn pic32mx_usb_sk3 Select this MPLAB X IDE project configuration to run the demonstration on the PIC32 USB
Starter Kit III configured for Interrupt mode and dynamic operation.
pic32mz_ef_sk_int_dyn pic32mz_ef_sk Select this MPLAB X IDE project configuration to run the demonstration on the PIC32MZ
Embedded Connectivity with Floating Point Unit (EF) Starter Kit configured for Interrupt mode
and dynamic operation.
pic32mz_ef_sk_poll_dyn pic32mz_ef_sk Select this MPLAB X IDE project configuration to run the demonstration on the PIC32MZ
Embedded Connectivity with Floating Point Unit (EF) Starter Kit configured for Polled mode
and dynamic operation.
Configuring the Hardware
Describes how to configure the supported hardware.
Description
PIC32 USB Starter Kit II
Remove jumper JP2.
Volume I: Getting Started With MPLAB Harmony Applications Help USB Demonstrations
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 33
PIC32MZ EF Starter Kit
No hardware related configuration or jumper setting changes are necessary.
PIC32 USB Starter Kit III
Remove jumper JP1.
PIC32 Bluetooth Starter Kit
No hardware related configuration or jumper settings required.
PIC32MX460F512L PIM
Jumper J10 should be removed. This plug-in module should be used along with the Explorer 16 Development Board and the USB PICtail Plus
daughter board. The microcontroller PIM should be plugged into the PIM_socket_on the board. The USB PICtail Plus daughter board should be
connected to the edge connector J9.
On the Explorer 16 Development Board:
• Switch S2 should be set to PIM
• Jumper JP2 should be in place
On the USB PICtail Plus Daughter Board:
• Jumper JP1 should be in place
• Jumper JP2 and JP4 should be removed
Running the Demonstration
Provides instructions on how to build and run the USB MSD Basic demonstration.
Description
This demonstration uses the selected hardware platform as a logical drive on the computer using the internal Flash of the device as the drive
storage media. Connect the hardware platform to a computer through a USB cable. The device should appear as a new drive on the computer
named "Drive Name". The drive can used to store files.
The LEDs on the demonstration board will indicate the USB state of the device, as described in the USB Device State and LED Indication Table in
the Device section.
Note:
Reprogramming the development board will cause any stored files to be erased.
msd_fs_spiflash
This application demonstrates accessing the SPI Flash connected to the PIC32 device as a media by multiple clients.
Description
This application demonstrates accessing the SPI Flash connected to the PIC32 device as a media by multiple clients. When connected via USB to
the Host Computer, the SPI Flash is shown as the storage media. The Host writes files to the media, which is later accessed by the application
running on the PIC32 device using the File System.
Building the Application
This section identifies the MPLAB X IDE project name and location and lists and describes the available configurations for the USB MSD File
System SPI Flash Demonstration.
Description
To build this project, you must open the msd_fs_spiflash.X project in MPLAB X IDE, and then select the desired configuration.
The following tables list and describe the project and supported configurations. The parent folder for these files is
/apps/usb/device/msd_fs_spiflash.
MPLAB X IDE Project
This table lists the name and location of the MPLAB X IDE project folder for the demonstration.
Project Name Location
msd_fs_spiflash.X /apps/usb/device/msd_fs_spiflash/firmware
Volume I: Getting Started With MPLAB Harmony Applications Help USB Demonstrations
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 34
MPLAB X IDE Project Configurations
This table lists and describes the supported configurations of the demonstration, which are located within ./firmware/src/system_config.
Project Configuration
Name
BSP Used Description
bt_audio_dk_int_dyn bt_audio_dk Select this MPLAB X IDE project configuration to run the demonstration on the PIC32
Bluetooth Audio Development Kit.
Configuring the Hardware
Describes how to configure the supported hardware.
Description
PIC32 Bluetooth Audio Develoment Kit
Ensure that switch S1 is set to PIC32_MCLR.
Running the Demonstration
Provides instructions on how to build and run the USB MSD File System SPI Flash demonstration.
Description
This demonstration shows an example of:
• Accessing the media attached to PIC32 by multiple clients
• Application running on the PIC32 firmware accesses the media using the MPLAB Harmony File System
When connected to the USB Host the very first time, the user is expected to format the media and create a file named FILE.TXT in the root
directory of the media. The user can update the file to provide input for the application to glow the LEDs present on the development kit. The
application running on the PIC32 reads and interprets the data present in the file and accordingly turns ON or OFF the LEDs LED8 and LED9 of
the development kit. The format of input in the file FILE.TXT should be as follows:
• For turning ON an LED:
• LED8:1
• LED9:1
• For turning OFF an LED:
• LED8:0
• LED9:0
After having set the appropriate values in the file, the user can then press and release the wwitch SW1 located on the development kit for the
MPLAB Harmony File System running on the PIC32 to act upon the contents of the file.
The FS state machine of the demonstration is only triggered by the switch SW1. When the user presses and releases SW1 the following occurs:
• LED5 is turned ON to indicate that the FS state machine is running
• The USB is detached
• The file system on the SPI Flash is mounted
• The contents of FILE.TXT is read and acted upon. Depending on the values set in the file, the LEDs are either turned ON or OFF.
• Next, the file system is unmounted and the USB is reattached
• LED5 is turned OFF to indicate that FS state machine is no longer running
• If LED6 is turned ON during any part of the demonstration, this indicates the demonstration has failed
msd_multiple_luns
This topic demonstrates data transfer between two storage media - SD card and non-volatile memory (NVM) - and a computer through USB Mass
Storage Device (MSD).
Description
This application demonstrates the creation of a USB device with multiple logical units. The storage media, SD Card, acts as one logical unit, and
the NVM acts as the second logical unit. Data transfer between a computer and the logical units (SD Card / NVM) takes place through USB MSD.
Building the Application
This section identifies the MPLAB X IDE project name and location, and then lists and describes the available configurations for the USB MSD
multiple LUNs demonstration.
Volume I: Getting Started With MPLAB Harmony Applications Help USB Demonstrations
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 35
Description
To build this project, you must open the msd_multiple_luns.X project in MPLAB X IDE, and then select the desired configuration. The
following tables lists and describes the project and the supported configurations. The parent folder for these files is
/apps/usb/device/msd_multiple_luns
MPLAB X IDE Project
This table lists the name and location of the MPLAB X IDE project folder for the demonstration.
Project Name Location
msd_multiple_luns.X /apps/usb/device/msd_multiple_luns/firmware
MPLAB X IDE Project Configurations
This table lists and describes the supported configurations of the demonstration, which are located within ./firmware/src/system_config.
Project
Configuration Name
BSP Used Description
pic32mx470_curiosity pic32mx470_curiosity Select this MPLAB X IDE project configuration to run the demonstration on the PIC32MX470
Curiosity board with the USB device stack configured for Interrupt mode and full speed operation.
The LUN0 media type is configured as SD Card and LUN1 media type is configured as NVM.
pic32mz_ef_curiosity pic32mz_ef_curiosity Select this MPLAB X IDE project configuration to run the demonstration on the PIC32MZ EF
Curiosity board with the USB device stack configured for Interrupt mode and high speed
operation. The LUN0 media type is configured as SD Card and LUN1 media type is configured as
NVM.
Configuring the Hardware
This section describes how to configure the supported hardware.
Description
PIC32MX470 Curiosity Development Board
1. Ensure that a jumper is placed at 4-3 on J8, to select supply from debug USB connector.
2. Mount the SD Click board, "microSD click" from MikroElektronika (http://www.mikroe.com/click/microsd/) on the mikro bus interface J10.
3. Plug a micro SD card into the microSD click board card slot.
4. Power the PIC32MX470 Curiosity Development Board from a Host PC through a Type-A male to mini-B USB cable connected to Mini-B port
(J3).
5. Connect a Type-A male to micro USB cable to the micro USB port (J12) on PIC32MX470 Curiosity Development Board.
Volume I: Getting Started With MPLAB Harmony Applications Help USB Demonstrations
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 36
PIC32MZ EF Curiosity Development Board
1. Ensure that a jumper is placed at 4-3 on J8, to select supply from debug USB connector.
2. Mount the SD Click board, "microSD click" from MikroElektronika (http://www.mikroe.com/click/microsd/) on the mikro bus interface J10.
3. Plug a micro SD card into the microSD click board card slot.
4. Power the PIC32MZ EF Curiosity Development Board from a Host PC through a Type-A male to micro USB cable connected to micro USB port
(J3).
5. Connect a Type-A male to micro USB cable to the micro USB port (J12) on PIC32MZ EF Curiosity Development Board.
Volume I: Getting Started With MPLAB Harmony Applications Help USB Demonstrations
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 37
Running the Demonstration
This section provides instructions about how to build and run the USB MSD Multiple LUNs demonstration.
Description
This demonstration uses SD card and NVM as drive storage media and shows them as two logical drives on the computer.
• Connect the hardware platform to a computer through a USB cable.
• The device should appear as two new drives on the computer.
• The NVM media should appear as "Drive Name" and should have a sample “FILE.txt” file. The drive name for the SD card media depends
on the micro SD card vendor. The drives can then be used to store files.
• The LEDs on the demonstration board will indicate the USB state of the device, as described in the USB Device State and LED Indication
Table in the Device section.
Note:
Reprogramming the development board will cause any stored files in the NVM media to be erased.
msd_sdcard
Demonstrates data transfer from a SD card and a computer through USB MSD.
Volume I: Getting Started With MPLAB Harmony Applications Help USB Demonstrations
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 38
Description
This application demonstrates the usage of a SD card reader through the USB Mass Storage Device (MSD) class to transfer data between a
computer and SD card. High-Speed USB is used for communication between the Host computer and the PIC32 device, while a SD card is used as
the storage medium.
Building the Application
This section identifies the MPLAB X IDE project name and location and lists and describes the available configurations for the USB MSD SD Card
Demonstration.
Description
To build this project, you must open the msd_sdcard.X project in MPLAB X IDE, and then select the desired configuration.
The following tables list and describe the project and supported configurations. The parent folder for these files is
/apps/usb/device/msd_sdcard.
MPLAB X IDE Project
This table lists the name and location of the MPLAB X IDE project folder for the demonstration.
Project Name Location
msd_sdcard.X /apps/usb/device/msd_sdcard/firmware
MPLAB X IDE Project Configurations
This table lists and describes the supported configurations of the demonstration, which are located within ./firmware/src/system_config.
Project Configuration
Name
BSP Used Description
pic32mz_ec_sk_int_dyn pic32mz_ec_sk+meb2 Select this MPLAB X IDE project configuration to run the demonstration on the PIC32MZ EC
Starter Kit connected to the MEB II. The media drivers are configured for Interrupt mode and
dynamic operation.
Configuring the Hardware
Describes how to configure the supported hardware.
Description
PIC32MZ Embedded Connectivity (EC) Starter Kit and Multimedia Expansion Board II (MEB II)
No hardware related configuration or jumper settings required.
Running the Demonstration
Provides instructions on how to build and run the USB MSD SD Card demonstration.
Description
This demonstration uses the selected hardware platform as a logical drive on the computer using the SD card as the drive storage media. Connect
the hardware platform to a computer through a USB cable. The device should appear as a new drive on the computer named "Drive Name". The
drive can then be used to store files.
The LEDs on the demonstration board will indicate the USB state of the device, as described in the USB Device State and LED Indication Table in
the Device section.
vendor
Demonstrates a custom USB Device created by using the USB Device Layer Endpoint functions.
Description
This demonstration application creates a custom USB device using the USB Device Layer Endpoint functions.
Volume I: Getting Started With MPLAB Harmony Applications Help USB Demonstrations
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 39
Building the Application
This section identifies the MPLAB X IDE project name and location and lists and describes the available configurations for the Vendor USB Device
Demonstration.
Description
To build this project, you must open the vendor.X project in MPLAB X IDE, and then select the desired configuration.
The following tables list and describe the project and supported configurations. The parent folder for these files is
/apps/usb/device/vendor.
MPLAB X IDE Project
This table lists the name and location of the MPLAB X IDE project folder for the demonstration.
Project Name Location
vendor.X /apps/usb/device/vendor/firmware
MPLAB X IDE Project Configurations
This table lists and describes the supported configurations of the demonstration, which are located within ./firmware/src/system_config.
Project Configuration Name BSP Used Description
pic32mx460_pim_e16_int_dyn pic32mx460_pim+e16 Select this MPLAB X IDE project configuration to run the demonstration on the Explorer
16 Development Board configured for Interrupt mode and dynamic operation. This
configuration also requires the PIC32MX460F512L Plug-In Module (PIM) and the USB
PICtail Plus Daughter Board.
pic32mx_usb_sk3_int_dyn pic32mx_usb_sk3 Select this MPLAB X IDE project configuration to run the demonstration on the PIC32
USB Starter Kit III configured for Interrupt mode and dynamic operation.
pic32mx_usb_sk2_int_dyn pic32mx_usb_sk2 Select this MPLAB X IDE project configuration to run the demonstration on the PIC32
USB Starter Kit II configured for Interrupt mode and dynamic operation.
pic32mz_ef_sk_int_dyn pic32mz_ef_sk Select this MPLAB X IDE project configuration to run the demonstration on the PIC32MZ
Embedded Connectivity with Floating Point Unit (EF) Starter Kit configured for Interrupt
mode and dynamic operation.
Configuring the Hardware
Describes how to configure the supported hardware.
Description
PIC32 USB Starter Kit II
Remove jumper JP2.
PIC32MZ EF Starter Kit
No hardware related configuration or jumper setting changes are necessary.
PIC32 USB Starter Kit III
Remove jumper JP1.
PIC32MX460F512L PIM
Jumper J10 should be removed. This plug-in module should be used along with the Explorer 16 Development Board and the USB PICtail Plus
daughter board. The microcontroller PIM should be plugged into the PIM_socket_on the board. The USB PICtail Plus daughter board should be
connected to the edge connector J9.
On the Explorer 16 Development Board:
• Switch S2 should be set to PIM
• Jumper JP2 should be in place
On the USB PICtail Plus Daughter Board:
• Jumper JP1 should be in place
Volume I: Getting Started With MPLAB Harmony Applications Help USB Demonstrations
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 40
• Jumper JP2 and JP4 should be removed
On the PIC32MX460F512L PIM:
• Keep jumper J10 open
• Keep all jumpers in J9 open
Running the Demonstration
Provides instructions on how to build and run the Vendor USB Device demonstration.
Description
The Vendor device can be exercised by using the WinUSB PnP Demonstration application, which is provided in your installation of MPLAB
Harmony.
The LEDs on the demonstration board will indicate the USB state of the device, as described in the USB Device State and LED Indication Table in
the Device section.
This application allows the state of the LEDs on the board to be toggled and indicates the state of a switch (pressed/released) on the board.
To launch the application, double click WinUSB PnP Demo.exe located in /apps/usb/device/vendor/bin. A dialog box
similar to the following should appear:
The appropriate device family that is under testing should be selected in the utility. Pressing the Toggle LED button will cause the LED on the
board to toggle. The Pushbutton State field in the application indicates the state of a button on connected USB Device. Pressing the switch on the
development board will update the Pressed/Not Pressed status of the Pushbutton State field.
Demonstration Board Button
PIC32 USB Starter Kit II
PIC32 USB Starter Kit III
PIC32MZ Embedded Connectivity (EC) Starter Kit
PIC32MZ Embedded Connectivity with Floating Point Unit (EF) Starter Kit
SW1
Explorer 16 Development Board S3
Note:
The device family under test should be selected appropriately. An incorrect selection will result in an invalid push button status.
Host
This section describes the USB Host demonstrations.
audio_speaker
This application demonstrates the use of the Audio v1.0 Host Class Driver to enumerate and operate an audio speaker device.
Description
This application demonstrates the use of the Audio v1.0 Host Class Driver to enumerate and an audio speaker device. The application uses the
USB Host Layer and Audio 1.0 class driver to enumerate an Audio v1.0 USB device. The demonstration host application then operates and uses
the functionality of the attached audio speaker device.
Volume I: Getting Started With MPLAB Harmony Applications Help USB Demonstrations
© 2013-2017 Microchip Technology Inc. MPLAB Harmony v2.06 41
Building the Application
This section identifies the MPLAB X IDE project name and location and lists and describes the available configurations for the USB Host Audio
Speaker Demonstration.
Description
To build this project, you must open the audio_speaker.X project in MPLAB X IDE, and then select the desired configuration.
The following tables list and describe the project and supported configurations. The parent folder for these files is